Re: [PATCH] bcachefs: Switch to memalloc_flags_do() for vmalloc allocations

[Michal Hocko <mhocko@suse.com>]

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