On Thu, Dec 14, 2023 at 08:31:44AM +0900, Namjae Jeon wrote: > 2023-12-13 23:36 GMT+09:00, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>: > > On Tue, Dec 12, 2023 at 08:13:37PM +0000, Steven French wrote: > >> 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). > > > > We did take a "big backport/sync" for io_uring in 5.15.y a while ago, so > > there is precident for this. > > > > But really, is anyone even using this feature in 5.15.y anyway? I don't > > know of any major distro using 5.15.y any more, and Android systems > > based on 5.15.y don't use this specific filesystem, so what is left? > > Can we just mark it broken and be done with it? > As I know, ksmbd is enable in 5.15 kernel of some distros(opensuse, > ubuntu, etc) except redhat. But do any of them actually use the 5.15.y kernel tree and take updates from there? That's the key thing here. > And users can use this feature. I will > make the time for ksmbd backporting job. To facilitate backport, Can I > submit clean-up patches for ksmbd of 5.15 kernel or only bug fixes are > allowed? If a fix relies on an upstream cleanup, that's fine to take. But first, find out if anyone is actually using this before you take the time here. thanks, greg k-h
