KEYS changes for v7.3-rc7

Hi,

I've started to take steps towards better quality PRs.

Br, Jarkko

The following changes since commit 7704c4c5bb127673b4f0ead839919db573559e38:

Merge tag 'i2c-fixes-7.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux (2026-10-04 09:38:11 -0700)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git tags/keys-v7.3-rc7

for you to fetch changes up to dd3ea3fcba7c75493760cdbccd35f029597e8d5e:

KEYS: Fix add_key() race with keyring restriction (2026-10-04 21:09:32 +0300)

----------------------------------------------------------------
KEYS changes for v7.3-rc7

This pull request contains two critical bug fixes, which can be briefly descibed as follows:

1. key_get_persistent() creates a new persisten keyring for UID if it does not exist yet, and creates a link from it to the nominated keyring. Function did not set timeout when linking failed, therefore preventing GC. The bug was addressed by calling key_set_timeout() regardless of key_link() result when the persistent keyring gets created by key_get_persistent().
2. __key_create_or_update() made a copy of keyring->restrict_link before holding keyring->sem, which can cause add_key() to be executed against stale keyring restrictions. The bug was fixed by copying the value only after keyring->sem was taken.

----------------------------------------------------------------
Karl Mehltretter (1):
keys: finalize persistent keyring timeout after link attempt

성병찬 (1):
KEYS: Fix add_key() race with keyring restriction

 security/keys/key.c        |  6 ++---
 security/keys/persistent.c | 55 +++++++++++++++++++++++++++-------------------
 2 files changed, 35 insertions(+), 26 deletions(-)

Looks better.

It reads like an llm, but that's perfectly acceptable use of tooling. If it was an llm, you can tell it to be a bit less verbose, and that it should prefer imperative voice ("Fix it by" vs "The bug was fixed by")

Linus

Nope, this was not with LLM, honestly :-) I hope it isn't Claude tho because I can't stand it...

I spent just way too much time fitting all the details while keeping then compact as possible and that is what I ended up with. And as I recall saying (I think) previously, I will take a habbit of writing these at the time when I ack the patch.

I also think that while there are situations where I could use an LLM for development, using them for PR would impose a quality risk as it is also the last time to sanity check and drop patches when needed.

Putting things down early and eagerly is probably a right choice and it is best use of the energy spent on review process.

Br, Jarkko