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] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 14 Apr 2022 04:23:13 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     "Alex Xu (Hello71)" <alex_y_xu@...oo.ca>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Daniel Colascione <dancol@...gle.com>,
        linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH] mm/smaps_rollup: return empty file for kthreads instead
 of ESRCH

On Wed, Apr 13, 2022 at 04:06:13PM -0700, Andrew Morton wrote:
> On Wed, 13 Apr 2022 18:25:53 -0400 "Alex Xu (Hello71)" <alex_y_xu@...oo.ca> wrote:
> > > 258f669e7e88 was 4 years ago, so I guess a -stable backport isn't
> > > really needed.
> > 
> > Current behavior (4.19+):
[...]
> > Pre-4.19 and post-patch behavior:
> 
> I don't think this will work very well.  smaps_rollup is the sort of
> system tuning thing for which organizations will develop in-house
> tooling which never get relesaed externally.
> 
> > 3. As mentioned previously, this was already the behavior between 4.14 
> >    and 4.18 (inclusive).
> > 
> 
> Yup.  Hm, tricky.  I'd prefer to leave it alone if possible.  How
> serious a problem is this, really?  

I don't think "It's been like this for four years" is as solid an argument
as you might like.  Certain distributions (of the coloured millinery
variety, for example) haven't updated their kernel since then and so
there may well be many organisations who have not been exposed to the
current behaviour.  Even my employers distribution, while it offers a
5.4 based kernel, still has many customers who have not moved from the
4.14 kernel.  Inertia is a real thing, and restoring this older behaviour
might well be an improvement.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ