linux-kernel - Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC

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: <vvulqfvftctokjzy3ookgmx2ja73uuekvby3xcc2quvptudw7e@7qj4gyaw2zfo>
Date: Wed, 20 Nov 2024 15:34:58 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Shuah Khan <skhan@...uxfoundation.org>
Cc: Michal Hocko <mhocko@...e.com>, Dave Chinner <david@...morbit.com>, 
	Andrew Morton <akpm@...ux-foundation.org>, Christoph Hellwig <hch@....de>, 
	Yafang Shao <laoar.shao@...il.com>, jack@...e.cz, Christian Brauner <brauner@...nel.org>, 
	Alexander Viro <viro@...iv.linux.org.uk>, Paul Moore <paul@...l-moore.com>, 
	James Morris <jmorris@...ei.org>, "Serge E. Hallyn" <serge@...lyn.com>, 
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, linux-bcachefs@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, 
	"conduct@...nel.org" <conduct@...nel.org>
Subject: Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM

On Wed, Sep 04, 2024 at 12:01:50PM -0600, Shuah Khan wrote:
> On 9/2/24 03:51, Kent Overstreet wrote:
> > On Mon, Sep 02, 2024 at 11:39:41AM GMT, Michal Hocko wrote:
> > > On Mon 02-09-24 04:52:49, Kent Overstreet wrote:
> > > > On Mon, Sep 02, 2024 at 10:41:31AM GMT, Michal Hocko wrote:
> > > > > On Sun 01-09-24 21:35:30, Kent Overstreet wrote:
> > > > > [...]
> > > > > > But I am saying that kmalloc(__GFP_NOFAIL) _should_ fail and return NULL
> > > > > > in the case of bugs, because that's going to be an improvement w.r.t.
> > > > > > system robustness, in exactly the same way we don't use BUG_ON() if it's
> > > > > > something that we can't guarantee won't happen in the wild - we WARN()
> > > > > > and try to handle the error as best we can.
> > > > > 
> > > > > We have discussed that in a different email thread. And I have to say
> > > > > that I am not convinced that returning NULL makes a broken code much
> > > > > better. Why? Because we can expect that broken NOFAIL users will not have a
> > > > > error checking path. Even valid NOFAIL users will not have one because
> > > > > they _know_ they do not have a different than retry for ever recovery
> > > > > path.
> > > > 
> > > > You mean where I asked you for a link to the discussion and rationale
> > > > you claimed had happened? Still waiting on that
> > > 
> > > I am not your assistent to be tasked and search through lore archives.
> > > Find one if you need that.
> > > 
> > > Anyway, if you read the email and even tried to understand what is
> > > written there rather than immediately started shouting a response then
> > > you would have noticed I have put actual arguments here. You are free to
> > > disagree with them and lay down your arguments. You have decided to
> > > 
> > > [...]
> > > 
> > > > Yeah, enough of this insanity.
> > > 
> > > so I do not think you are able to do that. Again...
> > 
> > Michal, if you think crashing processes is an acceptable alternative to
> > error handling _you have no business writing kernel code_.
> > 
> > You have been stridently arguing for one bad idea after another, and
> > it's an insult to those of us who do give a shit about writing reliable
> > software.
> > 
> > You're arguing against basic precepts of kernel programming.
> > 
> > Get your head examined. And get the fuck out of here with this shit.
> > 
> 
> Kent,
> 
> Using language like this is clearly unacceptable and violates the
> Code of Conduct. This type of language doesn't promote respectful
> and productive discussions and is detrimental to the health of the
> community.
> 
> You should be well aware that this type of language and personal
> attack is a clear violation of the Linux kernel Contributor Covenant
> Code of Conduct as outlined in the following:
> 
> https://www.kernel.org/doc/html/latest/process/code-of-conduct.html
> 
> Refer to the Code of Conduct and refrain from violating the Code of
> Conduct in the future.

I believe Michal and I have more or less worked this out privately (and
you guys have been copied on that as well).