All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: Luis Henriques <lhenriques@suse.de>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] keys: flush work when accessing /proc/key-users
Date: Mon, 11 Dec 2023 19:03:04 -0800	[thread overview]
Message-ID: <20231212030304.GA39443@sol.localdomain> (raw)
In-Reply-To: <2744563.1702303367@warthog.procyon.org.uk>

On Mon, Dec 11, 2023 at 02:02:47PM +0000, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > If there was a function that fully and synchronously releases a key's quota,
> > fs/crypto/ could call it before unlinking the key.  key_payload_reserve(key,
> > 0) almost does the trick, but it would release the key's bytes, not the key
> > itself.
> 
> Umm...  The point of the quota is that the key is occupying unswappable kernel
> memory (partly true in the case of big_key) and we need to limit that.
> Further, the key is not released until it is unlinked.

Well, fs/crypto/ no longer uses the keyrings subsystem for the actual keys, as
that was far too broken.  It just ties into the quota now.  So what's needed is
a way to release quota synchronously.

That might just mean not using the keyrings subsystem at all anymore.

> Do we need faster disposal of keys?  Perhaps keeping a list of keys that need
> destroying rather than scanning the entire key set for them.  We still need to
> scan non-destroyed keyrings, though, to find the pointers to defunct keys
> unless I have some sort of backpointer list.

If it's still asynchronous, that doesn't solve the problem.

- Eric

  reply	other threads:[~2023-12-12  3:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-06 14:57 [RFC PATCH] keys: flush work when accessing /proc/key-users Luis Henriques
2023-12-06 16:04 ` David Howells
2023-12-06 17:55   ` Luis Henriques
2023-12-07  2:43     ` Eric Biggers
2023-12-11 14:02       ` David Howells
2023-12-12  3:03         ` Eric Biggers [this message]
2023-12-14 14:44         ` Luís Henriques
2024-01-15 12:03         ` [RFC PATCH v2] keys: update key quotas in key_put() Luis Henriques
2024-01-19 21:10           ` Jarkko Sakkinen
2024-01-22 11:50             ` Luis Henriques
2024-01-22 19:45               ` Jarkko Sakkinen
2024-01-24 22:12           ` Eric Biggers
2024-01-26 16:12             ` Luis Henriques
2024-01-27  6:42               ` Eric Biggers
2024-01-29 11:23                 ` Luis Henriques
2023-12-07  4:33 ` [RFC PATCH] keys: flush work when accessing /proc/key-users Jarkko Sakkinen

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=20231212030304.GA39443@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=jarkko@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=lhenriques@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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.