Hi Christian,
Thanks for your review.
> On Nov 13, 2024, at 2:19 AM, Christian Brauner <brauner@xxxxxxxxxx> wrote:
[...]
>> diff --git a/include/linux/fs.h b/include/linux/fs.h
>> index 3559446279c1..479097e4dd5b 100644
>> --- a/include/linux/fs.h
>> +++ b/include/linux/fs.h
>> @@ -79,6 +79,7 @@ struct fs_context;
>> struct fs_parameter_spec;
>> struct fileattr;
>> struct iomap_ops;
>> +struct bpf_local_storage;
>>
>> extern void __init inode_init(void);
>> extern void __init inode_init_early(void);
>> @@ -648,6 +649,9 @@ struct inode {
>> #ifdef CONFIG_SECURITY
>> void *i_security;
>> #endif
>> +#ifdef CONFIG_BPF_SYSCALL
>> + struct bpf_local_storage __rcu *i_bpf_storage;
>> +#endif
>
> Sorry, we're not growing struct inode for this. It just keeps getting
> bigger. Last cycle we freed up 8 bytes to shrink it and we're not going
> to waste them on special-purpose stuff. We already NAKed someone else's
> pet field here.
Would it be acceptable if we union i_bpf_storage with i_security?
IOW, if CONFIG_SECURITY is enabled, we will use existing logic.
If CONFIG_SECURITY is not enabled, we will use i_bpf_storage.
Given majority of default configs have CONFIG_SECURITY=y, this
will not grow inode for most users. OTOH, users with
CONFIG_SECURITY=n && CONFIG_BPF_SYSCALL=y combination can still
use inode local storage in the tracing BPF programs.
Does this make sense?
Thanks,
Song
