Re: [GIT PULL for v7.4] vfs keyring

[Christian Brauner <brauner@kernel.org>]

On Mon, Oct 26, 2026 at 10:10:54AM -0400, James Bottomley wrote:
> On Sat, 2026-10-24 at 12:44 +0200, Christian Brauner wrote:
> > Hey Linus,
> > 
> > This is a delayed pull request which was waiting for the bpf merge.
> > This used a shared branch.
> > 
> > /* Summary */
> > This adds well-known key ids for the .dm-verity and .fs-verity
> > keyrings.
> > 
> > Neither keyring is linked into any other keyring so request_key() and
> > KEYCTL_SEARCH can't find them. Userspace has to scrape the serial out
> > of /proc/keys before it can add a key to either of them. That's not
> > great as any user can add a key with a newline in its description and
> > make /proc/keys show a fake .dm-verity keyring line with whatever
> > serial they like.
> > 
> > /* Testing */
> > 
> > No build failures or warnings were observed.
> > 
> > /* Conflicts */
> > 
> > Merge conflicts with mainline
> > =============================
> > 
> > No known conflicts.
> > 
> > Merge conflicts with other trees
> > ================================
> > 
> > No known conflicts.
> > 
> > The following changes since commit
> > 1b7415bf70be95b9a1e7e87d544867881065613f:
> > 
> >   Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.3-rc2
> > (2026-09-06 16:17:40 -0700)
> > 
> > are available in the Git repository at:
> > 
> >   git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-
> > 7.4-rc1.keyring
> > 
> > for you to fetch changes up to
> > 503b65da9a7e5447d91222f62399522f2f62a0fa:
> > 
> >   Merge patch series "keys: Add well known IDs for fs-verity/dm-
> > verity keys" (2026-10-12 23:37:42 +0200)
> > 
> > ----------------------------------------------------------------
> > vfs-7.4-rc1.keyring
> > 
> > Please consider pulling these changes from the signed vfs-7.4-
> > rc1.keyring tag.
> > 
> > Thanks!
> > Christian
> > 
> > ----------------------------------------------------------------
> > Andrew Halaney (3):
> >       keys: add KEY_SPEC_DM_VERITY_KEYRING
> >       keys: add KEY_SPEC_FS_VERITY_KEYRING
> >       Documentation: keys: document IDs added since
> > KEY_SPEC_REQKEY_AUTH_KEY
> 
> It would actually have been nice to copy the keyrings list and
> maintainers on this.  I don't think there's an objection but not cc'ing
> the list and maintainers makes it look like some type of end run.

Uhm, they were?...

    From: Andrew Halaney <andrew@amutable.com>
    To: Alexei Starovoitov <ast@kernel.org>,  Daniel Borkmann <daniel@iogearbox.net>, Andrii Nakryiko <andrii@kernel.org>,  Alasdair Kergon <agk@redhat.com>, Mike
            Snitzer <snitzer@kernel.org>,  Mikulas Patocka <mpatocka@redhat.com>, Benjamin Marzinski <bmarzins@redhat.com>,  David Howells <dhowells@redhat.com>,
            Jarkko Sakkinen <jarkko@kernel.org>,  Paul Moore <paul@paul-moore.com>, James Morris <jmorris@namei.org>,  "Serge E. Hallyn" <serge@hallyn.com>, Eric
            Biggers <ebiggers@kernel.org>,  "Theodore Y. Ts'o" <tytso@mit.edu>, Jonathan Corbet <corbet@lwn.net>,  Shuah Khan <skhan@linuxfoundation.org>, Randy
            Dunlap <rdunlap@infradead.org>
    Cc: dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org,  keyrings@vger.kernel.org, linux-security-module@vger.kernel.org, bpf@vger.kernel.org,
                                                                 ^^^^^^^^^^^^^^^^^^^^^^^^
            fsverity@lists.linux.dev, linux-doc@vger.kernel.org, Andrew Halaney <andrew@amutable.com>,  "Christian Brauner (Amutable)" <brauner@kernel.org>
    Subject: [PATCH bpf-next v2 0/3] keys: Add well known IDs for fs-verity/dm-verity keys
    Message-Id: <20261008-ajhalaney-dmverity-key-identifier-v2-0-008456d189cb@amutable.com>

> > Christian Brauner (2):
> >       Merge bpf keyring work from of
> > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next
> >       Merge patch series "keys: Add well known IDs for fs-verity/dm-
> > verity keys"
> 
> This is a bit nasty because the keyring specs get renumbered inside the
> merges ... it would have been much clearer to people looking at the
> history if the patches were rebased instead.

Nothing got renumbered. Both merges are clean.
The only commits that touch the ids are Daniel's bpf one adding -9 in
bpf-next and Andrew's two adding -10 and -11. The branch is the three
patches on top of the bits shared with bpf-next with an explanation why
this was needed.

A rebase would given the same commit but would've meant invalidating
things that were already in -next.