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:   Mon, 27 Feb 2023 09:18:59 -0500
From:   Sasha Levin <sashal@...nel.org>
To:     Eric Biggers <ebiggers@...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 Sun, Feb 26, 2023 at 11:24:36AM -0800, Eric Biggers 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@...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.

Yup, no problem - I'll ignore any commits authored by you.

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

One of the challanges here is that it's difficult to solicit reviews or
really any interaction from authors after a commit lands upstream. Look
at the response rates to Greg's "FAILED" emails that ask authors to
provide backports to commits they tagged for stable.

>> 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.
>>
>
>The really annoying thing is that someone even replied to your AUTOSEL email for
>that broken patch and told you it is broken
>(https://lore.kernel.org/stable/d91aaff1-470f-cfdf-41cf-031eea9d6aca@mailbox.org),
>and ***you ignored it and applied the patch anyway***.
>
>Why are you even sending these emails if you are ignoring feedback anyway?

I obviously didn't ignore it on purpose, right?

-- 
Thanks,
Sasha