linux-kernel - Re: [PATCH] bcachefs: Switch to memalloc_flags

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: <Zs959Pa5H5WeY5_i@tiehlicka>
Date: Wed, 28 Aug 2024 21:26:44 +0200
From: Michal Hocko <mhocko@...e.com>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Matthew Wilcox <willy@...radead.org>, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Dave Chinner <dchinner@...hat.com>
Subject: Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc
 allocations

On Wed 28-08-24 15:11:19, Kent Overstreet wrote:
> On Wed, Aug 28, 2024 at 07:48:43PM GMT, Matthew Wilcox wrote:
> > On Wed, Aug 28, 2024 at 10:06:36AM -0400, Kent Overstreet wrote:
> > > vmalloc doesn't correctly respect gfp flags - gfp flags aren't used for
> > > pte allocation, so doing vmalloc/kvmalloc allocations with reclaim
> > > unsafe locks is a potential deadlock.
> > 
> > Kent, the approach you've taken with this was NACKed.  You merged it
> > anyway (!).  Now you're spreading this crap further, presumably in an effort
> > to make it harder to remove.
> 
> Excuse me? This is fixing a real issue which has been known for years.

If you mean a lack of GFP_NOWAIT support in vmalloc then this is not a
bug but a lack of feature. vmalloc has never promissed to support this
allocation mode and a scoped gfp flag will not magically make it work
because there is a sleeping lock involved in an allocation path in some
cases.

If you really need this feature to be added then you should clearly
describe your usecase and listen to people who are familiar with the
vmalloc internals rather than heavily pushing your direction which
doesn't work anyway.

> It was decided _years_ ago that PF_MEMALLOC flags were how this was
> going to be addressed.

Nope! It has been decided that _some_ gfp flags are acceptable to be used
by scoped APIs. Most notably NOFS and NOIO are compatible with reclaim
modifiers and other flags so these are indeed safe to be used that way.

> > Stop it.  Work with us to come up with an acceptable approach.  I
> > think there is one that will work, but you need to listen to the people
> > who're giving you feedback because Linux is too big of a code-base for
> > you to understand everything.
> 
> No, you guys need to stop pushing broken shit.

This is not the way to work with other people. Seriously!

-- 
Michal Hocko
SUSE Labs