> keys: add KEY_SPEC_DM_VERITY_KEYRING TL;DR: Design/uapi question: was David Howells' v1 suggestion (reserved negative key ID block, common register functions) intentionally dropped? The new uapi value -10 should be settled before release.
> diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h > --- a/include/uapi/linux/keyctl.h > +++ b/include/uapi/linux/keyctl.h > @@ -25,6 +25,7 @@ > #define KEY_SPEC_REQKEY_AUTH_KEY -7 /* - key ID for assumed > request_key auth key */ > #define KEY_SPEC_REQUESTOR_KEYRING -8 /* - key ID for request_key() > dest keyring */ > #define KEY_SPEC_BPF_KEYRING -9 /* - key ID for the > BPF-specific keyring */ > +#define KEY_SPEC_DM_VERITY_KEYRING -10 /* - key ID for the .dm-verity > keyring */ On v1, David Howells wrote: I have no particular objection to setting aside a block of negative key IDs for special keyrings that need to be accessed a lot - though I would make common reg/unreg functions that take the ID to be registered and, say, set the block at -257..-512. Moving the BFP keyring to -257 and DM to -258. (<[email protected]>) The question of whether this was being asked for v2 was raised in reply, but there was no answer, and this version still continues the one-off -9/-10 sequence with a dm-verity specific key_register_dm_verity_keyring() and dm_verity_keyring_lock. Was the suggestion to use a reserved ID block with common register and unregister functions intentionally dropped, or should it still be addressed? Since KEY_SPEC_DM_VERITY_KEYRING is a UAPI value, would it be possible to settle this before the -10 value is released? --- AI reviewed your patch. Please fix the bug or email reply why it's not a bug. See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37844805282
