On Mon, Sep 15, 2025 at 6:30 AM Sabyrzhan Tasbolatov <[email protected]> wrote: > > > Why is the check removed here and in some other places below? This > > need to be explained in the commit message. > > kasan_arch_is_ready which was unified with kasan_enabled, was removed > here because > __kasan_slab_pre_free is called from include/linux/kasan.h [1] where > there's already kasan_enabled() check. > > [1] https://elixir.bootlin.com/linux/v6.16.7/source/include/linux/kasan.h#L198 > > Please let me know if v7 is required with the change in the git commit > message only.
No need, but next time please add such info into the commit message. > > What I meant with these __wrappers was that we should add them for the > > KASAN hooks that are called from non-KASAN code (i.e. for the hooks > > defined in include/linux/kasan.h). And then move all the > > kasan_enabled() checks from mm/kasan/* to where the wrappers are > > defined in include/linux/kasan.h (see kasan_unpoison_range() as an > > example). > > > > kasan_save_free_info is a KASAN internal function that should need > > such a wrapper. > > > > For now, to make these patches simpler, you can keep kasan_enabled() > > checks in mm/kasan/*, where they are now. Later we can move them to > > include/linux/kasan.h with a separate patch. > > Yes, I'd like to revisit this in the next separate patch series. Great! But for now, please send a fix-up patch that removes the __kasan_save_free_info() wrapper (or a v8? But I see that your series is now in mm-stable, so I guess a separate fix-up patch is preferred). I don't think you need a kasan_enabled() check in kasan_save_free_info() at all. Both the higher level paths (kasan_slab_free and kasan_mempool_poison_object) already contain this check. Thanks!
