From nobody Fri Apr 10 10:51:46 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 DAFD1C38145 for ; Fri, 2 Sep 2022 12:56:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238283AbiIBM46 (ORCPT ); Fri, 2 Sep 2022 08:56:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238284AbiIBMyR (ORCPT ); Fri, 2 Sep 2022 08:54:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D228913F59; Fri, 2 Sep 2022 05:38:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AF49A62119; Fri, 2 Sep 2022 12:38:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3822C433C1; Fri, 2 Sep 2022 12:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122318; bh=56qpjWB8mJKn1eLnKq9RG+xLWF2hplTX40XmhiVK548=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Wq0LdSDgEBtYQYuWc8mI/7k+bwksLfSJOJUzE5tINQFzXzVDXiKvP0OZgffEmmEPa W9SPG41ywKBBY60t/Nk0eH6ArklKlLTD6KTDJwJ8EPcvcXp+77CYb5qEDB3Hb8dlKU 7sBD14BQ7+S8gFN7oieIik+ltLnfmQ6oisBC6XGk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Jann Horn Subject: [PATCH 5.10 01/37] mm: Force TLB flush for PFNMAP mappings before unlink_file_vma() Date: Fri, 2 Sep 2022 14:19:23 +0200 Message-Id: <20220902121359.222008856@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Jann Horn commit b67fbebd4cf980aecbcc750e1462128bffe8ae15 upstream. Some drivers rely on having all VMAs through which a PFN might be accessible listed in the rmap for correctness. However, on X86, it was possible for a VMA with stale TLB entries to not be listed in the rmap. This was fixed in mainline with commit b67fbebd4cf9 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas"), but that commit relies on preceding refactoring in commit 18ba064e42df3 ("mmu_gather: Let there be one tlb_{start,end}_vma() implementation") and commit 1e9fdf21a4339 ("mmu_gather: Remove per arch tlb_{start,end}_vma()"). This patch provides equivalent protection without needing that refactoring, by forcing a TLB flush between removing PTEs in unmap_vmas() and the call to unlink_file_vma() in free_pgtables(). [This is a stable-specific rewrite of the upstream commit!] Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- mm/mmap.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2669,6 +2669,18 @@ static void unmap_region(struct mm_struc tlb_gather_mmu(&tlb, mm, start, end); update_hiwater_rss(mm); unmap_vmas(&tlb, vma, start, end); + + /* + * Ensure we have no stale TLB entries by the time this mapping is + * removed from the rmap. + * Note that we don't have to worry about nested flushes here because + * we're holding the mm semaphore for removing the mapping - so any + * concurrent flush in this region has to be coming through the rmap, + * and we synchronize against that using the rmap lock. + */ + if ((vma->vm_flags & (VM_PFNMAP|VM_MIXEDMAP)) !=3D 0) + tlb_flush_mmu(&tlb); + free_pgtables(&tlb, vma, prev ? prev->vm_end : FIRST_USER_ADDRESS, next ? next->vm_start : USER_PGTABLES_CEILING); tlb_finish_mmu(&tlb, start, end); From nobody Fri Apr 10 10:51:46 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 3B4ABC38145 for ; Fri, 2 Sep 2022 12:59:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238379AbiIBM7u (ORCPT ); Fri, 2 Sep 2022 08:59:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34604 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238383AbiIBM6c (ORCPT ); Fri, 2 Sep 2022 08:58:32 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7BEEF7679; Fri, 2 Sep 2022 05:39:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 630C3B82A91; Fri, 2 Sep 2022 12:38:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE4D0C433C1; Fri, 2 Sep 2022 12:38:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122321; bh=8ZyxFmBp2uqaGt5Eh18Ji1AwunRhLQ2k9S/b4qloXA0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=n/DBxG5lGRg9zCjFi/07A2JRXhQyOWsJEORFDpevoCpS0hxPaYp45Ria7slvNm25K nrfoCGb3Hivas8ciAPjIT9019TCCQsuLr89fRMHxek98Mctt8TV7MAY2o1iF7Ypv9O kxwt2IVV0D4jmmwp++u9/lc1qemAxmNW7+lNFZnQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Peter Zijlstra (Intel)" , Ben Hutchings Subject: [PATCH 5.10 02/37] x86/nospec: Unwreck the RSB stuffing Date: Fri, 2 Sep 2022 14:19:24 +0200 Message-Id: <20220902121359.251537007@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Peter Zijlstra commit 4e3aa9238277597c6c7624f302d81a7b568b6f2d upstream. Commit 2b1299322016 ("x86/speculation: Add RSB VM Exit protections") made a right mess of the RSB stuffing, rewrite the whole thing to not suck. Thanks to Andrew for the enlightening comment about Post-Barrier RSB things so we can make this code less magical. Cc: stable@vger.kernel.org Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/YvuNdDWoUZSBjYcm@worktop.programming.kicks-= ass.net [bwh: Backported to 5.10: adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/include/asm/nospec-branch.h | 80 +++++++++++++++++-------------= ----- 1 file changed, 39 insertions(+), 41 deletions(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -35,33 +35,44 @@ #define RSB_CLEAR_LOOPS 32 /* To forcibly overwrite all entries */ =20 /* + * Common helper for __FILL_RETURN_BUFFER and __FILL_ONE_RETURN. + */ +#define __FILL_RETURN_SLOT \ + ANNOTATE_INTRA_FUNCTION_CALL; \ + call 772f; \ + int3; \ +772: + +/* + * Stuff the entire RSB. + * * Google experimented with loop-unrolling and this turned out to be * the optimal version =E2=80=94 two calls, each with their own speculation * trap should their return address end up getting used, in a loop. */ -#define __FILL_RETURN_BUFFER(reg, nr, sp) \ - mov $(nr/2), reg; \ -771: \ - ANNOTATE_INTRA_FUNCTION_CALL; \ - call 772f; \ -773: /* speculation trap */ \ - UNWIND_HINT_EMPTY; \ - pause; \ - lfence; \ - jmp 773b; \ -772: \ - ANNOTATE_INTRA_FUNCTION_CALL; \ - call 774f; \ -775: /* speculation trap */ \ - UNWIND_HINT_EMPTY; \ - pause; \ - lfence; \ - jmp 775b; \ -774: \ - add $(BITS_PER_LONG/8) * 2, sp; \ - dec reg; \ - jnz 771b; \ - /* barrier for jnz misprediction */ \ +#define __FILL_RETURN_BUFFER(reg, nr) \ + mov $(nr/2), reg; \ +771: \ + __FILL_RETURN_SLOT \ + __FILL_RETURN_SLOT \ + add $(BITS_PER_LONG/8) * 2, %_ASM_SP; \ + dec reg; \ + jnz 771b; \ + /* barrier for jnz misprediction */ \ + lfence; + +/* + * Stuff a single RSB slot. + * + * To mitigate Post-Barrier RSB speculation, one CALL instruction must be + * forced to retire before letting a RET instruction execute. + * + * On PBRSB-vulnerable CPUs, it is not safe for a RET to be executed + * before this point. + */ +#define __FILL_ONE_RETURN \ + __FILL_RETURN_SLOT \ + add $(BITS_PER_LONG/8), %_ASM_SP; \ lfence; =20 #ifdef __ASSEMBLY__ @@ -120,28 +131,15 @@ #endif .endm =20 -.macro ISSUE_UNBALANCED_RET_GUARD - ANNOTATE_INTRA_FUNCTION_CALL - call .Lunbalanced_ret_guard_\@ - int3 -.Lunbalanced_ret_guard_\@: - add $(BITS_PER_LONG/8), %_ASM_SP - lfence -.endm - /* * A simpler FILL_RETURN_BUFFER macro. Don't make people use the CPP * monstrosity above, manually. */ -.macro FILL_RETURN_BUFFER reg:req nr:req ftr:req ftr2 -.ifb \ftr2 - ALTERNATIVE "jmp .Lskip_rsb_\@", "", \ftr -.else - ALTERNATIVE_2 "jmp .Lskip_rsb_\@", "", \ftr, "jmp .Lunbalanced_\@", \ftr2 -.endif - __FILL_RETURN_BUFFER(\reg,\nr,%_ASM_SP) -.Lunbalanced_\@: - ISSUE_UNBALANCED_RET_GUARD +.macro FILL_RETURN_BUFFER reg:req nr:req ftr:req ftr2=3DALT_NOT(X86_FEATUR= E_ALWAYS) + ALTERNATIVE_2 "jmp .Lskip_rsb_\@", \ + __stringify(__FILL_RETURN_BUFFER(\reg,\nr)), \ftr, \ + __stringify(__FILL_ONE_RETURN), \ftr2 + .Lskip_rsb_\@: .endm =20 From nobody Fri Apr 10 10:51:46 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 89929ECAAD5 for ; Fri, 2 Sep 2022 13:00:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238434AbiIBNAE (ORCPT ); Fri, 2 Sep 2022 09:00:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51244 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238503AbiIBM6y (ORCPT ); Fri, 2 Sep 2022 08:58:54 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B977E52FF3; Fri, 2 Sep 2022 05:40:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6038BB82A99; Fri, 2 Sep 2022 12:38:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94894C433C1; Fri, 2 Sep 2022 12:38:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122324; bh=nKLyEYkuJbbO4xhPz9cjO9niiSLIKKfhqIwlxrgCWTo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DS5GU5G46URqjC6+7JGdHmleuSOIsv9o8axWrW1jtGtWbSq+Upo+gUGTGPiC3tPBZ 4PY38XLxDT6pCLFsDvujFHhMPP3oaiJ4DvbDbvB253z3QxmGIcjlOZZfDwLZt/+3OX 8HNco6k8r63Yc4ZRnx4SDck7OvLSCefrTk70KFyg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ben Hutchings , "Peter Zijlstra (Intel)" Subject: [PATCH 5.10 03/37] x86/nospec: Fix i386 RSB stuffing Date: Fri, 2 Sep 2022 14:19:25 +0200 Message-Id: <20220902121359.280247994@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Peter Zijlstra commit 332924973725e8cdcc783c175f68cf7e162cb9e5 upstream. Turns out that i386 doesn't unconditionally have LFENCE, as such the loop in __FILL_RETURN_BUFFER isn't actually speculation safe on such chips. Fixes: ba6e31af2be9 ("x86/speculation: Add LFENCE to RSB fill sequence") Reported-by: Ben Hutchings Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/Yv9tj9vbQ9nNlXoY@worktop.programming.kicks-= ass.net Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/x86/include/asm/nospec-branch.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -50,6 +50,7 @@ * the optimal version =E2=80=94 two calls, each with their own speculation * trap should their return address end up getting used, in a loop. */ +#ifdef CONFIG_X86_64 #define __FILL_RETURN_BUFFER(reg, nr) \ mov $(nr/2), reg; \ 771: \ @@ -60,6 +61,17 @@ jnz 771b; \ /* barrier for jnz misprediction */ \ lfence; +#else +/* + * i386 doesn't unconditionally have LFENCE, as such it can't + * do a loop. + */ +#define __FILL_RETURN_BUFFER(reg, nr) \ + .rept nr; \ + __FILL_RETURN_SLOT; \ + .endr; \ + add $(BITS_PER_LONG/8) * nr, %_ASM_SP; +#endif =20 /* * Stuff a single RSB slot. From nobody Fri Apr 10 10:51:46 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 941DEC54EE9 for ; Fri, 2 Sep 2022 12:59:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238399AbiIBM7w (ORCPT ); Fri, 2 Sep 2022 08:59:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238448AbiIBM6m (ORCPT ); Fri, 2 Sep 2022 08:58:42 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13C2311A2F; Fri, 2 Sep 2022 05:39:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 47A64B82AC1; Fri, 2 Sep 2022 12:38:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 981CBC433D7; Fri, 2 Sep 2022 12:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122327; bh=K07g13l32rClJcNoxbLcDmonK4zHo/OsvyUnY5GNgG8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=InglBb5fuyfAqI1paYrPu46TtnMWMTM/Gyc3voj1fc1aHUlxiOUcUODp3i7jol6c+ lFq8FP6jZUt3JatZfpBtafY01S49JmZs6RkHQw9pBOfz0O+qf0x9PmdKkpiGvJgSel fitrlMz+GMYTJtRNGikVQdNuFIUzhVKXLKma7X0s= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Biggers , Herbert Xu Subject: [PATCH 5.10 04/37] crypto: lib - remove unneeded selection of XOR_BLOCKS Date: Fri, 2 Sep 2022 14:19:26 +0200 Message-Id: <20220902121359.309458684@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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 Biggers commit 874b301985ef2f89b8b592ad255e03fb6fbfe605 upstream. CRYPTO_LIB_CHACHA_GENERIC doesn't need to select XOR_BLOCKS. It perhaps was thought that it's needed for __crypto_xor, but that's not the case. Enabling XOR_BLOCKS is problematic because the XOR_BLOCKS code runs a benchmark when it is initialized. That causes a boot time regression on systems that didn't have it enabled before. Therefore, remove this unnecessary and problematic selection. Fixes: e56e18985596 ("lib/crypto: add prompts back to crypto libraries") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- lib/crypto/Kconfig | 1 - 1 file changed, 1 deletion(-) --- a/lib/crypto/Kconfig +++ b/lib/crypto/Kconfig @@ -33,7 +33,6 @@ config CRYPTO_ARCH_HAVE_LIB_CHACHA =20 config CRYPTO_LIB_CHACHA_GENERIC tristate - select XOR_BLOCKS help This symbol can be depended upon by arch implementations of the ChaCha library interface that require the generic code as a From nobody Fri Apr 10 10:51:46 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 20D9DC38145 for ; Fri, 2 Sep 2022 13:02:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238589AbiIBNB6 (ORCPT ); Fri, 2 Sep 2022 09:01:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50798 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238395AbiIBM7v (ORCPT ); Fri, 2 Sep 2022 08:59:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8BE1FE357; Fri, 2 Sep 2022 05:41:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D1BACB82A94; Fri, 2 Sep 2022 12:40:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2D703C433C1; Fri, 2 Sep 2022 12:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122432; bh=HvJAvfahX2qMcHfJMcbUzlT+p01VbVQuQu0FwetkayU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rgAYcY/nyYZxsvkJWn0YEfoVU1MyFCpZjvaRhC0rAtOTsGUrCMCF4iVwATOE1tfnf ba54n1oGZF0TCY3FB3Z+z/rbic1V2lJaMimrKLTztTdv2RexyYm9Buxxk3wRFr3KFO 8oTy4FZM0VzbygrFWfdVkDOVBqIq2atiBTICPaic= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, David Hildenbrand , Heiko Carstens , Gerald Schaefer , Vasily Gorbik Subject: [PATCH 5.10 05/37] s390/mm: do not trigger write fault when vma does not allow VM_WRITE Date: Fri, 2 Sep 2022 14:19:27 +0200 Message-Id: <20220902121359.338498863@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Gerald Schaefer commit 41ac42f137080bc230b5882e3c88c392ab7f2d32 upstream. For non-protection pXd_none() page faults in do_dat_exception(), we call do_exception() with access =3D=3D (VM_READ | VM_WRITE | VM_EXEC). In do_exception(), vma->vm_flags is checked against that before calling handle_mm_fault(). Since commit 92f842eac7ee3 ("[S390] store indication fault optimization"), we call handle_mm_fault() with FAULT_FLAG_WRITE, when recognizing that it was a write access. However, the vma flags check is still only checking against (VM_READ | VM_WRITE | VM_EXEC), and therefore also calling handle_mm_fault() with FAULT_FLAG_WRITE in cases where the vma does not allow VM_WRITE. Fix this by changing access check in do_exception() to VM_WRITE only, when recognizing write access. Link: https://lkml.kernel.org/r/20220811103435.188481-3-david@redhat.com Fixes: 92f842eac7ee3 ("[S390] store indication fault optimization") Cc: Reported-by: David Hildenbrand Reviewed-by: Heiko Carstens Signed-off-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Gerald Schaefer Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/s390/mm/fault.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/arch/s390/mm/fault.c +++ b/arch/s390/mm/fault.c @@ -429,7 +429,9 @@ static inline vm_fault_t do_exception(st flags =3D FAULT_FLAG_DEFAULT; if (user_mode(regs)) flags |=3D FAULT_FLAG_USER; - if (access =3D=3D VM_WRITE || (trans_exc_code & store_indication) =3D=3D = 0x400) + if ((trans_exc_code & store_indication) =3D=3D 0x400) + access =3D VM_WRITE; + if (access =3D=3D VM_WRITE) flags |=3D FAULT_FLAG_WRITE; mmap_read_lock(mm); From nobody Fri Apr 10 10:51:46 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 08974C54EE9 for ; Fri, 2 Sep 2022 12:57:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238318AbiIBM50 (ORCPT ); Fri, 2 Sep 2022 08:57:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238001AbiIBMyo (ORCPT ); Fri, 2 Sep 2022 08:54:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1BDB2B33; Fri, 2 Sep 2022 05:39:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A2A5A6215D; Fri, 2 Sep 2022 12:38:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2311C433C1; Fri, 2 Sep 2022 12:38:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122333; bh=BCPPt0LOctTxI2SeC9BJPqci9jzrGee47gQKv2P6LsI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S+JPoxsFnksEkX0THWA3YPOOcGMS6BhWSZoEAm2HA0Qraal0RBkifuh6wMh4lmHx9 Fbx8jXoLcHC8vTdtIAt42yXBaSohiuoMsMz9vz+J2z0QFOvwcnbO5RhBzM0k+0LQoM l3/ELnSw5zaFWe9u8s3NmP+i9o81lPr37HUPV2qk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jing Leng , Masahiro Yamada , Nicolas Schier Subject: [PATCH 5.10 06/37] kbuild: Fix include path in scripts/Makefile.modpost Date: Fri, 2 Sep 2022 14:19:28 +0200 Message-Id: <20220902121359.376467893@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Jing Leng commit 23a0cb8e3225122496bfa79172005c587c2d64bf upstream. When building an external module, if users don't need to separate the compilation output and source code, they run the following command: "make -C $(LINUX_SRC_DIR) M=3D$(PWD)". At this point, "$(KBUILD_EXTMOD)" and "$(src)" are the same. If they need to separate them, they run "make -C $(KERNEL_SRC_DIR) O=3D$(KERNEL_OUT_DIR) M=3D$(OUT_DIR) src=3D$(PWD)". Before running the command, they need to copy "Kbuild" or "Makefile" to "$(OUT_DIR)" to prevent compilation failure. So the kernel should change the included path to avoid the copy operation. Signed-off-by: Jing Leng [masahiro: I do not think "M=3D$(OUT_DIR) src=3D$(PWD)" is the official way, but this patch is a nice clean up anyway.] Signed-off-by: Masahiro Yamada Signed-off-by: Nicolas Schier Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- scripts/Makefile.modpost | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/scripts/Makefile.modpost +++ b/scripts/Makefile.modpost @@ -87,8 +87,7 @@ obj :=3D $(KBUILD_EXTMOD) src :=3D $(obj) =20 # Include the module's Makefile to find KBUILD_EXTRA_SYMBOLS -include $(if $(wildcard $(KBUILD_EXTMOD)/Kbuild), \ - $(KBUILD_EXTMOD)/Kbuild, $(KBUILD_EXTMOD)/Makefile) +include $(if $(wildcard $(src)/Kbuild), $(src)/Kbuild, $(src)/Makefile) =20 # modpost option for external modules MODPOST +=3D -e From nobody Fri Apr 10 10:51:46 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 5D590ECAAD5 for ; Fri, 2 Sep 2022 13:12:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238738AbiIBNMC (ORCPT ); Fri, 2 Sep 2022 09:12:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54486 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238790AbiIBNLk (ORCPT ); Fri, 2 Sep 2022 09:11:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9190F3ECD1; Fri, 2 Sep 2022 05:48:57 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B237C620DF; Fri, 2 Sep 2022 12:39:27 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C05ADC433C1; Fri, 2 Sep 2022 12:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122367; bh=m9vXiS0wVCsyjRG1863RIyfzqmzDF4v8y0kU38y9bBc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=omKcVDKF7+g1EvOjlInbwvwM004hauvnibjA7t7MhMEkELDWGGHcJbXxvAHkes78e L/qjOJTNdhyNPoN+3hYOdIoWJ2XJaOoFkhHkOIsi3W8opuSDuLqvlpOWRICd9vjqns pD/aRehQ5hNu5sUTnOAW6cqbxpBp16452azOdG9g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Luiz Augusto von Dentz , Sudip Mukherjee Subject: [PATCH 5.10 07/37] Bluetooth: L2CAP: Fix build errors in some archs Date: Fri, 2 Sep 2022 14:19:29 +0200 Message-Id: <20220902121359.409183770@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Luiz Augusto von Dentz commit b840304fb46cdf7012722f456bce06f151b3e81b upstream. This attempts to fix the follow errors: In function 'memcmp', inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9, inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2003:15: ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=3Dstringop-overread] 44 | #define __underlying_memcmp __builtin_memcmp | ^ ./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp' 420 | return __underlying_memcmp(p, q, size); | ^~~~~~~~~~~~~~~~~~~ In function 'memcmp', inlined from 'bacmp' at ./include/net/bluetooth/bluetooth.h:347:9, inlined from 'l2cap_global_chan_by_psm' at net/bluetooth/l2cap_core.c:2004:15: ./include/linux/fortify-string.h:44:33: error: '__builtin_memcmp' specified bound 6 exceeds source size 0 [-Werror=3Dstringop-overread] 44 | #define __underlying_memcmp __builtin_memcmp | ^ ./include/linux/fortify-string.h:420:16: note: in expansion of macro '__underlying_memcmp' 420 | return __underlying_memcmp(p, q, size); | ^~~~~~~~~~~~~~~~~~~ Fixes: 332f1795ca20 ("Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm regres= sion") Signed-off-by: Luiz Augusto von Dentz Cc: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/bluetooth/l2cap_core.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -1988,11 +1988,11 @@ static struct l2cap_chan *l2cap_global_c src_match =3D !bacmp(&c->src, src); dst_match =3D !bacmp(&c->dst, dst); if (src_match && dst_match) { - c =3D l2cap_chan_hold_unless_zero(c); - if (c) { - read_unlock(&chan_list_lock); - return c; - } + if (!l2cap_chan_hold_unless_zero(c)) + continue; + + read_unlock(&chan_list_lock); + return c; } =20 /* Closest match */ From nobody Fri Apr 10 10:51:46 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 C9663ECAAD5 for ; Fri, 2 Sep 2022 13:01:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238443AbiIBNBI (ORCPT ); Fri, 2 Sep 2022 09:01:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51722 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238704AbiIBM7W (ORCPT ); Fri, 2 Sep 2022 08:59:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A842C3AE4B; Fri, 2 Sep 2022 05:40:53 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BD381B829E5; Fri, 2 Sep 2022 12:40:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA5FBC433D6; Fri, 2 Sep 2022 12:40:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122401; bh=2mE2jwlzv5qeiHp5VD8bwbMz3PgUEayrX1/dxiB2RAo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=If7ApqSgGfBVurx12uHdtdH0ljx1Kzx71rW3LLtxtL0aSBpNg3c5CRcOYCWX9UMPd ghHo1H81oJx2KeGNrob0M7OdP6DoM2cLIOKtBLSA/AHBbql1bKwvZkONGFU5SshJcW /cL8AhqmYdoysckshYrh4RQaOU75Wq9fYtddyTek= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Ben Greear , Stefan Roese , Bjorn Helgaas , =?UTF-8?q?Pali=20Roh=C3=A1r?= , "Rafael J. Wysocki" , Bharat Kumar Gogada , Michal Simek , Yao Hongbo , Naveen Naidu , Sasha Levin Subject: [PATCH 5.10 08/37] Revert "PCI/portdrv: Dont disable AER reporting in get_port_device_capability()" Date: Fri, 2 Sep 2022 14:19:30 +0200 Message-Id: <20220902121359.438662311@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Greg Kroah-Hartman This reverts commit ee70aa214a2d9fa74539b52f6c326ba2f7c0fb11 which is commit 8795e182b02dc87e343c79e73af6b8b7f9c5e635 upstream. It is reported to cause problems, so drop it from the stable trees for now until it gets sorted out. Link: https://lore.kernel.org/r/47b775c5-57fa-5edf-b59e-8a9041ffbee7@candel= atech.com Reported-by: Ben Greear Cc: Stefan Roese Cc: Bjorn Helgaas Cc: Pali Roh=C3=A1r Cc: Rafael J. Wysocki Cc: Bharat Kumar Gogada Cc: Michal Simek Cc: Yao Hongbo Cc: Naveen Naidu Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/pci/pcie/portdrv_core.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/drivers/pci/pcie/portdrv_core.c +++ b/drivers/pci/pcie/portdrv_core.c @@ -222,8 +222,15 @@ static int get_port_device_capability(st =20 #ifdef CONFIG_PCIEAER if (dev->aer_cap && pci_aer_available() && - (pcie_ports_native || host->native_aer)) + (pcie_ports_native || host->native_aer)) { services |=3D PCIE_PORT_SERVICE_AER; + + /* + * Disable AER on this port in case it's been enabled by the + * BIOS (the AER service driver will enable it when necessary). + */ + pci_disable_pcie_error_reporting(dev); + } #endif =20 /* From nobody Fri Apr 10 10:51:46 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 D484BC54EE9 for ; Fri, 2 Sep 2022 13:01:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238511AbiIBNBk (ORCPT ); Fri, 2 Sep 2022 09:01:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238160AbiIBM7d (ORCPT ); Fri, 2 Sep 2022 08:59:33 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67977FC334; Fri, 2 Sep 2022 05:40:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 26D9FB81CCF; Fri, 2 Sep 2022 12:40:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F628C433D6; Fri, 2 Sep 2022 12:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122413; bh=Bs2CQBsnUjpIZ+XxHHFSiRhfkB928kkGSKMck2e8gws=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LnAewgnh+LU+Enum7LXvsBmyitv+NlN2hAcGPkEU14ASBKyR8vs4it6gBxq3NZCjN hK4ewyApmhGCisUn1ZdgF/MeFES8wLJW6jgjK11AwDsnWh2EnzynVfwCtNVg81k9Jg 3Z1m6CQBUXO4ESff0At5kT0jc5Ww2qW2aJzWezDc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiri Kosina , Benjamin Tissoires , linux-input@vger.kernel.org, Lee Jones , Jiri Kosina Subject: [PATCH 5.10 09/37] HID: steam: Prevent NULL pointer dereference in steam_{recv,send}_report Date: Fri, 2 Sep 2022 14:19:31 +0200 Message-Id: <20220902121359.467033047@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Lee Jones commit cd11d1a6114bd4bc6450ae59f6e110ec47362126 upstream. It is possible for a malicious device to forgo submitting a Feature Report. The HID Steam driver presently makes no prevision for this and de-references the 'struct hid_report' pointer obtained from the HID devices without first checking its validity. Let's change that. Cc: Jiri Kosina Cc: Benjamin Tissoires Cc: linux-input@vger.kernel.org Fixes: c164d6abf3841 ("HID: add driver for Valve Steam Controller") Signed-off-by: Lee Jones Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hid/hid-steam.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/hid/hid-steam.c +++ b/drivers/hid/hid-steam.c @@ -134,6 +134,11 @@ static int steam_recv_report(struct stea int ret; =20 r =3D steam->hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[0]; + if (!r) { + hid_err(steam->hdev, "No HID_FEATURE_REPORT submitted - nothing to read= \n"); + return -EINVAL; + } + if (hid_report_len(r) < 64) return -EINVAL; =20 @@ -165,6 +170,11 @@ static int steam_send_report(struct stea int ret; =20 r =3D steam->hdev->report_enum[HID_FEATURE_REPORT].report_id_hash[0]; + if (!r) { + hid_err(steam->hdev, "No HID_FEATURE_REPORT submitted - nothing to read= \n"); + return -EINVAL; + } + if (hid_report_len(r) < 64) return -EINVAL; From nobody Fri Apr 10 10:51:46 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 9D3DDECAAD5 for ; Fri, 2 Sep 2022 13:02:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238623AbiIBNCS (ORCPT ); Fri, 2 Sep 2022 09:02:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238478AbiIBNAU (ORCPT ); Fri, 2 Sep 2022 09:00:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 66416FC33E; Fri, 2 Sep 2022 05:41:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3B131B82AE2; Fri, 2 Sep 2022 12:40:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7980EC433C1; Fri, 2 Sep 2022 12:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122417; bh=SGi+1RnrP8fPAFe7dJvXJ1AlUmwFWSRiimkwKEE5VSA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HdneWD+ijrP7PIxXd6zgHi9mJp8FNLFJ8cXWOaknJ/sHIR2BkClW1M+qDGZJebUv9 +yZ2+W9arpm5kOI7yYEU9/ZHNCrI74E2ItdeiM81RMVDIGue0ZA23/Biqx/XTgJeHd NJM0oX5ZEEObI/q17nkmY7yf74enGbt0sUPacHbI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com, Gerd Hoffmann , Vivek Kasireddy Subject: [PATCH 5.10 10/37] udmabuf: Set the DMA mask for the udmabuf device (v2) Date: Fri, 2 Sep 2022 14:19:32 +0200 Message-Id: <20220902121359.496209507@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Vivek Kasireddy commit 9e9fa6a9198b767b00f48160800128e83a038f9f upstream. If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com Cc: Gerd Hoffmann Signed-off-by: Vivek Kasireddy Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1= -vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -327,7 +327,23 @@ static struct miscdevice udmabuf_misc =3D =20 static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret =3D misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret =3D dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } =20 static void __exit udmabuf_dev_exit(void) From nobody Fri Apr 10 10:51:46 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 7FFB0C54EE9 for ; Fri, 2 Sep 2022 13:04:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238421AbiIBNEo (ORCPT ); Fri, 2 Sep 2022 09:04:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238369AbiIBNDH (ORCPT ); Fri, 2 Sep 2022 09:03:07 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABB041090B4; Fri, 2 Sep 2022 05:41:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 93C19621EF; Fri, 2 Sep 2022 12:40:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88F46C433C1; Fri, 2 Sep 2022 12:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122420; bh=xIwGVScQaB9wNQuwUy6UEhNULReYG68Iz9QNMVFlI5Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GVsKqBsjMooRinMJvX/Jf/HVpKcRnlxx2bsWlu8ma0WlM0I8pFHoPxouOOF5wlQDo NK2HJSmg+IVr4lG5NBi7q3bA6cqxkBkePKpL4oQslE/4f7yvIp6y81SGUDOLE9YpLU LUjK/9k2Y6+TNyT2gk8OeB9gSoXSnYYV/Pw6PH1Q= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+77b432d57c4791183ed4@syzkaller.appspotmail.com, Dongliang Mu , Hans Verkuil , Mauro Carvalho Chehab Subject: [PATCH 5.10 11/37] media: pvrusb2: fix memory leak in pvr_probe Date: Fri, 2 Sep 2022 14:19:33 +0200 Message-Id: <20220902121359.524649515@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Dongliang Mu commit 945a9a8e448b65bec055d37eba58f711b39f66f0 upstream. The error handling code in pvr2_hdw_create forgets to unregister the v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create, it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL, which leads to that pvr2_hdw_destroy directly returns. Fix this by adding v4l2_device_unregister to decrease the refcount of usb interface. Reported-by: syzbot+77b432d57c4791183ed4@syzkaller.appspotmail.com Signed-off-by: Dongliang Mu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/media/usb/pvrusb2/pvrusb2-hdw.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/media/usb/pvrusb2/pvrusb2-hdw.c +++ b/drivers/media/usb/pvrusb2/pvrusb2-hdw.c @@ -2610,6 +2610,7 @@ struct pvr2_hdw *pvr2_hdw_create(struct del_timer_sync(&hdw->encoder_run_timer); del_timer_sync(&hdw->encoder_wait_timer); flush_work(&hdw->workpoll); + v4l2_device_unregister(&hdw->v4l2_dev); usb_free_urb(hdw->ctl_read_urb); usb_free_urb(hdw->ctl_write_urb); kfree(hdw->ctl_read_buffer); From nobody Fri Apr 10 10:51:46 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 03116ECAAD5 for ; Fri, 2 Sep 2022 13:03:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238673AbiIBND2 (ORCPT ); Fri, 2 Sep 2022 09:03:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238599AbiIBNCu (ORCPT ); Fri, 2 Sep 2022 09:02:50 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC41910F085; Fri, 2 Sep 2022 05:41:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A547E62190; Fri, 2 Sep 2022 12:40:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD67DC433B5; Fri, 2 Sep 2022 12:40:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122423; bh=r1vX3nIzj0NgU00yTqlhOhNlBWhKxamxJjekSzxyAww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y0BnTpaRgaq1tjvTIZMu4NTvqqK6Kb3R6h1X/Eh926BrlfWB0em+u9BNjbJ5GrXIb CMfCA5zn4yHkxGwwNAypmXMEQx4IackR7wef+e9WfwFtnCbcDCwUtLzCeD2kixrOMg bpl7ooTJq0FaPwTKSlu1XwwTsOx1P8R1wITg9Yh8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com, Karthik Alapati , Jiri Kosina Subject: [PATCH 5.10 12/37] HID: hidraw: fix memory leak in hidraw_release() Date: Fri, 2 Sep 2022 14:19:34 +0200 Message-Id: <20220902121359.551771738@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Karthik Alapati commit a5623a203cffe2d2b84d2f6c989d9017db1856af upstream. Free the buffered reports before deleting the list entry. BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmemdup+0x23/0x50 mm/util.c:128 [] kmemdup include/linux/fortify-string.h:440 [inline] [] hidraw_report_event+0xa2/0x150 drivers/hid/hidraw.= c:521 [] hid_report_raw_event+0x27d/0x740 drivers/hid/hid-c= ore.c:1992 [] hid_input_report+0x1ae/0x270 drivers/hid/hid-core.= c:2065 [] hid_irq_in+0x1ff/0x250 drivers/hid/usbhid/hid-core= .c:284 [] __usb_hcd_giveback_urb+0xf9/0x230 drivers/usb/core= /hcd.c:1670 [] usb_hcd_giveback_urb+0x1b6/0x1d0 drivers/usb/core/= hcd.c:1747 [] dummy_timer+0x8e4/0x14c0 drivers/usb/gadget/udc/du= mmy_hcd.c:1988 [] call_timer_fn+0x38/0x200 kernel/time/timer.c:1474 [] expire_timers kernel/time/timer.c:1519 [inline] [] __run_timers.part.0+0x316/0x430 kernel/time/timer.= c:1790 [] __run_timers kernel/time/timer.c:1768 [inline] [] run_timer_softirq+0x44/0x90 kernel/time/timer.c:18= 03 [] __do_softirq+0xe6/0x2ea kernel/softirq.c:571 [] invoke_softirq kernel/softirq.c:445 [inline] [] __irq_exit_rcu kernel/softirq.c:650 [inline] [] irq_exit_rcu+0xc0/0x110 kernel/softirq.c:662 [] sysvec_apic_timer_interrupt+0xa2/0xd0 arch/x86/ker= nel/apic/apic.c:1106 [] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86= /include/asm/idtentry.h:649 [] native_safe_halt arch/x86/include/asm/irqflags.h:5= 1 [inline] [] arch_safe_halt arch/x86/include/asm/irqflags.h:89 = [inline] [] acpi_safe_halt drivers/acpi/processor_idle.c:111 [= inline] [] acpi_idle_do_entry+0xc0/0xd0 drivers/acpi/processo= r_idle.c:554 Link: https://syzkaller.appspot.com/bug?id=3D19a04b43c75ed1092021010419b5e5= 60a8172c4f Reported-by: syzbot+f59100a0428e6ded9443@syzkaller.appspotmail.com Signed-off-by: Karthik Alapati Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/hid/hidraw.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/hid/hidraw.c +++ b/drivers/hid/hidraw.c @@ -346,10 +346,13 @@ static int hidraw_release(struct inode * unsigned int minor =3D iminor(inode); struct hidraw_list *list =3D file->private_data; unsigned long flags; + int i; =20 mutex_lock(&minors_lock); =20 spin_lock_irqsave(&hidraw_table[minor]->list_lock, flags); + for (i =3D list->tail; i < list->head; i++) + kfree(list->buffer[i].value); list_del(&list->node); spin_unlock_irqrestore(&hidraw_table[minor]->list_lock, flags); kfree(list); From nobody Fri Apr 10 10:51:46 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 AFF7EC54EE9 for ; Fri, 2 Sep 2022 13:14:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236550AbiIBNN6 (ORCPT ); Fri, 2 Sep 2022 09:13:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36410 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238560AbiIBNNN (ORCPT ); Fri, 2 Sep 2022 09:13:13 -0400 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3829A98CBB; Fri, 2 Sep 2022 05:50:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id A76D2CE2E6C; Fri, 2 Sep 2022 12:40:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE09DC433C1; Fri, 2 Sep 2022 12:40:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122426; bh=5I5WgbFR00KcFPgxXOaC3z7i3XsVwy5EdHXJcG36H14=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=0gGWY16J7zQDvbbNDGz/bP3+ay63C4pqEbY3khHgBshJhR1MkeSM3WL+mCvVTBFFN XGGyrKxiS9YaE21FwH4Iin7iAX2B38D05BfxPKUY76Y76RHjQQ8bBAKyNaAFhr24v/ Gsa6Kfvve6b6jXRtfUIX8SyX6AXBp6YVI4LEoP2k= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jakub Kicinski , Wen Gu , Hawkins Jiawei , Jakub Sitnicki , syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.com Subject: [PATCH 5.10 13/37] net: fix refcount bug in sk_psock_get (2) Date: Fri, 2 Sep 2022 14:19:35 +0200 Message-Id: <20220902121359.580930358@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Hawkins Jiawei commit 2a0133723f9ebeb751cfce19f74ec07e108bef1f upstream. Syzkaller reports refcount bug as follows: Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee ------------[ cut here ]------------ refcount_t: saturated; leaking memory. WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/= 0x1e0 lib/refcount.c:19 Modules linked in: CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g= 7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 During SMC fallback process in connect syscall, kernel will replaces TCP with SMC. In order to forward wakeup smc socket waitqueue after fallback, kernel will sets clcsk->sk_user_data to origin smc socket in smc_fback_replace_callbacks(). Later, in shutdown syscall, kernel will calls sk_psock_get(), which treats the clcsk->sk_user_data as psock type, triggering the refcnt warning. So, the root cause is that smc and psock, both will use sk_user_data field. So they will mismatch this field easily. This patch solves it by using another bit(defined as SK_USER_DATA_PSOCK) in PTRMASK, to mark whether sk_user_data points to a psock object or not. This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e ("net, sk_msg: Clear sk_user_data pointer on clone if tagged"). For there will possibly be more flags in the sk_user_data field, this patch also refactor sk_user_data flags code to be more generic to improve its maintainability. Reported-and-tested-by: syzbot+5f26f85569bd179c18ce@syzkaller.appspotmail.c= om Suggested-by: Jakub Kicinski Acked-by: Wen Gu Signed-off-by: Hawkins Jiawei Reviewed-by: Jakub Sitnicki Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman --- include/linux/skmsg.h | 3 +- include/net/sock.h | 68 +++++++++++++++++++++++++++++++++++----------= ----- net/core/skmsg.c | 4 ++ 3 files changed, 53 insertions(+), 22 deletions(-) --- a/include/linux/skmsg.h +++ b/include/linux/skmsg.h @@ -281,7 +281,8 @@ static inline void sk_msg_sg_copy_clear( =20 static inline struct sk_psock *sk_psock(const struct sock *sk) { - return rcu_dereference_sk_user_data(sk); + return __rcu_dereference_sk_user_data_with_flags(sk, + SK_USER_DATA_PSOCK); } =20 static inline void sk_psock_queue_msg(struct sk_psock *psock, --- a/include/net/sock.h +++ b/include/net/sock.h @@ -527,14 +527,26 @@ enum sk_pacing { SK_PACING_FQ =3D 2, }; =20 -/* Pointer stored in sk_user_data might not be suitable for copying - * when cloning the socket. For instance, it can point to a reference - * counted object. sk_user_data bottom bit is set if pointer must not - * be copied. +/* flag bits in sk_user_data + * + * - SK_USER_DATA_NOCOPY: Pointer stored in sk_user_data might + * not be suitable for copying when cloning the socket. For instance, + * it can point to a reference counted object. sk_user_data bottom + * bit is set if pointer must not be copied. + * + * - SK_USER_DATA_BPF: Mark whether sk_user_data field is + * managed/owned by a BPF reuseport array. This bit should be set + * when sk_user_data's sk is added to the bpf's reuseport_array. + * + * - SK_USER_DATA_PSOCK: Mark whether pointer stored in + * sk_user_data points to psock type. This bit should be set + * when sk_user_data is assigned to a psock object. */ #define SK_USER_DATA_NOCOPY 1UL -#define SK_USER_DATA_BPF 2UL /* Managed by BPF */ -#define SK_USER_DATA_PTRMASK ~(SK_USER_DATA_NOCOPY | SK_USER_DATA_BPF) +#define SK_USER_DATA_BPF 2UL +#define SK_USER_DATA_PSOCK 4UL +#define SK_USER_DATA_PTRMASK ~(SK_USER_DATA_NOCOPY | SK_USER_DATA_BPF |\ + SK_USER_DATA_PSOCK) =20 /** * sk_user_data_is_nocopy - Test if sk_user_data pointer must not be copied @@ -547,24 +559,40 @@ static inline bool sk_user_data_is_nocop =20 #define __sk_user_data(sk) ((*((void __rcu **)&(sk)->sk_user_data))) =20 +/** + * __rcu_dereference_sk_user_data_with_flags - return the pointer + * only if argument flags all has been set in sk_user_data. Otherwise + * return NULL + * + * @sk: socket + * @flags: flag bits + */ +static inline void * +__rcu_dereference_sk_user_data_with_flags(const struct sock *sk, + uintptr_t flags) +{ + uintptr_t sk_user_data =3D (uintptr_t)rcu_dereference(__sk_user_data(sk)); + + WARN_ON_ONCE(flags & SK_USER_DATA_PTRMASK); + + if ((sk_user_data & flags) =3D=3D flags) + return (void *)(sk_user_data & SK_USER_DATA_PTRMASK); + return NULL; +} + #define rcu_dereference_sk_user_data(sk) \ + __rcu_dereference_sk_user_data_with_flags(sk, 0) +#define __rcu_assign_sk_user_data_with_flags(sk, ptr, flags) \ ({ \ - void *__tmp =3D rcu_dereference(__sk_user_data((sk))); \ - (void *)((uintptr_t)__tmp & SK_USER_DATA_PTRMASK); \ -}) -#define rcu_assign_sk_user_data(sk, ptr) \ -({ \ - uintptr_t __tmp =3D (uintptr_t)(ptr); \ - WARN_ON_ONCE(__tmp & ~SK_USER_DATA_PTRMASK); \ - rcu_assign_pointer(__sk_user_data((sk)), __tmp); \ -}) -#define rcu_assign_sk_user_data_nocopy(sk, ptr) \ -({ \ - uintptr_t __tmp =3D (uintptr_t)(ptr); \ - WARN_ON_ONCE(__tmp & ~SK_USER_DATA_PTRMASK); \ + uintptr_t __tmp1 =3D (uintptr_t)(ptr), \ + __tmp2 =3D (uintptr_t)(flags); \ + WARN_ON_ONCE(__tmp1 & ~SK_USER_DATA_PTRMASK); \ + WARN_ON_ONCE(__tmp2 & SK_USER_DATA_PTRMASK); \ rcu_assign_pointer(__sk_user_data((sk)), \ - __tmp | SK_USER_DATA_NOCOPY); \ + __tmp1 | __tmp2); \ }) +#define rcu_assign_sk_user_data(sk, ptr) \ + __rcu_assign_sk_user_data_with_flags(sk, ptr, 0) =20 /* * SK_CAN_REUSE and SK_NO_REUSE on a socket mean that the socket is OK --- a/net/core/skmsg.c +++ b/net/core/skmsg.c @@ -612,7 +612,9 @@ struct sk_psock *sk_psock_init(struct so sk_psock_set_state(psock, SK_PSOCK_TX_ENABLED); refcount_set(&psock->refcnt, 1); =20 - rcu_assign_sk_user_data_nocopy(sk, psock); + __rcu_assign_sk_user_data_with_flags(sk, psock, + SK_USER_DATA_NOCOPY | + SK_USER_DATA_PSOCK); sock_hold(sk); =20 out: From nobody Fri Apr 10 10:51:46 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 EC43FECAAD5 for ; Fri, 2 Sep 2022 13:02:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238630AbiIBNCW (ORCPT ); Fri, 2 Sep 2022 09:02:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238532AbiIBNAh (ORCPT ); Fri, 2 Sep 2022 09:00:37 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 84402E833C; Fri, 2 Sep 2022 05:41:04 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 86A76B82A99; Fri, 2 Sep 2022 12:40:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9CD5C433D7; Fri, 2 Sep 2022 12:40:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122429; bh=4xJJOHqLzP7spsbVN3XdLsPg6PaX12EVx7PC1XKrqDs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mzejSoSoLvQ8Pg5L+PbiR89fQcLrTv0OOM78iudqg+FobLZqXriZCQlugtw/HxGos 3FnfhuWYFq6CGHsQyTsHyhTpR5FacN962Qt0DTQA/1roxOq60nYbGya9WE+uLLD5Od /KBvqsWL94glaakksTjbqWxSD3L8tVf3E3h4e+uU= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Zheyu Ma , Letu Ren , Helge Deller Subject: [PATCH 5.10 14/37] fbdev: fb_pm2fb: Avoid potential divide by zero error Date: Fri, 2 Sep 2022 14:19:36 +0200 Message-Id: <20220902121359.612473653@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Letu Ren commit 19f953e7435644b81332dd632ba1b2d80b1e37af upstream. In `do_fb_ioctl()` of fbmem.c, if cmd is FBIOPUT_VSCREENINFO, var will be copied from user, then go through `fb_set_var()` and `info->fbops->fb_check_var()` which could may be `pm2fb_check_var()`. Along the path, `var->pixclock` won't be modified. This function checks whether reciprocal of `var->pixclock` is too high. If `var->pixclock` is zero, there will be a divide by zero error. So, it is necessary to check whether denominator is zero to avoid crash. As this bug is found by Syzkaller, logs are listed below. divide error in pm2fb_check_var Call Trace: fb_set_var+0x367/0xeb0 drivers/video/fbdev/core/fbmem.c:1015 do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110 fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189 Reported-by: Zheyu Ma Signed-off-by: Letu Ren Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/video/fbdev/pm2fb.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/video/fbdev/pm2fb.c +++ b/drivers/video/fbdev/pm2fb.c @@ -616,6 +616,11 @@ static int pm2fb_check_var(struct fb_var return -EINVAL; } =20 + if (!var->pixclock) { + DPRINTK("pixclock is zero\n"); + return -EINVAL; + } + if (PICOS2KHZ(var->pixclock) > PM2_MAX_PIXCLOCK) { DPRINTK("pixclock too high (%ldKHz)\n", PICOS2KHZ(var->pixclock)); From nobody Fri Apr 10 10:51:46 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 4266DECAAD5 for ; Fri, 2 Sep 2022 12:57:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238336AbiIBM5c (ORCPT ); Fri, 2 Sep 2022 08:57:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238114AbiIBMzF (ORCPT ); Fri, 2 Sep 2022 08:55:05 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEE88FB0F7; Fri, 2 Sep 2022 05:39:06 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CCBF5620DF; Fri, 2 Sep 2022 12:38:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C214AC433C1; Fri, 2 Sep 2022 12:38:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122336; bh=faLChOxeieXjbyD01+wjrgInYc6RGJlhVeKWx//i6UA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d9yxkV79ruKYmf5arv3pdQH6jymdK5/ooWJ6cqb/Qd3FobRPAR4tSTa+shXn31CUz MMecebleFv32LiPn2qD1/foOs4r+i7vts6xkcHWfSqmEefdM2y0VnaGt+bFJvgUfsZ RqTGOHFQiSeivg/4FaJ8b/1zZ7SLCC9G7+/GfNNI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Steven Rostedt , Yang Jihong Subject: [PATCH 5.10 15/37] ftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead Date: Fri, 2 Sep 2022 14:19:37 +0200 Message-Id: <20220902121359.645097230@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Yang Jihong commit c3b0f72e805f0801f05fa2aa52011c4bfc694c44 upstream. ftrace_startup does not remove ops from ftrace_ops_list when ftrace_startup_enable fails: register_ftrace_function ftrace_startup __register_ftrace_function ... add_ftrace_ops(&ftrace_ops_list, ops) ... ... ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is= set to 1 ... return 0 // ops is in the ftrace_ops_list. When ftrace_disabled =3D 1, unregister_ftrace_function simply returns witho= ut doing anything: unregister_ftrace_function ftrace_shutdown if (unlikely(ftrace_disabled)) return -ENODEV; // return here, __unregister_ftrace_function i= s not executed, // as a result, ops is still in the ftrace_ops= _list __unregister_ftrace_function ... If ops is dynamically allocated, it will be free later, in this case, is_ftrace_trampoline accesses NULL pointer: is_ftrace_trampoline ftrace_ops_trampoline do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL! Syzkaller reports as follows: [ 1203.506103] BUG: kernel NULL pointer dereference, address: 0000000000000= 10b [ 1203.508039] #PF: supervisor read access in kernel mode [ 1203.508798] #PF: error_code(0x0000) - not-present page [ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0 [ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI [ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G B W = 5.10.0 #8 [ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS = rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0 [ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff = 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48= > 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00 [ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246 [ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a3= 31866 [ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000= 0010b [ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df= 18b07 [ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 00000000004= 78399 [ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 00000000000= 00008 [ 1203.525634] FS: 00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:= 0000000000000000 [ 1203.526801] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003= 706e0 [ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000= 00400 Therefore, when ftrace_startup_enable fails, we need to rollback registrati= on process and remove ops from ftrace_ops_list. Link: https://lkml.kernel.org/r/20220818032659.56209-1-yangjihong1@huawei.c= om Suggested-by: Steven Rostedt Signed-off-by: Yang Jihong 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: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/trace/ftrace.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -2899,6 +2899,16 @@ int ftrace_startup(struct ftrace_ops *op =20 ftrace_startup_enable(command); =20 + /* + * If ftrace is in an undefined state, we just remove ops from list + * to prevent the NULL pointer, instead of totally rolling it back and + * free trampoline, because those actions could cause further damage. + */ + if (unlikely(ftrace_disabled)) { + __unregister_ftrace_function(ops); + return -ENODEV; + } + ops->flags &=3D ~FTRACE_OPS_FL_ADDING; =20 return 0; From nobody Fri Apr 10 10:51:46 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 0C706ECAAD5 for ; Fri, 2 Sep 2022 14:34:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236809AbiIBOdi (ORCPT ); Fri, 2 Sep 2022 10:33:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38932 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237072AbiIBOav (ORCPT ); Fri, 2 Sep 2022 10:30:51 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96392201A4; Fri, 2 Sep 2022 06:55:19 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 74FA4B82AAC; Fri, 2 Sep 2022 12:39:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9DEEC433D6; Fri, 2 Sep 2022 12:38:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122339; bh=grrOAlYIZGyqwrMbbVHIL1tatlu+W0H81mTS44QmifQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x4j+pr9lj3Yfi8s83ixAKCgJNvqnhYeBJYPxRivY8nzH7NVYonq16nv78Zn5pe+hc fZf2jyH96iy9GuNZFA593plCxMf5dWiJyXh6TviValFNr+7agDIPgl/ZWUCLuwFrhr J6nUrRgcCmA/dW/Wd5HBfYzosdQ8/dJZDB38u+Bw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com, Zhengchao Shao , Stanislav Fomichev , Alexei Starovoitov Subject: [PATCH 5.10 16/37] bpf: Dont redirect packets with invalid pkt_len Date: Fri, 2 Sep 2022 14:19:38 +0200 Message-Id: <20220902121359.686245488@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Zhengchao Shao commit fd1894224407c484f652ad456e1ce423e89bb3eb upstream. Syzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout any skbs, that is, the flow->head is null. The root cause, as the [2] says, is because that bpf_prog_test_run_skb() run a bpf prog which redirects empty skbs. So we should determine whether the length of the packet modified by bpf prog or others like bpf_prog_test is valid before forwarding it directly. LINK: [1] https://syzkaller.appspot.com/bug?id=3D0b84da80c2917757915afa89f7= 738a9d16ec96c5 LINK: [2] https://www.spinics.net/lists/netdev/msg777503.html Reported-by: syzbot+7a12909485b94426aceb@syzkaller.appspotmail.com Signed-off-by: Zhengchao Shao Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20220715115559.139691-1-shaozhengchao@huawe= i.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/skbuff.h | 8 ++++++++ net/bpf/test_run.c | 3 +++ net/core/dev.c | 1 + 3 files changed, 12 insertions(+) --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -2222,6 +2222,14 @@ static inline void skb_set_tail_pointer( =20 #endif /* NET_SKBUFF_DATA_USES_OFFSET */ =20 +static inline void skb_assert_len(struct sk_buff *skb) +{ +#ifdef CONFIG_DEBUG_NET + if (WARN_ONCE(!skb->len, "%s\n", __func__)) + DO_ONCE_LITE(skb_dump, KERN_ERR, skb, false); +#endif /* CONFIG_DEBUG_NET */ +} + /* * Add data to an sk_buff */ --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -441,6 +441,9 @@ static int convert___skb_to_skb(struct s { struct qdisc_skb_cb *cb =3D (struct qdisc_skb_cb *)skb->cb; =20 + if (!skb->len) + return -EINVAL; + if (!__skb) return 0; =20 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -4097,6 +4097,7 @@ static int __dev_queue_xmit(struct sk_bu bool again =3D false; =20 skb_reset_mac_header(skb); + skb_assert_len(skb); =20 if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_SCHED_TSTAMP)) __skb_tstamp_tx(skb, NULL, skb->sk, SCM_TSTAMP_SCHED); From nobody Fri Apr 10 10:51:46 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 51499C54EE9 for ; Fri, 2 Sep 2022 13:00:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238392AbiIBNA5 (ORCPT ); Fri, 2 Sep 2022 09:00:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238664AbiIBM7Q (ORCPT ); Fri, 2 Sep 2022 08:59:16 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDE01D345D; Fri, 2 Sep 2022 05:40:39 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F02156211D; Fri, 2 Sep 2022 12:39:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4CB0C433C1; Fri, 2 Sep 2022 12:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122342; bh=ORU/2/OmjdcfBY6KpJu60URZdtECRnBHqc7OGRlwUpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SoccmGXy+NMSUy/W7NPSv261L4b1+5Rl44jv1RyCKmzQQP+J67CncKUo7cuLl33A5 6o3G9rgn74n7Ml5Y1JEU/Ye1gVJu/wrVBOxMSAmti2FNYpGRr2q2stk9kbjrQ1YqF/ pgjMhrVScH2Ip9yVJOlEGnYWH6RoiUk+Jojr1O1M= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, stable@kernel.org, Michal Hocko , Vlastimil Babka , Jann Horn , Linus Torvalds Subject: [PATCH 5.10 17/37] mm/rmap: Fix anon_vma->degree ambiguity leading to double-reuse Date: Fri, 2 Sep 2022 14:19:39 +0200 Message-Id: <20220902121359.715096766@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Jann Horn commit 2555283eb40df89945557273121e9393ef9b542b upstream. anon_vma->degree tracks the combined number of child anon_vmas and VMAs that use the anon_vma as their ->anon_vma. anon_vma_clone() then assumes that for any anon_vma attached to src->anon_vma_chain other than src->anon_vma, it is impossible for it to be a leaf node of the VMA tree, meaning that for such VMAs ->degree is elevated by 1 because of a child anon_vma, meaning that if ->degree equals 1 there are no VMAs that use the anon_vma as their ->anon_vma. This assumption is wrong because the ->degree optimization leads to leaf nodes being abandoned on anon_vma_clone() - an existing anon_vma is reused and no new parent-child relationship is created. So it is possible to reuse an anon_vma for one VMA while it is still tied to another VMA. This is an issue because is_mergeable_anon_vma() and its callers assume that if two VMAs have the same ->anon_vma, the list of anon_vmas attached to the VMAs is guaranteed to be the same. When this assumption is violated, vma_merge() can merge pages into a VMA that is not attached to the corresponding anon_vma, leading to dangling page->mapping pointers that will be dereferenced during rmap walks. Fix it by separately tracking the number of child anon_vmas and the number of VMAs using the anon_vma as their ->anon_vma. Fixes: 7a3ef208e662 ("mm: prevent endless growth of anon_vma hierarchy") Cc: stable@kernel.org Acked-by: Michal Hocko Acked-by: Vlastimil Babka Signed-off-by: Jann Horn Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- include/linux/rmap.h | 7 +++++-- mm/rmap.c | 29 ++++++++++++++++------------- 2 files changed, 21 insertions(+), 15 deletions(-) --- a/include/linux/rmap.h +++ b/include/linux/rmap.h @@ -39,12 +39,15 @@ struct anon_vma { atomic_t refcount; =20 /* - * Count of child anon_vmas and VMAs which points to this anon_vma. + * Count of child anon_vmas. Equals to the count of all anon_vmas that + * have ->parent pointing to this one, including itself. * * This counter is used for making decision about reusing anon_vma * instead of forking new one. See comments in function anon_vma_clone. */ - unsigned degree; + unsigned long num_children; + /* Count of VMAs whose ->anon_vma pointer points to this object. */ + unsigned long num_active_vmas; =20 struct anon_vma *parent; /* Parent of this anon_vma */ =20 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -89,7 +89,8 @@ static inline struct anon_vma *anon_vma_ anon_vma =3D kmem_cache_alloc(anon_vma_cachep, GFP_KERNEL); if (anon_vma) { atomic_set(&anon_vma->refcount, 1); - anon_vma->degree =3D 1; /* Reference for first vma */ + anon_vma->num_children =3D 0; + anon_vma->num_active_vmas =3D 0; anon_vma->parent =3D anon_vma; /* * Initialise the anon_vma root to point to itself. If called @@ -197,6 +198,7 @@ int __anon_vma_prepare(struct vm_area_st anon_vma =3D anon_vma_alloc(); if (unlikely(!anon_vma)) goto out_enomem_free_avc; + anon_vma->num_children++; /* self-parent link for new root */ allocated =3D anon_vma; } =20 @@ -206,8 +208,7 @@ int __anon_vma_prepare(struct vm_area_st if (likely(!vma->anon_vma)) { vma->anon_vma =3D anon_vma; anon_vma_chain_link(vma, avc, anon_vma); - /* vma reference or self-parent link for new root */ - anon_vma->degree++; + anon_vma->num_active_vmas++; allocated =3D NULL; avc =3D NULL; } @@ -292,19 +293,19 @@ int anon_vma_clone(struct vm_area_struct anon_vma_chain_link(dst, avc, anon_vma); =20 /* - * Reuse existing anon_vma if its degree lower than two, - * that means it has no vma and only one anon_vma child. + * Reuse existing anon_vma if it has no vma and only one + * anon_vma child. * - * Do not chose parent anon_vma, otherwise first child - * will always reuse it. Root anon_vma is never reused: + * Root anon_vma is never reused: * it has self-parent reference and at least one child. */ if (!dst->anon_vma && src->anon_vma && - anon_vma !=3D src->anon_vma && anon_vma->degree < 2) + anon_vma->num_children < 2 && + anon_vma->num_active_vmas =3D=3D 0) dst->anon_vma =3D anon_vma; } if (dst->anon_vma) - dst->anon_vma->degree++; + dst->anon_vma->num_active_vmas++; unlock_anon_vma_root(root); return 0; =20 @@ -354,6 +355,7 @@ int anon_vma_fork(struct vm_area_struct anon_vma =3D anon_vma_alloc(); if (!anon_vma) goto out_error; + anon_vma->num_active_vmas++; avc =3D anon_vma_chain_alloc(GFP_KERNEL); if (!avc) goto out_error_free_anon_vma; @@ -374,7 +376,7 @@ int anon_vma_fork(struct vm_area_struct vma->anon_vma =3D anon_vma; anon_vma_lock_write(anon_vma); anon_vma_chain_link(vma, avc, anon_vma); - anon_vma->parent->degree++; + anon_vma->parent->num_children++; anon_vma_unlock_write(anon_vma); =20 return 0; @@ -406,7 +408,7 @@ void unlink_anon_vmas(struct vm_area_str * to free them outside the lock. */ if (RB_EMPTY_ROOT(&anon_vma->rb_root.rb_root)) { - anon_vma->parent->degree--; + anon_vma->parent->num_children--; continue; } =20 @@ -414,7 +416,7 @@ void unlink_anon_vmas(struct vm_area_str anon_vma_chain_free(avc); } if (vma->anon_vma) - vma->anon_vma->degree--; + vma->anon_vma->num_active_vmas--; unlock_anon_vma_root(root); =20 /* @@ -425,7 +427,8 @@ void unlink_anon_vmas(struct vm_area_str list_for_each_entry_safe(avc, next, &vma->anon_vma_chain, same_vma) { struct anon_vma *anon_vma =3D avc->anon_vma; =20 - VM_WARN_ON(anon_vma->degree); + VM_WARN_ON(anon_vma->num_children); + VM_WARN_ON(anon_vma->num_active_vmas); put_anon_vma(anon_vma); =20 list_del(&avc->same_vma); From nobody Fri Apr 10 10:51:46 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 E016EECAAD5 for ; Fri, 2 Sep 2022 12:57:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238032AbiIBM5h (ORCPT ); Fri, 2 Sep 2022 08:57:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38668 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238177AbiIBMzO (ORCPT ); Fri, 2 Sep 2022 08:55:14 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03A89FB2AC; Fri, 2 Sep 2022 05:39:09 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D5739B81CCF; Fri, 2 Sep 2022 12:39:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A872C433D6; Fri, 2 Sep 2022 12:39:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122345; bh=Q0SVH1IxXT81b8t8CBT7NGPcmgYDkaNz/BIVC8rNBs0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ye8mUTqnLZYEYpMKugVoLD3QQO8KFtmvJmxR7QOShX9fbp21uRjoB1xCjOHM0MYwX pzkQNplfQ73Yefo4gXiOr6r8a9fEmBn5lsgX2KbYGb1XwugZLEMbnB10WzM+loWmCG P1ZnOuYe7ymLef1Nb+m6Zt83TR1ACk80mmzS6pP8= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Wenbin Mei , Ulf Hansson , Sasha Levin Subject: [PATCH 5.10 18/37] mmc: mtk-sd: Clear interrupts when cqe off/disable Date: Fri, 2 Sep 2022 14:19:40 +0200 Message-Id: <20220902121359.744176795@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Wenbin Mei [ Upstream commit cc5d1692600613e72f32af60e27330fe0c79f4fe ] Currently we don't clear MSDC interrupts when cqe off/disable, which led to the data complete interrupt will be reserved for the next command. If the next command with data transfer after cqe off/disable, we process the CMD ready interrupt and trigger DMA start for data, but the data complete interrupt is already exists, then SW assume that the data transfer is complete, SW will trigger DMA stop, but the data may not be transmitted yet or is transmitting, so we may encounter the following error: mtk-msdc 11230000.mmc: CMD bus busy detected. Signed-off-by: Wenbin Mei Fixes: 88bd652b3c74 ("mmc: mediatek: command queue support") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220728080048.21336-1-wenbin.mei@mediatek.= com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/mmc/host/mtk-sd.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index f5c965da95013..d71c113f428f6 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -2293,6 +2293,9 @@ static void msdc_cqe_disable(struct mmc_host *mmc, bo= ol recovery) /* disable busy check */ sdr_clr_bits(host->base + MSDC_PATCH_BIT1, MSDC_PB1_BUSY_CHECK_SEL); =20 + val =3D readl(host->base + MSDC_INT); + writel(val, host->base + MSDC_INT); + if (recovery) { sdr_set_field(host->base + MSDC_DMA_CTRL, MSDC_DMA_CTRL_STOP, 1); @@ -2693,11 +2696,14 @@ static int __maybe_unused msdc_suspend(struct devic= e *dev) { struct mmc_host *mmc =3D dev_get_drvdata(dev); int ret; + u32 val; =20 if (mmc->caps2 & MMC_CAP2_CQE) { ret =3D cqhci_suspend(mmc); if (ret) return ret; + val =3D readl(((struct msdc_host *)mmc_priv(mmc))->base + MSDC_INT); + writel(val, ((struct msdc_host *)mmc_priv(mmc))->base + MSDC_INT); } =20 return pm_runtime_force_suspend(dev); --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 3BCABC54EE9 for ; Fri, 2 Sep 2022 12:58:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238173AbiIBM6P (ORCPT ); Fri, 2 Sep 2022 08:58:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238083AbiIBM4U (ORCPT ); Fri, 2 Sep 2022 08:56:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 198EBFC10D; Fri, 2 Sep 2022 05:39:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E5B98B82A8B; Fri, 2 Sep 2022 12:39:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3FC42C433D6; Fri, 2 Sep 2022 12:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122348; bh=7lhXcAHIL3TDkoMSC25OC0sjHdnQIJIiGV0yYCdlsQ4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YbrIHCP7ImV9if2JakiCsNFMgG4SMIm3pL3a6h0YGQcq49C2B8fvgTc81d1MqOuW8 Xdll++W9fg5z4uW0BnPOP5txfmkC4e+1TKXjt4lMA5YqfjuHYcNvXRfaKVVKNmub0K lWec/pn2waM+8iOQeBZOYfarJ/r842tKuC7qxXcg= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Josip Pavic , Jun Lei , Alex Hung , Aric Cyr , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 5.10 19/37] drm/amd/display: Avoid MPC infinite loop Date: Fri, 2 Sep 2022 14:19:41 +0200 Message-Id: <20220902121359.772125162@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Josip Pavic [ Upstream commit 8de297dc046c180651c0500f8611663ae1c3828a ] [why] In some cases MPC tree bottom pipe ends up point to itself. This causes iterating from top to bottom to hang the system in an infinite loop. [how] When looping to next MPC bottom pipe, check that the pointer is not same as current to avoid infinite loop. Reviewed-by: Josip Pavic Reviewed-by: Jun Lei Acked-by: Alex Hung Signed-off-by: Aric Cyr Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 6 ++++++ drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c | 6 ++++++ 2 files changed, 12 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c b/drivers/gpu= /drm/amd/display/dc/dcn10/dcn10_mpc.c index 3fcd408e91032..855682590c1bb 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c @@ -125,6 +125,12 @@ struct mpcc *mpc1_get_mpcc_for_dpp(struct mpc_tree *tr= ee, int dpp_id) while (tmp_mpcc !=3D NULL) { if (tmp_mpcc->dpp_id =3D=3D dpp_id) return tmp_mpcc; + + /* avoid circular linked list */ + ASSERT(tmp_mpcc !=3D tmp_mpcc->mpcc_bot); + if (tmp_mpcc =3D=3D tmp_mpcc->mpcc_bot) + break; + tmp_mpcc =3D tmp_mpcc->mpcc_bot; } return NULL; diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c b/drivers/gpu= /drm/amd/display/dc/dcn20/dcn20_mpc.c index 99cc095dc33c7..a701ea56c0aa0 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c @@ -533,6 +533,12 @@ struct mpcc *mpc2_get_mpcc_for_dpp(struct mpc_tree *tr= ee, int dpp_id) while (tmp_mpcc !=3D NULL) { if (tmp_mpcc->dpp_id =3D=3D 0xf || tmp_mpcc->dpp_id =3D=3D dpp_id) return tmp_mpcc; + + /* avoid circular linked list */ + ASSERT(tmp_mpcc !=3D tmp_mpcc->mpcc_bot); + if (tmp_mpcc =3D=3D tmp_mpcc->mpcc_bot) + break; + tmp_mpcc =3D tmp_mpcc->mpcc_bot; } return NULL; --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 DD76DC6FA85 for ; Fri, 2 Sep 2022 12:59:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238163AbiIBM7d (ORCPT ); Fri, 2 Sep 2022 08:59:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47540 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238216AbiIBM5Z (ORCPT ); Fri, 2 Sep 2022 08:57:25 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9250DFB295; Fri, 2 Sep 2022 05:39:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 3427DB829E5; Fri, 2 Sep 2022 12:39:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70BC7C433C1; Fri, 2 Sep 2022 12:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122351; bh=Yi0ZLQXekHALMCo1xZjaKGu0N21/ZoJLrfDzDxhFFZU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hoY2tbE2Wx9AhXh7mv11dwWM0BAGtRwWWLgXyXju5whxnSf9Hd4X6KUOxgXr2HvKP buJyldqZ6Xm553Gm/3OuiXeCfonX8Hx4z90eSesZgBTn0d0SO4Rv6bqn8PoTSbbaib Rz8yAQm8H+NKWSmKIKV8N23GIUdELO9jgd471ylM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Martin Leung , Tom Chung , Alvin Lee , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 5.10 20/37] drm/amd/display: For stereo keep "FLIP_ANY_FRAME" Date: Fri, 2 Sep 2022 14:19:42 +0200 Message-Id: <20220902121359.805894912@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Alvin Lee [ Upstream commit 84ef99c728079dfd21d6bc70b4c3e4af20602b3c ] [Description] Observed in stereomode that programming FLIP_LEFT_EYE can cause hangs. Keep FLIP_ANY_FRAME in stereo mode so the surface flip can take place before left or right eye Reviewed-by: Martin Leung Acked-by: Tom Chung Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c b/drivers/gp= u/drm/amd/display/dc/dcn30/dcn30_hubp.c index af462fe4260de..b0fd8859bd2f2 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c +++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_hubp.c @@ -86,7 +86,7 @@ bool hubp3_program_surface_flip_and_addr( VMID, address->vmid); =20 if (address->type =3D=3D PLN_ADDR_TYPE_GRPH_STEREO) { - REG_UPDATE(DCSURF_FLIP_CONTROL, SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0x1); + REG_UPDATE(DCSURF_FLIP_CONTROL, SURFACE_FLIP_MODE_FOR_STEREOSYNC, 0); REG_UPDATE(DCSURF_FLIP_CONTROL, SURFACE_FLIP_IN_STEREOSYNC, 0x1); =20 } else { --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 341E2ECAAD5 for ; Fri, 2 Sep 2022 13:01:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236061AbiIBNBr (ORCPT ); Fri, 2 Sep 2022 09:01:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238211AbiIBM7e (ORCPT ); Fri, 2 Sep 2022 08:59:34 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61EEBFCA0A; Fri, 2 Sep 2022 05:41:01 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A7F776216B; Fri, 2 Sep 2022 12:39:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C194C433C1; Fri, 2 Sep 2022 12:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122355; bh=rQVPe2AP+dstyhY4TGM0lQgU9b22ikWfA5vLcarZ3Mg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hQsTmd1k4sJcJlS21rVM7Xf7hHvQpfBd98PmdP1cpztXH7YFE2D/If6gHeK74WLyk q2Tv8NhlSembVbzw9OWofqYVu8DdzBRkbKvlqcvZc//mDJvwbuV62/16jWeDKeJKb6 tmwtkv8Co6jWB8+l75Lny0o82xSm7Ov7LHeFy0KI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Alvin Lee , Tom Chung , Fudong Wang , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 5.10 21/37] drm/amd/display: clear optc underflow before turn off odm clock Date: Fri, 2 Sep 2022 14:19:43 +0200 Message-Id: <20220902121359.844133783@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Fudong Wang [ Upstream commit b2a93490201300a749ad261b5c5d05cb50179c44 ] [Why] After ODM clock off, optc underflow bit will be kept there always and clear= not work. We need to clear that before clock off. [How] Clear that if have when clock off. Reviewed-by: Alvin Lee Acked-by: Tom Chung Signed-off-by: Fudong Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c b/drivers/gp= u/drm/amd/display/dc/dcn10/dcn10_optc.c index 800be2693faca..963d72f96dca3 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_optc.c @@ -464,6 +464,11 @@ void optc1_enable_optc_clock(struct timing_generator *= optc, bool enable) OTG_CLOCK_ON, 1, 1, 1000); } else { + + //last chance to clear underflow, otherwise, it will always there due to= clock is off. + if (optc->funcs->is_optc_underflow_occurred(optc) =3D=3D true) + optc->funcs->clear_optc_underflow(optc); + REG_UPDATE_2(OTG_CLOCK_CONTROL, OTG_CLOCK_GATE_DIS, 0, OTG_CLOCK_EN, 0); --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 9AAF2C38145 for ; Fri, 2 Sep 2022 13:02:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238618AbiIBNCM (ORCPT ); Fri, 2 Sep 2022 09:02:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238476AbiIBNAU (ORCPT ); Fri, 2 Sep 2022 09:00:20 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67CA8FC335; Fri, 2 Sep 2022 05:40:59 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 2CBC9B82AC8; Fri, 2 Sep 2022 12:39:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 67E45C433D6; Fri, 2 Sep 2022 12:39:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122357; bh=bYlICM6Qgwhi5tAFWazWgh8mpqGEcWaF0Dp4ZqVvWFs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EVG1XBvkFHWwp4F5bXrTpIu9/H2gbQ/bHh6G+ytoEMd19ggt+Fa35dqImH6GgMc7M DE/2E6QVpTGpafy69QqzgHAF+t+X5kAhMKPoCUxRVkE4wGpBDH8DXY9i1QZqBMBtMs m/y01UtGtvQrQAd3jTBN/xZtpT4ThzkdsyPzhyoI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Daniel Borkmann , David Ahern , Yajun Deng , Roopa Prabhu , Christian Brauner , netdev@vger.kernel.org, Alexey Kuznetsov , Alexander Mikhalitsyn , Konstantin Khorenko , kernel@openvz.org, devel@openvz.org, "Denis V. Lunev" , Sasha Levin Subject: [PATCH 5.10 22/37] neigh: fix possible DoS due to net iface start/stop loop Date: Fri, 2 Sep 2022 14:19:44 +0200 Message-Id: <20220902121359.873244372@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Denis V. Lunev [ Upstream commit 66ba215cb51323e4e55e38fd5f250e0fae0cbc94 ] Normal processing of ARP request (usually this is Ethernet broadcast packet) coming to the host is looking like the following: * the packet comes to arp_process() call and is passed through routing procedure * the request is put into the queue using pneigh_enqueue() if corresponding ARP record is not local (common case for container records on the host) * the request is processed by timer (within 80 jiffies by default) and ARP reply is sent from the same arp_process() using NEIGH_CB(skb)->flags & LOCALLY_ENQUEUED condition (flag is set inside pneigh_enqueue()) And here the problem comes. Linux kernel calls pneigh_queue_purge() which destroys the whole queue of ARP requests on ANY network interface start/stop event through __neigh_ifdown(). This is actually not a problem within the original world as network interface start/stop was accessible to the host 'root' only, which could do more destructive things. But the world is changed and there are Linux containers available. Here container 'root' has an access to this API and could be considered as untrusted user in the hosting (container's) world. Thus there is an attack vector to other containers on node when container's root will endlessly start/stop interfaces. We have observed similar situation on a real production node when docker container was doing such activity and thus other containers on the node become not accessible. The patch proposed doing very simple thing. It drops only packets from the same namespace in the pneigh_queue_purge() where network interface state change is detected. This is enough to prevent the problem for the whole node preserving original semantics of the code. v2: - do del_timer_sync() if queue is empty after pneigh_queue_purge() v3: - rebase to net tree Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Daniel Borkmann Cc: David Ahern Cc: Yajun Deng Cc: Roopa Prabhu Cc: Christian Brauner Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Alexey Kuznetsov Cc: Alexander Mikhalitsyn Cc: Konstantin Khorenko Cc: kernel@openvz.org Cc: devel@openvz.org Investigated-by: Alexander Mikhalitsyn Signed-off-by: Denis V. Lunev 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: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/neighbour.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-) diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 52a1c8725337b..e7dcdad5876b1 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -280,14 +280,23 @@ static int neigh_del_timer(struct neighbour *n) return 0; } =20 -static void pneigh_queue_purge(struct sk_buff_head *list) +static void pneigh_queue_purge(struct sk_buff_head *list, struct net *net) { + unsigned long flags; struct sk_buff *skb; =20 - while ((skb =3D skb_dequeue(list)) !=3D NULL) { - dev_put(skb->dev); - kfree_skb(skb); + spin_lock_irqsave(&list->lock, flags); + skb =3D skb_peek(list); + while (skb !=3D NULL) { + struct sk_buff *skb_next =3D skb_peek_next(skb, list); + if (net =3D=3D NULL || net_eq(dev_net(skb->dev), net)) { + __skb_unlink(skb, list); + dev_put(skb->dev); + kfree_skb(skb); + } + skb =3D skb_next; } + spin_unlock_irqrestore(&list->lock, flags); } =20 static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *de= v, @@ -358,9 +367,9 @@ static int __neigh_ifdown(struct neigh_table *tbl, stru= ct net_device *dev, write_lock_bh(&tbl->lock); neigh_flush_dev(tbl, dev, skip_perm); pneigh_ifdown_and_unlock(tbl, dev); - - del_timer_sync(&tbl->proxy_timer); - pneigh_queue_purge(&tbl->proxy_queue); + pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev)); + if (skb_queue_empty_lockless(&tbl->proxy_queue)) + del_timer_sync(&tbl->proxy_timer); return 0; } =20 @@ -1743,7 +1752,7 @@ int neigh_table_clear(int index, struct neigh_table *= tbl) /* It is not clean... Fix it to unload IPv6 module safely */ cancel_delayed_work_sync(&tbl->gc_work); del_timer_sync(&tbl->proxy_timer); - pneigh_queue_purge(&tbl->proxy_queue); + pneigh_queue_purge(&tbl->proxy_queue, NULL); neigh_ifdown(tbl, NULL); if (atomic_read(&tbl->entries)) pr_crit("neighbour leakage\n"); --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 228EDC6FA82 for ; Fri, 2 Sep 2022 13:01:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238491AbiIBNBb (ORCPT ); Fri, 2 Sep 2022 09:01:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238112AbiIBM7c (ORCPT ); Fri, 2 Sep 2022 08:59:32 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96012FC33A; Fri, 2 Sep 2022 05:40:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B041E6217E; Fri, 2 Sep 2022 12:39:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8EDFC433C1; Fri, 2 Sep 2022 12:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122361; bh=lVgdqr38Jt4ri3oENA3ZbW/QQK5tDQxvfQtgt9PHjxc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WKWbpZ4D+zPT0fJc6AcDqAbE1v4bbekjhWPGbIz+r88rOzDG1pBrAlN2U7k+9HQcU 5/hS54Dcg05s9RD8hnVBtcTXRspaHKgba5k6DXlLaSI8mEvXxrIU6Re84DWJisrhqi LkUQFlK8UftjheEclqPi3JTmZytsYXkJ4VW6OLdI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Juergen Gross , Heiko Carstens , Christian Borntraeger , Alexander Gordeev , Sasha Levin Subject: [PATCH 5.10 23/37] s390/hypfs: avoid error message under KVM Date: Fri, 2 Sep 2022 14:19:45 +0200 Message-Id: <20220902121359.902181760@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Juergen Gross [ Upstream commit 7b6670b03641ac308aaa6fa2e6f964ac993b5ea3 ] When booting under KVM the following error messages are issued: hypfs.7f5705: The hardware system does not support hypfs hypfs.7a79f0: Initialization of hypfs failed with rc=3D-61 Demote the severity of first message from "error" to "info" and issue the second message only in other error cases. Signed-off-by: Juergen Gross Acked-by: Heiko Carstens Acked-by: Christian Borntraeger Link: https://lore.kernel.org/r/20220620094534.18967-1-jgross@suse.com [arch/s390/hypfs/hypfs_diag.c changed description] Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- arch/s390/hypfs/hypfs_diag.c | 2 +- arch/s390/hypfs/inode.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/hypfs/hypfs_diag.c b/arch/s390/hypfs/hypfs_diag.c index f0bc4dc3e9bf0..6511d15ace45e 100644 --- a/arch/s390/hypfs/hypfs_diag.c +++ b/arch/s390/hypfs/hypfs_diag.c @@ -437,7 +437,7 @@ __init int hypfs_diag_init(void) int rc; =20 if (diag204_probe()) { - pr_err("The hardware system does not support hypfs\n"); + pr_info("The hardware system does not support hypfs\n"); return -ENODATA; } =20 diff --git a/arch/s390/hypfs/inode.c b/arch/s390/hypfs/inode.c index 5c97f48cea91d..ee919bfc81867 100644 --- a/arch/s390/hypfs/inode.c +++ b/arch/s390/hypfs/inode.c @@ -496,9 +496,9 @@ static int __init hypfs_init(void) hypfs_vm_exit(); fail_hypfs_diag_exit: hypfs_diag_exit(); + pr_err("Initialization of hypfs failed with rc=3D%i\n", rc); fail_dbfs_exit: hypfs_dbfs_exit(); - pr_err("Initialization of hypfs failed with rc=3D%i\n", rc); return rc; } device_initcall(hypfs_init) --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 62CD5ECAAD5 for ; Fri, 2 Sep 2022 14:36:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236569AbiIBOgW (ORCPT ); Fri, 2 Sep 2022 10:36:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236297AbiIBOfk (ORCPT ); Fri, 2 Sep 2022 10:35:40 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8444167476; Fri, 2 Sep 2022 06:56:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A95596217F; Fri, 2 Sep 2022 12:39:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF2AAC433C1; Fri, 2 Sep 2022 12:39:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122364; bh=fnN0EiVZn6o6LF1pXzUjmt8WAUMjyGbBmYQqntl8lKc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gW3V/2b09SnWKas4isj5lqtEzNbhWOxe8U+piQHLxpID5F5HGWmWClIohL8v2YIze PasliXceOpDdMmDSAlcWCBi9WL4ArF80jHBUxgYlKGFArYez03Mpuk+/KFQZW989Df 8DwVKQEtY003flM3Q1Rv7ARB2rwGEHjKbgyT5pvk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Evan Quan , Alex Deucher , Sasha Levin Subject: [PATCH 5.10 24/37] drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid Date: Fri, 2 Sep 2022 14:19:46 +0200 Message-Id: <20220902121359.932334412@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Evan Quan [ Upstream commit 0a2d922a5618377cdf8fa476351362733ef55342 ] To avoid any potential memory leak. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c b/driv= ers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c index 8556c229ff598..49d7fa1d08427 100644 --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c @@ -2759,6 +2759,7 @@ static const struct pptable_funcs sienna_cichlid_ppt_= funcs =3D { .dump_pptable =3D sienna_cichlid_dump_pptable, .init_microcode =3D smu_v11_0_init_microcode, .load_microcode =3D smu_v11_0_load_microcode, + .fini_microcode =3D smu_v11_0_fini_microcode, .init_smc_tables =3D sienna_cichlid_init_smc_tables, .fini_smc_tables =3D smu_v11_0_fini_smc_tables, .init_power =3D smu_v11_0_init_power, --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 3BD6FC54EE9 for ; Fri, 2 Sep 2022 13:02:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238636AbiIBNCh (ORCPT ); Fri, 2 Sep 2022 09:02:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238584AbiIBNBR (ORCPT ); Fri, 2 Sep 2022 09:01:17 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B53F01090A1; Fri, 2 Sep 2022 05:41:21 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D1D506215D; Fri, 2 Sep 2022 12:39:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2E54C433C1; Fri, 2 Sep 2022 12:39:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122370; bh=I48YNY8iGTo0l+25pl0NUHm3d2fzxBhUGKALZNO7RzY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=T5VS9g8Gu3cHdA2d91bTxqvuizPUdVvWCjWZN7VOMlWaNws/1sZojXuZ9Cw8wsAt8 xN6BqtU3fOW53jnjwnUpcVDmz4MuRvUv2urGs67ZTaL5wZ323UA8T446/DqgJQxgrd 2ri9kC4ljF3yi/jKk6EY6G+bLQe7U7rT6zfk3DDI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Aric Cyr , Brian Chang , Ilya Bakoulin , Daniel Wheeler , Alex Deucher , Sasha Levin Subject: [PATCH 5.10 25/37] drm/amd/display: Fix pixel clock programming Date: Fri, 2 Sep 2022 14:19:47 +0200 Message-Id: <20220902121359.959351226@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Ilya Bakoulin [ Upstream commit 04fb918bf421b299feaee1006e82921d7d381f18 ] [Why] Some pixel clock values could cause HDMI TMDS SSCPs to be misaligned between different HDMI lanes when using YCbCr420 10-bit pixel format. BIOS functions for transmitter/encoder control take pixel clock in kHz increments, whereas the function for setting the pixel clock is in 100Hz increments. Setting pixel clock to a value that is not on a kHz boundary will cause the issue. [How] Round pixel clock down to nearest kHz in 10/12-bpc cases. Reviewed-by: Aric Cyr Acked-by: Brian Chang Signed-off-by: Ilya Bakoulin Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c b/driver= s/gpu/drm/amd/display/dc/dce/dce_clock_source.c index bae3a146b2cc2..89cc852cb27c5 100644 --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clock_source.c @@ -546,9 +546,11 @@ static void dce112_get_pix_clk_dividers_helper ( switch (pix_clk_params->color_depth) { case COLOR_DEPTH_101010: actual_pixel_clock_100hz =3D (actual_pixel_clock_100hz * 5) >> 2; + actual_pixel_clock_100hz -=3D actual_pixel_clock_100hz % 10; break; case COLOR_DEPTH_121212: actual_pixel_clock_100hz =3D (actual_pixel_clock_100hz * 6) >> 2; + actual_pixel_clock_100hz -=3D actual_pixel_clock_100hz % 10; break; case COLOR_DEPTH_161616: actual_pixel_clock_100hz =3D actual_pixel_clock_100hz * 2; --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 F112FC38145 for ; Fri, 2 Sep 2022 12:59:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238348AbiIBM7j (ORCPT ); Fri, 2 Sep 2022 08:59:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238370AbiIBM57 (ORCPT ); Fri, 2 Sep 2022 08:57:59 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A62260F9; Fri, 2 Sep 2022 05:39:52 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A5466B81CCF; Fri, 2 Sep 2022 12:39:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC475C433C1; Fri, 2 Sep 2022 12:39:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122373; bh=GRfRgwRNZtPb6r67mlPpKY252biLe89b9FGSVYoHyMk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UHKgzAr0SmmGReN5yDYEgsnXwO11r//94jj/BnoPLUXJAvbjs9SMgFQxBgeOilVom IiK/tUcvnpr7QTOdORFxUYPFN6x9tXEc0y94dMaSphQ599ruZoEsYXcltX78iF7fX2 Amj8WrNG+UyRtuqrPxI+0UReIkWNKpz30yCZWTbE= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Dusica Milinkovic , Shaoyun Liu , Alex Deucher , Sasha Levin Subject: [PATCH 5.10 26/37] drm/amdgpu: Increase tlb flush timeout for sriov Date: Fri, 2 Sep 2022 14:19:48 +0200 Message-Id: <20220902121359.988440574@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Dusica Milinkovic [ Upstream commit 373008bfc9cdb0f050258947fa5a095f0657e1bc ] [Why] During multi-vf executing benchmark (Luxmark) observed kiq error timeout. It happenes because all of VFs do the tlb invalidation at the same time. Although each VF has the invalidate register set, from hardware side the invalidate requests are queue to execute. [How] In case of 12 VF increase timeout on 12*100ms Signed-off-by: Dusica Milinkovic Acked-by: Shaoyun Liu Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 3 ++- drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 3 ++- 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdg= pu/amdgpu.h index d949d6c52f24b..ff5555353eb4f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h @@ -283,7 +283,7 @@ enum amdgpu_kiq_irq { AMDGPU_CP_KIQ_IRQ_DRIVER0 =3D 0, AMDGPU_CP_KIQ_IRQ_LAST }; - +#define SRIOV_USEC_TIMEOUT 1200000 /* wait 12 * 100ms for SRIOV */ #define MAX_KIQ_REG_WAIT 5000 /* in usecs, 5ms */ #define MAX_KIQ_REG_BAILOUT_INTERVAL 5 /* in msecs, 5ms */ #define MAX_KIQ_REG_TRY 80 /* 20 -> 80 */ diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c b/drivers/gpu/drm/amd/a= mdgpu/gmc_v10_0.c index 150fa5258fb6f..2aa9242c58ab9 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c @@ -371,6 +371,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct amdgpu_= device *adev, uint32_t seq; uint16_t queried_pasid; bool ret; + u32 usec_timeout =3D amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT : adev->u= sec_timeout; struct amdgpu_ring *ring =3D &adev->gfx.kiq.ring; struct amdgpu_kiq *kiq =3D &adev->gfx.kiq; =20 @@ -389,7 +390,7 @@ static int gmc_v10_0_flush_gpu_tlb_pasid(struct amdgpu_= device *adev, =20 amdgpu_ring_commit(ring); spin_unlock(&adev->gfx.kiq.ring_lock); - r =3D amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout); + r =3D amdgpu_fence_wait_polling(ring, seq, usec_timeout); if (r < 1) { dev_err(adev->dev, "wait for kiq fence error: %ld.\n", r); return -ETIME; diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c b/drivers/gpu/drm/amd/am= dgpu/gmc_v9_0.c index 3a864041968f6..1673bf3bae55a 100644 --- a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c @@ -839,6 +839,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct amdgpu_d= evice *adev, uint32_t seq; uint16_t queried_pasid; bool ret; + u32 usec_timeout =3D amdgpu_sriov_vf(adev) ? SRIOV_USEC_TIMEOUT : adev->u= sec_timeout; struct amdgpu_ring *ring =3D &adev->gfx.kiq.ring; struct amdgpu_kiq *kiq =3D &adev->gfx.kiq; =20 @@ -878,7 +879,7 @@ static int gmc_v9_0_flush_gpu_tlb_pasid(struct amdgpu_d= evice *adev, =20 amdgpu_ring_commit(ring); spin_unlock(&adev->gfx.kiq.ring_lock); - r =3D amdgpu_fence_wait_polling(ring, seq, adev->usec_timeout); + r =3D amdgpu_fence_wait_polling(ring, seq, usec_timeout); if (r < 1) { dev_err(adev->dev, "wait for kiq fence error: %ld.\n", r); up_read(&adev->reset_sem); --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 36660ECAAD5 for ; Fri, 2 Sep 2022 13:01:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238452AbiIBNBv (ORCPT ); Fri, 2 Sep 2022 09:01:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48672 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238265AbiIBM7g (ORCPT ); Fri, 2 Sep 2022 08:59:36 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 528D6D4F51; Fri, 2 Sep 2022 05:40:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C9ECFB82AC5; Fri, 2 Sep 2022 12:39:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 227F6C433D6; Fri, 2 Sep 2022 12:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122376; bh=Rl54nJO1BHf012tRjZqYPLcT3BC/VSEP7sb101CBww0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dfOfup6MlQQjFdDr9IN/GFj0NBgmptaGgS67G858XwY1QhcKlj9oAp0zzYfKrzTTI UeG2ynyDL0oJvwAkYmyPEa77Oyg1Y3afAk5zMnDkHAO7aX1HxMVAXPEozXRk11HAAv KqBq6WVRYjRB7fpnSCE1cTcBJJ2KkvMued2j9/XM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Geert Uytterhoeven , Florian Westphal , Sasha Levin Subject: [PATCH 5.10 27/37] netfilter: conntrack: NF_CONNTRACK_PROCFS should no longer default to y Date: Fri, 2 Sep 2022 14:19:49 +0200 Message-Id: <20220902121400.016500501@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Geert Uytterhoeven [ Upstream commit aa5762c34213aba7a72dc58e70601370805fa794 ] NF_CONNTRACK_PROCFS was marked obsolete in commit 54b07dca68557b09 ("netfilter: provide config option to disable ancient procfs parts") in v3.3. Signed-off-by: Geert Uytterhoeven Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/netfilter/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index 6bafd3876aff3..8bf70ce03f951 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -118,7 +118,6 @@ config NF_CONNTRACK_ZONES =20 config NF_CONNTRACK_PROCFS bool "Supply CT list in procfs (OBSOLETE)" - default y depends on PROC_FS help This option enables for the list of known conntrack entries --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 25FAAECAAD5 for ; Fri, 2 Sep 2022 13:00:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238446AbiIBNAK (ORCPT ); Fri, 2 Sep 2022 09:00:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238521AbiIBM66 (ORCPT ); Fri, 2 Sep 2022 08:58:58 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 994CE100B; Fri, 2 Sep 2022 05:40:03 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 275BDB82A8B; Fri, 2 Sep 2022 12:39:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CCAAC433D6; Fri, 2 Sep 2022 12:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122379; bh=bZOdvd7tVKQAveBefOzuydtnXtRslrZSGWeFKUZsUMM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fmp8wl9nHotw2Q17jcQvcocvl00L7elzppSlCY7wYZ/nDhGEnCR5RPfS+eZvkGcAI UPWi0YuI4ptSBw80Ye2+OCtW+nyq/S2JV57Yquc3xG6Y0VIGZzSnJmQYUlWK7hBic4 pNyUgeyjKbR0jHD+tTZMoWcqUJELu0aEwHQMyFUY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Christophe Leroy , Thomas Gleixner , Vincenzo Frascino , Michael Ellerman , Sasha Levin Subject: [PATCH 5.10 28/37] lib/vdso: Mark do_hres_timens() and do_coarse_timens() __always_inline() Date: Fri, 2 Sep 2022 14:19:50 +0200 Message-Id: <20220902121400.049401850@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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 [ Upstream commit 58efe9f696cf908f40d6672aeca81cb2ad2bc762 ] In the same spirit as commit c966533f8c6c ("lib/vdso: Mark do_hres() and do_coarse() as __always_inline"), mark do_hres_timens() and do_coarse_timens() __always_inline. The measurement below in on a non timens process, ie on the fastest path. On powerpc32, without the patch: clock-gettime-monotonic-raw: vdso: 1155 nsec/call clock-gettime-monotonic-coarse: vdso: 813 nsec/call clock-gettime-monotonic: vdso: 1076 nsec/call With the patch: clock-gettime-monotonic-raw: vdso: 1100 nsec/call clock-gettime-monotonic-coarse: vdso: 667 nsec/call clock-gettime-monotonic: vdso: 1025 nsec/call Signed-off-by: Christophe Leroy Reviewed-by: Thomas Gleixner Reviewed-by: Vincenzo Frascino Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/90dcf45ebadfd5a07f24241551c62f619d1cb930.16= 17209142.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- lib/vdso/gettimeofday.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/lib/vdso/gettimeofday.c b/lib/vdso/gettimeofday.c index 2919f16981404..c6f6dee087460 100644 --- a/lib/vdso/gettimeofday.c +++ b/lib/vdso/gettimeofday.c @@ -46,8 +46,8 @@ static inline bool vdso_cycles_ok(u64 cycles) #endif =20 #ifdef CONFIG_TIME_NS -static int do_hres_timens(const struct vdso_data *vdns, clockid_t clk, - struct __kernel_timespec *ts) +static __always_inline int do_hres_timens(const struct vdso_data *vdns, cl= ockid_t clk, + struct __kernel_timespec *ts) { const struct vdso_data *vd =3D __arch_get_timens_vdso_data(); const struct timens_offset *offs =3D &vdns->offset[clk]; @@ -97,8 +97,8 @@ static __always_inline const struct vdso_data *__arch_get= _timens_vdso_data(void) return NULL; } =20 -static int do_hres_timens(const struct vdso_data *vdns, clockid_t clk, - struct __kernel_timespec *ts) +static __always_inline int do_hres_timens(const struct vdso_data *vdns, cl= ockid_t clk, + struct __kernel_timespec *ts) { return -EINVAL; } @@ -159,8 +159,8 @@ static __always_inline int do_hres(const struct vdso_da= ta *vd, clockid_t clk, } =20 #ifdef CONFIG_TIME_NS -static int do_coarse_timens(const struct vdso_data *vdns, clockid_t clk, - struct __kernel_timespec *ts) +static __always_inline int do_coarse_timens(const struct vdso_data *vdns, = clockid_t clk, + struct __kernel_timespec *ts) { const struct vdso_data *vd =3D __arch_get_timens_vdso_data(); const struct vdso_timestamp *vdso_ts =3D &vd->basetime[clk]; @@ -188,8 +188,8 @@ static int do_coarse_timens(const struct vdso_data *vdn= s, clockid_t clk, return 0; } #else -static int do_coarse_timens(const struct vdso_data *vdns, clockid_t clk, - struct __kernel_timespec *ts) +static __always_inline int do_coarse_timens(const struct vdso_data *vdns, = clockid_t clk, + struct __kernel_timespec *ts) { return -1; } --=20 2.35.1 From nobody Fri Apr 10 10:51:46 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 0CB20C38145 for ; Fri, 2 Sep 2022 12:59:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238413AbiIBM7z (ORCPT ); Fri, 2 Sep 2022 08:59:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238476AbiIBM6t (ORCPT ); Fri, 2 Sep 2022 08:58:49 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 835863AB1E; Fri, 2 Sep 2022 05:40:08 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E3C0BB82AC9; Fri, 2 Sep 2022 12:39:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 187CBC433C1; Fri, 2 Sep 2022 12:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122382; bh=vZZC4t0wZnIFjIs+2LojoObBY6qivzb/3hLQTr2f4+0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DoGPWw4CQDfGQz5Z/x1+JQ61Pe37bKylJmbJlEcaC3jbPApr47D0+NX7aa2DLN129 5GgHGkssKaK9GI2NLD2Iu7Zn/9eI6YA4IJoMyyqGo4qpjXKus8Xe28F1aJ0TEE00xU 2XsDeY4cqkxO9PoEZpStvG47hcIfLmld5ZQZ6lbY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Kuniyuki Iwashima , Ayushman Dutta , "Naveen N. Rao" , Anil S Keshavamurthy , "David S. Miller" , Masami Hiramatsu , Wang Nan , Kuniyuki Iwashima , Andrew Morton Subject: [PATCH 5.10 29/37] kprobes: dont call disarm_kprobe() for disabled kprobes Date: Fri, 2 Sep 2022 14:19:51 +0200 Message-Id: <20220902121400.082172669@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Kuniyuki Iwashima commit 9c80e79906b4ca440d09e7f116609262bb747909 upstream. The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 3. Write 1 to /sys/kernel/debug/kprobes/enabled, which changes kprobes_all_disarmed to false but does not arm the disabled kprobe. # echo 1 > /sys/kernel/debug/kprobes/enabled # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffffffff91345650 k __x64_sys_execve+0x0 [DISABLED][FTRACE] 4. Kill execsnoop, when __disable_kprobe() calls disarm_kprobe() for the disabled kprobe and hits the WARN_ONCE() in __disarm_kprobe_ftrace(). # fg /usr/share/bcc/tools/execsnoop ^C Actually, WARN_ONCE() is fired twice, and __unregister_kprobe_top() misses some cleanups and leaves the aggregated kprobe in the hash table. Then, __unregister_trace_kprobe() initialises tk->rp.kp.list and creates an infinite loop like this. aggregated kprobe.list -> kprobe.list -. ^ | '.__.' In this situation, these commands fall into the infinite loop and result in RCU stall or soft lockup. cat /sys/kernel/debug/kprobes/list : show_kprobe_addr() enters into the infinite loop with RCU. /usr/share/bcc/tools/execsnoop : warn_kprobe_rereg() holds kprobe_mutex, and __get_valid_kprobe() is stuck in the loop. To avoid the issue, make sure we don't call disarm_kprobe() for disabled kprobes. [0] Failed to disarm kprobe-ftrace at __x64_sys_execve+0x0/0x40 (error -2) WARNING: CPU: 6 PID: 2460 at kernel/kprobes.c:1130 __disarm_kprobe_ftrace.i= sra.19 (kernel/kprobes.c:1129) Modules linked in: ena CPU: 6 PID: 2460 Comm: execsnoop Not tainted 5.19.0+ #28 Hardware name: Amazon EC2 c5.2xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:__disarm_kprobe_ftrace.isra.19 (kernel/kprobes.c:1129) Code: 24 8b 02 eb c1 80 3d c4 83 f2 01 00 75 d4 48 8b 75 00 89 c2 48 c7 c7 = 90 fa 0f 92 89 04 24 c6 05 ab 83 01 e8 e4 94 f0 ff <0f> 0b 8b 04 24 eb b1 8= 9 c6 48 c7 c7 60 fa 0f 92 89 04 24 e8 cc 94 RSP: 0018:ffff9e6ec154bd98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffff930f7b00 RCX: 0000000000000001 RDX: 0000000080000001 RSI: ffffffff921461c5 RDI: 00000000ffffffff RBP: ffff89c504286da8 R08: 0000000000000000 R09: c0000000fffeffff R10: 0000000000000000 R11: ffff9e6ec154bc28 R12: ffff89c502394e40 R13: ffff89c502394c00 R14: ffff9e6ec154bc00 R15: 0000000000000000 FS: 00007fe800398740(0000) GS:ffff89c812d80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000c00057f010 CR3: 0000000103b54006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: __disable_kprobe (kernel/kprobes.c:1716) disable_kprobe (kernel/kprobes.c:2392) __disable_trace_kprobe (kernel/trace/trace_kprobe.c:340) disable_trace_kprobe (kernel/trace/trace_kprobe.c:429) perf_trace_event_unreg.isra.2 (./include/linux/tracepoint.h:93 kernel/trac= e/trace_event_perf.c:168) perf_kprobe_destroy (kernel/trace/trace_event_perf.c:295) _free_event (kernel/events/core.c:4971) perf_event_release_kernel (kernel/events/core.c:5176) perf_release (kernel/events/core.c:5186) __fput (fs/file_table.c:321) task_work_run (./include/linux/sched.h:2056 (discriminator 1) kernel/task_= work.c:179 (discriminator 1)) exit_to_user_mode_prepare (./include/linux/resume_user_mode.h:49 kernel/en= try/common.c:169 kernel/entry/common.c:201) syscall_exit_to_user_mode (./arch/x86/include/asm/jump_label.h:55 ./arch/x= 86/include/asm/nospec-branch.h:384 ./arch/x86/include/asm/entry-common.h:94= kernel/entry/common.c:133 kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:87) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) RIP: 0033:0x7fe7ff210654 Code: 15 79 89 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb be 0f 1f 00 8b = 05 9a cd 20 00 48 63 ff 85 c0 75 11 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff f= f 77 3a f3 c3 48 83 ec 18 48 89 7c 24 08 e8 34 fc RSP: 002b:00007ffdbd1d3538 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000008 RCX: 00007fe7ff210654 RDX: 0000000000000000 RSI: 0000000000002401 RDI: 0000000000000008 RBP: 0000000000000000 R08: 94ae31d6fda838a4 R0900007fe8001c9d30 R10: 00007ffdbd1d34b0 R11: 0000000000000246 R12: 00007ffdbd1d3600 R13: 0000000000000000 R14: fffffffffffffffc R15: 00007ffdbd1d3560 Link: https://lkml.kernel.org/r/20220813020509.90805-1-kuniyu@amazon.com Fixes: 69d54b916d83 ("kprobes: makes kprobes/enabled works correctly for op= timized kprobes.") Signed-off-by: Kuniyuki Iwashima Reported-by: Ayushman Dutta Cc: "Naveen N. Rao" Cc: Anil S Keshavamurthy Cc: "David S. Miller" Cc: Masami Hiramatsu Cc: Wang Nan Cc: Kuniyuki Iwashima Cc: Kuniyuki Iwashima Cc: Ayushman Dutta Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- kernel/kprobes.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -1786,11 +1786,12 @@ static struct kprobe *__disable_kprobe(s /* Try to disarm and disable this/parent probe */ if (p =3D=3D orig_p || aggr_kprobe_disabled(orig_p)) { /* - * If kprobes_all_disarmed is set, orig_p - * should have already been disarmed, so - * skip unneed disarming process. + * Don't be lazy here. Even if 'kprobes_all_disarmed' + * is false, 'orig_p' might not have been armed yet. + * Note arm_all_kprobes() __tries__ to arm all kprobes + * on the best effort basis. */ - if (!kprobes_all_disarmed) { + if (!kprobes_all_disarmed && !kprobe_disabled(orig_p)) { ret =3D disarm_kprobe(orig_p, true); if (ret) { p->flags &=3D ~KPROBE_FLAG_DISABLED; From nobody Fri Apr 10 10:51:46 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 DFB9EC38145 for ; Fri, 2 Sep 2022 13:00:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238458AbiIBNAR (ORCPT ); Fri, 2 Sep 2022 09:00:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238532AbiIBM67 (ORCPT ); Fri, 2 Sep 2022 08:58:59 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83F19520BF; Fri, 2 Sep 2022 05:40:17 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1DE78B82AD7; Fri, 2 Sep 2022 12:39:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57321C433C1; Fri, 2 Sep 2022 12:39:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122385; bh=G2T7Tlf5fBjaTBzZT3U25YetWR9g+p/O4H0DDcDcyqA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=yDPvrazkY4Ok2dMzwogmXskXeKiG/NGH/GrCyqgx7OsJsifLO8kqJqGmEP0LCSe4D +oh9TplYp3RzWPYB2FptO0MuOGRk9J6PIFdvZFsnjYnFqe/UUywA9r1F5YuJ3veDgU 0pYounfvlGKbc9nCRDc8DgO/6+xVpRHZbJMb7l0U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Greg Kroah-Hartman , Pavel Begunkov Subject: [PATCH 5.10 30/37] io_uring: disable polling pollfree files Date: Fri, 2 Sep 2022 14:19:52 +0200 Message-Id: <20220902121400.115965399@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" From: Pavel Begunkov Older kernels lack io_uring POLLFREE handling. As only affected files are signalfd and android binder the safest option would be to disable polling those files via io_uring and hope there are no users. Fixes: 221c5eb233823 ("io_uring: add support for IORING_OP_POLL") Signed-off-by: Pavel Begunkov Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- drivers/android/binder.c | 1 + fs/io_uring.c | 5 +++++ fs/signalfd.c | 1 + include/linux/fs.h | 1 + 4 files changed, 8 insertions(+) --- a/drivers/android/binder.c +++ b/drivers/android/binder.c @@ -6069,6 +6069,7 @@ const struct file_operations binder_fops .open =3D binder_open, .flush =3D binder_flush, .release =3D binder_release, + .may_pollfree =3D true, }; =20 static int __init init_binder_device(const char *name) --- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -5198,6 +5198,11 @@ static __poll_t __io_arm_poll_handler(st struct io_ring_ctx *ctx =3D req->ctx; bool cancel =3D false; =20 + if (req->file->f_op->may_pollfree) { + spin_lock_irq(&ctx->completion_lock); + return -EOPNOTSUPP; + } + INIT_HLIST_NODE(&req->hash_node); io_init_poll_iocb(poll, mask, wake_func); poll->file =3D req->file; --- a/fs/signalfd.c +++ b/fs/signalfd.c @@ -248,6 +248,7 @@ static const struct file_operations sign .poll =3D signalfd_poll, .read =3D signalfd_read, .llseek =3D noop_llseek, + .may_pollfree =3D true, }; =20 static int do_signalfd4(int ufd, sigset_t *mask, int flags) --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1859,6 +1859,7 @@ struct file_operations { struct file *file_out, loff_t pos_out, loff_t len, unsigned int remap_flags); int (*fadvise)(struct file *, loff_t, loff_t, int); + bool may_pollfree; } __randomize_layout; =20 struct inode_operations { From nobody Fri Apr 10 10:51:46 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 8FAC8ECAAD5 for ; Fri, 2 Sep 2022 13:03:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238657AbiIBNDP (ORCPT ); Fri, 2 Sep 2022 09:03:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38392 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238401AbiIBNCo (ORCPT ); Fri, 2 Sep 2022 09:02:44 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFA8810B971; Fri, 2 Sep 2022 05:41:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7E556621AD; Fri, 2 Sep 2022 12:39:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6E1C3C433D6; Fri, 2 Sep 2022 12:39:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122388; bh=dxzaYWsKEC/iaUOjhi3s42CTv+Z/QYHQanu3QtWLlWs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tDEfYGI7VXWpN6dpYUvbRjKoz4+Yv5wJjv9f+ody21gcIoawHoGIXlba4hhPZyMye LAYOPpp02sxPiSEUdx0PQe7Csigp0DZNGXCcwWDcZH2PvcdoFBX6jaTrKFoM/40153 6SAOJIn8JKPrszKT+UM5bFnyBOaa7b+SdyNldNO0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Foster , "Darrick J. Wong" , Dave Chinner , Amir Goldstein Subject: [PATCH 5.10 31/37] xfs: remove infinite loop when reserving free block pool Date: Fri, 2 Sep 2022 14:19:53 +0200 Message-Id: <20220902121400.150139481@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Darrick J. Wong commit 15f04fdc75aaaa1cccb0b8b3af1be290e118a7bc upstream. [Added wrapper xfs_fdblocks_unavailable() for 5.10.y backport] Infinite loops in kernel code are scary. Calls to xfs_reserve_blocks should be rare (people should just use the defaults!) so we really don't need to try so hard. Simplify the logic here by removing the infinite loop. Cc: Brian Foster Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_fsops.c | 52 +++++++++++++++++++++---------------------------= ---- fs/xfs/xfs_mount.h | 8 ++++++++ 2 files changed, 29 insertions(+), 31 deletions(-) --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -376,46 +376,36 @@ xfs_reserve_blocks( * If the request is larger than the current reservation, reserve the * blocks before we update the reserve counters. Sample m_fdblocks and * perform a partial reservation if the request exceeds free space. + * + * The code below estimates how many blocks it can request from + * fdblocks to stash in the reserve pool. This is a classic TOCTOU + * race since fdblocks updates are not always coordinated via + * m_sb_lock. */ - error =3D -ENOSPC; - do { - free =3D percpu_counter_sum(&mp->m_fdblocks) - - mp->m_alloc_set_aside; - if (free <=3D 0) - break; - - delta =3D request - mp->m_resblks; - lcounter =3D free - delta; - if (lcounter < 0) - /* We can't satisfy the request, just get what we can */ - fdblks_delta =3D free; - else - fdblks_delta =3D delta; - + free =3D percpu_counter_sum(&mp->m_fdblocks) - + xfs_fdblocks_unavailable(mp); + delta =3D request - mp->m_resblks; + if (delta > 0 && free > 0) { /* * We'll either succeed in getting space from the free block - * count or we'll get an ENOSPC. If we get a ENOSPC, it means - * things changed while we were calculating fdblks_delta and so - * we should try again to see if there is anything left to - * reserve. - * - * Don't set the reserved flag here - we don't want to reserve - * the extra reserve blocks from the reserve..... + * count or we'll get an ENOSPC. Don't set the reserved flag + * here - we don't want to reserve the extra reserve blocks + * from the reserve. */ + fdblks_delta =3D min(free, delta); spin_unlock(&mp->m_sb_lock); error =3D xfs_mod_fdblocks(mp, -fdblks_delta, 0); spin_lock(&mp->m_sb_lock); - } while (error =3D=3D -ENOSPC); =20 - /* - * Update the reserve counters if blocks have been successfully - * allocated. - */ - if (!error && fdblks_delta) { - mp->m_resblks +=3D fdblks_delta; - mp->m_resblks_avail +=3D fdblks_delta; + /* + * Update the reserve counters if blocks have been successfully + * allocated. + */ + if (!error) { + mp->m_resblks +=3D fdblks_delta; + mp->m_resblks_avail +=3D fdblks_delta; + } } - out: if (outval) { outval->resblks =3D mp->m_resblks; --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -406,6 +406,14 @@ extern int xfs_initialize_perag(xfs_moun xfs_agnumber_t *maxagi); extern void xfs_unmountfs(xfs_mount_t *); =20 +/* Accessor added for 5.10.y backport */ +static inline uint64_t +xfs_fdblocks_unavailable( + struct xfs_mount *mp) +{ + return mp->m_alloc_set_aside; +} + extern int xfs_mod_fdblocks(struct xfs_mount *mp, int64_t delta, bool reserved); extern int xfs_mod_frextents(struct xfs_mount *mp, int64_t delta); From nobody Fri Apr 10 10:51:46 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 6E9C6C54EE9 for ; Fri, 2 Sep 2022 13:03:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238668AbiIBNDW (ORCPT ); Fri, 2 Sep 2022 09:03:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238419AbiIBNCp (ORCPT ); Fri, 2 Sep 2022 09:02:45 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFB2ED34E9; Fri, 2 Sep 2022 05:41:34 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 33705B829FB; Fri, 2 Sep 2022 12:39:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8CBA1C433C1; Fri, 2 Sep 2022 12:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122392; bh=6hLifgpSQoFJmNrN2OD//Blc0nqMW0j+eEoAYhRhqtA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=x9e4QTCMzTBaojJq7t5i/aQgMbq7COHAMxJssIU40uGZb6NaUZLRZxvNpnnr4CWVY SU5QJWCnXZMAZ4EJQDpQRiZ2a0aqfincZNHM1WLXRvAA4OnK8XPjt11hdTmPRkmSlD tJrbAfyl3HMPIBuXcanRq0qOUFSvJnk8hYSKwj2E= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Darrick J. Wong" , Dave Chinner , Amir Goldstein Subject: [PATCH 5.10 32/37] xfs: always succeed at setting the reserve pool size Date: Fri, 2 Sep 2022 14:19:54 +0200 Message-Id: <20220902121400.180514184@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: "Darrick J. Wong" commit 0baa2657dc4d79202148be79a3dc36c35f425060 upstream. Nowadays, xfs_mod_fdblocks will always choose to fill the reserve pool with freed blocks before adding to fdblocks. Therefore, we can change the behavior of xfs_reserve_blocks slightly -- setting the target size of the pool should always succeed, since a deficiency will eventually be made up as blocks get freed. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_fsops.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -380,11 +380,14 @@ xfs_reserve_blocks( * The code below estimates how many blocks it can request from * fdblocks to stash in the reserve pool. This is a classic TOCTOU * race since fdblocks updates are not always coordinated via - * m_sb_lock. + * m_sb_lock. Set the reserve size even if there's not enough free + * space to fill it because mod_fdblocks will refill an undersized + * reserve when it can. */ free =3D percpu_counter_sum(&mp->m_fdblocks) - xfs_fdblocks_unavailable(mp); delta =3D request - mp->m_resblks; + mp->m_resblks =3D request; if (delta > 0 && free > 0) { /* * We'll either succeed in getting space from the free block @@ -401,10 +404,8 @@ xfs_reserve_blocks( * Update the reserve counters if blocks have been successfully * allocated. */ - if (!error) { - mp->m_resblks +=3D fdblks_delta; + if (!error) mp->m_resblks_avail +=3D fdblks_delta; - } } out: if (outval) { From nobody Fri Apr 10 10:51:46 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 F1FE7C54EE9 for ; Fri, 2 Sep 2022 13:00:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238488AbiIBNAV (ORCPT ); Fri, 2 Sep 2022 09:00:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37824 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238552AbiIBM7C (ORCPT ); Fri, 2 Sep 2022 08:59:02 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 345765EDCD; Fri, 2 Sep 2022 05:40:22 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 6A8E3B82A94; Fri, 2 Sep 2022 12:39:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A4327C43470; Fri, 2 Sep 2022 12:39:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122395; bh=I8lkaMFzQUWXn3VkE2HN1MPqneA7HYh09OkxjTKmFqI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TEv69qIpIL4BLlSM2kRStbC0PQit3YTdBIgEJExXvJa3L4A2F2nRYEYuXVATxn12Y 0cgdYCyzLDpO9BJUD4966CPE4RbuPi6Z4mcAtD+tP4b0dw+8LKlREcVuGpybsqvBjl qlRML+7vdAQfwAwVzpaQ+JC6kDUPygNrX8ZVpCns= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Darrick J. Wong" , Dave Chinner , Amir Goldstein Subject: [PATCH 5.10 33/37] xfs: fix overfilling of reserve pool Date: Fri, 2 Sep 2022 14:19:55 +0200 Message-Id: <20220902121400.210546576@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: "Darrick J. Wong" commit 82be38bcf8a2e056b4c99ce79a3827fa743df6ec upstream. Due to cycling of m_sb_lock, it's possible for multiple callers of xfs_reserve_blocks to race at changing the pool size, subtracting blocks from fdblocks, and actually putting it in the pool. The result of all this is that we can overfill the reserve pool to hilarious levels. xfs_mod_fdblocks, when called with a positive value, already knows how to take freed blocks and either fill the reserve until it's full, or put them in fdblocks. Use that instead of setting m_resblks_avail directly. Signed-off-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_fsops.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) --- a/fs/xfs/xfs_fsops.c +++ b/fs/xfs/xfs_fsops.c @@ -394,18 +394,17 @@ xfs_reserve_blocks( * count or we'll get an ENOSPC. Don't set the reserved flag * here - we don't want to reserve the extra reserve blocks * from the reserve. + * + * The desired reserve size can change after we drop the lock. + * Use mod_fdblocks to put the space into the reserve or into + * fdblocks as appropriate. */ fdblks_delta =3D min(free, delta); spin_unlock(&mp->m_sb_lock); error =3D xfs_mod_fdblocks(mp, -fdblks_delta, 0); - spin_lock(&mp->m_sb_lock); - - /* - * Update the reserve counters if blocks have been successfully - * allocated. - */ if (!error) - mp->m_resblks_avail +=3D fdblks_delta; + xfs_mod_fdblocks(mp, fdblks_delta, 0); + spin_lock(&mp->m_sb_lock); } out: if (outval) { From nobody Fri Apr 10 10:51:46 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 DE1F0ECAAD5 for ; Fri, 2 Sep 2022 13:03:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238584AbiIBNDJ (ORCPT ); Fri, 2 Sep 2022 09:03:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52074 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238632AbiIBNCg (ORCPT ); Fri, 2 Sep 2022 09:02:36 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8DEE10D4F8; Fri, 2 Sep 2022 05:41:40 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id D79DC620C5; Fri, 2 Sep 2022 12:39:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF78AC433B5; Fri, 2 Sep 2022 12:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122398; bh=WYQUAaHzuh1gTk7tpo20isuFPFLINoLlLgreSnsWMtI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BGqdMLdbkFsAp2lNQEY4ppD/yNkcllquA0qNw4FdF5wZG4141toZxiJvD24hWOjFb yauxSz0xbq2vtxouYDx4L9taZXCMRRwbJqUUaRt3njJsW8FrtDuD/mWkXr1obPYdpx PEM2DYu//VlLyAyfw1ynFGGRQktIjsM+fIaxa+T0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Brian Foster , "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , Amir Goldstein Subject: [PATCH 5.10 34/37] xfs: fix soft lockup via spinning in filestream ag selection loop Date: Fri, 2 Sep 2022 14:19:56 +0200 Message-Id: <20220902121400.239846375@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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 Foster commit f650df7171b882dca737ddbbeb414100b31f16af upstream. The filestream AG selection loop uses pagf data to aid in AG selection, which depends on pagf initialization. If the in-core structure is not initialized, the caller invokes the AGF read path to do so and carries on. If another task enters the loop and finds a pagf init already in progress, the AGF read returns -EAGAIN and the task continues the loop. This does not increment the current ag index, however, which means the task spins on the current AGF buffer until unlocked. If the AGF read I/O submitted by the initial task happens to be delayed for whatever reason, this results in soft lockup warnings via the spinning task. This is reproduced by xfs/170. To avoid this problem, fix the AGF trylock failure path to properly iterate to the next AG. If a task iterates all AGs without making progress, the trylock behavior is dropped in favor of blocking locks and thus a soft lockup is no longer possible. Fixes: f48e2df8a877ca1c ("xfs: make xfs_*read_agf return EAGAIN to ALLOC_FL= AG_TRYLOCK callers") Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Dave Chinner Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_filestream.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) --- a/fs/xfs/xfs_filestream.c +++ b/fs/xfs/xfs_filestream.c @@ -128,11 +128,12 @@ xfs_filestream_pick_ag( if (!pag->pagf_init) { err =3D xfs_alloc_pagf_init(mp, NULL, ag, trylock); if (err) { - xfs_perag_put(pag); - if (err !=3D -EAGAIN) + if (err !=3D -EAGAIN) { + xfs_perag_put(pag); return err; + } /* Couldn't lock the AGF, skip this AG. */ - continue; + goto next_ag; } } From nobody Fri Apr 10 10:51:46 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 8E8E4ECAAD5 for ; Fri, 2 Sep 2022 13:02:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238566AbiIBNCI (ORCPT ); Fri, 2 Sep 2022 09:02:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238402AbiIBM7w (ORCPT ); Fri, 2 Sep 2022 08:59:52 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6746FFC32D; Fri, 2 Sep 2022 05:40:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id D69E3B82AE0; Fri, 2 Sep 2022 12:40:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 184D4C433C1; Fri, 2 Sep 2022 12:40:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122404; bh=B3TWZtAIrgKyArLCCITDfgSyhqaG2UKQiJWQ25NpFcU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vL+h5qCV7nJP83IpSjfN3+aR5ss3V5R6vU9EK9RLzNpvablBJ0eEb137CAPQxRKpU KmlmvZ9aTsv3J5onjV1yLLgTaGEZFdXH7BaXVMRd/nfGiWm+fdtx0otza2uT6PcgIe Bz8PDPJj3Ln8C3rbmejVd0EwSzCah4O7kgr5UjaQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Eric Sandeen , "Darrick J. Wong" , Dave Chinner , Dave Chinner , Amir Goldstein Subject: [PATCH 5.10 35/37] xfs: revert "xfs: actually bump warning counts when we send warnings" Date: Fri, 2 Sep 2022 14:19:57 +0200 Message-Id: <20220902121400.268955285@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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 Sandeen commit bc37e4fb5cac2925b2e286b1f1d4fc2b519f7d92 upstream. This reverts commit 4b8628d57b725b32616965e66975fcdebe008fe7. XFS quota has had the concept of a "quota warning limit" since the earliest Irix implementation, but a mechanism for incrementing the warning counter was never implemented, as documented in the xfs_quota(8) man page. We do know from the historical archive that it was never incremented at runtime during quota reservation operations. With this commit, the warning counter quickly increments for every allocation attempt after the user has crossed a quote soft limit threshold, and this in turn transitions the user to hard quota failures, rendering soft quota thresholds and timers useless. This was reported as a regression by users. Because the intended behavior of this warning counter has never been understood or documented, and the result of this change is a regression in soft quota functionality, revert this commit to make soft quota limits and timers operable again. Fixes: 4b8628d57b72 ("xfs: actually bump warning counts when we send warnin= gs) Signed-off-by: Eric Sandeen Reviewed-by: Darrick J. Wong Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Amir Goldstein Acked-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- fs/xfs/xfs_trans_dquot.c | 1 - 1 file changed, 1 deletion(-) --- a/fs/xfs/xfs_trans_dquot.c +++ b/fs/xfs/xfs_trans_dquot.c @@ -615,7 +615,6 @@ xfs_dqresv_check( return QUOTA_NL_ISOFTLONGWARN; } =20 - res->warnings++; return QUOTA_NL_ISOFTWARN; } From nobody Fri Apr 10 10:51:46 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 3ECACC38145 for ; Fri, 2 Sep 2022 13:40:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236927AbiIBNkY (ORCPT ); Fri, 2 Sep 2022 09:40:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236846AbiIBNjs (ORCPT ); Fri, 2 Sep 2022 09:39:48 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40324F8FE7; Fri, 2 Sep 2022 06:17:30 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 512616220E; Fri, 2 Sep 2022 12:40:08 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42F54C433C1; Fri, 2 Sep 2022 12:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122407; bh=l55iIEOTa99MJyVj0bZkhMqp2quVOE9KQuUvpsRy65E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=y1Q925U9h01tRQO8xaxutTCu9bHx00BIk/aU7j9IXuEdHwtu5hmQTZ/oKq4Uzdenx AwOp7HtpOVzTgzfNIRY/CpR051ZWZ/ekoqnQQxs95TECkffacvCfEQ02j4A1yUJmd5 UPo9gAVG8wchLX622nor8kts5qSqxMKae5cpIXGM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, syzbot+5ea725c25d06fb9114c4@syzkaller.appspotmail.com, Zhengchao Shao , "David S. Miller" Subject: [PATCH 5.10 36/37] net/af_packet: check len when min_header_len equals to 0 Date: Fri, 2 Sep 2022 14:19:58 +0200 Message-Id: <20220902121400.298585305@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Zhengchao Shao commit dc633700f00f726e027846a318c5ffeb8deaaeda upstream. User can use AF_PACKET socket to send packets with the length of 0. When min_header_len equals to 0, packet_snd will call __dev_queue_xmit to send packets, and sock->type can be any type. Reported-by: syzbot+5ea725c25d06fb9114c4@syzkaller.appspotmail.com Fixes: fd1894224407 ("bpf: Don't redirect packets with invalid pkt_len") Signed-off-by: Zhengchao Shao 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: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/packet/af_packet.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/net/packet/af_packet.c +++ b/net/packet/af_packet.c @@ -2986,8 +2986,8 @@ static int packet_snd(struct socket *soc if (err) goto out_free; =20 - if (sock->type =3D=3D SOCK_RAW && - !dev_validate_header(dev, skb->data, len)) { + if ((sock->type =3D=3D SOCK_RAW && + !dev_validate_header(dev, skb->data, len)) || !skb->len) { err =3D -EINVAL; goto out_free; } From nobody Fri Apr 10 10:51:46 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 38671ECAAD5 for ; Fri, 2 Sep 2022 13:02:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238459AbiIBNCD (ORCPT ); Fri, 2 Sep 2022 09:02:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48836 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238398AbiIBM7w (ORCPT ); Fri, 2 Sep 2022 08:59:52 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 676D6FC32F; Fri, 2 Sep 2022 05:40:58 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 06693B82ADF; Fri, 2 Sep 2022 12:40:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 508D9C433D6; Fri, 2 Sep 2022 12:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1662122410; bh=qJtlZbyOTsV51PIP1uTB7gctPH/B6Gl+DB+pExHFlyw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cLcVk9RbfRpPHpATjxZ0FUVlW6m0JrenCE2v61mLeGb9n8ZMDZp0cNpYHFyoyWhSD Q2IzTVFp3LeRO9fzk3Bdyc1ADl/PMTqwVhWf34I9mW27Bd3OsU3tpekU87T4qG37rl dqzkXuQVPW/8pRGxqk6Cjit6OeZylF23AtjkG48U= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Denis V. Lunev" , Yang Yingliang , Nikolay Aleksandrov , "David S. Miller" Subject: [PATCH 5.10 37/37] net: neigh: dont call kfree_skb() under spin_lock_irqsave() Date: Fri, 2 Sep 2022 14:19:59 +0200 Message-Id: <20220902121400.327532774@linuxfoundation.org> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20220902121359.177846782@linuxfoundation.org> References: <20220902121359.177846782@linuxfoundation.org> User-Agent: quilt/0.67 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: Yang Yingliang commit d5485d9dd24e1d04e5509916515260186eb1455c upstream. It is not allowed to call kfree_skb() from hardware interrupt context or with interrupts being disabled. So add all skb to a tmp list, then free them after spin_unlock_irqrestore() at once. Fixes: 66ba215cb513 ("neigh: fix possible DoS due to net iface start/stop l= oop") Suggested-by: Denis V. Lunev Signed-off-by: Yang Yingliang Reviewed-by: Nikolay Aleksandrov 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: Pavel Machek (CIP) = =20 Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Sudip Mukherjee --- net/core/neighbour.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -282,21 +282,27 @@ static int neigh_del_timer(struct neighb =20 static void pneigh_queue_purge(struct sk_buff_head *list, struct net *net) { + struct sk_buff_head tmp; unsigned long flags; struct sk_buff *skb; =20 + skb_queue_head_init(&tmp); spin_lock_irqsave(&list->lock, flags); skb =3D skb_peek(list); while (skb !=3D NULL) { struct sk_buff *skb_next =3D skb_peek_next(skb, list); if (net =3D=3D NULL || net_eq(dev_net(skb->dev), net)) { __skb_unlink(skb, list); - dev_put(skb->dev); - kfree_skb(skb); + __skb_queue_tail(&tmp, skb); } skb =3D skb_next; } spin_unlock_irqrestore(&list->lock, flags); + + while ((skb =3D __skb_dequeue(&tmp))) { + dev_put(skb->dev); + kfree_skb(skb); + } } =20 static void neigh_flush_dev(struct neigh_table *tbl, struct net_device *de= v,