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
| ||
|
Date: Fri, 16 Dec 2016 16:58:06 +0100 From: Michal Hocko <mhocko@...nel.org> To: Nils Holland <nholland@...ys.org> Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org, Chris Mason <clm@...com>, David Sterba <dsterba@...e.cz>, linux-btrfs@...r.kernel.org Subject: Re: OOM: Better, but still there on On Fri 16-12-16 08:39:41, Michal Hocko wrote: [...] > That being said, the OOM killer invocation is clearly pointless and > pre-mature. We normally do not invoke it normally for GFP_NOFS requests > exactly for these reasons. But this is GFP_NOFS|__GFP_NOFAIL which > behaves differently. I am about to change that but my last attempt [1] > has to be rethought. > > Now another thing is that the __GFP_NOFAIL which has this nasty side > effect has been introduced by me d1b5c5671d01 ("btrfs: Prevent from > early transaction abort") in 4.3 so I am quite surprised that this has > shown up only in 4.8. Anyway there might be some other changes in the > btrfs which could make it more subtle. > > I believe the right way to go around this is to pursue what I've started > in [1]. I will try to prepare something for testing today for you. Stay > tuned. But I would be really happy if somebody from the btrfs camp could > check the NOFS aspect of this allocation. We have already seen > allocation stalls from this path quite recently Could you try to run with the two following patches?
Powered by blists - more mailing lists