lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 1 Nov 2018 22:45:28 +0100
From:   Pavel Machek <pavel@....cz>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     Hugh Dickins <hughd@...gle.com>, Jan Kara <jack@...e.cz>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>
Subject: Re: [PATCH 4.4 50/92] mm: filemap: avoid unnecessary calls to
 lock_page when waiting for IO to complete during a read

Hi!

> > > > I've no wish to be disputatious, but it does seem that the definition of
> > > > "stable" has changed, and not necessarily for the better, if it's now a
> > > > home for small gains: I thought we left those to upstream.
> > 
> > > This is in the SLES kernel for a reason, and again, it's in the section
> > > that says "this should be pushed to stable".  So if it's good enough for
> > > the SLES kernel, why isn't it good enough for all users of this kernel
> > > tree?
> > 
> > > If you all think it should be dropped in both places, that's fine with
> > > me :)
> > 
> > I think they are perfectly fine in SLES: folding in good work is a part of
> > what distros are about.
> 
> And it's also what stable is for.  We have had backports of performance
> improvements in the past, along with lots of other things over the
> years.  This is a performance improvement.  A tiny one, yes, but getting
> rid of a lock is a good thing, and I picked it up as part of my review
> of what a distro decided was worth adding for their users, as that's a
> huge signal that might be of value to others.
> 
> > But I cannot find anything in stable-kernel-rules.rst that would admit them
> > - perhaps that's just out of date?
> 
> Nope, that's the list I use to say "no" to.  You can't describe
> everything in that file, it's a judgement call.

Well, it would be good if the documentation matched reality, because other people
use the documentation to decide, too.

For example, documentation says bug has to be fixed in mainline, but in actual practice
you try to have exactly the same patch.

										Pavel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ