_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 Ilya, can you share any context for this patch? Do you have any evidence that `proba` can be negative? A discussion was just started about this patch on the zstd repo [0]. I'm happy to discuss this here or there, whichever is more convenient. But to my first pass inspection, this seems to be protecting an impossible situation. (Separately: if it could happen, the correct behavior would to catch it and return an error, not just skip it like this patch proposes.) Thanks, Felix [0] https://github.com/facebook/zstd/issues/4567 On 12/11/25 12:19 PM, Ilya Krutskih wrote: > 'rtbTable' may be underflowed because 'proba' is used without > checking for a non-negative as index of rtbTable[]. > > Add check: proba >= 0 > > Cc: stable@vger.kernel.org # v5.10+ > Fixes: e0c1b49f5b67 ("lib: zstd: Upgrade to latest upstream zstd version 1.4.10") > Signed-off-by: Ilya Krutskih > --- > lib/zstd/compress/fse_compress.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/lib/zstd/compress/fse_compress.c b/lib/zstd/compress/fse_compress.c > index 44a3c10becf2..6b83f8bc943a 100644 > --- a/lib/zstd/compress/fse_compress.c > +++ b/lib/zstd/compress/fse_compress.c > @@ -492,9 +492,10 @@ size_t FSE_normalizeCount (short* normalizedCounter, unsigned tableLog, > stillToDistribute--; > } else { > short proba = (short)((count[s]*step) >> scale); > - if (proba<8) { > - U64 restToBeat = vStep * rtbTable[proba]; > - proba += (count[s]*step) - ((U64)proba< restToBeat; > + if ((proba >= 0) && (proba < 8)) { > + U64 restToBeat = vStep * rtbTable[proba]; > + > + proba += (count[s]*step) - ((U64)proba< restToBeat; > } > if (proba > largestP) { largestP=proba; largest=s; } > normalizedCounter[s] = proba; From - Tue Jan 13 20:03:24 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id YKAMB4iXZmmNkhkAYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:05:44 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:05:44 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfji3-00000007X2L-22KA for hi@josie.lol; Tue, 13 Jan 2026 19:05:43 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 2E0AC3016DD5 for ; Tue, 13 Jan 2026 19:05:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8E79335771C; Tue, 13 Jan 2026 19:05:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="NkjJirpc" X-Original-To: io-uring@vger.kernel.org Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 80A053570D6; Tue, 13 Jan 2026 19:05:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768331141; cv=none; b=E4EvYGDUQstWU5F6Whpc+2jsLWScqFNVg0vaIWklLVnxV5ubVNV3zYJcWnTiodhp0zanKPX2ON+PI/7PoJlEVDXoV9ybN3orSA7iqeIhWc3huT7ZE+5L6tEx1yzk6cSQDVX7rc6u8FYIbemxP1NBi21F2sswrcYwoBrIsI30XN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768331141; c=relaxed/simple; bh=wu2ToQdgBhgHCk0SMRuUYKoigLiRakf77u0rPqPRCa8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=IPX3jXo6Y1NODrZzORlCw+gKhKkaWGukZifSEklM9xviDnB6Fo3HDNRkTdfM3kZb/tzsL8xjW2gh/qoSHQOvHEmRA5KMvOc81jIxrRlBdIHOEo9fEmLijCXzvwHqiaY22D1euUNcUqfPpl0p+EAy9UgFWjhD80oo4W1qqnqlmUs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=NkjJirpc; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=lPg+mldV0tHpP5Arkhs5w91g4oKcpmQv2d6ztcobjyo=; b=NkjJirpcLC9kdmGT5sTwA+Ed6l 20LRtJAF/cvV26OMlMIfhCEwSPSyzydcgaqVScsqee8TF2tki/94j8TuJFLLQIXoYuISAB7mYQQdr KsNxLoEEMqdox0dnSntl0BeazyM03C/D9sAdveMM01GNntrp2VDVkqfcn8Vq046Wd9Tu0ZuPlcOF7 D5kqyCaTxXJq/PKAaX/5J8aQR+/qmkKs/xt3HrJ32ti5timEzat9Cg9j6jXDYZyoAVg3Y3iNYbMUZ NucH8xBTWFhodWvKUl2a+Y/lNk6MhshrdRwmfaahrT4DCqD70Ofg9kvBRBkZSFe0R9ZwukpigHh5W R6Y+4RHw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99 #2 (Red Hat Linux)) id 1vfjjJ-0000000FTeo-2Kte; Tue, 13 Jan 2026 19:07:01 +0000 Date: Tue, 13 Jan 2026 19:07:01 +0000 From: Al Viro To: Mark Brown Cc: linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org, brauner@kernel.org, jack@suse.cz, mjguzik@gmail.com, paul@paul-moore.com, axboe@kernel.dk, audit@vger.kernel.org, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 15/59] struct filename: saner handling of long names Message-ID: <20260113190701.GO3634291@ZenIV> References: <20260108073803.425343-1-viro@zeniv.linux.org.uk> <20260108073803.425343-16-viro@zeniv.linux.org.uk> <20260113153953.GN3634291@ZenIV> Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260113153953.GN3634291@ZenIV> Sender: Al Viro X-DKIM: signer='linux.org.uk' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 5 On Tue, Jan 13, 2026 at 03:39:53PM +0000, Al Viro wrote: > On Tue, Jan 13, 2026 at 03:31:14PM +0000, Mark Brown wrote: > > > I'm seeing a regression in -next in the execveat kselftest which bisects > > to 2a0db5f7653b ("struct filename: saner handling of long names"). The > > test triggers two new failures with very long filenames for tests that > > previously succeeded: > > > > # # Failed to open length 4094 filename, errno=36 (File name too long) > > # # Invoke exec via root_dfd and relative filename > > # # child execveat() failed, rc=-1 errno=36 (File name too long) > > # # child 9501 exited with 36 neither 99 nor 99 > > # not ok 48 Check success of execveat(8, 'opt/kselftest/exec/x...yyyyyyyyyyyyyyyyyyyy', 0)... > > # # Failed to open length 4094 filename, errno=36 (File name too long) > > # # Invoke script via root_dfd and relative filename > > # # child execveat() failed, rc=-1 errno=36 (File name too long) > > # # child 9502 exited with 36 neither 127 nor 126 > > # not ok 49 Check success of execveat(8, 'opt/kselftest/exec/x...yyyyyyyyyyyyyyyyyyyy', 0)... > > Could you check if replacing (in include/linux/fs.h) > > #define EMBEDDED_NAME_MAX 192 - sizeof(struct __filename_head) > > with > > #define EMBEDDED_NAME_MAX (192 - sizeof(struct __filename_head)) > > is sufficient for fixing that reproducer? FWIW, an unpleasant surprise is that LTP apparently doesn't test that case anywhere - the effect of that braino is to lower the cutoff for name length by 48 characters and there's not a single test in there that would test that ;-/ chdir04 does check that name component is not too long, but that's a different codepath - it's individual filesystem's ->lookup() rejecting a component. Oh, well - not hard to add (to the same chdir04, for example)... From - Tue Jan 13 20:03:24 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id uHqLBdmaZmnjoxwAYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:19:53 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:19:53 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfjvk-000000088Oh-20hY for hi@josie.lol; Tue, 13 Jan 2026 19:19:53 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id DCD1B30A0F66 for ; Tue, 13 Jan 2026 19:15:40 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5423C364050; Tue, 13 Jan 2026 19:15:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="wVhY9iZL" X-Original-To: io-uring@vger.kernel.org Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BB933624AC; Tue, 13 Jan 2026 19:15:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768331740; cv=none; b=eJ58SGRr11jzNSW/K6vbD82jbJfW+GIhafiBmeDuIMRnL8TzyMPqKtnSmrsNRDHXLFmeZhAYhCEGBI3FqW80v4OPNKzdgsf1bli5Ag9ic3xg5JuGAYm/j0TUdB+uFGUD3Jl+ASDwrtFV9mokrWrcoTiyxwEI552q+FWLv93m9XE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768331740; c=relaxed/simple; bh=I6UITsJP9IZGg0x9KUYtzcKMszxjLObOfiJ3tDF6NAE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZncNi8YJEt5pXQ169o2eeIXvMWvIzmblt/YWc6qVHEn3TQYzA4VtNTeqjgW2JVzbweWru7PjXr1MMFnEOj4d3ZCEauwqMMhqmyDa191v8+E4nyX/reTYFV3kk3gvhOxEKVzIVZZWgKV6sPmhuGNquEHIoGEFUh7eA1xMywBLKmo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=wVhY9iZL; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=XgGrVDhdd2cjZ6Fq5+hoLI+F3LjOb87+IxBIMIOVNqM=; b=wVhY9iZLZqukol8KYcnVYSugOA MmnaSOcyoX/M+xamn/giGAbPACFWWXrO/LR3ee+FiElnq9yOUZ/Ih0q5hPJoFEyJzoQur/V2bvSUh VkjGMUdNU9WfdOJ6kbA3O7W+XtQg3isncUHGyOkjMBlf12Gkp0nG8W12phisXX0Zzp14R25Tp8cpd wJp04JhZC8Qh9iJAh9aj8VR8Fz3WG+f/hW18UfvauSjwV2Gjt1i4Z69MPOQ07Zw4u058s0FoqW5Kt jgVPjZQTJkDK7HEBoCtAgVFPT2wIeCVWT7cowHOM843E52KWJqntYihKnyvzuo30wed9l0Zg8pmHy zMMhgG7A==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.99 #2 (Red Hat Linux)) id 1vfjt0-0000000FUet-3QCS; Tue, 13 Jan 2026 19:17:03 +0000 Date: Tue, 13 Jan 2026 19:17:02 +0000 From: Al Viro To: Mark Brown Cc: linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org, brauner@kernel.org, jack@suse.cz, mjguzik@gmail.com, paul@paul-moore.com, axboe@kernel.dk, audit@vger.kernel.org, io-uring@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 15/59] struct filename: saner handling of long names Message-ID: <20260113191702.GP3634291@ZenIV> References: <20260108073803.425343-1-viro@zeniv.linux.org.uk> <20260108073803.425343-16-viro@zeniv.linux.org.uk> <20260113153953.GN3634291@ZenIV> <20260113190701.GO3634291@ZenIV> Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260113190701.GO3634291@ZenIV> Sender: Al Viro X-DKIM: signer='linux.org.uk' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linux.org.uk] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 5 On Tue, Jan 13, 2026 at 07:07:01PM +0000, Al Viro wrote: > FWIW, an unpleasant surprise is that LTP apparently doesn't test that > case anywhere - the effect of that braino is to lower the cutoff for > name length by 48 characters and there's not a single test in there > that would test that ;-/ > > chdir04 does check that name component is not too long, but that's > a different codepath - it's individual filesystem's ->lookup() rejecting > a component. > > Oh, well - not hard to add (to the same chdir04, for example)... Crude variant on top of https://github.com/linux-test-project/ltp #master: diff --git a/testcases/kernel/syscalls/chdir/chdir04.c b/testcases/kernel/syscalls/chdir/chdir04.c index 6e53b7fef..7e959e090 100644 --- a/testcases/kernel/syscalls/chdir/chdir04.c +++ b/testcases/kernel/syscalls/chdir/chdir04.c @@ -11,6 +11,8 @@ #include "tst_test.h" static char long_dir[] = "abcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyzabcdefghijklmnopqrstmnopqrstuvwxyz"; +static char long_path_4096[4096+1]; +static char long_path_4094[4094+1]; static char noexist_dir[] = "noexistdir"; static struct tcase { @@ -20,16 +22,26 @@ static struct tcase { {long_dir, ENAMETOOLONG}, {noexist_dir, ENOENT}, {0, EFAULT}, // bad_addr + {long_path_4096, ENAMETOOLONG}, + {long_path_4094, 0}, }; static void verify_chdir(unsigned int i) { - TST_EXP_FAIL(chdir(tcases[i].dir), tcases[i].exp_errno, "chdir()"); + if (tcases[i].exp_errno) + TST_EXP_FAIL(chdir(tcases[i].dir), tcases[i].exp_errno, "chdir()"); + else + TST_EXP_PASS(chdir(tcases[i].dir), "chdir()"); } static void setup(void) { tcases[2].dir = tst_get_bad_addr(NULL); + for (int i = 0; i < 4096; ) { + long_path_4096[i++] = '.'; + long_path_4096[i++] = '/'; + } + memcpy(long_path_4094, long_path_4096, 4094); } static struct tst_test test = { From - Tue Jan 13 20:03:24 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 8BBxOESbZmmiIRwAYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:21:40 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:21:41 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfjxU-00000008DHG-2Fic for hi@josie.lol; Tue, 13 Jan 2026 19:21:40 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id BBC2530C06E9 for ; Tue, 13 Jan 2026 19:16:12 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8910236C595; Tue, 13 Jan 2026 19:16:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="U9I1sV5q" X-Original-To: stable@vger.kernel.org Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A4BF4369982 for ; Tue, 13 Jan 2026 19:16:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768331765; cv=none; b=dSXmJWhkU7ByMy4SJuLJ29pAFg4qqszGlFKva0wtI91tzAGVppwTOuYF9Gn0BNn8XtdU8N66jng/WVwOs7HKhNRgPeqmWFi27YhTlvabN2rcwh0KLGPl9STswBC5bKNUcllZC7KgXfBvDTM5FAqU9eAbZKJiAWdadI74II2ntAs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768331765; c=relaxed/simple; bh=Z5urRHLHK7nLUana3bPqam/CMrPaNzlqkPx1+GvkixM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Ea7HyAadWNqL7EoMPHuOS4SV2cJKothXJ0yLHb8KmMK3N9ES8gn7RGkSIPBS577VFdut0HXK1hV6DdiOh/1k+CB5wJCzmhgSdHTHRtpCFXGviRjUPOMoOuQzgbFrk2VesggL52aUzEI8kjHG7yEjgdYSqI3dRastT3FEZWRb4l8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=U9I1sV5q; arc=none smtp.client-ip=209.85.208.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-3831b6abed6so5397861fa.1 for ; Tue, 13 Jan 2026 11:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768331761; x=1768936561; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kNWxc7urAc+WPUb7dtJ1KQJNNzOu7ZjngdMJAMiDVCE=; b=U9I1sV5qTsEO7dADG3acuoYUup2uwKdSiXBHrtAWFHyo7QUfAkAxoeqMMbDk8uZBQ4 +JBkB59hZ3gh7dfMrg7xmIexRV0utaInGglhJG1fz+gztTZGu2kd2jQEM0yePrQwtuiI 1BWzQbJqWco+IttK4jVTGYj0lnBLFt+KhoXhbeWOg8fSjz/mdCpp0i+CD1z81/RUEESj x1WOecDuQsp8zN7M1UyDWgCuizCx2BJrmm36PoXlLtmdLyiUl+418wJh2UW1xZAsxFfa tkYW+gHoOgJN9L7uNvqXaCxKXd9/qsurlsJt/mSOoNn893C5oJEgP8VT7KUeZIE5EQOc yCYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768331761; x=1768936561; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=kNWxc7urAc+WPUb7dtJ1KQJNNzOu7ZjngdMJAMiDVCE=; b=rTro633ipR4MZ1Nk0Rrr8CPEZJ7f3dDuGrMR1yLrIyIs+UwueoNl+MlBiKV1nVcRJv ahCr4JJRz5qq/fxNgDR3qDnAwMlVHC6ns7zCV4k9zFZVrFlGqAxB/D/FWpVN+Sh5s2AA ut+z2NSJPlwwTJYDqEpuu4SX0SO7nnFzaKSi+S31DCfAh+N5A4b73Cdnb01PzBcxrKwx dx8ChpKvMPTHHEGGhhlMkeXMAEJ8hHDcnfjKM5Vl90W7/x/VAN+cm5xBlAKr+5D+ct5z txKR68BShuG5V+nZi6yn5lmtwkggCIfGyFVwY4kadFjsu/HAUOrNZVcdJkCmztF2gxcN KqgQ== X-Forwarded-Encrypted: i=1; AJvYcCVpEx+Ag9aCie5E9i46NCXcIbXDbkis6A2aNhg6W7hXSRAIoAb014rZkiy9PtFkKyGtns70SZE=@vger.kernel.org X-Gm-Message-State: AOJu0YxwsYU158BvxkNLTAO6Fac16KPP6XVdjv4lXMLQL8nehn78fhcL 8e7AK5OPLvJOLbbboGJlhBrUjdD+zwZ/8fQrnNq9r4PRYpOPed+yyxpt X-Gm-Gg: AY/fxX4glcdUqzuj8wbIoe57b5xfnSDJkNbuEeyGK3RKzIkyBTWmLBJW0R7Mlv+3FR7 uAsld1ekvGqCAAZmw0tV4ipRoPLJIWSVU1Q9aR9G45aeSjnhDMspg/5zMGqrq/sOJ/9ZMD8Gpeq 2VYvTwuSOg5kBASOZfka6MpmXENjHTKHWH9L1JgCVEl+LmosL4UetDILVPEKQdLlv6n+LuVuoU9 Gt3dXsakNUlvF0gzbs1t7OHsxD1JIGocGEFrsAUR9xtSVb1sfMo663kTr/AlqWzwNNT2a4sB6Jz Wy66TdHB17g+xLdE/bpfUd+/Ovd+Z/iQlJTzgxiPZgx/jNjItFT66fDEmOcIjFNsM+8ETJLSb9r isifjGkL0g2Wc3HzMUJZc7TTh4XbibzgGLJIfTalQcjW0ihN/1armXKft8xnvFLDxVx+PJ/QqFs YV3Lwl12X/4sJGNQeawwZrvTyTH8v/GEq+sg== X-Google-Smtp-Source: AGHT+IEWr6drC+zpyxpYdRsl+WTpwPbMxB4PxC6CXmyNXqXAc6ksEPPqWnLy4U69o0ywwEWEZ9DZXw== X-Received: by 2002:a05:6512:3b25:b0:59b:7291:9cd8 with SMTP id 2adb3069b0e04-59b72919e55mr4212248e87.7.1768331760373; Tue, 13 Jan 2026 11:16:00 -0800 (PST) Received: from dellarbn.yandex.net ([80.93.240.68]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-59b6a97e94csm5568773e87.91.2026.01.13.11.15.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jan 2026 11:15:59 -0800 (PST) From: Andrey Ryabinin To: Andrew Morton Cc: =?UTF-8?q?Maciej=20=C5=BBenczykowski?= , Maciej Wieczor-Retman , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com, Uladzislau Rezki , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrey Ryabinin , joonki.min@samsung-slsi.corp-partner.google.com, stable@vger.kernel.org Subject: [PATCH 1/2] mm/kasan: Fix KASAN poisoning in vrealloc() Date: Tue, 13 Jan 2026 20:15:15 +0100 Message-ID: <20260113191516.31015-1-ryabinin.a.a@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: References: Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='gmail.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [ryabinin.a.a[at]gmail.com] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 A KASAN warning can be triggered when vrealloc() changes the requested size to a value that is not aligned to KASAN_GRANULE_SIZE. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1 at mm/kasan/shadow.c:174 kasan_unpoison+0x40/0x48 ... pc : kasan_unpoison+0x40/0x48 lr : __kasan_unpoison_vmalloc+0x40/0x68 Call trace: kasan_unpoison+0x40/0x48 (P) vrealloc_node_align_noprof+0x200/0x320 bpf_patch_insn_data+0x90/0x2f0 convert_ctx_accesses+0x8c0/0x1158 bpf_check+0x1488/0x1900 bpf_prog_load+0xd20/0x1258 __sys_bpf+0x96c/0xdf0 __arm64_sys_bpf+0x50/0xa0 invoke_syscall+0x90/0x160 Introduce a dedicated kasan_vrealloc() helper that centralizes KASAN handling for vmalloc reallocations. The helper accounts for KASAN granule alignment when growing or shrinking an allocation and ensures that partial granules are handled correctly. Use this helper from vrealloc_node_align_noprof() to fix poisoning logic. Reported-by: Maciej Żenczykowski Reported-by: Closes: https://lkml.kernel.org/r/CANP3RGeuRW53vukDy7WDO3FiVgu34-xVJYkfpm08oLO3odYFrA@mail.gmail.com Fixes: d699440f58ce ("mm: fix vrealloc()'s KASAN poisoning logic") Cc: stable@vger.kernel.org Signed-off-by: Andrey Ryabinin --- include/linux/kasan.h | 6 ++++++ mm/kasan/shadow.c | 24 ++++++++++++++++++++++++ mm/vmalloc.c | 7 ++----- 3 files changed, 32 insertions(+), 5 deletions(-) diff --git a/include/linux/kasan.h b/include/linux/kasan.h index 9c6ac4b62eb9..ff27712dd3c8 100644 --- a/include/linux/kasan.h +++ b/include/linux/kasan.h @@ -641,6 +641,9 @@ kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, __kasan_unpoison_vmap_areas(vms, nr_vms, flags); } +void kasan_vrealloc(const void *start, unsigned long old_size, + unsigned long new_size); + #else /* CONFIG_KASAN_VMALLOC */ static inline void kasan_populate_early_vm_area_shadow(void *start, @@ -670,6 +673,9 @@ kasan_unpoison_vmap_areas(struct vm_struct **vms, int nr_vms, kasan_vmalloc_flags_t flags) { } +static inline void kasan_vrealloc(const void *start, unsigned long old_size, + unsigned long new_size) { } + #endif /* CONFIG_KASAN_VMALLOC */ #if (defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KASAN_SW_TAGS)) && \ diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c index 32fbdf759ea2..e9b6b2d8e651 100644 --- a/mm/kasan/shadow.c +++ b/mm/kasan/shadow.c @@ -651,6 +651,30 @@ void __kasan_poison_vmalloc(const void *start, unsigned long size) kasan_poison(start, size, KASAN_VMALLOC_INVALID, false); } +void kasan_vrealloc(const void *addr, unsigned long old_size, + unsigned long new_size) +{ + if (!kasan_enabled()) + return; + + if (new_size < old_size) { + kasan_poison_last_granule(addr, new_size); + + new_size = round_up(new_size, KASAN_GRANULE_SIZE); + old_size = round_up(old_size, KASAN_GRANULE_SIZE); + if (new_size < old_size) + __kasan_poison_vmalloc(addr + new_size, + old_size - new_size); + } else if (new_size > old_size) { + old_size = round_down(old_size, KASAN_GRANULE_SIZE); + __kasan_unpoison_vmalloc(addr + old_size, + new_size - old_size, + KASAN_VMALLOC_PROT_NORMAL | + KASAN_VMALLOC_VM_ALLOC | + KASAN_VMALLOC_KEEP_TAG); + } +} + #else /* CONFIG_KASAN_VMALLOC */ int kasan_alloc_module_shadow(void *addr, size_t size, gfp_t gfp_mask) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 41dd01e8430c..2536d34df058 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -4322,7 +4322,7 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align if (want_init_on_free() || want_init_on_alloc(flags)) memset((void *)p + size, 0, old_size - size); vm->requested_size = size; - kasan_poison_vmalloc(p + size, old_size - size); + kasan_vrealloc(p, old_size, size); return (void *)p; } @@ -4330,16 +4330,13 @@ void *vrealloc_node_align_noprof(const void *p, size_t size, unsigned long align * We already have the bytes available in the allocation; use them. */ if (size <= alloced_size) { - kasan_unpoison_vmalloc(p + old_size, size - old_size, - KASAN_VMALLOC_PROT_NORMAL | - KASAN_VMALLOC_VM_ALLOC | - KASAN_VMALLOC_KEEP_TAG); /* * No need to zero memory here, as unused memory will have * already been zeroed at initial allocation time or during * realloc shrink time. */ vm->requested_size = size; + kasan_vrealloc(p, old_size, size); return (void *)p; } -- 2.52.0 From - Tue Jan 13 20:03:24 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id GBpHHVifZmmiIRwAYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:39:04 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:39:04 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfkEJ-00000008zyp-3MO6 for hi@josie.lol; Tue, 13 Jan 2026 19:39:04 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id DB5BF302BF53 for ; Tue, 13 Jan 2026 19:39:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0E13B36C593; Tue, 13 Jan 2026 19:39:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="J0Vy1xbO" X-Original-To: stable@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8508736AB65; Tue, 13 Jan 2026 19:39:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333141; cv=none; b=JBFu4RWoeRAaWMgf2rqoJnVu8iLg945gMXLx4RNh6aEKxid3229icKGsMYZB9s32gcej1WfzAv6RteRiby1GhxvfQMo6vioM+2kMsFEqAIXepK0pP6zfIo2m0KSkhsOYAQirjCJslRW/s551DneUt62mTLueEmz2mJPRNBRj5Kk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333141; c=relaxed/simple; bh=cQBJ2VxWuFTxQUDOTo6qtyEYlivydYoNMrH+/6fqZRo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o/92oHemBQKARPGywudauypWppvvF4ERarA1eXPKEUE8wrB9Zb1Py5DfwA4ymJiL42njaE3fVTD2puQEBpP57I0E/4eVt+4QXH12jVSHn3RSbzIcSG6O4QyMkSH2LDYiP/KeBv5Gn6ntxEyBbfnPjp2oxcWSxnaffucjvAQM4+A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=J0Vy1xbO; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768333140; x=1799869140; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=cQBJ2VxWuFTxQUDOTo6qtyEYlivydYoNMrH+/6fqZRo=; b=J0Vy1xbO0Mw7OSJ9f7VU+PF3C4aBt/66TSUh+UIyb5hOTWh75IltLM46 Euk9SLzr3VnlA0OyN0CKpK4bQ+zsHgJcKIirHYs23sCxrBEtuAG0g8lpW 2SmkAxn1dgBCkYI6uSBfzujRJ2BDjZ6lqbXB1jMKWVThHfxX7sgayc1v0 NIAIepiIChLn4/GYHbNgLsZ6NrXM+4ac3m8RjTpAA5A13X+ZMHk7245aJ WHDO6qVmTquVFccBZ4UmLaTUxuYKW3pkxvGkcOQRRwe/TLMnFishlGVUs 7t3JQHhofxKTVAgzYq0aDCgis0U2aA4nKfd1OHBPbIrJTUXwmEAHDROwN w==; X-CSE-ConnectionGUID: eN5uY+DaTGin4ScuteoUPQ== X-CSE-MsgGUID: KDH6pDTOSJW2SjEIiIMF2A== X-IronPort-AV: E=McAfee;i="6800,10657,11670"; a="80993531" X-IronPort-AV: E=Sophos;i="6.21,222,1763452800"; d="scan'208";a="80993531" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2026 11:39:00 -0800 X-CSE-ConnectionGUID: fuUb7S8FSd+1isAwjaWYGQ== X-CSE-MsgGUID: XmFmkVOGTBSszu2DWXYeFg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,222,1763452800"; d="scan'208";a="208629085" Received: from kasadzad-mobl.ger.corp.intel.com (HELO soc-5CG4396XFB.clients.intel.com) ([10.94.252.226]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2026 11:38:58 -0800 From: Dawid Osuchowski To: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, Jakub Staniszewski , stable@vger.kernel.org, Dawid Osuchowski , Aleksandr Loktionov , Przemek Kitszel Subject: [PATCH iwl-net 2/2] ice: fix retry for AQ command 0x06EE Date: Tue, 13 Jan 2026 20:38:17 +0100 Message-ID: <20260113193817.582-3-dawid.osuchowski@linux.intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260113193817.582-1-dawid.osuchowski@linux.intel.com> References: <20260113193817.582-1-dawid.osuchowski@linux.intel.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: 8bit X-DKIM: signer='intel.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-DKIM: signer='@intel.com' status='pass' reason='' X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: intel.com] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 5 From: Jakub Staniszewski Executing ethtool -m can fail reporting a netlink I/O error while firmware link management holds the i2c bus used to communicate with the module. According to Intel(R) Ethernet Controller E810 Datasheet Rev 2.8 [1] Section 3.3.10.4 Read/Write SFF EEPROM (0x06EE) request should to be retried upon receiving EBUSY from firmware. Commit e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") implemented it only for part of ice_get_module_eeprom(), leaving all other calls to ice_aq_sff_eeprom() vulnerable to returning early on getting EBUSY without retrying. Remove the retry loop from ice_get_module_eeprom() and add Admin Queue (AQ) command with opcode 0x06EE to the list of commands that should be retried on receiving EBUSY from firmware. Cc: stable@vger.kernel.org Fixes: e9c9692c8a81 ("ice: Reimplement module reads used by ethtool") Signed-off-by: Jakub Staniszewski Co-developed-by: Dawid Osuchowski Signed-off-by: Dawid Osuchowski Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel Link: https://www.intel.com/content/www/us/en/content-details/613875/intel-ethernet-controller-e810-datasheet.html [1] --- drivers/net/ethernet/intel/ice/ice_common.c | 1 + drivers/net/ethernet/intel/ice/ice_ethtool.c | 35 ++++++++------------ 2 files changed, 15 insertions(+), 21 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c index aab00c44e9b2..26eb8e05498b 100644 --- a/drivers/net/ethernet/intel/ice/ice_common.c +++ b/drivers/net/ethernet/intel/ice/ice_common.c @@ -1854,6 +1854,7 @@ static bool ice_should_retry_sq_send_cmd(u16 opcode) case ice_aqc_opc_lldp_stop: case ice_aqc_opc_lldp_start: case ice_aqc_opc_lldp_filter_ctrl: + case ice_aqc_opc_sff_eeprom: return true; } diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c index 3565a5d96c6d..478876908db1 100644 --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c @@ -4496,7 +4496,7 @@ ice_get_module_eeprom(struct net_device *netdev, u8 addr = ICE_I2C_EEPROM_DEV_ADDR; struct ice_hw *hw = &pf->hw; bool is_sfp = false; - unsigned int i, j; + unsigned int i; u16 offset = 0; u8 page = 0; int status; @@ -4538,26 +4538,19 @@ ice_get_module_eeprom(struct net_device *netdev, if (page == 0 || !(data[0x2] & 0x4)) { u32 copy_len; - /* If i2c bus is busy due to slow page change or - * link management access, call can fail. This is normal. - * So we retry this a few times. - */ - for (j = 0; j < 4; j++) { - status = ice_aq_sff_eeprom(hw, 0, addr, offset, page, - !is_sfp, value, - SFF_READ_BLOCK_SIZE, - 0, NULL); - netdev_dbg(netdev, "SFF %02X %02X %02X %X = %02X%02X%02X%02X.%02X%02X%02X%02X (%X)\n", - addr, offset, page, is_sfp, - value[0], value[1], value[2], value[3], - value[4], value[5], value[6], value[7], - status); - if (status) { - usleep_range(1500, 2500); - memset(value, 0, SFF_READ_BLOCK_SIZE); - continue; - } - break; + status = ice_aq_sff_eeprom(hw, 0, addr, offset, page, + !is_sfp, value, + SFF_READ_BLOCK_SIZE, + 0, NULL); + netdev_dbg(netdev, "SFF %02X %02X %02X %X = %02X%02X%02X%02X.%02X%02X%02X%02X (%pe)\n", + addr, offset, page, is_sfp, + value[0], value[1], value[2], value[3], + value[4], value[5], value[6], value[7], + ERR_PTR(status)); + if (status) { + netdev_err(netdev, "%s: error reading module EEPROM: status %pe\n", + __func__, ERR_PTR(status)); + return status; } /* Make sure we have enough room for the new block */ -- 2.51.0 From - Tue Jan 13 20:03:24 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id OEpdL1+fZmlSXh0AYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:39:11 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:39:11 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfkER-0000000909F-1Cz2 for hi@josie.lol; Tue, 13 Jan 2026 19:39:11 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id DBFF53018D79 for ; Tue, 13 Jan 2026 19:38:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ADDB935E527; Tue, 13 Jan 2026 19:38:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Lx3W1//z" X-Original-To: stable@vger.kernel.org Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DDED30EF88; Tue, 13 Jan 2026 19:38:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.10 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333126; cv=none; b=mGfhYyu5A0dAS4+RLg5E+FWCFi7JFEYXm/YC3NtghbgG01YMrwbqrn5GA7wT6z7jIfF/NypBYQQL4DMom63mo7WdVuTz6g1QQn7jMPAenJ8+NO4g+5q1Jv5QTK541HvA5lGOrbY3+lzfCsLW5OdKPurzrasPNf/MFCRYsRVBohM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333126; c=relaxed/simple; bh=jEtf1ydCCX46cmNa/3QR3V9ozblq9GLYYAgW3YJ8E94=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YCFLAzcJDMVkCkPJX8bFxjmZ8s+mUpup9tql/D3eFC4wP4EswqI4Zw6s9CaNGjY9Q2YCQm8++Np9KxpGOgwgF6ld8LrVkequgdlR5yFBBMweQpoLfL5GHq9KTnmOlOxb5NQ7bdUAgk8wYXbbyst8I5NtfKT5r0G7hwJ1jwk4L3o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Lx3W1//z; arc=none smtp.client-ip=192.198.163.10 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768333125; x=1799869125; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=jEtf1ydCCX46cmNa/3QR3V9ozblq9GLYYAgW3YJ8E94=; b=Lx3W1//zzCuBGGKILF0Bh9j07xaFr4b6bzuErKACTUSs/RRo1+j2BIDj aFjshU8NZa0LTGpRe/7yGw84RmgB5HpvHe+QBo3x2FQTlrGlpH3sLqrDd ziQcuIILx0r7KPhKY5fXWPl9q4LLm56CSippg6pM3wwYQDlL53kzZaSWy a2VDtSVFig64t0ez1A0OzzCBNEASVPyC9TVGnzDR+39oanUdsw6OxyGAn L6mgyOYNNgyI08qn+4F8IPIty201RiZw4xEXymYFbW7yk3Wwly3XDdZeC kx02ON9Rn+AFgmahkOOufNoY3rItiyH+c1JVBMzG7kAiNWNrUu7K5jGM8 w==; X-CSE-ConnectionGUID: g9+5Wro6Rp+DvId/Uxnu0g== X-CSE-MsgGUID: t2Un/i6aQ4mgCQLDOeZB7g== X-IronPort-AV: E=McAfee;i="6800,10657,11670"; a="80993504" X-IronPort-AV: E=Sophos;i="6.21,222,1763452800"; d="scan'208";a="80993504" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2026 11:38:44 -0800 X-CSE-ConnectionGUID: Wk4Q4ESsRWaYfdnVw0F4dQ== X-CSE-MsgGUID: kznnjLrFS9ymw2PuD78+/w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,222,1763452800"; d="scan'208";a="208629040" Received: from kasadzad-mobl.ger.corp.intel.com (HELO soc-5CG4396XFB.clients.intel.com) ([10.94.252.226]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jan 2026 11:38:42 -0800 From: Dawid Osuchowski To: intel-wired-lan@lists.osuosl.org Cc: netdev@vger.kernel.org, Jakub Staniszewski , Michal Schmidt , stable@vger.kernel.org, Dawid Osuchowski , Aleksandr Loktionov , Przemek Kitszel Subject: [PATCH iwl-net 1/2] ice: reintroduce retry mechanism for indirect AQ Date: Tue, 13 Jan 2026 20:38:16 +0100 Message-ID: <20260113193817.582-2-dawid.osuchowski@linux.intel.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260113193817.582-1-dawid.osuchowski@linux.intel.com> References: <20260113193817.582-1-dawid.osuchowski@linux.intel.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Organization: Intel Technology Poland sp. z o.o. - ul. Slowackiego 173, 80-298 Gdansk - KRS 101882 - NIP 957-07-52-316 Content-Transfer-Encoding: 8bit X-DKIM: signer='intel.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-DKIM: signer='@intel.com' status='pass' reason='' X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: intel.com] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 5 From: Jakub Staniszewski Add retry mechanism for indirect Admin Queue (AQ) commands. To do so we need to keep the command buffer. This technically reverts commit 43a630e37e25 ("ice: remove unused buffer copy code in ice_sq_send_cmd_retry()"), but combines it with a fix in the logic by using a kmemdup() call, making it more robust and less likely to break in the future due to programmer error. Cc: Michal Schmidt Cc: stable@vger.kernel.org Fixes: 3056df93f7a8 ("ice: Re-send some AQ commands, as result of EBUSY AQ error") Signed-off-by: Jakub Staniszewski Co-developed-by: Dawid Osuchowski Signed-off-by: Dawid Osuchowski Reviewed-by: Aleksandr Loktionov Reviewed-by: Przemek Kitszel --- Ccing Michal, given they are the author of the "reverted" commit. drivers/net/ethernet/intel/ice/ice_common.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c index a400bf4f239a..aab00c44e9b2 100644 --- a/drivers/net/ethernet/intel/ice/ice_common.c +++ b/drivers/net/ethernet/intel/ice/ice_common.c @@ -1879,34 +1879,40 @@ ice_sq_send_cmd_retry(struct ice_hw *hw, struct ice_ctl_q_info *cq, { struct libie_aq_desc desc_cpy; bool is_cmd_for_retry; + u8 *buf_cpy = NULL; u8 idx = 0; u16 opcode; int status; opcode = le16_to_cpu(desc->opcode); is_cmd_for_retry = ice_should_retry_sq_send_cmd(opcode); memset(&desc_cpy, 0, sizeof(desc_cpy)); if (is_cmd_for_retry) { - /* All retryable cmds are direct, without buf. */ - WARN_ON(buf); + if (buf) { + buf_cpy = kmemdup(buf, buf_size, GFP_KERNEL); + if (!buf_cpy) + return -ENOMEM; + } memcpy(&desc_cpy, desc, sizeof(desc_cpy)); } do { status = ice_sq_send_cmd(hw, cq, desc, buf, buf_size, cd); if (!is_cmd_for_retry || !status || hw->adminq.sq_last_status != LIBIE_AQ_RC_EBUSY) break; + if (buf_cpy) + memcpy(buf, buf_cpy, buf_size); memcpy(desc, &desc_cpy, sizeof(desc_cpy)); - msleep(ICE_SQ_SEND_DELAY_TIME_MS); } while (++idx < ICE_SQ_SEND_MAX_EXECUTE); + kfree(buf_cpy); return status; } -- 2.51.0 From - Tue Jan 13 20:03:24 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id eIdkLaKgZmk0/RcAYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:44:34 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:44:34 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfkJe-00000009EY8-23Om for hi@josie.lol; Tue, 13 Jan 2026 19:44:34 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id BB4593027809 for ; Tue, 13 Jan 2026 19:44:33 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A48E036AB65; Tue, 13 Jan 2026 19:44:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="IIVkepfR" X-Original-To: io-uring@vger.kernel.org Received: from mail-wm1-f68.google.com (mail-wm1-f68.google.com [209.85.128.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2904035E527 for ; Tue, 13 Jan 2026 19:44:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.68 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333471; cv=none; b=L6XIyC+62C/pGsPCEgev9dCL8XLyrPY4vZAjMXWA1Dlil+ZcKCNFsBAUCbR8D0DsXnDx9CwuDAQBBubzU9Xe51xGUWsdS+MFUl0noCWfvozNN6S5sNvwJJ8n4MJX6sUykdGBvUnFRA9SkX91mV7P/PyzFAHN/475REr14WJaz2M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333471; c=relaxed/simple; bh=+5eNlG53pCnP2H6HkD8AFxk5fYZZbrZGswP+g2LyVEA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=hVWW7ogIXtr2wu7ZoGMQ9lsdBudr6stpBucVJhR99cN/UM4TrDCAOa5VT+qpyp67gLF79bLR12EdXYW+Sf2gOZw3/NP8ELLNp/2At6jdnLx9QUs99rYBAgzgGsyDBkH1qonH5bxH0Dxxgi9oWro6l8Xml7LO3rM7V1tcjyhlj0E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=IIVkepfR; arc=none smtp.client-ip=209.85.128.68 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f68.google.com with SMTP id 5b1f17b1804b1-4779aa4f928so79893225e9.1 for ; Tue, 13 Jan 2026 11:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768333468; x=1768938268; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wzKJiDxWGZWZK58KulJ6Ai7jgCO+I4d2FOxBhj+H/CY=; b=IIVkepfRlSbS7/7rFiS+cOJV8Pt1kpWkQeE/8QvFhKwQgNfcBMAnc+2OHUg5kegxuQ C6I1JRmbHGn2ulDJxFvRTUjelI81AMWAecVT35Lgxh7oz4fzTeQ0pmtXY3ljju4/zLrx JXddVc1GxfgRkyfGKZZ33XrJ+6NcOvE8AURAH1s54jBzO7bcMVnHzgRz/0UA+xZCRd1v R5kkM2SqrPEKquLIatPG0EECBY+ECFaXcNZSNgxq/cCmPWlCHfj0YzQjU0VZjZt5E7CP HOMSfAgLagvjNhhmWmITe8w6wD+YEn32nMPMAxRn+0u2h45h/Zex+q0hM+dWN6gHAPng EIRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768333468; x=1768938268; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wzKJiDxWGZWZK58KulJ6Ai7jgCO+I4d2FOxBhj+H/CY=; b=II1PZGfLZH+FLZNm+CHzgvTpMLzdYEhtiTsqqmfLub8VuTH88yYgczqbMFGcsh9/wz ku1jkOK9s7CuP8Myp4zTR5L178rCh/hPqEsNxLgj4f+3HoDn5Q9moSDPYRVRYCg1VAmL diwZ64O5tgw+/oa7iN3f4EPXGRTbxPk2a/yUkTnwAx9U5v0Z8skBJypQZ4FQwht+v1JZ hDog5kclNUTA1er2owHr8GJAO0wg4gpV7hprTzNJ8SOJWjO5R9W3Ar7D+D31N32oFGM7 Hc670A04d+j41614tUTt7DGuidmeA29qjEuIJ6cxtIA8D0MDRKkz7MjpNV946egNnqKv /wdg== X-Gm-Message-State: AOJu0YzwzzsRLj4rA+NXetwnl7ryGKwyI5itS+ioPg6T9zNIFSvJBQWe +FRkCSzK/Ug87HIF0cL260o0JTDoKC/LtamS1Xc2CtzxDlSsqp4qQyTY X-Gm-Gg: AY/fxX7Mha/+UoLgJKAs5bC1KN517UVCRlGqQLIGCwdpxkxh2egLCOgHeBS37o2ITr0 q1/sHkTlg4e10XZFU3M4y0yeNzpgeGpgYjI6lRQrenGo2PFEO1SEHvnfYtDSuUEXVWxyhuWmzNn Gxu4yrN2535qKjK6KdB0HcKlrS/NNUdwiosgyIXm1/F30eRz/UNzO+iHDVNFZxfnqH1KrGzhVdc Z86wI7Qb+mgZLONU4iKxoPzRoTzfcvo8drSAvDlqi0pv7ckBXXwQxwM4NI5pW3EHnr/bChqejI5 YyAWCaWaOHkNvPejeQCygkVDZy+aPZy3Q8aTDme7jCVUSyf5zBhpnRCIn1Ps7SLW1o/PHoPHzkX WIcHXueDvorVBMLFHUMl5NUfZFV6CZUq9n4WMt25NGjMNIhKln0QDb60OgEB3E96Qf2xHHJRyoa I5zqOXKcMj72UVwEFY7x5QN+RnhXXeFJq+sY6e27FWz0l2/4XChGk1XesFRoKNwVU7Vw+d+kbGY jfij20TZ+Nmgrk0YNxeiyme0DnGcT6rn0NNTv0WgSfb7Be0oev7f6Q6hMgvfJzbIA== X-Received: by 2002:a05:600c:3556:b0:477:7f4a:44b0 with SMTP id 5b1f17b1804b1-47ee338ed50mr3080765e9.33.1768333468295; Tue, 13 Jan 2026 11:44:28 -0800 (PST) Received: from ?IPV6:2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c? ([2a01:4b00:bd21:4f00:7cc6:d3ca:494:116c]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd5ede7esm47023689f8f.32.2026.01.13.11.44.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Jan 2026 11:44:27 -0800 (PST) Message-ID: Date: Tue, 13 Jan 2026 19:44:22 +0000 Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] io_uring/rsrc: fix RLIMIT_MEMLOCK bypass via compound page accounting To: Yuhao Jiang , Jens Axboe Cc: io-uring@vger.kernel.org, linux-kernel@vger.kernel.org References: <20251218025947.36115-1-danisjiang@gmail.com> Content-Language: en-US From: Pavel Begunkov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-DKIM: signer='gmail.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [asml.silence[at]gmail.com] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 On 1/9/26 03:02, Yuhao Jiang wrote: > Hi Jens, Pavel, and all, > > Just a gentle follow-up on this patch below. > Please let me know if there are any concerns or if changes are needed. I'm pretty this will break with buffer sharing / cloning. I'd be tempted to remove all this cross buffer accounting logic and overestimate it, the current accounting is not sane. Otherwise, it'll likely need some proxy object shared b/w buffers or some other overly overcomplicated solution. > Thanks for your time. > > Best regards, > Yuhao Jiang > > On Wed, Dec 17, 2025 at 9:00 PM Yuhao Jiang wrote: >> >> When multiple registered buffers share the same compound page, only the >> first buffer accounts for the memory via io_buffer_account_pin(). The >> subsequent buffers skip accounting since headpage_already_acct() returns >> true. >> >> When the first buffer is unregistered, the accounting is decremented, >> but the compound page remains pinned by the remaining buffers. This >> creates a state where pinned memory is not properly accounted against >> RLIMIT_MEMLOCK. >> >> On systems with HugeTLB pages pre-allocated, an unprivileged user can >> exploit this to pin memory beyond RLIMIT_MEMLOCK by cycling buffer >> registrations. The bypass amount is proportional to the number of >> available huge pages, potentially allowing gigabytes of memory to be >> pinned while the kernel accounting shows near-zero. >> >> Fix this by recalculating the actual pages to unaccount when unmapping >> a buffer. For regular pages, always unaccount. For compound pages, only >> unaccount if no other registered buffer references the same compound >> page. This ensures the accounting persists until the last buffer >> referencing the compound page is released. >> >> Reported-by: Yuhao Jiang >> Fixes: 57bebf807e2a ("io_uring/rsrc: optimise registered huge pages") That's not the right commit, the accounting is ancient, should get blamed somewhere around first commits that added registered buffers. -- Pavel Begunkov From - Tue Jan 13 20:03:25 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id CDp6Fq6hZmkWxh4AYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:49:02 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:49:02 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfkNx-00000009Pf6-4BuW for hi@josie.lol; Tue, 13 Jan 2026 19:49:02 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id B63D13023D6E for ; Tue, 13 Jan 2026 19:48:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 20D1034DCF9; Tue, 13 Jan 2026 19:48:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="Y7Irkn5S" X-Original-To: stable@vger.kernel.org Received: from smtpout.efficios.com (smtpout.efficios.com [158.69.130.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78D8831327D; Tue, 13 Jan 2026 19:48:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=158.69.130.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333722; cv=none; b=sD4jY7aTV/uHEfbugQZ/3naZWFGvVb5/ecHzLwz/ukdpov9+/xQHHnj0kmy8lP4SJyqyOv0L0kdIR+QzzNTIXHXnn64qq5sQ2dpq7BMxvUj75Ggdlag5usrcLqbbXgbPNXl+O80sNwFa1Vee7Hn3x49eZ+xhWv/vwttWvzR2nkQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333722; c=relaxed/simple; bh=bTp2Vjo4mw/wCtFQXi3331QEgeDTFtRFmfRf0623Zr4=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=lvkulqr6iTZ5cBmKHB/xwfJxhl4H7a/UlrXhCh/cW6VQGs9CMpbQPsyn8FZR/dB17m+UILa0LKE+WhN2RWBNAa60yH+bVL6IECgW9pgMG0LNepJOKW9yfYezOLBb8pHzCmWP6TaAXc8Zi6iIbSpv0sctkII3hPsXArd2X72efYU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=Y7Irkn5S; arc=none smtp.client-ip=158.69.130.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=smtpout1; t=1768333719; bh=FnQ6Xj9eoyZHqA1dE1GyFR6lhfMRam/O2mY67l2o+yY=; h=From:To:Cc:Subject:Date:From; b=Y7Irkn5SAfMbS6XllRAOy38YzIKPePFRJxrmK5s/LlwoBiKjexTQsXLqkDvG4V/H9 XlrU7L6s6UHwIbnKcoEST9xs24ZMEBbAksgKDYxi6O+hcFqU1Gdzlj5y31k28IQHbX LSTeK5oD4u4tz180kv1jIN6Nh7BtJKTqyx4GNmd6aYsvBQ9I42SFWhZCF3VuNgHKuo eQCrVk3Yh3G0omKKLElaM87Jf/Kh9jNEXWiZG2vhooOzVy6tD5jYEWxhAQrNQDaJGd C5qtL6gUYat8Id5+6CNaBnkKszN5bR+71dNi7CBQBa8h0rhL6/ImQHZc5m4VNK0LcF hNSfuGwcinaKA== Received: from thinkos.internal.efficios.com (mtl.efficios.com [216.120.195.104]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4drKYg2L7PzlTP; Tue, 13 Jan 2026 14:48:39 -0500 (EST) From: Mathieu Desnoyers To: Andrew Morton Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers , "Paul E. McKenney" , Steven Rostedt , Masami Hiramatsu , Dennis Zhou , Tejun Heo , Christoph Lameter , Martin Liu , David Rientjes , christian.koenig@amd.com, Shakeel Butt , SeongJae Park , Michal Hocko , Johannes Weiner , Sweet Tea Dorminy , Lorenzo Stoakes , "Liam R . Howlett" , Mike Rapoport , Suren Baghdasaryan , Vlastimil Babka , Christian Brauner , Wei Yang , David Hildenbrand , Miaohe Lin , Al Viro , linux-mm@kvack.org, stable@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Yu Zhao , Roman Gushchin , Mateusz Guzik , Matthew Wilcox , Baolin Wang , Aboorva Devarajan Subject: [PATCH v1 0/1] mm: Fix OOM killer and proc stats inaccuracy on large many-core systems Date: Tue, 13 Jan 2026 14:47:33 -0500 Message-Id: <20260113194734.28983-1-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.5 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='efficios.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: efficios.com] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 Hi Andrew, This patch modifies the OOM killer and all proc RSS stats to use the precise for-each-possible-cpu sum to fix the inaccuracy issues. This approach was suggested by Michal Hocko as a straightforward fix for the inaccuracy issue by using more precise (but slower) RSS stats sum. With this, the hierarchical per-cpu counters become a simple optimization rather than a bug fix. I will post a new version of the HPCC soon which will be based on this patch. Feedback is welcome! Thanks, Mathieu Cc: Andrew Morton Cc: "Paul E. McKenney" Cc: Steven Rostedt Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Dennis Zhou Cc: Tejun Heo Cc: Christoph Lameter Cc: Martin Liu Cc: David Rientjes Cc: christian.koenig@amd.com Cc: Shakeel Butt Cc: SeongJae Park Cc: Michal Hocko Cc: Johannes Weiner Cc: Sweet Tea Dorminy Cc: Lorenzo Stoakes Cc: "Liam R . Howlett" Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Christian Brauner Cc: Wei Yang Cc: David Hildenbrand Cc: Miaohe Lin Cc: Al Viro Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Cc: linux-trace-kernel@vger.kernel.org Cc: Yu Zhao Cc: Roman Gushchin Cc: Mateusz Guzik Cc: Matthew Wilcox Cc: Baolin Wang Cc: Aboorva Devarajan Mathieu Desnoyers (1): mm: Fix OOM killer and proc stats inaccuracy on large many-core systems fs/proc/task_mmu.c | 14 +++++++------- include/linux/mm.h | 5 ----- 2 files changed, 7 insertions(+), 12 deletions(-) -- 2.39.5 From - Tue Jan 13 20:03:25 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id mMwtLLKhZmkzxh4AYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 19:49:06 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 19:49:06 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfkO2-00000009Psb-19YB for hi@josie.lol; Tue, 13 Jan 2026 19:49:06 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 4C92A306CD82 for ; Tue, 13 Jan 2026 19:48:43 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4EC4D35F8AA; Tue, 13 Jan 2026 19:48:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="FRxqryaH" X-Original-To: stable@vger.kernel.org Received: from smtpout.efficios.com (smtpout.efficios.com [158.69.130.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78D073126C2; Tue, 13 Jan 2026 19:48:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=158.69.130.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333722; cv=none; b=mFwG7WOawEeRmgsOlGAXg9hOQjS/klw9VqpX3/IdxqBpXRzzkEBBxcBO34h2ylt8Nj1XTipjATkrz/bjckVvgQq2bAjar6XfOgMYMiXuSiDxJDyzRMnm/Lxu7QLQqGtWwP5NwH9ztRyK3Ozi4ijsFayfKgD82jzY+GV39JWhfco= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768333722; c=relaxed/simple; bh=Xz260U2fGs2qgfeXh7+wphQkViPoj/5lzrfL8TG5FxA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=pMgMTfqQeXK09pC5i43NRPzyyz5DrL2cxPNYnlbTXecoHNfx8QJFhUKf5bWYnuVvd536Ce7SO2yMdw0FTos0Xkmh5B1GlxSx33QXT0S/oL5S9fEWea1s7rorp13uqiXwcEE+ln8nWNiSsMl9tiyDjaPtvP0IPp2cvc2Nf5/y86M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com; spf=pass smtp.mailfrom=efficios.com; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b=FRxqryaH; arc=none smtp.client-ip=158.69.130.18 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=smtpout1; t=1768333719; bh=ibI7m5hVA+BML8zWJ+X0AQLePZoxFXR6rc0fCgAMKyU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FRxqryaHtE4q7Dc3L1yQfbYf3EA6gZnk9TO9G6Ily22Tpr2V37FMSXS8FfXv+gkX3 3T9wjufK4+hIH9SJbm1+yYOjX0GnaleffjYwEDPXRBLHclHhpjERmjuHTFp2NE3Mcy WCDvL2+74yzG3f9+UV5Sjw4iy9h+GU/i4foTfkxXh0zfjCHbcKMPBRCtLZPfoHgkf5 /1TmH5sXzlOWMF/m22Of/AjMoSsowk50zh3sbijkKbkrwXVCMjW5t0st6enAWDdbC/ +SRd5xRRMXGQbTxQafem5fOnEC+Y9Se3/lXhSz+lin50gYGeIhVACSIHRNj/qBUFuf Q3CNp1Fvq1Tgw== Received: from thinkos.internal.efficios.com (mtl.efficios.com [216.120.195.104]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4drKYg3hXRzlTQ; Tue, 13 Jan 2026 14:48:39 -0500 (EST) From: Mathieu Desnoyers To: Andrew Morton Cc: linux-kernel@vger.kernel.org, Mathieu Desnoyers , "Paul E. McKenney" , Steven Rostedt , Masami Hiramatsu , Dennis Zhou , Tejun Heo , Christoph Lameter , Martin Liu , David Rientjes , christian.koenig@amd.com, Shakeel Butt , SeongJae Park , Michal Hocko , Johannes Weiner , Sweet Tea Dorminy , Lorenzo Stoakes , "Liam R . Howlett" , Mike Rapoport , Suren Baghdasaryan , Vlastimil Babka , Christian Brauner , Wei Yang , David Hildenbrand , Miaohe Lin , Al Viro , linux-mm@kvack.org, stable@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Yu Zhao , Roman Gushchin , Mateusz Guzik , Matthew Wilcox , Baolin Wang , Aboorva Devarajan Subject: [PATCH v1 1/1] mm: Fix OOM killer and proc stats inaccuracy on large many-core systems Date: Tue, 13 Jan 2026 14:47:34 -0500 Message-Id: <20260113194734.28983-2-mathieu.desnoyers@efficios.com> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20260113194734.28983-1-mathieu.desnoyers@efficios.com> References: <20260113194734.28983-1-mathieu.desnoyers@efficios.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='efficios.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: efficios.com] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 Use the precise, albeit slower, precise RSS counter sums for the OOM killer task selection and proc statistics. The approximated value is too imprecise on large many-core systems. The following rss tracking issues were noted by Sweet Tea Dorminy [1], which lead to picking wrong tasks as OOM kill target: Recently, several internal services had an RSS usage regression as part of a kernel upgrade. Previously, they were on a pre-6.2 kernel and were able to read RSS statistics in a backup watchdog process to monitor and decide if they'd overrun their memory budget. Now, however, a representative service with five threads, expected to use about a hundred MB of memory, on a 250-cpu machine had memory usage tens of megabytes different from the expected amount -- this constituted a significant percentage of inaccuracy, causing the watchdog to act. This was a result of commit f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") [1]. Previously, the memory error was bounded by 64*nr_threads pages, a very livable megabyte. Now, however, as a result of scheduler decisions moving the threads around the CPUs, the memory error could be as large as a gigabyte. This is a really tremendous inaccuracy for any few-threaded program on a large machine and impedes monitoring significantly. These stat counters are also used to make OOM killing decisions, so this additional inaccuracy could make a big difference in OOM situations -- either resulting in the wrong process being killed, or in less memory being returned from an OOM-kill than expected. Here is a (possibly incomplete) list of the prior approaches that were used or proposed, along with their downside: 1) Per-thread rss tracking: large error on many-thread processes. 2) Per-CPU counters: up to 12% slower for short-lived processes and 9% increased system time in make test workloads [1]. Moreover, the inaccuracy increases with O(n^2) with the number of CPUs. 3) Per-NUMA-node counters: requires atomics on fast-path (overhead), error is high with systems that have lots of NUMA nodes (32 times the number of NUMA nodes). The simple fix proposed here is to do the precise per-cpu counters sum every time a counter value needs to be read. This applies to the OOM killer task selection, to the /proc statistics, and to the oom mark_victim trace event. Note that commit 82241a83cd15 ("mm: fix the inaccurate memory statistics issue for users") introduced get_mm_counter_sum() for precise proc memory status queries for _some_ proc files. This change renames get_mm_counter_sum() to get_mm_counter(), thus moving the rest of the proc files to the precise sum. This change effectively increases the latency introduced when the OOM killer executes in favor of doing a more precise OOM target task selection. Effectively, the OOM killer iterates on all tasks, for all relevant page types, for which the precise sum iterates on all possible CPUs. As a reference, here is the execution time of the OOM killer before/after the change: AMD EPYC 9654 96-Core (2 sockets) Within a KVM, configured with 256 logical cpus. | before | after | ----------------------------------|----------|----------| nr_processes=40 | 0.3 ms | 0.5 ms | nr_processes=10000 | 3.0 ms | 80.0 ms | Suggested-by: Michal Hocko Fixes: f1a7941243c1 ("mm: convert mm's rss stats into percpu_counter") Link: https://lore.kernel.org/lkml/20250331223516.7810-2-sweettea-kernel@dorminy.me/ # [1] Signed-off-by: Mathieu Desnoyers Cc: Andrew Morton Cc: "Paul E. McKenney" Cc: Steven Rostedt Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Dennis Zhou Cc: Tejun Heo Cc: Christoph Lameter Cc: Martin Liu Cc: David Rientjes Cc: christian.koenig@amd.com Cc: Shakeel Butt Cc: SeongJae Park Cc: Michal Hocko Cc: Johannes Weiner Cc: Sweet Tea Dorminy Cc: Lorenzo Stoakes Cc: "Liam R . Howlett" Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Christian Brauner Cc: Wei Yang Cc: David Hildenbrand Cc: Miaohe Lin Cc: Al Viro Cc: linux-mm@kvack.org Cc: stable@vger.kernel.org Cc: linux-trace-kernel@vger.kernel.org Cc: Yu Zhao Cc: Roman Gushchin Cc: Mateusz Guzik Cc: Matthew Wilcox Cc: Baolin Wang Cc: Aboorva Devarajan --- fs/proc/task_mmu.c | 14 +++++++------- include/linux/mm.h | 5 ----- 2 files changed, 7 insertions(+), 12 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 81dfc26bfae8..8ca4fbf53fc5 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -39,9 +39,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm) unsigned long text, lib, swap, anon, file, shmem; unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss; - anon = get_mm_counter_sum(mm, MM_ANONPAGES); - file = get_mm_counter_sum(mm, MM_FILEPAGES); - shmem = get_mm_counter_sum(mm, MM_SHMEMPAGES); + anon = get_mm_counter(mm, MM_ANONPAGES); + file = get_mm_counter(mm, MM_FILEPAGES); + shmem = get_mm_counter(mm, MM_SHMEMPAGES); /* * Note: to minimize their overhead, mm maintains hiwater_vm and @@ -62,7 +62,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm) text = min(text, mm->exec_vm << PAGE_SHIFT); lib = (mm->exec_vm << PAGE_SHIFT) - text; - swap = get_mm_counter_sum(mm, MM_SWAPENTS); + swap = get_mm_counter(mm, MM_SWAPENTS); SEQ_PUT_DEC("VmPeak:\t", hiwater_vm); SEQ_PUT_DEC(" kB\nVmSize:\t", total_vm); SEQ_PUT_DEC(" kB\nVmLck:\t", mm->locked_vm); @@ -95,12 +95,12 @@ unsigned long task_statm(struct mm_struct *mm, unsigned long *shared, unsigned long *text, unsigned long *data, unsigned long *resident) { - *shared = get_mm_counter_sum(mm, MM_FILEPAGES) + - get_mm_counter_sum(mm, MM_SHMEMPAGES); + *shared = get_mm_counter(mm, MM_FILEPAGES) + + get_mm_counter(mm, MM_SHMEMPAGES); *text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK)) >> PAGE_SHIFT; *data = mm->data_vm + mm->stack_vm; - *resident = *shared + get_mm_counter_sum(mm, MM_ANONPAGES); + *resident = *shared + get_mm_counter(mm, MM_ANONPAGES); return mm->total_vm; } diff --git a/include/linux/mm.h b/include/linux/mm.h index 6f959d8ca4b4..d096bb3593ba 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2847,11 +2847,6 @@ static inline bool get_user_page_fast_only(unsigned long addr, * per-process(per-mm_struct) statistics. */ static inline unsigned long get_mm_counter(struct mm_struct *mm, int member) -{ - return percpu_counter_read_positive(&mm->rss_stat[member]); -} - -static inline unsigned long get_mm_counter_sum(struct mm_struct *mm, int member) { return percpu_counter_sum_positive(&mm->rss_stat[member]); } -- 2.39.5 From - Tue Jan 13 20:03:25 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 0AP0D7WkZmlmzyMAYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 20:01:57 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 20:01:57 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfkaS-00000009vbX-47Sy for hi@josie.lol; Tue, 13 Jan 2026 20:01:57 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id BF9C5301F8FA for ; Tue, 13 Jan 2026 20:01:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 32985318B9E; Tue, 13 Jan 2026 20:01:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EDjkcVDc" X-Original-To: stable@vger.kernel.org Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F3A71A5B84; Tue, 13 Jan 2026 20:01:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768334515; cv=none; b=Zm4+KTDQJyhdtibFOpgSQ4KEve3Qx6bnL4YCET1oX/YrvBV0Z/8Jf3L/G4dxBJBhXR8FmJK+2vjbSjhgv4H/23U9yyekeoVqGitsNXHWUyBnmchGYgWv4XNPyJub3mHlyB5CMhPbLGtoMJyyn4ZqWTPSMoF/WS9qO0Z4ovQmyfk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768334515; c=relaxed/simple; bh=M4uUyEp62gWWD4OOHFLprekCcfTdrbBnebmztF3mh64=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lGF0qlxjYqszVrHt3cHPMiclrIk9yfRLXpWYMeVPQmMvIZQpIz8BsLv4LdV3QquyzFuhaLMroH5pxfw5eLvzTj5POJfdQe6FJK+O3TpKz6OPEtmb5qHgawKsKqMprbfkiJjfPZmitdjBUdx6HZwUNo19sF8Veb4h4GXIPr8plaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EDjkcVDc; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7647DC116C6; Tue, 13 Jan 2026 20:01:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1768334514; bh=M4uUyEp62gWWD4OOHFLprekCcfTdrbBnebmztF3mh64=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=EDjkcVDc8fy2JPLPcxCXi+cKEji/LSh7u5E4loJIV8SBUN9ksk9z8X4YQLRBQEYvk cH0NpPRL+2VmpppDijtqgINcFyY+bBSOLbbD6l9Cvfimky5Gz170JWS+J8n31NBoyp WMVpGOL/tiBpGy6uTLEFfJic4cIUYMlRP77Vpv+Z2A2IOdOA7OhPLgtNbam30fTbhZ TIWv3Bb0h74UQlZlJMcitgfHi9qtiURXDQnWiJumppZaKYlY0MjiyeBoh2lHu7IodA CSnI01WN3g5I/C3vHP+QbWZxBEYb2xCvZUlPvNqbZGjaD0K6nevM4fSq7XmwtlyjsH 0ToWKe84JxRnQ== Date: Tue, 13 Jan 2026 15:01:53 -0500 From: Sasha Levin To: Nathan Chancellor Cc: Greg Kroah-Hartman , amd-gfx@lists.freedesktop.org, stable@vger.kernel.org, llvm@lists.linux.dev Subject: Re: Apply 70740454377f1ba3ff32f5df4acd965db99d055b to linux-6.12.y Message-ID: References: <20260113005327.GA2283840@ax162> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20260113005327.GA2283840@ax162> X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 On Mon, Jan 12, 2026 at 05:53:27PM -0700, Nathan Chancellor wrote: >Hi Greg and Sasha, > >Commit 70740454377f ("drm/amd/display: Apply e4479aecf658 to dml") was >recently queued up for 6.18. This same change will be needed in 6.12 but >it will need commit 820ccf8cb2b1 ("drm/amd/display: Respect user's >CONFIG_FRAME_WARN more for dml files") applied first for it to apply >cleanly. Please let me know if there are any problems with this. Queued up, thanks! -- Thanks, Sasha From - Tue Jan 13 20:07:21 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id yG2AK/elZmlZzyMAYBR5ng (envelope-from ) for ; Tue, 13 Jan 2026 20:07:19 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 13 Jan 2026 20:07:19 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vfkff-0000000A8oQ-1Gq3 for hi@josie.lol; Tue, 13 Jan 2026 20:07:19 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 31F5A302CBA4 for ; Tue, 13 Jan 2026 20:05:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A015F318B9E; Tue, 13 Jan 2026 20:05:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iJ+NxVs7" X-Original-To: io-uring@vger.kernel.org Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1C0C0318EC5 for ; Tue, 13 Jan 2026 20:05:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768334716; cv=none; b=hMwNjZ9kfp4foCs0vhaVI9feW5VPmttO6X2ox5XrjqK0yLzhNbwVhV9SB/l4b9q4Yv4wK745XZCa4fC3xu1lxrx3FMWfMogIkCDUErWUaRV94mopN7aT+SvVB3rt5gxZ4qpMTAyoljlRE4jITc5t7iUES3AueBW081OL+1ScIyg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768334716; c=relaxed/simple; bh=PVK4zx+iAg1xSk