From: Kent Overstreet <kent.overstreet@linux.dev>

It seems we need to be more forceful with the compiler on this one.

Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
 mm/slub.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/slub.c b/mm/slub.c
index 9ea03d6e9c9d..4d480784942e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2124,7 +2124,7 @@ bool slab_free_hook(struct kmem_cache *s, void *x, bool init)
 	return !kasan_slab_free(s, x, init);
 }
 
-static inline bool slab_free_freelist_hook(struct kmem_cache *s,
+static __always_inline bool slab_free_freelist_hook(struct kmem_cache *s,
 					   void **head, void **tail,
 					   int *cnt)
 {
-- 
2.43.0.687.g38aa6559b0-goog

On Mon, Feb 12, 2024 at 01:39:09PM -0800, Suren Baghdasaryan wrote:
> From: Kent Overstreet <kent.overstreet@linux.dev>
> 
> It seems we need to be more forceful with the compiler on this one.

Sure, but why?

> 
> Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>

Reviewed-by: Kees Cook <keescook@chromium.org>

-- 
Kees Cook

On Mon, Feb 12, 2024 at 04:31:14PM -0800, Kees Cook wrote:
> On Mon, Feb 12, 2024 at 01:39:09PM -0800, Suren Baghdasaryan wrote:
> > From: Kent Overstreet <kent.overstreet@linux.dev>
> > 
> > It seems we need to be more forceful with the compiler on this one.
> 
> Sure, but why?

Wasn't getting inlined without it, and that's one we do want inlined -
it's only called in one place.

On 2/13/24 03:08, Kent Overstreet wrote:
> On Mon, Feb 12, 2024 at 04:31:14PM -0800, Kees Cook wrote:
>> On Mon, Feb 12, 2024 at 01:39:09PM -0800, Suren Baghdasaryan wrote:
>> > From: Kent Overstreet <kent.overstreet@linux.dev>
>> > 
>> > It seems we need to be more forceful with the compiler on this one.
>> 
>> Sure, but why?
> 
> Wasn't getting inlined without it, and that's one we do want inlined -
> it's only called in one place.

It would be better to mention this in the changelog so it's clear this is
for performance and not e.g. needed for the code tagging to work as expected.

* Vlastimil Babka <vbabka@suse.cz> [240214 10:14]:
> On 2/13/24 03:08, Kent Overstreet wrote:
> > On Mon, Feb 12, 2024 at 04:31:14PM -0800, Kees Cook wrote:
> >> On Mon, Feb 12, 2024 at 01:39:09PM -0800, Suren Baghdasaryan wrote:
> >> > From: Kent Overstreet <kent.overstreet@linux.dev>
> >> > 
> >> > It seems we need to be more forceful with the compiler on this one.
> >> 
> >> Sure, but why?
> > 
> > Wasn't getting inlined without it, and that's one we do want inlined -
> > it's only called in one place.
> 
> It would be better to mention this in the changelog so it's clear this is
> for performance and not e.g. needed for the code tagging to work as expected.

Since it's not needed specifically for this set, can we take this patch
out of the set (and any others) and get them upstream first?

My hope is to reduce the count of 35 patches.  Less patches might get
more reviews and small things like this (should be, are?) easy enough to
get out of the way.  But also, it sounds worth doing on its own.

On Mon, Feb 12, 2024 at 4:31 PM Kees Cook <keescook@chromium.org> wrote:
>
> On Mon, Feb 12, 2024 at 01:39:09PM -0800, Suren Baghdasaryan wrote:
> > From: Kent Overstreet <kent.overstreet@linux.dev>
> >
> > It seems we need to be more forceful with the compiler on this one.
>
> Sure, but why?

IIRC Kent saw a case when it was not inlined for some reason... Kent,
do you recall this?

>
> >
> > Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
>
> Reviewed-by: Kees Cook <keescook@chromium.org>
>
> --
> Kees Cook