[GIT PULL] KEYS changes for v7.3-rc7

[GIT PULL] KEYS changes for v7.3-rc7

[Jarkko Sakkinen]

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.

Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>

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

Re: [GIT PULL] KEYS changes for v7.3-rc7

[Linus Torvalds]

On Tue, 6 Oct 2026 at 00:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> I've started to take steps towards better quality PRs.

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

Re: [GIT PULL] KEYS changes for v7.3-rc7

[pr-tracker-bot]

The pull request you sent on Tue, 6 Oct 2026 01:46:40 +0300:

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

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2c3418fffa9d037b2038a6db48be63f9e2291806

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] KEYS changes for v7.3-rc7

[Jarkko Sakkinen]

On Tue, Oct 06, 2026 at 05:03:42AM +0200, Linus Torvalds wrote:
> On Tue, 6 Oct 2026 at 00:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > I've started to take steps towards better quality PRs.
> 
> 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")

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.

> 
>                 Linus

Br, Jarkko