From patchwork Fri Sep 4 13:30:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264379 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDE1FC2BB84 for ; Fri, 4 Sep 2020 14:25:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id ACCD7206B8 for ; Fri, 4 Sep 2020 14:25:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229548; bh=Z43hsJRsfSylTDdOsmfHse5zoUozD+qAvb/fuNHvOm8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=MWaxEzLWNKjInX7mXBsNsfQ/uUQlI8Z0TmROOKtYSpwQHJlB/LQaD1/xh6TDYBUAT NGPteQKBSCO0pH5uYkVQyhAlnvtdSNMJHR7KdTC/LbluuwdL46erGyzcIhCp87Xhz0 GyMSOvXTUYBSQ+M0K0yYBGzz4dFYCdX0QwJHgPNE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730480AbgIDOZr (ORCPT ); Fri, 4 Sep 2020 10:25:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:38078 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730465AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6AD2B2100A; Fri, 4 Sep 2020 13:30:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226252; bh=Z43hsJRsfSylTDdOsmfHse5zoUozD+qAvb/fuNHvOm8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zrXGU7JARtDotpczgh8kMNxCGYRTzDxN4nxc00ntZqTKikmXE44MaalT2Su91j7N4 TYealU5OZUHRdsbhrB256xiDwn3RPvftLYaGorIy9Ognv3kg97AaGeLThg6ilSjwwE YMQhDNVitR3NKOQcAHqTJ5dZNMbFGY+LJQ+L54lk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Zyngier , Benjamin Tissoires Subject: [PATCH 5.8 02/17] HID: core: Sanitize event code and type when mapping input Date: Fri, 4 Sep 2020 15:30:01 +0200 Message-Id: <20200904120258.098166396@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Marc Zyngier commit 35556bed836f8dc07ac55f69c8d17dce3e7f0e25 upstream. When calling into hid_map_usage(), the passed event code is blindly stored as is, even if it doesn't fit in the associated bitmap. This event code can come from a variety of sources, including devices masquerading as input devices, only a bit more "programmable". Instead of taking the event code at face value, check that it actually fits the corresponding bitmap, and if it doesn't: - spit out a warning so that we know which device is acting up - NULLify the bitmap pointer so that we catch unexpected uses Code paths that can make use of untrusted inputs can now check that the mapping was indeed correct and bail out if not. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Benjamin Tissoires Signed-off-by: Greg Kroah-Hartman --- drivers/hid/hid-input.c | 4 ++++ drivers/hid/hid-multitouch.c | 2 ++ include/linux/hid.h | 42 +++++++++++++++++++++++++++++------------- 3 files changed, 35 insertions(+), 13 deletions(-) --- a/drivers/hid/hid-input.c +++ b/drivers/hid/hid-input.c @@ -1132,6 +1132,10 @@ static void hidinput_configure_usage(str } mapped: + /* Mapping failed, bail out */ + if (!bit) + return; + if (device->driver->input_mapped && device->driver->input_mapped(device, hidinput, field, usage, &bit, &max) < 0) { --- a/drivers/hid/hid-multitouch.c +++ b/drivers/hid/hid-multitouch.c @@ -856,6 +856,8 @@ static int mt_touch_input_mapping(struct code = BTN_0 + ((usage->hid - 1) & HID_USAGE); hid_map_usage(hi, usage, bit, max, EV_KEY, code); + if (!*bit) + return -1; input_set_capability(hi->input, EV_KEY, code); return 1; --- a/include/linux/hid.h +++ b/include/linux/hid.h @@ -959,34 +959,49 @@ static inline void hid_device_io_stop(st * @max: maximal valid usage->code to consider later (out parameter) * @type: input event type (EV_KEY, EV_REL, ...) * @c: code which corresponds to this usage and type + * + * The value pointed to by @bit will be set to NULL if either @type is + * an unhandled event type, or if @c is out of range for @type. This + * can be used as an error condition. */ static inline void hid_map_usage(struct hid_input *hidinput, struct hid_usage *usage, unsigned long **bit, int *max, - __u8 type, __u16 c) + __u8 type, unsigned int c) { struct input_dev *input = hidinput->input; - - usage->type = type; - usage->code = c; + unsigned long *bmap = NULL; + unsigned int limit = 0; switch (type) { case EV_ABS: - *bit = input->absbit; - *max = ABS_MAX; + bmap = input->absbit; + limit = ABS_MAX; break; case EV_REL: - *bit = input->relbit; - *max = REL_MAX; + bmap = input->relbit; + limit = REL_MAX; break; case EV_KEY: - *bit = input->keybit; - *max = KEY_MAX; + bmap = input->keybit; + limit = KEY_MAX; break; case EV_LED: - *bit = input->ledbit; - *max = LED_MAX; + bmap = input->ledbit; + limit = LED_MAX; break; } + + if (unlikely(c > limit || !bmap)) { + pr_warn_ratelimited("%s: Invalid code %d type %d\n", + input->name, c, type); + *bit = NULL; + return; + } + + usage->type = type; + usage->code = c; + *max = limit; + *bit = bmap; } /** @@ -1000,7 +1015,8 @@ static inline void hid_map_usage_clear(s __u8 type, __u16 c) { hid_map_usage(hidinput, usage, bit, max, type, c); - clear_bit(c, *bit); + if (*bit) + clear_bit(usage->code, *bit); } /** From patchwork Fri Sep 4 13:30:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310121 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84310C433E2 for ; Fri, 4 Sep 2020 14:25:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 50C2A20709 for ; Fri, 4 Sep 2020 14:25:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229554; bh=HFapN7zvtezMJU2LiF4VaXhhRaky00ItAw3UbeyTDWI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=GSoOLpJGNZHsXGTNd5ACrigTa1dpbI2Y2gy7g4eTzdxgQ7wF6mL5qrUnlQKzwWhL7 uNjcZjOsn6cV+H0YXnG74xd6TfTHu8CyDWRtY6wO8N9wShzx2TjkxQCEbGh8fx2/RL V9r5VIkx1o4shlCGuXL28uQpATkKs6AGgwDtHe/0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730270AbgIDOZs (ORCPT ); Fri, 4 Sep 2020 10:25:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:37290 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730458AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AC94321556; Fri, 4 Sep 2020 13:30:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226255; bh=HFapN7zvtezMJU2LiF4VaXhhRaky00ItAw3UbeyTDWI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xzpXfwoXQ+U6j4/hneahUFy7kPQUE0mqzWKwkeM9n0HE559fUWOU3VEgSVsUjBuAx ciLtzUwScbKdrZLfCImWBlVCLr7ppAqo5zwFrqzmihyBghj5xNs1ThYoP7KoNGWXLC yNKu9hCbBON6othyl/bZQTa9ykpDg18E8/qTbNe8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andreas Fischer , Stefano Brivio , Pablo Neira Ayuso Subject: [PATCH 5.8 03/17] netfilter: nft_set_rbtree: Handle outcomes of tree rotations in overlap detection Date: Fri, 4 Sep 2020 15:30:02 +0200 Message-Id: <20200904120258.147134635@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Stefano Brivio commit 226a88de473e475cb9f993682a1c7d0c2b451ad8 upstream. Checks for partial overlaps on insertion assume that end elements are always descendant nodes of their corresponding start, because they are inserted later. However, this is not the case if a previous delete operation caused a tree rotation as part of rebalancing. Taking the issue reported by Andreas Fischer as an example, if we omit delete operations, the existing procedure works because, equivalently, we are inserting a start item with value 40 in the this region of the red-black tree with single-sized intervals: overlap flag 10 (start) / \ false 20 (start) / \ false 30 (start) / \ false 60 (start) / \ false 50 (end) / \ false 20 (end) / \ false 40 (start) if we now delete interval 30 - 30, the tree can be rearranged in a way similar to this (note the rotation involving 50 - 50): overlap flag 10 (start) / \ false 20 (start) / \ false 25 (start) / \ false 70 (start) / \ false 50 (end) / \ true (from rule a1.) 50 (start) / \ true 40 (start) and we traverse interval 50 - 50 from the opposite direction compared to what was expected. To deal with those cases, add a start-before-start rule, b4., that covers traversal of existing intervals from the right. We now need to restrict start-after-end rule b3. to cases where there are no occurring nodes between existing start and end elements, because addition of rule b4. isn't sufficient to ensure that the pre-existing end element we encounter while descending the tree corresponds to a start element of an interval that we already traversed entirely. Different types of overlap detection on trees with rotations resulting from re-balancing will be covered by nft test case sets/0044interval_overlap_1. Reported-by: Andreas Fischer Bugzilla: https://bugzilla.netfilter.org/show_bug.cgi?id=1449 Cc: # 5.6.x Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Signed-off-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman --- net/netfilter/nft_set_rbtree.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) --- a/net/netfilter/nft_set_rbtree.c +++ b/net/netfilter/nft_set_rbtree.c @@ -238,21 +238,27 @@ static int __nft_rbtree_insert(const str * * b1. _ _ __>| !_ _ __| (insert end before existing start) * b2. _ _ ___| !_ _ _>| (insert end after existing start) - * b3. _ _ ___! >|_ _ __| (insert start after existing end) + * b3. _ _ ___! >|_ _ __| (insert start after existing end, as a leaf) + * '--' no nodes falling in this range + * b4. >|_ _ ! (insert start before existing start) * * Case a3. resolves to b3.: * - if the inserted start element is the leftmost, because the '0' * element in the tree serves as end element - * - otherwise, if an existing end is found. Note that end elements are - * always inserted after corresponding start elements. + * - otherwise, if an existing end is found immediately to the left. If + * there are existing nodes in between, we need to further descend the + * tree before we can conclude the new start isn't causing an overlap + * + * or to b4., which, preceded by a3., means we already traversed one or + * more existing intervals entirely, from the right. * * For a new, rightmost pair of elements, we'll hit cases b3. and b2., * in that order. * * The flag is also cleared in two special cases: * - * b4. |__ _ _!|<_ _ _ (insert start right before existing end) - * b5. |__ _ >|!__ _ _ (insert end right after existing start) + * b5. |__ _ _!|<_ _ _ (insert start right before existing end) + * b6. |__ _ >|!__ _ _ (insert end right after existing start) * * which always happen as last step and imply that no further * overlapping is possible. @@ -272,7 +278,7 @@ static int __nft_rbtree_insert(const str if (nft_rbtree_interval_start(new)) { if (nft_rbtree_interval_end(rbe) && nft_set_elem_active(&rbe->ext, genmask) && - !nft_set_elem_expired(&rbe->ext)) + !nft_set_elem_expired(&rbe->ext) && !*p) overlap = false; } else { overlap = nft_rbtree_interval_end(rbe) && @@ -288,10 +294,9 @@ static int __nft_rbtree_insert(const str nft_set_elem_active(&rbe->ext, genmask) && !nft_set_elem_expired(&rbe->ext); - } else if (nft_rbtree_interval_end(rbe) && - nft_set_elem_active(&rbe->ext, genmask) && + } else if (nft_set_elem_active(&rbe->ext, genmask) && !nft_set_elem_expired(&rbe->ext)) { - overlap = true; + overlap = nft_rbtree_interval_end(rbe); } } else { if (nft_rbtree_interval_end(rbe) && From patchwork Fri Sep 4 13:30:03 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310123 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65F4DC43461 for ; Fri, 4 Sep 2020 14:22:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B5AA2074A for ; Fri, 4 Sep 2020 14:22:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229323; bh=wvxtajZLIXfuNmxZJFRiIF+SaRJ8cKhztaeZ5ho8vSM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=DlMse3FmkywRZthMInBU3UNH1FFCT0oiLJTdPe4L7tyI+GQvhKf4/clcpHX/OXQz/ hXP81uA3ibHSUCcVyFYr1PppDQbhU3RkgVxJmYOaONDMSHY3Nxv8sZzidvI/nLU8p+ 6waczjiNe4wXOVFChtZ1N8YRF7NcZwus22geJMtg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730767AbgIDOVx (ORCPT ); Fri, 4 Sep 2020 10:21:53 -0400 Received: from mail.kernel.org ([198.145.29.99]:37296 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730455AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E2F2821582; Fri, 4 Sep 2020 13:30:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226257; bh=wvxtajZLIXfuNmxZJFRiIF+SaRJ8cKhztaeZ5ho8vSM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wZHRpDb2i3nlvTU6bfSEM/HUQ/rL7EUZH2+1BJJPU80LdC+5021ICTi/88lJYqoOQ BjAQDV/k6z3yXxvdtkkTZfyRANS7Vq/Q6PSSXC3BWXo8dZcIXgUgLzPo0HcKjL01wQ nC5L5bhhu86OHxoKSOJsjkkO6gbK2MIgENdzrJxs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dave Hansen , Peter Zijlstra , John Hubbard , Andy Lutomirski , x86@kernel.org, Jann Horn , Andrew Morton , "Kirill A. Shutemov" , Linus Torvalds Subject: [PATCH 5.8 04/17] mm: fix pin vs. gup mismatch with gate pages Date: Fri, 4 Sep 2020 15:30:03 +0200 Message-Id: <20200904120258.196815367@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Dave Hansen commit 9fa2dd946743ae6f30dc4830da19147bf100a7f2 upstream. Gate pages were missed when converting from get to pin_user_pages(). This can lead to refcount imbalances. This is reliably and quickly reproducible running the x86 selftests when vsyscall=emulate is enabled (the default). Fix by using try_grab_page() with appropriate flags passed. The long story: Today, pin_user_pages() and get_user_pages() are similar interfaces for manipulating page reference counts. However, "pins" use a "bias" value and manipulate the actual reference count by 1024 instead of 1 used by plain "gets". That means that pin_user_pages() must be matched with unpin_user_pages() and can't be mixed with a plain put_user_pages() or put_page(). Enter gate pages, like the vsyscall page. They are pages usually in the kernel image, but which are mapped to userspace. Userspace is allowed access to them, including interfaces using get/pin_user_pages(). The refcount of these kernel pages is manipulated just like a normal user page on the get/pin side so that the put/unpin side can work the same for normal user pages or gate pages. get_gate_page() uses try_get_page() which only bumps the refcount by 1, not 1024, even if called in the pin_user_pages() path. If someone pins a gate page, this happens: pin_user_pages() get_gate_page() try_get_page() // bump refcount +1 ... some time later unpin_user_pages() page_ref_sub_and_test(page, 1024)) ... and boom, we get a refcount off by 1023. This is reliably and quickly reproducible running the x86 selftests when booted with vsyscall=emulate (the default). The selftests use ptrace(), but I suspect anything using pin_user_pages() on gate pages could hit this. To fix it, simply use try_grab_page() instead of try_get_page(), and pass 'gup_flags' in so that FOLL_PIN can be respected. This bug traces back to the very beginning of the FOLL_PIN support in commit 3faa52c03f44 ("mm/gup: track FOLL_PIN pages"), which showed up in the 5.7 release. Signed-off-by: Dave Hansen Fixes: 3faa52c03f44 ("mm/gup: track FOLL_PIN pages") Reported-by: Peter Zijlstra Reviewed-by: John Hubbard Acked-by: Andy Lutomirski Cc: x86@kernel.org Cc: Jann Horn Cc: Andrew Morton Cc: Kirill A. Shutemov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/gup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/gup.c +++ b/mm/gup.c @@ -843,7 +843,7 @@ static int get_gate_page(struct mm_struc goto unmap; *page = pte_page(*pte); } - if (unlikely(!try_get_page(*page))) { + if (unlikely(!try_grab_page(*page, gup_flags))) { ret = -ENOMEM; goto unmap; } From patchwork Fri Sep 4 13:30:04 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264378 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B6E6C43461 for ; Fri, 4 Sep 2020 14:26:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E56B1206B8 for ; Fri, 4 Sep 2020 14:26:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229561; bh=JwQ7xpsQPSQRg6LDxLlqmQ2JIHnKRfij90mKN1gXFYg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=e0Qv0aR7I81YX4OhNzWQM4JvpoYUDdlkqSaFfqC3LtJf7NlsphbqWuFREXkMNNj1g O2O5cdtGdTyCRqtlGgaal7OT5+OeJuHgHv8ixe2EJPJVdf46ZT9skNT+q6C/hBSm3D 7r2sljVoB5QwkbR1ngteW+oX9l/YW46JNx0X2aj8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730599AbgIDOZ4 (ORCPT ); Fri, 4 Sep 2020 10:25:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:38080 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730466AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9447D215A4; Fri, 4 Sep 2020 13:30:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226260; bh=JwQ7xpsQPSQRg6LDxLlqmQ2JIHnKRfij90mKN1gXFYg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H6AHYyO3GqRo3IC5qeXG/l9MlHYkZe7syAhPGBckTYKFBhrkF8Hr/3tnmYs153ftA TQ4FREpjJfWcEu9a8brZFZZ7+cduakZ4ZlZ0MzMoQqlPpXWA9dHBa0v4DpFs6dSKvR nK3Gh3CUA7CdeEyHO0VUh6Lg+FqhgKeokmt3bEhc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Andy Lutomirski , Dave Hansen , x86@kernel.org, Peter Zijlstra , Jann Horn , John Hubbard , Andrew Morton , "Kirill A. Shutemov" , Linus Torvalds Subject: [PATCH 5.8 05/17] selftests/x86/test_vsyscall: Improve the process_vm_readv() test Date: Fri, 4 Sep 2020 15:30:04 +0200 Message-Id: <20200904120258.245905910@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Andy Lutomirski commit 8891adc61dce2a8a41fc0c23262b681c3ec4b73a upstream. The existing code accepted process_vm_readv() success or failure as long as it didn't return garbage. This is too weak: if the vsyscall page is readable, then process_vm_readv() should succeed and, if the page is not readable, then it should fail. Signed-off-by: Andy Lutomirski Signed-off-by: Dave Hansen Cc: x86@kernel.org Cc: Peter Zijlstra Cc: Andy Lutomirski Cc: Jann Horn Cc: John Hubbard Cc: Andrew Morton Cc: Kirill A. Shutemov Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- tools/testing/selftests/x86/test_vsyscall.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/x86/test_vsyscall.c +++ b/tools/testing/selftests/x86/test_vsyscall.c @@ -462,6 +462,17 @@ static int test_vsys_x(void) return 0; } +/* + * Debuggers expect ptrace() to be able to peek at the vsyscall page. + * Use process_vm_readv() as a proxy for ptrace() to test this. We + * want it to work in the vsyscall=emulate case and to fail in the + * vsyscall=xonly case. + * + * It's worth noting that this ABI is a bit nutty. write(2) can't + * read from the vsyscall page on any kernel version or mode. The + * fact that ptrace() ever worked was a nice courtesy of old kernels, + * but the code to support it is fairly gross. + */ static int test_process_vm_readv(void) { #ifdef __x86_64__ @@ -477,8 +488,12 @@ static int test_process_vm_readv(void) remote.iov_len = 4096; ret = process_vm_readv(getpid(), &local, 1, &remote, 1, 0); if (ret != 4096) { - printf("[OK]\tprocess_vm_readv() failed (ret = %d, errno = %d)\n", ret, errno); - return 0; + /* + * We expect process_vm_readv() to work if and only if the + * vsyscall page is readable. + */ + printf("[%s]\tprocess_vm_readv() failed (ret = %d, errno = %d)\n", vsyscall_map_r ? "FAIL" : "OK", ret, errno); + return vsyscall_map_r ? 1 : 0; } if (vsyscall_map_r) { @@ -488,6 +503,9 @@ static int test_process_vm_readv(void) printf("[FAIL]\tIt worked but returned incorrect data\n"); return 1; } + } else { + printf("[FAIL]\tprocess_rm_readv() succeeded, but it should have failed in this configuration\n"); + return 1; } #endif From patchwork Fri Sep 4 13:30:05 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310132 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FFABC43461 for ; Fri, 4 Sep 2020 13:34:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C3FFD204FD for ; Fri, 4 Sep 2020 13:34:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226484; bh=Qoayjoiq0uSKgxLGXmLIhulkMjEAiiCj6O1lrgz1Tlc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=UqOG+52AP8Dp2c5So1wYgDHGLhc6BvFoI2OaBdagTXyO1ZGbluu+quegXVP8qsHZz 1jHaqa12ElxCda+yflaUZdynii1YfnEuM0FzssFBuLWoreI2baVjUdX88KZSofR5S0 EuUV4oiImHUo+AKGD9Ka50hwrmbnwN//FZOdpijA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730491AbgIDNeZ (ORCPT ); Fri, 4 Sep 2020 09:34:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:38082 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730467AbgIDNeW (ORCPT ); Fri, 4 Sep 2020 09:34:22 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0BC5B21655; Fri, 4 Sep 2020 13:31:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226262; bh=Qoayjoiq0uSKgxLGXmLIhulkMjEAiiCj6O1lrgz1Tlc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ygBMttGZzvyz7hq5c6blWlcm1lwWKR3tVUPr5h+ZkjA82qvuE4LvD1L1QESZit10V SJvC04yOVDN5k2SAmw3dHeryzWnRdtkdrdxKE+Jt5xQC7wt0yR8cVXnUBcZZAlrLJq Tc8G8DQv3xMDX5ELDtYvY1wURQIAikptpBZbJAQg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kim Phillips , Adrian Hunter , Alexander Shishkin , Alexey Budankov , Ian Rogers , Jin Yao , Jiri Olsa , Mark Rutland , Namhyung Kim , Paul Clarke , Peter Zijlstra , Stephane Eranian , Tony Jones , Arnaldo Carvalho de Melo Subject: [PATCH 5.8 06/17] perf record/stat: Explicitly call out event modifiers in the documentation Date: Fri, 4 Sep 2020 15:30:05 +0200 Message-Id: <20200904120258.295056672@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Kim Phillips commit e48a73a312ebf19cc3d72aa74985db25c30757c1 upstream. Event modifiers are not mentioned in the perf record or perf stat manpages. Add them to orient new users more effectively by pointing them to the perf list manpage for details. Fixes: 2055fdaf8703 ("perf list: Document precise event sampling for AMD IBS") Signed-off-by: Kim Phillips Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexey Budankov Cc: Ian Rogers Cc: Jin Yao Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Paul Clarke Cc: Peter Zijlstra Cc: Stephane Eranian Cc: Tony Jones Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/20200901215853.276234-1-kim.phillips@amd.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman --- tools/perf/Documentation/perf-record.txt | 4 ++++ tools/perf/Documentation/perf-stat.txt | 4 ++++ 2 files changed, 8 insertions(+) --- a/tools/perf/Documentation/perf-record.txt +++ b/tools/perf/Documentation/perf-record.txt @@ -33,6 +33,10 @@ OPTIONS - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a hexadecimal event descriptor. + - a symbolic or raw PMU event followed by an optional colon + and a list of event modifiers, e.g., cpu-cycles:p. See the + linkperf:perf-list[1] man page for details on event modifiers. + - a symbolically formed PMU event like 'pmu/param1=0x3,param2/' where 'param1', 'param2', etc are defined as formats for the PMU in /sys/bus/event_source/devices//format/*. --- a/tools/perf/Documentation/perf-stat.txt +++ b/tools/perf/Documentation/perf-stat.txt @@ -39,6 +39,10 @@ report:: - a raw PMU event (eventsel+umask) in the form of rNNN where NNN is a hexadecimal event descriptor. + - a symbolic or raw PMU event followed by an optional colon + and a list of event modifiers, e.g., cpu-cycles:p. See the + linkperf:perf-list[1] man page for details on event modifiers. + - a symbolically formed event like 'pmu/param1=0x3,param2/' where param1 and param2 are defined as formats for the PMU in /sys/bus/event_source/devices//format/* From patchwork Fri Sep 4 13:30:06 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264377 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77F6AC433E2 for ; Fri, 4 Sep 2020 14:26:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4D736206B8 for ; Fri, 4 Sep 2020 14:26:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229573; bh=BxUZNLAprx2ZNy1EjFaO8fkvg3UKlR/PaDsQLdY9Mgo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=tjTG7lOLWVXajPuUSCbpLZjXHbc5hGMsTufL1lPFZEyHqRfozxe7MxSpBxcIeDvzO sv97c2k8NDunTTpqsMtWM5ziglduwz0MWIOvv786vUl9FUyT1PInQ8gMbwLh9g4SfD 7iTeQKcq0Q5MTE3YBfMYl+wofrZl/F18GOJ3fErk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730707AbgIDO0J (ORCPT ); Fri, 4 Sep 2020 10:26:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:38084 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730469AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5FD712168B; Fri, 4 Sep 2020 13:31:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226264; bh=BxUZNLAprx2ZNy1EjFaO8fkvg3UKlR/PaDsQLdY9Mgo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=COHiWJLEOjm913yP+bctzKEUMeUtQeFOSw+1NqsW6wyKxfQX7rR+qgmsHP5WlC5ww ai/uMtUos4pPODS5Fesc9bK4iEafq991dvarvASup/YKpP5G8rUqQB9idB0F+iE8SJ YnLm2tltAYjvqW78gJpNz3gWtpR6NJ6DF0OTtx6I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Laurent Pinchart , Arnd Bergmann , Peilin Ye , Hans Verkuil , Mauro Carvalho Chehab , syzbot+79d751604cb6f29fbf59@syzkaller.appspotmail.com Subject: [PATCH 5.8 07/17] media: media/v4l2-core: Fix kernel-infoleak in video_put_user() Date: Fri, 4 Sep 2020 15:30:06 +0200 Message-Id: <20200904120258.352370251@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Peilin Ye commit 4ffb879ea648c2b42da4ca992ed3db87e564af69 upstream. video_put_user() is copying uninitialized stack memory to userspace due to the compiler not initializing holes in the structures declared on the stack. Fix it by initializing `ev32` and `vb32` using memset(). Reported-and-tested-by: syzbot+79d751604cb6f29fbf59@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=79d751604cb6f29fbf59 Cc: stable@vger.kernel.org Fixes: 1a6c0b36dd19 ("media: v4l2-core: fix VIDIOC_DQEVENT for time64 ABI") Fixes: 577c89b0ce72 ("media: v4l2-core: fix v4l2_buffer handling for time64 ABI") Reviewed-by: Laurent Pinchart Reviewed-by: Arnd Bergmann Signed-off-by: Peilin Ye Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman --- drivers/media/v4l2-core/v4l2-ioctl.c | 50 ++++++++++++++++++----------------- 1 file changed, 27 insertions(+), 23 deletions(-) --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -3186,14 +3186,16 @@ static int video_put_user(void __user *a #ifdef CONFIG_COMPAT_32BIT_TIME case VIDIOC_DQEVENT_TIME32: { struct v4l2_event *ev = parg; - struct v4l2_event_time32 ev32 = { - .type = ev->type, - .pending = ev->pending, - .sequence = ev->sequence, - .timestamp.tv_sec = ev->timestamp.tv_sec, - .timestamp.tv_nsec = ev->timestamp.tv_nsec, - .id = ev->id, - }; + struct v4l2_event_time32 ev32; + + memset(&ev32, 0, sizeof(ev32)); + + ev32.type = ev->type; + ev32.pending = ev->pending; + ev32.sequence = ev->sequence; + ev32.timestamp.tv_sec = ev->timestamp.tv_sec; + ev32.timestamp.tv_nsec = ev->timestamp.tv_nsec; + ev32.id = ev->id; memcpy(&ev32.u, &ev->u, sizeof(ev->u)); memcpy(&ev32.reserved, &ev->reserved, sizeof(ev->reserved)); @@ -3207,21 +3209,23 @@ static int video_put_user(void __user *a case VIDIOC_DQBUF_TIME32: case VIDIOC_PREPARE_BUF_TIME32: { struct v4l2_buffer *vb = parg; - struct v4l2_buffer_time32 vb32 = { - .index = vb->index, - .type = vb->type, - .bytesused = vb->bytesused, - .flags = vb->flags, - .field = vb->field, - .timestamp.tv_sec = vb->timestamp.tv_sec, - .timestamp.tv_usec = vb->timestamp.tv_usec, - .timecode = vb->timecode, - .sequence = vb->sequence, - .memory = vb->memory, - .m.userptr = vb->m.userptr, - .length = vb->length, - .request_fd = vb->request_fd, - }; + struct v4l2_buffer_time32 vb32; + + memset(&vb32, 0, sizeof(vb32)); + + vb32.index = vb->index; + vb32.type = vb->type; + vb32.bytesused = vb->bytesused; + vb32.flags = vb->flags; + vb32.field = vb->field; + vb32.timestamp.tv_sec = vb->timestamp.tv_sec; + vb32.timestamp.tv_usec = vb->timestamp.tv_usec; + vb32.timecode = vb->timecode; + vb32.sequence = vb->sequence; + vb32.memory = vb->memory; + vb32.m.userptr = vb->m.userptr; + vb32.length = vb->length; + vb32.request_fd = vb->request_fd; if (copy_to_user(arg, &vb32, sizeof(vb32))) return -EFAULT; From patchwork Fri Sep 4 13:30:07 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264380 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2FC43C433E2 for ; Fri, 4 Sep 2020 14:21:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E2F4320797 for ; Fri, 4 Sep 2020 14:21:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229317; bh=7Igl/N2E3zZvyoS60wvEZZPsthK5fqko3m+FNuWCYYA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=tY8stXHsbz2AUGIBa2VEtVyeLsfWriz4xA7ZVdNl3Ut7okNvUKZmknGxAyz7lrdTh AAN0Fqn5gDS/6PEXLiEHKE4scyFecXslS4Y4QI/XzzpF8wPeONZOfiNX7m2icpcOkT AG/uEKO31TKcm8GlWilJIgdBlyMqtrYwOmtPpk4c= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730677AbgIDOVu (ORCPT ); Fri, 4 Sep 2020 10:21:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:36824 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730374AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AFE0721707; Fri, 4 Sep 2020 13:31:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226267; bh=7Igl/N2E3zZvyoS60wvEZZPsthK5fqko3m+FNuWCYYA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tiBnEGDzH8DYQzhD6TVrWZN2KXNbLiGcUGcw/SdwqiRUwWJInqSsl5klLAryxQEeN c5Xg8peOUTDHM0sdb7WWs1ql4DpCj4IPtfpiyzMycDpODSKJSJUeug/42nNB5ftVId iKTv+bW3aHiDLTJ6WJ4rYx251lJ4nKzvu9PyrUyI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, James Morse , Marc Zyngier , Catalin Marinas , Andre Przywara Subject: [PATCH 5.8 08/17] KVM: arm64: Add kvm_extable for vaxorcism code Date: Fri, 4 Sep 2020 15:30:07 +0200 Message-Id: <20200904120258.400721610@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: James Morse commit e9ee186bb735bfc17fa81dbc9aebf268aee5b41e upstream. KVM has a one instruction window where it will allow an SError exception to be consumed by the hypervisor without treating it as a hypervisor bug. This is used to consume asynchronous external abort that were caused by the guest. As we are about to add another location that survives unexpected exceptions, generalise this code to make it behave like the host's extable. KVM's version has to be mapped to EL2 to be accessible on nVHE systems. The SError vaxorcism code is a one instruction window, so has two entries in the extable. Because the KVM code is copied for VHE and nVHE, we end up with four entries, half of which correspond with code that isn't mapped. Signed-off-by: James Morse Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Andre Przywara Signed-off-by: Greg Kroah-Hartman --- arch/arm64/include/asm/kvm_asm.h | 15 +++++++++++ arch/arm64/kernel/vmlinux.lds.S | 8 ++++++ arch/arm64/kvm/hyp/entry.S | 15 ++++++----- arch/arm64/kvm/hyp/hyp-entry.S | 51 +++++++++++++++++++++++---------------- arch/arm64/kvm/hyp/switch.c | 31 +++++++++++++++++++++++ 5 files changed, 94 insertions(+), 26 deletions(-) --- a/arch/arm64/include/asm/kvm_asm.h +++ b/arch/arm64/include/asm/kvm_asm.h @@ -146,6 +146,21 @@ extern char __smccc_workaround_1_smc[__S kern_hyp_va \vcpu .endm +/* + * KVM extable for unexpected exceptions. + * In the same format _asm_extable, but output to a different section so that + * it can be mapped to EL2. The KVM version is not sorted. The caller must + * ensure: + * x18 has the hypervisor value to allow any Shadow-Call-Stack instrumented + * code to write to it, and that SPSR_EL2 and ELR_EL2 are restored by the fixup. + */ +.macro _kvm_extable, from, to + .pushsection __kvm_ex_table, "a" + .align 3 + .long (\from - .), (\to - .) + .popsection +.endm + #endif #endif /* __ARM_KVM_ASM_H__ */ --- a/arch/arm64/kernel/vmlinux.lds.S +++ b/arch/arm64/kernel/vmlinux.lds.S @@ -21,6 +21,13 @@ ENTRY(_text) jiffies = jiffies_64; + +#define HYPERVISOR_EXTABLE \ + . = ALIGN(SZ_8); \ + __start___kvm_ex_table = .; \ + *(__kvm_ex_table) \ + __stop___kvm_ex_table = .; + #define HYPERVISOR_TEXT \ /* \ * Align to 4 KB so that \ @@ -36,6 +43,7 @@ jiffies = jiffies_64; __hyp_idmap_text_end = .; \ __hyp_text_start = .; \ *(.hyp.text) \ + HYPERVISOR_EXTABLE \ __hyp_text_end = .; #define IDMAP_TEXT \ --- a/arch/arm64/kvm/hyp/entry.S +++ b/arch/arm64/kvm/hyp/entry.S @@ -198,20 +198,23 @@ alternative_endif // This is our single instruction exception window. A pending // SError is guaranteed to occur at the earliest when we unmask // it, and at the latest just after the ISB. - .global abort_guest_exit_start abort_guest_exit_start: isb - .global abort_guest_exit_end abort_guest_exit_end: msr daifset, #4 // Mask aborts + ret - // If the exception took place, restore the EL1 exception - // context so that we can report some information. - // Merge the exception code with the SError pending bit. - tbz x0, #ARM_EXIT_WITH_SERROR_BIT, 1f + _kvm_extable abort_guest_exit_start, 9997f + _kvm_extable abort_guest_exit_end, 9997f +9997: + msr daifset, #4 // Mask aborts + mov x0, #(1 << ARM_EXIT_WITH_SERROR_BIT) + + // restore the EL1 exception context so that we can report some + // information. Merge the exception code with the SError pending bit. msr elr_el2, x2 msr esr_el2, x3 msr spsr_el2, x4 --- a/arch/arm64/kvm/hyp/hyp-entry.S +++ b/arch/arm64/kvm/hyp/hyp-entry.S @@ -15,6 +15,30 @@ #include #include +.macro save_caller_saved_regs_vect + /* x0 and x1 were saved in the vector entry */ + stp x2, x3, [sp, #-16]! + stp x4, x5, [sp, #-16]! + stp x6, x7, [sp, #-16]! + stp x8, x9, [sp, #-16]! + stp x10, x11, [sp, #-16]! + stp x12, x13, [sp, #-16]! + stp x14, x15, [sp, #-16]! + stp x16, x17, [sp, #-16]! +.endm + +.macro restore_caller_saved_regs_vect + ldp x16, x17, [sp], #16 + ldp x14, x15, [sp], #16 + ldp x12, x13, [sp], #16 + ldp x10, x11, [sp], #16 + ldp x8, x9, [sp], #16 + ldp x6, x7, [sp], #16 + ldp x4, x5, [sp], #16 + ldp x2, x3, [sp], #16 + ldp x0, x1, [sp], #16 +.endm + .text .pushsection .hyp.text, "ax" @@ -156,27 +180,14 @@ el2_sync: el2_error: - ldp x0, x1, [sp], #16 + save_caller_saved_regs_vect + stp x29, x30, [sp, #-16]! + + bl kvm_unexpected_el2_exception + + ldp x29, x30, [sp], #16 + restore_caller_saved_regs_vect - /* - * Only two possibilities: - * 1) Either we come from the exit path, having just unmasked - * PSTATE.A: change the return code to an EL2 fault, and - * carry on, as we're already in a sane state to handle it. - * 2) Or we come from anywhere else, and that's a bug: we panic. - * - * For (1), x0 contains the original return code and x1 doesn't - * contain anything meaningful at that stage. We can reuse them - * as temp registers. - * For (2), who cares? - */ - mrs x0, elr_el2 - adr x1, abort_guest_exit_start - cmp x0, x1 - adr x1, abort_guest_exit_end - ccmp x0, x1, #4, ne - b.ne __hyp_panic - mov x0, #(1 << ARM_EXIT_WITH_SERROR_BIT) eret sb --- a/arch/arm64/kvm/hyp/switch.c +++ b/arch/arm64/kvm/hyp/switch.c @@ -14,6 +14,7 @@ #include #include +#include #include #include #include @@ -24,6 +25,9 @@ #include #include +extern struct exception_table_entry __start___kvm_ex_table; +extern struct exception_table_entry __stop___kvm_ex_table; + /* Check whether the FP regs were dirtied while in the host-side run loop: */ static bool __hyp_text update_fp_enabled(struct kvm_vcpu *vcpu) { @@ -934,3 +938,30 @@ void __hyp_text __noreturn hyp_panic(str unreachable(); } + +asmlinkage void __hyp_text kvm_unexpected_el2_exception(void) +{ + unsigned long addr, fixup; + struct kvm_cpu_context *host_ctxt; + struct exception_table_entry *entry, *end; + unsigned long elr_el2 = read_sysreg(elr_el2); + + entry = hyp_symbol_addr(__start___kvm_ex_table); + end = hyp_symbol_addr(__stop___kvm_ex_table); + host_ctxt = &__hyp_this_cpu_ptr(kvm_host_data)->host_ctxt; + + while (entry < end) { + addr = (unsigned long)&entry->insn + entry->insn; + fixup = (unsigned long)&entry->fixup + entry->fixup; + + if (addr != elr_el2) { + entry++; + continue; + } + + write_sysreg(fixup, elr_el2); + return; + } + + hyp_panic(host_ctxt); +} From patchwork Fri Sep 4 13:30:08 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310122 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E322C43461 for ; Fri, 4 Sep 2020 14:25:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1C87D2078E for ; Fri, 4 Sep 2020 14:25:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229547; bh=6KTkxpgzQHDR1wFViFDOTk7r1crsAnUhrlDc4NUnbmE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=bbQASnoUxA2nrLaTo9jJwokkSOVXy7vEa9DcL6Vn+Z+OsKTuvaBF21i8MA6/OcOnv m5p2UwZj78lAzQf0DI6k2wU1fthLBOTWsz+bo/quP/RarxCXrgsLYKNyrIaOuVfGcg EqHxN/jhFwjQi9lN4Vwcgf4VW/bRWusj48gq+pW4= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730521AbgIDOVr (ORCPT ); Fri, 4 Sep 2020 10:21:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:38338 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730476AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 3432B2166E; Fri, 4 Sep 2020 13:31:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226269; bh=6KTkxpgzQHDR1wFViFDOTk7r1crsAnUhrlDc4NUnbmE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zPn+u4B9ePNx0o2SSf9VKW00FGM4iak4fYTwhWyQlISiP00VOZwKADM5bGqOFNlnv QjD25xugUtaQMoycDoSqkz8TZ1Axjytkmfgrt+ZK/SVpqPGmZqHjaAlGgrFu7Nk6WP Xyofay/lkks4ouVV9Wvc1ftKf2w3Db13SmodVKtU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, James Morse , Marc Zyngier , Catalin Marinas , Andre Przywara Subject: [PATCH 5.8 09/17] KVM: arm64: Survive synchronous exceptions caused by AT instructions Date: Fri, 4 Sep 2020 15:30:08 +0200 Message-Id: <20200904120258.449102679@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: James Morse commit 88a84ccccb3966bcc3f309cdb76092a9892c0260 upstream. KVM doesn't expect any synchronous exceptions when executing, any such exception leads to a panic(). AT instructions access the guest page tables, and can cause a synchronous external abort to be taken. The arm-arm is unclear on what should happen if the guest has configured the hardware update of the access-flag, and a memory type in TCR_EL1 that does not support atomic operations. B2.2.6 "Possible implementation restrictions on using atomic instructions" from DDI0487F.a lists synchronous external abort as a possible behaviour of atomic instructions that target memory that isn't writeback cacheable, but the page table walker may behave differently. Make KVM robust to synchronous exceptions caused by AT instructions. Add a get_user() style helper for AT instructions that returns -EFAULT if an exception was generated. While KVM's version of the exception table mixes synchronous and asynchronous exceptions, only one of these can occur at each location. Re-enter the guest when the AT instructions take an exception on the assumption the guest will take the same exception. This isn't guaranteed to make forward progress, as the AT instructions may always walk the page tables, but guest execution may use the translation cached in the TLB. This isn't a problem, as since commit 5dcd0fdbb492 ("KVM: arm64: Defer guest entry when an asynchronous exception is pending"), KVM will return to the host to process IRQs allowing the rest of the system to keep running. Cc: stable@vger.kernel.org # Reviewed-by: Marc Zyngier Signed-off-by: Catalin Marinas Signed-off-by: Andre Przywara Signed-off-by: Greg Kroah-Hartman --- arch/arm64/include/asm/kvm_asm.h | 28 ++++++++++++++++++++++++++++ arch/arm64/kvm/hyp/hyp-entry.S | 14 ++++++++++---- arch/arm64/kvm/hyp/switch.c | 8 ++++---- 3 files changed, 42 insertions(+), 8 deletions(-) --- a/arch/arm64/include/asm/kvm_asm.h +++ b/arch/arm64/include/asm/kvm_asm.h @@ -121,6 +121,34 @@ extern char __smccc_workaround_1_smc[__S *__hyp_this_cpu_ptr(sym); \ }) +#define __KVM_EXTABLE(from, to) \ + " .pushsection __kvm_ex_table, \"a\"\n" \ + " .align 3\n" \ + " .long (" #from " - .), (" #to " - .)\n" \ + " .popsection\n" + + +#define __kvm_at(at_op, addr) \ +( { \ + int __kvm_at_err = 0; \ + u64 spsr, elr; \ + asm volatile( \ + " mrs %1, spsr_el2\n" \ + " mrs %2, elr_el2\n" \ + "1: at "at_op", %3\n" \ + " isb\n" \ + " b 9f\n" \ + "2: msr spsr_el2, %1\n" \ + " msr elr_el2, %2\n" \ + " mov %w0, %4\n" \ + "9:\n" \ + __KVM_EXTABLE(1b, 2b) \ + : "+r" (__kvm_at_err), "=&r" (spsr), "=&r" (elr) \ + : "r" (addr), "i" (-EFAULT)); \ + __kvm_at_err; \ +} ) + + #else /* __ASSEMBLY__ */ .macro hyp_adr_this_cpu reg, sym, tmp --- a/arch/arm64/kvm/hyp/hyp-entry.S +++ b/arch/arm64/kvm/hyp/hyp-entry.S @@ -166,13 +166,19 @@ el1_error: b __guest_exit el2_sync: - /* Check for illegal exception return, otherwise panic */ + /* Check for illegal exception return */ mrs x0, spsr_el2 + tbnz x0, #20, 1f - /* if this was something else, then panic! */ - tst x0, #PSR_IL_BIT - b.eq __hyp_panic + save_caller_saved_regs_vect + stp x29, x30, [sp, #-16]! + bl kvm_unexpected_el2_exception + ldp x29, x30, [sp], #16 + restore_caller_saved_regs_vect + eret + +1: /* Let's attempt a recovery from the illegal exception return */ get_vcpu_ptr x1, x0 mov x0, #ARM_EXCEPTION_IL --- a/arch/arm64/kvm/hyp/switch.c +++ b/arch/arm64/kvm/hyp/switch.c @@ -303,10 +303,10 @@ static bool __hyp_text __translate_far_t * saved the guest context yet, and we may return early... */ par = read_sysreg(par_el1); - asm volatile("at s1e1r, %0" : : "r" (far)); - isb(); - - tmp = read_sysreg(par_el1); + if (!__kvm_at("s1e1r", far)) + tmp = read_sysreg(par_el1); + else + tmp = SYS_PAR_EL1_F; /* back to the guest */ write_sysreg(par, par_el1); if (unlikely(tmp & SYS_PAR_EL1_F)) From patchwork Fri Sep 4 13:30:09 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264387 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52CB0C433E2 for ; Fri, 4 Sep 2020 13:34:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2783220797 for ; Fri, 4 Sep 2020 13:34:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226487; bh=m9pIERxvWHUgsDqBqgVJI3JMc/1+doudOyGmLox0dOo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=xGAOz9+tTpJvgVh5ERaAJ5lCmzo+yD8CoNSurNAch9RlaUllpcNhBPPPW0rMN76go ygT2RmJMg7hN1xijaFy4luHPRqa3arxuKZfiwPyX/PO7G5Lnq6NLYbcSxbad1/LSma ymaWwoDuEtjKeFRTsLRc9/UdcXdcw8RP/ZTPY31A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730493AbgIDNek (ORCPT ); Fri, 4 Sep 2020 09:34:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:38076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730463AbgIDNeW (ORCPT ); Fri, 4 Sep 2020 09:34:22 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E1E1E2083B; Fri, 4 Sep 2020 13:30:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226244; bh=m9pIERxvWHUgsDqBqgVJI3JMc/1+doudOyGmLox0dOo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dKWQjXs9be77p3NDUujSJyKRekCSS/uFtn8EswFxfMo9g0GzidLNi4ymgOE/AirrO 6CGGTqjgaU0mAfsACQc1hGLev2JhB2MlBAgU7NH4QR+BpWyM2zptYbzc60ROUbUqeF sCtpDtUF0HGAJQikubhKeIgBgrXVjKgaeX0UiCXU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter , Sowjanya Komatineni , Ulf Hansson Subject: [PATCH 5.8 10/17] dt-bindings: mmc: tegra: Add tmclk for Tegra210 and later Date: Fri, 4 Sep 2020 15:30:09 +0200 Message-Id: <20200904120258.497389751@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sowjanya Komatineni commit f7f86e8ac0ad7cd6792a80137f5a550924966916 upstream. commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Tegra210 and later uses separate SDMMC_LEGACY_TM clock for data timeout. So, this patch adds "tmclk" to Tegra sdhci clock property in the device tree binding. Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Cc: stable # 5.4 Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-4-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt | 32 +++++++++- 1 file changed, 29 insertions(+), 3 deletions(-) --- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt +++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt @@ -15,8 +15,15 @@ Required properties: - "nvidia,tegra210-sdhci": for Tegra210 - "nvidia,tegra186-sdhci": for Tegra186 - "nvidia,tegra194-sdhci": for Tegra194 -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. +- clocks: For Tegra210, Tegra186 and Tegra194 must contain two entries. + One for the module clock and one for the timeout clock. + For all other Tegra devices, must contain a single entry for + the module clock. See ../clocks/clock-bindings.txt for details. +- clock-names: For Tegra210, Tegra186 and Tegra194 must contain the + strings 'sdhci' and 'tmclk' to represent the module and + the timeout clocks, respectively. + For all other Tegra devices must contain the string 'sdhci' + to represent the module clock. - resets : Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names : Must include the following entries: @@ -99,7 +106,7 @@ Optional properties for Tegra210, Tegra1 Example: sdhci@700b0000 { - compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci"; + compatible = "nvidia,tegra124-sdhci"; reg = <0x0 0x700b0000 0x0 0x200>; interrupts = ; clocks = <&tegra_car TEGRA210_CLK_SDMMC1>; @@ -107,6 +114,25 @@ sdhci@700b0000 { resets = <&tegra_car 14>; reset-names = "sdhci"; pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; + pinctrl-0 = <&sdmmc1_3v3>; + pinctrl-1 = <&sdmmc1_1v8>; + nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>; + nvidia,pad-autocal-pull-down-offset-3v3 = <0x7d>; + nvidia,pad-autocal-pull-up-offset-1v8 = <0x7b>; + nvidia,pad-autocal-pull-down-offset-1v8 = <0x7b>; + status = "disabled"; +}; + +sdhci@700b0000 { + compatible = "nvidia,tegra210-sdhci"; + reg = <0x0 0x700b0000 0x0 0x200>; + interrupts = ; + clocks = <&tegra_car TEGRA210_CLK_SDMMC1>, + <&tegra_car TEGRA210_CLK_SDMMC_LEGACY>; + clock-names = "sdhci", "tmclk"; + resets = <&tegra_car 14>; + reset-names = "sdhci"; + pinctrl-names = "sdmmc-3v3", "sdmmc-1v8"; pinctrl-0 = <&sdmmc1_3v3>; pinctrl-1 = <&sdmmc1_1v8>; nvidia,pad-autocal-pull-up-offset-3v3 = <0x00>; From patchwork Fri Sep 4 13:30:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264376 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F362DC43461 for ; Fri, 4 Sep 2020 14:26:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CB2D2206B8 for ; Fri, 4 Sep 2020 14:26:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229579; bh=OyJPEEMtX0OZO8ZGe/PWQVztakgqVmr0EUsWqA/IVP8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=YCGwPoiO4zqbrUeOwK11t3k3DztKcirqWYoPvYGggz1NlTEAa24xcNvUuPqVShaE8 ZLOVqWtNFlG6BLTGoJWRqYMaxgdPGO5yPkuBkzwVZTMk7tBYndfyVQBZrROgic6M/T y2ONDxKu6t6sBz6jYvfeeYLm0fRDM1Qb7NLsISVc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730759AbgIDO0R (ORCPT ); Fri, 4 Sep 2020 10:26:17 -0400 Received: from mail.kernel.org ([198.145.29.99]:37298 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730460AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8FBAE20E65; Fri, 4 Sep 2020 13:30:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226248; bh=OyJPEEMtX0OZO8ZGe/PWQVztakgqVmr0EUsWqA/IVP8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=U0mX0EnUxL4GumD+/nMnqWtduGR4TTth3msZQoO5LsQ800Y84TZOvDfWJNJwk3KGe jT+4I8S2pU0rAsrxt6myVXi6Elz+A4Woym2U5HS1IZYAl9MobRA14Qxl2L3r7E9BFK OqZPmTGa3GeJWaaqXpc6XUVbQpDTkoAR/7WwB5Kk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter , Sowjanya Komatineni , Ulf Hansson Subject: [PATCH 5.8 11/17] arm64: tegra: Add missing timeout clock to Tegra194 SDMMC nodes Date: Fri, 4 Sep 2020 15:30:10 +0200 Message-Id: <20200904120258.543409905@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sowjanya Komatineni commit c956c0cd4f6f4aac4f095621b1c4e1c5ee1df877 upstream. commit 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Tegra194 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra194 SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 5425fb15d8ee ("arm64: tegra: Add Tegra194 chip device tree") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-7-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman --- arch/arm64/boot/dts/nvidia/tegra194.dtsi | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi @@ -453,8 +453,9 @@ compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci"; reg = <0x03400000 0x10000>; interrupts = ; - clocks = <&bpmp TEGRA194_CLK_SDMMC1>; - clock-names = "sdhci"; + clocks = <&bpmp TEGRA194_CLK_SDMMC1>, + <&bpmp TEGRA194_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; resets = <&bpmp TEGRA194_RESET_SDMMC1>; reset-names = "sdhci"; nvidia,pad-autocal-pull-up-offset-3v3-timeout = @@ -475,8 +476,9 @@ compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci"; reg = <0x03440000 0x10000>; interrupts = ; - clocks = <&bpmp TEGRA194_CLK_SDMMC3>; - clock-names = "sdhci"; + clocks = <&bpmp TEGRA194_CLK_SDMMC3>, + <&bpmp TEGRA194_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; resets = <&bpmp TEGRA194_RESET_SDMMC3>; reset-names = "sdhci"; nvidia,pad-autocal-pull-up-offset-1v8 = <0x00>; @@ -498,8 +500,9 @@ compatible = "nvidia,tegra194-sdhci", "nvidia,tegra186-sdhci"; reg = <0x03460000 0x10000>; interrupts = ; - clocks = <&bpmp TEGRA194_CLK_SDMMC4>; - clock-names = "sdhci"; + clocks = <&bpmp TEGRA194_CLK_SDMMC4>, + <&bpmp TEGRA194_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; assigned-clocks = <&bpmp TEGRA194_CLK_SDMMC4>, <&bpmp TEGRA194_CLK_PLLC4>; assigned-clock-parents = From patchwork Fri Sep 4 13:30:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310120 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6963C43461 for ; Fri, 4 Sep 2020 14:26:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A6640206B8 for ; Fri, 4 Sep 2020 14:26:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229569; bh=/yaMY8IeoBXsJH1ZIKTurEUCGIG5SXESRnFSHWEqhFs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=zgx9mrNYwIytLwBIN8PLY2AbqY8ryAy2YV+RCEKZ1wT+XiuijTFwJlcEo01fE1QSf 4vN/AEEmjIGrfgGJScLtRGDsXZEhB+KvCc0SB50d2VuxVN0bz/8zQOVIEi8culiADW hbigBXcgMT++eGjkoflDo5dS5Xxf7aNpU1bd9aSc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730547AbgIDOZ6 (ORCPT ); Fri, 4 Sep 2020 10:25:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:37288 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730441AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E38A320797; Fri, 4 Sep 2020 13:30:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226250; bh=/yaMY8IeoBXsJH1ZIKTurEUCGIG5SXESRnFSHWEqhFs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CzawyVW55SxMJVLP8ZJ0SdChd64h+y1hHypYEO8g/lmOn98uDU7DPKxfdNvTdeAMt tFLdMkFidEHuQNw98s37h8CuDsE6Jopk9NpV1ZFmiTMMIesUg/wL71goKq0q3iiMYd skaMQJkSH5hI4054WQrMCm83TcmYzQibbemylhMY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter , Sowjanya Komatineni , Ulf Hansson Subject: [PATCH 5.8 12/17] arm64: tegra: Add missing timeout clock to Tegra186 SDMMC nodes Date: Fri, 4 Sep 2020 15:30:11 +0200 Message-Id: <20200904120258.593742953@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sowjanya Komatineni commit baba217d2c4446b6eef309d81d8776cb5c68cb55 upstream. commit 39cb62cb8973 ("arm64: tegra: Add Tegra186 support") Tegra186 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra186 SDMMC advertises 12Mhz as timeout clock frequency in host capability register and uses it by default. So, this clock should be kept enabled by the SDMMC driver. Fixes: 39cb62cb8973 ("arm64: tegra: Add Tegra186 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-6-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman --- arch/arm64/boot/dts/nvidia/tegra186.dtsi | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi @@ -331,8 +331,9 @@ compatible = "nvidia,tegra186-sdhci"; reg = <0x0 0x03400000 0x0 0x10000>; interrupts = ; - clocks = <&bpmp TEGRA186_CLK_SDMMC1>; - clock-names = "sdhci"; + clocks = <&bpmp TEGRA186_CLK_SDMMC1>, + <&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; resets = <&bpmp TEGRA186_RESET_SDMMC1>; reset-names = "sdhci"; iommus = <&smmu TEGRA186_SID_SDMMC1>; @@ -357,8 +358,9 @@ compatible = "nvidia,tegra186-sdhci"; reg = <0x0 0x03420000 0x0 0x10000>; interrupts = ; - clocks = <&bpmp TEGRA186_CLK_SDMMC2>; - clock-names = "sdhci"; + clocks = <&bpmp TEGRA186_CLK_SDMMC2>, + <&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; resets = <&bpmp TEGRA186_RESET_SDMMC2>; reset-names = "sdhci"; iommus = <&smmu TEGRA186_SID_SDMMC2>; @@ -378,8 +380,9 @@ compatible = "nvidia,tegra186-sdhci"; reg = <0x0 0x03440000 0x0 0x10000>; interrupts = ; - clocks = <&bpmp TEGRA186_CLK_SDMMC3>; - clock-names = "sdhci"; + clocks = <&bpmp TEGRA186_CLK_SDMMC3>, + <&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; resets = <&bpmp TEGRA186_RESET_SDMMC3>; reset-names = "sdhci"; iommus = <&smmu TEGRA186_SID_SDMMC3>; @@ -401,8 +404,9 @@ compatible = "nvidia,tegra186-sdhci"; reg = <0x0 0x03460000 0x0 0x10000>; interrupts = ; - clocks = <&bpmp TEGRA186_CLK_SDMMC4>; - clock-names = "sdhci"; + clocks = <&bpmp TEGRA186_CLK_SDMMC4>, + <&bpmp TEGRA186_CLK_SDMMC_LEGACY_TM>; + clock-names = "sdhci", "tmclk"; assigned-clocks = <&bpmp TEGRA186_CLK_SDMMC4>, <&bpmp TEGRA186_CLK_PLLC4_VCO>; assigned-clock-parents = <&bpmp TEGRA186_CLK_PLLC4_VCO>; From patchwork Fri Sep 4 13:30:12 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310130 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7C59CC433E2 for ; Fri, 4 Sep 2020 13:40:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 534E1205F4 for ; Fri, 4 Sep 2020 13:40:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226852; bh=rRl7szRYiIqy5kj3LwgtNrpjQmW5mOVLLWGAuMf1VLk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=TjggrNFqTDuN1imsQRupB4leSaSyFNCbxRWy0oupLuCuUUP5ShA/TASYWW84M5xUd lFZngrje3Nx+8F6QRn8xrn16/UpwqDTQeXPsSJ745r08cKcJ9HN+YGZvPeaY9Yg2wK 8IscCLUgSoQvGYj8CS8HKgEn/XHAgeG5CYWrnPH8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730451AbgIDNkr (ORCPT ); Fri, 4 Sep 2020 09:40:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:38076 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730490AbgIDNe0 (ORCPT ); Fri, 4 Sep 2020 09:34:26 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 487B321741; Fri, 4 Sep 2020 13:31:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226281; bh=rRl7szRYiIqy5kj3LwgtNrpjQmW5mOVLLWGAuMf1VLk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zGpI25qEg8haGzg8p9ql8u3sJvkk0M+dgqDUOetuSRmyElkGMAOik9zuC+ui/yGY6 bY3yA56mVth/v13sKp3C8yXfycKsI9wivxGuoBZKeM0pCBAc0vjhgd6ikJgUmQshAV qGTCVF1pIn6+d/79e24wxOwnKAbb7utTqwyyhv1w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter , Sowjanya Komatineni , Ulf Hansson Subject: [PATCH 5.8 13/17] arm64: tegra: Add missing timeout clock to Tegra210 SDMMC Date: Fri, 4 Sep 2020 15:30:12 +0200 Message-Id: <20200904120258.642434450@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sowjanya Komatineni commit 679f71fa0db2d777f39c7a5af7f7c0689fc713fa upstream. commit 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Tegra210 uses separate SDMMC_LEGACY_TM clock for data timeout and this clock is not enabled currently which is not recommended. Tegra SDMMC advertises 12Mhz as timeout clock frequency in host capability register. So, this clock should be kept enabled by SDMMC driver. Fixes: 742af7e7a0a1 ("arm64: tegra: Add Tegra210 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-5-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman --- arch/arm64/boot/dts/nvidia/tegra210.dtsi | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi @@ -1180,8 +1180,9 @@ compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci"; reg = <0x0 0x700b0000 0x0 0x200>; interrupts = ; - clocks = <&tegra_car TEGRA210_CLK_SDMMC1>; - clock-names = "sdhci"; + clocks = <&tegra_car TEGRA210_CLK_SDMMC1>, + <&tegra_car TEGRA210_CLK_SDMMC_LEGACY>; + clock-names = "sdhci", "tmclk"; resets = <&tegra_car 14>; reset-names = "sdhci"; pinctrl-names = "sdmmc-3v3", "sdmmc-1v8", @@ -1208,8 +1209,9 @@ compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci"; reg = <0x0 0x700b0200 0x0 0x200>; interrupts = ; - clocks = <&tegra_car TEGRA210_CLK_SDMMC2>; - clock-names = "sdhci"; + clocks = <&tegra_car TEGRA210_CLK_SDMMC2>, + <&tegra_car TEGRA210_CLK_SDMMC_LEGACY>; + clock-names = "sdhci", "tmclk"; resets = <&tegra_car 9>; reset-names = "sdhci"; pinctrl-names = "sdmmc-1v8-drv"; @@ -1225,8 +1227,9 @@ compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci"; reg = <0x0 0x700b0400 0x0 0x200>; interrupts = ; - clocks = <&tegra_car TEGRA210_CLK_SDMMC3>; - clock-names = "sdhci"; + clocks = <&tegra_car TEGRA210_CLK_SDMMC3>, + <&tegra_car TEGRA210_CLK_SDMMC_LEGACY>; + clock-names = "sdhci", "tmclk"; resets = <&tegra_car 69>; reset-names = "sdhci"; pinctrl-names = "sdmmc-3v3", "sdmmc-1v8", @@ -1248,8 +1251,9 @@ compatible = "nvidia,tegra210-sdhci", "nvidia,tegra124-sdhci"; reg = <0x0 0x700b0600 0x0 0x200>; interrupts = ; - clocks = <&tegra_car TEGRA210_CLK_SDMMC4>; - clock-names = "sdhci"; + clocks = <&tegra_car TEGRA210_CLK_SDMMC4>, + <&tegra_car TEGRA210_CLK_SDMMC_LEGACY>; + clock-names = "sdhci", "tmclk"; resets = <&tegra_car 15>; reset-names = "sdhci"; pinctrl-names = "sdmmc-3v3-drv", "sdmmc-1v8-drv"; From patchwork Fri Sep 4 13:30:13 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310119 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B757EC433E2 for ; Fri, 4 Sep 2020 14:26:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8CF6B20709 for ; Fri, 4 Sep 2020 14:26:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229578; bh=Tr4z+NR1SRMOzY+LWC5T7njKmV51Ey9kJebg7MBtyho=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=wdzyvMI67eAhpaIvbqxMmlyvqR0lMpIOub4SDj8NfvYgUKIm3C6UhiALltMaq8vgr gvkHatKY9bTUBpHuOKxxPAy64PF62k76pqqyW2QIZFKXrgQGr2DjWhbc6m82rWF+kT iVzzEUlJ4weYhqVIY+HCAOIGViXsORwI2QIAII3g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730726AbgIDO0Q (ORCPT ); Fri, 4 Sep 2020 10:26:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:36826 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730388AbgIDNeX (ORCPT ); Fri, 4 Sep 2020 09:34:23 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8916C216C4; Fri, 4 Sep 2020 13:31:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226272; bh=Tr4z+NR1SRMOzY+LWC5T7njKmV51Ey9kJebg7MBtyho=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A/cqYwoylcvvLKW9dpAGMqEr+nJVeM4xw6upTWqBvLJh9NW7nNVRltEPNpn+bnFHO MUxM/qS/kgiO/VH4CUvY2P/Jx7ENGC1uc5HtwZzdcMFYVqppDm+fOspcVnkmlszXif fwXPuSOCmo3gJyUqNVCayPeYkfI/e8PaYq5+vnjw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter , Adrian Hunter , Sowjanya Komatineni , Ulf Hansson Subject: [PATCH 5.8 14/17] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra210 Date: Fri, 4 Sep 2020 15:30:13 +0200 Message-Id: <20200904120258.690017339@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sowjanya Komatineni commit e33588adcaa925c18ee2ea253161fb0317fa2329 upstream. commit b5a84ecf025a ("mmc: tegra: Add Tegra210 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra210 from the beginning of Tegra210 support in the driver. Tegra210 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra210. Fixes: b5a84ecf025a ("mmc: tegra: Add Tegra210 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Acked-by: Adrian Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-2-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman --- drivers/mmc/host/sdhci-tegra.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/mmc/host/sdhci-tegra.c +++ b/drivers/mmc/host/sdhci-tegra.c @@ -1409,7 +1409,6 @@ static const struct sdhci_ops tegra210_s static const struct sdhci_pltfm_data sdhci_tegra210_pdata = { .quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL | - SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK | SDHCI_QUIRK_SINGLE_POWER_WRITE | SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | From patchwork Fri Sep 4 13:30:14 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 310118 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EF78C433E2 for ; Fri, 4 Sep 2020 14:27:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2997F206B7 for ; Fri, 4 Sep 2020 14:27:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229642; bh=R7kHP+c8UJw7wZgBJfS8+JpKz9yyFp5+l1ul23dYSSM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Yn0TIefc0Rab9DK0Pua7zxEODr44LIaxjwMw23F7XynxwM8vY8zSqgZnHQK9uXPjt 79Kbw2wCERM7PfwehR9PF9F8ibJdbg3EFr+3h8KltN8/WWl7LUv6k/4KZj9zsd4x6V pjEOs1m1OgEwurZdtEbi1acJMZQGdPL5C2efLjYM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730770AbgIDO1N (ORCPT ); Fri, 4 Sep 2020 10:27:13 -0400 Received: from mail.kernel.org ([198.145.29.99]:38384 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730481AbgIDNeW (ORCPT ); Fri, 4 Sep 2020 09:34:22 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 20E49214D8; Fri, 4 Sep 2020 13:31:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226274; bh=R7kHP+c8UJw7wZgBJfS8+JpKz9yyFp5+l1ul23dYSSM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OLfKZsX5tKb9dU4fXMSAr7LsF/XpcewLv6qagbrru1AjTZdHiLhqHh15v2Wc7bIO0 rObVWiWHjDjdC8pqk2EmIWyjT9AhFoEs9fDY3I5JLvmX2yB5YZ0Imr+urN3TcO0gy4 Yh5qJNpXnJEYku3v6fEohV1jpBao5YkFF26aIizU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter , Adrian Hunter , Sowjanya Komatineni , Ulf Hansson Subject: [PATCH 5.8 15/17] sdhci: tegra: Remove SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK for Tegra186 Date: Fri, 4 Sep 2020 15:30:14 +0200 Message-Id: <20200904120258.738498484@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Sowjanya Komatineni commit 391d89dba8c290859a3e29430d0b9e32c358bb0d upstream. commit 4346b7c7941d ("mmc: tegra: Add Tegra186 support") SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK is set for Tegra186 from the beginning of its support in driver. Tegra186 SDMMC hardware by default uses timeout clock (TMCLK) instead of SDCLK and this quirk should not be set. So, this patch remove this quirk for Tegra186. Fixes: 4346b7c7941d ("mmc: tegra: Add Tegra186 support") Cc: stable # 5.4 Tested-by: Jon Hunter Reviewed-by: Jon Hunter Acked-by: Adrian Hunter Signed-off-by: Sowjanya Komatineni Link: https://lore.kernel.org/r/1598548861-32373-3-git-send-email-skomatineni@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman --- drivers/mmc/host/sdhci-tegra.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/mmc/host/sdhci-tegra.c +++ b/drivers/mmc/host/sdhci-tegra.c @@ -1446,7 +1446,6 @@ static const struct sdhci_ops tegra186_s static const struct sdhci_pltfm_data sdhci_tegra186_pdata = { .quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL | - SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK | SDHCI_QUIRK_SINGLE_POWER_WRITE | SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC | From patchwork Fri Sep 4 13:30:15 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264381 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 236F1C2D0A8 for ; Fri, 4 Sep 2020 14:21:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E0D18206B7 for ; Fri, 4 Sep 2020 14:21:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599229301; bh=eqFhAXZbmT26mUEhpjJJVcnWgVNwi5MXc9wL2qtl/7A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=0crpkosCUqnLFn0iBme3v/JuCQ4PaQ27EzpUGA/d+O3H+QvVS+X1AeGfx0UHGMlw5 JL9d6pHFAZqhH1pgWU6luL/P8dpWeJvqjl1DBIrvpjNoYg8CSBOP34JygMpfcxXinc zuAhJ5FV/2hS0FL0VJlJ3Yxv6gZG3pnn1VzEun+A= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730330AbgIDOVi (ORCPT ); Fri, 4 Sep 2020 10:21:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:38082 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730416AbgIDNeY (ORCPT ); Fri, 4 Sep 2020 09:34:24 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8242021527; Fri, 4 Sep 2020 13:31:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226277; bh=eqFhAXZbmT26mUEhpjJJVcnWgVNwi5MXc9wL2qtl/7A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=atuO0HeADBwnfIbz6dpC3LvviHrTT9mRPB7Udi8uuaj1VGRkGkamYUuTgSoZal605 5IQikB9ow2U8EAb/l1k7BeCKA2rDwuj+KzrHfSvKwFbf/u+eI9LW95GSn7QMXorcMC c8KBU1dNmjc5r98EgZa7+ugTsknYL50LVAIriGKc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Johannes Berg Subject: [PATCH 5.8 16/17] nl80211: fix NL80211_ATTR_HE_6GHZ_CAPABILITY usage Date: Fri, 4 Sep 2020 15:30:15 +0200 Message-Id: <20200904120258.791596514@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Johannes Berg commit fce2ff728f95b8894db14f51c9274dc56c37616f upstream. In nl80211_set_station(), we check NL80211_ATTR_HE_6GHZ_CAPABILITY and then use NL80211_ATTR_HE_CAPABILITY, which is clearly wrong. Fix this to use NL80211_ATTR_HE_6GHZ_CAPABILITY as well. Cc: stable@vger.kernel.org Fixes: 43e64bf301fd ("cfg80211: handle 6 GHz capability of new station") Link: https://lore.kernel.org/r/20200805153516.310cef625955.I0abc04dc8abb2c7c005c88ef8fa2d0e3c9fb95c4@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman --- net/wireless/nl80211.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -6010,7 +6010,7 @@ static int nl80211_set_station(struct sk if (info->attrs[NL80211_ATTR_HE_6GHZ_CAPABILITY]) params.he_6ghz_capa = - nla_data(info->attrs[NL80211_ATTR_HE_CAPABILITY]); + nla_data(info->attrs[NL80211_ATTR_HE_6GHZ_CAPABILITY]); if (info->attrs[NL80211_ATTR_AIRTIME_WEIGHT]) params.airtime_weight = From patchwork Fri Sep 4 13:30:16 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 264386 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9FF80C433E2 for ; Fri, 4 Sep 2020 13:40:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6EE83205F4 for ; Fri, 4 Sep 2020 13:40:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226854; bh=5IwSshPpgozIPZMjbeg/fb3EXkle70zb11w810FYpW0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=COIk4TzVCnKmmvLhrp1+hUkfYI9kDzxsg2juC6W50EwqiwiPk2OkTVQDMZ6O/rQSa SxIDtmZx5p9XWN16XrtGpGUAXWCT15HlF8BnX8kFYBScix2R456rNCJ6Sv/7m0HXDQ ysH4gCvPnGIRunDAxBtL6FBOu8YwOfP0L/fKUONE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730474AbgIDNku (ORCPT ); Fri, 4 Sep 2020 09:40:50 -0400 Received: from mail.kernel.org ([198.145.29.99]:38488 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730488AbgIDNeY (ORCPT ); Fri, 4 Sep 2020 09:34:24 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DAB5E21734; Fri, 4 Sep 2020 13:31:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599226279; bh=5IwSshPpgozIPZMjbeg/fb3EXkle70zb11w810FYpW0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DmuO6/Gm/vXZr09yyWeEN91h92YYLGW1ID6+xR9Mli84Vz9IvyUIC1qYIlrtqn8l/ t7zmuoa+Tx4jtMyhLxRK4fGkrWV6xIO40mydLCGPXZHoz7UT4U0rWTfLfxEdaTHh+H 0Md22jElYz9Ui7+PL1OAYAtIDThCmN6fGM1ZeFRE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, JiangYu , Daniel Meyerholt , Mike Christie , Bodo Stroesser , "Martin K. Petersen" Subject: [PATCH 5.8 17/17] scsi: target: tcmu: Optimize use of flush_dcache_page Date: Fri, 4 Sep 2020 15:30:16 +0200 Message-Id: <20200904120258.840415117@linuxfoundation.org> X-Mailer: git-send-email 2.28.0 In-Reply-To: <20200904120257.983551609@linuxfoundation.org> References: <20200904120257.983551609@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Bodo Stroesser commit 3c58f737231e2c8cbf543a09d84d8c8e80e05e43 upstream. (scatter|gather)_data_area() need to flush dcache after writing data to or before reading data from a page in uio data area. The two routines are able to handle data transfer to/from such a page in fragments and flush the cache after each fragment was copied by calling the wrapper tcmu_flush_dcache_range(). That means: 1) flush_dcache_page() can be called multiple times for the same page. 2) Calling flush_dcache_page() indirectly using the wrapper does not make sense, because each call of the wrapper is for one single page only and the calling routine already has the correct page pointer. Change (scatter|gather)_data_area() such that, instead of calling tcmu_flush_dcache_range() before/after each memcpy, it now calls flush_dcache_page() before unmapping a page (when writing is complete for that page) or after mapping a page (when starting to read the page). After this change only calls to tcmu_flush_dcache_range() for addresses in vmalloc'ed command ring are left over. The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-2-bstroesser@ts.fujitsu.com Tested-by: JiangYu Tested-by: Daniel Meyerholt Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman --- drivers/target/target_core_user.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) --- a/drivers/target/target_core_user.c +++ b/drivers/target/target_core_user.c @@ -676,8 +676,10 @@ static void scatter_data_area(struct tcm from = kmap_atomic(sg_page(sg)) + sg->offset; while (sg_remaining > 0) { if (block_remaining == 0) { - if (to) + if (to) { + flush_dcache_page(page); kunmap_atomic(to); + } block_remaining = DATA_BLOCK_SIZE; dbi = tcmu_cmd_get_dbi(tcmu_cmd); @@ -722,7 +724,6 @@ static void scatter_data_area(struct tcm memcpy(to + offset, from + sg->length - sg_remaining, copy_bytes); - tcmu_flush_dcache_range(to, copy_bytes); } sg_remaining -= copy_bytes; @@ -731,8 +732,10 @@ static void scatter_data_area(struct tcm kunmap_atomic(from - sg->offset); } - if (to) + if (to) { + flush_dcache_page(page); kunmap_atomic(to); + } } static void gather_data_area(struct tcmu_dev *udev, struct tcmu_cmd *cmd, @@ -778,13 +781,13 @@ static void gather_data_area(struct tcmu dbi = tcmu_cmd_get_dbi(cmd); page = tcmu_get_block_page(udev, dbi); from = kmap_atomic(page); + flush_dcache_page(page); } copy_bytes = min_t(size_t, sg_remaining, block_remaining); if (read_len < copy_bytes) copy_bytes = read_len; offset = DATA_BLOCK_SIZE - block_remaining; - tcmu_flush_dcache_range(from, copy_bytes); memcpy(to + sg->length - sg_remaining, from + offset, copy_bytes);