Date: Tue, 25 Jun 2024 13:43:03 -0700
From: Guenter Roeck <linux@...ck-us.net>
To: Chuck Lever III <chuck.lever@...cle.com>
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 6/25/24 12:49, Chuck Lever III wrote:
> 
> 
>> 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.
> 

Sounds good to me.

Thanks,
Guenter

Powered by blists - more mailing lists