>
> 2) Then, further down in the "local_storage.c" file in
> "SEC("lsm.s/bprm_committed_creds")", there is another call to
> bpf_inode_storage_get on the same inode_storage_map but on a different
> inode, also with the BPF_LOCAL_STORAGE_GET_F_CREATE flag set. This
> will also call into bpf_local_storage_update.
I belive this is the inode and the storage that the second
bpf_inode_storage_get(..., 0) in the "inode_rename" bpf-prog is supposed
to get. Otherwise, I don't see how the test can pass.
>
> 3) In bpf_local_storage_update from the call in #2, it sees that there
> is a local storage associated with this map in the RCU, it tries to
> look for the inode but doesn't find it, so it needs to allocate with
> GFP_KERNEL a new selem and then update with the new selem.
Correct, that will be the very first storage created for this inode
and it will go through the "if (!local_storage || hlist_empty(&local_storage->list))"
allocation code path in bpf_local_storage_update() which is
an existing code path.
I was talking specifically about the "if (gfp_flags == GFP_KERNEL)"
allocation code path. Thus, it needs a second inode local storage (i.e.
a second inode map) for the same inode. A second inode storage map
and another "bpf_inode_storage_get(&second_inode_storage_map, ...
BPF_LOCAL_STORAGE_GET_F_CREATE)" should be enough.
It seems it needs a re-spin because of the sparse warning.
I don't see an issue from the code, just thinking it will
be useful to have a test to exercise this path. It
could be a follow up as an individual patch if not in v3.
