Re: [PATCH RFC v2 bpf-next 1/9] mm: Store build id in inode object
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2023-02-28 19:13:15
Also in:
bpf, linux-fsdevel, linux-perf-users, lkml
On Tue, 28 Feb 2023 10:31:58 +0100 Jiri Olsa [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Storing build id in file's inode object for elf executable with build id defined. The build id is stored when file is mmaped. This is enabled with new config option CONFIG_INODE_BUILD_ID. The build id is valid only when the file with given inode is mmap-ed. We store either the build id itself or the error we hit during the retrieval. ...--- a/include/linux/fs.h +++ b/include/linux/fs.h@@ -699,6 +700,12 @@ struct inode { struct fsverity_info *i_verity_info; #endif +#ifdef CONFIG_INODE_BUILD_ID + /* Initialized and valid for executable elf files when mmap-ed. */ + struct build_id *i_build_id; + spinlock_t i_build_id_lock; +#endif +
Remember we can have squillions of inodes in memory. So that's one costly spinlock! AFAICT this lock could be removed if mmap_region() were to use an atomic exchange on inode->i_build_id? If not, can we use an existing lock? i_lock would be appropriate (don't forget to update its comment). Also, the code in mmap_region() runs build_id_free() inside the locked region, which seems unnecessary.