MIME-Version: 1.0
References: <20230226034256.771769-1-sashal@kernel.org> <20230226034256.771769-12-sashal@kernel.org>
 <Y/rbGxq8oAEsW28j@sol.localdomain> <Y/rufenGRpoJVXZr@sol.localdomain> <Y/ux9JLHQKDOzWHJ@sol.localdomain>
In-Reply-To: <Y/ux9JLHQKDOzWHJ@sol.localdomain>
From:   Slade Watkins <srw@sladewatkins.net>
Date:   Sun, 26 Feb 2023 14:33:22 -0500
Message-ID: <CA+pv=HONnqX-mv9aieRAqbVnzUL70=cVE+H5ZwW855nVuRph1w@mail.gmail.com>
Subject: Re: [PATCH AUTOSEL 6.1 12/21] fs/super.c: stop calling
 fscrypt_destroy_keyring() from __put_super()
To:     Eric Biggers <ebiggers@kernel.org>
Cc:     Sasha Levin <sashal@kernel.org>, linux-kernel@vger.kernel.org,
        stable@vger.kernel.org, viro@zeniv.linux.org.uk,
        linux-fsdevel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Feb 26, 2023 at 2:24=E2=80=AFPM Eric Biggers <ebiggers@kernel.org> =
wrote:
>
> On Sat, Feb 25, 2023 at 09:30:37PM -0800, Eric Biggers wrote:
> > On Sat, Feb 25, 2023 at 08:07:55PM -0800, Eric Biggers wrote:
> > > On Sat, Feb 25, 2023 at 10:42:47PM -0500, Sasha Levin wrote:
> > > > From: Eric Biggers <ebiggers@google.com>
> > > >
> > > > [ Upstream commit ec64036e68634231f5891faa2b7a81cdc5dcd001 ]
> > > >
> > > > Now that the key associated with the "test_dummy_operation" mount o=
ption
> > > > is added on-demand when it's needed, rather than immediately when t=
he
> > > > filesystem is mounted, fscrypt_destroy_keyring() no longer needs to=
 be
> > > > called from __put_super() to avoid a memory leak on mount failure.
> > > >
> > > > Remove this call, which was causing confusion because it appeared t=
o be
> > > > a sleep-in-atomic bug (though it wasn't, for a somewhat-subtle reas=
on).
> > > >
> > > > Signed-off-by: Eric Biggers <ebiggers@google.com>
> > > > Link: https://lore.kernel.org/r/20230208062107.199831-5-ebiggers@ke=
rnel.org
> > > > Signed-off-by: Sasha Levin <sashal@kernel.org>
> > >
> > > Why is this being backported?
> > >
> > > - Eric
> >
> > BTW, can you please permanently exclude all commits authored by me from=
 AUTOSEL
> > so that I don't have to repeatedly complain about every commit individu=
ally?
> > Especially when these mails often come on weekends and holidays.
> >
> > I know how to use Cc stable, and how to ask explicitly for a stable bac=
kport if
> > I find out after the fact that one is needed.  (And other real people c=
an always
> > ask too... not counting AUTOSEL, even though you are sending the AUTOSE=
L emails,
> > since clearly they go through no or very little human review.)
> >
> > Of course, it's not just me that AUTOSEL isn't working for.  So, you'll=
 still
> > continue backporting random commits that I have to spend hours bisectin=
g, e.g.
> > https://lore.kernel.org/stable/20220921155332.234913-7-sashal@kernel.or=
g.
> >
> > But at least I won't have to deal with this garbage for my own commits.
> >
> > Now, I'm not sure I'll get a response to this --- I received no respons=
e to my
> > last AUTOSEL question at
> > https://lore.kernel.org/stable/Y1DTFiP12ws04eOM@sol.localdomain.  So to
> > hopefully entice you to actually do something, I'm also letting you kno=
w that I
> > won't be reviewing any AUTOSEL mails for my commits anymore.
> >
>
> The really annoying thing is that someone even replied to your AUTOSEL em=
ail for
> that broken patch and told you it is broken
> (https://lore.kernel.org/stable/d91aaff1-470f-cfdf-41cf-031eea9d6aca@mail=
box.org),
> and ***you ignored it and applied the patch anyway***.
>
> Why are you even sending these emails if you are ignoring feedback anyway=
?
>
> How do I even get you to not apply a patch?  Is it even possible?
>
> I guess I might as well just add an email filter that auto-deletes all AU=
TOSEL
> emails, as apparently there's no point in responding anyway?

I test this branch for Greg but don't pay attention to these emails
Sasha sends out (because there's just waaaaay too many of them to look
through unless they get a reply; I find them quite annoying
otherwise.) But if these commits automatically get applied to stable
trees, even with objections from the committers, then I personally
question the methodology for having AUTOSEL in the first place.
Commits should be tested and backported with explicit purpose by their
developers, IMO.

-- Slade