| Message ID | 20250408112402.181574-4-shivankg@amd.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Add NUMA mempolicy support for KVM guest-memfd | expand |
On Tue, Apr 8, 2025 at 7:25 AM Shivank Garg <shivankg@amd.com> wrote: > > KVM guest_memfd is implementing its own inodes to store metadata for > backing memory using a custom filesystem. This requires the ability to > initialize anonymous inode using security_inode_init_security_anon(). > > As guest_memfd currently resides in the KVM module, we need to export this > symbol for use outside the core kernel. In the future, guest_memfd might be > moved to core-mm, at which point the symbols no longer would have to be > exported. When/if that happens is still unclear. Can you help me understand the timing just a bit more ... do you expect the move to the core MM code to happen during the lifetime of this patchset, or is it just some hand-wavy "future date"? No worries either way, just trying to understand things a bit better. > Signed-off-by: Shivank Garg <shivankg@amd.com> > --- > security/security.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/security/security.c b/security/security.c > index fb57e8fddd91..097283bb06a5 100644 > --- a/security/security.c > +++ b/security/security.c > @@ -1877,6 +1877,7 @@ int security_inode_init_security_anon(struct inode *inode, > return call_int_hook(inode_init_security_anon, inode, name, > context_inode); > } > +EXPORT_SYMBOL(security_inode_init_security_anon); > > #ifdef CONFIG_SECURITY_PATH > /** > -- > 2.34.1
On Tue, Apr 08, 2025 at 11:23:57AM +0000, Shivank Garg wrote: > KVM guest_memfd is implementing its own inodes to store metadata for > backing memory using a custom filesystem. This requires the ability to > initialize anonymous inode using security_inode_init_security_anon(). > > As guest_memfd currently resides in the KVM module, we need to export this > symbol for use outside the core kernel. In the future, guest_memfd might be > moved to core-mm, at which point the symbols no longer would have to be > exported. When/if that happens is still unclear. This really should be a EXPORT_SYMBOL_GPL, if at all. But you really should look into a new interface in anon_inode.c that can be reused instead of duplicating anonymouns inode logic in kvm.ko.
Hi Paul, On 4/10/2025 1:49 AM, Paul Moore wrote: > On Tue, Apr 8, 2025 at 7:25 AM Shivank Garg <shivankg@amd.com> wrote: >> >> KVM guest_memfd is implementing its own inodes to store metadata for >> backing memory using a custom filesystem. This requires the ability to >> initialize anonymous inode using security_inode_init_security_anon(). >> >> As guest_memfd currently resides in the KVM module, we need to export this >> symbol for use outside the core kernel. In the future, guest_memfd might be >> moved to core-mm, at which point the symbols no longer would have to be >> exported. When/if that happens is still unclear. > > Can you help me understand the timing just a bit more ... do you > expect the move to the core MM code to happen during the lifetime of > this patchset, or is it just some hand-wavy "future date"? No worries > either way, just trying to understand things a bit better. I am not sure about it, any ideas David? Thanks, Shivank > >> Signed-off-by: Shivank Garg <shivankg@amd.com> >> --- >> security/security.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/security/security.c b/security/security.c >> index fb57e8fddd91..097283bb06a5 100644 >> --- a/security/security.c >> +++ b/security/security.c >> @@ -1877,6 +1877,7 @@ int security_inode_init_security_anon(struct inode *inode, >> return call_int_hook(inode_init_security_anon, inode, name, >> context_inode); >> } >> +EXPORT_SYMBOL(security_inode_init_security_anon); >> >> #ifdef CONFIG_SECURITY_PATH >> /** >> -- >> 2.34.1 >
On 4/10/2025 2:11 PM, Christoph Hellwig wrote: > On Tue, Apr 08, 2025 at 11:23:57AM +0000, Shivank Garg wrote: >> KVM guest_memfd is implementing its own inodes to store metadata for >> backing memory using a custom filesystem. This requires the ability to >> initialize anonymous inode using security_inode_init_security_anon(). >> >> As guest_memfd currently resides in the KVM module, we need to export this >> symbol for use outside the core kernel. In the future, guest_memfd might be >> moved to core-mm, at which point the symbols no longer would have to be >> exported. When/if that happens is still unclear. > > This really should be a EXPORT_SYMBOL_GPL, if at all. > > But you really should look into a new interface in anon_inode.c that > can be reused instead of duplicating anonymouns inode logic in kvm.ko. > I agree, it makes sense. I'll use EXPORT_SYMBOL_GPL in next version and look into reusing reusing existing logic. Thanks, Shivank
diff --git a/security/security.c b/security/security.c index fb57e8fddd91..097283bb06a5 100644 --- a/security/security.c +++ b/security/security.c @@ -1877,6 +1877,7 @@ int security_inode_init_security_anon(struct inode *inode, return call_int_hook(inode_init_security_anon, inode, name, context_inode); } +EXPORT_SYMBOL(security_inode_init_security_anon); #ifdef CONFIG_SECURITY_PATH /**
KVM guest_memfd is implementing its own inodes to store metadata for backing memory using a custom filesystem. This requires the ability to initialize anonymous inode using security_inode_init_security_anon(). As guest_memfd currently resides in the KVM module, we need to export this symbol for use outside the core kernel. In the future, guest_memfd might be moved to core-mm, at which point the symbols no longer would have to be exported. When/if that happens is still unclear. Signed-off-by: Shivank Garg <shivankg@amd.com> --- security/security.c | 1 + 1 file changed, 1 insertion(+)