linux-kernel - Re: [PATCH AUTOSEL 6.1 12/21] fs/super.c: stop calling fscrypt_destroy_keyring() from __put

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Feb 2023 21:30:37 -0800
From:   Eric Biggers <ebiggers@...nel.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        viro@...iv.linux.org.uk, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 6.1 12/21] fs/super.c: stop calling
 fscrypt_destroy_keyring() from __put_super()

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@...gle.com>
> > 
> > [ Upstream commit ec64036e68634231f5891faa2b7a81cdc5dcd001 ]
> > 
> > Now that the key associated with the "test_dummy_operation" mount option
> > is added on-demand when it's needed, rather than immediately when the
> > 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 to be
> > a sleep-in-atomic bug (though it wasn't, for a somewhat-subtle reason).
> > 
> > Signed-off-by: Eric Biggers <ebiggers@...gle.com>
> > Link: https://lore.kernel.org/r/20230208062107.199831-5-ebiggers@kernel.org
> > Signed-off-by: Sasha Levin <sashal@...nel.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 individually?
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 backport if
I find out after the fact that one is needed.  (And other real people can always
ask too... not counting AUTOSEL, even though you are sending the AUTOSEL 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 bisecting, e.g.
https://lore.kernel.org/stable/20220921155332.234913-7-sashal@kernel.org.

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 response 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 know that I
won't be reviewing any AUTOSEL mails for my commits anymore.

- Eric