From nobody Wed Jul 1 03:23:32 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 12E12C433FE for ; Mon, 31 Jan 2022 10:58:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239879AbiAaK6O (ORCPT ); Mon, 31 Jan 2022 05:58:14 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:59472 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239344AbiAaK6N (ORCPT ); Mon, 31 Jan 2022 05:58:13 -0500 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 D058860AF6; Mon, 31 Jan 2022 10:58:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8623BC340E8; Mon, 31 Jan 2022 10:58:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626692; bh=Am7HN6bjhbVZ5pfZErRSqrJI5VgqHDagnnGL38sPjRs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TV2y1TpsF8Tqlvhrj+5HqsOMrni3XIqfRgE+tQfagdyeW/fe0oAt7tjkdtKyfxqBX Ey+lIuqo/5V4SR0vTllDAAhsIgF3+oq3t7iwP+f4OJT1pn5PJPPL/fLEdm5SdyA5NJ ryDUEEv720mmDYxmn+NyiF9zX2EF0eWtLh4pXStI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Gix , Marcel Holtmann , syphyr Subject: [PATCH 5.4 01/64] Bluetooth: refactor malicious adv data check Date: Mon, 31 Jan 2022 11:55:46 +0100 Message-Id: <20220131105215.695316553@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@linuxfoundation.org> User-Agent: quilt/0.66 X-stable: review X-Patchwork-Hint: ignore 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: Brian Gix commit 899663be5e75dc0174dc8bda0b5e6826edf0b29a upstream. Check for out-of-bound read was being performed at the end of while num_reports loop, and would fill journal with false positives. Added check to beginning of loop processing so that it doesn't get checked after ptr has been advanced. Signed-off-by: Brian Gix Signed-off-by: Marcel Holtmann Cc: syphyr Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/bluetooth/hci_event.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -5506,6 +5506,11 @@ static void hci_le_adv_report_evt(struct struct hci_ev_le_advertising_info *ev =3D ptr; s8 rssi; =20 + if (ptr > (void *)skb_tail_pointer(skb) - sizeof(*ev)) { + bt_dev_err(hdev, "Malicious advertising data."); + break; + } + if (ev->length <=3D HCI_MAX_AD_LENGTH && ev->data + ev->length <=3D skb_tail_pointer(skb)) { rssi =3D ev->data[ev->length]; @@ -5517,11 +5522,6 @@ static void hci_le_adv_report_evt(struct } =20 ptr +=3D sizeof(*ev) + ev->length + 1; - - if (ptr > (void *) skb_tail_pointer(skb) - sizeof(*ev)) { - bt_dev_err(hdev, "Malicious advertising data. Stopping processing"); - break; - } } =20 hci_dev_unlock(hdev); From nobody Wed Jul 1 03:23:32 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 AC5BCC433F5 for ; Mon, 31 Jan 2022 10:59:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358368AbiAaK7V (ORCPT ); Mon, 31 Jan 2022 05:59:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244667AbiAaK6r (ORCPT ); Mon, 31 Jan 2022 05:58:47 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC141C061741; Mon, 31 Jan 2022 02:58:46 -0800 (PST) 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 8E56460AD6; Mon, 31 Jan 2022 10:58:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BD49C340E8; Mon, 31 Jan 2022 10:58:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626726; bh=kvmeKDKq4ruE2gAqLGR7+eCTMNUXOvT8e/qFwT9YNBE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ALnPbrkjpcpjzEm5aVTjxP78DNrDkT6AV5guUuXGqTBXHV1lTl1ftqFPzlemMH8fM VWi1yIY5YUPbAP5CxhXeeiY9237LRvUMB71fYq8Ns7eF/KPwM9lFp6OmDIxSFITqI2 dTa08UXHIunXpQfjK4qgTdlBoHVdZ0TnyIv7vz4o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Gerald Schaefer , Vasily Gorbik Subject: [PATCH 5.4 02/64] s390/hypfs: include z/VM guests with access control group set Date: Mon, 31 Jan 2022 11:55:47 +0100 Message-Id: <20220131105215.724794699@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Vasily Gorbik commit 663d34c8df98740f1e90241e78e456d00b3c6cad upstream. Currently if z/VM guest is allowed to retrieve hypervisor performance data globally for all guests (privilege class B) the query is formed in a way to include all guests but the group name is left empty. This leads to that z/VM guests which have access control group set not being included in the results (even local vm). Change the query group identifier from empty to "any" to retrieve information about all guests from any groups (or without a group set). Cc: stable@vger.kernel.org Fixes: 31cb4bd31a48 ("[S390] Hypervisor filesystem (s390_hypfs) for z/VM") Reviewed-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- arch/s390/hypfs/hypfs_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/arch/s390/hypfs/hypfs_vm.c +++ b/arch/s390/hypfs/hypfs_vm.c @@ -20,6 +20,7 @@ =20 static char local_guest[] =3D " "; static char all_guests[] =3D "* "; +static char *all_groups =3D all_guests; static char *guest_query; =20 struct diag2fc_data { @@ -62,10 +63,11 @@ static int diag2fc(int size, char* query =20 memcpy(parm_list.userid, query, NAME_LEN); ASCEBC(parm_list.userid, NAME_LEN); - parm_list.addr =3D (unsigned long) addr ; + memcpy(parm_list.aci_grp, all_groups, NAME_LEN); + ASCEBC(parm_list.aci_grp, NAME_LEN); + parm_list.addr =3D (unsigned long)addr; parm_list.size =3D size; parm_list.fmt =3D 0x02; - memset(parm_list.aci_grp, 0x40, NAME_LEN); rc =3D -1; =20 diag_stat_inc(DIAG_STAT_X2FC); From nobody Wed Jul 1 03:23:32 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 300B6C433F5 for ; Mon, 31 Jan 2022 11:00:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358621AbiAaLAe (ORCPT ); Mon, 31 Jan 2022 06:00:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358340AbiAaK7v (ORCPT ); Mon, 31 Jan 2022 05:59:51 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 178B4C06175E; Mon, 31 Jan 2022 02:59:20 -0800 (PST) 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 AA3BD60BA5; Mon, 31 Jan 2022 10:59:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B866AC340E8; Mon, 31 Jan 2022 10:59:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626759; bh=73BdNz4Hg5qLRQTfuS4+6Pt09s5QMlox2v1WqQLxkag=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B6pcscalJgrHLxudZX40pnyBsuPDdwIXzi+T4OcQsnV0aUoN55I/UvvOC4MSDD4PX 16u2NdrCAoegHI2L5h3+TQdUxr0o0a0ZRwtbB39cuq/8YaVF+AzkG7aCVM2QN6cEd/ XN9pDqHyk3IAxtkHuOziFyysm2W62BQrAsLb3I3o= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Benjamin Block , Steffen Maier , "Martin K. Petersen" Subject: [PATCH 5.4 03/64] scsi: zfcp: Fix failed recovery on gone remote port with non-NPIV FCP devices Date: Mon, 31 Jan 2022 11:55:48 +0100 Message-Id: <20220131105215.758509390@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Steffen Maier commit 8c9db6679be4348b8aae108e11d4be2f83976e30 upstream. Suppose we have an environment with a number of non-NPIV FCP devices (virtual HBAs / FCP devices / zfcp "adapter"s) sharing the same physical FCP channel (HBA port) and its I_T nexus. Plus a number of storage target ports zoned to such shared channel. Now one target port logs out of the fabric causing an RSCN. Zfcp reacts with an ADISC ELS and subsequent port recovery depending on the ADISC result. This happens on all such FCP devices (in different Linux images) concurrently as they all receive a copy of this RSCN. In the following we look at one of those FCP devices. Requests other than FSF_QTCB_FCP_CMND can be slow until they get a response. Depending on which requests are affected by slow responses, there are different recovery outcomes. Here we want to fix failed recoveries on port or adapter level by avoiding recovery requests that can be slow. We need the cached N_Port_ID for the remote port "link" test with ADISC. Just before sending the ADISC, we now intentionally forget the old cached N_Port_ID. The idea is that on receiving an RSCN for a port, we have to assume that any cached information about this port is stale. This forces a fresh new GID_PN [FC-GS] nameserver lookup on any subsequent recovery for the same port. Since we typically can still communicate with the nameserver efficiently, we now reach steady state quicker: Either the nameserver still does not know about the port so we stop recovery, or the nameserver already knows the port potentially with a new N_Port_ID and we can successfully and quickly perform open port recovery. For the one case, where ADISC returns successfully, we re-initialize port->d_id because that case does not involve any port recovery. This also solves a problem if the storage WWPN quickly logs into the fabric again but with a different N_Port_ID. Such as on virtual WWPN takeover during target NPIV failover. [https://www.redbooks.ibm.com/abstracts/redp5477.html] In that case the RSCN from the storage FDISC was ignored by zfcp and we could not successfully recover the failover. On some later failback on the storage, we could have been lucky if the virtual WWPN got the same old N_Port_ID from the SAN switch as we still had cached. Then the related RSCN triggered a successful port reopen recovery. However, there is no guarantee to get the same N_Port_ID on NPIV FDISC. Even though NPIV-enabled FCP devices are not affected by this problem, this code change optimizes recovery time for gone remote ports as a side effect. The timely drop of cached N_Port_IDs prevents unnecessary slow open port attempts. While the problem might have been in code before v2.6.32 commit 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") this fix depends on the gid_pn_work introduced with that commit, so we mark it as culprit to satisfy fix dependencies. Note: Point-to-point remote port is already handled separately and gets its N_Port_ID from the cached peer_d_id. So resetting port->d_id in general does not affect PtP. Link: https://lore.kernel.org/r/20220118165803.3667947-1-maier@linux.ibm.com Fixes: 799b76d09aee ("[SCSI] zfcp: Decouple gid_pn requests from erp") Cc: #2.6.32+ Suggested-by: Benjamin Block Reviewed-by: Benjamin Block Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/s390/scsi/zfcp_fc.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) --- a/drivers/s390/scsi/zfcp_fc.c +++ b/drivers/s390/scsi/zfcp_fc.c @@ -521,6 +521,8 @@ static void zfcp_fc_adisc_handler(void * goto out; } =20 + /* re-init to undo drop from zfcp_fc_adisc() */ + port->d_id =3D ntoh24(adisc_resp->adisc_port_id); /* port is good, unblock rport without going through erp */ zfcp_scsi_schedule_rport_register(port); out: @@ -534,6 +536,7 @@ static int zfcp_fc_adisc(struct zfcp_por struct zfcp_fc_req *fc_req; struct zfcp_adapter *adapter =3D port->adapter; struct Scsi_Host *shost =3D adapter->scsi_host; + u32 d_id; int ret; =20 fc_req =3D kmem_cache_zalloc(zfcp_fc_req_cache, GFP_ATOMIC); @@ -558,7 +561,15 @@ static int zfcp_fc_adisc(struct zfcp_por fc_req->u.adisc.req.adisc_cmd =3D ELS_ADISC; hton24(fc_req->u.adisc.req.adisc_port_id, fc_host_port_id(shost)); =20 - ret =3D zfcp_fsf_send_els(adapter, port->d_id, &fc_req->ct_els, + d_id =3D port->d_id; /* remember as destination for send els below */ + /* + * Force fresh GID_PN lookup on next port recovery. + * Must happen after request setup and before sending request, + * to prevent race with port->d_id re-init in zfcp_fc_adisc_handler(). + */ + port->d_id =3D 0; + + ret =3D zfcp_fsf_send_els(adapter, d_id, &fc_req->ct_els, ZFCP_FC_CTELS_TMO); if (ret) kmem_cache_free(zfcp_fc_req_cache, fc_req); From nobody Wed Jul 1 03:23:32 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 E2C43C433EF for ; Mon, 31 Jan 2022 11:01:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348448AbiAaLBd (ORCPT ); Mon, 31 Jan 2022 06:01:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43126 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358591AbiAaLAW (ORCPT ); Mon, 31 Jan 2022 06:00:22 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6A54C0613E5; Mon, 31 Jan 2022 02:59:38 -0800 (PST) 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 87D9060B28; Mon, 31 Jan 2022 10:59:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5ED62C340F0; Mon, 31 Jan 2022 10:59:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626777; bh=etwDj2ZJLh6nqqlIe8jncPRFjBV+R7ONKL8aFnttvpg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A/rjBsjhhrjtElqV1Mw1jXK8vs8tgJKOFKnLkMUMM9z+R6+rIGdbz0FR2n6sL8jgN ixY9iH1M8ij3pBcNaxvDeYjpRDk8sk/rPgEK7WsFtQBQb1sEJtETJjW+PeZ6PiSKpW TVvedb6A7ZpjrmjhO9Tbvun09OzP/Vg43n7wDIiw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, butt3rflyh4ck , Christoph Hellwig , Jan Kara Subject: [PATCH 5.4 04/64] udf: Restore i_lenAlloc when inode expansion fails Date: Mon, 31 Jan 2022 11:55:49 +0100 Message-Id: <20220131105215.797442396@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Jan Kara commit ea8569194b43f0f01f0a84c689388542c7254a1f upstream. When we fail to expand inode from inline format to a normal format, we restore inode to contain the original inline formatting but we forgot to set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then causing further problems such as warnings and lost data down the line. Reported-by: butt3rflyh4ck CC: stable@vger.kernel.org Fixes: 7e49b6f2480c ("udf: Convert UDF to new truncate calling sequence") Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/udf/inode.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -318,6 +318,7 @@ int udf_expand_file_adinicb(struct inode unlock_page(page); iinfo->i_alloc_type =3D ICBTAG_FLAG_AD_IN_ICB; inode->i_data.a_ops =3D &udf_adinicb_aops; + iinfo->i_lenAlloc =3D inode->i_size; up_write(&iinfo->i_data_sem); } put_page(page); From nobody Wed Jul 1 03:23:32 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 CA17CC433F5 for ; Mon, 31 Jan 2022 11:00:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358470AbiAaLAY (ORCPT ); Mon, 31 Jan 2022 06:00:24 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60614 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358431AbiAaK7m (ORCPT ); Mon, 31 Jan 2022 05:59:42 -0500 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 AD5CD60AD6; Mon, 31 Jan 2022 10:59:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75241C340E8; Mon, 31 Jan 2022 10:59:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626781; bh=Qaq1eYmEKuHp4EfSym8gVoXa+XNpJfoIhWl2rY8NBjo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ewuUEe31jUv3ZCGW9hWO29zsHEovTu9rDKJOFPnUnw5x07WaOjrMhOQ6Xd7MFjHY5 Tki1kbTQKaChk7Fv3hubtZ4gG0Jsi/X+edN6UmmTFTbvV6u4as5K2BWISRtU8g4fnF iAqgGOHwxFOWbL8E4nkggze7XduHtWeetVm1HHdc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, butt3rflyh4ck , Christoph Hellwig , Jan Kara Subject: [PATCH 5.4 05/64] udf: Fix NULL ptr deref when converting from inline format Date: Mon, 31 Jan 2022 11:55:50 +0100 Message-Id: <20220131105215.830592752@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Jan Kara commit 7fc3b7c2981bbd1047916ade327beccb90994eee upstream. udf_expand_file_adinicb() calls directly ->writepage to write data expanded into a page. This however misses to setup inode for writeback properly and so we can crash on inode->i_wb dereference when submitting page for IO like: BUG: kernel NULL pointer dereference, address: 0000000000000158 #PF: supervisor read access in kernel mode ... __folio_start_writeback+0x2ac/0x350 __block_write_full_page+0x37d/0x490 udf_expand_file_adinicb+0x255/0x400 [udf] udf_file_write_iter+0xbe/0x1b0 [udf] new_sync_write+0x125/0x1c0 vfs_write+0x28e/0x400 Fix the problem by marking the page dirty and going through the standard writeback path to write the page. Strictly speaking we would not even have to write the page but we want to catch e.g. ENOSPC errors early. Reported-by: butt3rflyh4ck CC: stable@vger.kernel.org Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific= bdi_writebacks") Reviewed-by: Christoph Hellwig Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/udf/inode.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/fs/udf/inode.c +++ b/fs/udf/inode.c @@ -258,10 +258,6 @@ int udf_expand_file_adinicb(struct inode char *kaddr; struct udf_inode_info *iinfo =3D UDF_I(inode); int err; - struct writeback_control udf_wbc =3D { - .sync_mode =3D WB_SYNC_NONE, - .nr_to_write =3D 1, - }; =20 WARN_ON_ONCE(!inode_is_locked(inode)); if (!iinfo->i_lenAlloc) { @@ -305,8 +301,10 @@ int udf_expand_file_adinicb(struct inode iinfo->i_alloc_type =3D ICBTAG_FLAG_AD_LONG; /* from now on we have normal address_space methods */ inode->i_data.a_ops =3D &udf_aops; + set_page_dirty(page); + unlock_page(page); up_write(&iinfo->i_data_sem); - err =3D inode->i_data.a_ops->writepage(page, &udf_wbc); + err =3D filemap_fdatawrite(inode->i_mapping); if (err) { /* Restore everything back so that we don't lose data... */ lock_page(page); From nobody Wed Jul 1 03:23:32 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 6D20DC433F5 for ; Mon, 31 Jan 2022 11:01:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348563AbiAaLBW (ORCPT ); Mon, 31 Jan 2022 06:01:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43144 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358341AbiAaLAY (ORCPT ); Mon, 31 Jan 2022 06:00:24 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2CE03C0613EF; Mon, 31 Jan 2022 02:59:45 -0800 (PST) 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 C132C60B28; Mon, 31 Jan 2022 10:59:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B1B0C340F0; Mon, 31 Jan 2022 10:59:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626784; bh=y8gnLAmebI/LsWI7Qf1t1rVMg1fjqFljK3zoLhrq18I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PGQTg5EI8/hseh3Yb5WyjsmdGNVD8A8u6HROicivD4S5futB6xtvcUR9qxSbpZXBz vMu9/fMOBB03p/QnxluCHjQLzuqCEGvxOUaVG+02CqKQc/kcduSpszIEP41r/+GiCJ QE1SzW+3X5t0RrOF95NnnHGCESL59evCzx59Xwsw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lee Jones , "Rafael J. Wysocki" Subject: [PATCH 5.4 06/64] PM: wakeup: simplify the output logic of pm_show_wakelocks() Date: Mon, 31 Jan 2022 11:55:51 +0100 Message-Id: <20220131105215.860810413@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Greg Kroah-Hartman commit c9d967b2ce40d71e968eb839f36c936b8a9cf1ea upstream. The buffer handling in pm_show_wakelocks() is tricky, and hopefully correct. Ensure it really is correct by using sysfs_emit_at() which handles all of the tricky string handling logic in a PAGE_SIZE buffer for us automatically as this is a sysfs file being read from. Reviewed-by: Lee Jones Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- kernel/power/wakelock.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) --- a/kernel/power/wakelock.c +++ b/kernel/power/wakelock.c @@ -39,23 +39,20 @@ ssize_t pm_show_wakelocks(char *buf, boo { struct rb_node *node; struct wakelock *wl; - char *str =3D buf; - char *end =3D buf + PAGE_SIZE; + int len =3D 0; =20 mutex_lock(&wakelocks_lock); =20 for (node =3D rb_first(&wakelocks_tree); node; node =3D rb_next(node)) { wl =3D rb_entry(node, struct wakelock, node); if (wl->ws->active =3D=3D show_active) - str +=3D scnprintf(str, end - str, "%s ", wl->name); + len +=3D sysfs_emit_at(buf, len, "%s ", wl->name); } - if (str > buf) - str--; =20 - str +=3D scnprintf(str, end - str, "\n"); + len +=3D sysfs_emit_at(buf, len, "\n"); =20 mutex_unlock(&wakelocks_lock); - return (str - buf); + return len; } =20 #if CONFIG_PM_WAKELOCKS_LIMIT > 0 From nobody Wed Jul 1 03:23:32 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 AE7EAC433F5 for ; Mon, 31 Jan 2022 11:02:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358715AbiAaLCR (ORCPT ); Mon, 31 Jan 2022 06:02:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358448AbiAaLBA (ORCPT ); Mon, 31 Jan 2022 06:01:00 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1CCA2C0617A3; Mon, 31 Jan 2022 02:59:48 -0800 (PST) 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 B050D60B28; Mon, 31 Jan 2022 10:59:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9528EC340E8; Mon, 31 Jan 2022 10:59:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626787; bh=pF66JUufhVkGFO/oRzhbn0auR3ADePKpbz05UIfv6Nw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PQvocjqAp0aSMXxKfueBwlhfhtd3APxqZkXpguW2GMtISYFSCthG0LFerQw5nCTf4 WKUgJv3cYw8eSW9FutmzfgNutcANsBIJd3lqgRIAHAaHApUCcTVlHxqgXlYVAJSaWs kZxO96vOrTBlf19WHKDwwp/pLfOFEsS4A2na/5HI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xiaoke Wang , "Steven Rostedt (Google)" Subject: [PATCH 5.4 07/64] tracing/histogram: Fix a potential memory leak for kstrdup() Date: Mon, 31 Jan 2022 11:55:52 +0100 Message-Id: <20220131105215.899357792@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Xiaoke Wang commit e629e7b525a179e29d53463d992bdee759c950fb upstream. kfree() is missing on an error path to free the memory allocated by kstrdup(): p =3D param =3D kstrdup(data->params[i], GFP_KERNEL); So it is better to free it via kfree(p). Link: https://lkml.kernel.org/r/tencent_C52895FD37802832A3E5B272D05008866F0= A@qq.com Cc: stable@vger.kernel.org Fixes: d380dcde9a07c ("tracing: Fix now invalid var_ref_vals assumption in = trace action") Signed-off-by: Xiaoke Wang Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- kernel/trace/trace_events_hist.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -4398,6 +4398,7 @@ static int trace_action_create(struct hi =20 var_ref_idx =3D find_var_ref_idx(hist_data, var_ref); if (WARN_ON(var_ref_idx < 0)) { + kfree(p); ret =3D var_ref_idx; goto err; } From nobody Wed Jul 1 03:23:32 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 A23D7C433FE for ; Mon, 31 Jan 2022 11:00:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358616AbiAaLAa (ORCPT ); Mon, 31 Jan 2022 06:00:30 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60252 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358321AbiAaK7u (ORCPT ); Mon, 31 Jan 2022 05:59:50 -0500 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 A77EF60B28; Mon, 31 Jan 2022 10:59:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 896DFC340E8; Mon, 31 Jan 2022 10:59:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626790; bh=tnuOzLwaVZRpggTfGRr/SWIBGVOtaXSM75Dd1lEwC2Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tcj4zETWXYQu04k28gPqsa1biTcmQYJYxhl6J6cpDaWy6oZXxx7PP0ZQpUmcU8Ux1 3iW8nNI583Ril7NWNhGlsgfajdA48q0BCW6pyTeCFm/4AayqOWVmzRGYKb44BWmhKc wqTtoQwCGyyim60pGaa5Rj3GBE+5YCuM0Plip4oo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Tom Zanussi , "Steven Rostedt (Google)" Subject: [PATCH 5.4 08/64] tracing: Dont inc err_log entry count if entry allocation fails Date: Mon, 31 Jan 2022 11:55:53 +0100 Message-Id: <20220131105215.933572729@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Tom Zanussi commit 67ab5eb71b37b55f7c5522d080a1b42823351776 upstream. tr->n_err_log_entries should only be increased if entry allocation succeeds. Doing it when it fails won't cause any problems other than wasting an entry, but should be fixed anyway. Link: https://lkml.kernel.org/r/cad1ab28f75968db0f466925e7cba5970cec6c29.16= 43319703.git.zanussi@kernel.org Cc: stable@vger.kernel.org Fixes: 2f754e771b1a6 ("tracing: Don't inc err_log entry count if entry allo= cation fails") Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- kernel/trace/trace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -6994,7 +6994,8 @@ static struct tracing_log_err *get_traci err =3D kzalloc(sizeof(*err), GFP_KERNEL); if (!err) err =3D ERR_PTR(-ENOMEM); - tr->n_err_log_entries++; + else + tr->n_err_log_entries++; =20 return err; } From nobody Wed Jul 1 03:23:32 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 4160FC433EF for ; Mon, 31 Jan 2022 11:00:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348652AbiAaLAx (ORCPT ); Mon, 31 Jan 2022 06:00:53 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:47818 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358347AbiAaK7z (ORCPT ); Mon, 31 Jan 2022 05:59:55 -0500 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 41AC2B82A61; Mon, 31 Jan 2022 10:59:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 645B7C36AE3; Mon, 31 Jan 2022 10:59:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626793; bh=5RpfSYlB+m4DKtd8y+OsIMz88vwvd7QTSuwCX00payI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eRJRVedcYfyrVSAwOwoNQUokyeSxW9zsjcwrOvwb3cqmWdjWF9nTTJQOlpCXYpwA+ XoXZRJ0UAhaQutskO8TdzAom7mTzwFS7LWJdrYxVG1TRPR2fJYB1rl05CkY3IT8yqT Zqf4YUlnQF9PvQH48WPX3SR2qUugfXIuqNwu71c0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ivan Delalande , Amir Goldstein , Jan Kara Subject: [PATCH 5.4 09/64] fsnotify: fix fsnotify hooks in pseudo filesystems Date: Mon, 31 Jan 2022 11:55:54 +0100 Message-Id: <20220131105215.972215147@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Amir Goldstein commit 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 upstream. Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify will have access to a positive dentry. This allowed a race where opening the deleted file via cached dentry is now possible after receiving the IN_DELETE event. To fix the regression in pseudo filesystems, convert d_delete() calls to d_drop() (see commit 46c46f8df9aa ("devpts_pty_kill(): don't bother with d_delete()") and move the fsnotify hook after d_drop(). Add a missing fsnotify_unlink() hook in nfsdfs that was found during the audit of fsnotify hooks in pseudo filesystems. Note that the fsnotify hooks in simple_recursive_removal() follow d_invalidate(), so they require no change. Link: https://lore.kernel.org/r/20220120215305.282577-2-amir73il@gmail.com Reported-by: Ivan Delalande Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/ Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_de= lete()") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/configfs/dir.c | 6 +++--- fs/devpts/inode.c | 2 +- fs/nfsd/nfsctl.c | 5 +++-- net/sunrpc/rpc_pipe.c | 4 ++-- 4 files changed, 9 insertions(+), 8 deletions(-) --- a/fs/configfs/dir.c +++ b/fs/configfs/dir.c @@ -1805,8 +1805,8 @@ void configfs_unregister_group(struct co configfs_detach_group(&group->cg_item); d_inode(dentry)->i_flags |=3D S_DEAD; dont_mount(dentry); + d_drop(dentry); fsnotify_rmdir(d_inode(parent), dentry); - d_delete(dentry); inode_unlock(d_inode(parent)); =20 dput(dentry); @@ -1947,10 +1947,10 @@ void configfs_unregister_subsystem(struc configfs_detach_group(&group->cg_item); d_inode(dentry)->i_flags |=3D S_DEAD; dont_mount(dentry); - fsnotify_rmdir(d_inode(root), dentry); inode_unlock(d_inode(dentry)); =20 - d_delete(dentry); + d_drop(dentry); + fsnotify_rmdir(d_inode(root), dentry); =20 inode_unlock(d_inode(root)); =20 --- a/fs/devpts/inode.c +++ b/fs/devpts/inode.c @@ -621,8 +621,8 @@ void devpts_pty_kill(struct dentry *dent =20 dentry->d_fsdata =3D NULL; drop_nlink(dentry->d_inode); - fsnotify_unlink(d_inode(dentry->d_parent), dentry); d_drop(dentry); + fsnotify_unlink(d_inode(dentry->d_parent), dentry); dput(dentry); /* d_alloc_name() in devpts_pty_new() */ } =20 --- a/fs/nfsd/nfsctl.c +++ b/fs/nfsd/nfsctl.c @@ -1247,7 +1247,8 @@ static void nfsdfs_remove_file(struct in clear_ncl(d_inode(dentry)); dget(dentry); ret =3D simple_unlink(dir, dentry); - d_delete(dentry); + d_drop(dentry); + fsnotify_unlink(dir, dentry); dput(dentry); WARN_ON_ONCE(ret); } @@ -1336,8 +1337,8 @@ void nfsd_client_rmdir(struct dentry *de dget(dentry); ret =3D simple_rmdir(dir, dentry); WARN_ON_ONCE(ret); + d_drop(dentry); fsnotify_rmdir(dir, dentry); - d_delete(dentry); dput(dentry); inode_unlock(dir); } --- a/net/sunrpc/rpc_pipe.c +++ b/net/sunrpc/rpc_pipe.c @@ -599,9 +599,9 @@ static int __rpc_rmdir(struct inode *dir =20 dget(dentry); ret =3D simple_rmdir(dir, dentry); + d_drop(dentry); if (!ret) fsnotify_rmdir(dir, dentry); - d_delete(dentry); dput(dentry); return ret; } @@ -612,9 +612,9 @@ static int __rpc_unlink(struct inode *di =20 dget(dentry); ret =3D simple_unlink(dir, dentry); + d_drop(dentry); if (!ret) fsnotify_unlink(dir, dentry); - d_delete(dentry); dput(dentry); return ret; } From nobody Wed Jul 1 03:23:32 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 9F85CC433FE for ; Mon, 31 Jan 2022 10:58:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240712AbiAaK6V (ORCPT ); Mon, 31 Jan 2022 05:58:21 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:59510 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239344AbiAaK6P (ORCPT ); Mon, 31 Jan 2022 05:58:15 -0500 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 9164A60B28; Mon, 31 Jan 2022 10:58:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79BE9C340E8; Mon, 31 Jan 2022 10:58:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626695; bh=OMklhXxpD3qq02yGA+cPXwbcYLb0YVS3ZDDGQVSvSiI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nPP2JjTsQ1SGg1v7Thqe5zAA4utZSI4xtE/oV8al0dBWWHot4hHlZ8X+FoORLq1IG 5LbskVozMVYD789g0i6LIal3jDoRCdwUXKppRRrX+MEc8mI19UyO3xBuxcYDcZ+vex BAsIrKfs6NfXfl0uMycGl7UF2ddOpTWwAu1ajupE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lucas Stach , Christian Gmeiner Subject: [PATCH 5.4 10/64] drm/etnaviv: relax submit size limits Date: Mon, 31 Jan 2022 11:55:55 +0100 Message-Id: <20220131105216.005198204@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Lucas Stach commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream. While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace. Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach Reviewed-by: Christian Gmeiner Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c @@ -471,8 +471,8 @@ int etnaviv_ioctl_gem_submit(struct drm_ return -EINVAL; } =20 - if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K || - args->nr_bos > SZ_64K || args->nr_pmrs > 128) { + if (args->stream_size > SZ_128K || args->nr_relocs > SZ_128K || + args->nr_bos > SZ_128K || args->nr_pmrs > 128) { DRM_ERROR("submit arguments out of size limits\n"); return -EINVAL; } From nobody Wed Jul 1 03:23:32 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 22C3EC433FE for ; Mon, 31 Jan 2022 10:58:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239344AbiAaK6Y (ORCPT ); Mon, 31 Jan 2022 05:58:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240233AbiAaK6V (ORCPT ); Mon, 31 Jan 2022 05:58:21 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE746C06173D; Mon, 31 Jan 2022 02:58:20 -0800 (PST) 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 3F4E7B82A60; Mon, 31 Jan 2022 10:58:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAA03C340E8; Mon, 31 Jan 2022 10:58:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626698; bh=3RWFoGGfMGkzU+hhQKLd0GwS2R0ZphrWfI32rXdE5FI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gnRA14mwoVW+eRd8M+mWa40TIVE/FoJ3kh3NtouvvA/aVLftYf0pzcj0x8FJaegVL eWhSpfdgxJwjmUKrIX5HsfsNfDvRlFX9L/jXQ9m7jHFLCPfWMl398ZQKsvzRi2LNIK 8gE+yB/N+0CVCf4tTE1V6OfdQE5czT+sV9nQbejc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, D Scott Phillips , Marc Zyngier , Catalin Marinas Subject: [PATCH 5.4 11/64] arm64: errata: Fix exec handling in erratum 1418040 workaround Date: Mon, 31 Jan 2022 11:55:56 +0100 Message-Id: <20220131105216.042502594@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: D Scott Phillips commit 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c upstream. The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0 when executing compat threads. The workaround is applied when switching between tasks, but the need for the workaround could also change at an exec(), when a non-compat task execs a compat binary or vice versa. Apply the workaround in arch_setup_new_exec(). This leaves a small window of time between SET_PERSONALITY and arch_setup_new_exec where preemption could occur and confuse the old workaround logic that compares TIF_32BIT between prev and next. Instead, we can just read cntkctl to make sure it's in the state that the next task needs. I measured cntkctl read time to be about the same as a mov from a general-purpose register on N1. Update the workaround logic to examine the current value of cntkctl instead of the previous task's compat state. Fixes: d49f7d7376d0 ("arm64: Move handling of erratum 1418040 into C code") Cc: # 5.9.x Signed-off-by: D Scott Phillips Reviewed-by: Marc Zyngier Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomput= ing.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- arch/arm64/kernel/process.c | 39 ++++++++++++++++----------------------- 1 file changed, 16 insertions(+), 23 deletions(-) --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -500,34 +500,26 @@ static void entry_task_switch(struct tas =20 /* * ARM erratum 1418040 handling, affecting the 32bit view of CNTVCT. - * Assuming the virtual counter is enabled at the beginning of times: - * - * - disable access when switching from a 64bit task to a 32bit task - * - enable access when switching from a 32bit task to a 64bit task + * Ensure access is disabled when switching to a 32bit task, ensure + * access is enabled when switching to a 64bit task. */ -static void erratum_1418040_thread_switch(struct task_struct *prev, - struct task_struct *next) +static void erratum_1418040_thread_switch(struct task_struct *next) { - bool prev32, next32; - u64 val; - - if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040)) - return; - - prev32 =3D is_compat_thread(task_thread_info(prev)); - next32 =3D is_compat_thread(task_thread_info(next)); - - if (prev32 =3D=3D next32 || !this_cpu_has_cap(ARM64_WORKAROUND_1418040)) + if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040) || + !this_cpu_has_cap(ARM64_WORKAROUND_1418040)) return; =20 - val =3D read_sysreg(cntkctl_el1); - - if (!next32) - val |=3D ARCH_TIMER_USR_VCT_ACCESS_EN; + if (is_compat_thread(task_thread_info(next))) + sysreg_clear_set(cntkctl_el1, ARCH_TIMER_USR_VCT_ACCESS_EN, 0); else - val &=3D ~ARCH_TIMER_USR_VCT_ACCESS_EN; + sysreg_clear_set(cntkctl_el1, 0, ARCH_TIMER_USR_VCT_ACCESS_EN); +} =20 - write_sysreg(val, cntkctl_el1); +static void erratum_1418040_new_exec(void) +{ + preempt_disable(); + erratum_1418040_thread_switch(current); + preempt_enable(); } =20 /* @@ -546,7 +538,7 @@ __notrace_funcgraph struct task_struct * uao_thread_switch(next); ptrauth_thread_switch(next); ssbs_thread_switch(next); - erratum_1418040_thread_switch(prev, next); + erratum_1418040_thread_switch(next); =20 /* * Complete any pending TLB or cache maintenance on this CPU in case @@ -605,6 +597,7 @@ void arch_setup_new_exec(void) current->mm->context.flags =3D is_compat_task() ? MMCF_AARCH32 : 0; =20 ptrauth_thread_init_user(current); + erratum_1418040_new_exec(); } =20 #ifdef CONFIG_ARM64_TAGGED_ADDR_ABI From nobody Wed Jul 1 03:23:32 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 E87EAC433F5 for ; Mon, 31 Jan 2022 10:58:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244225AbiAaK6b (ORCPT ); Mon, 31 Jan 2022 05:58:31 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:59602 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240414AbiAaK6W (ORCPT ); Mon, 31 Jan 2022 05:58:22 -0500 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 DCDE160AF6; Mon, 31 Jan 2022 10:58:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8CCBC340E8; Mon, 31 Jan 2022 10:58:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626701; bh=zX33FfZApvJ5Vhpb1n8iOw2JtQ1Gf9PODqJa4yO962I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e/ZeAYKUc25aOI3BE+nil3wduUAcM22B3gapU4yWzVQyz4kN8jmR0OufmzQaKqsSD 8s4Ap80MJtcExhpF1ciUG1vmvbRhuOkwR+mUZZU2pL2SsEAWMYWcGS0+iX0OFvW05E HIvABtir8t9M2FQEVV5DALyRnLcJf1qNamI03+kw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pablo Neira Ayuso , Florian Westphal , Steffen Weinreich Subject: [PATCH 5.4 12/64] netfilter: nft_payload: do not update layer 4 checksum when mangling fragments Date: Mon, 31 Jan 2022 11:55:57 +0100 Message-Id: <20220131105216.074681008@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Pablo Neira Ayuso commit 4e1860a3863707e8177329c006d10f9e37e097a8 upstream. IP fragments do not come with the transport header, hence skip bogus layer 4 checksum updates. Fixes: 1814096980bb ("netfilter: nft_payload: layer 4 checksum adjustment f= or pseudoheader fields") Reported-and-tested-by: Steffen Weinreich Signed-off-by: Pablo Neira Ayuso Signed-off-by: Florian Westphal Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/netfilter/nft_payload.c | 3 +++ 1 file changed, 3 insertions(+) --- a/net/netfilter/nft_payload.c +++ b/net/netfilter/nft_payload.c @@ -420,6 +420,9 @@ static int nft_payload_l4csum_offset(con struct sk_buff *skb, unsigned int *l4csum_offset) { + if (pkt->xt.fragoff) + return -1; + switch (pkt->tprot) { case IPPROTO_TCP: *l4csum_offset =3D offsetof(struct tcphdr, check); From nobody Wed Jul 1 03:23:32 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 BFEF6C433F5 for ; Mon, 31 Jan 2022 10:58:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244556AbiAaK6f (ORCPT ); Mon, 31 Jan 2022 05:58:35 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:59668 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240779AbiAaK6Z (ORCPT ); Mon, 31 Jan 2022 05:58:25 -0500 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 E72F860AD6; Mon, 31 Jan 2022 10:58:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD864C340E8; Mon, 31 Jan 2022 10:58:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626704; bh=EClu4GjrOR5bHAUlw9/tGEzgEjXffrX+eOks0piuWQA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=q701v+6UQu+bf4Hd38zvFvr2Y4hkFa59z9GEahniQW7ZuCuZP7Eq4hq5DjLl3fWwI RgoK+QpJK4P4ehsDLCM/SttONpKExXpi6EzW78Omv1Hy/D6k0aEZNx8JwS7HePH4Nv pPoiSI47TNhjI+cluJvHjigRkOSgUtwmb7z9wWhs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robert Hancock Subject: [PATCH 5.4 13/64] serial: 8250: of: Fix mapped region size when using reg-offset property Date: Mon, 31 Jan 2022 11:55:58 +0100 Message-Id: <20220131105216.106208598@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Robert Hancock commit d06b1cf28297e27127d3da54753a3a01a2fa2f28 upstream. 8250_of supports a reg-offset property which is intended to handle cases where the device registers start at an offset inside the region of memory allocated to the device. The Xilinx 16550 UART, for which this support was initially added, requires this. However, the code did not adjust the overall size of the mapped region accordingly, causing the driver to request an area of memory past the end of the device's allocation. For example, if the UART was allocated an address of 0xb0130000, size of 0x10000 and reg-offset of 0x1000 in the device tree, the region of memory reserved was b0131000-b0140fff, which caused the driver for the region starting at b0140000 to fail to probe. Fix this by subtracting reg-offset from the mapped region size. Fixes: b912b5e2cfb3 ([POWERPC] Xilinx: of_serial support for Xilinx uart 16= 550.) Cc: stable Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20220112194214.881844-1-robert.hancock@cali= an.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/tty/serial/8250/8250_of.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/drivers/tty/serial/8250/8250_of.c +++ b/drivers/tty/serial/8250/8250_of.c @@ -105,8 +105,17 @@ static int of_platform_serial_setup(stru port->mapsize =3D resource_size(&resource); =20 /* Check for shifted address mapping */ - if (of_property_read_u32(np, "reg-offset", &prop) =3D=3D 0) + if (of_property_read_u32(np, "reg-offset", &prop) =3D=3D 0) { + if (prop >=3D port->mapsize) { + dev_warn(&ofdev->dev, "reg-offset %u exceeds region size %pa\n", + prop, &port->mapsize); + ret =3D -EINVAL; + goto err_unprepare; + } + port->mapbase +=3D prop; + port->mapsize -=3D prop; + } =20 port->iotype =3D UPIO_MEM; if (of_property_read_u32(np, "reg-io-width", &prop) =3D=3D 0) { From nobody Wed Jul 1 03:23:32 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 140F5C433EF for ; Mon, 31 Jan 2022 10:59:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243029AbiAaK67 (ORCPT ); Mon, 31 Jan 2022 05:58:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240541AbiAaK6d (ORCPT ); Mon, 31 Jan 2022 05:58:33 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BCA30C06174A; Mon, 31 Jan 2022 02:58:29 -0800 (PST) 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 8A965B82A57; Mon, 31 Jan 2022 10:58:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD983C340E8; Mon, 31 Jan 2022 10:58:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626707; bh=2jHehAxg34trZwPG7uzvrdZ+YQzxe23DhyXcvREkmnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=m1/9yD+AfPkiXGhdyXE3YMmryGNnmi55QpW3ah5LVhzLH8j8PYP/DYXYuBiy7WTRL 0CJjGlq7Ol8A+2Cfyvmh1s06TCaAsUaYmUunVlRQ8al/rHc6nOOXj0dQcXA8re/0pD YL72nImXcHp8/MMbrMzXaaXow8NYb/zpRVSHybIU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Erwan Le Ray , Valentin Caron Subject: [PATCH 5.4 14/64] serial: stm32: fix software flow control transfer Date: Mon, 31 Jan 2022 11:55:59 +0100 Message-Id: <20220131105216.149581086@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Valentin Caron commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream. x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty. Fix start_tx condition to allow x_char to be sent. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Cc: stable Signed-off-by: Erwan Le Ray Signed-off-by: Valentin Caron Link: https://lore.kernel.org/r/20220111164441.6178-3-valentin.caron@foss.s= t.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/tty/serial/stm32-usart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/tty/serial/stm32-usart.c +++ b/drivers/tty/serial/stm32-usart.c @@ -536,7 +536,7 @@ static void stm32_start_tx(struct uart_p { struct circ_buf *xmit =3D &port->state->xmit; =20 - if (uart_circ_empty(xmit)) + if (uart_circ_empty(xmit) && !port->x_char) return; =20 stm32_transmit_chars(port); From nobody Wed Jul 1 03:23:32 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 DCFA2C4332F for ; Mon, 31 Jan 2022 10:58:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244033AbiAaK6r (ORCPT ); Mon, 31 Jan 2022 05:58:47 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:46914 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244251AbiAaK6d (ORCPT ); Mon, 31 Jan 2022 05:58:33 -0500 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 B1953B82A5C; Mon, 31 Jan 2022 10:58:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9C3AC340E8; Mon, 31 Jan 2022 10:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626710; bh=inEi6MZyFIrjD+u/UkCk8WlduMCblX7w7gqJwvl//nE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x+T4/n3oJuos4bf9wdlRhnC6qFSKzAZsijIG/nSYthYAbKL7PGgvrsVlp1svbgx5E B2FDT4ntUPHgbDb8+x9D0NTzdRgNBGiIkv9SuZGlC7yDv6LLVNEwelj8n5DYNinl0c Uw9ytp8oqbDSuoIdDD5iccDAHQgHKp83trOD58c4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Starke Subject: [PATCH 5.4 15/64] tty: n_gsm: fix SW flow control encoding/handling Date: Mon, 31 Jan 2022 11:56:00 +0100 Message-Id: <20220131105216.178948164@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: daniel.starke@siemens.com commit 8838b2af23caf1ff0610caef2795d6668a013b2d upstream. n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDeta= ils.aspx?specificationId=3D1516 The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF) are the control characters defined in ISO/IEC 646. These shall be quoted if seen in the data stream to avoid interpretation as flow control characters. ISO/IEC 646 refers to the set of ISO standards described as the ISO 7-bit coded character set for information interchange. Its final version is also known as ITU T.50. See https://www.itu.int/rec/T-REC-T.50-199209-I/en To abide the standard it is needed to quote DC1 and DC3 correctly if these are seen as data bytes and not as control characters. The current implementation already tries to enforce this but fails to catch all defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most significant bit shall be ignored for DC1 and DC3 handling. The current implementation handles only the case with the most significant bit set 0. Cases in which DC1 and DC3 have the most significant bit set 1 are left unhandled. This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only the 7 least significant bits set 1) before comparing them with XON (a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need quotation via byte stuffing. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220120101857.2509-1-daniel.starke@siemens= .com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/tty/n_gsm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -313,6 +313,7 @@ static struct tty_driver *gsm_tty_driver #define GSM1_ESCAPE_BITS 0x20 #define XON 0x11 #define XOFF 0x13 +#define ISO_IEC_646_MASK 0x7F =20 static const struct tty_port_operations gsm_port_ops; =20 @@ -531,7 +532,8 @@ static int gsm_stuff_frame(const u8 *inp int olen =3D 0; while (len--) { if (*input =3D=3D GSM1_SOF || *input =3D=3D GSM1_ESCAPE - || *input =3D=3D XON || *input =3D=3D XOFF) { + || (*input & ISO_IEC_646_MASK) =3D=3D XON + || (*input & ISO_IEC_646_MASK) =3D=3D XOFF) { *output++ =3D GSM1_ESCAPE; *output++ =3D *input++ ^ GSM1_ESCAPE_BITS; olen++; From nobody Wed Jul 1 03:23:32 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 B3843C433F5 for ; Mon, 31 Jan 2022 10:59:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348417AbiAaK7H (ORCPT ); Mon, 31 Jan 2022 05:59:07 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:59774 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243515AbiAaK6e (ORCPT ); Mon, 31 Jan 2022 05:58:34 -0500 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 90F7C60AD6; Mon, 31 Jan 2022 10:58:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79B00C340EF; Mon, 31 Jan 2022 10:58:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626714; bh=dE+HDY6859BIwwahvx9pPj2hSI97g2EgD8qCFDpwe/s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QWnQ8klEvHwm8aq9HhKyuSxJIZ4PGnUMS62cy8nBFQ0nNaPqSRHYhOG6oIV9MRodJ CyPywxaqu6WEfT+XgM7a+9tizpF8kIHP/BTa69gFy1g5xAKGgdX41/75fELW0Qt0eY 2wx8WFDxL8EZr/+fIF0WZ6XagGCluHrDv0OHWOtk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Cameron Williams Subject: [PATCH 5.4 16/64] tty: Add support for Brainboxes UC cards. Date: Mon, 31 Jan 2022 11:56:01 +0100 Message-Id: <20220131105216.209649180@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Cameron Williams commit 152d1afa834c84530828ee031cf07a00e0fc0b8c upstream. This commit adds support for the some of the Brainboxes PCI range of cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279, UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368 and UC-420/431. Signed-off-by: Cameron Williams Cc: stable Link: https://lore.kernel.org/r/AM5PR0202MB2564688493F7DD9B9C610827C45E9@AM= 5PR0202MB2564.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/tty/serial/8250/8250_pci.c | 100 ++++++++++++++++++++++++++++++++= ++++- 1 file changed, 98 insertions(+), 2 deletions(-) --- a/drivers/tty/serial/8250/8250_pci.c +++ b/drivers/tty/serial/8250/8250_pci.c @@ -5130,8 +5130,30 @@ static const struct pci_device_id serial { PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400, PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */ pbn_b2_4_115200 }, + /* Brainboxes Devices */ /* - * BrainBoxes UC-260 + * Brainboxes UC-101 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0BA1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-235/246 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0AA1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_1_115200 }, + /* + * Brainboxes UC-257 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0861, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-260/271/701/756 */ { PCI_VENDOR_ID_INTASHIELD, 0x0D21, PCI_ANY_ID, PCI_ANY_ID, @@ -5139,7 +5161,81 @@ static const struct pci_device_id serial pbn_b2_4_115200 }, { PCI_VENDOR_ID_INTASHIELD, 0x0E34, PCI_ANY_ID, PCI_ANY_ID, - PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, + PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-268 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0841, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-275/279 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0881, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_8_115200 }, + /* + * Brainboxes UC-302 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x08E1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-310 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x08C1, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-313 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x08A3, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-320/324 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0A61, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_1_115200 }, + /* + * Brainboxes UC-346 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0B02, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-357 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0A81, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + { PCI_VENDOR_ID_INTASHIELD, 0x0A83, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_2_115200 }, + /* + * Brainboxes UC-368 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0C41, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, + pbn_b2_4_115200 }, + /* + * Brainboxes UC-420/431 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0921, + PCI_ANY_ID, PCI_ANY_ID, + 0, 0, pbn_b2_4_115200 }, /* * Perle PCI-RAS cards From nobody Wed Jul 1 03:23:32 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 92279C433EF for ; Mon, 31 Jan 2022 10:59:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358416AbiAaK7i (ORCPT ); Mon, 31 Jan 2022 05:59:38 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:59852 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243806AbiAaK6i (ORCPT ); Mon, 31 Jan 2022 05:58:38 -0500 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 6DA7660B3A; Mon, 31 Jan 2022 10:58:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CFC8C340E8; Mon, 31 Jan 2022 10:58:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626716; bh=p9gzYhntkEFFU0kZCVkx2X3WS7L38CrCbtyOn9AY4Z0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0VYZk5nzENTdSbFkc451NuOb7/3bwSoOiTPhkF20IFljlh3mmVVQzyG1lAoQPgPPJ sC3WubN2iH8k96NlMLM9c9CFd6suIrymcLhEFIu/uKgkTgrKBx6EQHkmWn1RlaYtCO eGcK9z1ibWQNtpu4gTtRmQmA1mY/04HWSChSi8ss= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, DocMAX , Alan Stern , =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= Subject: [PATCH 5.4 17/64] usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge Date: Mon, 31 Jan 2022 11:56:02 +0100 Message-Id: <20220131105216.243192293@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@linuxfoundation.org> User-Agent: quilt/0.66 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: Alan Stern commit 5b67b315037250a61861119683e7fcb509deea25 upstream. Two people have reported (and mentioned numerous other reports on the web) that VIA's VL817 USB-SATA bridge does not work with the uas driver. Typical log messages are: [ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 infligh= t: CMD [ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18= 0c c9 80 00 00 00 80 00 00 [ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 1= 1 using xhci_hcd [ 3606.328584] scsi host14: uas_eh_device_reset_handler success Surprisingly, the devices do seem to work okay for some other people. The cause of the differing behaviors is not known. In the hope of getting the devices to work for the most users, even at the possible cost of degraded performance for some, this patch adds an unusual_devs entry for the VL817 to block it from binding to the uas driver by default. Users will be able to override this entry by means of a module parameter, if they want. CC: Reported-by: DocMAX Reported-and-tested-by: Thomas Wei=C3=9Fschuh Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Ye8IsK2sjlEv1rqU@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/usb/storage/unusual_devs.h | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/usb/storage/unusual_devs.h +++ b/drivers/usb/storage/unusual_devs.h @@ -2301,6 +2301,16 @@ UNUSUAL_DEV( 0x2027, 0xa001, 0x0000, 0x USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init, US_FL_SCM_MULT_TARG ), =20 +/* + * Reported by DocMAX + * and Thomas Wei=C3=9Fschuh + */ +UNUSUAL_DEV( 0x2109, 0x0715, 0x9999, 0x9999, + "VIA Labs, Inc.", + "VL817 SATA Bridge", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_IGNORE_UAS), + UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001, "ST", "2A", From nobody Wed Jul 1 03:23:32 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 C2DA0C433EF for ; Mon, 31 Jan 2022 10:59:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348462AbiAaK7P (ORCPT ); Mon, 31 Jan 2022 05:59:15 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:46996 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348403AbiAaK6l (ORCPT ); Mon, 31 Jan 2022 05:58:41 -0500 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 D3DF3B82A5E; Mon, 31 Jan 2022 10:58:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27C68C340E8; Mon, 31 Jan 2022 10:58:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626719; bh=41Bn7dpcwKdRVGJAeUT3KkBCidaikRKvL17gJkZ77QY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XIxjDb3c21FkzYEuVqiM45ESjB23w6UEuXWmEXPkk4TwEosjUzIDD/AhFEsH/8wV9 JKXNpGwYLTdcgnbbTeNF7GP/2H1jJFXspbUQVVR9/8bvXUpbDWT326t4vKG6KUKwFh Dydl67cqncuc6+F52bVuQXOCDEduFWXhAbos8zyM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jon Hunter Subject: [PATCH 5.4 18/64] usb: common: ulpi: Fix crash in ulpi_match() Date: Mon, 31 Jan 2022 11:56:03 +0100 Message-Id: <20220131105216.275584125@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Jon Hunter commit 2e3dd4a6246945bf84ea6f478365d116e661554c upstream. Commit 7495af930835 ("ARM: multi_v7_defconfig: Enable drivers for DragonBoard 410c") enables the CONFIG_PHY_QCOM_USB_HS for the ARM multi_v7_defconfig. Enabling this Kconfig is causing the kernel to crash on the Tegra20 Ventana platform in the ulpi_match() function. The Qualcomm USB HS PHY driver that is enabled by CONFIG_PHY_QCOM_USB_HS, registers a ulpi_driver but this driver does not provide an 'id_table', so when ulpi_match() is called on the Tegra20 Ventana platform, it crashes when attempting to deference the id_table pointer which is not valid. The Qualcomm USB HS PHY driver uses device-tree for matching the ULPI driver with the device and so fix this crash by using device-tree for matching if the id_table is not valid. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Cc: stable Signed-off-by: Jon Hunter Link: https://lore.kernel.org/r/20220117150039.44058-1-jonathanh@nvidia.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/usb/common/ulpi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/usb/common/ulpi.c +++ b/drivers/usb/common/ulpi.c @@ -39,8 +39,11 @@ static int ulpi_match(struct device *dev struct ulpi *ulpi =3D to_ulpi_dev(dev); const struct ulpi_device_id *id; =20 - /* Some ULPI devices don't have a vendor id so rely on OF match */ - if (ulpi->id.vendor =3D=3D 0) + /* + * Some ULPI devices don't have a vendor id + * or provide an id_table so rely on OF match. + */ + if (ulpi->id.vendor =3D=3D 0 || !drv->id_table) return of_driver_match_device(dev, driver); =20 for (id =3D drv->id_table; id->vendor; id++) From nobody Wed Jul 1 03:23:32 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 A08A5C433EF for ; Mon, 31 Jan 2022 10:59:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348401AbiAaK7c (ORCPT ); Mon, 31 Jan 2022 05:59:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244327AbiAaK6p (ORCPT ); Mon, 31 Jan 2022 05:58:45 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 52EB3C061714; Mon, 31 Jan 2022 02:58:45 -0800 (PST) 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 20CA7B82A5C; Mon, 31 Jan 2022 10:58:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C50FC340E8; Mon, 31 Jan 2022 10:58:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626723; bh=ENdP0HiCeo/ou9suAY2/M17r/tqT17x+t6XVJsAoOcM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RUoGT+4ivIP5/5zEhlkfVqxJ+YTgPozoT1fdEY17qq22PCo0YDdGrS7wawgtySzy7 OTAqz70Aw46BGrHMKM9F49asZxT6iqHf3LidZ2aXCG7pBtbaZhNoxQcBNO2ppNkE6u Z0h8wACln/AduUshgLSXK0EK4tXwYQMv4OJPv2GI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavankumar Kondeti Subject: [PATCH 5.4 19/64] usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS Date: Mon, 31 Jan 2022 11:56:04 +0100 Message-Id: <20220131105216.312080252@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Pavankumar Kondeti commit 904edf8aeb459697129be5fde847e2a502f41fd9 upstream. Currently when gadget enumerates in super speed plus, the isoc endpoint request buffer size is not calculated correctly. Fix this by checking the gadget speed against USB_SPEED_SUPER_PLUS and update the request buffer size. Fixes: 90c4d05780d4 ("usb: fix various gadgets null ptr deref on 10gbps cab= ling.") Cc: stable Signed-off-by: Pavankumar Kondeti Link: https://lore.kernel.org/r/1642820602-20619-1-git-send-email-quic_pkon= deti@quicinc.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/usb/gadget/function/f_sourcesink.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/function/f_sourcesink.c +++ b/drivers/usb/gadget/function/f_sourcesink.c @@ -583,6 +583,7 @@ static int source_sink_start_ep(struct f =20 if (is_iso) { switch (speed) { + case USB_SPEED_SUPER_PLUS: case USB_SPEED_SUPER: size =3D ss->isoc_maxpacket * (ss->isoc_mult + 1) * From nobody Wed Jul 1 03:23:32 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 852DCC433FE for ; Mon, 31 Jan 2022 10:59:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358433AbiAaK7l (ORCPT ); Mon, 31 Jan 2022 05:59:41 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:59948 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348439AbiAaK6t (ORCPT ); Mon, 31 Jan 2022 05:58:49 -0500 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 5D2AE60A75; Mon, 31 Jan 2022 10:58:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44F9AC340E8; Mon, 31 Jan 2022 10:58:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626728; bh=AzLDUvZKhjiXaHSVxJMEYJZbDTq15sluSU36IrxlWDQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f/rJtIeD1Oa/9VgwhXeh2V+NcK3KCLNjClE2oFdxJDvh5gtU9bv5snb9WDmMqULrs szMd1b6pPOs6hoWSF18mKW3DZL59HL/SvedysRWhyzTxHMKrqmR1G0iVqJg7Vq8pZp 7HkOsayJFzbiYZFS1rVL2PiL2LWrf1qYj3aAwgiw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alan Stern , syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.com Subject: [PATCH 5.4 20/64] USB: core: Fix hang in usb_kill_urb by adding memory barriers Date: Mon, 31 Jan 2022 11:56:05 +0100 Message-Id: <20220131105216.343049836@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 26fbe9772b8c459687930511444ce443011f86bf upstream. The syzbot fuzzer has identified a bug in which processes hang waiting for usb_kill_urb() to return. It turns out the issue is not unlinking the URB; that works just fine. Rather, the problem arises when the wakeup notification that the URB has completed is not received. The reason is memory-access ordering on SMP systems. In outline form, usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on different CPUs perform the following actions: CPU 0 CPU 1 Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan ---------------------------- --------------------------------- usb_kill_urb(): __usb_hcd_giveback_urb(): ... ... atomic_inc(&urb->reject); atomic_dec(&urb->use_count); ... ... wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) =3D=3D 0); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); Confining your attention to urb->reject and urb->use_count, you can see that the overall pattern of accesses on CPU 0 is: write urb->reject, then read urb->use_count; whereas the overall pattern of accesses on CPU 1 is: write urb->use_count, then read urb->reject. This pattern is referred to in memory-model circles as SB (for "Store Buffering"), and it is well known that without suitable enforcement of the desired order of accesses -- in the form of memory barriers -- it is entirely possible for one or both CPUs to execute their reads ahead of their writes. The end result will be that sometimes CPU 0 sees the old un-decremented value of urb->use_count while CPU 1 sees the old un-incremented value of urb->reject. Consequently CPU 0 ends up on the wait queue and never gets woken up, leading to the observed hang in usb_kill_urb(). The same pattern of accesses occurs in usb_poison_urb() and the failure pathway of usb_hcd_submit_urb(). The problem is fixed by adding suitable memory barriers. To provide proper memory-access ordering in the SB pattern, a full barrier is required on both CPUs. The atomic_inc() and atomic_dec() accesses themselves don't provide any memory ordering, but since they are present, we can use the optimized smp_mb__after_atomic() memory barrier in the various routines to obtain the desired effect. This patch adds the necessary memory barriers. CC: Reported-and-tested-by: syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.c= om Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman --- drivers/usb/core/hcd.c | 14 ++++++++++++++ drivers/usb/core/urb.c | 12 ++++++++++++ 2 files changed, 26 insertions(+) --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -1567,6 +1567,13 @@ int usb_hcd_submit_urb (struct urb *urb, urb->hcpriv =3D NULL; INIT_LIST_HEAD(&urb->urb_list); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + atomic_dec(&urb->dev->urbnum); if (atomic_read(&urb->reject)) wake_up(&usb_kill_urb_queue); @@ -1662,6 +1669,13 @@ static void __usb_hcd_giveback_urb(struc =20 usb_anchor_resume_wakeups(anchor); atomic_dec(&urb->use_count); + /* + * Order the write of urb->use_count above before the read + * of urb->reject below. Pairs with the memory barriers in + * usb_kill_urb() and usb_poison_urb(). + */ + smp_mb__after_atomic(); + if (unlikely(atomic_read(&urb->reject))) wake_up(&usb_kill_urb_queue); usb_put_urb(urb); --- a/drivers/usb/core/urb.c +++ b/drivers/usb/core/urb.c @@ -691,6 +691,12 @@ void usb_kill_urb(struct urb *urb) if (!(urb && urb->dev && urb->ep)) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); =20 usb_hcd_unlink_urb(urb, -ENOENT); wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) =3D=3D 0); @@ -732,6 +738,12 @@ void usb_poison_urb(struct urb *urb) if (!urb) return; atomic_inc(&urb->reject); + /* + * Order the write of urb->reject above before the read + * of urb->use_count below. Pairs with the barriers in + * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). + */ + smp_mb__after_atomic(); =20 if (!urb->dev || !urb->ep) return; From nobody Wed Jul 1 03:23:32 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 864F0C433EF for ; Mon, 31 Jan 2022 10:59:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358444AbiAaK7m (ORCPT ); Mon, 31 Jan 2022 05:59:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348387AbiAaK6x (ORCPT ); Mon, 31 Jan 2022 05:58:53 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08773C061401; Mon, 31 Jan 2022 02:58:53 -0800 (PST) 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 9D5EE60ABE; Mon, 31 Jan 2022 10:58:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FD58C340E8; Mon, 31 Jan 2022 10:58:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626732; bh=ImYMI2kEIGkDJb80MsVasoHkiHC0+iZ8ySDDAdgJNfc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AovQi6EwEjueVvU5wNZRKhRoZnF49Qe2ai0UJlG/bLBmL7j4GdvOXRYydAfAGsM8/ cOhn8UNouR3CTzoo8iKHyeBQk/xsTc27EJCW1amCo+f87SJno2E3OgIgMPrkThCQN7 oxgYCCd5fW+V9zI8+8DYPAFXNNK6Fx6twMd1PGZY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Heikki Krogerus , Badhri Jagan Sridharan Subject: [PATCH 5.4 21/64] usb: typec: tcpm: Do not disconnect while receiving VBUS off Date: Mon, 31 Jan 2022 11:56:06 +0100 Message-Id: <20220131105216.376549759@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Badhri Jagan Sridharan commit 90b8aa9f5b09edae6928c0561f933fec9f7a9987 upstream. With some chargers, vbus might momentarily raise above VSAFE5V and fall back to 0V before tcpm gets to read port->tcpc->get_vbus. This will will report a VBUS off event causing TCPM to transition to SNK_UNATTACHED where it should be waiting in either SNK_ATTACH_WAIT or SNK_DEBOUNCED state. This patch makes TCPM avoid vbus off events while in SNK_ATTACH_WAIT or SNK_DEBOUNCED state. Stub from the spec: "4.5.2.2.4.2 Exiting from AttachWait.SNK State A Sink shall transition to Unattached.SNK when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce. A DRP shall transition to Unattached.SRC when the state of both the CC1 and CC2 pins is SNK.Open for at least tPDDebounce." [23.194131] CC1: 0 -> 0, CC2: 0 -> 5 [state SNK_UNATTACHED, polarity 0, con= nected] [23.201777] state change SNK_UNATTACHED -> SNK_ATTACH_WAIT [rev3 NONE_AMS] [23.209949] pending state change SNK_ATTACH_WAIT -> SNK_DEBOUNCED @ 170 ms = [rev3 NONE_AMS] [23.300579] VBUS off [23.300668] state change SNK_ATTACH_WAIT -> SNK_UNATTACHED [rev3 NONE_AMS] [23.301014] VBUS VSAFE0V [23.301111] Start toggling Fixes: f0690a25a140b8 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable@vger.kernel.org Acked-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20220122015520.332507-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/usb/typec/tcpm/tcpm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -3903,7 +3903,8 @@ static void _tcpm_pd_vbus_off(struct tcp case SNK_TRYWAIT_DEBOUNCE: break; case SNK_ATTACH_WAIT: - tcpm_set_state(port, SNK_UNATTACHED, 0); + case SNK_DEBOUNCED: + /* Do nothing, as TCPM is still waiting for vbus to reaach VSAFE5V to co= nnect */ break; =20 case SNK_NEGOTIATE_CAPABILITIES: From nobody Wed Jul 1 03:23:32 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 E9E3EC433EF for ; Mon, 31 Jan 2022 10:59:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358465AbiAaK7s (ORCPT ); Mon, 31 Jan 2022 05:59:48 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:47170 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347215AbiAaK65 (ORCPT ); Mon, 31 Jan 2022 05:58:57 -0500 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 508F3B82A5B; Mon, 31 Jan 2022 10:58:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87C7DC340E8; Mon, 31 Jan 2022 10:58:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626735; bh=r7uyHTqwIEpWFXAEtLU0400+E6IKEBK6/CX5sFHCkmY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GBcKzo4A15bhqk1jwaHHAuif6ykuR5RI/VY2iPxk7/z+ZOA/yDZiMZBMjau9sDyW1 MyZ6J78y+02QD4Y/KNkO2lK0FfIFsHZa4YlsE7Kb4/bTTmR2pCWSdoO938NZtcyMpp c18MnHjlzZNzIm7XsCm9aLTeQa9LQvJJBtsai+SQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Heikki Krogerus , Sing-Han Chen , Wayne Chang Subject: [PATCH 5.4 22/64] ucsi_ccg: Check DEV_INT bit only when starting CCG4 Date: Mon, 31 Jan 2022 11:56:07 +0100 Message-Id: <20220131105216.409342888@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Sing-Han Chen commit 825911492eb15bf8bb7fb94bc0c0421fe7a6327d upstream. CCGx clears Bit 0:Device Interrupt in the INTR_REG if CCGx is reset successfully. However, there might be a chance that other bits in INTR_REG are not cleared due to internal data queued in PPM. This case misleads the driver that CCGx reset failed. The commit checks bit 0 in INTR_REG and ignores other bits. The ucsi driver would reset PPM later. Fixes: 247c554a14aa ("usb: typec: ucsi: add support for Cypress CCGx") Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Signed-off-by: Sing-Han Chen Signed-off-by: Wayne Chang Link: https://lore.kernel.org/r/20220112094143.628610-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/usb/typec/ucsi/ucsi_ccg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/typec/ucsi/ucsi_ccg.c +++ b/drivers/usb/typec/ucsi/ucsi_ccg.c @@ -304,7 +304,7 @@ static int ucsi_ccg_init(struct ucsi_ccg if (status < 0) return status; =20 - if (!data) + if (!(data & DEV_INT)) return 0; =20 status =3D ccg_write(uc, CCGX_RAB_INTR_REG, &data, sizeof(data)); From nobody Wed Jul 1 03:23:32 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 AFD25C433EF for ; Mon, 31 Jan 2022 10:59:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358322AbiAaK7u (ORCPT ); Mon, 31 Jan 2022 05:59:50 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:47194 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244170AbiAaK7B (ORCPT ); Mon, 31 Jan 2022 05:59:01 -0500 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 5DDD1B82A5C; Mon, 31 Jan 2022 10:58:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99F8AC340EF; Mon, 31 Jan 2022 10:58:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626738; bh=zK74JLsNNG35iN3KFqzkDIftMt6obJHu9qL2hrEwLkU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HUr10TtUv4bheFd26/5cfOaJZ62kfDLW9OjU6N1a8ESjXrPizcqvG+A+n15+x2I1K 0R6NvnBg1JSlYwTM023bMQNji68rRb82IMmWqruMqEiKH4GiB8F/nATpi4An0P73c3 ws3erCy/9dgSOlnKsHj4nzyYkk6K0yuPkoNyfpDY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Marek=20Beh=C3=BAn?= , "David S. Miller" Subject: [PATCH 5.4 23/64] net: sfp: ignore disabled SFP node Date: Mon, 31 Jan 2022 11:56:08 +0100 Message-Id: <20220131105216.448654800@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@linuxfoundation.org> User-Agent: quilt/0.66 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: Marek Beh=C3=BAn commit 2148927e6ed43a1667baf7c2ae3e0e05a44b51a0 upstream. Commit ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") added code which finds SFP bus DT node even if the node is disabled with status =3D "disabled". Because of this, when phylink is created, it ends with non-null .sfp_bus member, even though the SFP module is not probed (because the node is disabled). We need to ignore disabled SFP bus node. Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices an= d sfp cages") Signed-off-by: Marek Beh=C3=BAn Cc: stable@vger.kernel.org # 2203cbf2c8b5 ("net: sfp: move fwnode parsing i= nto sfp-bus layer") Signed-off-by: David S. Miller [ backport to 5.4 ] Signed-off-by: Marek Beh=C3=BAn Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/phy/phylink.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/phy/phylink.c +++ b/drivers/net/phy/phylink.c @@ -582,6 +582,11 @@ static int phylink_register_sfp(struct p return ret; } =20 + if (!fwnode_device_is_available(ref.fwnode)) { + fwnode_handle_put(ref.fwnode); + return 0; + } + pl->sfp_bus =3D sfp_register_upstream(ref.fwnode, pl, &sfp_phylink_ops); if (!pl->sfp_bus) return -ENOMEM; From nobody Wed Jul 1 03:23:32 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 E2E4CC433F5 for ; Mon, 31 Jan 2022 11:00:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358513AbiAaLAA (ORCPT ); Mon, 31 Jan 2022 06:00:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358344AbiAaK7Q (ORCPT ); Mon, 31 Jan 2022 05:59:16 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0B24BC06174E; Mon, 31 Jan 2022 02:59:02 -0800 (PST) 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 9DA7760ABE; Mon, 31 Jan 2022 10:59:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA0D8C340EF; Mon, 31 Jan 2022 10:59:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626741; bh=e2WQ35VBoBcBt40QoBPEn2xr4K/4V24VvJRY9NjJxNQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jHuIPhkLJZWoMK+mp/q41pUouxEsgTrE5AcBWm1Z+BcHDRJ52U2R8u0l03h3WHQGI XpzG0qcWpSNOswuH21RDu75Tt1FP18CpG74DZQqAxqw6AzW2cgZYcMQuLtqRmJ/+ht y1dFrzTLEauY1y7QsOJBq+aTxurtZ97QKXLjn2lU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Erhard Furtner , Christophe Leroy , Michael Ellerman Subject: [PATCH 5.4 24/64] powerpc/32: Fix boot failure with GCC latent entropy plugin Date: Mon, 31 Jan 2022 11:56:09 +0100 Message-Id: <20220131105216.481851495@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Christophe Leroy commit bba496656a73fc1d1330b49c7f82843836e9feb1 upstream. Boot fails with GCC latent entropy plugin enabled. This is due to early boot functions trying to access 'latent_entropy' global data while the kernel is not relocated at its final destination yet. As there is no way to tell GCC to use PTRRELOC() to access it, disable latent entropy plugin in early_32.o and feature-fixups.o and code-patching.o Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") Cc: stable@vger.kernel.org # v4.9+ Reported-by: Erhard Furtner Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D215217 Link: https://lore.kernel.org/r/2bac55483b8daf5b1caa163a45fa5f9cdbe18be4.16= 40178426.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/lib/Makefile | 3 +++ 2 files changed, 4 insertions(+) --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -13,6 +13,7 @@ CFLAGS_prom_init.o +=3D -fPIC CFLAGS_btext.o +=3D -fPIC endif =20 +CFLAGS_early_32.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_cputable.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_prom_init.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) CFLAGS_btext.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) --- a/arch/powerpc/lib/Makefile +++ b/arch/powerpc/lib/Makefile @@ -16,6 +16,9 @@ CFLAGS_code-patching.o +=3D -DDISABLE_BRAN CFLAGS_feature-fixups.o +=3D -DDISABLE_BRANCH_PROFILING endif =20 +CFLAGS_code-patching.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) +CFLAGS_feature-fixups.o +=3D $(DISABLE_LATENT_ENTROPY_PLUGIN) + obj-y +=3D alloc.o code-patching.o feature-fixups.o pmem.o =20 ifndef CONFIG_KASAN From nobody Wed Jul 1 03:23:32 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 6B4E7C433EF for ; Mon, 31 Jan 2022 11:00:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348594AbiAaLAO (ORCPT ); Mon, 31 Jan 2022 06:00:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358374AbiAaK7Y (ORCPT ); Mon, 31 Jan 2022 05:59:24 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 78711C061756; Mon, 31 Jan 2022 02:59:06 -0800 (PST) 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 45077B82A61; Mon, 31 Jan 2022 10:59:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 81C2FC340E8; Mon, 31 Jan 2022 10:59:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626744; bh=rml6SmFqUX/9fx0HeGdsOnY9/GT3ir5zHsysGMI2h8o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QBizVBeaB25nPIsZyvyvvl1YKDNhH+TNzeaPdQxGoIu7jkDJ3wKoPMMaWbgIREMwA ilspyWZezeLexWVhrx25wvOy0g0gijWO2eYvtU2ZbiOieUwxPFOEr0ir0t0L0BI+v5 5VZ17lAg/IW3ZAvcCcuFCX5QIG5Ijlbvwac/Ux14= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Arkadiusz Kubalewski , Jedrzej Jagielski , Gurucharan G , Tony Nguyen Subject: [PATCH 5.4 25/64] i40e: Increase delay to 1 s after global EMP reset Date: Mon, 31 Jan 2022 11:56:10 +0100 Message-Id: <20220131105216.513051719@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Jedrzej Jagielski commit 9b13bd53134c9ddd544a790125199fdbdb505e67 upstream. Recently simplified i40e_rebuild causes that FW sometimes is not ready after NVM update, the ping does not return. Increase the delay in case of EMP reset. Old delay of 300 ms was introduced for specific cards for 710 series. Now it works for all the cards and delay was increased. Fixes: 1fa51a650e1d ("i40e: Add delay after EMP reset for firmware to recov= er") Signed-off-by: Arkadiusz Kubalewski Signed-off-by: Jedrzej Jagielski Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/ethernet/intel/i40e/i40e_main.c | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -10084,15 +10084,9 @@ static void i40e_rebuild(struct i40e_pf } i40e_get_oem_version(&pf->hw); =20 - if (test_bit(__I40E_EMP_RESET_INTR_RECEIVED, pf->state) && - ((hw->aq.fw_maj_ver =3D=3D 4 && hw->aq.fw_min_ver <=3D 33) || - hw->aq.fw_maj_ver < 4) && hw->mac.type =3D=3D I40E_MAC_XL710) { - /* The following delay is necessary for 4.33 firmware and older - * to recover after EMP reset. 200 ms should suffice but we - * put here 300 ms to be sure that FW is ready to operate - * after reset. - */ - mdelay(300); + if (test_and_clear_bit(__I40E_EMP_RESET_INTR_RECEIVED, pf->state)) { + /* The following delay is necessary for firmware update. */ + mdelay(1000); } =20 /* re-verify the eeprom if we just had an EMP reset */ From nobody Wed Jul 1 03:23:32 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 5C266C433F5 for ; Mon, 31 Jan 2022 10:59:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348464AbiAaK76 (ORCPT ); Mon, 31 Jan 2022 05:59:58 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60166 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348430AbiAaK7H (ORCPT ); Mon, 31 Jan 2022 05:59:07 -0500 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 92DB660ABE; Mon, 31 Jan 2022 10:59:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A41F1C340E8; Mon, 31 Jan 2022 10:59:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626747; bh=ikzpM6yMqqarD5b5oWLdMis0x23B4FdoQI5mEmCsh20=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uA8xNufhyh3OWLXNj5OVVHP/eRvMuuQo80ZWgfO5Kn15xOfF6pFFojFH2N7iVs+3O U7jSE4hzcH7sHQAUS6hTTWNt8NHTo51EtsGsmqhG6Z6fB79cUwShgp+DojE/dTkNI3 t9+w5/HgZC5CDlOdhzeZK8TN5NNbaTDYlXdOOXMg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jaroslaw Gawin , Slawomir Laba , Jedrzej Jagielski , Konrad Jankowski , Tony Nguyen Subject: [PATCH 5.4 26/64] i40e: Fix issue when maximum queues is exceeded Date: Mon, 31 Jan 2022 11:56:11 +0100 Message-Id: <20220131105216.550107980@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Jedrzej Jagielski commit d701658a50a471591094b3eb3961b4926cc8f104 upstream. Before this patch VF interface vanished when maximum queue number was exceeded. Driver tried to add next queues even if there was not enough space. PF sent incorrect number of queues to the VF when there were not enough of them. Add an additional condition introduced to check available space in 'qp_pile' before proceeding. This condition makes it impossible to add queues if they number is greater than the number resulting from available space. Also add the search for free space in PF queue pair piles. Without this patch VF interfaces are not seen when available space for queues has been exceeded and following logs appears permanently in dmesg: "Unable to get VF config (-32)". "VF 62 failed opcode 3, retval: -5" "Unable to get VF config due to PF error condition, not retrying" Fixes: 7daa6bf3294e ("i40e: driver core headers") Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Jaroslaw Gawin Signed-off-by: Slawomir Laba Signed-off-by: Jedrzej Jagielski Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/ethernet/intel/i40e/i40e.h | 1=20 drivers/net/ethernet/intel/i40e/i40e_main.c | 14 ---- drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 59 ++++++++++++++++= +++++ 3 files changed, 61 insertions(+), 13 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -182,7 +182,6 @@ enum i40e_interrupt_policy { =20 struct i40e_lump_tracking { u16 num_entries; - u16 search_hint; u16 list[0]; #define I40E_PILE_VALID_BIT 0x8000 #define I40E_IWARP_IRQ_PILE_ID (I40E_PILE_VALID_BIT - 2) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -204,10 +204,6 @@ int i40e_free_virt_mem_d(struct i40e_hw * @id: an owner id to stick on the items assigned * * Returns the base item index of the lump, or negative for error - * - * The search_hint trick and lack of advanced fit-finding only work - * because we're highly likely to have all the same size lump requests. - * Linear search time and any fragmentation should be minimal. **/ static int i40e_get_lump(struct i40e_pf *pf, struct i40e_lump_tracking *pi= le, u16 needed, u16 id) @@ -222,8 +218,7 @@ static int i40e_get_lump(struct i40e_pf return -EINVAL; } =20 - /* start the linear search with an imperfect hint */ - i =3D pile->search_hint; + i =3D 0; while (i < pile->num_entries) { /* skip already allocated entries */ if (pile->list[i] & I40E_PILE_VALID_BIT) { @@ -242,7 +237,6 @@ static int i40e_get_lump(struct i40e_pf for (j =3D 0; j < needed; j++) pile->list[i+j] =3D id | I40E_PILE_VALID_BIT; ret =3D i; - pile->search_hint =3D i + j; break; } =20 @@ -265,7 +259,7 @@ static int i40e_put_lump(struct i40e_lum { int valid_id =3D (id | I40E_PILE_VALID_BIT); int count =3D 0; - int i; + u16 i; =20 if (!pile || index >=3D pile->num_entries) return -EINVAL; @@ -277,8 +271,6 @@ static int i40e_put_lump(struct i40e_lum count++; } =20 - if (count && index < pile->search_hint) - pile->search_hint =3D index; =20 return count; } @@ -11382,7 +11374,6 @@ static int i40e_init_interrupt_scheme(st return -ENOMEM; =20 pf->irq_pile->num_entries =3D vectors; - pf->irq_pile->search_hint =3D 0; =20 /* track first vector for misc interrupts, ignore return */ (void)i40e_get_lump(pf, pf->irq_pile, 1, I40E_PILE_VALID_BIT - 1); @@ -12133,7 +12124,6 @@ static int i40e_sw_init(struct i40e_pf * goto sw_init_done; } pf->qp_pile->num_entries =3D pf->hw.func_caps.num_tx_qp; - pf->qp_pile->search_hint =3D 0; =20 pf->tx_timeout_recovery_level =3D 1; =20 --- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c +++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c @@ -2486,6 +2486,59 @@ error_param: } =20 /** + * i40e_check_enough_queue - find big enough queue number + * @vf: pointer to the VF info + * @needed: the number of items needed + * + * Returns the base item index of the queue, or negative for error + **/ +static int i40e_check_enough_queue(struct i40e_vf *vf, u16 needed) +{ + unsigned int i, cur_queues, more, pool_size; + struct i40e_lump_tracking *pile; + struct i40e_pf *pf =3D vf->pf; + struct i40e_vsi *vsi; + + vsi =3D pf->vsi[vf->lan_vsi_idx]; + cur_queues =3D vsi->alloc_queue_pairs; + + /* if current allocated queues are enough for need */ + if (cur_queues >=3D needed) + return vsi->base_queue; + + pile =3D pf->qp_pile; + if (cur_queues > 0) { + /* if the allocated queues are not zero + * just check if there are enough queues for more + * behind the allocated queues. + */ + more =3D needed - cur_queues; + for (i =3D vsi->base_queue + cur_queues; + i < pile->num_entries; i++) { + if (pile->list[i] & I40E_PILE_VALID_BIT) + break; + + if (more-- =3D=3D 1) + /* there is enough */ + return vsi->base_queue; + } + } + + pool_size =3D 0; + for (i =3D 0; i < pile->num_entries; i++) { + if (pile->list[i] & I40E_PILE_VALID_BIT) { + pool_size =3D 0; + continue; + } + if (needed <=3D ++pool_size) + /* there is enough */ + return i; + } + + return -ENOMEM; +} + +/** * i40e_vc_request_queues_msg * @vf: pointer to the VF info * @msg: pointer to the msg buffer @@ -2519,6 +2572,12 @@ static int i40e_vc_request_queues_msg(st req_pairs - cur_pairs, pf->queues_left); vfres->num_queue_pairs =3D pf->queues_left + cur_pairs; + } else if (i40e_check_enough_queue(vf, req_pairs) < 0) { + dev_warn(&pf->pdev->dev, + "VF %d requested %d more queues, but there is not enough for it.\n", + vf->vf_id, + req_pairs - cur_pairs); + vfres->num_queue_pairs =3D cur_pairs; } else { /* successful request */ vf->num_req_queues =3D req_pairs; From nobody Wed Jul 1 03:23:32 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 5CAA0C433EF for ; Mon, 31 Jan 2022 10:59:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244116AbiAaK7z (ORCPT ); Mon, 31 Jan 2022 05:59:55 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:47310 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348365AbiAaK7M (ORCPT ); Mon, 31 Jan 2022 05:59:12 -0500 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 50469B82A5D; Mon, 31 Jan 2022 10:59:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94EC6C340E8; Mon, 31 Jan 2022 10:59:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626750; bh=imYH5bbG6S86GeRA86TEMDFwEd8PVDGQNFc7gSYzQA0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eyd55errKvymF9KX84rOVK+mQktonV0YyMyFXEOKlugMdHD3Apxtt9+8Bsvam0TCO n4FVQVPAaHFF1Pws6nveMY4zhD28senxiUN6OPOxhbH4/jElp+kVSUPqxNafdujs/1 fjSrMkHckd89gn/IZxoWIQlp0te51fVaIC5kCkC8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sylwester Dziedziuch , Mateusz Palczewski , Maciej Fijalkowski , Kiran Bhandare , Tony Nguyen Subject: [PATCH 5.4 27/64] i40e: Fix queues reservation for XDP Date: Mon, 31 Jan 2022 11:56:12 +0100 Message-Id: <20220131105216.582709802@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Sylwester Dziedziuch commit 92947844b8beee988c0ce17082b705c2f75f0742 upstream. When XDP was configured on a system with large number of CPUs and X722 NIC there was a call trace with NULL pointer dereference. i40e 0000:87:00.0: failed to get tracking for 256 queues for VSI 0 err -12 i40e 0000:87:00.0: setup of MAIN VSI failed BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:i40e_xdp+0xea/0x1b0 [i40e] Call Trace: ? i40e_reconfig_rss_queues+0x130/0x130 [i40e] dev_xdp_install+0x61/0xe0 dev_xdp_attach+0x18a/0x4c0 dev_change_xdp_fd+0x1e6/0x220 do_setlink+0x616/0x1030 ? ahci_port_stop+0x80/0x80 ? ata_qc_issue+0x107/0x1e0 ? lock_timer_base+0x61/0x80 ? __mod_timer+0x202/0x380 rtnl_setlink+0xe5/0x170 ? bpf_lsm_binder_transaction+0x10/0x10 ? security_capable+0x36/0x50 rtnetlink_rcv_msg+0x121/0x350 ? rtnl_calcit.isra.0+0x100/0x100 netlink_rcv_skb+0x50/0xf0 netlink_unicast+0x1d3/0x2a0 netlink_sendmsg+0x22a/0x440 sock_sendmsg+0x5e/0x60 __sys_sendto+0xf0/0x160 ? __sys_getsockname+0x7e/0xc0 ? _copy_from_user+0x3c/0x80 ? __sys_setsockopt+0xc8/0x1a0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f83fa7a39e0 This was caused by PF queue pile fragmentation due to flow director VSI queue being placed right after main VSI. Because of this main VSI was not able to resize its queue allocation for XDP resulting in no queues allocated for main VSI when XDP was turned on. Fix this by always allocating last queue in PF queue pile for a flow director VSI. Fixes: 41c445ff0f48 ("i40e: main driver core") Fixes: 74608d17fe29 ("i40e: add support for XDP_TX action") Signed-off-by: Sylwester Dziedziuch Signed-off-by: Mateusz Palczewski Reviewed-by: Maciej Fijalkowski Tested-by: Kiran Bhandare Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/ethernet/intel/i40e/i40e_main.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -218,6 +218,20 @@ static int i40e_get_lump(struct i40e_pf return -EINVAL; } =20 + /* Allocate last queue in the pile for FDIR VSI queue + * so it doesn't fragment the qp_pile + */ + if (pile =3D=3D pf->qp_pile && pf->vsi[id]->type =3D=3D I40E_VSI_FDIR) { + if (pile->list[pile->num_entries - 1] & I40E_PILE_VALID_BIT) { + dev_err(&pf->pdev->dev, + "Cannot allocate queue %d for I40E_VSI_FDIR\n", + pile->num_entries - 1); + return -ENOMEM; + } + pile->list[pile->num_entries - 1] =3D id | I40E_PILE_VALID_BIT; + return pile->num_entries - 1; + } + i =3D 0; while (i < pile->num_entries) { /* skip already allocated entries */ From nobody Wed Jul 1 03:23:32 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 3B431C433EF for ; Mon, 31 Jan 2022 10:59:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358477AbiAaK7x (ORCPT ); Mon, 31 Jan 2022 05:59:53 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60252 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348448AbiAaK7O (ORCPT ); Mon, 31 Jan 2022 05:59:14 -0500 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 CC97360B03; Mon, 31 Jan 2022 10:59:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9464C340E8; Mon, 31 Jan 2022 10:59:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626753; bh=S6vdptvFv56Eyz0nhwFQ/zLSBlr6zeYcd/EY1HFYt0U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=k+m7CNlt+Mp+V/g/gDBbi0fqfHRmbgEaAH9a3fB7pinJbFWbaqmvbrC3gKYQN0DUx 5nIZewzIvvlG1S99PcqrRECSJa8tbjPcznk76KnUJVJ08TLaZq2kv7mURykIQMlG8h 00rEqQawkvUALn3FQuSXlDghXg/1w5Ud+yTqFWE8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Joe Damato , kernel test robot , Gurucharan G , Tony Nguyen Subject: [PATCH 5.4 28/64] i40e: fix unsigned stat widths Date: Mon, 31 Jan 2022 11:56:13 +0100 Message-Id: <20220131105216.623202023@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Joe Damato commit 3b8428b84539c78fdc8006c17ebd25afd4722d51 upstream. Change i40e_update_vsi_stats and struct i40e_vsi to use u64 fields to match the width of the stats counters in struct i40e_rx_queue_stats. Update debugfs code to use the correct format specifier for u64. Fixes: 41c445ff0f48 ("i40e: main driver core") Signed-off-by: Joe Damato Reported-by: kernel test robot Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/ethernet/intel/i40e/i40e.h | 8 ++++---- drivers/net/ethernet/intel/i40e/i40e_debugfs.c | 2 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 4 ++-- 3 files changed, 7 insertions(+), 7 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e.h +++ b/drivers/net/ethernet/intel/i40e/i40e.h @@ -756,12 +756,12 @@ struct i40e_vsi { struct rtnl_link_stats64 net_stats_offsets; struct i40e_eth_stats eth_stats; struct i40e_eth_stats eth_stats_offsets; - u32 tx_restart; - u32 tx_busy; + u64 tx_restart; + u64 tx_busy; u64 tx_linearize; u64 tx_force_wb; - u32 rx_buf_failed; - u32 rx_page_failed; + u64 rx_buf_failed; + u64 rx_page_failed; =20 /* These are containers of ring pointers, allocated at run-time */ struct i40e_ring **rx_rings; --- a/drivers/net/ethernet/intel/i40e/i40e_debugfs.c +++ b/drivers/net/ethernet/intel/i40e/i40e_debugfs.c @@ -234,7 +234,7 @@ static void i40e_dbg_dump_vsi_seid(struc (unsigned long int)vsi->net_stats_offsets.rx_compressed, (unsigned long int)vsi->net_stats_offsets.tx_compressed); dev_info(&pf->pdev->dev, - " tx_restart =3D %d, tx_busy =3D %d, rx_buf_failed =3D %d, rx_page_f= ailed =3D %d\n", + " tx_restart =3D %llu, tx_busy =3D %llu, rx_buf_failed =3D %llu, rx_= page_failed =3D %llu\n", vsi->tx_restart, vsi->tx_busy, vsi->rx_buf_failed, vsi->rx_page_failed); rcu_read_lock(); --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -804,9 +804,9 @@ static void i40e_update_vsi_stats(struct struct rtnl_link_stats64 *ns; /* netdev stats */ struct i40e_eth_stats *oes; struct i40e_eth_stats *es; /* device's eth stats */ - u32 tx_restart, tx_busy; + u64 tx_restart, tx_busy; struct i40e_ring *p; - u32 rx_page, rx_buf; + u64 rx_page, rx_buf; u64 bytes, packets; unsigned int start; u64 tx_linearize; From nobody Wed Jul 1 03:23:32 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 AEED2C433EF for ; Mon, 31 Jan 2022 11:00:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358527AbiAaLAh (ORCPT ); Mon, 31 Jan 2022 06:00:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243790AbiAaK7v (ORCPT ); Mon, 31 Jan 2022 05:59:51 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E08E6C06173D; Mon, 31 Jan 2022 02:59:18 -0800 (PST) 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 9B4A0B82A5E; Mon, 31 Jan 2022 10:59:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7979C340E8; Mon, 31 Jan 2022 10:59:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626756; bh=GRljlsUiZjmSfP4O6YrXQsag9y6pdD5CSeuzgodm4tA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oz+kvCSQxDWRmks9UOdV3qwNUNftBg+5ksIVSOsSjYTUPBBgyBIU5ckTuxS9E5zSX 0KlWWJjvmeX4cfXqKv65Ryx6bsLcPCuMGc9r/iG/XaA9/c3mWSHzX8u7dJBP3OyV/r 27HkTBuuJa4L2tqyCotbsvLbd42tJlGofeL8TvlU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sujit Kautkar , Matthias Kaehlcke , Mathieu Poirier , Bjorn Andersson , Stephen Boyd Subject: [PATCH 5.4 29/64] rpmsg: char: Fix race between the release of rpmsg_ctrldev and cdev Date: Mon, 31 Jan 2022 11:56:14 +0100 Message-Id: <20220131105216.658489390@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Sujit Kautkar commit b7fb2dad571d1e21173c06cef0bced77b323990a upstream. struct rpmsg_ctrldev contains a struct cdev. The current code frees the rpmsg_ctrldev struct in rpmsg_ctrldev_release_device(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_ctrldev could be freed before the cdev is entirely released, as in the backtrace below. [ 93.625603] ODEBUG: free active (active state 0) object type: timer_list= hint: delayed_work_timer_fn+0x0/0x7c [ 93.636115] WARNING: CPU: 0 PID: 12 at lib/debugobjects.c:488 debug_prin= t_object+0x13c/0x1b0 [ 93.644799] Modules linked in: veth xt_cgroup xt_MASQUERADE rfcomm algif= _hash algif_skcipher af_alg uinput ip6table_nat fuse uvcvideo videobuf2_vma= lloc venus_enc venus_dec videobuf2_dma_contig hci_uart btandroid btqca snd_= soc_rt5682_i2c bluetooth qcom_spmi_temp_alarm snd_soc_rt5682v [ 93.715175] CPU: 0 PID: 12 Comm: kworker/0:1 Tainted: G B = 5.4.163-lockdep #26 [ 93.723855] Hardware name: Google Lazor (rev3 - 8) with LTE (DT) [ 93.730055] Workqueue: events kobject_delayed_cleanup [ 93.735271] pstate: 60c00009 (nZCv daif +PAN +UAO) [ 93.740216] pc : debug_print_object+0x13c/0x1b0 [ 93.744890] lr : debug_print_object+0x13c/0x1b0 [ 93.749555] sp : ffffffacf5bc7940 [ 93.752978] x29: ffffffacf5bc7940 x28: dfffffd000000000 [ 93.758448] x27: ffffffacdb11a800 x26: dfffffd000000000 [ 93.763916] x25: ffffffd0734f856c x24: dfffffd000000000 [ 93.769389] x23: 0000000000000000 x22: ffffffd0733c35b0 [ 93.774860] x21: ffffffd0751994a0 x20: ffffffd075ec27c0 [ 93.780338] x19: ffffffd075199100 x18: 00000000000276e0 [ 93.785814] x17: 0000000000000000 x16: dfffffd000000000 [ 93.791291] x15: ffffffffffffffff x14: 6e6968207473696c [ 93.796768] x13: 0000000000000000 x12: ffffffd075e2b000 [ 93.802244] x11: 0000000000000001 x10: 0000000000000000 [ 93.807723] x9 : d13400dff1921900 x8 : d13400dff1921900 [ 93.813200] x7 : 0000000000000000 x6 : 0000000000000000 [ 93.818676] x5 : 0000000000000080 x4 : 0000000000000000 [ 93.824152] x3 : ffffffd0732a0fa4 x2 : 0000000000000001 [ 93.829628] x1 : ffffffacf5bc7580 x0 : 0000000000000061 [ 93.835104] Call trace: [ 93.837644] debug_print_object+0x13c/0x1b0 [ 93.841963] __debug_check_no_obj_freed+0x25c/0x3c0 [ 93.846987] debug_check_no_obj_freed+0x18/0x20 [ 93.851669] slab_free_freelist_hook+0xbc/0x1e4 [ 93.856346] kfree+0xfc/0x2f4 [ 93.859416] rpmsg_ctrldev_release_device+0x78/0xb8 [ 93.864445] device_release+0x84/0x168 [ 93.868310] kobject_cleanup+0x12c/0x298 [ 93.872356] kobject_delayed_cleanup+0x10/0x18 [ 93.876948] process_one_work+0x578/0x92c [ 93.881086] worker_thread+0x804/0xcf8 [ 93.884963] kthread+0x2a8/0x314 [ 93.888303] ret_from_fork+0x10/0x18 The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del(). Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Signed-off-by: Sujit Kautkar Signed-off-by: Matthias Kaehlcke Reviewed-by: Mathieu Poirier Reviewed-by: Bjorn Andersson Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220110104706.v6.1.Iaac908f3e3149a89190ce0= 06ba166e2d3fd247a3@changeid Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/rpmsg/rpmsg_char.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) --- a/drivers/rpmsg/rpmsg_char.c +++ b/drivers/rpmsg/rpmsg_char.c @@ -462,7 +462,6 @@ static void rpmsg_ctrldev_release_device =20 ida_simple_remove(&rpmsg_ctrl_ida, dev->id); ida_simple_remove(&rpmsg_minor_ida, MINOR(dev->devt)); - cdev_del(&ctrldev->cdev); kfree(ctrldev); } =20 @@ -497,19 +496,13 @@ static int rpmsg_chrdev_probe(struct rpm dev->id =3D ret; dev_set_name(&ctrldev->dev, "rpmsg_ctrl%d", ret); =20 - ret =3D cdev_add(&ctrldev->cdev, dev->devt, 1); + ret =3D cdev_device_add(&ctrldev->cdev, &ctrldev->dev); if (ret) goto free_ctrl_ida; =20 /* We can now rely on the release function for cleanup */ dev->release =3D rpmsg_ctrldev_release_device; =20 - ret =3D device_add(dev); - if (ret) { - dev_err(&rpdev->dev, "device_add failed: %d\n", ret); - put_device(dev); - } - dev_set_drvdata(&rpdev->dev, ctrldev); =20 return ret; @@ -535,7 +528,7 @@ static void rpmsg_chrdev_remove(struct r if (ret) dev_warn(&rpdev->dev, "failed to nuke endpoints: %d\n", ret); =20 - device_del(&ctrldev->dev); + cdev_device_del(&ctrldev->cdev, &ctrldev->dev); put_device(&ctrldev->dev); } =20 From nobody Wed Jul 1 03:23:32 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 1C290C433EF for ; Mon, 31 Jan 2022 11:00:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358377AbiAaLAn (ORCPT ); Mon, 31 Jan 2022 06:00:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358471AbiAaK7w (ORCPT ); Mon, 31 Jan 2022 05:59:52 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D569FC061401; Mon, 31 Jan 2022 02:59:24 -0800 (PST) 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 9A070B82A57; Mon, 31 Jan 2022 10:59:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8F67DC340E8; Mon, 31 Jan 2022 10:59:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626762; bh=Wz/w4hNDWFLR4+ezkUUBoMewqb0kz+Z+JvTo/zU9V9w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z6ajhU7LfXz9zEwZvmQAYdwczLZBgyVJ5l76Omkh4g5ivSi8tD4Z5KuIn3fK3LT5g RwAz2KvgHy3nIPxnkPcB3k7qeJwe90Cz9PcrKGIOdVRklU+Pklw8mFAGfOEOQXCykL OEuaSYlFKaww5AT2F1Sfdsr0RpgTiU4AxM7dnD7s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Bjorn Andersson , Matthias Kaehlcke , Mathieu Poirier , Stephen Boyd Subject: [PATCH 5.4 30/64] rpmsg: char: Fix race between the release of rpmsg_eptdev and cdev Date: Mon, 31 Jan 2022 11:56:15 +0100 Message-Id: <20220131105216.690902742@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Matthias Kaehlcke commit 7a534ae89e34e9b51acb5a63dd0f88308178b46a upstream. struct rpmsg_eptdev contains a struct cdev. The current code frees the rpmsg_eptdev struct in rpmsg_eptdev_destroy(), but the cdev is a managed object, therefore its release is not predictable and the rpmsg_eptdev could be freed before the cdev is entirely released. The cdev_device_add/del() API was created to address this issue (see commit '233ed09d7fda ("chardev: add helper function to register char devs with a struct device")'), use it instead of cdev add/del(). Fixes: c0cdc19f84a4 ("rpmsg: Driver for user space endpoint interface") Suggested-by: Bjorn Andersson Signed-off-by: Matthias Kaehlcke Reviewed-by: Mathieu Poirier Reviewed-by: Stephen Boyd Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220110104706.v6.2.Idde68b05b88d4a2e6e5476= 6c653f3a6d9e419ce6@changeid Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/rpmsg/rpmsg_char.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) --- a/drivers/rpmsg/rpmsg_char.c +++ b/drivers/rpmsg/rpmsg_char.c @@ -92,7 +92,7 @@ static int rpmsg_eptdev_destroy(struct d /* wake up any blocked readers */ wake_up_interruptible(&eptdev->readq); =20 - device_del(&eptdev->dev); + cdev_device_del(&eptdev->cdev, &eptdev->dev); put_device(&eptdev->dev); =20 return 0; @@ -336,7 +336,6 @@ static void rpmsg_eptdev_release_device( =20 ida_simple_remove(&rpmsg_ept_ida, dev->id); ida_simple_remove(&rpmsg_minor_ida, MINOR(eptdev->dev.devt)); - cdev_del(&eptdev->cdev); kfree(eptdev); } =20 @@ -381,19 +380,13 @@ static int rpmsg_eptdev_create(struct rp dev->id =3D ret; dev_set_name(dev, "rpmsg%d", ret); =20 - ret =3D cdev_add(&eptdev->cdev, dev->devt, 1); + ret =3D cdev_device_add(&eptdev->cdev, &eptdev->dev); if (ret) goto free_ept_ida; =20 /* We can now rely on the release function for cleanup */ dev->release =3D rpmsg_eptdev_release_device; =20 - ret =3D device_add(dev); - if (ret) { - dev_err(dev, "device_add failed: %d\n", ret); - put_device(dev); - } - return ret; =20 free_ept_ida: From nobody Wed Jul 1 03:23:32 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 6C109C433F5 for ; Mon, 31 Jan 2022 11:00:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358413AbiAaLAH (ORCPT ); Mon, 31 Jan 2022 06:00:07 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60416 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358387AbiAaK70 (ORCPT ); Mon, 31 Jan 2022 05:59:26 -0500 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 0628260B2E; Mon, 31 Jan 2022 10:59:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB18BC340E8; Mon, 31 Jan 2022 10:59:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626765; bh=lRIxAQRuIbiEZInmHSdCwwYZQESUK+uniNe1nS9nRSo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=07oSr1jc0U+PVj2VUOXwuSn7YZpgMfZMCS/zdiOrKLO5ohuRHwRc00BwtZeUbWT2u H9BxCWY+usfR3jO/MJ4UBbUAO8/o6yO72jdV5ERBa8WmbNLQmTz5ekWZo908yMseQy pHdPs9ezNitS843ss647UTKX4Nznc7Pa+vy5+ChI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guangwu Zhang , Maurizio Lombardi , John Meneghini , "Martin K. Petersen" Subject: [PATCH 5.4 31/64] scsi: bnx2fc: Flush destroy_work queue before calling bnx2fc_interface_put() Date: Mon, 31 Jan 2022 11:56:16 +0100 Message-Id: <20220131105216.728297562@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: John Meneghini commit 847f9ea4c5186fdb7b84297e3eeed9e340e83fce upstream. The bnx2fc_destroy() functions are removing the interface before calling destroy_work. This results multiple WARNings from sysfs_remove_group() as the controller rport device attributes are removed too early. Replace the fcoe_port's destroy_work queue. It's not needed. The problem is easily reproducible with the following steps. Example: $ dmesg -w & $ systemctl enable --now fcoe $ fipvlan -s -c ens2f1 $ fcoeadm -d ens2f1.802 [ 583.464488] host2: libfc: Link down on port (7500a1) [ 583.472651] bnx2fc: 7500a1 - rport not created Yet!! [ 583.490468] ------------[ cut here ]------------ [ 583.538725] sysfs group 'power' not found for kobject 'rport-2:0-0' [ 583.568814] WARNING: CPU: 3 PID: 192 at fs/sysfs/group.c:279 sysfs_rem= ove_group+0x6f/0x80 [ 583.607130] Modules linked in: dm_service_time 8021q garp mrp stp llc = bnx2fc cnic uio rpcsec_gss_krb5 auth_rpcgss nfsv4 ... [ 583.942994] CPU: 3 PID: 192 Comm: kworker/3:2 Kdump: loaded Not tainte= d 5.14.0-39.el9.x86_64 #1 [ 583.984105] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013 [ 584.016535] Workqueue: fc_wq_2 fc_rport_final_delete [scsi_transport_f= c] [ 584.050691] RIP: 0010:sysfs_remove_group+0x6f/0x80 [ 584.074725] Code: ff 5b 48 89 ef 5d 41 5c e9 ee c0 ff ff 48 89 ef e8 f= 6 b8 ff ff eb d1 49 8b 14 24 48 8b 33 48 c7 c7 ... [ 584.162586] RSP: 0018:ffffb567c15afdc0 EFLAGS: 00010282 [ 584.188225] RAX: 0000000000000000 RBX: ffffffff8eec4220 RCX: 000000000= 0000000 [ 584.221053] RDX: ffff8c1586ce84c0 RSI: ffff8c1586cd7cc0 RDI: ffff8c158= 6cd7cc0 [ 584.255089] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb567c= 15afc00 [ 584.287954] R10: ffffb567c15afbf8 R11: ffffffff8fbe7f28 R12: ffff8c148= 6326400 [ 584.322356] R13: ffff8c1486326480 R14: ffff8c1483a4a000 R15: 000000000= 0000004 [ 584.355379] FS: 0000000000000000(0000) GS:ffff8c1586cc0000(0000) knlG= S:0000000000000000 [ 584.394419] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 584.421123] CR2: 00007fe95a6f7840 CR3: 0000000107674002 CR4: 000000000= 00606e0 [ 584.454888] Call Trace: [ 584.466108] device_del+0xb2/0x3e0 [ 584.481701] device_unregister+0x13/0x60 [ 584.501306] bsg_unregister_queue+0x5b/0x80 [ 584.522029] bsg_remove_queue+0x1c/0x40 [ 584.541884] fc_rport_final_delete+0xf3/0x1d0 [scsi_transport_fc] [ 584.573823] process_one_work+0x1e3/0x3b0 [ 584.592396] worker_thread+0x50/0x3b0 [ 584.609256] ? rescuer_thread+0x370/0x370 [ 584.628877] kthread+0x149/0x170 [ 584.643673] ? set_kthread_struct+0x40/0x40 [ 584.662909] ret_from_fork+0x22/0x30 [ 584.680002] ---[ end trace 53575ecefa942ece ]--- Link: https://lore.kernel.org/r/20220115040044.1013475-1-jmeneghi@redhat.com Fixes: 0cbf32e1681d ("[SCSI] bnx2fc: Avoid calling bnx2fc_if_destroy with u= nnecessary locks") Tested-by: Guangwu Zhang Co-developed-by: Maurizio Lombardi Signed-off-by: Maurizio Lombardi Signed-off-by: John Meneghini Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) --- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c +++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c @@ -80,7 +80,7 @@ static int bnx2fc_bind_pcidev(struct bnx static void bnx2fc_unbind_pcidev(struct bnx2fc_hba *hba); static struct fc_lport *bnx2fc_if_create(struct bnx2fc_interface *interfac= e, struct device *parent, int npiv); -static void bnx2fc_destroy_work(struct work_struct *work); +static void bnx2fc_port_destroy(struct fcoe_port *port); =20 static struct bnx2fc_hba *bnx2fc_hba_lookup(struct net_device *phys_dev); static struct bnx2fc_interface *bnx2fc_interface_lookup(struct net_device @@ -902,9 +902,6 @@ static void bnx2fc_indicate_netevent(voi __bnx2fc_destroy(interface); } mutex_unlock(&bnx2fc_dev_lock); - - /* Ensure ALL destroy work has been completed before return */ - flush_workqueue(bnx2fc_wq); return; =20 default: @@ -1211,8 +1208,8 @@ static int bnx2fc_vport_destroy(struct f mutex_unlock(&n_port->lp_mutex); bnx2fc_free_vport(interface->hba, port->lport); bnx2fc_port_shutdown(port->lport); + bnx2fc_port_destroy(port); bnx2fc_interface_put(interface); - queue_work(bnx2fc_wq, &port->destroy_work); return 0; } =20 @@ -1521,7 +1518,6 @@ static struct fc_lport *bnx2fc_if_create port->lport =3D lport; port->priv =3D interface; port->get_netdev =3D bnx2fc_netdev; - INIT_WORK(&port->destroy_work, bnx2fc_destroy_work); =20 /* Configure fcoe_port */ rc =3D bnx2fc_lport_config(lport); @@ -1649,8 +1645,8 @@ static void __bnx2fc_destroy(struct bnx2 bnx2fc_interface_cleanup(interface); bnx2fc_stop(interface); list_del(&interface->list); + bnx2fc_port_destroy(port); bnx2fc_interface_put(interface); - queue_work(bnx2fc_wq, &port->destroy_work); } =20 /** @@ -1691,15 +1687,12 @@ netdev_err: return rc; } =20 -static void bnx2fc_destroy_work(struct work_struct *work) +static void bnx2fc_port_destroy(struct fcoe_port *port) { - struct fcoe_port *port; struct fc_lport *lport; =20 - port =3D container_of(work, struct fcoe_port, destroy_work); lport =3D port->lport; - - BNX2FC_HBA_DBG(lport, "Entered bnx2fc_destroy_work\n"); + BNX2FC_HBA_DBG(lport, "Entered %s, destroying lport %p\n", __func__, lpor= t); =20 bnx2fc_if_destroy(lport); } @@ -2553,9 +2546,6 @@ static void bnx2fc_ulp_exit(struct cnic_ __bnx2fc_destroy(interface); mutex_unlock(&bnx2fc_dev_lock); =20 - /* Ensure ALL destroy work has been completed before return */ - flush_workqueue(bnx2fc_wq); - bnx2fc_ulp_stop(hba); /* unregister cnic device */ if (test_and_clear_bit(BNX2FC_CNIC_REGISTERED, &hba->reg_with_cnic)) From nobody Wed Jul 1 03:23:32 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 DC5B7C433EF for ; Mon, 31 Jan 2022 11:00:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348492AbiAaLAR (ORCPT ); Mon, 31 Jan 2022 06:00:17 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60464 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358392AbiAaK73 (ORCPT ); Mon, 31 Jan 2022 05:59:29 -0500 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 4F6A560A75; Mon, 31 Jan 2022 10:59:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D745C340E8; Mon, 31 Jan 2022 10:59:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626768; bh=hIfUf3yN1UNeN2vT8cU48/YWdF/Y5IljBCJYrJJAObw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KW62loPjZ7aGyngYfcTL7pSMSaRyiwcrA+v/0Xg3oDaL44Avfec/j+ORItfvncVXI 7eW7HaHaKYmSknMMVKS+YedaMlH4Hm39D8XX0xGKpv6oB2ZsFA38UUT+eRp/b/PuMa MZ0FUG51yY5EJqkLG4w6nVmyFpwbTLnY0f+8tf5c= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Maksym Yaremchuk , Ido Schimmel , Amit Cohen , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 32/64] ipv6_tunnel: Rate limit warning messages Date: Mon, 31 Jan 2022 11:56:17 +0100 Message-Id: <20220131105216.758612243@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Ido Schimmel commit 6cee105e7f2ced596373951d9ea08dacc3883c68 upstream. The warning messages can be invoked from the data path for every packet transmitted through an ip6gre netdev, leading to high CPU utilization. Fix that by rate limiting the messages. Fixes: 09c6bbf090ec ("[IPV6]: Do mandatory IPv6 tunnel endpoint checks in r= ealtime") Reported-by: Maksym Yaremchuk Tested-by: Maksym Yaremchuk Signed-off-by: Ido Schimmel Reviewed-by: Amit Cohen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/ipv6/ip6_tunnel.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1000,14 +1000,14 @@ int ip6_tnl_xmit_ctl(struct ip6_tnl *t, =20 if (unlikely(!ipv6_chk_addr_and_flags(net, laddr, ldev, false, 0, IFA_F_TENTATIVE))) - pr_warn("%s xmit: Local address not yet configured!\n", - p->name); + pr_warn_ratelimited("%s xmit: Local address not yet configured!\n", + p->name); else if (!(p->flags & IP6_TNL_F_ALLOW_LOCAL_REMOTE) && !ipv6_addr_is_multicast(raddr) && unlikely(ipv6_chk_addr_and_flags(net, raddr, ldev, true, 0, IFA_F_TENTATIVE))) - pr_warn("%s xmit: Routing loop! Remote address found on this node!\n", - p->name); + pr_warn_ratelimited("%s xmit: Routing loop! Remote address found on thi= s node!\n", + p->name); else ret =3D 1; rcu_read_unlock(); From nobody Wed Jul 1 03:23:32 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 D3AE7C433EF for ; Mon, 31 Jan 2022 11:01:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358744AbiAaLBS (ORCPT ); Mon, 31 Jan 2022 06:01:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358587AbiAaLAU (ORCPT ); Mon, 31 Jan 2022 06:00:20 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD7F5C0613DC; Mon, 31 Jan 2022 02:59:32 -0800 (PST) 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 5F67360B28; Mon, 31 Jan 2022 10:59:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29FACC340E8; Mon, 31 Jan 2022 10:59:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626771; bh=K8uS/L0iTWLq7FlRCD2DFohHBclcjVpDwfvTy1cfNPY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vghOg05tLX8fxb9CV3luRlbPQTlckdq9EGGtgXTmWc/hPH4Dn4Sq/eIN7vypur1FU IBN2TTO/3J5/DPRAMa4+RWL6YHAbNJbDDy3ekXeqyinkKvOCLwo19kJcl9m/Fv6/d6 k2KBQeJMwAazTkyEctirjsfjsPwLNQRddEuoTbj0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, huangshaobo , Ard Biesheuvel , "Russell King (Oracle)" Subject: [PATCH 5.4 33/64] ARM: 9170/1: fix panic when kasan and kprobe are enabled Date: Mon, 31 Jan 2022 11:56:18 +0100 Message-Id: <20220131105216.796938973@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: sparkhuang commit 8b59b0a53c840921b625378f137e88adfa87647e upstream. arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 : e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd =3D ecb46400 [00000090] *pgd=3D2e0fa003, *pmd=3D00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit =3D 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) Fixes: 35aa1df43283 ("ARM kprobes: instruction single-stepping support") Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Signed-off-by: huangshaobo Acked-by: Ard Biesheuvel Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- arch/arm/probes/kprobes/Makefile | 3 +++ 1 file changed, 3 insertions(+) --- a/arch/arm/probes/kprobes/Makefile +++ b/arch/arm/probes/kprobes/Makefile @@ -1,4 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 +KASAN_SANITIZE_actions-common.o :=3D n +KASAN_SANITIZE_actions-arm.o :=3D n +KASAN_SANITIZE_actions-thumb.o :=3D n obj-$(CONFIG_KPROBES) +=3D core.o actions-common.o checkers-common.o obj-$(CONFIG_ARM_KPROBES_TEST) +=3D test-kprobes.o test-kprobes-objs :=3D test-core.o From nobody Wed Jul 1 03:23:32 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 C2AC8C4332F for ; Mon, 31 Jan 2022 11:00:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243891AbiAaLAV (ORCPT ); Mon, 31 Jan 2022 06:00:21 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60570 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358417AbiAaK7i (ORCPT ); Mon, 31 Jan 2022 05:59:38 -0500 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 8884760AF6; Mon, 31 Jan 2022 10:59:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4481DC340E8; Mon, 31 Jan 2022 10:59:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626774; bh=3XIa/muwBTvvKBs3bdBiG2V3lDx1LVelKRjXVwnkQCc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZVv5WGyvNc5BcOkw49C29NtI/LS8t+EC9rX10+uNGRUAkMuatbAYIgGs/gV3iMiHw JySnrZoqKtoXAIVx/YugQY9mQIEMjHe0sWOF1cTfww8i/XVNE+8kWh8LiNWbN+SoCg kF12dM1YPD2YueoNZGjuqoDbvsE+9TxsQrNxySO8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Congyu Liu , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 34/64] net: fix information leakage in /proc/net/ptype Date: Mon, 31 Jan 2022 11:56:19 +0100 Message-Id: <20220131105216.838034920@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Congyu Liu commit 47934e06b65637c88a762d9c98329ae6e3238888 upstream. In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new `packet_type` added by this packet socket by reading `/proc/net/ptype` file. This is minor information leakage as packet socket is namespace aware. Add a net pointer in `packet_type` to keep the net namespace of of corresponding packet socket. In `ptype_seq_show`, this net pointer must be checked when it is not NULL. Fixes: 2feb27dbe00c ("[NETNS]: Minor information leak via /proc/net/ptype f= ile.") Signed-off-by: Congyu Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- include/linux/netdevice.h | 1 + net/core/net-procfs.c | 3 ++- net/packet/af_packet.c | 2 ++ 3 files changed, 5 insertions(+), 1 deletion(-) --- a/include/linux/netdevice.h +++ b/include/linux/netdevice.h @@ -2397,6 +2397,7 @@ struct packet_type { struct net_device *); bool (*id_match)(struct packet_type *ptype, struct sock *sk); + struct net *af_packet_net; void *af_packet_priv; struct list_head list; }; --- a/net/core/net-procfs.c +++ b/net/core/net-procfs.c @@ -252,7 +252,8 @@ static int ptype_seq_show(struct seq_fil =20 if (v =3D=3D SEQ_START_TOKEN) seq_puts(seq, "Type Device Function\n"); - else if (pt->dev =3D=3D NULL || dev_net(pt->dev) =3D=3D seq_file_net(seq)= ) { + else if ((!pt->af_packet_net || net_eq(pt->af_packet_net, seq_file_net(se= q))) && + (!pt->dev || net_eq(dev_net(pt->dev), seq_file_net(seq)))) { if (pt->type =3D=3D htons(ETH_P_ALL)) seq_puts(seq, "ALL "); else --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -1715,6 +1715,7 @@ static int fanout_add(struct sock *sk, u match->prot_hook.dev =3D po->prot_hook.dev; match->prot_hook.func =3D packet_rcv_fanout; match->prot_hook.af_packet_priv =3D match; + match->prot_hook.af_packet_net =3D read_pnet(&match->net); match->prot_hook.id_match =3D match_fanout_group; list_add(&match->list, &fanout_list); } @@ -3294,6 +3295,7 @@ static int packet_create(struct net *net po->prot_hook.func =3D packet_rcv_spkt; =20 po->prot_hook.af_packet_priv =3D sk; + po->prot_hook.af_packet_net =3D sock_net(sk); =20 if (proto) { po->prot_hook.type =3D proto; From nobody Wed Jul 1 03:23:32 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 BA877C433EF for ; Mon, 31 Jan 2022 11:04:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358635AbiAaLE1 (ORCPT ); Mon, 31 Jan 2022 06:04:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359145AbiAaLDB (ORCPT ); Mon, 31 Jan 2022 06:03:01 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF1B4C0612F4; Mon, 31 Jan 2022 03:01:30 -0800 (PST) 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 4F2D760B2C; Mon, 31 Jan 2022 11:01:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 336D4C340E8; Mon, 31 Jan 2022 11:01:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626889; bh=7E9ERDVZttx1BEkbi9cB6zU2U3oaHnyBYoXJvVBibGo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=y3LjrInQv9UWJA3SJixuti5031CoKQddjkGKFWdPIuJ4k+z1Y0PjFM3QOIeTGGYNp XHPVjQOyXICWPxovOwbZfh9QODwPrxoVjyClhMCMYYOBzW/6FT6ZdMKuHu/GDoQwG2 hUv3VcBBWvW6PJf4FIcGwyFSgrymqmncMeSxf8CM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck Subject: [PATCH 5.4 35/64] hwmon: (lm90) Mark alert as broken for MAX6646/6647/6649 Date: Mon, 31 Jan 2022 11:56:20 +0100 Message-Id: <20220131105216.868584958@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Guenter Roeck commit f614629f9c1080dcc844a8430e3fb4c37ebbf05d upstream. Experiments with MAX6646 and MAX6648 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -394,7 +394,7 @@ static const struct lm90_params lm90_par .max_convrate =3D 9, }, [max6646] =3D { - .flags =3D LM90_HAVE_CRIT, + .flags =3D LM90_HAVE_CRIT | LM90_HAVE_BROKEN_ALERT, .alert_alarms =3D 0x7c, .max_convrate =3D 6, .reg_local_ext =3D MAX6657_REG_R_LOCAL_TEMPL, From nobody Wed Jul 1 03:23:32 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 14622C433EF for ; Mon, 31 Jan 2022 11:02:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237880AbiAaLCa (ORCPT ); Mon, 31 Jan 2022 06:02:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358755AbiAaLBT (ORCPT ); Mon, 31 Jan 2022 06:01:19 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86460C061392; Mon, 31 Jan 2022 03:00:01 -0800 (PST) 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 52EC2B82A57; Mon, 31 Jan 2022 11:00:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86F54C340E8; Mon, 31 Jan 2022 10:59:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626799; bh=0EFvWCyzPTR972W2aSbT7/hxxvBhl8DPD0Oj9l1LhLE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uKfRVeCJJD9AyjlCrGHqSzHUOysIOhn8Xsd+gMnfn6YFBCbcfdhcFY6WyVcCIoohp QU3Amm8JRZzm+63k2MSBmtOD5zL32Wc4OIz5CD95HfpqlaO+Gcqxr3fCZrw1YenIEp /mikEq9Ib1jzWsmZiCrUPxfHw9FmmrF2ViLiJa+U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck , Sasha Levin Subject: [PATCH 5.4 36/64] hwmon: (lm90) Mark alert as broken for MAX6680 Date: Mon, 31 Jan 2022 11:56:21 +0100 Message-Id: <20220131105216.900187278@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Guenter Roeck commit 94746b0ba479743355e0d3cc1cb9cfe3011fb8be upstream. Experiments with MAX6680 and MAX6681 show that the alert function of those chips is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 4667bcb8d8fc ("hwmon: (lm90) Introduce chip parameter structure") Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -418,7 +418,7 @@ static const struct lm90_params lm90_par }, [max6680] =3D { .flags =3D LM90_HAVE_OFFSET | LM90_HAVE_CRIT - | LM90_HAVE_CRIT_ALRM_SWP, + | LM90_HAVE_CRIT_ALRM_SWP | LM90_HAVE_BROKEN_ALERT, .alert_alarms =3D 0x7c, .max_convrate =3D 7, }, From nobody Wed Jul 1 03:23:32 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 B05DAC433EF for ; Mon, 31 Jan 2022 11:04:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358793AbiAaLEq (ORCPT ); Mon, 31 Jan 2022 06:04:46 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42842 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358449AbiAaLCW (ORCPT ); Mon, 31 Jan 2022 06:02:22 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B613C061769; Mon, 31 Jan 2022 03:00:36 -0800 (PST) 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 08196B82A5F; Mon, 31 Jan 2022 11:00:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6370EC340E8; Mon, 31 Jan 2022 11:00:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626833; bh=pprbZsg+C92F/5sdWdHZshcc/eOL9hMtUXknEI2V4gg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XotECHmPjk9O0L5lvD/cEr/tH6iE418LtXaPGdAdsxzokpA+NWo4zBpW8mq6E67x+ ycDuBTikh0v3hWZrAkEC0KPqh1Iz3KtX7IqUwuf7JDtRcB941wYT9qwWWaT2Xi4M1L 6/emaA0T9OCkwh4ZohjQz7WtFU4l+1D9F7dgIWmg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hangbin Liu , Xin Long , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 37/64] ping: fix the sk_bound_dev_if match in ping_lookup Date: Mon, 31 Jan 2022 11:56:22 +0100 Message-Id: <20220131105216.930543828@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Xin Long commit 2afc3b5a31f9edf3ef0f374f5d70610c79c93a42 upstream. When 'ping' changes to use PING socket instead of RAW socket by: # sysctl -w net.ipv4.ping_group_range=3D"0 100" the selftests 'router_broadcast.sh' will fail, as such command # ip vrf exec vrf-h1 ping -I veth0 198.51.100.255 -b can't receive the response skb by the PING socket. It's caused by mismatch of sk_bound_dev_if and dif in ping_rcv() when looking up the PING socket, as dif is vrf-h1 if dif's master was set to vrf-h1. This patch is to fix this regression by also checking the sk_bound_dev_if against sdif so that the packets can stil be received even if the socket is not bound to the vrf device but to the real iif. Fixes: c319b4d76b9e ("net: ipv4: add IPPROTO_ICMP socket kind") Reported-by: Hangbin Liu Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/ipv4/ping.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/ipv4/ping.c +++ b/net/ipv4/ping.c @@ -220,7 +220,8 @@ static struct sock *ping_lookup(struct n continue; } =20 - if (sk->sk_bound_dev_if && sk->sk_bound_dev_if !=3D dif) + if (sk->sk_bound_dev_if && sk->sk_bound_dev_if !=3D dif && + sk->sk_bound_dev_if !=3D inet_sdif(skb)) continue; =20 sock_hold(sk); From nobody Wed Jul 1 03:23:32 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 E9369C433EF for ; Mon, 31 Jan 2022 11:05:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358940AbiAaLFK (ORCPT ); Mon, 31 Jan 2022 06:05:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359074AbiAaLCx (ORCPT ); Mon, 31 Jan 2022 06:02:53 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 54106C061373; Mon, 31 Jan 2022 03:01:08 -0800 (PST) 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 6448360B9C; Mon, 31 Jan 2022 11:01:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2F975C340E8; Mon, 31 Jan 2022 11:01:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626867; bh=tXZ+7dvf12dco54niTjCNvirBlrte9jCHP9j93/5Tro=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vQGZpIQqP2pU4V8gGZ+cYied4tLTfwJZxqEJf5DaeAr6vfGtGvLSMQu1sy/V52WZN vydq/jx1o1D5F93wP3QAKIp/CeoN1nP3UBF1AEIhlj8IG9F6l/4m2zWY5wAek5lN6D G0Dx9t+ghnGPxr8H+akIF44vcq+FFG0RUdYkGteM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , David Ahern , Ray Che , Willy Tarreau , Jakub Kicinski Subject: [PATCH 5.4 38/64] ipv4: avoid using shared IP generator for connected sockets Date: Mon, 31 Jan 2022 11:56:23 +0100 Message-Id: <20220131105216.962973200@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 commit 23f57406b82de51809d5812afd96f210f8b627f3 upstream. ip_select_ident_segs() has been very conservative about using the connected socket private generator only for packets with IP_DF set, claiming it was needed for some VJ compression implementations. As mentioned in this referenced document, this can be abused. (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment) Before switching to pure random IPID generation and possibly hurt some workloads, lets use the private inet socket generator. Not only this will remove one vulnerability, this will also improve performance of TCP flows using pmtudisc=3D=3DIP_PMTUDISC_DONT Fixes: 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Reported-by: Ray Che Cc: Willy Tarreau Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- include/net/ip.h | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) --- a/include/net/ip.h +++ b/include/net/ip.h @@ -509,19 +509,18 @@ static inline void ip_select_ident_segs( { struct iphdr *iph =3D ip_hdr(skb); =20 + /* We had many attacks based on IPID, use the private + * generator as much as we can. + */ + if (sk && inet_sk(sk)->inet_daddr) { + iph->id =3D htons(inet_sk(sk)->inet_id); + inet_sk(sk)->inet_id +=3D segs; + return; + } if ((iph->frag_off & htons(IP_DF)) && !skb->ignore_df) { - /* This is only to work around buggy Windows95/2000 - * VJ compression implementations. If the ID field - * does not change, they drop every other packet in - * a TCP stream using header compression. - */ - if (sk && inet_sk(sk)->inet_daddr) { - iph->id =3D htons(inet_sk(sk)->inet_id); - inet_sk(sk)->inet_id +=3D segs; - } else { - iph->id =3D 0; - } + iph->id =3D 0; } else { + /* Unfortunately we need the big hammer to get a suitable IPID */ __ip_select_ident(net, iph, segs); } } From nobody Wed Jul 1 03:23:32 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 91FFFC433FE for ; Mon, 31 Jan 2022 11:05:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358893AbiAaLFF (ORCPT ); Mon, 31 Jan 2022 06:05:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359078AbiAaLCx (ORCPT ); Mon, 31 Jan 2022 06:02:53 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BB44C06177E; Mon, 31 Jan 2022 03:01:13 -0800 (PST) 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 470CEB82A61; Mon, 31 Jan 2022 11:01:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BD24C340E8; Mon, 31 Jan 2022 11:01:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626871; bh=cyrUHQ/bV6GZ/AT9V/xmKq9w0SJfnB1JiyEl7DchvfA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Psk3tClGfUpy1N6sIQKGYILfn7TPhdspaplBXLuA2Qj/kZXQ/bgzMvR6JjQlrDjZq xBGKBVcKbaJ4BoX2Mpk8Mxq/OIMjp2ZKiMqpMgHLQFfz6KtzJGLAAKxMMT7ulBJcZm gKv1p+KkCE0TWO7y8KGawUroCbeoUXTWvw3RK+0s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck , Sasha Levin Subject: [PATCH 5.4 39/64] hwmon: (lm90) Reduce maximum conversion rate for G781 Date: Mon, 31 Jan 2022 11:56:24 +0100 Message-Id: <20220131105217.001644228@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Guenter Roeck [ Upstream commit a66c5ed539277b9f2363bbace0dba88b85b36c26 ] According to its datasheet, G781 supports a maximum conversion rate value of 8 (62.5 ms). However, chips labeled G781 and G780 were found to only support a maximum conversion rate value of 7 (125 ms). On the other side, chips labeled G781-1 and G784 were found to support a conversion rate value of 8. There is no known means to distinguish G780 from G781 or G784; all chips report the same manufacturer ID and chip revision. Setting the conversion rate register value to 8 on chips not supporting it causes unexpected behavior since the real conversion rate is set to 0 (16 seconds) if a value of 8 is written into the conversion rate register. Limit the conversion rate register value to 7 for all G78x chips to avoid the problem. Fixes: ae544f64cc7b ("hwmon: (lm90) Add support for GMT G781") Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/hwmon/lm90.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -373,7 +373,7 @@ static const struct lm90_params lm90_par .flags =3D LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT | LM90_HAVE_BROKEN_ALERT | LM90_HAVE_CRIT, .alert_alarms =3D 0x7c, - .max_convrate =3D 8, + .max_convrate =3D 7, }, [lm86] =3D { .flags =3D LM90_HAVE_OFFSET | LM90_HAVE_REM_LIMIT_EXT From nobody Wed Jul 1 03:23:32 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 E68FAC4332F for ; Mon, 31 Jan 2022 11:04:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358543AbiAaLE5 (ORCPT ); Mon, 31 Jan 2022 06:04:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42960 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359103AbiAaLC6 (ORCPT ); Mon, 31 Jan 2022 06:02:58 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8439C0613E3; Mon, 31 Jan 2022 03:01:15 -0800 (PST) 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 4FCEEB82A57; Mon, 31 Jan 2022 11:01:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C041C340EE; Mon, 31 Jan 2022 11:01:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626874; bh=rpnftBRACWes5GtqEEFzPZ2+KGvGlU+bFKluK1c0RuM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WdeOiLlUbtcRGR1TJYkAyzlCZIghD5cdG1USbTygcxr+NLk8ptxP1WAG2yxvE4NEn CytheCYirY821//AelZgWFO23aBEKn/QYVj+wpD0ZLVCdog1/OfYyjbEEW0Uf/l45h sBbzpK4K8ilHaULhE8TvH81usAhtnlgNKfmeOc2w= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lyu Tao , Trond Myklebust , Anna Schumaker Subject: [PATCH 5.4 40/64] NFSv4: Handle case where the lookup of a directory fails Date: Mon, 31 Jan 2022 11:56:25 +0100 Message-Id: <20220131105217.032432494@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Trond Myklebust commit ac795161c93699d600db16c1a8cc23a65a1eceaf upstream. If the application sets the O_DIRECTORY flag, and tries to open a regular file, nfs_atomic_open() will punt to doing a regular lookup. If the server then returns a regular file, we will happily return a file descriptor with uninitialised open state. The fix is to return the expected ENOTDIR error in these cases. Reported-by: Lyu Tao Fixes: 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/nfs/dir.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1638,6 +1638,19 @@ out: =20 no_open: res =3D nfs_lookup(dir, dentry, lookup_flags); + if (!res) { + inode =3D d_inode(dentry); + if ((lookup_flags & LOOKUP_DIRECTORY) && inode && + !S_ISDIR(inode->i_mode)) + res =3D ERR_PTR(-ENOTDIR); + } else if (!IS_ERR(res)) { + inode =3D d_inode(res); + if ((lookup_flags & LOOKUP_DIRECTORY) && inode && + !S_ISDIR(inode->i_mode)) { + dput(res); + res =3D ERR_PTR(-ENOTDIR); + } + } if (switched) { d_lookup_done(dentry); if (!res) From nobody Wed Jul 1 03:23:32 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 152FAC4167D for ; Mon, 31 Jan 2022 11:04:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359276AbiAaLEx (ORCPT ); Mon, 31 Jan 2022 06:04:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359108AbiAaLC6 (ORCPT ); Mon, 31 Jan 2022 06:02:58 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C6E8C061377; Mon, 31 Jan 2022 03:01:18 -0800 (PST) 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 D011260B2D; Mon, 31 Jan 2022 11:01:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF0B7C340E8; Mon, 31 Jan 2022 11:01:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626877; bh=AW09Hw0O0tjN//AzuiSh6wQwxIaj6bNbvICHTQHbuRw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kfqn8BU/gXhBhL2qnZ43+Kloo9Dxp3Fqp8A+mycZIQwtXQ7wYM3tSNMItIgRNGhS5 IKzXzU4HhXTIrJK4zTIdCEbSjYF8o84ftJsLWr56J5hz7vtuZx9cjJp9BMht3ZxPQG BSBisKrvP7Hmh4AOYA/pJ9qQ8aBZMAphgAGdqTAs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Anna Schumaker Subject: [PATCH 5.4 41/64] NFSv4: nfs_atomic_open() can race when looking up a non-regular file Date: Mon, 31 Jan 2022 11:56:26 +0100 Message-Id: <20220131105217.063133700@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Trond Myklebust commit 1751fc1db36f6f411709e143d5393f92d12137a9 upstream. If the file type changes back to being a regular file on the server between the failed OPEN and our LOOKUP, then we need to re-run the OPEN. Fixes: 0dd2b474d0b6 ("nfs: implement i_op->atomic_open()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/nfs/dir.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -1643,12 +1643,17 @@ no_open: if ((lookup_flags & LOOKUP_DIRECTORY) && inode && !S_ISDIR(inode->i_mode)) res =3D ERR_PTR(-ENOTDIR); + else if (inode && S_ISREG(inode->i_mode)) + res =3D ERR_PTR(-EOPENSTALE); } else if (!IS_ERR(res)) { inode =3D d_inode(res); if ((lookup_flags & LOOKUP_DIRECTORY) && inode && !S_ISDIR(inode->i_mode)) { dput(res); res =3D ERR_PTR(-ENOTDIR); + } else if (inode && S_ISREG(inode->i_mode)) { + dput(res); + res =3D ERR_PTR(-EOPENSTALE); } } if (switched) { From nobody Wed Jul 1 03:23:32 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 1C3D4C4332F for ; Mon, 31 Jan 2022 11:04:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359186AbiAaLEh (ORCPT ); Mon, 31 Jan 2022 06:04:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359118AbiAaLC7 (ORCPT ); Mon, 31 Jan 2022 06:02:59 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3F3B8C0613E9; Mon, 31 Jan 2022 03:01:21 -0800 (PST) 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 D11E260BA2; Mon, 31 Jan 2022 11:01:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BAC6DC340E8; Mon, 31 Jan 2022 11:01:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626880; bh=eqaDUaWKBeWkcDFPzgRykjEQnCAlLdBYpvHrHiPgvio=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jBFsRpDn/rSx54J91L+wCaODl84GYP5b+mPYyy/5mBpjZ17fTmXtO9wFaHjhzWn2A SfzHwPrwqnGt6jEPaym5MquyapsOKuexQIWhmLR2XO25nnXhoYdJ448V4jdhB0nkKW ZJ8QzDrKBDcveVi0AyVBq11GwYVTLBt5GAJNZtnQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jianguo Wu , "David S. Miller" Subject: [PATCH 5.4 42/64] net-procfs: show net devices bound packet types Date: Mon, 31 Jan 2022 11:56:27 +0100 Message-Id: <20220131105217.100841787@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Jianguo Wu commit 1d10f8a1f40b965d449e8f2d5ed7b96a7c138b77 upstream. After commit:7866a621043f ("dev: add per net_device packet type chains"), we can not get packet types that are bound to a specified net device by /proc/net/ptype, this patch fix the regression. Run "tcpdump -i ens192 udp -nns0" Before and after apply this patch: Before: [root@localhost ~]# cat /proc/net/ptype Type Device Function 0800 ip_rcv 0806 arp_rcv 86dd ipv6_rcv After: [root@localhost ~]# cat /proc/net/ptype Type Device Function ALL ens192 tpacket_rcv 0800 ip_rcv 0806 arp_rcv 86dd ipv6_rcv v1 -> v2: - fix the regression rather than adding new /proc API as suggested by Stephen Hemminger. Fixes: 7866a621043f ("dev: add per net_device packet type chains") Signed-off-by: Jianguo Wu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/core/net-procfs.c | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) --- a/net/core/net-procfs.c +++ b/net/core/net-procfs.c @@ -182,12 +182,23 @@ static const struct seq_operations softn .show =3D softnet_seq_show, }; =20 -static void *ptype_get_idx(loff_t pos) +static void *ptype_get_idx(struct seq_file *seq, loff_t pos) { + struct list_head *ptype_list =3D NULL; struct packet_type *pt =3D NULL; + struct net_device *dev; loff_t i =3D 0; int t; =20 + for_each_netdev_rcu(seq_file_net(seq), dev) { + ptype_list =3D &dev->ptype_all; + list_for_each_entry_rcu(pt, ptype_list, list) { + if (i =3D=3D pos) + return pt; + ++i; + } + } + list_for_each_entry_rcu(pt, &ptype_all, list) { if (i =3D=3D pos) return pt; @@ -208,22 +219,40 @@ static void *ptype_seq_start(struct seq_ __acquires(RCU) { rcu_read_lock(); - return *pos ? ptype_get_idx(*pos - 1) : SEQ_START_TOKEN; + return *pos ? ptype_get_idx(seq, *pos - 1) : SEQ_START_TOKEN; } =20 static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos) { + struct net_device *dev; struct packet_type *pt; struct list_head *nxt; int hash; =20 ++*pos; if (v =3D=3D SEQ_START_TOKEN) - return ptype_get_idx(0); + return ptype_get_idx(seq, 0); =20 pt =3D v; nxt =3D pt->list.next; + if (pt->dev) { + if (nxt !=3D &pt->dev->ptype_all) + goto found; + + dev =3D pt->dev; + for_each_netdev_continue_rcu(seq_file_net(seq), dev) { + if (!list_empty(&dev->ptype_all)) { + nxt =3D dev->ptype_all.next; + goto found; + } + } + + nxt =3D ptype_all.next; + goto ptype_all; + } + if (pt->type =3D=3D htons(ETH_P_ALL)) { +ptype_all: if (nxt !=3D &ptype_all) goto found; hash =3D 0; From nobody Wed Jul 1 03:23:32 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 9BE19C433F5 for ; Mon, 31 Jan 2022 11:03:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358804AbiAaLCf (ORCPT ); Mon, 31 Jan 2022 06:02:35 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:34148 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358768AbiAaLBY (ORCPT ); Mon, 31 Jan 2022 06:01:24 -0500 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 0F27F60E83; Mon, 31 Jan 2022 11:01:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC1A1C340E8; Mon, 31 Jan 2022 11:01:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626883; bh=O8hN4RHA2dNA3i8vREGTpfrzZsh7MozUKG5wA36Ztw0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MNG7HaeYmrX9tIMNYAiTOOxpPPMu667c2dNw3BUKZzwyKD1lppPe1z2EqnQ3zGUNX 5mUl8eESWGzJeI+dug4Ov8wYjrO759evhGY3QWV65ItNBI21LAd6Pw6pPxABagdjDT unbb4u2DnMLFIi3uTc7o8icNJlnvq99KPeIMtUx8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Xianting Tian , Dmitry Baryshkov , Sasha Levin Subject: [PATCH 5.4 43/64] drm/msm: Fix wrong size calculation Date: Mon, 31 Jan 2022 11:56:28 +0100 Message-Id: <20220131105217.138108037@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Xianting Tian commit 0a727b459ee39bd4c5ced19d6024258ac87b6b2e upstream. For example, memory-region in .dts as below, reg =3D <0x0 0x50000000 0x0 0x20000000> We can get below values, struct resource r; r.start =3D 0x50000000; r.end =3D 0x6fffffff; So the size should be: size =3D r.end - r.start + 1 =3D 0x20000000 Signed-off-by: Xianting Tian Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem") Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220112123334.749776-1-xianting.tian@linux= .alibaba.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/gpu/drm/msm/msm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -337,7 +337,7 @@ static int msm_init_vram(struct drm_devi of_node_put(node); if (ret) return ret; - size =3D r.end - r.start; + size =3D r.end - r.start + 1; DRM_INFO("using VRAM carveout: %lx@%pa\n", size, &r.start); =20 /* if we have no IOMMU, then we need to use carveout allocator. From nobody Wed Jul 1 03:23:32 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 86D2FC433F5 for ; Mon, 31 Jan 2022 11:04:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359165AbiAaLEf (ORCPT ); Mon, 31 Jan 2022 06:04:35 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43348 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359135AbiAaLDB (ORCPT ); Mon, 31 Jan 2022 06:03:01 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55AE1C06137E; Mon, 31 Jan 2022 03:01:27 -0800 (PST) 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 EAC4660B2D; Mon, 31 Jan 2022 11:01:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CAA68C340E8; Mon, 31 Jan 2022 11:01:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626886; bh=yvLfEvfM1S9QsM+cfwQvHnI2a+N1nMMw0orbNRBlg70=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M3AnDFXea3VB0ZgIy8XR6MIY8RmJM4jChf/nrWFisqMF8GoiCr9WxrvEU1Iz9loz1 Q1n5OiDU2aX/KczyuxjtZ60tXcEsWAp6t4AN7FVddatqtxH2H4iEigOch0tEH3b+rH pSCCu3HCasAnTqjGlw/UAs1pIW1f2WBWmvhVKOxQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miaoqian Lin , Dmitry Baryshkov Subject: [PATCH 5.4 44/64] drm/msm/dsi: Fix missing put_device() call in dsi_get_phy Date: Mon, 31 Jan 2022 11:56:29 +0100 Message-Id: <20220131105217.168931203@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 commit c04c3148ca12227d92f91b355b4538cc333c9922 upstream. If of_find_device_by_node() succeeds, dsi_get_phy() doesn't a corresponding put_device(). Thus add put_device() to fix the exception handling. Fixes: ec31abf ("drm/msm/dsi: Separate PHY to another platform device") Signed-off-by: Miaoqian Lin Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211230070943.18116-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/gpu/drm/msm/dsi/dsi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/msm/dsi/dsi.c +++ b/drivers/gpu/drm/msm/dsi/dsi.c @@ -33,7 +33,12 @@ static int dsi_get_phy(struct msm_dsi *m =20 of_node_put(phy_node); =20 - if (!phy_pdev || !msm_dsi->phy) { + if (!phy_pdev) { + DRM_DEV_ERROR(&pdev->dev, "%s: phy driver is not ready\n", __func__); + return -EPROBE_DEFER; + } + if (!msm_dsi->phy) { + put_device(&phy_pdev->dev); DRM_DEV_ERROR(&pdev->dev, "%s: phy driver is not ready\n", __func__); return -EPROBE_DEFER; } From nobody Wed Jul 1 03:23:32 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 4E97AC433FE for ; Mon, 31 Jan 2022 11:00:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358654AbiAaLAz (ORCPT ); Mon, 31 Jan 2022 06:00:55 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60416 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358344AbiAaLAC (ORCPT ); Mon, 31 Jan 2022 06:00:02 -0500 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 C16C960B2D; Mon, 31 Jan 2022 11:00:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A00CAC340E8; Mon, 31 Jan 2022 11:00:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626802; bh=JlOr/yvP2mLTO7wY47UB0HAcHZzuT6BggfEUvoJDg5M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AkWIjIxAF7rV2Q7fR+qBtAt3drvM81Ici5MMoIUN4lbVzWNPHxdObDfjs55G42eVL DYrNUhp24bg83Uwd4BU3SBfsDIaldf+JnRtrYe9f3WLce9hEUsHyvTK2vuF5nejDJE gIDtSJvR4XESv/E4CC6oGbEr0ytI4dQUodwp5p2I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Jos=C3=A9=20Exp=C3=B3sito?= , Dmitry Baryshkov Subject: [PATCH 5.4 45/64] drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable Date: Mon, 31 Jan 2022 11:56:30 +0100 Message-Id: <20220131105217.201443004@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@linuxfoundation.org> User-Agent: quilt/0.66 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: Jos=C3=A9 Exp=C3=B3sito commit 5e761a2287234bc402ba7ef07129f5103bcd775c upstream. The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files") Addresses-Coverity-ID: 1493860 ("Null pointer dereference") Signed-off-by: Jos=C3=A9 Exp=C3=B3sito Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220116181844.7400-1-jose.exposito89@gmail= .com Signed-off-by: Dmitry Baryshkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c +++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c @@ -665,12 +665,14 @@ void __exit msm_dsi_phy_driver_unregiste int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int src_pll_id, struct msm_dsi_phy_clk_request *clk_req) { - struct device *dev =3D &phy->pdev->dev; + struct device *dev; int ret; =20 if (!phy || !phy->cfg->ops.enable) return -EINVAL; =20 + dev =3D &phy->pdev->dev; + ret =3D dsi_phy_enable_resource(phy); if (ret) { DRM_DEV_ERROR(dev, "%s: resource enable failed, %d\n", From nobody Wed Jul 1 03:23:32 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 C399AC433F5 for ; Mon, 31 Jan 2022 11:00:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358666AbiAaLA5 (ORCPT ); Mon, 31 Jan 2022 06:00:57 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48026 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358412AbiAaLAH (ORCPT ); Mon, 31 Jan 2022 06:00:07 -0500 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 8D317B82A62; Mon, 31 Jan 2022 11:00:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BF66C340E8; Mon, 31 Jan 2022 11:00:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626805; bh=uUZ22xHy5+pfz1qktFjosXl0+UJuFpfr9JpcWYiMl1I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Bup6Qy7KjszTmkURR5isIfgvtNopeLMIhkp6B2EPuhdIx405hV+jwe3WCovskbc63 JNx470w8L5tLF93sjzVcwOGD/+eKifBcjOLIuAmjYR3Kw5c+8bbAD9PjMCwkJZ6A71 cU5valg/jAhWxt23Mpfy9uz7eSZ/0g9iky4K0/Ek= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , syzbot , Jakub Kicinski Subject: [PATCH 5.4 46/64] ipv6: annotate accesses to fn->fn_sernum Date: Mon, 31 Jan 2022 11:56:31 +0100 Message-Id: <20220131105217.231179349@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 commit aafc2e3285c2d7a79b7ee15221c19fbeca7b1509 upstream. struct fib6_node's fn_sernum field can be read while other threads change it. Add READ_ONCE()/WRITE_ONCE() annotations. Do not change existing smp barriers in fib6_get_cookie_safe() and __fib6_update_sernum_upto_root() syzbot reported: BUG: KCSAN: data-race in fib6_clean_node / inet6_csk_route_socket write to 0xffff88813df62e2c of 4 bytes by task 1920 on cpu 1: fib6_clean_node+0xc2/0x260 net/ipv6/ip6_fib.c:2178 fib6_walk_continue+0x38e/0x430 net/ipv6/ip6_fib.c:2112 fib6_walk net/ipv6/ip6_fib.c:2160 [inline] fib6_clean_tree net/ipv6/ip6_fib.c:2240 [inline] __fib6_clean_all+0x1a9/0x2e0 net/ipv6/ip6_fib.c:2256 fib6_flush_trees+0x6c/0x80 net/ipv6/ip6_fib.c:2281 rt_genid_bump_ipv6 include/net/net_namespace.h:488 [inline] addrconf_dad_completed+0x57f/0x870 net/ipv6/addrconf.c:4230 addrconf_dad_work+0x908/0x1170 process_one_work+0x3f6/0x960 kernel/workqueue.c:2307 worker_thread+0x616/0xa70 kernel/workqueue.c:2454 kthread+0x1bf/0x1e0 kernel/kthread.c:359 ret_from_fork+0x1f/0x30 read to 0xffff88813df62e2c of 4 bytes by task 15701 on cpu 0: fib6_get_cookie_safe include/net/ip6_fib.h:285 [inline] rt6_get_cookie include/net/ip6_fib.h:306 [inline] ip6_dst_store include/net/ip6_route.h:234 [inline] inet6_csk_route_socket+0x352/0x3c0 net/ipv6/inet6_connection_sock.c:109 inet6_csk_xmit+0x91/0x1e0 net/ipv6/inet6_connection_sock.c:121 __tcp_transmit_skb+0x1323/0x1840 net/ipv4/tcp_output.c:1402 tcp_transmit_skb net/ipv4/tcp_output.c:1420 [inline] tcp_write_xmit+0x1450/0x4460 net/ipv4/tcp_output.c:2680 __tcp_push_pending_frames+0x68/0x1c0 net/ipv4/tcp_output.c:2864 tcp_push+0x2d9/0x2f0 net/ipv4/tcp.c:725 mptcp_push_release net/mptcp/protocol.c:1491 [inline] __mptcp_push_pending+0x46c/0x490 net/mptcp/protocol.c:1578 mptcp_sendmsg+0x9ec/0xa50 net/mptcp/protocol.c:1764 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:643 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] kernel_sendmsg+0x97/0xd0 net/socket.c:745 sock_no_sendpage+0x84/0xb0 net/core/sock.c:3086 inet_sendpage+0x9d/0xc0 net/ipv4/af_inet.c:834 kernel_sendpage+0x187/0x200 net/socket.c:3492 sock_sendpage+0x5a/0x70 net/socket.c:1007 pipe_to_sendpage+0x128/0x160 fs/splice.c:364 splice_from_pipe_feed fs/splice.c:418 [inline] __splice_from_pipe+0x207/0x500 fs/splice.c:562 splice_from_pipe fs/splice.c:597 [inline] generic_splice_sendpage+0x94/0xd0 fs/splice.c:746 do_splice_from fs/splice.c:767 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:936 splice_direct_to_actor+0x345/0x650 fs/splice.c:891 do_splice_direct+0x106/0x190 fs/splice.c:979 do_sendfile+0x675/0xc40 fs/read_write.c:1245 __do_sys_sendfile64 fs/read_write.c:1310 [inline] __se_sys_sendfile64 fs/read_write.c:1296 [inline] __x64_sys_sendfile64+0x102/0x140 fs/read_write.c:1296 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x0000026f -> 0x00000271 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 15701 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 01/01/2011 The Fixes tag I chose is probably arbitrary, I do not think we need to backport this patch to older kernels. Fixes: c5cff8561d2d ("ipv6: add rcu grace period before freeing fib6_node") Signed-off-by: Eric Dumazet Reported-by: syzbot Link: https://lore.kernel.org/r/20220120174112.1126644-1-eric.dumazet@gmail= .com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- include/net/ip6_fib.h | 2 +- net/ipv6/ip6_fib.c | 23 +++++++++++++---------- net/ipv6/route.c | 2 +- 3 files changed, 15 insertions(+), 12 deletions(-) --- a/include/net/ip6_fib.h +++ b/include/net/ip6_fib.h @@ -247,7 +247,7 @@ static inline bool fib6_get_cookie_safe( fn =3D rcu_dereference(f6i->fib6_node); =20 if (fn) { - *cookie =3D fn->fn_sernum; + *cookie =3D READ_ONCE(fn->fn_sernum); /* pairs with smp_wmb() in fib6_update_sernum_upto_root() */ smp_rmb(); status =3D true; --- a/net/ipv6/ip6_fib.c +++ b/net/ipv6/ip6_fib.c @@ -110,7 +110,7 @@ void fib6_update_sernum(struct net *net, fn =3D rcu_dereference_protected(f6i->fib6_node, lockdep_is_held(&f6i->fib6_table->tb6_lock)); if (fn) - fn->fn_sernum =3D fib6_new_sernum(net); + WRITE_ONCE(fn->fn_sernum, fib6_new_sernum(net)); } =20 /* @@ -535,12 +535,13 @@ static int fib6_dump_table(struct fib6_t spin_unlock_bh(&table->tb6_lock); if (res > 0) { cb->args[4] =3D 1; - cb->args[5] =3D w->root->fn_sernum; + cb->args[5] =3D READ_ONCE(w->root->fn_sernum); } } else { - if (cb->args[5] !=3D w->root->fn_sernum) { + int sernum =3D READ_ONCE(w->root->fn_sernum); + if (cb->args[5] !=3D sernum) { /* Begin at the root if the tree changed */ - cb->args[5] =3D w->root->fn_sernum; + cb->args[5] =3D sernum; w->state =3D FWS_INIT; w->node =3D w->root; w->skip =3D w->count; @@ -1276,7 +1277,7 @@ static void __fib6_update_sernum_upto_ro /* paired with smp_rmb() in rt6_get_cookie_safe() */ smp_wmb(); while (fn) { - fn->fn_sernum =3D sernum; + WRITE_ONCE(fn->fn_sernum, sernum); fn =3D rcu_dereference_protected(fn->parent, lockdep_is_held(&rt->fib6_table->tb6_lock)); } @@ -2068,8 +2069,8 @@ static int fib6_clean_node(struct fib6_w }; =20 if (c->sernum !=3D FIB6_NO_SERNUM_CHANGE && - w->node->fn_sernum !=3D c->sernum) - w->node->fn_sernum =3D c->sernum; + READ_ONCE(w->node->fn_sernum) !=3D c->sernum) + WRITE_ONCE(w->node->fn_sernum, c->sernum); =20 if (!c->func) { WARN_ON_ONCE(c->sernum =3D=3D FIB6_NO_SERNUM_CHANGE); @@ -2433,7 +2434,7 @@ static void ipv6_route_seq_setup_walk(st iter->w.state =3D FWS_INIT; iter->w.node =3D iter->w.root; iter->w.args =3D iter; - iter->sernum =3D iter->w.root->fn_sernum; + iter->sernum =3D READ_ONCE(iter->w.root->fn_sernum); INIT_LIST_HEAD(&iter->w.lh); fib6_walker_link(net, &iter->w); } @@ -2461,8 +2462,10 @@ static struct fib6_table *ipv6_route_seq =20 static void ipv6_route_check_sernum(struct ipv6_route_iter *iter) { - if (iter->sernum !=3D iter->w.root->fn_sernum) { - iter->sernum =3D iter->w.root->fn_sernum; + int sernum =3D READ_ONCE(iter->w.root->fn_sernum); + + if (iter->sernum !=3D sernum) { + iter->sernum =3D sernum; iter->w.state =3D FWS_INIT; iter->w.node =3D iter->w.root; WARN_ON(iter->w.skip); --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -2697,7 +2697,7 @@ static void ip6_link_failure(struct sk_b if (from) { fn =3D rcu_dereference(from->fib6_node); if (fn && (rt->rt6i_flags & RTF_DEFAULT)) - fn->fn_sernum =3D -1; + WRITE_ONCE(fn->fn_sernum, -1); } } rcu_read_unlock(); From nobody Wed Jul 1 03:23:32 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 C48E4C433EF for ; Mon, 31 Jan 2022 11:01:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358700AbiAaLBA (ORCPT ); Mon, 31 Jan 2022 06:01:00 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60614 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348645AbiAaLAJ (ORCPT ); Mon, 31 Jan 2022 06:00:09 -0500 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 5B55760B03; Mon, 31 Jan 2022 11:00:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A34EC340EF; Mon, 31 Jan 2022 11:00:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626808; bh=QS+rHwM5FkMxeZz8bHDNTNPX8CJF2uRNcfo1OIB6xRY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PrlTT+I6bAslqPN4t/oGIOwXxCAz5kajlhB9yfEpH9v9Icw40MN04TxKuCu96MYd/ ggQ+oEo9w8CNNQtINi2QF43XYbUZw5aBS3km6L6VexCOsx6aov6JZOcU5xDo8T74yh E1VbWf6tJ+HLBqfz4w5DvXPkz9SyIK34oHqrrJC4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Anna Schumaker , Sasha Levin Subject: [PATCH 5.4 47/64] NFS: Ensure the server has an up to date ctime before hardlinking Date: Mon, 31 Jan 2022 11:56:32 +0100 Message-Id: <20220131105217.272730572@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Trond Myklebust [ Upstream commit 204975036b34f55237bc44c8a302a88468ef21b5 ] Creating a hard link is required by POSIX to update the file ctime, so ensure that the file data is synced to disk so that we don't clobber the updated ctime by writing back after creating the hard link. Fixes: 9f7682728728 ("NFS: Move the delegation return down into nfs4_proc_l= ink()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/nfs/dir.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2053,6 +2053,8 @@ nfs_link(struct dentry *old_dentry, stru =20 trace_nfs_link_enter(inode, dir, dentry); d_drop(dentry); + if (S_ISREG(inode->i_mode)) + nfs_sync_inode(inode); error =3D NFS_PROTO(dir)->link(inode, dir, &dentry->d_name); if (error =3D=3D 0) { ihold(inode); From nobody Wed Jul 1 03:23:32 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 CBBFFC4332F for ; Mon, 31 Jan 2022 11:01:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358732AbiAaLBH (ORCPT ); Mon, 31 Jan 2022 06:01:07 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48104 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348546AbiAaLAO (ORCPT ); Mon, 31 Jan 2022 06:00:14 -0500 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 1983EB82A5D; Mon, 31 Jan 2022 11:00:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 44D0DC340E8; Mon, 31 Jan 2022 11:00:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626811; bh=bwNfiph+mzFupEybTRho7bodcExQLjUfJ5lC3jX7wY8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mfpwYCEbOTy2SO2GcwK6Bv2lCmYjobB60ekRByQBHAy46M9zs6iN2iJuQzBRqjCtm OeZ6pV8cyZPRacPry5N/Wz/PLh8Pl3IfM+QoOGZn6oKhDv6UC99Mfobp6WtVgQP0nc jjjqK/zPwyzWcjsE4TpKgdITz/4AydmxMpIPtoYk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Trond Myklebust , Anna Schumaker , Sasha Levin Subject: [PATCH 5.4 48/64] NFS: Ensure the server has an up to date ctime before renaming Date: Mon, 31 Jan 2022 11:56:33 +0100 Message-Id: <20220131105217.303568218@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Trond Myklebust [ Upstream commit 6ff9d99bb88faebf134ca668842349d9718e5464 ] Renaming a file is required by POSIX to update the file ctime, so ensure that the file data is synced to disk so that we don't clobber the updated ctime by writing back after creating the hard link. Fixes: f2c2c552f119 ("NFS: Move delegation recall into the NFSv4 callback f= or rename_setup()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/nfs/dir.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/nfs/dir.c +++ b/fs/nfs/dir.c @@ -2143,6 +2143,8 @@ int nfs_rename(struct inode *old_dir, st } } =20 + if (S_ISREG(old_inode->i_mode)) + nfs_sync_inode(old_inode); task =3D nfs_async_rename(old_dir, new_dir, old_dentry, new_dentry, NULL); if (IS_ERR(task)) { error =3D PTR_ERR(task); From nobody Wed Jul 1 03:23:32 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 31BCCC433F5 for ; Mon, 31 Jan 2022 11:04:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358753AbiAaLEi (ORCPT ); Mon, 31 Jan 2022 06:04:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42762 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358873AbiAaLB4 (ORCPT ); Mon, 31 Jan 2022 06:01:56 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7E642C061757; Mon, 31 Jan 2022 03:00:17 -0800 (PST) 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 48FDFB82A69; Mon, 31 Jan 2022 11:00:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 68276C340E8; Mon, 31 Jan 2022 11:00:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626815; bh=zlA4dr6EEzG4yI4mNFgUJEXAqyTrvPkR0P4A7MTyLSU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nyYXYujc/EMLk4fP1ZABTcvYJ+JWg8IXS0arr1JfeWG6WVzaTz+6ovvrLpq8xgwKa lxAkMSxUqdqTPugTblDl8vZKHjJmaMeU/BoLDczRtUYgZ+TzQlvh4fEbQHwqORU0Z3 29PQOa4LbSdStDpDXQuRqhRPwFCh5Yv7YklS97qw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Florian Westphal , Pablo Neira Ayuso , Sasha Levin Subject: [PATCH 5.4 49/64] netfilter: conntrack: dont increment invalid counter on NF_REPEAT Date: Mon, 31 Jan 2022 11:56:34 +0100 Message-Id: <20220131105217.335272096@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Florian Westphal [ Upstream commit 830af2eba40327abec64325a5b08b1e85c37a2e0 ] The packet isn't invalid, REPEAT means we're trying again after cleaning out a stale connection, e.g. via tcp tracker. This caused increases of invalid stat counter in a test case involving frequent connection reuse, even though no packet is actually invalid. Fixes: 56a62e2218f5 ("netfilter: conntrack: fix NF_REPEAT handling") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/netfilter/nf_conntrack_core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack= _core.c index 4bcc36e4b2ef0..d9b6f2001d006 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -1709,15 +1709,17 @@ repeat: pr_debug("nf_conntrack_in: Can't track with proto module\n"); nf_conntrack_put(&ct->ct_general); skb->_nfct =3D 0; - NF_CT_STAT_INC_ATOMIC(state->net, invalid); - if (ret =3D=3D -NF_DROP) - NF_CT_STAT_INC_ATOMIC(state->net, drop); /* Special case: TCP tracker reports an attempt to reopen a * closed/aborted connection. We have to go back and create a * fresh conntrack. */ if (ret =3D=3D -NF_REPEAT) goto repeat; + + NF_CT_STAT_INC_ATOMIC(state->net, invalid); + if (ret =3D=3D -NF_DROP) + NF_CT_STAT_INC_ATOMIC(state->net, drop); + ret =3D -ret; goto out; } --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 615DCC43219 for ; Mon, 31 Jan 2022 11:03:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348769AbiAaLDs (ORCPT ); Mon, 31 Jan 2022 06:03:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358931AbiAaLCN (ORCPT ); Mon, 31 Jan 2022 06:02:13 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D6E7C061759; Mon, 31 Jan 2022 03:00:19 -0800 (PST) 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 BEEB360AF6; Mon, 31 Jan 2022 11:00:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C0DAC340E8; Mon, 31 Jan 2022 11:00:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626818; bh=gRRUr3GZfH0oOWsALBJ1NzPStNd7gByEVdYf3P2O07k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ws+5ImAWjSh07C8WzATqna3/yJ5HZaKTRkOL3zlGsTm6RrSbdpy5m49l/XLDv2IYN BSUYTkRW/j0SozvKqneUJ84wU5jl6hNo5vaQhG6DBrTGwjc3Fb0X4Vy5uuZbtL7mWL hZ++AT7u5uTAW1jAzzmnDLAAT3Ai5a0eFsIcrrO4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Robert Hancock , Florian Fainelli , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 50/64] net: phy: broadcom: hook up soft_reset for BCM54616S Date: Mon, 31 Jan 2022 11:56:35 +0100 Message-Id: <20220131105217.373387209@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Robert Hancock [ Upstream commit d15c7e875d44367005370e6a82e8f3a382a04f9b ] A problem was encountered with the Bel-Fuse 1GBT-SFP05 SFP module (which is a 1 Gbps copper module operating in SGMII mode with an internal BCM54616S PHY device) using the Xilinx AXI Ethernet MAC core, where the module would work properly on the initial insertion or boot of the device, but after the device was rebooted, the link would either only come up at 100 Mbps speeds or go up and down erratically. I found no meaningful changes in the PHY configuration registers between the working and non-working boots, but the status registers seemed to have a lot of error indications set on the SERDES side of the device on the non-working boot. I suspect the problem is that whatever happens on the SGMII link when the device is rebooted and the FPGA logic gets reloaded ends up putting the module's onboard PHY into a bad state. Since commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") the genphy_soft_reset call is not made automatically by the PHY core unless the callback is explicitly specified in the driver structure. For most of these Broadcom devices, there is probably a hardware reset that gets asserted to reset the PHY during boot, however for SFP modules (where the BCM54616S is commonly found) no such reset line exists, so if the board keeps the SFP cage powered up across a reboot, it will end up with no reset occurring during reboots. Hook up the genphy_soft_reset callback for BCM54616S to ensure that a PHY reset is performed before the device is initialized. This appears to fix the issue with erratic operation after a reboot with this SFP module. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Robert Hancock Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/phy/broadcom.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c index 5e956089bf525..c23fec34b50e9 100644 --- a/drivers/net/phy/broadcom.c +++ b/drivers/net/phy/broadcom.c @@ -646,6 +646,7 @@ static struct phy_driver broadcom_drivers[] =3D { .phy_id_mask =3D 0xfffffff0, .name =3D "Broadcom BCM54616S", /* PHY_GBIT_FEATURES */ + .soft_reset =3D genphy_soft_reset, .config_init =3D bcm54xx_config_init, .config_aneg =3D bcm54616s_config_aneg, .ack_interrupt =3D bcm_phy_ack_intr, --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 294F1C433F5 for ; Mon, 31 Jan 2022 11:01:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358773AbiAaLBZ (ORCPT ); Mon, 31 Jan 2022 06:01:25 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48234 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358456AbiAaLAX (ORCPT ); Mon, 31 Jan 2022 06:00:23 -0500 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 79B07B82A5E; Mon, 31 Jan 2022 11:00:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92F22C340E8; Mon, 31 Jan 2022 11:00:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626821; bh=6bTuMqjIAe8M5U9uAeUKlMxp1hGna8u+ajA/AFCtbEM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ng0M60fYzLkcfwBoTwvKt7eAPkgmqx4UA8kzSoHEnsTUI7NK+GiC4d7TtPPUOHqbz ngJm+ujIfEJsO4XfmRhZNsjM+y5QQfg1Uhyj7E6scs2GIDsBDO4TTLiVrua3iMHwKw a9gSaZZpbyScDZ8bA2bNN44cIBtfn+tHQHlxz3ZY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, =?UTF-8?q?Marek=20Beh=C3=BAn?= , Andrew Lunn , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.4 51/64] phylib: fix potential use-after-free Date: Mon, 31 Jan 2022 11:56:36 +0100 Message-Id: <20220131105217.406475015@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@linuxfoundation.org> User-Agent: quilt/0.66 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: Marek Beh=C3=BAn [ Upstream commit cbda1b16687580d5beee38273f6241ae3725960c ] Commit bafbdd527d56 ("phylib: Add device reset GPIO support") added call to phy_device_reset(phydev) after the put_device() call in phy_detach(). The comment before the put_device() call says that the phydev might go away with put_device(). Fix potential use-after-free by calling phy_device_reset() before put_device(). Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support") Signed-off-by: Marek Beh=C3=BAn Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20220119162748.32418-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/phy/phy_device.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 35ade5d21de51..78b918dcd5472 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -1433,6 +1433,9 @@ void phy_detach(struct phy_device *phydev) phy_driver_is_genphy_10g(phydev)) device_release_driver(&phydev->mdio.dev); =20 + /* Assert the reset signal */ + phy_device_reset(phydev, 1); + /* * The phydev might go away on the put_device() below, so avoid * a use-after-free bug by reading the underlying bus first. @@ -1444,9 +1447,6 @@ void phy_detach(struct phy_device *phydev) ndev_owner =3D dev->dev.parent->driver->owner; if (ndev_owner !=3D bus->owner) module_put(bus->owner); - - /* Assert the reset signal */ - phy_device_reset(phydev, 1); } EXPORT_SYMBOL(phy_detach); =20 --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 7C00AC433EF for ; Mon, 31 Jan 2022 11:01:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358791AbiAaLBg (ORCPT ); Mon, 31 Jan 2022 06:01:36 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:33094 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358610AbiAaLAZ (ORCPT ); Mon, 31 Jan 2022 06:00:25 -0500 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 E1AF860BC0; Mon, 31 Jan 2022 11:00:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDCD6C340E8; Mon, 31 Jan 2022 11:00:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626824; bh=ZIeqG/4W3iMtANw1XSfN8K18a49BnpXQ6VvJzNGfFAw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ASoVHX3rMzBoYSfztU4k7pyIqAGJCxDf9rb49oXu5TSozp/K/zDing6f7WxbwIGqY kdRhPLoTrXqVefsh+QBsCW63kuS4OugwX90TujRJl931+1uw2F9eV5QBoVtmStzr8X n4jTktc3Ci1M17YFqOuH+dgaoX7biWxWB+n3L1MI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Dionne , David Howells , linux-afs@lists.infradead.org, "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 52/64] rxrpc: Adjust retransmission backoff Date: Mon, 31 Jan 2022 11:56:37 +0100 Message-Id: <20220131105217.437321340@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: David Howells [ Upstream commit 2c13c05c5ff4b9fc907b07f7311821910ebaaf8a ] Improve retransmission backoff by only backing off when we retransmit data packets rather than when we set the lost ack timer. To this end: (1) In rxrpc_resend(), use rxrpc_get_rto_backoff() when setting the retransmission timer and only tell it that we are retransmitting if we actually have things to retransmit. Note that it's possible for the retransmission algorithm to race with the processing of a received ACK, so we may see no packets needing retransmission. (2) In rxrpc_send_data_packet(), don't bump the backoff when setting the ack_lost_at timer, as it may then get bumped twice. With this, when looking at one particular packet, the retransmission intervals were seen to be 1.5ms, 2ms, 3ms, 5ms, 9ms, 17ms, 33ms, 71ms, 136ms, 264ms, 544ms, 1.088s, 2.1s, 4.2s and 8.3s. Fixes: c410bf01933e ("rxrpc: Fix the excessive initial retransmission timeo= ut") Suggested-by: Marc Dionne Signed-off-by: David Howells Reviewed-by: Marc Dionne Tested-by: Marc Dionne cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/164138117069.2023386.17446904856843997127.s= tgit@warthog.procyon.org.uk/ Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/rxrpc/call_event.c | 8 +++----- net/rxrpc/output.c | 2 +- 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/net/rxrpc/call_event.c b/net/rxrpc/call_event.c index 9ff85ee8337cd..80e15310f1b29 100644 --- a/net/rxrpc/call_event.c +++ b/net/rxrpc/call_event.c @@ -157,7 +157,7 @@ static void rxrpc_congestion_timeout(struct rxrpc_call = *call) static void rxrpc_resend(struct rxrpc_call *call, unsigned long now_j) { struct sk_buff *skb; - unsigned long resend_at, rto_j; + unsigned long resend_at; rxrpc_seq_t cursor, seq, top; ktime_t now, max_age, oldest, ack_ts; int ix; @@ -165,10 +165,8 @@ static void rxrpc_resend(struct rxrpc_call *call, unsi= gned long now_j) =20 _enter("{%d,%d}", call->tx_hard_ack, call->tx_top); =20 - rto_j =3D call->peer->rto_j; - now =3D ktime_get_real(); - max_age =3D ktime_sub(now, jiffies_to_usecs(rto_j)); + max_age =3D ktime_sub(now, jiffies_to_usecs(call->peer->rto_j)); =20 spin_lock_bh(&call->lock); =20 @@ -213,7 +211,7 @@ static void rxrpc_resend(struct rxrpc_call *call, unsig= ned long now_j) } =20 resend_at =3D nsecs_to_jiffies(ktime_to_ns(ktime_sub(now, oldest))); - resend_at +=3D jiffies + rto_j; + resend_at +=3D jiffies + rxrpc_get_rto_backoff(call->peer, retrans); WRITE_ONCE(call->resend_at, resend_at); =20 if (unacked) diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c index f8b632a5c6197..a4a6f8ee07201 100644 --- a/net/rxrpc/output.c +++ b/net/rxrpc/output.c @@ -426,7 +426,7 @@ done: if (call->peer->rtt_count > 1) { unsigned long nowj =3D jiffies, ack_lost_at; =20 - ack_lost_at =3D rxrpc_get_rto_backoff(call->peer, retrans); + ack_lost_at =3D rxrpc_get_rto_backoff(call->peer, false); ack_lost_at +=3D nowj; WRITE_ONCE(call->ack_lost_at, ack_lost_at); rxrpc_reduce_call_timer(call, ack_lost_at, nowj, --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 BE33DC433F5 for ; Mon, 31 Jan 2022 11:03:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358731AbiAaLDu (ORCPT ); Mon, 31 Jan 2022 06:03:50 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358969AbiAaLCU (ORCPT ); Mon, 31 Jan 2022 06:02:20 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC2BCC06135C; Mon, 31 Jan 2022 03:00:29 -0800 (PST) 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 8A3FDB82A67; Mon, 31 Jan 2022 11:00:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFB79C340EF; Mon, 31 Jan 2022 11:00:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626827; bh=pEbtwk1Tu+AIA9m5CSRw9WEv78RmSuPWfYDqnGxqOKo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LB4O2HILfFH2tzPXcRk2HeMhXzJUeN18Qrp2B2FULy9Ll6CR+SIUvN6KHjJIEC5Zv imB1alJKorMIIpxP/DajX/G3AyFs+biFUxb+5OEbn5WJz9sbGbJC4NxLLOBxry9cY2 5JFgGvYCkkzdvVu2bGHlXBlQq3H4WXgdwTbtim3g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josh Lehan , Guenter Roeck , Sasha Levin Subject: [PATCH 5.4 53/64] hwmon: (lm90) Mark alert as broken for MAX6654 Date: Mon, 31 Jan 2022 11:56:38 +0100 Message-Id: <20220131105217.468698771@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Guenter Roeck [ Upstream commit a53fff96f35763d132a36c620b183fdf11022d7a ] Experiments with MAX6654 show that its alert function is broken, similar to other chips supported by the lm90 driver. Mark it accordingly. Fixes: 229d495d8189 ("hwmon: (lm90) Add max6654 support to lm90 driver") Cc: Josh Lehan Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/hwmon/lm90.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c index 0e3304d1c3f28..28b408728282d 100644 --- a/drivers/hwmon/lm90.c +++ b/drivers/hwmon/lm90.c @@ -400,6 +400,7 @@ static const struct lm90_params lm90_params[] =3D { .reg_local_ext =3D MAX6657_REG_R_LOCAL_TEMPL, }, [max6654] =3D { + .flags =3D LM90_HAVE_BROKEN_ALERT, .alert_alarms =3D 0x7c, .max_convrate =3D 7, .reg_local_ext =3D MAX6657_REG_R_LOCAL_TEMPL, --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 C8863C433F5 for ; Mon, 31 Jan 2022 11:01:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358631AbiAaLBn (ORCPT ); Mon, 31 Jan 2022 06:01:43 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48348 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358371AbiAaLAd (ORCPT ); Mon, 31 Jan 2022 06:00:33 -0500 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 EB713B82A5C; Mon, 31 Jan 2022 11:00:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05055C340E8; Mon, 31 Jan 2022 11:00:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626830; bh=ref6tF7RBZ3165LTzpOwRWi0L1OuFqLlajqoFTwRDB4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Nh58O+4b6EncISYcu7+Ttj6YA5Qbcg+dDUZehYISPiLZ2567FI9EvHut06CQTQLmh yD59Gf/0L72E3M4oC/Hy1w89ixsa+Pd6uLvHLtLBAYkSrBe7VTtK+/wZE/7M1pqXAW UT3AwXQqqxG25nnZLgTMFxsId+XnSp04+wSHfTKQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sukadev Bhattiprolu , Dany Madden , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 54/64] ibmvnic: init ->running_cap_crqs early Date: Mon, 31 Jan 2022 11:56:39 +0100 Message-Id: <20220131105217.501005104@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Sukadev Bhattiprolu [ Upstream commit 151b6a5c06b678687f64f2d9a99fd04d5cd32b72 ] We use ->running_cap_crqs to determine when the ibmvnic_tasklet() should send out the next protocol message type. i.e when we get back responses to all our QUERY_CAPABILITY CRQs we send out REQUEST_CAPABILITY crqs. Similiary, when we get responses to all the REQUEST_CAPABILITY crqs, we send out the QUERY_IP_OFFLOAD CRQ. We currently increment ->running_cap_crqs as we send out each CRQ and have the ibmvnic_tasklet() send out the next message type, when this running_cap_crqs count drops to 0. This assumes that all the CRQs of the current type were sent out before the count drops to 0. However it is possible that we send out say 6 CRQs, get preempted and receive all the 6 responses before we send out the remaining CRQs. This can result in ->running_cap_crqs count dropping to zero before all messages of the current type were sent and we end up sending the next protocol message too early. Instead initialize the ->running_cap_crqs upfront so the tasklet will only send the next protocol message after all responses are received. Use the cap_reqs local variable to also detect any discrepancy (either now or in future) in the number of capability requests we actually send. Currently only send_query_cap() is affected by this behavior (of sending next message early) since it is called from the worker thread (during reset) and from application thread (during ->ndo_open()) and they can be preempted. send_request_cap() is only called from the tasklet which processes CRQ responses sequentially, is not be affected. But to maintain the existing symmtery with send_query_capability() we update send_request_capability() also. Fixes: 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capa= bilities crqs") Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/ethernet/ibm/ibmvnic.c | 106 +++++++++++++++++++---------- 1 file changed, 71 insertions(+), 35 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/= ibmvnic.c index 9adfc0a7ab823..6ecbe70614378 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -3258,11 +3258,25 @@ static void ibmvnic_send_req_caps(struct ibmvnic_ad= apter *adapter, int retry) struct device *dev =3D &adapter->vdev->dev; union ibmvnic_crq crq; int max_entries; + int cap_reqs; + + /* We send out 6 or 7 REQUEST_CAPABILITY CRQs below (depending on + * the PROMISC flag). Initialize this count upfront. When the tasklet + * receives a response to all of these, it will send the next protocol + * message (QUERY_IP_OFFLOAD). + */ + if (!(adapter->netdev->flags & IFF_PROMISC) || + adapter->promisc_supported) + cap_reqs =3D 7; + else + cap_reqs =3D 6; =20 if (!retry) { /* Sub-CRQ entries are 32 byte long */ int entries_page =3D 4 * PAGE_SIZE / (sizeof(u64) * 4); =20 + atomic_set(&adapter->running_cap_crqs, cap_reqs); + if (adapter->min_tx_entries_per_subcrq > entries_page || adapter->min_rx_add_entries_per_subcrq > entries_page) { dev_err(dev, "Fatal, invalid entries per sub-crq\n"); @@ -3323,44 +3337,45 @@ static void ibmvnic_send_req_caps(struct ibmvnic_ad= apter *adapter, int retry) adapter->opt_rx_comp_queues; =20 adapter->req_rx_add_queues =3D adapter->max_rx_add_queues; + } else { + atomic_add(cap_reqs, &adapter->running_cap_crqs); } - memset(&crq, 0, sizeof(crq)); crq.request_capability.first =3D IBMVNIC_CRQ_CMD; crq.request_capability.cmd =3D REQUEST_CAPABILITY; =20 crq.request_capability.capability =3D cpu_to_be16(REQ_TX_QUEUES); crq.request_capability.number =3D cpu_to_be64(adapter->req_tx_queues); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_RX_QUEUES); crq.request_capability.number =3D cpu_to_be64(adapter->req_rx_queues); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_RX_ADD_QUEUES); crq.request_capability.number =3D cpu_to_be64(adapter->req_rx_add_queues); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_TX_ENTRIES_PER_SUBCRQ); crq.request_capability.number =3D cpu_to_be64(adapter->req_tx_entries_per_subcrq); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_RX_ADD_ENTRIES_PER_SUBCRQ); crq.request_capability.number =3D cpu_to_be64(adapter->req_rx_add_entries_per_subcrq); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 crq.request_capability.capability =3D cpu_to_be16(REQ_MTU); crq.request_capability.number =3D cpu_to_be64(adapter->req_mtu); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); =20 if (adapter->netdev->flags & IFF_PROMISC) { @@ -3368,16 +3383,21 @@ static void ibmvnic_send_req_caps(struct ibmvnic_ad= apter *adapter, int retry) crq.request_capability.capability =3D cpu_to_be16(PROMISC_REQUESTED); crq.request_capability.number =3D cpu_to_be64(1); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); } } else { crq.request_capability.capability =3D cpu_to_be16(PROMISC_REQUESTED); crq.request_capability.number =3D cpu_to_be64(0); - atomic_inc(&adapter->running_cap_crqs); + cap_reqs--; ibmvnic_send_crq(adapter, &crq); } + + /* Keep at end to catch any discrepancy between expected and actual + * CRQs sent. + */ + WARN_ON(cap_reqs !=3D 0); } =20 static int pending_scrq(struct ibmvnic_adapter *adapter, @@ -3782,118 +3802,132 @@ static void send_map_query(struct ibmvnic_adapter= *adapter) static void send_cap_queries(struct ibmvnic_adapter *adapter) { union ibmvnic_crq crq; + int cap_reqs; + + /* We send out 25 QUERY_CAPABILITY CRQs below. Initialize this count + * upfront. When the tasklet receives a response to all of these, it + * can send out the next protocol messaage (REQUEST_CAPABILITY). + */ + cap_reqs =3D 25; + + atomic_set(&adapter->running_cap_crqs, cap_reqs); =20 - atomic_set(&adapter->running_cap_crqs, 0); memset(&crq, 0, sizeof(crq)); crq.query_capability.first =3D IBMVNIC_CRQ_CMD; crq.query_capability.cmd =3D QUERY_CAPABILITY; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_TX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_RX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_RX_ADD_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_TX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_RX_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_RX_ADD_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_TX_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_RX_ADD_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_TX_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_RX_ADD_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(TCP_IP_OFFLOAD); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(PROMISC_SUPPORTED); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MIN_MTU); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_MTU); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_MULTICAST_FILTERS); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(VLAN_HEADER_INSERTION); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(RX_VLAN_HEADER_INSERTION); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(MAX_TX_SG_ENTRIES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(RX_SG_SUPPORTED); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_TX_COMP_SUB_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_RX_COMP_QUEUES); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_RX_BUFADD_Q_PER_RX_COMP_Q); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_TX_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(OPT_RXBA_ENTRIES_PER_SUBCRQ); - atomic_inc(&adapter->running_cap_crqs); ibmvnic_send_crq(adapter, &crq); + cap_reqs--; =20 crq.query_capability.capability =3D cpu_to_be16(TX_RX_DESC_REQ); - atomic_inc(&adapter->running_cap_crqs); + ibmvnic_send_crq(adapter, &crq); + cap_reqs--; + + /* Keep at end to catch any discrepancy between expected and actual + * CRQs sent. + */ + WARN_ON(cap_reqs !=3D 0); } =20 static void handle_vpd_size_rsp(union ibmvnic_crq *crq, @@ -4160,6 +4194,8 @@ static void handle_request_cap_rsp(union ibmvnic_crq = *crq, char *name; =20 atomic_dec(&adapter->running_cap_crqs); + netdev_dbg(adapter->netdev, "Outstanding request-caps: %d\n", + atomic_read(&adapter->running_cap_crqs)); switch (be16_to_cpu(crq->request_capability_rsp.capability)) { case REQ_TX_QUEUES: req_value =3D &adapter->req_tx_queues; --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 B5D81C4332F for ; Mon, 31 Jan 2022 11:01:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358519AbiAaLBq (ORCPT ); Mon, 31 Jan 2022 06:01:46 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:60416 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358623AbiAaLAh (ORCPT ); Mon, 31 Jan 2022 06:00:37 -0500 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 7127960ABE; Mon, 31 Jan 2022 11:00:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51A02C340E8; Mon, 31 Jan 2022 11:00:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626836; bh=hp3tUhukj1H0fyjDpKJuoQvkedvjJfb9P/laApICm3M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mRN+IdXbopUU+c5ECz+aWD9it4YvrYaT56rMZWIm4DDvKMTYqWIbgUSp3/OdcaL9L va9GuRWioHVG6swnFbvQoMBhId0ZH5kjED8EiigRe3TkhL7dLdX5s3tRj2W7cHR2Ot kcrWIF/FkBpGjiHixLcayL/bypCU2ALPhtcd4daY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Sukadev Bhattiprolu , Dany Madden , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 55/64] ibmvnic: dont spin in tasklet Date: Mon, 31 Jan 2022 11:56:40 +0100 Message-Id: <20220131105217.538146815@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Sukadev Bhattiprolu [ Upstream commit 48079e7fdd0269d66b1d7d66ae88bd03162464ad ] ibmvnic_tasklet() continuously spins waiting for responses to all capability requests. It does this to avoid encountering an error during initialization of the vnic. However if there is a bug in the VIOS and we do not receive a response to one or more queries the tasklet ends up spinning continuously leading to hard lock ups. If we fail to receive a message from the VIOS it is reasonable to timeout the login attempt rather than spin indefinitely in the tasklet. Fixes: 249168ad07cd ("ibmvnic: Make CRQ interrupt tasklet wait for all capa= bilities crqs") Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/ethernet/ibm/ibmvnic.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/= ibmvnic.c index 6ecbe70614378..26d49dcdbeb3e 100644 --- a/drivers/net/ethernet/ibm/ibmvnic.c +++ b/drivers/net/ethernet/ibm/ibmvnic.c @@ -4823,12 +4823,6 @@ static void ibmvnic_tasklet(void *data) ibmvnic_handle_crq(crq, adapter); crq->generic.first =3D 0; } - - /* remain in tasklet until all - * capabilities responses are received - */ - if (!adapter->wait_capability) - done =3D true; } /* if capabilities CRQ's were sent in this tasklet, the following * tasklet must wait until all responses are received --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 8A6A6C433EF for ; Mon, 31 Jan 2022 11:01:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358539AbiAaLBw (ORCPT ); Mon, 31 Jan 2022 06:01:52 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48454 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358530AbiAaLAm (ORCPT ); Mon, 31 Jan 2022 06:00:42 -0500 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 11C92B82A5B; Mon, 31 Jan 2022 11:00:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DD33C340EE; Mon, 31 Jan 2022 11:00:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626839; bh=/wAIDgbERjf5UmB7nohSv94TjpNXrntbr7XxfL+KZ5A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Sv8U26TrP39ev74c6rTdXDE+ZMX4X5YHBn+oH4HxT/NlF7gKRcIF2/i9FJ2DsWt2Z 8CBKn0DxAnHYdKc1rC1fRLFH4+3jlHwFxeLCRF/35mU2dwABTY5f6NgjdrDxycpVGH HkUVYArh8pqKKQ6coEipEkrzdmxyZmrXkI3JEy1I= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Miaoqian Lin , Dmitry Baryshkov , Sasha Levin Subject: [PATCH 5.4 56/64] drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phy Date: Mon, 31 Jan 2022 11:56:41 +0100 Message-Id: <20220131105217.568120068@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 774fe0cd838d1b1419d41ab4ea0613c80d4ecbd7 ] The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling path. Fixes: e00012b256d4 ("drm/msm/hdmi: Make HDMI core get its PHY") Signed-off-by: Miaoqian Lin Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220107085026.23831-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/gpu/drm/msm/hdmi/hdmi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/drivers/gpu/drm/msm/hdmi/hdm= i.c index 355afb936401a..1a7e77373407f 100644 --- a/drivers/gpu/drm/msm/hdmi/hdmi.c +++ b/drivers/gpu/drm/msm/hdmi/hdmi.c @@ -97,10 +97,15 @@ static int msm_hdmi_get_phy(struct hdmi *hdmi) =20 of_node_put(phy_node); =20 - if (!phy_pdev || !hdmi->phy) { + if (!phy_pdev) { DRM_DEV_ERROR(&pdev->dev, "phy driver is not ready\n"); return -EPROBE_DEFER; } + if (!hdmi->phy) { + DRM_DEV_ERROR(&pdev->dev, "phy driver is not ready\n"); + put_device(&phy_pdev->dev); + return -EPROBE_DEFER; + } =20 hdmi->phy_dev =3D get_device(&phy_pdev->dev); =20 --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 4FA5EC433F5 for ; Mon, 31 Jan 2022 11:01:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358863AbiAaLBz (ORCPT ); Mon, 31 Jan 2022 06:01:55 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48518 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240064AbiAaLAp (ORCPT ); Mon, 31 Jan 2022 06:00:45 -0500 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 21614B82A62; Mon, 31 Jan 2022 11:00:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D544C340E8; Mon, 31 Jan 2022 11:00:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626843; bh=GZs9L7T9/6ZSXdD31buqSGJavwQTf+8MmVZed58b7SQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dv9LgpoeGUL7Wmf7oqHg17ZJBJAObTt0ituSXn/YHqWrUjg64w9abCwARJJckzp8F kZrLkFej3mo6QXXeRAK8RAoHRUoAbWuQG3WYy2oc+6VvqBNONFb67o86TusDX7QzXM k9DFwmCwj4kPq5IvA0Rm6IcGzp2MCJyVBibRr2qA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Hangyu Hua , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 57/64] yam: fix a memory leak in yam_siocdevprivate() Date: Mon, 31 Jan 2022 11:56:42 +0100 Message-Id: <20220131105217.601561681@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Hangyu Hua [ Upstream commit 29eb31542787e1019208a2e1047bb7c76c069536 ] ym needs to be free when ym->cmd !=3D SIOCYAMSMCS. Fixes: 0781168e23a2 ("yam: fix a missing-check bug") Signed-off-by: Hangyu Hua Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/hamradio/yam.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c index 5ab53e9942f30..5d30b3e1806ab 100644 --- a/drivers/net/hamradio/yam.c +++ b/drivers/net/hamradio/yam.c @@ -951,9 +951,7 @@ static int yam_ioctl(struct net_device *dev, struct ifr= eq *ifr, int cmd) sizeof(struct yamdrv_ioctl_mcs)); if (IS_ERR(ym)) return PTR_ERR(ym); - if (ym->cmd !=3D SIOCYAMSMCS) - return -EINVAL; - if (ym->bitrate > YAM_MAXBITRATE) { + if (ym->cmd !=3D SIOCYAMSMCS || ym->bitrate > YAM_MAXBITRATE) { kfree(ym); return -EINVAL; } --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 63870C4321E for ; Mon, 31 Jan 2022 11:02:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358559AbiAaLCC (ORCPT ); Mon, 31 Jan 2022 06:02:02 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:33372 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358543AbiAaLAq (ORCPT ); Mon, 31 Jan 2022 06:00:46 -0500 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 AF73D60B2E; Mon, 31 Jan 2022 11:00:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75F3EC340EF; Mon, 31 Jan 2022 11:00:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626846; bh=UX7bfLZZjswaacQhiYiq56Uuh1Jos6QIbBnp3bN5WmQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XZFXv5B1EEgsavwjI/ucDADPBp6dkj8H+dKA61aGAlF73/gcAub7GhqQrABjqMbjZ VmKCAUuUS6fG5KKV5zUysbze21ZQycGq121K/CQY/w7SwljuV1dyC0jRJqRRtKO3nP 1qr9rrGmLkFA/PTQhXRf1MeF3u6v7HW9mGdae3m0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Yufeng Mo , Guangbin Huang , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 58/64] net: hns3: handle empty unknown interrupt for VF Date: Mon, 31 Jan 2022 11:56:43 +0100 Message-Id: <20220131105217.631535565@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Yufeng Mo [ Upstream commit 2f61353cd2f789a4229b6f5c1c24a40a613357bb ] Since some interrupt states may be cleared by hardware, the driver may receive an empty interrupt. Currently, the VF driver directly disables the vector0 interrupt in this case. As a result, the VF is unavailable. Therefore, the vector0 interrupt should be enabled in this case. Fixes: b90fcc5bd904 ("net: hns3: add reset handling for VF when doing Core/= Global/IMP reset") Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/dr= ivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c index ce6a4e1965e1d..403c1b9cf6ab8 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c @@ -1970,8 +1970,7 @@ static irqreturn_t hclgevf_misc_irq_handle(int irq, v= oid *data) break; } =20 - if (event_cause !=3D HCLGEVF_VECTOR0_EVENT_OTHER) - hclgevf_enable_vector(&hdev->misc_vector, true); + hclgevf_enable_vector(&hdev->misc_vector, true); =20 return IRQ_HANDLED; } --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 7C5D7C4321E for ; Mon, 31 Jan 2022 11:01:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358679AbiAaLB6 (ORCPT ); Mon, 31 Jan 2022 06:01:58 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:48590 "EHLO ams.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358641AbiAaLAv (ORCPT ); Mon, 31 Jan 2022 06:00:51 -0500 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 76B6AB82A68; Mon, 31 Jan 2022 11:00:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B15AC36AE3; Mon, 31 Jan 2022 11:00:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626849; bh=PUmvYzb+OCYFQGmQDGGTRfDoODW0wPWWKqGQXNDZGwI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SPvN0/pF00wv2gGmawd5vIFx+ZIOmDJlMPRnjENIAQIysUpSft4lMaB2UuyXNASDB 32tQXMzyV/9kBAdA8u/FaHN2mssSLprgnYaWP7jGc0l0GAENQFhC05+JJpz8yHVOvJ 9AfN1e3rurnJaOsUTbU/1kknAf9X2OApwr9h3Z5Y= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , syzbot , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 59/64] ipv4: raw: lock the socket in raw_bind() Date: Mon, 31 Jan 2022 11:56:44 +0100 Message-Id: <20220131105217.664192135@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 153a0d187e767c68733b8e9f46218eb1f41ab902 ] For some reason, raw_bind() forgot to lock the socket. BUG: KCSAN: data-race in __ip4_datagram_connect / raw_bind write to 0xffff8881170d4308 of 4 bytes by task 5466 on cpu 0: raw_bind+0x1b0/0x250 net/ipv4/raw.c:739 inet_bind+0x56/0xa0 net/ipv4/af_inet.c:443 __sys_bind+0x14b/0x1b0 net/socket.c:1697 __do_sys_bind net/socket.c:1708 [inline] __se_sys_bind net/socket.c:1706 [inline] __x64_sys_bind+0x3d/0x50 net/socket.c:1706 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff8881170d4308 of 4 bytes by task 5468 on cpu 1: __ip4_datagram_connect+0xb7/0x7b0 net/ipv4/datagram.c:39 ip4_datagram_connect+0x2a/0x40 net/ipv4/datagram.c:89 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00000000 -> 0x0003007f Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 5468 Comm: syz-executor.5 Not tainted 5.17.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Goo= gle 01/01/2011 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/ipv4/raw.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c index 3183413ebc6c2..ddc24e57dc555 100644 --- a/net/ipv4/raw.c +++ b/net/ipv4/raw.c @@ -720,6 +720,7 @@ static int raw_bind(struct sock *sk, struct sockaddr *u= addr, int addr_len) int ret =3D -EINVAL; int chk_addr_ret; =20 + lock_sock(sk); if (sk->sk_state !=3D TCP_CLOSE || addr_len < sizeof(struct sockaddr_in)) goto out; =20 @@ -739,7 +740,9 @@ static int raw_bind(struct sock *sk, struct sockaddr *u= addr, int addr_len) inet->inet_saddr =3D 0; /* Use device */ sk_dst_reset(sk); ret =3D 0; -out: return ret; +out: + release_sock(sk); + return ret; } =20 /* --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 601FFC43219 for ; Mon, 31 Jan 2022 11:04:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359248AbiAaLEv (ORCPT ); Mon, 31 Jan 2022 06:04:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43472 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358796AbiAaLCf (ORCPT ); Mon, 31 Jan 2022 06:02:35 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A1A5C06136C; Mon, 31 Jan 2022 03:00:54 -0800 (PST) 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 44601B82A69; Mon, 31 Jan 2022 11:00:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC15BC340EE; Mon, 31 Jan 2022 11:00:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626852; bh=krk3JK/6W2Uck8W8Qsdm4XLEPCdioCNoGKl/TvaDwy4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eh5gvIoVVs6T2Ifa+buAzEnu1dN2qI+ql6u7wxKim7nBsXvOmXef9XvIF2UcjmbfW BWoKXu78dUe+OL3cd2f/UHop/5aoMb58ciuIEhRF+mosfVjeon67XULhByjQa8CVad 1I55LrYfF0b85fGAKtyILnjDU3qI4zZdhv796cYM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , Ray Che , David Ahern , Geoff Alexander , Willy Tarreau , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.4 60/64] ipv4: tcp: send zero IPID in SYNACK messages Date: Mon, 31 Jan 2022 11:56:45 +0100 Message-Id: <20220131105217.695729664@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 970a5a3ea86da637471d3cd04d513a0755aba4bf ] In commit 431280eebed9 ("ipv4: tcp: send zero IPID for RST and ACK sent in SYN-RECV and TIME-WAIT state") we took care of some ctl packets sent by TCP. It turns out we need to use a similar strategy for SYNACK packets. By default, they carry IP_DF and IPID=3D=3D0, but there are ways to ask them to use the hashed IP ident generator and thus be used to build off-path attacks. (Ref: Off-Path TCP Exploits of the Mixed IPID Assignment) One of this way is to force (before listener is started) echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc Another way is using forged ICMP ICMP_FRAG_NEEDED with a very small MTU (like 68) to force a false return from ip_dont_fragment() In this patch, ip_build_and_send_pkt() uses the following heuristics. 1) Most SYNACK packets are smaller than IPV4_MIN_MTU and therefore can use IP_DF regardless of the listener or route pmtu setting. 2) In case the SYNACK packet is bigger than IPV4_MIN_MTU, we use prandom_u32() generator instead of the IPv4 hashed ident one. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: Ray Che Reviewed-by: David Ahern Cc: Geoff Alexander Cc: Willy Tarreau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- net/ipv4/ip_output.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 0ec529d77a56e..418e939878004 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -161,12 +161,19 @@ int ip_build_and_send_pkt(struct sk_buff *skb, const = struct sock *sk, iph->daddr =3D (opt && opt->opt.srr ? opt->opt.faddr : daddr); iph->saddr =3D saddr; iph->protocol =3D sk->sk_protocol; - if (ip_dont_fragment(sk, &rt->dst)) { + /* Do not bother generating IPID for small packets (eg SYNACK) */ + if (skb->len <=3D IPV4_MIN_MTU || ip_dont_fragment(sk, &rt->dst)) { iph->frag_off =3D htons(IP_DF); iph->id =3D 0; } else { iph->frag_off =3D 0; - __ip_select_ident(net, iph, 1); + /* TCP packets here are SYNACK with fat IPv4/TCP options. + * Avoid using the hashed IP ident generator. + */ + if (sk->sk_protocol =3D=3D IPPROTO_TCP) + iph->id =3D (__force __be16)prandom_u32(); + else + __ip_select_ident(net, iph, 1); } =20 if (opt && opt->opt.optlen) { --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 B03ECC433FE for ; Mon, 31 Jan 2022 11:04:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358925AbiAaLEF (ORCPT ); Mon, 31 Jan 2022 06:04:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42868 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358800AbiAaLCf (ORCPT ); Mon, 31 Jan 2022 06:02:35 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50854C06136E; Mon, 31 Jan 2022 03:00:56 -0800 (PST) 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 E586460B28; Mon, 31 Jan 2022 11:00:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA944C340F0; Mon, 31 Jan 2022 11:00:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626855; bh=/JNizw2DE/Nlkh/hEPWIG7X7g8UTIItZA4wTHSrZrjM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P/jzkdWNXmXiTPXWFfBSpR4PMjawCu3c+VkTQv8BJcg5y2ZgXv5qw3nRKMCs5JlZf /zFufVZxB7UGv806EcKG3MUnbtvnxMGfmRHxsO56L2kutozvNlW4H6ff8HNGjedtaB Lg6ceGjYfKdWwzqRTBOwF5QZBNN0PRyxAwrLXdIo= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Dumazet , David Ahern , Jakub Kicinski , Sasha Levin Subject: [PATCH 5.4 61/64] ipv4: remove sparse error in ip_neigh_gw4() Date: Mon, 31 Jan 2022 11:56:46 +0100 Message-Id: <20220131105217.726529190@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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 3c42b2019863b327caa233072c50739d4144dd16 ] ./include/net/route.h:373:48: warning: incorrect type in argument 2 (differ= ent base types) ./include/net/route.h:373:48: expected unsigned int [usertype] key ./include/net/route.h:373:48: got restricted __be32 [usertype] daddr Fixes: 5c9f7c1dfc2e ("ipv4: Add helpers for neigh lookup for nexthop") Signed-off-by: Eric Dumazet Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20220127013404.1279313-1-eric.dumazet@gmail= .com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- include/net/route.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/route.h b/include/net/route.h index 6c516840380db..b85d1912d84fd 100644 --- a/include/net/route.h +++ b/include/net/route.h @@ -359,7 +359,7 @@ static inline struct neighbour *ip_neigh_gw4(struct net= _device *dev, { struct neighbour *neigh; =20 - neigh =3D __ipv4_neigh_lookup_noref(dev, daddr); + neigh =3D __ipv4_neigh_lookup_noref(dev, (__force u32)daddr); if (unlikely(!neigh)) neigh =3D __neigh_create(&arp_tbl, &daddr, dev, false); =20 --=20 2.34.1 From nobody Wed Jul 1 03:23:32 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 ACFBBC433F5 for ; Mon, 31 Jan 2022 11:05:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358983AbiAaLFU (ORCPT ); Mon, 31 Jan 2022 06:05:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43026 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359013AbiAaLCr (ORCPT ); Mon, 31 Jan 2022 06:02:47 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 77B5CC06176D; Mon, 31 Jan 2022 03:00:59 -0800 (PST) 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 15B7D60A75; Mon, 31 Jan 2022 11:00:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAC65C340E8; Mon, 31 Jan 2022 11:00:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626858; bh=DoZ1E/+8ix+OgIbNqPUNVDPpuSpcbXv83pH9UB60g/M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ov1UPJhItPnWCL9eFPn4NVZwlr+1XNM87qkZLhlmpZt44N686PuGlbBVL4Kzqq4pa T3rsi0XUVGmcJarlIgXZNM7ViyoPygsXjxPOgOIogi4Lw5sQj0cBZFKFMN/UbyAqYu AclrFwrSIxcayWHMtch8btkPW7tyepcY4RG80BvA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marc Kleine-Budde Subject: [PATCH 5.4 62/64] dt-bindings: can: tcan4x5x: fix mram-cfg RX FIFO config Date: Mon, 31 Jan 2022 11:56:47 +0100 Message-Id: <20220131105217.757376575@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Marc Kleine-Budde commit 17a30422621c0e04cb6060d20d7edcefd7463347 upstream. This tcan4x5x only comes with 2K of MRAM, a RX FIFO with a dept of 32 doesn't fit into the MRAM. Use a depth of 16 instead. Fixes: 4edd396a1911 ("dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4= x5X driver") Link: https://lore.kernel.org/all/20220119062951.2939851-1-mkl@pengutronix.= de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- Documentation/devicetree/bindings/net/can/tcan4x5x.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt +++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt @@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 { #address-cells =3D <1>; #size-cells =3D <1>; spi-max-frequency =3D <10000000>; - bosch,mram-cfg =3D <0x0 0 0 32 0 0 1 1>; + bosch,mram-cfg =3D <0x0 0 0 16 0 0 1 1>; interrupt-parent =3D <&gpio1>; interrupts =3D <14 IRQ_TYPE_LEVEL_LOW>; device-state-gpios =3D <&gpio3 21 GPIO_ACTIVE_HIGH>; From nobody Wed Jul 1 03:23:32 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 B63FDC4332F for ; Mon, 31 Jan 2022 11:02:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348500AbiAaLCU (ORCPT ); Mon, 31 Jan 2022 06:02:20 -0500 Received: from dfw.source.kernel.org ([139.178.84.217]:33612 "EHLO dfw.source.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358713AbiAaLBC (ORCPT ); Mon, 31 Jan 2022 06:01:02 -0500 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 10DD260B28; Mon, 31 Jan 2022 11:01:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E51B8C340E8; Mon, 31 Jan 2022 11:01:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626861; bh=/cyntStqv4oCksUJ9KxDVSZM2fJVy4w1KJWyVenh8Vg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X+ITaRDO/DnJib8AsfDIQygsC6oGmlK5pepFgJ15W9hHVB/B9bdpJwfUc9amYbBO+ P5j4BfMLd8maRX3tfV0vkJQ3RA3ikLbMfK60xViKGqnen93xcFPON576SM2EmdB0nc WCT8RRBPFeKvz/YY2k+tbjcd4cMKEOYQLmys9SbM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ivan Delalande , Amir Goldstein , Jan Kara Subject: [PATCH 5.4 63/64] fsnotify: invalidate dcache before IN_DELETE event Date: Mon, 31 Jan 2022 11:56:48 +0100 Message-Id: <20220131105217.789125603@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: Amir Goldstein commit a37d9a17f099072fe4d3a9048b0321978707a918 upstream. Apparently, there are some applications that use IN_DELETE event as an invalidation mechanism and expect that if they try to open a file with the name reported with the delete event, that it should not contain the content of the deleted file. Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify will have access to a positive dentry. This allowed a race where opening the deleted file via cached dentry is now possible after receiving the IN_DELETE event. To fix the regression, create a new hook fsnotify_delete() that takes the unlinked inode as an argument and use a helper d_delete_notify() to pin the inode, so we can pass it to fsnotify_delete() after d_delete(). Backporting hint: this regression is from v5.3. Although patch will apply with only trivial conflicts to v5.4 and v5.10, it won't build, because fsnotify_delete() implementation is different in each of those versions (see fsnotify_link()). A follow up patch will fix the fsnotify_unlink/rmdir() calls in pseudo filesystem that do not need to call d_delete(). Link: https://lore.kernel.org/r/20220120215305.282577-1-amir73il@gmail.com Reported-by: Ivan Delalande Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/ Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_de= lete()") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Amir Goldstein Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- fs/btrfs/ioctl.c | 6 +---- fs/namei.c | 10 ++++----- include/linux/fsnotify.h | 48 +++++++++++++++++++++++++++++++++++++++++-= ----- 3 files changed, 49 insertions(+), 15 deletions(-) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -3027,10 +3027,8 @@ static noinline int btrfs_ioctl_snap_des inode_lock(inode); err =3D btrfs_delete_subvolume(dir, dentry); inode_unlock(inode); - if (!err) { - fsnotify_rmdir(dir, dentry); - d_delete(dentry); - } + if (!err) + d_delete_notify(dir, dentry); =20 out_dput: dput(dentry); --- a/fs/namei.c +++ b/fs/namei.c @@ -3878,13 +3878,12 @@ int vfs_rmdir(struct inode *dir, struct dentry->d_inode->i_flags |=3D S_DEAD; dont_mount(dentry); detach_mounts(dentry); - fsnotify_rmdir(dir, dentry); =20 out: inode_unlock(dentry->d_inode); dput(dentry); if (!error) - d_delete(dentry); + d_delete_notify(dir, dentry); return error; } EXPORT_SYMBOL(vfs_rmdir); @@ -3995,7 +3994,6 @@ int vfs_unlink(struct inode *dir, struct if (!error) { dont_mount(dentry); detach_mounts(dentry); - fsnotify_unlink(dir, dentry); } } } @@ -4003,9 +4001,11 @@ out: inode_unlock(target); =20 /* We don't d_delete() NFS sillyrenamed files--they still exist. */ - if (!error && !(dentry->d_flags & DCACHE_NFSFS_RENAMED)) { + if (!error && dentry->d_flags & DCACHE_NFSFS_RENAMED) { + fsnotify_unlink(dir, dentry); + } else if (!error) { fsnotify_link_count(target); - d_delete(dentry); + d_delete_notify(dir, dentry); } =20 return error; --- a/include/linux/fsnotify.h +++ b/include/linux/fsnotify.h @@ -189,16 +189,52 @@ static inline void fsnotify_link(struct } =20 /* + * fsnotify_delete - @dentry was unlinked and unhashed + * + * Caller must make sure that dentry->d_name is stable. + * + * Note: unlike fsnotify_unlink(), we have to pass also the unlinked inode + * as this may be called after d_delete() and old_dentry may be negative. + */ +static inline void fsnotify_delete(struct inode *dir, struct inode *inode, + struct dentry *dentry) +{ + __u32 mask =3D FS_DELETE; + + if (S_ISDIR(inode->i_mode)) + mask |=3D FS_ISDIR; + + fsnotify(dir, mask, inode, FSNOTIFY_EVENT_INODE, &dentry->d_name, 0); +} + +/** + * d_delete_notify - delete a dentry and call fsnotify_delete() + * @dentry: The dentry to delete + * + * This helper is used to guaranty that the unlinked inode cannot be found + * by lookup of this name after fsnotify_delete() event has been delivered. + */ +static inline void d_delete_notify(struct inode *dir, struct dentry *dentr= y) +{ + struct inode *inode =3D d_inode(dentry); + + ihold(inode); + d_delete(dentry); + fsnotify_delete(dir, inode, dentry); + iput(inode); +} + +/* * fsnotify_unlink - 'name' was unlinked * * Caller must make sure that dentry->d_name is stable. */ static inline void fsnotify_unlink(struct inode *dir, struct dentry *dentr= y) { - /* Expected to be called before d_delete() */ - WARN_ON_ONCE(d_is_negative(dentry)); + if (WARN_ON_ONCE(d_is_negative(dentry))) + return; =20 - fsnotify_dirent(dir, dentry, FS_DELETE); + fsnotify_delete(dir, d_inode(dentry), dentry); } =20 /* @@ -218,10 +254,10 @@ static inline void fsnotify_mkdir(struct */ static inline void fsnotify_rmdir(struct inode *dir, struct dentry *dentry) { - /* Expected to be called before d_delete() */ - WARN_ON_ONCE(d_is_negative(dentry)); + if (WARN_ON_ONCE(d_is_negative(dentry))) + return; =20 - fsnotify_dirent(dir, dentry, FS_DELETE | FS_ISDIR); + fsnotify_delete(dir, d_inode(dentry), dentry); } =20 /* From nobody Wed Jul 1 03:23:32 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 74632C433F5 for ; Mon, 31 Jan 2022 11:05:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1359335AbiAaLFM (ORCPT ); Mon, 31 Jan 2022 06:05:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1359062AbiAaLCx (ORCPT ); Mon, 31 Jan 2022 06:02:53 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EE126C061777; Mon, 31 Jan 2022 03:01:06 -0800 (PST) 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 B8A6AB82A65; Mon, 31 Jan 2022 11:01:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD9F4C340EE; Mon, 31 Jan 2022 11:01:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1643626864; bh=4vgkwUN3HLgTHzDFntrtt0VQKHQcx+ZIF7bDA5iyJlw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wXvRjVICtI8jbv751SLuxm+wqSEpEJL+/SNs8rjew4jKXKkzRAGxKS6QquGobhmMQ mwz/bwe4VKaHwkLs12Ura4DUMI+OTFvzkZu0dBTQM+cj36qz9WiW+2ZhTkDiC0/lr5 wuKDoQDCzkDdrLHLfiAuk6QV48TSmz8Rn2RjKjt8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+ac94ae5f68b84197f41c@syzkaller.appspotmail.com, OGAWA Hirofumi , Ming Lei , Jens Axboe Subject: [PATCH 5.4 64/64] block: Fix wrong offset in bio_truncate() Date: Mon, 31 Jan 2022 11:56:49 +0100 Message-Id: <20220131105217.821837502@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220131105215.644174521@linuxfoundation.org> References: <20220131105215.644174521@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: OGAWA Hirofumi commit 3ee859e384d453d6ac68bfd5971f630d9fa46ad3 upstream. bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev. Reported-by: syzbot+ac94ae5f68b84197f41c@syzkaller.appspotmail.com Signed-off-by: OGAWA Hirofumi Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/875yqt1c9g.fsf@mail.parknet.co.jp Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan --- block/bio.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/block/bio.c +++ b/block/bio.c @@ -569,7 +569,8 @@ void bio_truncate(struct bio *bio, unsig offset =3D new_size - done; else offset =3D 0; - zero_user(bv.bv_page, offset, bv.bv_len - offset); + zero_user(bv.bv_page, bv.bv_offset + offset, + bv.bv_len - offset); truncated =3D true; } done +=3D bv.bv_len;