Re: [PATCH v2 2/2] EVM: add comment describing why ino field is still unsigned long

[Mimi Zohar <zohar@linux.ibm.com>]

On Fri, 2026-03-13 at 14:45 -0400, Jeff Layton wrote:
> Mimi pointed out that we didn't widen the inode number field in struct
> h_misc alongside the inode->i_ino widening. While we could make an
> equivalent change there, that would require EVM resigning on all 32-bit
> hosts.
> 
> Instead, leave the field as an unsigned long. This should have no effect
> on 64-bit hosts, and allow things to continue working on 32-bit hosts in
> the cases where the i_ino fits in 32-bits.
> 
> Add a comment explaining why it's being left as unsigned long.
> 
> Cc: Mimi Zohar <zohar@linux.ibm.com>
> Signed-off-by: Jeff Layton <jlayton@kernel.org>

Thanks, Jeff.

Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>


> ---
>  security/integrity/evm/evm_crypto.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/security/integrity/evm/evm_crypto.c b/security/integrity/evm/evm_crypto.c
> index c0ca4eedb0fe5d5c30f45f515a4bc90248ec64ea..1c41af2f91a60a714878ff93b554c90e45546503 100644
> --- a/security/integrity/evm/evm_crypto.c
> +++ b/security/integrity/evm/evm_crypto.c
> @@ -144,6 +144,12 @@ static void hmac_add_misc(struct shash_desc *desc, struct inode *inode,
>  			  char type, char *digest)
>  {
>  	struct h_misc {
> +		/*
> +		 * Although inode->i_ino is now u64, this field remains
> +		 * unsigned long to allow existing HMAC and signatures from
> +		 * 32-bit hosts to continue working when i_ino hasn't changed
> +		 * and fits in a u32.
> +		 */
>  		unsigned long ino;
>  		__u32 generation;
>  		uid_t uid;