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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <xxs3s22qmlzby3ligct7x5a3fbzzjfdqqt7unmpih64dk3kdyx@vml4m27gpujw>
Date: Wed, 28 Aug 2024 18:58:43 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Michal Hocko <mhocko@...e.com>
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, Aug 28, 2024 at 09:26:44PM GMT, Michal Hocko wrote:
> 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.

Michal, I'm plenty familiar with the vmalloc internals. Given that you
didn't even seem to be aware of how it doesn't respect gfp flags, you
seem to be the person who hasn't been up to speed in this discussion.

> > 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.

Decided by who?

Cite the list discussion, and the reasoning.

> > > 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!

No, your patches and the reasoning you've been pushing are broken.

A safe interface is not one that "does not fail", a safe interface is
one that never invokes undefined behaviour - and generally that means
it'll return an error instead.

And programming in the kernel means that you check for errors, period.

This idea that you have of "safety" meaning "we'll just conveniently
remove or ignore the cases where GFP_NOFAIL would have to fail" is
complete and utter garbage.