> Larger backports like that can make sense for a target audience who are invested in some feature but don't want to move anything else - then it becomes a deliverable in itself, typically from a professional services group. But linux-stable is definitely not the place for things like that. I wasn't so much thinking about it for stable, but for cases where it is safer to use an alternative to stable for a particular module (and for a particular older kernel). For active components (where dozens of patches go in each release) stable can carry risks because of subtle patch dependencies. Maybe not as much issue for the cifs.ko and ksmbd.ko cases because there are excellent testcase suites that could be automated for stable to catch the vast majority of stable backport problems for those, but that assumes that this (stable kernel component by component testing) is automated (which was a big topic of discussion at the most recent LSF/MM/Storage summit). Obviously distros do this all the time, and backport more than stable would for the more active modules, but there are probably cases where Debian e.g. users would want a module that had various security features backported and so couldn't use stable (because stable would typically not include new features, even if critical)
