Message-ID: <v2ur4jcqvjc4cqdbllij5gh6inlsxp3vmyswyhhjiv6m6nerxq@mrekyulqghv2>
Date: Wed, 20 Nov 2024 17:55:03 -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, Nov 20, 2024 at 05:39:19PM -0500, Kent Overstreet wrote:
> On Wed, Nov 20, 2024 at 03:21:06PM -0700, Shuah Khan wrote:
> > On 11/20/24 14:37, Shuah Khan wrote:
> > > On 11/20/24 14:20, Kent Overstreet wrote:
> > > > On Wed, Nov 20, 2024 at 02:12:12PM -0700, Shuah Khan wrote:
> > > > > On 11/20/24 13:34, Kent Overstreet wrote:
> > > > > > 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).
> > > > > 
> > > > > Thank you for updating us on the behind the scenes work between you
> > > > > and Michal.
> > > > > 
> > > > > I will make one correction to your statement, "you guys have been copied on
> > > > > that as well" - which is inaccurate. You have shared your email exchanges
> > > > > with Michal with us to let us know that the issue has been sorted out.
> > > > 
> > > > That seems to be what I just said.
> > > > 
> > > > > You might have your reasons and concerns about the direction of the code
> > > > > and design that pertains to the discussion in this email thread. You might
> > > > > have your reasons for expressing your frustration. However, those need to be
> > > > > worked out as separate from this Code of Conduct violation.
> > > > > 
> > > > > In the case of unacceptable behaviors as defined in the Code of Conduct
> > > > > document, the process is to work towards restoring productive and
> > > > > respectful discussions. It is reasonable to ask for an apology to help
> > > > > us get to the goal as soon as possible.
> > > > > 
> > > > > I urge you once again to apologize for using language that negatively impacts
> > > > > productive discussions.
> > > > 
> > > > Shuah, I'd be happy to give you that after the discussion I suggested.
> > > > Failing that, I urge you to stick to what we agreed to last night.
> > The only thing we agreed upon is that you would respond the thread
> > to update your sorting things out with Michal.
> 
> ...Shall I quote you?
> 
> > 
> > As for the discussion, I will repeat what I said in our conversation
> > that the discussion will be lot more productive after making amends
> > with the community. I stand by that assessment.
> > 
> > I will also repeat what I said that the discussion and debate is
> > outside the scope of the current issue the Code of Conduct Committee
> > is trying to resolve.
> > 
> > I didn't pick up on your desire to apologize after the discussion in
> > our conversation.
> > 
> > Are you saying you will be happy to make amends with an apology after
> > the discussion and debate?
> 
> Look, I just want to be done with this, so let me lay it all out as I
> see it, starting from the beginning of where things went off the rails
> between myself and Michal:
> 
> Michal's (as well as Steve's) behaviour in the memory allocation
> profiling review process was, in my view, unacceptable (this included
> such things as crashing our LSF presentation with ideas they'd come up
> with that morning, and persistent dismissive axegrinding on the list).
> The project was nearly killed because of his inability to listen to the
> reasons for a design and being stubbornly stuck on his right to be heard
> as the maintainer.
> 
> In my view, being a good maintainer has a lot more to do with
> stewardship and leadership, than stubbornly insisting for - whatever
> that was. In any event, that was where I came to the conclusion "I just
> cannot work that guy".
> 
> Next up, PF_MEMALLOC_NORECLAIM over Michal's nack - I was wrong there, I
> only did it because it really seemed to me that Michal was axe grinding
> against _anything_ I was posting, but I still shouldn't have and that
> was more serious infraction in my view; that sort of thing causes a real
> loss of trust, and no I will not do it again.
> 
> The subsequent PF_MEMALLOC_NORECLAIM discussion was such a trainwreck
> that I don't think I will go into it. Except to say that yes, if it
> makes you happy, I shouldn't have used that language and I won't do it
> again.
> 
> But I do have to call out you, the CoC board's behaviour, and I think
> that ony fair since you call out other people's behaviour publically.
> 
> Greg's behaviour when he approached me at Plumbers was beyond
> unprofessional, and since it wasn't exactly public and you guys have
> already heard about it privately I won't repeat exactly what happened,
> but it is an issue.
> 
> Shuah, you weren't much better.
> 
> There were concerns raised in the recent CoC enforcement thread, by
> someone with experience in such matters, that your aproach seemed
> extremeely heavy handed and I find myself in 100% agreement.
> 
> The approach you take is that of a bad HR department: all about image,
> no understanding. When tensions arise, it's important get to the bottom
> of things, to at least try to take the time to listen with an open mind.
> People have real frustrations, and it's amazing what you can learn and
> what you can accomplish by having real conversations.
> 
> But that's not what you guys do: you say "Ok, if someone's being too
> much of an asshole, we'll just be an even bigger asshole!".
> 
> No. Cut that out.
> 
> I've done the hard work of stepping in and building bridges when
> relations have broken down (on quite a large scale), so I'm offended by
> what you guys do.

Now, I've said two things I'll do differently, or not do in the future.

Michal, would you be willing to consider changing your approach a bit in
similar situations? Try to lead a little bit less by "I'm the mainainer,
my concerns must be addressed" and a little bit more by incorporating
the best of everyone's ideas, and showing respect to others who have
studied their problems, as you want to be respected as maintainer?

Shuah, would you be willing to entertain the notion of modifying your
approach a bit as well? More in the direction of genuine conversations
and understanding, less of just following a process and slapping people
if they don't comply?

We've got people in the community who are good at this sort of thing,
and might be willing to help if they were asked - it doesn't have to
just be you guys, and if we started encouraging this sort of thing it
could be a real learning experience for everyone.

Powered by blists - more mailing lists