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@xxxxxxxxxxxxxxxxxxx> Sent: Tuesday, December 12, 2023 2:05 PM To: paul.gortmaker@xxxxxxxxxxxxx Cc: Namjae Jeon <linkinjeon@xxxxxxxxxx>; Steven French <Steven.French@xxxxxxxxxxxxx>; stable@xxxxxxxxxxxxxxx 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@xxxxxxxxxxxxx wrote: > From: Paul Gortmaker <paul.gortmaker@xxxxxxxxxxxxx> > > 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
