On Mon, Nov 30, 2020 at 02:52:11PM +0100, Paolo Bonzini wrote:

On 30/11/20 14:28, Greg KH wrote:

quoted

quoted

quoted

Lines of code is not everything. If you think that this needs additional
testing then that's fine and we can drop it, but not picking up a fix
just because it's 120 lines is not something we'd do.

Starting with the first two steps in stable-kernel-rules.rst:

Rules on what kind of patches are accepted, and which ones are not, into the
"-stable" tree:

  - It must be obviously correct and tested.
  - It cannot be bigger than 100 lines, with context.

We do obviously take patches that are bigger than 100 lines, as there
are always exceptions to the rules here.  Look at all of the
spectre/meltdown patches as one such example.  Should we refuse a patch
just because it fixes a real issue yet is 101 lines long?

Every patch should be "fixing a real issue"---even a new feature.  But the
larger the patch, the more the submitters and maintainers should be trusted
rather than a bot.  The line between feature and bugfix _sometimes_ is
blurry, I would say that in this case it's not, and it makes me question how
the bot decided that this patch would be acceptable for stable (which AFAIK
is not something that can be answered).

I thought that earlier Sasha said that this patch was needed as a
prerequisite patch for a later fix, right?  If not, sorry, I've lost the
train of thought in this thread...

thanks,

greg k-h