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
| ||
|
Message-ID: <20150221213807.GI12722@dastard> Date: Sun, 22 Feb 2015 08:38:07 +1100 From: Dave Chinner <david@...morbit.com> To: Andrew Morton <akpm@...ux-foundation.org> Cc: Theodore Ts'o <tytso@....edu>, Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, hannes@...xchg.org, mhocko@...e.cz, dchinner@...hat.com, linux-mm@...ck.org, rientjes@...gle.com, oleg@...hat.com, mgorman@...e.de, torvalds@...ux-foundation.org, xfs@....sgi.com, linux-ext4@...r.kernel.org Subject: Re: How to handle TIF_MEMDIE stalls? On Sat, Feb 21, 2015 at 01:19:07AM -0800, Andrew Morton wrote: > On Fri, 20 Feb 2015 22:20:00 -0500 "Theodore Ts'o" <tytso@....edu> wrote: > > > +akpm > > I was hoping not to have to read this thread ;) ditto.... > And yes, I agree that sites such as xfs's kmem_alloc() should be > passing __GFP_NOFAIL to tell the page allocator what's going on. I > don't think it matters a lot whether kmem_alloc() retains its retry > loop. If __GFP_NOFAIL is working correctly then it will never loop > anyway... I'm not about to change behaviour "just because". Any sort of change like this requires a *lot* of low memory regression testing because we'd be replacing long standing known behaviour with behaviour that changes without warning. e.g the ext4 low memory failures starting because of changes made in 3.19-rc6 due to changes in oom-killer behaviour. Those changes *did not affect XFS* and that's the way I'd like things to remain. Put simply: right now I don't trust the mm subsystem to get low memory behaviour right, and this thread has done nothing to convince me that it's going to improve any time soon. > Also, this: > > On Wed, 18 Feb 2015 09:54:30 +1100 Dave Chinner <david@...morbit.com> wrote: > > > Right now, the oom killer is a liability. Over the past 6 months > > I've slowly had to exclude filesystem regression tests from running > > on small memory machines because the OOM killer is now so unreliable > > that it kills the test harness regularly rather than the process > > generating memory pressure. > > David, I did not know this! If you've been telling us about this then > perhaps it wasn't loud enough. IME, such bug reports get ignored. Instead, over the past few months I have been pointing out bugs and problems in the oom-killer in threads like this because it seems to be the only way to get any attention to the issues I'm seeing. Bug reports simply get ignored. From this process, I've managed to learn that low order memory allocation now never fails (contrary to documentation and long standing behavioural expectations) and pointed out bugs that cause the oom killer to get invoked when the filesystem is saying "I can handle ENOMEM!" (commit 45f87de ("mm: get rid of radix tree gfp mask for pagecache_get_page"). And yes, I've definitely mentioned in these discussions that, for example, xfstests::generic/224 is triggering the oom killer far more often than it used to on my 1GB RAM vm. The only fix that has been made recently that's made any difference is 45f87de, so it's a slow process of raising awareness and trying to ensure things don't get worse before they get better.... Cheers, Dave. -- Dave Chinner david@...morbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists