On 23/12/2017 10:24, Greg Kroah-Hartman wrote: > For many subsystems, the maintainers _never_ mark patches for stable. > Others, they catch maybe half of the things they should be applying. > > KVM is one such example of the "half" group, they mark patches as > resolving CVE issues at times, yet don't mark them for stable. So when > I see a patch like this, it triggers the "oh, look, KVM doing the same > thing again", so I take the patch and of course cc: the > developers/maintainers so they can object if they want to. In general there are some cases where I tend to be conservative on applying the "stable" tag, for example: 1) sometimes I'm not very familiar with API changes in the other subsystems (this was the case for this patch). If I am not sure of the amount of backporting effort required, and the bug is not super important, I don't mark it as stable because I don't want to later drop a complex backport on the floor. I prefer to have fewer patches applied, but know that the fixes are backported to all branches. 2) not all bugs are equal; a WARN_ON_ONCE from a syzkaller testcase for example doesn't really matter to a cloud provider that uses KVM, because invalid API usage is not controlled by the customer. But an oops or BUG_ON probably *will* get CCed to stable. So some patches for syzkaller bugs may be CCed, some may not. IIRC the CVE that you mention was a guest user->kernel escalation, but it didn't affect Linux guests at all, and it couldn't be fixed completely on Windows guests because Windows has another bug in the same area. Plus, I knew there would be different conflicts on all LTS branches, so I decided to not mark it for stable. I did dutifully provide a backport when someone (either you or Ben Hutchings) asked for one, though. It does happen that Radim or I forget to Cc stable, so I'm okay with you picking up more patches than what I mark and I will happily do the backports for you. Still, there is some thought put into whether to CC stable or not. :) Thanks, Paolo > Over time you get to know what subsystems are like this and what are > not. MM is one that is really good, I almost never take a mm patch > without being told explicitly to do so. Others are horrible and never > mark anything, so stuff has to be picked up manually through Sasha's > process or through other ways. > > So it's not a perfect system, but it seems to work "good enough", and if > you ever have any questions about any patch, always feel free to ask, > there's usually a story behind almost every one...