On 5/31/2021 3:25 PM, Vlastimil Babka wrote: > On 5/31/21 8:55 AM, Faiyaz Mohammed wrote: > >>> I don't see any of the symlinks under /sys/kernel/debug/slab/, so I think the >>> aliases handling code is wrong, and I can see at least two reasons why it could be: >>> >> >> I think I missed one thing, when CONFIG_SLUB_DEBUG_ON enable or >> slub_debug is pass through command line __kmem_cache_alias() will return >> null, so no symlinks will be created even if CONFIG_SLAB_MERGE_DEFAULT >> is enable and to store user data we need to enable CONFIG_SLUB_DEBUG_ON >> or pass slub_debug through command line. > > So you're saying that caches with SLAB_STORE_USER can never be aliases as the > merging logic will prevent merging with any debug flag, including STORE_USER. So > if we ignore aliases, it means we will not create the debugfs files for caches, > where opening the files would just return error, so we don't lose anything by > not creating the files in the first place. > > In that case, for consistency I would recommend to skip debugfs creation for all > caches without SLAB_STORE_USER (even if the caches are not an alias). I think we > can make this decision now as it's a whole new debugfs subtree so we don't break > any pre-existing code. > Hmmm, I think yes we can skip debugfs creation for all cache without SLAB_STORE_USER flag set instead of returning error after opening of file. I will do the change in next patch version. Thanks and regards, Mohammed Faiyaz
