Message-ID: <3ij22qnqpndxyckrdreswyxjaan3zudzdkv62vjeeytsep5bmz@5el2tljyx7wc>
Date: Wed, 20 Nov 2024 19:10:25 -0500
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Theodore Ts'o <tytso@....edu>
Cc: Shuah Khan <skhan@...uxfoundation.org>, 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 03:47:59PM -0800, Theodore Ts'o wrote:
> On Wed, Nov 20, 2024 at 05:55:03PM -0500, Kent Overstreet wrote:
> > Shuah, would you be willing to entertain the notion of modifying your...
> 
> Kent, I'd like to gently remind you that Shuah is not speaking in her
> personal capacity, but as a representative of the Code of Conduct
> Committee[1], as she has noted in her signature.  The Code of Conduct
> Committee is appointed by, and reports to, the TAB[2], which is an
> elected body composed of kernel developers and maintainers.
> 
> [1] https://www.kernel.org/code-of-conduct.html
> [2] https://www.kernel.org/doc/html/latest/process/code-of-conduct-interpretation.html
> 
> Speaking purely in a personal capacity, and not as a member of the TAB
> (although I do serve as vice-chair of that body) I am extremely
> grateful of the work of Shuah and her colleages (listed in [1]).  I
> believe that their work is important in terms of establishing guard
> rails regarding the minimum standards of behavior in our community.
> 
> If you look at the git history of the kernel sources, you will see
> that a large number of your fellow maintainers assented to this
> approach --- for example by providing their Acked-by in commit
> 1279dbeed36f ("Code of Conduct Interpretation: Add document explaining
> how the Code of Conduct is to be interpreted").

And Ted, I don't think you realize just how at my limit I am here with
what I'm willing to put up with.

I'm coming off of, what, 6+ months of getting roasted and having my work
quested by Linus every pull request (and he did stop that, but not
before it had done real damage, both completely changing the tone of
public conversations and nearly scaring off people I've been trying to
hire).

It's gotten harder and harder, not easier, for me to get work done in
other parts of the kernel; I gave up long ago in the block layer after
the two people in charge there had repeatedly introduced silent data
corruption bugs into core block layer code that I'd written, without
CCing me, which I then had to debug, which they then ignored or put up
ridiculous fights over when reported, and now have turned petty on
subsequent block layer patches.

Filesystem people have been good to work with, thank god, but now
getting anything done in mm is looking like more and more of what the
block layer has turned into.

And you guys, because the system works for you, keep saying "nah,
everything is fine and this has already been decided, you don't get any
say".

Meanwhile, I'm seeing more and more heisenbugs in the rest of the kernel
as I'm stabilizing bcachefs, and my users are reporting the same - in
compaction, in the block layer, now in the scheduler or locking, I'm not
sure on the last one.

And I'm sitting here wondering how the hell I'm supposed to debug my own
code when I don't even have a stable base to work on anymore.

This is turning into an utter farce.

Powered by blists - more mailing lists