[PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM

[Kent Overstreet]

On Fri, Nov 22, 2024 at 01:48:42PM -0800, Dan Williams wrote:
> 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:
> [..]
> 
> Kent,
> 
> The Code of Conduct Committee received reports about your conduct in
> this email discussion.
> 
> Link to email where the violation took place:
> 
> https://lore.kernel.org/citv2v6f33hoidq75xd2spaqxf7nl5wbmmzma4wgmrwpoqidhj@k453tmq7vdrk
> 
> Our community works on trust and respect and has agreed to abide by the
> Code of Conduct:
> 
> Reference: https://docs.kernel.org/process/code-of-conduct.html
> 
> The code of Conduct Committee has determined that your written abuse
> of another community member required action on your part to repair the
> damage to the individual and the community. You took insufficient action
> to restore the community's faith in having otherwise productive technical
> discussions without the fear of personal attacks.
> 
> Following the Code of Conduct Interpretation process the TAB has approved
> has approved the following recommendation:
> 
> -- Restrict Kent Overstreet's participation in the kernel development
>    process during the Linux 6.13 kernel development cycle.
> 
>        - Scope: Decline all pull requests from Kent Overstreet during
>          the Linux 6.13 kernel development cycle.

Ok.

Just to be clear on what this is about though, I'm going to post
publically what I wrote Michal back in September.

This is about a CoC board that on the one hand, doesn't wish to follow
its own rules, and on the other - I can't even make sense of.

>From kent.overstreet at linux.dev Wed Sep  4 14:22:39 2024
Date: Wed, 4 Sep 2024 14:22:39 -0400
From: Kent Overstreet <kent.overstreet at linux.dev>
To: Michal Hocko <mhocko at suse.com>
Subject: Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM
Message-ID: <5qukfetlxkadrdjp443xlzbyjhw26l3zzgcdlmfkxgbkpkrv65 at hobl73hoc5ip>
References: <20240827061543.1235703-1-mhocko at kernel.org>
 <Zs6jFb953AR2Raec at dread.disaster.area>
 <ylycajqc6yx633f4sh5g3mdbco7zrjdc5bg267sox2js6ok4qb at 7j7zut5drbyy>
 <ZtBzstXltxowPOhR at dread.disaster.area>
 <myb6fw5v2l2byxn4raxlaqozwfdpezdmn3mnacry3y2qxmdxtl at bxbsf4v4qbmg>
 <ZtUFaq3vD+zo0gfC at dread.disaster.area>
 <nawltogcoffous3zv4kd2eerrrwhihbulz7pi2qyfjvslp6g3f at j3qkqftra2qm>
 <ZtV6OwlFRu4ZEuSG at tiehlicka>
 <v664cj6evwv7zu3b77gf2lx6dv5sp4qp2rm7jjysddi2wc2uzl at qvnj4kmc6xhq>
 <ZtWH3SkiIEed4NDc at tiehlicka>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZtWH3SkiIEed4NDc at tiehlicka>
Status: RO
Content-Length: 4224
Lines: 88

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

BTW - (after getting emails for three different people about this, heh)

I do want to apologize for things getting this heated the other day, but
I need to also tell you why I reacted the way I did.

Firstly, it's nothing personal: I'm not axe grinding against you
(although you were a major source of frustration for myself and Suren in
the memory allocation profiling discussions, and I hope you can
recognize that as well).

But I do take correctness issues very seriously, and I will get frosty
or genuinely angry if they're being ignored or brushed aside.

The reality as that experience, and to be frank standards of
professionalism, do vary within the kernel community, and I have had
some _outrageous_ fights over things as bad as silent data corruption
bugs (introduced in code I wrote by people who did not CC me, no less;
it was _bad_, and yes it has happened more than once). So - I am _not_
inclined to let things slide, even if it means being the asshole at
times.

Thankfully, most people aren't like that. Dave, Willy, Linus - we can be
shouting at each other, but we still listen, and we know how not to take
it personally and focus on the technical when there's something serious
going on.

Usually when one of us is shouting, you'll find there's a good reason
and some history behind it, even if we also recognize the need to try to
tone things down and not be _too_ much of an asshole. Linus was
reminding me of that yesterday...

So for the record: I'm not trying to roadblock you or anyone else, I'm
just trying to make sure we all have shit that _works_.

And I have been noticing you stepping up in discussions more, and I'd
like to encourage that, if I may. MM has been lacking in strong
technical leadership for a _long_ time - Andrew's great on the process
side, he makes sure things move along, but we haven't had anyone who's
trying to keep everything important in their heads, who's able to point
out to people where their work fits in the larger picture, and there's
been some messy things that have built up over time.

And a word on technical leadership - it doesn't mean being the one who's
"right" all the time, although it does involve a lot of saying "no" to
people. The people who seem the smartest - it's not raw IQ that they've
got (although that helps!), it's the ability to listen and quickly
incorporate other people's ideas without drama or attachment, and the
ability to maintain perspective; notice what people are blocked on,
without getting stuck on it, and think about how it fits into the wider
perspective.

Cheers,
Kent