Message ID | 20250408112402.181574-4-shivankg@amd.com |
---|---|
State | New |
Headers | show |
Series | Add NUMA mempolicy support for KVM guest-memfd | expand |
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.
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(+)