Message-ID: <04BEF7A2-EB38-475D-BFD9-2E6B1C2C0972@oracle.com>
Date: Tue, 25 Jun 2024 19:49:57 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Guenter Roeck <linux@...ck-us.net>
CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-stable
	<stable@...r.kernel.org>,
        "patches@...ts.linux.dev"
	<patches@...ts.linux.dev>,
        Linux Kernel Mailing List
	<linux-kernel@...r.kernel.org>,
        Linus Torvalds
	<torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "patches@...nelci.org"
	<patches@...nelci.org>,
        "lkft-triage@...ts.linaro.org"
	<lkft-triage@...ts.linaro.org>,
        "pavel@...x.de" <pavel@...x.de>,
        "jonathanh@...dia.com" <jonathanh@...dia.com>,
        "f.fainelli@...il.com"
	<f.fainelli@...il.com>,
        "sudipm.mukherjee@...il.com"
	<sudipm.mukherjee@...il.com>,
        "srw@...dewatkins.net" <srw@...dewatkins.net>,
        "rwarsow@....de" <rwarsow@....de>,
        "conor@...nel.org" <conor@...nel.org>,
        "allen.lkml@...il.com" <allen.lkml@...il.com>,
        "broonie@...nel.org"
	<broonie@...nel.org>
Subject: Re: [PATCH 5.10 000/770] 5.10.220-rc1 review



> On Jun 25, 2024, at 3:40 PM, Chuck Lever III <chuck.lever@...cle.com> wrote:
> 
> 
> 
>> On Jun 25, 2024, at 3:35 PM, Guenter Roeck <linux@...ck-us.net> wrote:
>> 
>> On 6/25/24 12:08, Chuck Lever III wrote:
>>>> On Jun 25, 2024, at 12:29 PM, Guenter Roeck <linux@...ck-us.net> wrote:
>>>> 
>>>> On 6/25/24 08:13, Chuck Lever III wrote:
>>>>> Hi -
>>>>>> On Jun 25, 2024, at 11:04 AM, Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
>>>>>> 
>>>>>> On Tue, Jun 25, 2024 at 07:48:00AM -0700, Guenter Roeck wrote:
>>>>>>> On 6/18/24 05:27, Greg Kroah-Hartman wrote:
>>>>>>>> This is the start of the stable review cycle for the 5.10.220 release.
>>>>>>>> There are 770 patches in this series, all will be posted as a response
>>>>>>>> to this one.  If anyone has any issues with these being applied, please
>>>>>>>> let me know.
>>>>>>>> 
>>>>>>>> Responses should be made by Thu, 20 Jun 2024 12:32:00 +0000.
>>>>>>>> Anything received after that time might be too late.
>>>>>>>> 
>>>>>>> 
>>>>>>> [ ... ]
>>>>>>>> Chuck Lever <chuck.lever@...cle.com>
>>>>>>>>    SUNRPC: Prepare for xdr_stream-style decoding on the server-side
>>>>>>>> 
>>>>>>> The ChromeOS patches robot reports a number of fixes for the patches
>>>>>>> applied in 5.5.220. This is one example, later fixed with commit
>>>>>>> 90bfc37b5ab9 ("SUNRPC: Fix svcxdr_init_decode's end-of-buffer
>>>>>>> calculation"), but there are more. Are those fixes going to be
>>>>>>> applied in a subsequent release of v5.10.y, was there a reason to
>>>>>>> not include them, or did they get lost ?
>>>>>> 
>>>>>> I saw this as well, but when I tried to apply a few, they didn't, so I
>>>>>> was guessing that Chuck had merged them together into the series.
>>>>>> 
>>>>>> I'll defer to Chuck on this, this release was all his :)
>>>>> I did this port months ago, I've been waiting for the dust to
>>>>> settle on the 6.1 and 5.15 NFSD backports, so I've all but
>>>>> forgotten the status of individual patches.
>>>>> If you (Greg or Guenter) send me a list of what you believe is
>>>>> missing, I can have a look at the individual cases and then
>>>>> run the finished result through our NFSD CI gauntlet.
>>>> 
>>>> This is what the robot reported so far:
>>>> 
>>>> 1242a87da0d8 SUNRPC: Fix svcxdr_init_encode's buflen calculation
>>>> Fixes: bddfdbcddbe2 ("NFSD: Extract the svcxdr_init_encode() helper")
>>>> 90bfc37b5ab9 SUNRPC: Fix svcxdr_init_decode's end-of-buffer calculation
>>>> Fixes: 5191955d6fc6 ("SUNRPC: Prepare for xdr_stream-style decoding on the server-side")
>>>> 10396f4df8b7 nfsd: hold a lighter-weight client reference over CB_RECALL_ANY
>>>> Fixes: 44df6f439a17 ("NFSD: add delegation reaper to react to low memory condition")
>>> My naive search found:
>>> Checking commit 44df6f439a17 ...
>>>  upstream fix 10396f4df8b75ff6ab0aa2cd74296565466f2c8d not found
>>> 10396f4df8b75ff6ab0aa2cd74296565466f2c8d nfsd: hold a lighter-weight client reference over CB_RECALL_ANY
>>>  upstream fix f385f7d244134246f984975ed34cd75f77de479f is already applied
>>> Checking commit a2071573d634 ...
>>>  upstream fix f1aa2eb5ea05ccd1fd92d235346e60e90a1ed949 not found
>>> f1aa2eb5ea05ccd1fd92d235346e60e90a1ed949 sysctl: fix proc_dobool() usability
>>> Checking commit bddfdbcddbe2 ...
>>>  upstream fix 1242a87da0d8cd2a428e96ca68e7ea899b0f4624 not found
>>> 1242a87da0d8cd2a428e96ca68e7ea899b0f4624 SUNRPC: Fix svcxdr_init_encode's buflen calculation
>>> Checking commit 9fe61450972d ...     upstream fix 2111c3c0124f7432fe908c036a50abe8733dbf38 not found
>>> 2111c3c0124f7432fe908c036a50abe8733dbf38 namei: fix kernel-doc for struct renamedata and more
>>> Checking commit 013c1667cf78 ...     upstream fix 2c0f0f3639562d6e38ee9705303c6457c4936eac not found
>>> 2c0f0f3639562d6e38ee9705303c6457c4936eac module: correctly exit module_kallsyms_on_each_symbol when fn() != 0
>>>  upstream fix 1e80d9cb579ed7edd121753eeccce82ff82521b4 not found
>>> 1e80d9cb579ed7edd121753eeccce82ff82521b4 module: potential uninitialized return in module_kallsyms_on_each_symbol()
>>> Checking commit 89ff87494c6e ...
>>>  upstream fix 5c11720767f70d34357d00a15ba5a0ad052c40fe not found
>>> 5c11720767f70d34357d00a15ba5a0ad052c40fe SUNRPC: Fix a NULL pointer deref in trace_svc_stats_latency()
>>> Checking commit 5191955d6fc6 ...
>>>  upstream fix 90bfc37b5ab91c1a6165e3e5cfc49bf04571b762 not found
>>> 90bfc37b5ab91c1a6165e3e5cfc49bf04571b762 SUNRPC: Fix svcxdr_init_decode's end-of-buffer calculation
>>>  upstream fix b9f83ffaa0c096b4c832a43964fe6bff3acffe10 not found
>>> b9f83ffaa0c096b4c832a43964fe6bff3acffe10 SUNRPC: Fix null pointer dereference in svc_rqst_free()
>>> I'll look into backporting the missing NFSD and SUNRPC patches.
>> 
>> My list didn't include patches with conflicts. There are a lot of them. Our robot
>> collects those, but doesn't focus on it. It also doesn't analyze just nfds/SUNRPC
>> patches, but all of them. I started an analysis to list all the fixes with
>> conflicts; so far I found about 100 of them. Three are tagged SUNRPC.
>> 
>> Upstream commit 8e088a20dbe3 ("SUNRPC: add a missing rpc_stat for TCP TLS")
>> upstream: v6.9-rc7
>>   Fixes: 1548036ef120 ("nfs: make the rpc_stat per net namespace")
>>     in linux-5.4.y: 19f51adc778f
>>     in linux-5.10.y: afdbc21a92a0
>>     in linux-5.15.y: 7ceb89f4016e
>>     in linux-6.1.y: 2b7f2d663a96
>>     in linux-6.6.y: 260333221cf0
>>     upstream: v6.9-rc1
>>   Affected branches:
>>     linux-5.4.y (conflicts - backport needed)
>>     linux-5.10.y (conflicts - backport needed)
>>     linux-5.15.y (conflicts - backport needed)
>>     linux-6.1.y (conflicts - backport needed)
>>     linux-6.6.y (already applied)
>> 
>> Upstream commit aed28b7a2d62 ("SUNRPC: Don't dereference xprt->snd_task if it's a cookie")
>> upstream: v5.17-rc2
>>   Fixes: e26d9972720e ("SUNRPC: Clean up scheduling of autoclose")
>>     in linux-5.4.y: 2d6f096476e6
>>     in linux-5.10.y: 2ab569edd883
>>     upstream: v5.15-rc1
>>   Affected branches:
>>     linux-5.4.y (conflicts - backport needed)
>>     linux-5.10.y (conflicts - backport needed)
>>     linux-5.15.y (already applied)
>> 
>> Upstream commit aad41a7d7cf6 ("SUNRPC: Don't leak sockets in xs_local_connect()")
>> upstream: v5.18-rc6
>>   Fixes: f00432063db1 ("SUNRPC: Ensure we flush any closed sockets before xs_xprt_free()")
>>     in linux-5.4.y: 2f8f6c393b11
>>     in linux-5.10.y: e68b60ae29de
>>     in linux-5.15.y: 54f6834b283d
>>     upstream: v5.18-rc2
>>   Affected branches:
>>     linux-5.4.y (conflicts - backport needed)
>>     linux-5.10.y (conflicts - backport needed)
>>     linux-5.15.y (conflicts - backport needed)
>> 
>> I'll send a complete list after the analysis is done.
> 
> The "NFSD file cache fixes" backports focused on NFSD, not on
> SUNRPC, and only the NFS server side of affairs. The missing
> fixes you found are outside of one or both of those areas, so
> they can go through the usual stable backport process if the
> NFS client folks care to do that.

Or, to cut this another way: I looked at only the patches that
I submitted for v5.10.220; I will take responsibility for
ensuring those all have the latest upstream fixes applied,
where that is feasible.

Anything else (other subsystems, other LTS kernels) gets the
normal stable backport treatment: those subsystem maintainers
or their designees have to step up to handle the code work
and testing if they view the fix as a priority.


--
Chuck Lever

Powered by blists - more mailing lists