From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37A42C4707A for ; Mon, 21 Mar 2022 14:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348803AbiCUONF (ORCPT ); Mon, 21 Mar 2022 10:13:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348769AbiCUOFd (ORCPT ); Mon, 21 Mar 2022 10:05:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47A2F396A6; Mon, 21 Mar 2022 07:01:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 535ECB816D8; Mon, 21 Mar 2022 14:01:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9DE3C340E8; Mon, 21 Mar 2022 14:01:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871290; bh=AJsb5X7wBUotw3TxRY558vOtFqFD4GfaPxqom60XZWc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DS4g4LBZDsOZU+vwf9fays3CYJY/eFx7Em3qrRBLaog1YX8aGdhm5ktPHabUuHZMo 6LNoCxjSBN/0Ida5KPR494ehEhmAXc/JS4GVNjc6O6MLGJn//wozpOntJvnzImouBK n8oBBIZfZQY4htnZbcKhmhUnn8nFDS/VqYAc1fh4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Masney , Bjorn Andersson , Andrew Halaney , Herbert Xu Subject: [PATCH 5.16 01/37] crypto: qcom-rng - ensure buffer for generate is completely filled Date: Mon, 21 Mar 2022 14:52:43 +0100 Message-Id: <20220321133221.334710093@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Brian Masney commit a680b1832ced3b5fa7c93484248fd221ea0d614b upstream. The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi: kcapi-rng -b 9000000 > OUTFILE The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails. Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function returns success. Let's also have qcom_rng_generate() return the correct value. Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers: $ ent -c qcom-random-before Value Char Occurrences Fraction 0 606748 0.067416 1 33104 0.003678 2 33001 0.003667 ... 253 =EF=BF=BD 32883 0.003654 254 =EF=BF=BD 33035 0.003671 255 =EF=BF=BD 33239 0.003693 Total: 9000000 1.000000 Entropy =3D 7.811590 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 2 percent. Chi square distribution for 9000000 samples is 9329962.81, and randomly would exceed this value less than 0.01 percent of the times. Arithmetic mean value of data bytes is 119.3731 (127.5 =3D random). Monte Carlo value for Pi is 3.197293333 (error 1.77 percent). Serial correlation coefficient is 0.159130 (totally uncorrelated =3D 0.0). Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch: $ ent -c qcom-random-after Value Char Occurrences Fraction 0 35432 0.003937 1 35127 0.003903 2 35424 0.003936 ... 253 =EF=BF=BD 35201 0.003911 254 =EF=BF=BD 34835 0.003871 255 =EF=BF=BD 35368 0.003930 Total: 9000000 1.000000 Entropy =3D 7.999979 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 0 percent. Chi square distribution for 9000000 samples is 258.77, and randomly would exceed this value 42.24 percent of the times. Arithmetic mean value of data bytes is 127.5006 (127.5 =3D random). Monte Carlo value for Pi is 3.141277333 (error 0.01 percent). Serial correlation coefficient is 0.000468 (totally uncorrelated =3D 0.0). This change was tested on a Nexus 5 phone (msm8974 SoC). Signed-off-by: Brian Masney Fixes: ceec5f5b5988 ("crypto: qcom-rng - Add Qcom prng driver") Cc: stable@vger.kernel.org # 4.19+ Reviewed-by: Bjorn Andersson Reviewed-by: Andrew Halaney Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/crypto/qcom-rng.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) --- a/drivers/crypto/qcom-rng.c +++ b/drivers/crypto/qcom-rng.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include @@ -43,16 +44,19 @@ static int qcom_rng_read(struct qcom_rng { unsigned int currsize =3D 0; u32 val; + int ret; =20 /* read random data from hardware */ do { - val =3D readl_relaxed(rng->base + PRNG_STATUS); - if (!(val & PRNG_STATUS_DATA_AVAIL)) - break; + ret =3D readl_poll_timeout(rng->base + PRNG_STATUS, val, + val & PRNG_STATUS_DATA_AVAIL, + 200, 10000); + if (ret) + return ret; =20 val =3D readl_relaxed(rng->base + PRNG_DATA_OUT); if (!val) - break; + return -EINVAL; =20 if ((max - currsize) >=3D WORD_SZ) { memcpy(data, &val, WORD_SZ); @@ -61,11 +65,10 @@ static int qcom_rng_read(struct qcom_rng } else { /* copy only remaining bytes */ memcpy(data, &val, max - currsize); - break; } } while (currsize < max); =20 - return currsize; + return 0; } =20 static int qcom_rng_generate(struct crypto_rng *tfm, @@ -87,7 +90,7 @@ static int qcom_rng_generate(struct cryp mutex_unlock(&rng->lock); clk_disable_unprepare(rng->clk); =20 - return 0; + return ret; } =20 static int qcom_rng_seed(struct crypto_rng *tfm, const u8 *seed, From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 286EAC3525B for ; Mon, 21 Mar 2022 14:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348452AbiCUOND (ORCPT ); Mon, 21 Mar 2022 10:13:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36384 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348776AbiCUOFd (ORCPT ); Mon, 21 Mar 2022 10:05:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31D563B289; Mon, 21 Mar 2022 07:01:38 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1B421B816DA; Mon, 21 Mar 2022 14:01:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3DEB5C340E8; Mon, 21 Mar 2022 14:01:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871292; bh=1NvZWoJdlvPUkVw4Aq0oXH5wnc5kbY4fIKkcrvdEqtM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R24G6Ig89TIkG55sGS3O9D6n/oJvFJWX0y5WLU3XvnouiSrbRF0L3OJNIx5a+kFcn CaeFZ8MSXwTdxgrWBNF1H5AanzXJ3f0EuvZzZsPU1pC+rb3zvJEEtgD/Cn3Qv9q2B4 HwOheZS+0tFpARvYXHCivK9rmI6ZHQ7dlyzYniTw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joseph Qi , Mark Fasheh , Joel Becker , Junxiao Bi , Changwei Ge , Gang He , Jun Piao , Andrew Morton , Linus Torvalds Subject: [PATCH 5.16 02/37] ocfs2: fix crash when initialize filecheck kobj fails Date: Mon, 21 Mar 2022 14:52:44 +0100 Message-Id: <20220321133221.363764517@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Joseph Qi commit 7b0b1332cfdb94489836b67d088a779699f8e47e upstream. Once s_root is set, genric_shutdown_super() will be called if fill_super() fails. That means, we will call ocfs2_dismount_volume() twice in such case, which can lead to kernel crash. Fix this issue by initializing filecheck kobj before setting s_root. Link: https://lkml.kernel.org/r/20220310081930.86305-1-joseph.qi@linux.alib= aba.com Fixes: 5f483c4abb50 ("ocfs2: add kobject for online file check") Signed-off-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- fs/ocfs2/super.c | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) --- a/fs/ocfs2/super.c +++ b/fs/ocfs2/super.c @@ -1106,17 +1106,6 @@ static int ocfs2_fill_super(struct super goto read_super_error; } =20 - root =3D d_make_root(inode); - if (!root) { - status =3D -ENOMEM; - mlog_errno(status); - goto read_super_error; - } - - sb->s_root =3D root; - - ocfs2_complete_mount_recovery(osb); - osb->osb_dev_kset =3D kset_create_and_add(sb->s_id, NULL, &ocfs2_kset->kobj); if (!osb->osb_dev_kset) { @@ -1134,6 +1123,17 @@ static int ocfs2_fill_super(struct super goto read_super_error; } =20 + root =3D d_make_root(inode); + if (!root) { + status =3D -ENOMEM; + mlog_errno(status); + goto read_super_error; + } + + sb->s_root =3D root; + + ocfs2_complete_mount_recovery(osb); + if (ocfs2_mount_local(osb)) snprintf(nodestr, sizeof(nodestr), "local"); else From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5E13CC35278 for ; Mon, 21 Mar 2022 14:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352098AbiCUONP (ORCPT ); Mon, 21 Mar 2022 10:13:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59882 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348817AbiCUOFd (ORCPT ); Mon, 21 Mar 2022 10:05:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FCA93B02A; Mon, 21 Mar 2022 07:01:38 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C4346B816E1; Mon, 21 Mar 2022 14:01:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 032A4C340ED; Mon, 21 Mar 2022 14:01:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871295; bh=u3F5wmbk+6PkM8pt2vrxqech9PMOYixTjf4rRI8WWcM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BU/TADhVZdWXvUJ/8Aps3n/V3Por6ohsJBlFDWyxS31/zx9X7RrP0p9FpVIn+svOh j0mEKFqYy4JKf6APPPlmdW1+NwNmBfKleRMjdPjtU9Khen6BgH8+PrCfwve8QPYxFs wikWMuZ+ZCNd6nGUNAAUXj5FA2wKN8WsZekH9Yxc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guo Ziliang , Zeal Robot , Ran Xiaokai , Jiang Xuexin , Yang Yang , Hugh Dickins , Naoya Horiguchi , Michal Hocko , Minchan Kim , Johannes Weiner , Roger Quadros , Andrew Morton , Linus Torvalds Subject: [PATCH 5.16 03/37] mm: swap: get rid of livelock in swapin readahead Date: Mon, 21 Mar 2022 14:52:45 +0100 Message-Id: <20220321133221.392695021@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Guo Ziliang commit 029c4628b2eb2ca969e9bf979b05dc18d8d5575e upstream. In our testing, a livelock task was found. Through sysrq printing, same stack was found every time, as follows: __swap_duplicate+0x58/0x1a0 swapcache_prepare+0x24/0x30 __read_swap_cache_async+0xac/0x220 read_swap_cache_async+0x58/0xa0 swapin_readahead+0x24c/0x628 do_swap_page+0x374/0x8a0 __handle_mm_fault+0x598/0xd60 handle_mm_fault+0x114/0x200 do_page_fault+0x148/0x4d0 do_translation_fault+0xb0/0xd4 do_mem_abort+0x50/0xb0 The reason for the livelock is that swapcache_prepare() always returns EEXIST, indicating that SWAP_HAS_CACHE has not been cleared, so that it cannot jump out of the loop. We suspect that the task that clears the SWAP_HAS_CACHE flag never gets a chance to run. We try to lower the priority of the task stuck in a livelock so that the task that clears the SWAP_HAS_CACHE flag will run. The results show that the system returns to normal after the priority is lowered. In our testing, multiple real-time tasks are bound to the same core, and the task in the livelock is the highest priority task of the core, so the livelocked task cannot be preempted. Although cond_resched() is used by __read_swap_cache_async, it is an empty function in the preemptive system and cannot achieve the purpose of releasing the CPU. A high-priority task cannot release the CPU unless preempted by a higher-priority task. But when this task is already the highest priority task on this core, other tasks will not be able to be scheduled. So we think we should replace cond_resched() with schedule_timeout_uninterruptible(1), schedule_timeout_interruptible will call set_current_state first to set the task state, so the task will be removed from the running queue, so as to achieve the purpose of giving up the CPU and prevent it from running in kernel mode for too long. (akpm: ugly hack becomes uglier. But it fixes the issue in a backportable-to-stable fashion while we hopefully work on something better) Link: https://lkml.kernel.org/r/20220221111749.1928222-1-cgel.zte@gmail.com Signed-off-by: Guo Ziliang Reported-by: Zeal Robot Reviewed-by: Ran Xiaokai Reviewed-by: Jiang Xuexin Reviewed-by: Yang Yang Acked-by: Hugh Dickins Cc: Naoya Horiguchi Cc: Michal Hocko Cc: Minchan Kim Cc: Johannes Weiner Cc: Roger Quadros Cc: Ziliang Guo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- mm/swap_state.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -478,7 +478,7 @@ struct page *__read_swap_cache_async(swp * __read_swap_cache_async(), which has set SWAP_HAS_CACHE * in swap_map, but not yet added its page to swap cache. */ - cond_resched(); + schedule_timeout_uninterruptible(1); } =20 /* From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4991FC433F5 for ; Mon, 21 Mar 2022 14:14:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349228AbiCUOQD (ORCPT ); Mon, 21 Mar 2022 10:16:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59888 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349783AbiCUOIo (ORCPT ); Mon, 21 Mar 2022 10:08:44 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A72793A5FA; Mon, 21 Mar 2022 07:03:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 1DC94CE18C3; Mon, 21 Mar 2022 14:03:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30C68C340F2; Mon, 21 Mar 2022 14:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871391; bh=vZuF8pNbfFHYqxphOwnhbj2YwC3gKbMH1JxCRjKzhzI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ciISTSXZ7LCmKIFPfpOzTHZkv3djBaiOUDsYXis1CQf0liizTnXNLgIMtIPoZ9uIj XeQGXWtRo7AvX8INiQDBg483Di6YLWlym3I63uXfHoaQs1Q4YFRkPbuZnDjwD5ipoR qQTrB7dMMJTJmknxxsBeH6zJqdu+VWZWPjiXKNmI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christoph Hellwig , syzbot+b42749a851a47a0f581b@syzkaller.appspotmail.com, Ming Lei , Bart Van Assche , Jens Axboe Subject: [PATCH 5.16 04/37] block: release rq qos structures for queue without disk Date: Mon, 21 Mar 2022 14:52:46 +0100 Message-Id: <20220321133221.421650667@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ming Lei commit daaca3522a8e67c46e39ef09c1d542e866f85f3b upstream. blkcg_init_queue() may add rq qos structures to request queue, previously blk_cleanup_queue() calls rq_qos_exit() to release them, but commit 8e141f9eb803 ("block: drain file system I/O on del_gendisk") moves rq_qos_exit() into del_gendisk(), so memory leak is caused because queues may not have disk, such as un-present scsi luns, nvme admin queue, ... Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back. BTW, v5.18 won't need this patch any more since we move blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release handler, and patches have been in for-5.18/block. Cc: Christoph Hellwig Cc: stable@vger.kernel.org Fixes: 8e141f9eb803 ("block: drain file system I/O on del_gendisk") Reported-by: syzbot+b42749a851a47a0f581b@syzkaller.appspotmail.com Signed-off-by: Ming Lei Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220314043018.177141-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- block/blk-core.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/block/blk-core.c +++ b/block/blk-core.c @@ -51,6 +51,7 @@ #include "blk-mq-sched.h" #include "blk-pm.h" #include "blk-throttle.h" +#include "blk-rq-qos.h" =20 struct dentry *blk_debugfs_root; =20 @@ -354,6 +355,9 @@ void blk_cleanup_queue(struct request_qu */ blk_freeze_queue(q); =20 + /* cleanup rq qos structures for queue without disk */ + rq_qos_exit(q); + blk_queue_flag_set(QUEUE_FLAG_DEAD, q); =20 blk_sync_queue(q); From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81EE5C433EF for ; Mon, 21 Mar 2022 14:12:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352107AbiCUONT (ORCPT ); Mon, 21 Mar 2022 10:13:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348935AbiCUOFq (ORCPT ); Mon, 21 Mar 2022 10:05:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 137499F6EE; Mon, 21 Mar 2022 07:01:42 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 67DA46132C; Mon, 21 Mar 2022 14:01:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7CA7DC340E8; Mon, 21 Mar 2022 14:01:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871300; bh=np3PsbtFyilrKjrzx10d3sqVMIWHD2rFyiUwMPptA/8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Aiv+LtvfRCmFQlLSbPX+I96QmaMvvgWIE5lKGujK97VMdiSkGhVEqpOXGojM0KoPe Ir1EKbujbgJJ8YSbuy7nRlUkYlqgYvXt+3l1raedf8rYgnN6GrGXyGZNYDXC4hhJwY jKZLEm0bE51QQXNxKOiMDHD0yQOWoS7YGeCuK02c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jocelyn Falempe , Thomas Zimmermann Subject: [PATCH 5.16 05/37] drm/mgag200: Fix PLL setup for g200wb and g200ew Date: Mon, 21 Mar 2022 14:52:47 +0100 Message-Id: <20220321133221.450651401@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jocelyn Falempe commit 40ce1121c1d76daf9048a86e36c83e469281b9fd upstream. commit f86c3ed55920 ("drm/mgag200: Split PLL setup into compute and update functions") introduced a regression for g200wb and g200ew. The PLLs are not set up properly, and VGA screen stays black, or displays "out of range" message. MGA1064_WB_PIX_PLLC_N/M/P was mistakenly replaced with MGA1064_PIX_PLLC_N/M/P which have different addresses. Patch tested on a Dell T310 with g200wb Fixes: f86c3ed55920 ("drm/mgag200: Split PLL setup into compute and update = functions") Cc: stable@vger.kernel.org Signed-off-by: Jocelyn Falempe Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220308174321.225606-1= -jfalempe@redhat.com Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/gpu/drm/mgag200/mgag200_pll.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/gpu/drm/mgag200/mgag200_pll.c +++ b/drivers/gpu/drm/mgag200/mgag200_pll.c @@ -404,9 +404,9 @@ mgag200_pixpll_update_g200wb(struct mgag udelay(50); =20 /* program pixel pll register */ - WREG_DAC(MGA1064_PIX_PLLC_N, xpixpllcn); - WREG_DAC(MGA1064_PIX_PLLC_M, xpixpllcm); - WREG_DAC(MGA1064_PIX_PLLC_P, xpixpllcp); + WREG_DAC(MGA1064_WB_PIX_PLLC_N, xpixpllcn); + WREG_DAC(MGA1064_WB_PIX_PLLC_M, xpixpllcm); + WREG_DAC(MGA1064_WB_PIX_PLLC_P, xpixpllcp); =20 udelay(50); From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2BA8C43217 for ; Mon, 21 Mar 2022 14:13:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349118AbiCUOOe (ORCPT ); Mon, 21 Mar 2022 10:14:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347546AbiCUOHp (ORCPT ); Mon, 21 Mar 2022 10:07:45 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4CAA840E59; Mon, 21 Mar 2022 07:02:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DF41B61291; Mon, 21 Mar 2022 14:02:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C77C3C340E8; Mon, 21 Mar 2022 14:02:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871331; bh=pyps9KTcDO8WjOHx8j2dMRE9vR8E3xDRAC8V3DWspiY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IgJbHWdWwGqqK8MbkjgYy727FTNOcWx5VtcwdMMaONch8EikKv6fLmjAnmKtOFPNo DXwo4PSimyobqVeKbTJ5FtGfeLv3dNgAuinhEFE0hXh1BX35UvVlXiwCSDngMr4xgv torscAj4VNzPHz2xzSj45ya3Wczz8G6QYyppt1JA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Randy Dunlap , Igor Zhbanov , Ard Biesheuvel , linux-efi@vger.kernel.org, Lukas Wunner , Octavian Purdila , "Rafael J. Wysocki" , Matt Fleming , Sasha Levin Subject: [PATCH 5.16 06/37] efi: fix return value of __setup handlers Date: Mon, 21 Mar 2022 14:52:48 +0100 Message-Id: <20220321133221.479389067@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Randy Dunlap [ Upstream commit 9feaf8b387ee0ece9c1d7add308776b502a35d0c ] When "dump_apple_properties" is used on the kernel boot command line, it causes an Unknown parameter message and the string is added to init's argument strings: Unknown kernel command line parameters "dump_apple_properties BOOT_IMAGE=3D/boot/bzImage-517rc6 efivar_ssdt=3Dnewcpu_ssdt", will be passed to user space. Run /sbin/init as init process with arguments: /sbin/init dump_apple_properties with environment: HOME=3D/ TERM=3Dlinux BOOT_IMAGE=3D/boot/bzImage-517rc6 efivar_ssdt=3Dnewcpu_ssdt Similarly when "efivar_ssdt=3Dsomestring" is used, it is added to the Unknown parameter message and to init's environment strings, polluting them (see examples above). Change the return value of the __setup functions to 1 to indicate that the __setup options have been handled. Fixes: 58c5475aba67 ("x86/efi: Retrieve and assign Apple device properties") Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables") Signed-off-by: Randy Dunlap Reported-by: Igor Zhbanov Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru Cc: Ard Biesheuvel Cc: linux-efi@vger.kernel.org Cc: Lukas Wunner Cc: Octavian Purdila Cc: "Rafael J. Wysocki" Cc: Matt Fleming Link: https://lore.kernel.org/r/20220301041851.12459-1-rdunlap@infradead.org Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/firmware/efi/apple-properties.c | 2 +- drivers/firmware/efi/efi.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/efi/apple-properties.c b/drivers/firmware/efi= /apple-properties.c index 4c3201e290e2..ea84108035eb 100644 --- a/drivers/firmware/efi/apple-properties.c +++ b/drivers/firmware/efi/apple-properties.c @@ -24,7 +24,7 @@ static bool dump_properties __initdata; static int __init dump_properties_enable(char *arg) { dump_properties =3D true; - return 0; + return 1; } =20 __setup("dump_apple_properties", dump_properties_enable); diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 7de3f5b6e8d0..5502e176d51b 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -212,7 +212,7 @@ static int __init efivar_ssdt_setup(char *str) memcpy(efivar_ssdt, str, strlen(str)); else pr_warn("efivar_ssdt: name too long: %s\n", str); - return 0; + return 1; } __setup("efivar_ssdt=3D", efivar_ssdt_setup); =20 --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CB3A5C433F5 for ; Mon, 21 Mar 2022 14:15:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349317AbiCUORI (ORCPT ); Mon, 21 Mar 2022 10:17:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349353AbiCUOIL (ORCPT ); Mon, 21 Mar 2022 10:08:11 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F1BB179417; Mon, 21 Mar 2022 07:02:44 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9DA31B816C8; Mon, 21 Mar 2022 14:02:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F059C340F2; Mon, 21 Mar 2022 14:02:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871361; bh=kK0ExYZAsFXBMqVa2Gyws0IcFssO//gPc8Ps9AhPX5E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FsG9N5D4pym0LpAUPh6XLrr7zO9bpg5P1PhoBUO6y1FkCEKSCvLsBS4QVJULoOa0Y tRwseAkfTf1TWTzte5wfQtgECRo1NA91uHQWlRDiZgnvezioMD+S24BxEki0kTtsRn IbXtmih4bsk/iDgtBDPdtq6lHHVuMNZCn9nxQPDA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Niels Dossche , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 07/37] alx: acquire mutex for alx_reinit in alx_change_mtu Date: Mon, 21 Mar 2022 14:52:49 +0100 Message-Id: <20220321133221.507932995@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Niels Dossche [ Upstream commit 46b348fd2d81a341b15fb3f3f986204b038f5c42 ] alx_reinit has a lockdep assertion that the alx->mtx mutex must be held. alx_reinit is called from two places: alx_reset and alx_change_mtu. alx_reset does acquire alx->mtx before calling alx_reinit. alx_change_mtu does not acquire this mutex, nor do its callers or any path towards alx_change_mtu. Acquire the mutex in alx_change_mtu. The issue was introduced when the fine-grained locking was introduced to the code to replace the RTNL. The same commit also introduced the lockdep assertion. Fixes: 4a5fe57e7751 ("alx: use fine-grained locking instead of RTNL") Signed-off-by: Niels Dossche Link: https://lore.kernel.org/r/20220310232707.44251-1-dossche.niels@gmail.= com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/ethernet/atheros/alx/main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet= /atheros/alx/main.c index 4ad3fc72e74e..a89b93cb4e26 100644 --- a/drivers/net/ethernet/atheros/alx/main.c +++ b/drivers/net/ethernet/atheros/alx/main.c @@ -1181,8 +1181,11 @@ static int alx_change_mtu(struct net_device *netdev,= int mtu) alx->hw.mtu =3D mtu; alx->rxbuf_size =3D max(max_frame, ALX_DEF_RXBUF_SIZE); netdev_update_features(netdev); - if (netif_running(netdev)) + if (netif_running(netdev)) { + mutex_lock(&alx->mtx); alx_reinit(alx); + mutex_unlock(&alx->mtx); + } return 0; } =20 --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77DEFC433EF for ; Mon, 21 Mar 2022 14:15:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349310AbiCUOQ7 (ORCPT ); Mon, 21 Mar 2022 10:16:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349516AbiCUOI2 (ORCPT ); Mon, 21 Mar 2022 10:08:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F0A0F1100; Mon, 21 Mar 2022 07:03:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id E15006134A; Mon, 21 Mar 2022 14:02:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01A0FC340ED; Mon, 21 Mar 2022 14:02:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871375; bh=95HZ3XeRnBKWRdaCHl1jh7aK50a+tt+8zliE33glLlA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p5zOqD4kx6iAh9wmFNs1y074i9vx2Nrv9iPKhKq3kJsO7/dvfciCopJSOyOBUAMRv T2KQTEJUyvZT42P9xQRRntWxImP77phCKWPH5rzg1gMRnKj0TkU5yI5bIwvoKl2EgD gZeVHC2a+r8KLRq9BJCiTT6S/IvjYDuV4e9v3l7E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stefano Garzarella , "Michael S. Tsirkin" , Jiyong Park , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 08/37] vsock: each transport cycles only on its own sockets Date: Mon, 21 Mar 2022 14:52:50 +0100 Message-Id: <20220321133221.535983427@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jiyong Park [ Upstream commit 8e6ed963763fe21429eabfc76c69ce2b0163a3dd ] When iterating over sockets using vsock_for_each_connected_socket, make sure that a transport filters out sockets that don't belong to the transport. There actually was an issue caused by this; in a nested VM configuration, destroying the nested VM (which often involves the closing of /dev/vhost-vsock if there was h2g connections to the nested VM) kills not only the h2g connections, but also all existing g2h connections to the (outmost) host which are totally unrelated. Tested: Executed the following steps on Cuttlefish (Android running on a VM) [1]: (1) Enter into an `adb shell` session - to have a g2h connection inside the VM, (2) open and then close /dev/vhost-vsock by `exec 3< /dev/vhost-vsock && exec 3<&-`, (3) observe that the adb session is not reset. [1] https://android.googlesource.com/device/google/cuttlefish/ Fixes: c0cfa2d8a788 ("vsock: add multi-transports support") Reviewed-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Signed-off-by: Jiyong Park Link: https://lore.kernel.org/r/20220311020017.1509316-1-jiyong@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/vhost/vsock.c | 3 ++- include/net/af_vsock.h | 3 ++- net/vmw_vsock/af_vsock.c | 9 +++++++-- net/vmw_vsock/virtio_transport.c | 7 +++++-- net/vmw_vsock/vmci_transport.c | 5 ++++- 5 files changed, 20 insertions(+), 7 deletions(-) diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c index 37f0b4274113..e6c9d41db1de 100644 --- a/drivers/vhost/vsock.c +++ b/drivers/vhost/vsock.c @@ -753,7 +753,8 @@ static int vhost_vsock_dev_release(struct inode *inode,= struct file *file) =20 /* Iterating over all connections for all CIDs to find orphans is * inefficient. Room for improvement here. */ - vsock_for_each_connected_socket(vhost_vsock_reset_orphans); + vsock_for_each_connected_socket(&vhost_transport.transport, + vhost_vsock_reset_orphans); =20 /* Don't check the owner, because we are in the release path, so we * need to stop the vsock device in any case. diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h index ab207677e0a8..f742e50207fb 100644 --- a/include/net/af_vsock.h +++ b/include/net/af_vsock.h @@ -205,7 +205,8 @@ struct sock *vsock_find_bound_socket(struct sockaddr_vm= *addr); struct sock *vsock_find_connected_socket(struct sockaddr_vm *src, struct sockaddr_vm *dst); void vsock_remove_sock(struct vsock_sock *vsk); -void vsock_for_each_connected_socket(void (*fn)(struct sock *sk)); +void vsock_for_each_connected_socket(struct vsock_transport *transport, + void (*fn)(struct sock *sk)); int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk); bool vsock_find_cid(unsigned int cid); =20 diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 8e4f2a1346be..782aa4209718 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -333,7 +333,8 @@ void vsock_remove_sock(struct vsock_sock *vsk) } EXPORT_SYMBOL_GPL(vsock_remove_sock); =20 -void vsock_for_each_connected_socket(void (*fn)(struct sock *sk)) +void vsock_for_each_connected_socket(struct vsock_transport *transport, + void (*fn)(struct sock *sk)) { int i; =20 @@ -342,8 +343,12 @@ void vsock_for_each_connected_socket(void (*fn)(struct= sock *sk)) for (i =3D 0; i < ARRAY_SIZE(vsock_connected_table); i++) { struct vsock_sock *vsk; list_for_each_entry(vsk, &vsock_connected_table[i], - connected_table) + connected_table) { + if (vsk->transport !=3D transport) + continue; + fn(sk_vsock(vsk)); + } } =20 spin_unlock_bh(&vsock_table_lock); diff --git a/net/vmw_vsock/virtio_transport.c b/net/vmw_vsock/virtio_transp= ort.c index 4f7c99dfd16c..dad9ca65f4f9 100644 --- a/net/vmw_vsock/virtio_transport.c +++ b/net/vmw_vsock/virtio_transport.c @@ -24,6 +24,7 @@ static struct workqueue_struct *virtio_vsock_workqueue; static struct virtio_vsock __rcu *the_virtio_vsock; static DEFINE_MUTEX(the_virtio_vsock_mutex); /* protects the_virtio_vsock = */ +static struct virtio_transport virtio_transport; /* forward declaration */ =20 struct virtio_vsock { struct virtio_device *vdev; @@ -384,7 +385,8 @@ static void virtio_vsock_event_handle(struct virtio_vso= ck *vsock, switch (le32_to_cpu(event->id)) { case VIRTIO_VSOCK_EVENT_TRANSPORT_RESET: virtio_vsock_update_guest_cid(vsock); - vsock_for_each_connected_socket(virtio_vsock_reset_sock); + vsock_for_each_connected_socket(&virtio_transport.transport, + virtio_vsock_reset_sock); break; } } @@ -662,7 +664,8 @@ static void virtio_vsock_remove(struct virtio_device *v= dev) synchronize_rcu(); =20 /* Reset all connected sockets when the device disappear */ - vsock_for_each_connected_socket(virtio_vsock_reset_sock); + vsock_for_each_connected_socket(&virtio_transport.transport, + virtio_vsock_reset_sock); =20 /* Stop all work handlers to make sure no one is accessing the device, * so we can safely call vdev->config->reset(). diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c index 7aef34e32bdf..b17dc9745188 100644 --- a/net/vmw_vsock/vmci_transport.c +++ b/net/vmw_vsock/vmci_transport.c @@ -75,6 +75,8 @@ static u32 vmci_transport_qp_resumed_sub_id =3D VMCI_INVA= LID_ID; =20 static int PROTOCOL_OVERRIDE =3D -1; =20 +static struct vsock_transport vmci_transport; /* forward declaration */ + /* Helper function to convert from a VMCI error code to a VSock error code= . */ =20 static s32 vmci_transport_error_to_vsock_error(s32 vmci_error) @@ -882,7 +884,8 @@ static void vmci_transport_qp_resumed_cb(u32 sub_id, const struct vmci_event_data *e_data, void *client_data) { - vsock_for_each_connected_socket(vmci_transport_handle_detach); + vsock_for_each_connected_socket(&vmci_transport, + vmci_transport_handle_detach); } =20 static void vmci_transport_recv_pkt_work(struct work_struct *work) --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF894C433F5 for ; Mon, 21 Mar 2022 14:14:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349122AbiCUOPa (ORCPT ); Mon, 21 Mar 2022 10:15:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349604AbiCUOId (ORCPT ); Mon, 21 Mar 2022 10:08:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 558291B7B5; Mon, 21 Mar 2022 07:03:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 9F6B661350; Mon, 21 Mar 2022 14:02:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ACC41C340E8; Mon, 21 Mar 2022 14:02:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871378; bh=2nO093whqQ/sqbYqWbv0LaogH00/S1O/HY0QpO+NfNU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uqwUb/iCbeAiGiH6bOubamMb0i0uW3ZAg+C8v54TG9rDDjbseI5zc3tvU32XFWxJ8 jwKryWbIpPNP3K3PwOd/+kLeyVK/uYBK4XM1IO2XHFvt6pxYXC1ZUJFqrh1bYhsYTl OzZi9PNmaleALC0ulor5HDKmBUnlktbunm++uz+k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiumei Mu , Sabrina Dubroca , Steffen Klassert , Sasha Levin Subject: [PATCH 5.16 09/37] esp6: fix check on ipv6_skip_exthdrs return value Date: Mon, 21 Mar 2022 14:52:51 +0100 Message-Id: <20220321133221.564244907@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Sabrina Dubroca [ Upstream commit 4db4075f92af2b28f415fc979ab626e6b37d67b6 ] Commit 5f9c55c8066b ("ipv6: check return value of ipv6_skip_exthdr") introduced an incorrect check, which leads to all ESP packets over either TCPv6 or UDPv6 encapsulation being dropped. In this particular case, offset is negative, since skb->data points to the ESP header in the following chain of headers, while skb->network_header points to the IPv6 header: IPv6 | ext | ... | ext | UDP | ESP | ... That doesn't seem to be a problem, especially considering that if we reach esp6_input_done2, we're guaranteed to have a full set of headers available (otherwise the packet would have been dropped earlier in the stack). However, it means that the return value will (intentionally) be negative. We can make the test more specific, as the expected return value of ipv6_skip_exthdr will be the (negated) size of either a UDP header, or a TCP header with possible options. In the future, we should probably either make ipv6_skip_exthdr explicitly accept negative offsets (and adjust its return value for error cases), or make ipv6_skip_exthdr only take non-negative offsets (and audit all callers). Fixes: 5f9c55c8066b ("ipv6: check return value of ipv6_skip_exthdr") Reported-by: Xiumei Mu Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- net/ipv6/esp6.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c index b7b573085bd5..5023f59a5b96 100644 --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -813,8 +813,7 @@ int esp6_input_done2(struct sk_buff *skb, int err) struct tcphdr *th; =20 offset =3D ipv6_skip_exthdr(skb, offset, &nexthdr, &frag_off); - - if (offset < 0) { + if (offset =3D=3D -1) { err =3D -EINVAL; goto out; } --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 092B5C433F5 for ; Mon, 21 Mar 2022 14:22:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349588AbiCUOSN (ORCPT ); Mon, 21 Mar 2022 10:18:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349616AbiCUOId (ORCPT ); Mon, 21 Mar 2022 10:08:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D0CC1E3E4; Mon, 21 Mar 2022 07:03:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4F2C4611D5; Mon, 21 Mar 2022 14:03:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AC9EC340E8; Mon, 21 Mar 2022 14:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871380; bh=dja4BpNU5v3FWoo+Pg9KabpZUGDnbBswDF7NRHePqXI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jptkxEW4h0u2TKhrm4DSpFa7ruXX+dWtfG8XxBQs6NGhhE3qGJ/EpSj/Y5PWW3e+w Cr4qExu4w0oJ/pnAKh17yjBr+h9qfbPSfZuQBWj6HRRzLyZAjxaeYNrLmzQ44lRgOn vlcOI0aEzGqAtibDbqCKSsnDk6zJpkI7wLOtG6SA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kurt Cancemi , Andrew Lunn , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 10/37] net: phy: marvell: Fix invalid comparison in the resume and suspend functions Date: Mon, 21 Mar 2022 14:52:52 +0100 Message-Id: <20220321133221.593414150@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kurt Cancemi [ Upstream commit 837d9e49402eaf030db55a49f96fc51d73b4b441 ] This bug resulted in only the current mode being resumed and suspended when the PHY supported both fiber and copper modes and when the PHY only support= ed copper mode the fiber mode would incorrectly be attempted to be resumed and suspended. Fixes: 3758be3dc162 ("Marvell phy: add functions to suspend and resume both= interfaces: fiber and copper links.") Signed-off-by: Kurt Cancemi Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220312201512.326047-1-kurt@x64architectur= e.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/phy/marvell.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c index cfda625dbea5..4d726ee03ce2 100644 --- a/drivers/net/phy/marvell.c +++ b/drivers/net/phy/marvell.c @@ -1693,8 +1693,8 @@ static int marvell_suspend(struct phy_device *phydev) int err; =20 /* Suspend the fiber mode first */ - if (!linkmode_test_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, - phydev->supported)) { + if (linkmode_test_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, + phydev->supported)) { err =3D marvell_set_page(phydev, MII_MARVELL_FIBER_PAGE); if (err < 0) goto error; @@ -1728,8 +1728,8 @@ static int marvell_resume(struct phy_device *phydev) int err; =20 /* Resume the fiber mode first */ - if (!linkmode_test_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, - phydev->supported)) { + if (linkmode_test_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, + phydev->supported)) { err =3D marvell_set_page(phydev, MII_MARVELL_FIBER_PAGE); if (err < 0) goto error; --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B550AC433F5 for ; Mon, 21 Mar 2022 14:14:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349213AbiCUOPt (ORCPT ); Mon, 21 Mar 2022 10:15:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349672AbiCUOIh (ORCPT ); Mon, 21 Mar 2022 10:08:37 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 071B3BC1B; Mon, 21 Mar 2022 07:03:12 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 05603B816D9; Mon, 21 Mar 2022 14:03:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28685C340E8; Mon, 21 Mar 2022 14:03:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871383; bh=oMC3RtMnJPyHCeqYyWczj08a9PvQcM0tkZN8CGeCCAA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EjRIJexuFf6QRVQUkqsIRbGaRXVAVsyMq/UbbLU6368DWXPa+QhdyFUIA0a9jeemj FSEBeQrpzASUzBP59tZagbXm8kOKB4D7GzhFLYlK7KUodORG5fkQjc4MntuNqIXsCa mjSXVgPqhTjqkKpPn9jVw+s6NzMTOyiiRf4a1wtQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , syzbot , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 11/37] net/packet: fix slab-out-of-bounds access in packet_recvmsg() Date: Mon, 21 Mar 2022 14:52:53 +0100 Message-Id: <20220321133221.622664273@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit c700525fcc06b05adfea78039de02628af79e07a ] syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH and mmap operations, tpacket_rcv() is queueing skbs with garbage in skb->cb[], triggering a too big copy [1] Presumably, users of af_packet using mmap() already gets correct metadata from the mapped buffer, we can simply make sure to clear 12 bytes that might be copied to user space later. BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:22= 5 [inline] BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/a= f_packet.c:3489 Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-023= 96-g0b3660695e80 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [inline] packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 = 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff f= f 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005 RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60 R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at o= ffset 32 in frame: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246 this frame has 1 object: [32, 160) 'addr' Memory state around the buggy address: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 >ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fixes: 0fb375fb9b93 ("[AF_PACKET]: Allow for > 8 byte hardware addresses.") Signed-off-by: Eric Dumazet Reported-by: syzbot Link: https://lore.kernel.org/r/20220312232958.3535620-1-eric.dumazet@gmail= .com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- net/packet/af_packet.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c index fe9b4c04744a..92d180a0db5a 100644 --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -2316,8 +2316,11 @@ static int tpacket_rcv(struct sk_buff *skb, struct n= et_device *dev, copy_skb =3D skb_get(skb); skb_head =3D skb->data; } - if (copy_skb) + if (copy_skb) { + memset(&PACKET_SKB_CB(copy_skb)->sa.ll, 0, + sizeof(PACKET_SKB_CB(copy_skb)->sa.ll)); skb_set_owner_r(copy_skb, sk); + } } snaplen =3D po->rx_ring.frame_size - macoff; if ((int)snaplen < 0) { @@ -3469,6 +3472,8 @@ static int packet_recvmsg(struct socket *sock, struct= msghdr *msg, size_t len, sock_recv_ts_and_drops(msg, sk, skb); =20 if (msg->msg_name) { + const size_t max_len =3D min(sizeof(skb->cb), + sizeof(struct sockaddr_storage)); int copy_len; =20 /* If the address length field is there to be filled @@ -3491,6 +3496,10 @@ static int packet_recvmsg(struct socket *sock, struc= t msghdr *msg, size_t len, msg->msg_namelen =3D sizeof(struct sockaddr_ll); } } + if (WARN_ON_ONCE(copy_len > max_len)) { + copy_len =3D max_len; + msg->msg_namelen =3D copy_len; + } memcpy(msg->msg_name, &PACKET_SKB_CB(skb)->sa, copy_len); } =20 --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18C1FC433FE for ; Mon, 21 Mar 2022 14:22:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349610AbiCUOSU (ORCPT ); Mon, 21 Mar 2022 10:18:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349611AbiCUOId (ORCPT ); Mon, 21 Mar 2022 10:08:33 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CE411E3D5; Mon, 21 Mar 2022 07:03:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B09ED6132C; Mon, 21 Mar 2022 14:03:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0FB3C340E8; Mon, 21 Mar 2022 14:03:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871386; bh=0uBFwo4dObKSt47frABjkpdhEbOqAtuJ8KAHkE6jSiU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=J1iP2CjETf7WNqkuc+dPiwt56VxJT0LQLk04SRmMFo856iceBongTS9NQWxDHEKFM JfVbFRwZ3CkoFyIVZsMTIhLjfyz3kwy+3sPVr01sv06hNzdqVcBXWbv9DV3JEyyA/D Bs2rFX9LkRYV0LfWv+dJCZJSnIAYm+IWrxgAleC8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hannes Reinecke , Christoph Hellwig , Sasha Levin Subject: [PATCH 5.16 12/37] nvmet: revert "nvmet: make discovery NQN configurable" Date: Mon, 21 Mar 2022 14:52:54 +0100 Message-Id: <20220321133221.650869844@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Hannes Reinecke [ Upstream commit 0c48645a7f3988a624767d025fa3275ae24b6ca1 ] Revert commit 626851e9225d ("nvmet: make discovery NQN configurable"); the interface was deemed incorrect and will be replaced with a different one. Fixes: 626851e9225d ("nvmet: make discovery NQN configurable") Signed-off-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/nvme/target/configfs.c | 39 ---------------------------------- drivers/nvme/target/core.c | 3 +-- 2 files changed, 1 insertion(+), 41 deletions(-) diff --git a/drivers/nvme/target/configfs.c b/drivers/nvme/target/configfs.c index 091a0ca16361..496d775c6770 100644 --- a/drivers/nvme/target/configfs.c +++ b/drivers/nvme/target/configfs.c @@ -1233,44 +1233,6 @@ static ssize_t nvmet_subsys_attr_model_store(struct = config_item *item, } CONFIGFS_ATTR(nvmet_subsys_, attr_model); =20 -static ssize_t nvmet_subsys_attr_discovery_nqn_show(struct config_item *it= em, - char *page) -{ - return snprintf(page, PAGE_SIZE, "%s\n", - nvmet_disc_subsys->subsysnqn); -} - -static ssize_t nvmet_subsys_attr_discovery_nqn_store(struct config_item *i= tem, - const char *page, size_t count) -{ - struct nvmet_subsys *subsys =3D to_subsys(item); - char *subsysnqn; - int len; - - len =3D strcspn(page, "\n"); - if (!len) - return -EINVAL; - - subsysnqn =3D kmemdup_nul(page, len, GFP_KERNEL); - if (!subsysnqn) - return -ENOMEM; - - /* - * The discovery NQN must be different from subsystem NQN. - */ - if (!strcmp(subsysnqn, subsys->subsysnqn)) { - kfree(subsysnqn); - return -EBUSY; - } - down_write(&nvmet_config_sem); - kfree(nvmet_disc_subsys->subsysnqn); - nvmet_disc_subsys->subsysnqn =3D subsysnqn; - up_write(&nvmet_config_sem); - - return count; -} -CONFIGFS_ATTR(nvmet_subsys_, attr_discovery_nqn); - #ifdef CONFIG_BLK_DEV_INTEGRITY static ssize_t nvmet_subsys_attr_pi_enable_show(struct config_item *item, char *page) @@ -1300,7 +1262,6 @@ static struct configfs_attribute *nvmet_subsys_attrs[= ] =3D { &nvmet_subsys_attr_attr_cntlid_min, &nvmet_subsys_attr_attr_cntlid_max, &nvmet_subsys_attr_attr_model, - &nvmet_subsys_attr_attr_discovery_nqn, #ifdef CONFIG_BLK_DEV_INTEGRITY &nvmet_subsys_attr_attr_pi_enable, #endif diff --git a/drivers/nvme/target/core.c b/drivers/nvme/target/core.c index 5119c687de68..626caf6f1e4b 100644 --- a/drivers/nvme/target/core.c +++ b/drivers/nvme/target/core.c @@ -1493,8 +1493,7 @@ static struct nvmet_subsys *nvmet_find_get_subsys(str= uct nvmet_port *port, if (!port) return NULL; =20 - if (!strcmp(NVME_DISC_SUBSYS_NAME, subsysnqn) || - !strcmp(nvmet_disc_subsys->subsysnqn, subsysnqn)) { + if (!strcmp(NVME_DISC_SUBSYS_NAME, subsysnqn)) { if (!kref_get_unless_zero(&nvmet_disc_subsys->ref)) return NULL; return nvmet_disc_subsys; --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D3D7C433EF for ; Mon, 21 Mar 2022 14:14:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349145AbiCUOPz (ORCPT ); Mon, 21 Mar 2022 10:15:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39880 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349719AbiCUOIj (ORCPT ); Mon, 21 Mar 2022 10:08:39 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11BF243EDC; Mon, 21 Mar 2022 07:03:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 0FD08B816C8; Mon, 21 Mar 2022 14:03:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 770F9C340E8; Mon, 21 Mar 2022 14:03:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871388; bh=qPfk6gLyWnnbd5V+f6dbSOSO0L4BM1LgWP0BU6fEpnw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IX7Pd5JjqPeJyySR41hDA6xFgE9wRAbXuiOOZ2+etto1hs9iNJ2eVlysH3x1qneSg On6LDeurXUYs8ir7CxcRanw0Uv6x+xqYwy1A1GIGDO/ehwoeb4EuCViFIT4Wybu+R6 x7OkFJYSwqd79KTcVAZN85MlxU+r14e7apBSxrxw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiasheng Jiang , "David S. Miller" , Sasha Levin Subject: [PATCH 5.16 13/37] atm: eni: Add check for dma_map_single Date: Mon, 21 Mar 2022 14:52:55 +0100 Message-Id: <20220321133221.679081884@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jiasheng Jiang [ Upstream commit 0f74b29a4f53627376cf5a5fb7b0b3fa748a0b2b ] As the potential failure of the dma_map_single(), it should be better to check it and return error if fails. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Jiasheng Jiang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/atm/eni.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/atm/eni.c b/drivers/atm/eni.c index 422753d52244..a31ffe16e626 100644 --- a/drivers/atm/eni.c +++ b/drivers/atm/eni.c @@ -1112,6 +1112,8 @@ DPRINTK("iovcnt =3D %d\n",skb_shinfo(skb)->nr_frags); skb_data3 =3D skb->data[3]; paddr =3D dma_map_single(&eni_dev->pci_dev->dev,skb->data,skb->len, DMA_TO_DEVICE); + if (dma_mapping_error(&eni_dev->pci_dev->dev, paddr)) + return enq_next; ENI_PRV_PADDR(skb) =3D paddr; /* prepare DMA queue entries */ j =3D 0; --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 881B2C35280 for ; Mon, 21 Mar 2022 14:12:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345721AbiCUONX (ORCPT ); Mon, 21 Mar 2022 10:13:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348955AbiCUOFr (ORCPT ); Mon, 21 Mar 2022 10:05:47 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EA4C37BFE; Mon, 21 Mar 2022 07:01:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E3080B816D7; Mon, 21 Mar 2022 14:01:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31A9FC340E8; Mon, 21 Mar 2022 14:01:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871303; bh=tNAaY6+AF7LQOOmXcwOK7yuMrUF7EjEeuneIyfNNSLQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=noPVJIejAyLUXTlsiPYZc331KRswnMkhCoeATSjI6DoXZ0qvHGOv2BYmDATIQ5qTN 6Tf2yDxRG6s81Y6iN/Kjk81uM+J3C5b5FKiM1klH4QvJBWVZ6bfCVKoaPDjtooQQ55 z9w2Qp9223CBm7G1aE0vp/BYLjGs4Paj+PaqH7j0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, kernel test robot , Dan Carpenter , Maciej Fijalkowski , Alexander Lobakin , Tony Nguyen , Sasha Levin , Gurucharan G Subject: [PATCH 5.16 14/37] ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats() Date: Mon, 21 Mar 2022 14:52:56 +0100 Message-Id: <20220321133221.707706421@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Maciej Fijalkowski [ Upstream commit f153546913bada41a811722f2c6d17c3243a0333 ] It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL. Fixes: e72bba21355d ("ice: split ice_ring onto Tx/Rx separate structs") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Maciej Fijalkowski Acked-by: Alexander Lobakin Tested-by: Gurucharan G (A Contingent worker at I= ntel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/ethernet/intel/ice/ice_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethern= et/intel/ice/ice_main.c index 8a6c3716cdab..b449b3408a1c 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -5972,8 +5972,9 @@ ice_update_vsi_tx_ring_stats(struct ice_vsi *vsi, u64 pkts =3D 0, bytes =3D 0; =20 ring =3D READ_ONCE(rings[i]); - if (ring) - ice_fetch_u64_stats_per_ring(&ring->syncp, ring->stats, &pkts, &bytes); + if (!ring) + continue; + ice_fetch_u64_stats_per_ring(&ring->syncp, ring->stats, &pkts, &bytes); vsi_stats->tx_packets +=3D pkts; vsi_stats->tx_bytes +=3D bytes; vsi->tx_restart +=3D ring->tx_stats.restart_q; --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2736DC4332F for ; Mon, 21 Mar 2022 14:12:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345253AbiCUOOR (ORCPT ); Mon, 21 Mar 2022 10:14:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348854AbiCUOF7 (ORCPT ); Mon, 21 Mar 2022 10:05:59 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D85F6B2476; Mon, 21 Mar 2022 07:01:48 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 82C8BB816DD; Mon, 21 Mar 2022 14:01:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF88BC340E8; Mon, 21 Mar 2022 14:01:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871306; bh=Vdb1iWqlqHWiCH1Lg+xVDeo/BUxVscRQ0x8Astw8CXA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZMpfSoo1Bdcp6LcC1Pu/7NEYKALE8/j0McI3yokFNz3M/KoYpJokmVf5iaZO6PU// P2SAKah+Sq7CvYoVw0sijUWabY0ALwqpjgT/ORD5fSA9j3q12Jx47dEgDkoIQUA6Gq nOQy+xxiZg8RhYTAs9m5hekCumKzs7E0t9/4F1gs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Przemyslaw Patynowski , Dan Carpenter , Mateusz Palczewski , Konrad Jankowski , Tony Nguyen , Sasha Levin Subject: [PATCH 5.16 15/37] iavf: Fix double free in iavf_reset_task Date: Mon, 21 Mar 2022 14:52:57 +0100 Message-Id: <20220321133221.737945027@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Przemyslaw Patynowski [ Upstream commit 16b2dd8cdf6f4e0597c34899de74b4d012b78188 ] Fix double free possibility in iavf_disable_vf, as crit_lock is freed in caller, iavf_reset_task. Add kernel-doc for iavf_disable_vf. Remove mutex_unlock in iavf_disable_vf. Without this patch there is double free scenario, when calling iavf_reset_task. Fixes: e85ff9c631e1 ("iavf: Fix deadlock in iavf_reset_task") Signed-off-by: Przemyslaw Patynowski Suggested-by: Dan Carpenter Signed-off-by: Mateusz Palczewski Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/ethernet/intel/iavf/iavf_main.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethe= rnet/intel/iavf/iavf_main.c index 138db07bdfa8..f2ce30366484 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_main.c +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c @@ -2133,6 +2133,13 @@ static void iavf_watchdog_task(struct work_struct *w= ork) queue_delayed_work(iavf_wq, &adapter->watchdog_task, HZ * 2); } =20 +/** + * iavf_disable_vf - disable VF + * @adapter: board private structure + * + * Set communication failed flag and free all resources. + * NOTE: This function is expected to be called with crit_lock being held. + **/ static void iavf_disable_vf(struct iavf_adapter *adapter) { struct iavf_mac_filter *f, *ftmp; @@ -2187,7 +2194,6 @@ static void iavf_disable_vf(struct iavf_adapter *adap= ter) memset(adapter->vf_res, 0, IAVF_VIRTCHNL_VF_RESOURCE_SIZE); iavf_shutdown_adminq(&adapter->hw); adapter->netdev->flags &=3D ~IFF_UP; - mutex_unlock(&adapter->crit_lock); adapter->flags &=3D ~IAVF_FLAG_RESET_PENDING; iavf_change_state(adapter, __IAVF_DOWN); wake_up(&adapter->down_waitqueue); --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D0DFC43219 for ; Mon, 21 Mar 2022 14:12:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343577AbiCUONs (ORCPT ); Mon, 21 Mar 2022 10:13:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346510AbiCUOGx (ORCPT ); Mon, 21 Mar 2022 10:06:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 20C2A39150; Mon, 21 Mar 2022 07:01:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B18F06125C; Mon, 21 Mar 2022 14:01:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2FCEC340E8; Mon, 21 Mar 2022 14:01:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871309; bh=KeThQ4Xkm9ZzMBh/v6cnasHmfIHk65epkL073iR7Mtk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kgo7Rg2ujkSG4J0lQfdveqNYo+wV5OjVwUukoJhWWlGgu7WBml+8e5a3bHw6lmK/t 5E0Wd42whdWQkumQzfBkx4NtRbGKdJZekzSqvTuIye8nfbF962jwcX4gLrxeZG2OGO /e2SylztekMOgS2Lr7SiZGvoLZbmui79oRV0jyHg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiasheng Jiang , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 16/37] hv_netvsc: Add check for kvmalloc_array Date: Mon, 21 Mar 2022 14:52:58 +0100 Message-Id: <20220321133221.766451095@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Jiasheng Jiang [ Upstream commit 886e44c9298a6b428ae046e2fa092ca52e822e6a ] As the potential failure of the kvmalloc_array(), it should be better to check and restore the 'data' if fails in order to avoid the dereference of the NULL pointer. Fixes: 6ae746711263 ("hv_netvsc: Add per-cpu ethtool stats for netvsc") Signed-off-by: Jiasheng Jiang Link: https://lore.kernel.org/r/20220314020125.2365084-1-jiasheng@iscas.ac.= cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/hyperv/netvsc_drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_dr= v.c index 7e66ae1d2a59..7117187dfbd7 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -1587,6 +1587,9 @@ static void netvsc_get_ethtool_stats(struct net_devic= e *dev, pcpu_sum =3D kvmalloc_array(num_possible_cpus(), sizeof(struct netvsc_ethtool_pcpu_stats), GFP_KERNEL); + if (!pcpu_sum) + return; + netvsc_get_pcpu_stats(dev, pcpu_sum); for_each_present_cpu(cpu) { struct netvsc_ethtool_pcpu_stats *this_sum =3D &pcpu_sum[cpu]; --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 33AB3C433FE for ; Mon, 21 Mar 2022 14:22:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349442AbiCUOR4 (ORCPT ); Mon, 21 Mar 2022 10:17:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349022AbiCUOGx (ORCPT ); Mon, 21 Mar 2022 10:06:53 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7028D3D1F8; Mon, 21 Mar 2022 07:01:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 089DAB816DC; Mon, 21 Mar 2022 14:01:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 469D4C340F3; Mon, 21 Mar 2022 14:01:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871311; bh=ZLNrGtC/1yYtaIEPvn2dN37TDlIhPm1AaMyY5zLM+o8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w8gY10Zv3XvQyqm2Nt5OAfbKkFgLHV2J5YO3Iotiy2u/isKlm7tgLPqy9zeWe47+z MAyMKDwDDXiU1yKDNENy1+mwsmOd6SgN/UtVjolaUGeNEDO5v/2lA/jQP4qMjXb6Fo X4VsgHpCIBQrBnQoEUgKO35jyy4OSQfjQPcYBEqg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christoph Niedermaier , Marek Vasut , Boris Brezillon , Philipp Zabel , David Airlie , Daniel Vetter , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , linux-arm-kernel@lists.infradead.org, Max Krummenacher , Maarten Lankhorst , Sasha Levin Subject: [PATCH 5.16 17/37] drm/imx: parallel-display: Remove bus flags check in imx_pd_bridge_atomic_check() Date: Mon, 21 Mar 2022 14:52:59 +0100 Message-Id: <20220321133221.794975962@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Christoph Niedermaier [ Upstream commit 6061806a863e8b65b109eb06a280041cc7525442 ] If display timings were read from the devicetree using of_get_display_timing() and pixelclk-active is defined there, the flag DISPLAY_FLAGS_SYNC_POSEDGE/NEGEDGE is automatically generated. Through the function drm_bus_flags_from_videomode() e.g. called in the panel-simple driver this flag got into the bus flags, but then in imx_pd_bridge_atomic_check() the bus flag check failed and will not initialize the display. The original commit fe141cedc433 does not explain why this check was introduced. So remove the bus flags check, because it stops the initialization of the display with valid bus flags. Fixes: fe141cedc433 ("drm/imx: pd: Use bus format/flags provided by the bri= dge when available") Signed-off-by: Christoph Niedermaier Cc: Marek Vasut Cc: Boris Brezillon Cc: Philipp Zabel Cc: David Airlie Cc: Daniel Vetter Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: linux-arm-kernel@lists.infradead.org To: dri-devel@lists.freedesktop.org Tested-by: Max Krummenacher Acked-by: Boris Brezillon Signed-off-by: Marek Vasut Link: https://patchwork.freedesktop.org/patch/msgid/20220201113643.4638-1-c= niedermaier@dh-electronics.com Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/gpu/drm/imx/parallel-display.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/imx/parallel-display.c b/drivers/gpu/drm/imx/p= arallel-display.c index a8aba0141ce7..06cb1a59b9bc 100644 --- a/drivers/gpu/drm/imx/parallel-display.c +++ b/drivers/gpu/drm/imx/parallel-display.c @@ -217,14 +217,6 @@ static int imx_pd_bridge_atomic_check(struct drm_bridg= e *bridge, if (!imx_pd_format_supported(bus_fmt)) return -EINVAL; =20 - if (bus_flags & - ~(DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_DE_HIGH | - DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE | - DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE)) { - dev_warn(imxpd->dev, "invalid bus_flags (%x)\n", bus_flags); - return -EINVAL; - } - bridge_state->output_bus_cfg.flags =3D bus_flags; bridge_state->input_bus_cfg.flags =3D bus_flags; imx_crtc_state->bus_flags =3D bus_flags; --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 41D2FC433EF for ; Mon, 21 Mar 2022 14:22:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349501AbiCUOSE (ORCPT ); Mon, 21 Mar 2022 10:18:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349024AbiCUOGx (ORCPT ); Mon, 21 Mar 2022 10:06:53 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6EC523D4AC; Mon, 21 Mar 2022 07:01:55 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 079E96134B; Mon, 21 Mar 2022 14:01:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E01BBC340E8; Mon, 21 Mar 2022 14:01:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871314; bh=dOngte7wDYXuEx59lkF/6L4j2HvH4Rsn+39KIAog/z8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ynonakilRfAX2Jh3K9bsSKHAt94pvj8/YNjxVun0zTCmeOuAG1XN2vXe2aryB9eil vhwwmN25/jh5D3D/To01+fQ1uBRPDra3WU2NXVPE0RECMkfNv0MAmMPIKngyLAZJib mxg92xijfAgdAgKT5rTRPaCJPM4yLWO4BQrBkPsI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marek Vasut , Christoph Fritz , Laurent Pinchart , Maxime Ripard , Sam Ravnborg , Thomas Zimmermann , Laurent Pinchart , Maarten Lankhorst , Sasha Levin Subject: [PATCH 5.16 18/37] drm/panel: simple: Fix Innolux G070Y2-L01 BPP settings Date: Mon, 21 Mar 2022 14:53:00 +0100 Message-Id: <20220321133221.824234485@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Marek Vasut [ Upstream commit fc1b6ef7bfb3d1d4df868b1c3e0480cacda6cd81 ] The Innolux G070Y2-L01 supports two modes of operation: 1) FRC=3DLow/NC ... MEDIA_BUS_FMT_RGB666_1X7X3_SPWG ... BPP=3D6 2) FRC=3DHigh ..... MEDIA_BUS_FMT_RGB888_1X7X4_SPWG ... BPP=3D8 Currently the panel description mixes both, BPP from 1) and bus format from 2), which triggers a warning at panel-simple.c:615. Pick the later, set bpp=3D8, fix the warning. Fixes: a5d2ade627dca ("drm/panel: simple: Add support for Innolux G070Y2-L0= 1") Signed-off-by: Marek Vasut Cc: Christoph Fritz Cc: Laurent Pinchart Cc: Maxime Ripard Cc: Sam Ravnborg Cc: Thomas Zimmermann Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20220220040718.532866-1= -marex@denx.de Signed-off-by: Maarten Lankhorst Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/gpu/drm/panel/panel-simple.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/p= anel-simple.c index 87f30bced7b7..6a820b698f5a 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -2017,7 +2017,7 @@ static const struct display_timing innolux_g070y2_l01= _timing =3D { static const struct panel_desc innolux_g070y2_l01 =3D { .timings =3D &innolux_g070y2_l01_timing, .num_timings =3D 1, - .bpc =3D 6, + .bpc =3D 8, .size =3D { .width =3D 152, .height =3D 91, --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80276C433F5 for ; Mon, 21 Mar 2022 14:22:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349261AbiCUORr (ORCPT ); Mon, 21 Mar 2022 10:17:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348687AbiCUOGz (ORCPT ); Mon, 21 Mar 2022 10:06:55 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD2353E5CD; Mon, 21 Mar 2022 07:01:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6F25DB816D7; Mon, 21 Mar 2022 14:01:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0B9AC340ED; Mon, 21 Mar 2022 14:01:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871317; bh=P2IQTYz+6Lh8+CGifj/lOi7qPetT3jjEs9BZ0XForo0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fv28FioWB2hxFu28KrmTa1vmnRCGtHbt0+kDrM057Ad0LFainvRu687Rhx0kIZ6Nq KHFxMu993kObJ7mbCcnWAXsc1Zako++DYWXMdJ7GVUZY5bZvYu9bZ9wpFbSPbcwzY7 SX7ics5BUfUG4QS2VOTFnHjd18tBPWU3m0HjaYeU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Nicolas Dichtel , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 19/37] net: handle ARPHRD_PIMREG in dev_is_mac_header_xmit() Date: Mon, 21 Mar 2022 14:53:01 +0100 Message-Id: <20220321133221.852248137@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Nicolas Dichtel [ Upstream commit 4ee06de7729d795773145692e246a06448b1eb7a ] This kind of interface doesn't have a mac header. This patch fixes bpf_redirect() to a PIM interface. Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper") Signed-off-by: Nicolas Dichtel Link: https://lore.kernel.org/r/20220315092008.31423-1-nicolas.dichtel@6win= d.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- include/linux/if_arp.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/if_arp.h b/include/linux/if_arp.h index b712217f7030..1ed52441972f 100644 --- a/include/linux/if_arp.h +++ b/include/linux/if_arp.h @@ -52,6 +52,7 @@ static inline bool dev_is_mac_header_xmit(const struct ne= t_device *dev) case ARPHRD_VOID: case ARPHRD_NONE: case ARPHRD_RAWIP: + case ARPHRD_PIMREG: return false; default: return true; --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E429AC433EF for ; Mon, 21 Mar 2022 14:13:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349053AbiCUOO1 (ORCPT ); Mon, 21 Mar 2022 10:14:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348887AbiCUOG4 (ORCPT ); Mon, 21 Mar 2022 10:06:56 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A152F3EF3E; Mon, 21 Mar 2022 07:02:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 37BE5B816D8; Mon, 21 Mar 2022 14:02:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CC08C340E8; Mon, 21 Mar 2022 14:01:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871319; bh=1xDrE3o8l2iuNQei3iR6/FZfOOxhe6xPKBab17hrugo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vcRlPr/ny3SMGeZyl460pxz1ZaUkwMYgyTst4om8pY7wwT3IYsyluUmKxG9FURhIx uOqO60bBvY9QcqcIBLL3Lzvf3C2YfHBt1P2dC5rDsJz3UiDIPmrECN0aM6mQ/HX5/f WpYRatSYuJktWN737KVwzCoI3A2gtdAI0omzH0Ks= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Thomas Zimmermann , Sam Ravnborg , Brian Masney , kernel test robot , Naresh Kamboju , Linux Kernel Functional Testing , Lyude Paul , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , dri-devel@lists.freedesktop.org, Dave Airlie , Thierry Reding , Sasha Levin Subject: [PATCH 5.16 20/37] drm: Dont make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERS Date: Mon, 21 Mar 2022 14:53:02 +0100 Message-Id: <20220321133221.881441290@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Thomas Zimmermann [ Upstream commit 3c3384050d68570f9de0fec9e58824decfefba7a ] Fix a number of undefined references to drm_kms_helper.ko in drm_dp_helper.ko: arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in f= unction `drm_dp_mst_duplicate_state': drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to `__drm_atomi= c_helper_private_obj_duplicate_state' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in f= unction `drm_dp_delayed_destroy_work': drm_dp_mst_topology.c:(.text+0x370c): undefined reference to `drm_kms_hel= per_hotplug_event' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in f= unction `drm_dp_mst_up_req_work': drm_dp_mst_topology.c:(.text+0x7938): undefined reference to `drm_kms_hel= per_hotplug_event' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in f= unction `drm_dp_mst_link_probe_work': drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to `drm_kms_hel= per_hotplug_event' This happens if panel-edp.ko has been configured with DRM_PANEL_EDP=3Dy DRM_DP_HELPER=3Dy DRM_KMS_HELPER=3Dm which builds DP helpers into the kernel and KMS helpers sa a module. Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem. To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers cannot be selected directly by the user, config symbols should avoid depending on it anyway. Signed-off-by: Thomas Zimmermann Fixes: 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP") Acked-by: Sam Ravnborg Tested-by: Brian Masney Reported-by: kernel test robot Cc: Thomas Zimmermann Cc: Naresh Kamboju Cc: Linux Kernel Functional Testing Cc: Lyude Paul Cc: Sam Ravnborg Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: dri-devel@lists.freedesktop.org Cc: Dave Airlie Cc: Thierry Reding Link: https://patchwork.freedesktop.org/patch/478296/ Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/gpu/drm/bridge/Kconfig | 2 +- drivers/gpu/drm/panel/Kconfig | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 431b6e12a81f..68ec45abc1fb 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -8,7 +8,6 @@ config DRM_BRIDGE config DRM_PANEL_BRIDGE def_bool y depends on DRM_BRIDGE - depends on DRM_KMS_HELPER select DRM_PANEL help DRM bridge wrapper of DRM panels @@ -30,6 +29,7 @@ config DRM_CDNS_DSI config DRM_CHIPONE_ICN6211 tristate "Chipone ICN6211 MIPI-DSI/RGB Converter bridge" depends on OF + select DRM_KMS_HELPER select DRM_MIPI_DSI select DRM_PANEL_BRIDGE help diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index 0d3798354e6a..42011d884202 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -96,6 +96,7 @@ config DRM_PANEL_EDP select VIDEOMODE_HELPERS select DRM_DP_AUX_BUS select DRM_DP_HELPER + select DRM_KMS_HELPER help DRM panel driver for dumb eDP panels that need at most a regulator and a GPIO to be powered up. Optionally a backlight can be attached so --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4F4A1C43217 for ; Mon, 21 Mar 2022 14:22:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349737AbiCUOSz (ORCPT ); Mon, 21 Mar 2022 10:18:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349031AbiCUOG4 (ORCPT ); Mon, 21 Mar 2022 10:06:56 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4A72B6E58; Mon, 21 Mar 2022 07:02:05 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 78E94B816CE; Mon, 21 Mar 2022 14:02:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 569C0C340ED; Mon, 21 Mar 2022 14:02:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871323; bh=o9+D1OdqKcCLXQsIocAVqpLGD93PUevkaqmZLJxtPsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=136uKGzP878bjPkpYB+Nym1fZeG1ukqojMyl+ntSbV+2DkA6J8kiVtXLxP80V3rTr tiiwlG9eirFKCn6w1WLkVmF6otlV/bSX9xxnxLDGctqa+NvyBBKLygyj3kYoiJ39hN vgoXHvdwDfXqefoyUEHztC2k8dqQNuTQzi91AUgM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miaoqian Lin , Paolo Abeni , Sasha Levin Subject: [PATCH 5.16 21/37] net: dsa: Add missing of_node_put() in dsa_port_parse_of Date: Mon, 21 Mar 2022 14:53:03 +0100 Message-Id: <20220321133221.911185229@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Miaoqian Lin [ Upstream commit cb0b430b4e3acc88c85e0ad2e25f2a25a5765262 ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: 6d4e5c570c2d ("net: dsa: get port type at parse time") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220316082602.10785-1-linmq006@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- net/dsa/dsa2.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c index 7578b1350f18..e64ef196a984 100644 --- a/net/dsa/dsa2.c +++ b/net/dsa/dsa2.c @@ -1327,6 +1327,7 @@ static int dsa_port_parse_of(struct dsa_port *dp, str= uct device_node *dn) const char *user_protocol; =20 master =3D of_find_net_device_by_node(ethernet); + of_node_put(ethernet); if (!master) return -EPROBE_DEFER; =20 --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E264C433F5 for ; Mon, 21 Mar 2022 14:16:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240034AbiCUORj (ORCPT ); Mon, 21 Mar 2022 10:17:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349050AbiCUOHR (ORCPT ); Mon, 21 Mar 2022 10:07:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33108B716A; Mon, 21 Mar 2022 07:02:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 93028612DC; Mon, 21 Mar 2022 14:02:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9FE1DC340E8; Mon, 21 Mar 2022 14:02:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871326; bh=IAAFrUU8gQiQaC3sASTjgx3whxx7B6O72E6G9ckiAis=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kpbKgn5r8HpqSrKvLYiL3PK885mDp0zfaq1ps7bam9zlesqD1aZvjSDxVxc58jGei AyRrPGSVJ4nkfrzRuWSSDQq7+SMSwqj6j5M+fXm84q4etCnOLWVpv/sfqx6F/6/iic k8sFs1hYXHXUv9wQTg0fnrJawkzaLN6JsMSbQVi4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Juerg Haefliger , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 22/37] net: phy: mscc: Add MODULE_FIRMWARE macros Date: Mon, 21 Mar 2022 14:53:04 +0100 Message-Id: <20220321133221.939774567@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Juerg Haefliger [ Upstream commit f1858c277ba40172005b76a31e6bb931bfc19d9c ] The driver requires firmware so define MODULE_FIRMWARE so that modinfo provides the details. Fixes: fa164e40c53b ("net: phy: mscc: split the driver into separate files") Signed-off-by: Juerg Haefliger Link: https://lore.kernel.org/r/20220316151835.88765-1-juergh@canonical.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/phy/mscc/mscc_main.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/phy/mscc/mscc_main.c b/drivers/net/phy/mscc/mscc_m= ain.c index ebfeeb3c67c1..7e3017e7a1c0 100644 --- a/drivers/net/phy/mscc/mscc_main.c +++ b/drivers/net/phy/mscc/mscc_main.c @@ -2685,3 +2685,6 @@ MODULE_DEVICE_TABLE(mdio, vsc85xx_tbl); MODULE_DESCRIPTION("Microsemi VSC85xx PHY driver"); MODULE_AUTHOR("Nagaraju Lakkaraju"); MODULE_LICENSE("Dual MIT/GPL"); + +MODULE_FIRMWARE(MSCC_VSC8584_REVB_INT8051_FW); +MODULE_FIRMWARE(MSCC_VSC8574_REVB_INT8051_FW); --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3EEC8C4332F for ; Mon, 21 Mar 2022 14:22:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349718AbiCUOSt (ORCPT ); Mon, 21 Mar 2022 10:18:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349054AbiCUOHS (ORCPT ); Mon, 21 Mar 2022 10:07:18 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF2033D1C4; Mon, 21 Mar 2022 07:02:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 499A96125C; Mon, 21 Mar 2022 14:02:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59294C340E8; Mon, 21 Mar 2022 14:02:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871328; bh=bDBYpqSsEgzfk5gjSlyeH9wYNncdFV/M4wBhjRZVlDg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0efFpi+AGrd8/XNteX1CQxb6+4qotT4/cHAH1wMtCgrjm1HNm3lrr2u7KlFCn13Je TdmdLQxBS5LZxTZNWBELJ8yzR0D379E+JZd5I3Nu0qA9QGTX2EZfiQ2pD6L9jft7+D 0gi60LO6TXipLa6SY8Bd6BsmxfxeL8/Dlg5LNo4k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Paul Menzel , Manish Chopra , Ariel Elior , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 23/37] bnx2x: fix built-in kernel driver load failure Date: Mon, 21 Mar 2022 14:53:05 +0100 Message-Id: <20220321133221.968205925@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Manish Chopra [ Upstream commit 424e7834e293936a54fcf05173f2884171adc5a3 ] Commit b7a49f73059f ("bnx2x: Utilize firmware 7.13.21.0") added request_firmware() logic in probe() which caused load failure when firmware file is not present in initrd (below), as access to firmware file is not feasible during probe. Direct firmware load for bnx2x/bnx2x-e2-7.13.15.0.fw failed with error -2 Direct firmware load for bnx2x/bnx2x-e2-7.13.21.0.fw failed with error -2 This patch fixes this issue by - 1. Removing request_firmware() logic from the probe() such that .ndo_open() handle it as it used to handle it earlier 2. Given request_firmware() is removed from probe(), so driver has to relax FW version comparisons a bit against the already loaded FW version (by some other PFs of same adapter) to allow different compatible/close enough FWs with which multiple PFs may run with (in different environments), as the given PF who is in probe flow has no idea now with which firmware file version it is going to initialize the device in ndo_open() Link: https://lore.kernel.org/all/46f2d9d9-ae7f-b332-ddeb-b59802be2bab@molg= en.mpg.de/ Reported-by: Paul Menzel Tested-by: Paul Menzel Fixes: b7a49f73059f ("bnx2x: Utilize firmware 7.13.21.0") Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Link: https://lore.kernel.org/r/20220316214613.6884-1-manishc@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 2 -- .../net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 28 +++++++++++-------- .../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 15 ++-------- 3 files changed, 19 insertions(+), 26 deletions(-) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethe= rnet/broadcom/bnx2x/bnx2x.h index a19dd6797070..2209d99b3404 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h @@ -2533,6 +2533,4 @@ void bnx2x_register_phc(struct bnx2x *bp); * Meant for implicit re-load flows. */ int bnx2x_vlan_reconfigure_vid(struct bnx2x *bp); -int bnx2x_init_firmware(struct bnx2x *bp); -void bnx2x_release_firmware(struct bnx2x *bp); #endif /* bnx2x.h */ diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/= ethernet/broadcom/bnx2x/bnx2x_cmn.c index e57fe0034ce2..b1ad62774897 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c @@ -2363,24 +2363,30 @@ int bnx2x_compare_fw_ver(struct bnx2x *bp, u32 load= _code, bool print_err) /* is another pf loaded on this engine? */ if (load_code !=3D FW_MSG_CODE_DRV_LOAD_COMMON_CHIP && load_code !=3D FW_MSG_CODE_DRV_LOAD_COMMON) { - /* build my FW version dword */ - u32 my_fw =3D (bp->fw_major) + (bp->fw_minor << 8) + - (bp->fw_rev << 16) + (bp->fw_eng << 24); + u8 loaded_fw_major, loaded_fw_minor, loaded_fw_rev, loaded_fw_eng; + u32 loaded_fw; =20 /* read loaded FW from chip */ - u32 loaded_fw =3D REG_RD(bp, XSEM_REG_PRAM); + loaded_fw =3D REG_RD(bp, XSEM_REG_PRAM); =20 - DP(BNX2X_MSG_SP, "loaded fw %x, my fw %x\n", - loaded_fw, my_fw); + loaded_fw_major =3D loaded_fw & 0xff; + loaded_fw_minor =3D (loaded_fw >> 8) & 0xff; + loaded_fw_rev =3D (loaded_fw >> 16) & 0xff; + loaded_fw_eng =3D (loaded_fw >> 24) & 0xff; + + DP(BNX2X_MSG_SP, "loaded fw 0x%x major 0x%x minor 0x%x rev 0x%x eng 0x%x= \n", + loaded_fw, loaded_fw_major, loaded_fw_minor, loaded_fw_rev, loaded_fw= _eng); =20 /* abort nic load if version mismatch */ - if (my_fw !=3D loaded_fw) { + if (loaded_fw_major !=3D BCM_5710_FW_MAJOR_VERSION || + loaded_fw_minor !=3D BCM_5710_FW_MINOR_VERSION || + loaded_fw_eng !=3D BCM_5710_FW_ENGINEERING_VERSION || + loaded_fw_rev < BCM_5710_FW_REVISION_VERSION_V15) { if (print_err) - BNX2X_ERR("bnx2x with FW %x was already loaded which mismatches my %x = FW. Aborting\n", - loaded_fw, my_fw); + BNX2X_ERR("loaded FW incompatible. Aborting\n"); else - BNX2X_DEV_INFO("bnx2x with FW %x was already loaded which mismatches m= y %x FW, possibly due to MF UNDI\n", - loaded_fw, my_fw); + BNX2X_DEV_INFO("loaded FW incompatible, possibly due to MF UNDI\n"); + return -EBUSY; } } diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net= /ethernet/broadcom/bnx2x/bnx2x_main.c index 4ce596daeaae..569004c961d4 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -12319,15 +12319,6 @@ static int bnx2x_init_bp(struct bnx2x *bp) =20 bnx2x_read_fwinfo(bp); =20 - if (IS_PF(bp)) { - rc =3D bnx2x_init_firmware(bp); - - if (rc) { - bnx2x_free_mem_bp(bp); - return rc; - } - } - func =3D BP_FUNC(bp); =20 /* need to reset chip if undi was active */ @@ -12340,7 +12331,6 @@ static int bnx2x_init_bp(struct bnx2x *bp) =20 rc =3D bnx2x_prev_unload(bp); if (rc) { - bnx2x_release_firmware(bp); bnx2x_free_mem_bp(bp); return rc; } @@ -13420,7 +13410,7 @@ do { \ (u8 *)bp->arr, len); \ } while (0) =20 -int bnx2x_init_firmware(struct bnx2x *bp) +static int bnx2x_init_firmware(struct bnx2x *bp) { const char *fw_file_name, *fw_file_name_v15; struct bnx2x_fw_file_hdr *fw_hdr; @@ -13520,7 +13510,7 @@ int bnx2x_init_firmware(struct bnx2x *bp) return rc; } =20 -void bnx2x_release_firmware(struct bnx2x *bp) +static void bnx2x_release_firmware(struct bnx2x *bp) { kfree(bp->init_ops_offsets); kfree(bp->init_ops); @@ -14037,7 +14027,6 @@ static int bnx2x_init_one(struct pci_dev *pdev, return 0; =20 init_one_freemem: - bnx2x_release_firmware(bp); bnx2x_free_mem_bp(bp); =20 init_one_exit: --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2B0F3C433EF for ; Mon, 21 Mar 2022 14:22:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349698AbiCUOSl (ORCPT ); Mon, 21 Mar 2022 10:18:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348608AbiCUOHr (ORCPT ); Mon, 21 Mar 2022 10:07:47 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BF6B40A1C; Mon, 21 Mar 2022 07:02:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AB1BC61291; Mon, 21 Mar 2022 14:02:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B464CC340E8; Mon, 21 Mar 2022 14:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871334; bh=Rz97jaPjP8A5cEQQ+BaDGDxuBYyUviewzR5qgh6PjaQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QtoCLTtsShC0xZAVE11m7DZfay7sC4LDVfYKAPEz+5fiwKeRLnojNShyvsWHE5ULZ XpsVgLvTH65m/thLSz+rFx66ZjWlUlaCv1j2sTikguZ13UU0uEAuv5V1YUE5/yqtVT cLu+oUF7VvScBXyCgc36zjih7HgRmsqlLCHGzCbE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Doug Berger , Florian Fainelli , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 24/37] net: bcmgenet: skip invalid partial checksums Date: Mon, 21 Mar 2022 14:53:06 +0100 Message-Id: <20220321133221.996805822@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Doug Berger [ Upstream commit 0f643c88c8d240eba0ea25c2e095a46515ff46e9 ] The RXCHK block will return a partial checksum of 0 if it encounters a problem while receiving a packet. Since a 1's complement sum can only produce this result if no bits are set in the received data stream it is fair to treat it as an invalid partial checksum and not pass it up the stack. Fixes: 810155397890 ("net: bcmgenet: use CHECKSUM_COMPLETE for NETIF_F_RXCS= UM") Signed-off-by: Doug Berger Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20220317012812.1313196-1-opendmb@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/ethernet/broadcom/genet/bcmgenet.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/e= thernet/broadcom/genet/bcmgenet.c index 87f1056e29ff..2da804f84b48 100644 --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c @@ -2287,8 +2287,10 @@ static unsigned int bcmgenet_desc_rx(struct bcmgenet= _rx_ring *ring, dma_length_status =3D status->length_status; if (dev->features & NETIF_F_RXCSUM) { rx_csum =3D (__force __be16)(status->rx_csum & 0xffff); - skb->csum =3D (__force __wsum)ntohs(rx_csum); - skb->ip_summed =3D CHECKSUM_COMPLETE; + if (rx_csum) { + skb->csum =3D (__force __wsum)ntohs(rx_csum); + skb->ip_summed =3D CHECKSUM_COMPLETE; + } } =20 /* DMA flags and length are still valid no matter how --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45A09C433F5 for ; Mon, 21 Mar 2022 14:16:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349020AbiCUORc (ORCPT ); Mon, 21 Mar 2022 10:17:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349103AbiCUOHy (ORCPT ); Mon, 21 Mar 2022 10:07:54 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F062B41FB1; Mon, 21 Mar 2022 07:02:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6C777612DC; Mon, 21 Mar 2022 14:02:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 793D5C340E8; Mon, 21 Mar 2022 14:02:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871336; bh=8mRqTFjNVjmKjv5dCQ4bZtVtCi85jQvwxvTDpXOIhsQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LTAoZj8cRKkKG+jMn1Cgome32cp7f/wYN8uIgV8+KDHekJGcCoHsC/J2wqv1W28xs Y5dqyjfuJGODiuSRTOBEkWD4auJ6ViXUOMUH3MLPrCAbBS82fS//ZDhAKPT/RNkWWw wHNJ1fmcoZyWWbfhdMy6x606M7DbT9Xw7eHl018E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vladimir Oltean , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 25/37] net: mscc: ocelot: fix backwards compatibility with single-chain tc-flower offload Date: Mon, 21 Mar 2022 14:53:07 +0100 Message-Id: <20220321133222.025147482@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vladimir Oltean [ Upstream commit 8e0341aefcc9133f3f48683873284b169581315b ] ACL rules can be offloaded to VCAP IS2 either through chain 0, or, since the blamed commit, through a chain index whose number encodes a specific PAG (Policy Action Group) and lookup number. The chain number is translated through ocelot_chain_to_pag() into a PAG, and through ocelot_chain_to_lookup() into a lookup number. The problem with the blamed commit is that the above 2 functions don't have special treatment for chain 0. So ocelot_chain_to_pag(0) returns filter->pag =3D 224, which is in fact -32, but the "pag" field is an u8. So we end up programming the hardware with VCAP IS2 entries having a PAG of 224. But the way in which the PAG works is that it defines a subset of VCAP IS2 filters which should match on a packet. The default PAG is 0, and previous VCAP IS1 rules (which we offload using 'goto') can modify it. So basically, we are installing filters with a PAG on which no packet will ever match. This is the hardware equivalent of adding filters to a chain which has no 'goto' to it. Restore the previous functionality by making ACL filters offloaded to chain 0 go to PAG 0 and lookup number 0. The choice of PAG is clearly correct, but the choice of lookup number isn't "as before" (which was to leave the lookup a "don't care"). However, lookup 0 should be fine, since even though there are ACL actions (policers) which have a requirement to be used in a specific lookup, that lookup is 0. Fixes: 226e9cd82a96 ("net: mscc: ocelot: only install TCAM entries into a s= pecific lookup and PAG") Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20220316192117.2568261-1-vladimir.oltean@nx= p.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/ethernet/mscc/ocelot_flower.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mscc/ocelot_flower.c b/drivers/net/ethern= et/mscc/ocelot_flower.c index 738dd2be79dc..a3f1f1fbaf7d 100644 --- a/drivers/net/ethernet/mscc/ocelot_flower.c +++ b/drivers/net/ethernet/mscc/ocelot_flower.c @@ -54,6 +54,12 @@ static int ocelot_chain_to_block(int chain, bool ingress) */ static int ocelot_chain_to_lookup(int chain) { + /* Backwards compatibility with older, single-chain tc-flower + * offload support in Ocelot + */ + if (chain =3D=3D 0) + return 0; + return (chain / VCAP_LOOKUP) % 10; } =20 @@ -62,7 +68,15 @@ static int ocelot_chain_to_lookup(int chain) */ static int ocelot_chain_to_pag(int chain) { - int lookup =3D ocelot_chain_to_lookup(chain); + int lookup; + + /* Backwards compatibility with older, single-chain tc-flower + * offload support in Ocelot + */ + if (chain =3D=3D 0) + return 0; + + lookup =3D ocelot_chain_to_lookup(chain); =20 /* calculate PAG value as chain index relative to the first PAG */ return chain - VCAP_IS2_CHAIN(lookup, 0); --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 87A82C433EF for ; Mon, 21 Mar 2022 14:15:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349328AbiCUORN (ORCPT ); Mon, 21 Mar 2022 10:17:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349127AbiCUOH7 (ORCPT ); Mon, 21 Mar 2022 10:07:59 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D00FBABA0; Mon, 21 Mar 2022 07:02:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D93CBB816D8; Mon, 21 Mar 2022 14:02:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D682C340E8; Mon, 21 Mar 2022 14:02:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871339; bh=mACa8COPULaNZ07gn9hi7zqcmn7LS4lQkg33Nv0VA6Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TtIXY0iVSxYyWtnwih5jaQ3rAf2sV3u8seE5uXCKn4oR7aGW3bqNf1AdU2X6sEbZF eYJA7mT4ivCFgF7J7kJdXqSx0YqzVcgNLP5oS1X43sou4SYFtWXi05qezW1tfb4gRM gqsJGSgjrjWAe73ChDtIShu9vYJg9dHorP0eTwhI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ivan Vecera , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.16 26/37] iavf: Fix hang during reboot/shutdown Date: Mon, 21 Mar 2022 14:53:08 +0100 Message-Id: <20220321133222.053422632@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Ivan Vecera [ Upstream commit b04683ff8f0823b869c219c78ba0d974bddea0b5 ] Recent commit 974578017fc1 ("iavf: Add waiting so the port is initialized in remove") adds a wait-loop at the beginning of iavf_remove() to ensure that port initialization is finished prior unregistering net device. This causes a regression in reboot/shutdown scenario because in this case callback iavf_shutdown() is called and this callback detaches the device, makes it down if it is running and sets its state to __IAVF_REMOVE. Later shutdown callback of associated PF driver (e.g. ice_shutdown) is called. That callback calls among other things sriov_disable() that calls indirectly iavf_remove() (see stack trace below). As the adapter state is already __IAVF_REMOVE then the mentioned loop is end-less and shutdown process hangs. The patch fixes this by checking adapter's state at the beginning of iavf_remove() and skips the rest of the function if the adapter is already in remove state (shutdown is in progress). Reproducer: 1. Create VF on PF driven by ice or i40e driver 2. Ensure that the VF is bound to iavf driver 3. Reboot [52625.981294] sysrq: SysRq : Show Blocked State [52625.988377] task:reboot state:D stack: 0 pid:17359 ppid: = 1 f2 [52625.996732] Call Trace: [52625.999187] __schedule+0x2d1/0x830 [52626.007400] schedule+0x35/0xa0 [52626.010545] schedule_hrtimeout_range_clock+0x83/0x100 [52626.020046] usleep_range+0x5b/0x80 [52626.023540] iavf_remove+0x63/0x5b0 [iavf] [52626.027645] pci_device_remove+0x3b/0xc0 [52626.031572] device_release_driver_internal+0x103/0x1f0 [52626.036805] pci_stop_bus_device+0x72/0xa0 [52626.040904] pci_stop_and_remove_bus_device+0xe/0x20 [52626.045870] pci_iov_remove_virtfn+0xba/0x120 [52626.050232] sriov_disable+0x2f/0xe0 [52626.053813] ice_free_vfs+0x7c/0x340 [ice] [52626.057946] ice_remove+0x220/0x240 [ice] [52626.061967] ice_shutdown+0x16/0x50 [ice] [52626.065987] pci_device_shutdown+0x34/0x60 [52626.070086] device_shutdown+0x165/0x1c5 [52626.074011] kernel_restart+0xe/0x30 [52626.077593] __do_sys_reboot+0x1d2/0x210 [52626.093815] do_syscall_64+0x5b/0x1a0 [52626.097483] entry_SYSCALL_64_after_hwframe+0x65/0xca Fixes: 974578017fc1 ("iavf: Add waiting so the port is initialized in remov= e") Signed-off-by: Ivan Vecera Link: https://lore.kernel.org/r/20220317104524.2802848-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/ethernet/intel/iavf/iavf_main.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethe= rnet/intel/iavf/iavf_main.c index f2ce30366484..42e6675078cd 100644 --- a/drivers/net/ethernet/intel/iavf/iavf_main.c +++ b/drivers/net/ethernet/intel/iavf/iavf_main.c @@ -4028,6 +4028,13 @@ static void iavf_remove(struct pci_dev *pdev) struct iavf_hw *hw =3D &adapter->hw; int err; =20 + /* When reboot/shutdown is in progress no need to do anything + * as the adapter is already REMOVE state that was set during + * iavf_shutdown() callback. + */ + if (adapter->state =3D=3D __IAVF_REMOVE) + return; + set_bit(__IAVF_IN_REMOVE_TASK, &adapter->crit_section); /* Wait until port initialization is complete. * There are flows where register/unregister netdev may race. --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 617B3C433EF for ; Mon, 21 Mar 2022 14:15:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349340AbiCUORW (ORCPT ); Mon, 21 Mar 2022 10:17:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349133AbiCUOH7 (ORCPT ); Mon, 21 Mar 2022 10:07:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A1EEB82E2; Mon, 21 Mar 2022 07:02:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CAF9C613DC; Mon, 21 Mar 2022 14:02:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA88DC36AF8; Mon, 21 Mar 2022 14:02:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871342; bh=jbi74pirWmIJryKTHRKMdiKZsXWXK+wLnFhWCEPB59E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kCtxcd4E+HPh6F/q2SF+BxZzu/+uHcYcpNYeVYRbK0RifoYavudVetuuCKSHZnhgw 6zrip9v579L49ogL12/aFzbIsi4/saWwiH2Dt254ei8zJvIJYnKPezuNvcnBPDuqbd pKHume0eQjmtLW5sz+btKSLZIfOyfplx0Jry36BM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , James Morse , Catalin Marinas , Sasha Levin Subject: [PATCH 5.16 27/37] arm64: fix clang warning about TRAMP_VALIAS Date: Mon, 21 Mar 2022 14:53:09 +0100 Message-Id: <20220321133222.081671071@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit 7f34b43e07cb512b28543fdcb9f35d1fbfda9ebc ] The newly introduced TRAMP_VALIAS definition causes a build warning with clang-14: arch/arm64/include/asm/vectors.h:66:31: error: arithmetic on a null pointer= treated as a cast from integer to pointer is a GNU extension [-Werror,-Wnu= ll-pointer-arithmetic] return (char *)TRAMP_VALIAS + SZ_2K * slot; Change the addition to something clang does not complain about. Fixes: bd09128d16fa ("arm64: Add percpu vectors for EL1") Signed-off-by: Arnd Bergmann Acked-by: James Morse Link: https://lore.kernel.org/r/20220316183833.1563139-1-arnd@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- arch/arm64/include/asm/vectors.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/vectors.h b/arch/arm64/include/asm/vect= ors.h index f64613a96d53..bc9a2145f419 100644 --- a/arch/arm64/include/asm/vectors.h +++ b/arch/arm64/include/asm/vectors.h @@ -56,14 +56,14 @@ enum arm64_bp_harden_el1_vectors { DECLARE_PER_CPU_READ_MOSTLY(const char *, this_cpu_vector); =20 #ifndef CONFIG_UNMAP_KERNEL_AT_EL0 -#define TRAMP_VALIAS 0 +#define TRAMP_VALIAS 0ul #endif =20 static inline const char * arm64_get_bp_hardening_vector(enum arm64_bp_harden_el1_vectors slot) { if (arm64_kernel_unmapped_at_el0()) - return (char *)TRAMP_VALIAS + SZ_2K * slot; + return (char *)(TRAMP_VALIAS + SZ_2K * slot); =20 WARN_ON_ONCE(slot =3D=3D EL1_VECTOR_KPTI); =20 --=20 2.34.1 From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7A04C433EF for ; Mon, 21 Mar 2022 14:15:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238651AbiCUORR (ORCPT ); Mon, 21 Mar 2022 10:17:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349134AbiCUOH7 (ORCPT ); Mon, 21 Mar 2022 10:07:59 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 147DBC12DC; Mon, 21 Mar 2022 07:02:26 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 70D38613F5; Mon, 21 Mar 2022 14:02:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86FAAC36AE3; Mon, 21 Mar 2022 14:02:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871344; bh=JBwT2FpWuW+DXrzrhNxMCQ2pX1GZUCBphhPILV5OTbU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=w12dDXJsShb4DQn2QFtgl1JjnEa5Ba8sr6oeGJQij7eH2VClaUrkOQosZH5yrM3+f i+PefE/0hMshOGAkaCRjmzKnnjgUCU10kfd9ogyBFoTecZQSkWTwv4fnQz3rvbH1Os p2y1vylMVx/hTPey4uEbpLr4qLeglsChThJ4kKdY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Dan Carpenter Subject: [PATCH 5.16 28/37] usb: gadget: rndis: prevent integer overflow in rndis_set_response() Date: Mon, 21 Mar 2022 14:53:10 +0100 Message-Id: <20220321133222.109841423@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Dan Carpenter commit 65f3324f4b6fed78b8761c3b74615ecf0ffa81fa upstream. If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow. Cc: stable@kernel.org Fixes: 38ea1eac7d88 ("usb: gadget: rndis: check size of RNDIS_MSG_SET comma= nd") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20220301080424.GA17208@kili Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/usb/gadget/function/rndis.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/function/rndis.c +++ b/drivers/usb/gadget/function/rndis.c @@ -640,6 +640,7 @@ static int rndis_set_response(struct rnd BufLength =3D le32_to_cpu(buf->InformationBufferLength); BufOffset =3D le32_to_cpu(buf->InformationBufferOffset); if ((BufLength > RNDIS_MAX_TOTAL_SIZE) || + (BufOffset > RNDIS_MAX_TOTAL_SIZE) || (BufOffset + 8 >=3D RNDIS_MAX_TOTAL_SIZE)) return -EINVAL; From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED722C433F5 for ; Mon, 21 Mar 2022 14:22:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349659AbiCUOSa (ORCPT ); Mon, 21 Mar 2022 10:18:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349160AbiCUOIA (ORCPT ); Mon, 21 Mar 2022 10:08:00 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D927616F6E0; Mon, 21 Mar 2022 07:02:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 515956132C; Mon, 21 Mar 2022 14:02:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63ECBC340ED; Mon, 21 Mar 2022 14:02:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871347; bh=ODkaVcy06AKxQMIunHXBF+jcKN3OsNsFosFEWMc/nGI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Hq7D8dpmF+w+5ArEAqBbZdvUJHc6QKmq9wsJAL0T8mkOyZhFsZfBuzkf9hLl7NMPt utjyKsNc9EJVY8mUDmBBnHtdFcEJgp4pqmrKnYrJ0wyXoBVVs22RGISaO1ZKGfKEjJ XNceg1BpsXTr/iszJTVP/duo8O/0MDLsH9ooVy3c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , syzbot+348b571beb5eeb70a582@syzkaller.appspotmail.com Subject: [PATCH 5.16 29/37] usb: gadget: Fix use-after-free bug by not setting udc->dev.driver Date: Mon, 21 Mar 2022 14:53:11 +0100 Message-Id: <20220321133222.138112233@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Alan Stern commit 16b1941eac2bd499f065a6739a40ce0011a3d740 upstream. The syzbot fuzzer found a use-after-free bug: BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:23= 20 Read of size 8 at addr ffff88802b934098 by task udevd/3689 CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b7= 42eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094 Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does: if (dev->driver) add_uevent_var(env, "DRIVER=3D%s", dev->driver->name); and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL. The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL. In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC. This patch simply removes the statements in the gadget core that touch udc->dev.driver. Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class") CC: Reported-and-tested-by: syzbot+348b571beb5eeb70a582@syzkaller.appspotmail.c= om Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/YiQgukfFFbBnwJ/9@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/usb/gadget/udc/core.c | 3 --- 1 file changed, 3 deletions(-) --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -1436,7 +1436,6 @@ static void usb_gadget_remove_driver(str usb_gadget_udc_stop(udc); =20 udc->driver =3D NULL; - udc->dev.driver =3D NULL; udc->gadget->dev.driver =3D NULL; } =20 @@ -1498,7 +1497,6 @@ static int udc_bind_to_driver(struct usb driver->function); =20 udc->driver =3D driver; - udc->dev.driver =3D &driver->driver; udc->gadget->dev.driver =3D &driver->driver; =20 usb_gadget_udc_set_speed(udc, driver->max_speed); @@ -1521,7 +1519,6 @@ err1: dev_err(&udc->dev, "failed to start %s: %d\n", udc->driver->function, ret); udc->driver =3D NULL; - udc->dev.driver =3D NULL; udc->gadget->dev.driver =3D NULL; return ret; } From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5B93EC433F5 for ; Mon, 21 Mar 2022 14:13:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238166AbiCUOPQ (ORCPT ); Mon, 21 Mar 2022 10:15:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349243AbiCUOIF (ORCPT ); Mon, 21 Mar 2022 10:08:05 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2AA52174B8B; Mon, 21 Mar 2022 07:02:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9A429B816DC; Mon, 21 Mar 2022 14:02:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FB63C340E8; Mon, 21 Mar 2022 14:02:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871350; bh=pApDzt38GhzWwzmU3F/B28vg6zW1m34oDcityxP6B0g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NHEVxCRZcwIQoxfxM+Z/Mtmysrk/hBeQcm17luwUFxwhFSrufojorKRx+HsHl8eTi Nseh6SSait8QlN6s5Z0rsDS75YhfhWGwjfn3kIYnkkXjf/5j/5WRheZO69lJ4qEawL WIlnJkJ8fZH1J1jrJynVKCXm/wYgA9LE3G2YVyto= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , syzbot+a48e3d1a875240cab5de@syzkaller.appspotmail.com Subject: [PATCH 5.16 30/37] usb: usbtmc: Fix bug in pipe direction for control transfers Date: Mon, 21 Mar 2022 14:53:12 +0100 Message-Id: <20220321133222.166033255@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Alan Stern commit e9b667a82cdcfe21d590344447d65daed52b353b upstream. The syzbot fuzzer reported a minor bug in the usbtmc driver: usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0 WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Call Trace: usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline] The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for all of its transfers, whether they are in or out. It's easy to fix. CC: Reported-and-tested-by: syzbot+a48e3d1a875240cab5de@syzkaller.appspotmail.c= om Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/YiEsYTPEE6lOCOA5@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/usb/class/usbtmc.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) --- a/drivers/usb/class/usbtmc.c +++ b/drivers/usb/class/usbtmc.c @@ -1919,6 +1919,7 @@ static int usbtmc_ioctl_request(struct u struct usbtmc_ctrlrequest request; u8 *buffer =3D NULL; int rv; + unsigned int is_in, pipe; unsigned long res; =20 res =3D copy_from_user(&request, arg, sizeof(struct usbtmc_ctrlrequest)); @@ -1928,12 +1929,14 @@ static int usbtmc_ioctl_request(struct u if (request.req.wLength > USBTMC_BUFSIZE) return -EMSGSIZE; =20 + is_in =3D request.req.bRequestType & USB_DIR_IN; + if (request.req.wLength) { buffer =3D kmalloc(request.req.wLength, GFP_KERNEL); if (!buffer) return -ENOMEM; =20 - if ((request.req.bRequestType & USB_DIR_IN) =3D=3D 0) { + if (!is_in) { /* Send control data to device */ res =3D copy_from_user(buffer, request.data, request.req.wLength); @@ -1944,8 +1947,12 @@ static int usbtmc_ioctl_request(struct u } } =20 + if (is_in) + pipe =3D usb_rcvctrlpipe(data->usb_dev, 0); + else + pipe =3D usb_sndctrlpipe(data->usb_dev, 0); rv =3D usb_control_msg(data->usb_dev, - usb_rcvctrlpipe(data->usb_dev, 0), + pipe, request.req.bRequest, request.req.bRequestType, request.req.wValue, @@ -1957,7 +1964,7 @@ static int usbtmc_ioctl_request(struct u goto exit; } =20 - if (rv && (request.req.bRequestType & USB_DIR_IN)) { + if (rv && is_in) { /* Read control data from device */ res =3D copy_to_user(request.data, buffer, rv); if (res) From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79191C433EF for ; Mon, 21 Mar 2022 14:13:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349155AbiCUOOr (ORCPT ); Mon, 21 Mar 2022 10:14:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349231AbiCUOIE (ORCPT ); Mon, 21 Mar 2022 10:08:04 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 69D55174BB9; Mon, 21 Mar 2022 07:02:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id C3D356132C; Mon, 21 Mar 2022 14:02:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD94DC36AE9; Mon, 21 Mar 2022 14:02:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871353; bh=LEJPk0D57qEDTsqgXvDFEqHl7IO/xSoeV6j5WPkO2Eo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=zungZ22ah1s6p5uXgZS1NRz3Por7kWie+OqgsqBq2UfryTGl3DMUll0zvVftSLrSa NIQlsEIIbMmrEGSvkQvA/5jWdb/bRqQkHVPId2sJSY0OOru6NXezBdj0W4Mf40AcUU dn4cM0MbC+F5g9PkSNXPwJ+c72BXXWX2jafGSbRY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sreekanth Reddy , Matt Lupfer , "Martin K. Petersen" Subject: [PATCH 5.16 31/37] scsi: mpt3sas: Page fault in reply q processing Date: Mon, 21 Mar 2022 14:53:13 +0100 Message-Id: <20220321133222.194425394@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Matt Lupfer commit 69ad4ef868c1fc7609daa235dfa46d28ba7a3ba3 upstream. A page fault was encountered in mpt3sas on a LUN reset error path: [ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30= ) tr_method(0x0) smid(3) msix_index(0) [ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2) [ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29= a2) [ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 f= f fc 00 [ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b00002= 72b9), phy(0) [ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), = slot(0) [ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of s= mid(0), task_type(0x05), handle(0x0002) [ 149.875202] BUG: unable to handle page fault for address: 00000007fffc44= 5d [ 149.885617] #PF: supervisor read access in kernel mode [ 149.894346] #PF: error_code(0x0000) - not-present page [ 149.903123] PGD 0 P4D 0 [ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S= O 5.10.89-altav-1 #1 [ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB= , BIOS ATHG2.2.02.01 09/10/2021 [ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas] [ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f = b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 <0f= > b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee [ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246 [ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 00000000254= 8f071 [ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125e= d50d8 [ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000fff= f7fff [ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 00000000000= 00000 [ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034c= dea80 [ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:= 0000000000000000 [ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 00000000007= 70ee0 [ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000= 00400 [ 150.108323] PKRU: 55555554 [ 150.114690] Call Trace: [ 150.120497] ? printk+0x48/0x4a [ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas] [ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas] [ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas] [ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod] [ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod] [ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60 [ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod] [ 150.203206] ? __schedule+0x1e9/0x610 [ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod] [ 150.217924] kthread+0x12e/0x150 [ 150.224041] ? kthread_worker_fn+0x130/0x130 [ 150.231206] ret_from_fork+0x1f/0x30 This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q pointer outside of the list_for_each_entry() loop. At the end of the full list traversal the pointer is invalid. Move the _base_process_reply_queue() call inside of the loop. Link: https://lore.kernel.org/r/d625deae-a958-0ace-2ba3-0888dd0a415b@ddn.com Fixes: 711a923c14d9 ("scsi: mpt3sas: Postprocessing of target and LUN reset= ") Cc: stable@vger.kernel.org Acked-by: Sreekanth Reddy Signed-off-by: Matt Lupfer Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/scsi/mpt3sas/mpt3sas_base.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/scsi/mpt3sas/mpt3sas_base.c +++ b/drivers/scsi/mpt3sas/mpt3sas_base.c @@ -2011,9 +2011,10 @@ mpt3sas_base_sync_reply_irqs(struct MPT3 enable_irq(reply_q->os_irq); } } + + if (poll) + _base_process_reply_queue(reply_q); } - if (poll) - _base_process_reply_queue(reply_q); } =20 /** From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 597DAC433FE for ; Mon, 21 Mar 2022 14:13:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347611AbiCUOPC (ORCPT ); Mon, 21 Mar 2022 10:15:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38184 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349251AbiCUOIG (ORCPT ); Mon, 21 Mar 2022 10:08:06 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C4BB176D3A; Mon, 21 Mar 2022 07:02:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 78E246134A; Mon, 21 Mar 2022 14:02:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8790EC340E8; Mon, 21 Mar 2022 14:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871355; bh=ZaI+z8jCsQjDVirhHnBpi8JKgIL/KUzOPVBzH8tgTL4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H31CvJYjyvaQDvGlu7RPOxme74SdnKtRBw7lcUlFdu9tgRxYOXiwkpz7ojQmHnih9 67s6JCqasKTGK0s7X+Hq+sBF0X57Gr8nr16KVl6v7y6ltY6frOtu/AEX6RINypSlUy Sesnu7aj/Btbgjt9m1GcB6czGfSlI7Y+lf0AdNj4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Skripkin , Dmitry Torokhov , syzbot+75cccf2b7da87fb6f84b@syzkaller.appspotmail.com Subject: [PATCH 5.16 32/37] Input: aiptek - properly check endpoint type Date: Mon, 21 Mar 2022 14:53:14 +0100 Message-Id: <20220321133222.222194278@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pavel Skripkin commit 5600f6986628dde8881734090588474f54a540a8 upstream. Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint. Fix it by replacing old desc.bNumEndpoints check with usb_find_common_endpoints() helper for finding endpoints Fail log: usb 5-1: BOGUS urb xfer, pipe 1 !=3D type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/= 0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07= ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usb_hub_wq hub_event ... Call Trace: aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593 Fixes: 8e20cf2bce12 ("Input: aiptek - fix crash on detecting device without= endpoints") Reported-and-tested-by: syzbot+75cccf2b7da87fb6f84b@syzkaller.appspotmail.c= om Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/20220308194328.26220-1-paskripkin@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/input/tablet/aiptek.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) --- a/drivers/input/tablet/aiptek.c +++ b/drivers/input/tablet/aiptek.c @@ -1787,15 +1787,13 @@ aiptek_probe(struct usb_interface *intf, input_set_abs_params(inputdev, ABS_TILT_Y, AIPTEK_TILT_MIN, AIPTEK_TILT_M= AX, 0, 0); input_set_abs_params(inputdev, ABS_WHEEL, AIPTEK_WHEEL_MIN, AIPTEK_WHEEL_= MAX - 1, 0, 0); =20 - /* Verify that a device really has an endpoint */ - if (intf->cur_altsetting->desc.bNumEndpoints < 1) { + err =3D usb_find_common_endpoints(intf->cur_altsetting, + NULL, NULL, &endpoint, NULL); + if (err) { dev_err(&intf->dev, - "interface has %d endpoints, but must have minimum 1\n", - intf->cur_altsetting->desc.bNumEndpoints); - err =3D -EINVAL; + "interface has no int in endpoints, but must have minimum 1\n"); goto fail3; } - endpoint =3D &intf->cur_altsetting->endpoint[0].desc; =20 /* Go set up our URB, which is called when the tablet receives * input. From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 142C1C433FE for ; Mon, 21 Mar 2022 14:22:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349676AbiCUOSd (ORCPT ); Mon, 21 Mar 2022 10:18:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349315AbiCUOIJ (ORCPT ); Mon, 21 Mar 2022 10:08:09 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9016DBA33B; Mon, 21 Mar 2022 07:02:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2EF3C613F8; Mon, 21 Mar 2022 14:02:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3F339C340F8; Mon, 21 Mar 2022 14:02:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871358; bh=3912HSmqwhPBzrDap/K435w0ZNs81iLW6RVwmA+o/bQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Rb5ALAYbStDAOsOiHoNDpWg2UisPTxZDAC34OfVxJKw2/StARplIULkp36vvKdaCD xTE89sy5vm1CksfiJ97i9VNGvCP09YaHz0q9vS0vSQr/sBEe9Ztrd/YckjkR7nwNCV iCEOdnfR5udbYv4JMxksFqtDKSI/5kbRjLny3erM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arnd Bergmann , Catalin Marinas Subject: [PATCH 5.16 33/37] arm64: errata: avoid duplicate field initializer Date: Mon, 21 Mar 2022 14:53:15 +0100 Message-Id: <20220321133222.250460578@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann commit 316e46f65a5497839857db08b6fbf60f568b165a upstream. The '.type' field is initialized both in place and in the macro as reported by this W=3D1 warning: arch/arm64/include/asm/cpufeature.h:281:9: error: initialized field overwri= tten [-Werror=3Doverride-init] 281 | (ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_L= ATE_CPU) | ^ arch/arm64/kernel/cpu_errata.c:136:17: note: in expansion of macro 'ARM64_C= PUCAP_LOCAL_CPU_ERRATUM' 136 | .type =3D ARM64_CPUCAP_LOCAL_CPU_ERRATUM, = \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/cpu_errata.c:145:9: note: in expansion of macro 'ERRATA_M= IDR_RANGE' 145 | ERRATA_MIDR_RANGE(m, var, r_min, var, r_max) | ^~~~~~~~~~~~~~~~~ arch/arm64/kernel/cpu_errata.c:613:17: note: in expansion of macro 'ERRATA_= MIDR_REV_RANGE' 613 | ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2), | ^~~~~~~~~~~~~~~~~~~~~ arch/arm64/include/asm/cpufeature.h:281:9: note: (near initialization for '= arm64_errata[18].type') 281 | (ARM64_CPUCAP_SCOPE_LOCAL_CPU | ARM64_CPUCAP_OPTIONAL_FOR_L= ATE_CPU) | ^ Remove the extranous initializer. Signed-off-by: Arnd Bergmann Fixes: 1dd498e5e26a ("KVM: arm64: Workaround Cortex-A510's single-step and = PAC trap errata") Link: https://lore.kernel.org/r/20220316183800.1546731-1-arnd@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- arch/arm64/kernel/cpu_errata.c | 1 - 1 file changed, 1 deletion(-) --- a/arch/arm64/kernel/cpu_errata.c +++ b/arch/arm64/kernel/cpu_errata.c @@ -611,7 +611,6 @@ const struct arm64_cpu_capabilities arm6 { .desc =3D "ARM erratum 2077057", .capability =3D ARM64_WORKAROUND_2077057, - .type =3D ARM64_CPUCAP_LOCAL_CPU_ERRATUM, ERRATA_MIDR_REV_RANGE(MIDR_CORTEX_A510, 0, 0, 2), }, #endif From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D6D86C433F5 for ; Mon, 21 Mar 2022 14:22:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349630AbiCUOSY (ORCPT ); Mon, 21 Mar 2022 10:18:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349373AbiCUOIM (ORCPT ); Mon, 21 Mar 2022 10:08:12 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47170179429; Mon, 21 Mar 2022 07:02:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CA23B613CA; Mon, 21 Mar 2022 14:02:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2F60C340F2; Mon, 21 Mar 2022 14:02:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871364; bh=tj33CDVipt3Hwcf7gdEjoaIZbWPVmkUS+u0jcdrdLGM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eqdkokWqqr3sQZ06pD5Lo4Sadl2aioTGPBEhllPeS1s2audRB0JEbzL6xAiLosHte XOaoymMLBfMGdppmiuksJVi1QoTVST6upJN6ZzHx/RJHS7fhvbFGPtwy6PjRZ7Twjt iJfB9gawIOyCTX2EsqapLMq/5t0UDf+Hlzqho3X8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Michael Petlan , Athira Jajeev , Jiri Olsa , Kajol Jain , Madhavan Srinivasan , Arnaldo Carvalho de Melo Subject: [PATCH 5.16 34/37] perf symbols: Fix symbol size calculation condition Date: Mon, 21 Mar 2022 14:53:16 +0100 Message-Id: <20220321133222.278291921@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Michael Petlan commit 3cf6a32f3f2a45944dd5be5c6ac4deb46bcd3bee upstream. Before this patch, the symbol end address fixup to be called, needed two conditions being met: if (prev->end =3D=3D prev->start && prev->end !=3D curr->start) Where "prev->end =3D=3D prev->start" means that prev is zero-long (and thus needs a fixup) and "prev->end !=3D curr->start" means that fixup hasn't been applied yet However, this logic is incorrect in the following situation: *curr =3D {rb_node =3D {__rb_parent_color =3D 278218928, rb_right =3D 0x0, rb_left =3D 0x0}, start =3D 0xc000000000062354, end =3D 0xc000000000062354, namelen =3D 40, type =3D 2 '\002', binding =3D 0 '\000', idle =3D 0 '\000', ignore =3D 0 '\000', inlined =3D 0 '\000', arch_sym =3D 0 '\000', annotate2 =3D false, name =3D 0x1159739e "kprobe_optinsn_page\t[__builtin__kprobes]"} *prev =3D {rb_node =3D {__rb_parent_color =3D 278219041, rb_right =3D 0x109548b0, rb_left =3D 0x109547c0}, start =3D 0xc000000000062354, end =3D 0xc000000000062354, namelen =3D 12, type =3D 2 '\002', binding =3D 1 '\001', idle =3D 0 '\000', ignore =3D 0 '\000', inlined =3D 0 '\000', arch_sym =3D 0 '\000', annotate2 =3D false, name =3D 0x1095486e "optinsn_slot"} In this case, prev->start =3D=3D prev->end =3D=3D curr->start =3D=3D curr->= end, thus the condition above thinks that "we need a fixup due to zero length of prev symbol, but it has been probably done, since the prev->end =3D=3D curr->start", which is wrong. After the patch, the execution path proceeds to arch__symbols__fixup_end function which fixes up the size of prev symbol by adding page_size to its end offset. Fixes: 3b01a413c196c910 ("perf symbols: Improve kallsyms symbol end addr ca= lculation") Signed-off-by: Michael Petlan Cc: Athira Jajeev Cc: Jiri Olsa Cc: Kajol Jain Cc: Madhavan Srinivasan Link: http://lore.kernel.org/lkml/20220317135536.805-1-mpetlan@redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- tools/perf/util/symbol.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/perf/util/symbol.c +++ b/tools/perf/util/symbol.c @@ -231,7 +231,7 @@ void symbols__fixup_end(struct rb_root_c prev =3D curr; curr =3D rb_entry(nd, struct symbol, rb_node); =20 - if (prev->end =3D=3D prev->start && prev->end !=3D curr->start) + if (prev->end =3D=3D prev->start || prev->end !=3D curr->start) arch__symbols__fixup_end(prev, curr); } From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D18FC433F5 for ; Mon, 21 Mar 2022 14:14:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348944AbiCUOPZ (ORCPT ); Mon, 21 Mar 2022 10:15:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349452AbiCUOIZ (ORCPT ); Mon, 21 Mar 2022 10:08:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6FDC17A598; Mon, 21 Mar 2022 07:02:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 77F9B6132C; Mon, 21 Mar 2022 14:02:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B96AC340E8; Mon, 21 Mar 2022 14:02:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871366; bh=qf/4IqoCH15v/gP5BPbKxETcCxWbZ+FrQYit2rRSzY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T8BkqavWrskOaPUh5+adm55CKpvVIjQLw87q6k3z4Oy0+92iB2gd88fSVLTk7lWMc nHbBiHiHm4Ir7P3dpw8rdTVLP6GBSCVt1SI0G6Xf8QIqOHb4gn+QXsLqLbt9x5b/2L c5x8Xjii30k8x8jnoRPnA+hxyfeE5MeNSdnm/5v8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vladimir Oltean , Marc Zyngier , Arnd Bergmann Subject: [PATCH 5.16 35/37] Revert "arm64: dts: freescale: Fix interrupt-map parent address cells" Date: Mon, 21 Mar 2022 14:53:17 +0100 Message-Id: <20220321133222.305922095@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Vladimir Oltean commit 1447c635802fd0f5e213ad5277753108d56a4db3 upstream. This reverts commit 869f0ec048dc8fd88c0b2003373bd985795179fb. That updated the expected device tree binding format for the ls-extirq driver, without also updating the parsing code (ls_extirq_parse_map) to the new format. The context is that the ls-extirq driver uses the standard "interrupt-map" OF property in a non-standard way, as suggested by Rob Herring during review: https://lore.kernel.org/lkml/20190927161118.GA19333@bogus/ This has turned out to be problematic, as Marc Zyngier discovered through commit 041284181226 ("of/irq: Allow matching of an interrupt-map local to an interrupt controller"), later fixed through commit de4adddcbcc2 ("of/irq: Add a quirk for controllers with their own definition of interrupt-map"). Marc's position, expressed on multiple opportunities, is that: (a) [ making private use of the reserved "interrupt-map" name in a driver ] "is wrong, by the very letter of what an interrupt-map means. If the interrupt map points to an interrupt controller, that's the target for the interrupt." https://lore.kernel.org/lkml/87k0g8jlmg.wl-maz@kernel.org/ (b) [ updating the driver's bindings to accept a non-reserved name for this property, as an alternative, is ] "is totally pointless. These machines have been in the wild for years, and existing DTs will be there *forever*." https://lore.kernel.org/lkml/87ilvrk1r0.wl-maz@kernel.org/ Considering the above, the Linux kernel has quirks in place to deal with the ls-extirq's non-standard use of the "interrupt-map". These quirks may be needed in other operating systems that consume this device tree, yet this is seen as the only viable solution. Therefore, the premise of the patch being reverted here is invalid. It doesn't matter whether the driver, in its non-standard use of the property, complies to the standard format or not, since this property isn't expected to be used for interrupt translation by the core. This change restores LS1088A, LS2088A/LS2085A and LX2160A to their previous bindings, which allows these systems to continue to use external interrupt lines with the correct polarity. Fixes: 869f0ec048dc ("arm64: dts: freescale: Fix 'interrupt-map' parent add= ress cells") Signed-off-by: Vladimir Oltean Acked-by: Marc Zyngier Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 24 ++++++++++++--------= ---- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 24 ++++++++++++--------= ---- arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 24 ++++++++++++--------= ---- 3 files changed, 36 insertions(+), 36 deletions(-) --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi @@ -241,18 +241,18 @@ interrupt-controller; reg =3D <0x14 4>; interrupt-map =3D - <0 0 &gic 0 0 GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, - <1 0 &gic 0 0 GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, - <2 0 &gic 0 0 GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, - <3 0 &gic 0 0 GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, - <4 0 &gic 0 0 GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, - <5 0 &gic 0 0 GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, - <6 0 &gic 0 0 GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, - <7 0 &gic 0 0 GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, - <8 0 &gic 0 0 GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, - <9 0 &gic 0 0 GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, - <10 0 &gic 0 0 GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, - <11 0 &gic 0 0 GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; + <0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <8 0 &gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <9 0 &gic GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <10 0 &gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, + <11 0 &gic GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; interrupt-map-mask =3D <0xffffffff 0x0>; }; }; --- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi @@ -293,18 +293,18 @@ interrupt-controller; reg =3D <0x14 4>; interrupt-map =3D - <0 0 &gic 0 0 GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, - <1 0 &gic 0 0 GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, - <2 0 &gic 0 0 GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, - <3 0 &gic 0 0 GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, - <4 0 &gic 0 0 GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, - <5 0 &gic 0 0 GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, - <6 0 &gic 0 0 GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, - <7 0 &gic 0 0 GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, - <8 0 &gic 0 0 GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, - <9 0 &gic 0 0 GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, - <10 0 &gic 0 0 GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, - <11 0 &gic 0 0 GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; + <0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <8 0 &gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <9 0 &gic GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <10 0 &gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, + <11 0 &gic GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; interrupt-map-mask =3D <0xffffffff 0x0>; }; }; --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi @@ -680,18 +680,18 @@ interrupt-controller; reg =3D <0x14 4>; interrupt-map =3D - <0 0 &gic 0 0 GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, - <1 0 &gic 0 0 GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, - <2 0 &gic 0 0 GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, - <3 0 &gic 0 0 GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, - <4 0 &gic 0 0 GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, - <5 0 &gic 0 0 GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, - <6 0 &gic 0 0 GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, - <7 0 &gic 0 0 GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, - <8 0 &gic 0 0 GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, - <9 0 &gic 0 0 GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, - <10 0 &gic 0 0 GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, - <11 0 &gic 0 0 GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; + <0 0 &gic GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <1 0 &gic GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <2 0 &gic GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <3 0 &gic GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <4 0 &gic GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <5 0 &gic GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <6 0 &gic GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <7 0 &gic GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, + <8 0 &gic GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>, + <9 0 &gic GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH>, + <10 0 &gic GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>, + <11 0 &gic GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>; interrupt-map-mask =3D <0xffffffff 0x0>; }; }; From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56D60C43217 for ; Mon, 21 Mar 2022 14:22:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349543AbiCUOSI (ORCPT ); Mon, 21 Mar 2022 10:18:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37864 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349477AbiCUOI0 (ORCPT ); Mon, 21 Mar 2022 10:08:26 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B282546169; Mon, 21 Mar 2022 07:02:56 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E0420B816D7; Mon, 21 Mar 2022 14:02:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BBAAC340E8; Mon, 21 Mar 2022 14:02:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871369; bh=oxVeHmU6vXUXNj8ii8MS42qnjCRLISMiq/1Pu/HbLOU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=y+Q82zq41qiONYGp6esSJrDp3XsyJM92MHGVZgzoke7Pdm9lUTdASXWApehEOwYFa stihnK3mjB+1Xh3RmRPDdI5XKjjfYBx6DcfeE9PowOdewsLb+SgIYBaMTVdbhAlJOF OaIt/HhmM9e5NoB+mgR4TrWXu9AuqQR3Cn6/szsk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kalle Valo Subject: [PATCH 5.16 36/37] Revert "ath10k: drop beacon and probe response which leak from other channel" Date: Mon, 21 Mar 2022 14:53:18 +0100 Message-Id: <20220321133222.334723442@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Kalle Valo commit 45b4eb7ee6aa1a55a50831b328aa5f46ac3a7187 upstream. This reverts commit 3bf2537ec2e33310b431b53fd84be8833736c256. I was reported privately that this commit breaks AP and mesh mode on QCA9984 (firmware 10.4-3.9.0.2-00156). So revert the commit to fix the regression. There was a conflict due to cfg80211 API changes but that was easy to fix. Fixes: 3bf2537ec2e3 ("ath10k: drop beacon and probe response which leak fro= m other channel") Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220315155455.20446-1-kvalo@kernel.org Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- drivers/net/wireless/ath/ath10k/wmi.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-) --- a/drivers/net/wireless/ath/ath10k/wmi.c +++ b/drivers/net/wireless/ath/ath10k/wmi.c @@ -2611,30 +2611,9 @@ int ath10k_wmi_event_mgmt_rx(struct ath1 ath10k_mac_handle_beacon(ar, skb); =20 if (ieee80211_is_beacon(hdr->frame_control) || - ieee80211_is_probe_resp(hdr->frame_control)) { - struct ieee80211_mgmt *mgmt =3D (void *)skb->data; - u8 *ies; - int ies_ch; - + ieee80211_is_probe_resp(hdr->frame_control)) status->boottime_ns =3D ktime_get_boottime_ns(); =20 - if (!ar->scan_channel) - goto drop; - - ies =3D mgmt->u.beacon.variable; - - ies_ch =3D cfg80211_get_ies_channel_number(mgmt->u.beacon.variable, - skb_tail_pointer(skb) - ies, - sband->band); - - if (ies_ch > 0 && ies_ch !=3D channel) { - ath10k_dbg(ar, ATH10K_DBG_MGMT, - "channel mismatched ds channel %d scan channel %d\n", - ies_ch, channel); - goto drop; - } - } - ath10k_dbg(ar, ATH10K_DBG_MGMT, "event mgmt rx skb %pK len %d ftype %02x stype %02x\n", skb, skb->len, @@ -2648,10 +2627,6 @@ int ath10k_wmi_event_mgmt_rx(struct ath1 ieee80211_rx_ni(ar->hw, skb); =20 return 0; - -drop: - dev_kfree_skb(skb); - return 0; } =20 static int freq_to_idx(struct ath10k *ar, int freq) From nobody Mon Jun 22 15:38:39 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9F69FC433F5 for ; Mon, 21 Mar 2022 14:15:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349195AbiCUOQx (ORCPT ); Mon, 21 Mar 2022 10:16:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38464 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349511AbiCUOI1 (ORCPT ); Mon, 21 Mar 2022 10:08:27 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F8E846177; Mon, 21 Mar 2022 07:02:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3A52061331; Mon, 21 Mar 2022 14:02:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E4F6C340E8; Mon, 21 Mar 2022 14:02:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1647871372; bh=8M6kiTSMPh/VzwSpxOjYvSueTuAehvkBzzj388tLFUM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TI37EXYLYKeVCe4asbXHm0llCLe2PPtD00CvCK2zR/irBRO1/G5Fl2PHOHCmwIIYJ WUZAz1Tw98r5INmKgYwszTXVY3ueRVZDmJZaXahZkzEIxRlPG9yzskPscRcF0lrS6s ktF8tsC3haenLZN8zf4kG1cxnbDDETkexngMWDtI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , David Sterba , Anand Jain Subject: [PATCH 5.16 37/37] btrfs: skip reserved bytes warning on unmount after log cleanup failure Date: Mon, 21 Mar 2022 14:53:19 +0100 Message-Id: <20220321133222.362968532@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220321133221.290173884@linuxfoundation.org> References: <20220321133221.290173884@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Filipe Manana commit 40cdc509877bacb438213b83c7541c5e24a1d9ec upstream. After the recent changes made by commit c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it") and its followup fix, commit 651740a5024117 ("btrfs: check WRITE_ERR when trying to read an extent buffer"), we can now end up not cleaning up space reservations of log tree extent buffers after a transaction abort happens, as well as not cleaning up still dirty extent buffers. This happens because if writeback for a log tree extent buffer failed, then we have cleared the bit EXTENT_BUFFER_UPTODATE from the extent buffer and we have also set the bit EXTENT_BUFFER_WRITE_ERR on it. Later on, when trying to free the log tree with free_log_tree(), which iterates over the tree, we can end up getting an -EIO error when trying to read a node or a leaf, since read_extent_buffer_pages() returns -EIO if an extent buffer does not have EXTENT_BUFFER_UPTODATE set and has the EXTENT_BUFFER_WRITE_ERR bit set. Getting that -EIO means that we return immediately as we can not iterate over the entire tree. In that case we never update the reserved space for an extent buffer in the respective block group and space_info object. When this happens we get the following traces when unmounting the fs: [174957.284509] BTRFS: error (device dm-0) in cleanup_transaction:1913: err= no=3D-5 IO failure [174957.286497] BTRFS: error (device dm-0) in free_log_tree:3420: errno=3D-= 5 IO failure [174957.399379] ------------[ cut here ]------------ [174957.402497] WARNING: CPU: 2 PID: 3206883 at fs/btrfs/block-group.c:127 = btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.407523] Modules linked in: btrfs overlay dm_zero (...) [174957.424917] CPU: 2 PID: 3206883 Comm: umount Tainted: G W = 5.16.0-rc5-btrfs-next-109 #1 [174957.426689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS= rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [174957.428716] RIP: 0010:btrfs_put_block_group+0x77/0xb0 [btrfs] [174957.429717] Code: 21 48 8b bd (...) [174957.432867] RSP: 0018:ffffb70d41cffdd0 EFLAGS: 00010206 [174957.433632] RAX: 0000000000000001 RBX: ffff8b09c3848000 RCX: ffff8b0758= edd1c8 [174957.434689] RDX: 0000000000000001 RSI: ffffffffc0b467e7 RDI: ffff8b0758= edd000 [174957.436068] RBP: ffff8b0758edd000 R08: 0000000000000000 R09: 0000000000= 000000 [174957.437114] R10: 0000000000000246 R11: 0000000000000000 R12: ffff8b09c3= 848148 [174957.438140] R13: ffff8b09c3848198 R14: ffff8b0758edd188 R15: dead000000= 000100 [174957.439317] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS= :0000000000000000 [174957.440402] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [174957.441164] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000= 370ee0 [174957.442117] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000= 000000 [174957.443076] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000= 000400 [174957.443948] Call Trace: [174957.444264] [174957.444538] btrfs_free_block_groups+0x255/0x3c0 [btrfs] [174957.445238] close_ctree+0x301/0x357 [btrfs] [174957.445803] ? call_rcu+0x16c/0x290 [174957.446250] generic_shutdown_super+0x74/0x120 [174957.446832] kill_anon_super+0x14/0x30 [174957.447305] btrfs_kill_super+0x12/0x20 [btrfs] [174957.447890] deactivate_locked_super+0x31/0xa0 [174957.448440] cleanup_mnt+0x147/0x1c0 [174957.448888] task_work_run+0x5c/0xa0 [174957.449336] exit_to_user_mode_prepare+0x1e5/0x1f0 [174957.449934] syscall_exit_to_user_mode+0x16/0x40 [174957.450512] do_syscall_64+0x48/0xc0 [174957.450980] entry_SYSCALL_64_after_hwframe+0x44/0xae [174957.451605] RIP: 0033:0x7f328fdc4a97 [174957.452059] Code: 03 0c 00 f7 (...) [174957.454320] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ORIG_RAX: 00000= 000000000a6 [174957.455262] RAX: 0000000000000000 RBX: 00007f328feea264 RCX: 00007f328f= dc4a97 [174957.456131] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000560b8a= e51dd0 [174957.457118] RBP: 0000560b8ae51ba0 R08: 0000000000000000 R09: 00007fff13= 563c40 [174957.458005] R10: 00007f328fe49fc0 R11: 0000000000000246 R12: 0000000000= 000000 [174957.459113] R13: 0000560b8ae51dd0 R14: 0000560b8ae51cb0 R15: 0000000000= 000000 [174957.460193] [174957.460534] irq event stamp: 0 [174957.461003] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [174957.461947] hardirqs last disabled at (0): [] copy_pr= ocess+0x934/0x2040 [174957.463147] softirqs last enabled at (0): [] copy_pr= ocess+0x934/0x2040 [174957.465116] softirqs last disabled at (0): [<0000000000000000>] 0x0 [174957.466323] ---[ end trace bc7ee0c490bce3af ]--- [174957.467282] ------------[ cut here ]------------ [174957.468184] WARNING: CPU: 2 PID: 3206883 at fs/btrfs/block-group.c:3976= btrfs_free_block_groups+0x330/0x3c0 [btrfs] [174957.470066] Modules linked in: btrfs overlay dm_zero (...) [174957.483137] CPU: 2 PID: 3206883 Comm: umount Tainted: G W = 5.16.0-rc5-btrfs-next-109 #1 [174957.484691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS= rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [174957.486853] RIP: 0010:btrfs_free_block_groups+0x330/0x3c0 [btrfs] [174957.488050] Code: 00 00 00 ad de (...) [174957.491479] RSP: 0018:ffffb70d41cffde0 EFLAGS: 00010206 [174957.492520] RAX: ffff8b08d79310b0 RBX: ffff8b09c3848000 RCX: 0000000000= 000000 [174957.493868] RDX: 0000000000000001 RSI: fffff443055ee600 RDI: ffffffffb1= 131846 [174957.495183] RBP: ffff8b08d79310b0 R08: 0000000000000000 R09: 0000000000= 000000 [174957.496580] R10: 0000000000000001 R11: 0000000000000000 R12: ffff8b08d7= 931000 [174957.498027] R13: ffff8b09c38492b0 R14: dead000000000122 R15: dead000000= 000100 [174957.499438] FS: 00007f328fb82800(0000) GS:ffff8b0a2d200000(0000) knlGS= :0000000000000000 [174957.500990] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [174957.502117] CR2: 00007fff13563e98 CR3: 0000000404f4e005 CR4: 0000000000= 370ee0 [174957.503513] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000= 000000 [174957.504864] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000= 000400 [174957.506167] Call Trace: [174957.506654] [174957.507047] close_ctree+0x301/0x357 [btrfs] [174957.507867] ? call_rcu+0x16c/0x290 [174957.508567] generic_shutdown_super+0x74/0x120 [174957.509447] kill_anon_super+0x14/0x30 [174957.510194] btrfs_kill_super+0x12/0x20 [btrfs] [174957.511123] deactivate_locked_super+0x31/0xa0 [174957.511976] cleanup_mnt+0x147/0x1c0 [174957.512610] task_work_run+0x5c/0xa0 [174957.513309] exit_to_user_mode_prepare+0x1e5/0x1f0 [174957.514231] syscall_exit_to_user_mode+0x16/0x40 [174957.515069] do_syscall_64+0x48/0xc0 [174957.515718] entry_SYSCALL_64_after_hwframe+0x44/0xae [174957.516688] RIP: 0033:0x7f328fdc4a97 [174957.517413] Code: 03 0c 00 f7 d8 (...) [174957.521052] RSP: 002b:00007fff13564ec8 EFLAGS: 00000246 ORIG_RAX: 00000= 000000000a6 [174957.522514] RAX: 0000000000000000 RBX: 00007f328feea264 RCX: 00007f328f= dc4a97 [174957.523950] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000560b8a= e51dd0 [174957.525375] RBP: 0000560b8ae51ba0 R08: 0000000000000000 R09: 00007fff13= 563c40 [174957.526763] R10: 00007f328fe49fc0 R11: 0000000000000246 R12: 0000000000= 000000 [174957.528058] R13: 0000560b8ae51dd0 R14: 0000560b8ae51cb0 R15: 0000000000= 000000 [174957.529404] [174957.529843] irq event stamp: 0 [174957.530256] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [174957.531061] hardirqs last disabled at (0): [] copy_pr= ocess+0x934/0x2040 [174957.532075] softirqs last enabled at (0): [] copy_pr= ocess+0x934/0x2040 [174957.533083] softirqs last disabled at (0): [<0000000000000000>] 0x0 [174957.533865] ---[ end trace bc7ee0c490bce3b0 ]--- [174957.534452] BTRFS info (device dm-0): space_info 4 has 1070841856 free,= is not full [174957.535404] BTRFS info (device dm-0): space_info total=3D1073741824, us= ed=3D2785280, pinned=3D0, reserved=3D49152, may_use=3D0, readonly=3D65536 z= one_unusable=3D0 [174957.537029] BTRFS info (device dm-0): global_block_rsv: size 0 reserved= 0 [174957.537859] BTRFS info (device dm-0): trans_block_rsv: size 0 reserved 0 [174957.538697] BTRFS info (device dm-0): chunk_block_rsv: size 0 reserved 0 [174957.539552] BTRFS info (device dm-0): delayed_block_rsv: size 0 reserve= d 0 [174957.540403] BTRFS info (device dm-0): delayed_refs_rsv: size 0 reserved= 0 This also means that in case we have log tree extent buffers that are still dirty, we can end up not cleaning them up in case we find an extent buffer with EXTENT_BUFFER_WRITE_ERR set on it, as in that case we have no way for iterating over the rest of the tree. This issue is very often triggered with test cases generic/475 and generic/648 from fstests. The issue could almost be fixed by iterating over the io tree attached to each log root which keeps tracks of the range of allocated extent buffers, log_root->dirty_log_pages, however that does not work and has some inconveniences: 1) After we sync the log, we clear the range of the extent buffers from the io tree, so we can't find them after writeback. We could keep the ranges in the io tree, with a separate bit to signal they represent extent buffers already written, but that means we need to hold into more memory until the transaction commits. How much more memory is used depends a lot on whether we are able to allocate contiguous extent buffers on disk (and how often) for a log tree - if we are able to, then a single extent state record can represent multiple extent buffers, otherwise we need multiple extent state record structures to track each extent buffer. In fact, my earlier approach did that: https://lore.kernel.org/linux-btrfs/3aae7c6728257c7ce2279d6660ee2797e5e3= 4bbd.1641300250.git.fdmanana@suse.com/ However that can cause a very significant negative impact on performance, not only due to the extra memory usage but also because we get a larger and deeper dirty_log_pages io tree. We got a report that, on beefy machines at least, we can get such performance drop with fsmark for example: https://lore.kernel.org/linux-btrfs/20220117082426.GE32491@xsang-OptiPle= x-9020/ 2) We would be doing it only to deal with an unexpected and exceptional case, which is basically failure to read an extent buffer from disk due to IO failures. On a healthy system we don't expect transaction aborts to happen after all; 3) Instead of relying on iterating the log tree or tracking the ranges of extent buffers in the dirty_log_pages io tree, using the radix tree that tracks extent buffers (fs_info->buffer_radix) to find all log tree extent buffers is not reliable either, because after writeback of an extent buffer it can be evicted from memory by the release page callback of the btree inode (btree_releasepage()). Since there's no way to be able to properly cleanup a log tree without being able to read its extent buffers from disk and without using more memory to track the logical ranges of the allocated extent buffers do the following: 1) When we fail to cleanup a log tree, setup a flag that indicates that failure; 2) Trigger writeback of all log tree extent buffers that are still dirty, and wait for the writeback to complete. This is just to cleanup their state, page states, page leaks, etc; 3) When unmounting the fs, ignore if the number of bytes reserved in a block group and in a space_info is not 0 if, and only if, we failed to cleanup a log tree. Also ignore only for metadata block groups and the metadata space_info object. This is far from a perfect solution, but it serves to silence test failures such as those from generic/475 and generic/648. However having a non-zero value for the reserved bytes counters on unmount after a transaction abort, is not such a terrible thing and it's completely harmless, it does not affect the filesystem integrity in any way. Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Anand Jain Signed-off-by: Greg Kroah-Hartman Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Jeffrin Jose T Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz --- fs/btrfs/block-group.c | 26 ++++++++++++++++++++++++-- fs/btrfs/ctree.h | 7 +++++++ fs/btrfs/tree-log.c | 23 +++++++++++++++++++++++ 3 files changed, 54 insertions(+), 2 deletions(-) --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -124,7 +124,16 @@ void btrfs_put_block_group(struct btrfs_ { if (refcount_dec_and_test(&cache->refs)) { WARN_ON(cache->pinned > 0); - WARN_ON(cache->reserved > 0); + /* + * If there was a failure to cleanup a log tree, very likely due + * to an IO failure on a writeback attempt of one or more of its + * extent buffers, we could not do proper (and cheap) unaccounting + * of their reserved space, so don't warn on reserved > 0 in that + * case. + */ + if (!(cache->flags & BTRFS_BLOCK_GROUP_METADATA) || + !BTRFS_FS_LOG_CLEANUP_ERROR(cache->fs_info)) + WARN_ON(cache->reserved > 0); =20 /* * A block_group shouldn't be on the discard_list anymore. @@ -3987,9 +3996,22 @@ int btrfs_free_block_groups(struct btrfs * important and indicates a real bug if this happens. */ if (WARN_ON(space_info->bytes_pinned > 0 || - space_info->bytes_reserved > 0 || space_info->bytes_may_use > 0)) btrfs_dump_space_info(info, space_info, 0, 0); + + /* + * If there was a failure to cleanup a log tree, very likely due + * to an IO failure on a writeback attempt of one or more of its + * extent buffers, we could not do proper (and cheap) unaccounting + * of their reserved space, so don't warn on bytes_reserved > 0 in + * that case. + */ + if (!(space_info->flags & BTRFS_BLOCK_GROUP_METADATA) || + !BTRFS_FS_LOG_CLEANUP_ERROR(info)) { + if (WARN_ON(space_info->bytes_reserved > 0)) + btrfs_dump_space_info(info, space_info, 0, 0); + } + WARN_ON(space_info->reclaim_size > 0); list_del(&space_info->list); btrfs_sysfs_remove_space_info(space_info); --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -143,6 +143,9 @@ enum { BTRFS_FS_STATE_DEV_REPLACING, /* The btrfs_fs_info created for self-tests */ BTRFS_FS_STATE_DUMMY_FS_INFO, + + /* Indicates there was an error cleaning up a log tree. */ + BTRFS_FS_STATE_LOG_CLEANUP_ERROR, }; =20 #define BTRFS_BACKREF_REV_MAX 256 @@ -3585,6 +3588,10 @@ static inline void btrfs_print_v0_err(st "Unsupported V0 extent filesystem detected. Aborting. Please re-create you= r filesystem with a newer kernel"); } =20 +#define BTRFS_FS_LOG_CLEANUP_ERROR(fs_info) \ + (unlikely(test_bit(BTRFS_FS_STATE_LOG_CLEANUP_ERROR, \ + &(fs_info)->fs_state))) + __printf(5, 6) __cold void __btrfs_handle_fs_error(struct btrfs_fs_info *fs_info, const char *fu= nction, --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -3449,6 +3449,29 @@ static void free_log_tree(struct btrfs_t if (log->node) { ret =3D walk_log_tree(trans, log, &wc); if (ret) { + /* + * We weren't able to traverse the entire log tree, the + * typical scenario is getting an -EIO when reading an + * extent buffer of the tree, due to a previous writeback + * failure of it. + */ + set_bit(BTRFS_FS_STATE_LOG_CLEANUP_ERROR, + &log->fs_info->fs_state); + + /* + * Some extent buffers of the log tree may still be dirty + * and not yet written back to storage, because we may + * have updates to a log tree without syncing a log tree, + * such as during rename and link operations. So flush + * them out and wait for their writeback to complete, so + * that we properly cleanup their state and pages. + */ + btrfs_write_marked_extents(log->fs_info, + &log->dirty_log_pages, + EXTENT_DIRTY | EXTENT_NEW); + btrfs_wait_tree_log_extents(log, + EXTENT_DIRTY | EXTENT_NEW); + if (trans) btrfs_abort_transaction(trans, ret); else