Out of curiosity, has there been an alternative approach for some backports, where someone backports most fixes and features (and safe cleanup) but does not backport any of the changesets which have dependencies outside the module (e.g. VFS changes, netfs or mm changes etc.) to reduce patch dependency risk (ie 70-80% backport instead of the typical 10-20% that are picked up by stable)?
For example, we (on the client) ran into issues with 5.15 kernel (for the client) missing so many important fixes and features (and sometimes hard to distinguish when a new feature is also a 'fix') that I did a "full backport" for cifs.ko again a few months ago for 5.15 (leaving out about 10% of the patches, those with dependencies or that would be risky).
There are arguments to be made for larger backports when test infrastructure is good and lots of good functional tests (due to risk of subtle dependencies when cherrypicking 1 patch out of 5 to backport). In general, Namjae has access to excellent functional/regression suites for SMB server (not just from Samba "smbtorture") so it is theoretically possible to do larger "very safe" backports for ksmbd (or at least make these available as an alternative for users who hit serious roadblocks on older kernels), if the test automation were well trusted. Is there a precedent for this?
-----Original Message----- From: Greg KH gregkh@linuxfoundation.org Sent: Tuesday, December 12, 2023 2:05 PM To: paul.gortmaker@windriver.com Cc: Namjae Jeon linkinjeon@kernel.org; Steven French Steven.French@microsoft.com; stable@vger.kernel.org Subject: [EXTERNAL] Re: [PATCH 0/1] RFC: linux-5.15.y ksmbd backport for CVE-2023-38431
On Tue, Dec 12, 2023 at 01:47:44PM -0500, paul.gortmaker@windriver.com wrote:
From: Paul Gortmaker paul.gortmaker@windriver.com
This is a bit long, but I've never touched this code and all I can do is compile test it. So the below basically represents a capture of my thought process in fixing this for the v5.15.y-stable branch.
Nice work, but really, given that there are _SO_ many ksmb patches that have NOT been backported to 5.15.y, I would strongly recommend that we just mark the thing as depending on BROKEN there for now as your one backport here is not going to make a dent in the fixes that need to be applied there to resolve the known issues that the codebase currently has resolved in newer kernels.
Do you use this codebase on 5.15.y? What drove you to want to backport this, just the presence of a random CVE identifier? If that's all it takes to get companies to actually do backports, maybe I should go allocate more of them :)
thanks,
greg k-h