bcachefs
patreon
Update: no bcachefs updates for 6.13 confirmed
🕑 Added 2024-11-22 22:25:54 +0000 UTCFixes will have to come from my repository.
This came just as the CoC board seemed to be relenting, and we started to be having a public conversation. That's now been cut off, and I think after the private correspondence we had their action was dishonest.
Here's what I wrote to Michal way back in September (because yes, I was out of line, and yes, that did need to be addressed; but I don't think public mea culpas are the best way to do that).
I do hope something good comes out of all this.
Date: Wed, 4 Sep 2024 14:22:39 -0400
From: Kent Overstreet <kent.overstreet@linux.dev>
To: Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH 1/2 v2] bcachefs: do not use PF_MEMALLOC_NORECLAIM
Message-ID: <5qukfetlxkadrdjp443xlzbyjhw26l3zzgcdlmfkxgbkpkrv65@hobl73hoc5ip>
References: <20240827061543.1235703-1-mhocko@kernel.org>
<Zs6jFb953AR2Raec@dread.disaster.area>
<ylycajqc6yx633f4sh5g3mdbco7zrjdc5bg267sox2js6ok4qb@7j7zut5drbyy>
<ZtBzstXltxowPOhR@dread.disaster.area>
<myb6fw5v2l2byxn4raxlaqozwfdpezdmn3mnacry3y2qxmdxtl@bxbsf4v4qbmg>
<ZtUFaq3vD+zo0gfC@dread.disaster.area>
<nawltogcoffous3zv4kd2eerrrwhihbulz7pi2qyfjvslp6g3f@j3qkqftra2qm>
<ZtV6OwlFRu4ZEuSG@tiehlicka>
<v664cj6evwv7zu3b77gf2lx6dv5sp4qp2rm7jjysddi2wc2uzl@qvnj4kmc6xhq>
<ZtWH3SkiIEed4NDc@tiehlicka>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZtWH3SkiIEed4NDc@tiehlicka>
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
Comments
John-Gee
Kent your story reminds me a lot of Hans' : released something quite fresh but didn't maintain long and moved onto the next big thing promising to change the FS horizon, clashing with the maintainers over various aspects, risking the future of the FS, etc. Maybe this is the fate of FS geniuses... I strongly suggest you read the retrospective Hans wrote in an open letter a year ago or so, maybe what he learned can help you.
veritanuda
Kent, Just try and keep a cool head and don't resort to vulgar insults. It helps no one. Nor respond to any and let other deal with such vulgarity. Be a developer first and a distraction last.
Leonid Shchurov
I hope this all gets sorted out so we can keep getting your amazing contributions to this awesome filesystem in mainline
