Hi, after Christian's recent refactoring, we have the following APIs to create kmem caches: kmem_cache_create() with new args parameter (and the legacy variant of the same name) kmem_cache_create_usercopy() - also legacy at this point KMEM_CACHE() which takes the type, and has many users, but currently has no support for args KMEM_CACHE_USERCOPY() - like KMEM_CACHE() but with the usercopy parameters, and only two users I mentioned this at LPC when talking with Kees, and during Namhyung's talk. I was only vaguely aware of KMEM_CACHE(), but during the refactoring I became aware of if more. The reason it takes the struct type's name is currently to automatically derive __alignof__ - and it could be an interesting excercise to find out how many caches today exist for structures with specific cache alignment defined for some fields, which then fails to be satisfied because the caches are created by kmem_cache_create() without the proper alignment... Today we might have additionally interest to know the type for security hardening, i.e. like kmalloc_obj does [1], and for perf to help more with cache cpu optimizations [2]. Both got me wondering if it would help if we converted everything to use KMEM_CACHE(), assuming that - is there a way to store the type info somewhere (aside from using it for __alignof__) so that perf can later get it back? I think [2] is currently missing the step from knowing the kmem_cache's name to the type? - could hardening benefit from this somehow, like it is supposed to benefit for kmalloc() in [1] ? So if these questions have positive answers, we could think about extending KMEM_CACHE() to support the new args parameter, making it the primary cache creation API and converting all users to that, while deprecating the other variants. Thanks, Vlastimil [1] https://lore.kernel.org/all/20240822231324.make.666-kees@xxxxxxxxxx/ [2] https://lore.kernel.org/all/20241002180956.1781008-1-namhyung@xxxxxxxxxx/
