linux-kernel - Re: [RFC PATCH 1/2] mempool: do not consume memory reserves from the reclaim path

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]

Message-ID: <20160721121300.GA21806@cmpxchg.org>
Date:	Thu, 21 Jul 2016 08:13:00 -0400
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
	Mikulas Patocka <mpatocka@...hat.com>,
	Ondrej Kozina <okozina@...hat.com>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Mel Gorman <mgorman@...e.de>, Neil Brown <neilb@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, dm-devel@...hat.com
Subject: Re: [RFC PATCH 1/2] mempool: do not consume memory reserves from the
 reclaim path

On Thu, Jul 21, 2016 at 10:52:03AM +0200, Michal Hocko wrote:
> Look, there are
> $ git grep mempool_alloc | wc -l
> 304
> 
> many users of this API and we do not want to flip the default behavior
> which is there for more than 10 years. So far you have been arguing
> about potential deadlocks and haven't shown any particular path which
> would have a direct or indirect dependency between mempool and normal
> allocator and it wouldn't be a bug. As the matter of fact the change
> we are discussing here causes a regression. If you want to change the
> semantic of mempool allocator then you are absolutely free to do so. In
> a separate patch which would be discussed with IO people and other
> users, though. But we _absolutely_ want to fix the regression first
> and have a simple fix for 4.6 and 4.7 backports. At this moment there
> are revert and patch 1 on the table.  The later one should make your
> backtrace happy and should be only as a temporal fix until we find out
> what is actually misbehaving on your systems. If you are not interested
> to pursue that way I will simply go with the revert.

+1

It's very unlikely that decade-old mempool semantics are suddenly a
fundamental livelock problem, when all the evidence we have is one
hang and vague speculation. Given that the patch causes regressions,
and that the bug is most likely elsewhere anyway, a full revert rather
than merely-less-invasive mempool changes makes the most sense to me.