From: Jarkko Sakkinen <jarkko@kernel.org>
To: Paul Moore <paul@paul-moore.com>, Eric Biggers <ebiggers@kernel.org>
Cc: David Howells <dhowells@redhat.com>,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
syzkaller-bugs@googlegroups.com,
syzbot
<syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com>
Subject: Re: [syzbot] Monthly lsm report (Apr 2026)
Date: Sun, 10 May 2026 07:02:36 +0300 [thread overview]
Message-ID: <agADXEjqD2X8XWN1@kernel.org> (raw)
In-Reply-To: <CAHC9VhS2AaRwAQw1hNcpuGdFSOL7Li9PavKtU7eW-w8eMOFuKA@mail.gmail.com>
On Tue, Apr 14, 2026 at 10:02:13AM -0400, Paul Moore wrote:
> > <2> 68 Yes possible deadlock in keyring_clear (3)
> > https://syzkaller.appspot.com/bug?extid=f55b043dacf43776b50c
>
> Jarkko, David,
>
> Do we have a fix for the keyring_clear() issue, or is it not a real problem?
Sorry for not meeting the timeline I promised.
Anyhow, let's on the issue.
There's really just two alternatives to resolve [1]:
A. balance_pgdat() acquires keyring semaphore before __fs_reclaim_acquire(),
and a non-locking-acquiring aking __keyring_clear() would be called
inside fscrypt_put_master_key().
B. keyring_clear() is deferred and we accept that quota is not
immediately released.
Fixing this from the user process side doing kzalloc() is of course unrealistic,
and unstable fix.
So.. I don't think this is keyring issue per se. This is fscrypt issue
mainly, aand depending on whether A or B are used to sort this out,
possibly also kswapd issue.
Or this is my analysis (which could be wrong of course) after couple
hours looking into it.
[1] https://lore.kernel.org/all/68e54915.a00a0220.298cc0.0480.GAE@google.com/T/
BR, Jarkko
prev parent reply other threads:[~2026-05-10 4:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-14 6:40 [syzbot] Monthly lsm report (Apr 2026) syzbot
2026-04-14 13:59 ` Paul Moore
2026-04-14 15:42 ` Roberto Sassu
2026-04-14 14:02 ` Paul Moore
2026-04-15 2:51 ` Jarkko Sakkinen
2026-04-15 16:35 ` Jarkko Sakkinen
2026-05-10 4:02 ` Jarkko Sakkinen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=agADXEjqD2X8XWN1@kernel.org \
--to=jarkko@kernel.org \
--cc=dhowells@redhat.com \
--cc=ebiggers@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=syzbot+liste5004e02dae137bbd339@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.