[PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Alexey Dobriyan]

Sysfs "ctor" file prints offset/length of the cache's ctor function

	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
	init_once+0x0/0x10

This is not useful:

Offset will always be 0 because ctor is a function.

I'm not sure what ctor function size is doing here, it should be in
/proc/kallsyms

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---

 mm/slub.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/mm/slub.c
+++ b/mm/slub.c
@@ -9149,7 +9149,7 @@ static ssize_t ctor_show(struct kmem_cache *s, char *buf)
 {
 	if (!s->ctor)
 		return 0;
-	return sysfs_emit(buf, "%pS\n", s->ctor);
+	return sysfs_emit(buf, "%ps\n", s->ctor);
 }
 SLAB_ATTR_RO(ctor);
 

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Harry Yoo]

[-- Attachment #1.1: Type: text/plain, Size: 984 bytes --]



On 7/25/26 10:28 PM, Alexey Dobriyan wrote:
> Sysfs "ctor" file prints offset/length of the cache's ctor function
> 
> 	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
> 	init_once+0x0/0x10
> 
> This is not useful:
> 
> Offset will always be 0 because ctor is a function.
> 
> I'm not sure what ctor function size is doing here, it should be in
> /proc/kallsyms
> 
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---

I'm not convinced that changing this (without strong justification)
after exposing it to sysfs for 10+ years is worth the trouble.

>  mm/slub.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -9149,7 +9149,7 @@ static ssize_t ctor_show(struct kmem_cache *s, char *buf)
>  {
>  	if (!s->ctor)
>  		return 0;
> -	return sysfs_emit(buf, "%pS\n", s->ctor);
> +	return sysfs_emit(buf, "%ps\n", s->ctor);
>  }
>  SLAB_ATTR_RO(ctor);
>  

-- 
Cheers,
Harry / Hyeonggon


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Christoph Lameter (Ampere)]

Reviewed-by: Christoph Lameter (Ampere) <cl@gentwo.org>

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Vlastimil Babka (SUSE)]

On 7/27/26 07:27, Harry Yoo wrote:
> 
> 
> On 7/25/26 10:28 PM, Alexey Dobriyan wrote:
>> Sysfs "ctor" file prints offset/length of the cache's ctor function
>> 
>> 	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
>> 	init_once+0x0/0x10
>> 
>> This is not useful:
>> 
>> Offset will always be 0 because ctor is a function.
>> 
>> I'm not sure what ctor function size is doing here, it should be in
>> /proc/kallsyms
>> 
>> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>> ---
> 
> I'm not convinced that changing this (without strong justification)
> after exposing it to sysfs for 10+ years is worth the trouble.

Agreed. It's a pity this was exported in the first place. I can't see a
benefit for anyone knowing what the function is called. Should have been at
most a flag whether there's ctor or not.
But possibly a justification is not to leak the function size, which might
be theoretically (although unlikely) a hint to some attack.
Well at least if somebody complains about getting broken, it's trivial to
revert and we can hear about their usecase.
In-tree tools (slabinfo etc) were checked to work properly?

>>  mm/slub.c |    2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -9149,7 +9149,7 @@ static ssize_t ctor_show(struct kmem_cache *s, char *buf)
>>  {
>>  	if (!s->ctor)
>>  		return 0;
>> -	return sysfs_emit(buf, "%pS\n", s->ctor);
>> +	return sysfs_emit(buf, "%ps\n", s->ctor);
>>  }
>>  SLAB_ATTR_RO(ctor);
>>  
> 

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Harry Yoo]

On Thu, Jul 30, 2026 at 04:15:26PM +0200, Vlastimil Babka (SUSE) wrote:
> On 7/27/26 07:27, Harry Yoo wrote:
> > 
> > 
> > On 7/25/26 10:28 PM, Alexey Dobriyan wrote:
> >> Sysfs "ctor" file prints offset/length of the cache's ctor function
> >> 
> >> 	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
> >> 	init_once+0x0/0x10
> >> 
> >> This is not useful:
> >> 
> >> Offset will always be 0 because ctor is a function.
> >> 
> >> I'm not sure what ctor function size is doing here, it should be in
> >> /proc/kallsyms
> >> 
> >> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >> ---
> > 
> > I'm not convinced that changing this (without strong justification)
> > after exposing it to sysfs for 10+ years is worth the trouble.
> 
> Agreed. It's a pity this was exported in the first place. I can't see a
> benefit for anyone knowing what the function is called. Should have been at
> most a flag whether there's ctor or not.

Agreed.

> But possibly a justification is not to leak the function size, which might
> be theoretically (although unlikely) a hint to some attack.

...but you need to be the owner (root) to read this :P 

> Well at least if somebody complains about getting broken, it's trivial to
> revert and we can hear about their usecase.

If we were to experiment with this, we'll change it to print a flag
rather than the ctor's name, right?

> In-tree tools (slabinfo etc) were checked to work properly?

Looks like it doesn't read ctor at all.

Commit a87615b8f9e2 ("SLUB: slabinfo upgrade") added -o/--ops option
that should "Display of ctor / dtor etc.", but it reads "ops" attribute
that has never existed? Bit puzzled.

> >>  mm/slub.c |    2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> --- a/mm/slub.c
> >> +++ b/mm/slub.c
> >> @@ -9149,7 +9149,7 @@ static ssize_t ctor_show(struct kmem_cache *s, char *buf)
> >>  {
> >>  	if (!s->ctor)
> >>  		return 0;
> >> -	return sysfs_emit(buf, "%pS\n", s->ctor);
> >> +	return sysfs_emit(buf, "%ps\n", s->ctor);
> >>  }
> >>  SLAB_ATTR_RO(ctor);

-- 
Cheers,
Harry / Hyeonggon

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Vlastimil Babka (SUSE)]

On 8/2/26 07:13, Harry Yoo wrote:
> On Thu, Jul 30, 2026 at 04:15:26PM +0200, Vlastimil Babka (SUSE) wrote:
>> On 7/27/26 07:27, Harry Yoo wrote:
>> > 
>> > 
>> > On 7/25/26 10:28 PM, Alexey Dobriyan wrote:
>> >> Sysfs "ctor" file prints offset/length of the cache's ctor function
>> >> 
>> >> 	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
>> >> 	init_once+0x0/0x10
>> >> 
>> >> This is not useful:
>> >> 
>> >> Offset will always be 0 because ctor is a function.
>> >> 
>> >> I'm not sure what ctor function size is doing here, it should be in
>> >> /proc/kallsyms
>> >> 
>> >> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>> >> ---
>> > 
>> > I'm not convinced that changing this (without strong justification)
>> > after exposing it to sysfs for 10+ years is worth the trouble.
>> 
>> Agreed. It's a pity this was exported in the first place. I can't see a
>> benefit for anyone knowing what the function is called. Should have been at
>> most a flag whether there's ctor or not.
> 
> Agreed.
> 
>> But possibly a justification is not to leak the function size, which might
>> be theoretically (although unlikely) a hint to some attack.
> 
> ...but you need to be the owner (root) to read this :P 
> 
>> Well at least if somebody complains about getting broken, it's trivial to
>> revert and we can hear about their usecase.
> 
> If we were to experiment with this, we'll change it to print a flag
> rather than the ctor's name, right?

Yep, let's try that. Alexey?

>> In-tree tools (slabinfo etc) were checked to work properly?
> 
> Looks like it doesn't read ctor at all.
> 
> Commit a87615b8f9e2 ("SLUB: slabinfo upgrade") added -o/--ops option
> that should "Display of ctor / dtor etc.", but it reads "ops" attribute
> that has never existed? Bit puzzled.

Might have been stale code from some previous revisions that included dtor.

>> >>  mm/slub.c |    2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >> 
>> >> --- a/mm/slub.c
>> >> +++ b/mm/slub.c
>> >> @@ -9149,7 +9149,7 @@ static ssize_t ctor_show(struct kmem_cache *s, char *buf)
>> >>  {
>> >>  	if (!s->ctor)
>> >>  		return 0;
>> >> -	return sysfs_emit(buf, "%pS\n", s->ctor);
>> >> +	return sysfs_emit(buf, "%ps\n", s->ctor);
>> >>  }
>> >>  SLAB_ATTR_RO(ctor);
> 

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Alexey Dobriyan]

On Thu, Jul 30, 2026 at 04:15:26PM +0200, Vlastimil Babka (SUSE) wrote:
> On 7/27/26 07:27, Harry Yoo wrote:
> > 
> > 
> > On 7/25/26 10:28 PM, Alexey Dobriyan wrote:
> >> Sysfs "ctor" file prints offset/length of the cache's ctor function
> >> 
> >> 	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
> >> 	init_once+0x0/0x10
> >> 
> >> This is not useful:
> >> 
> >> Offset will always be 0 because ctor is a function.
> >> 
> >> I'm not sure what ctor function size is doing here, it should be in
> >> /proc/kallsyms
> >> 
> >> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >> ---
> > 
> > I'm not convinced that changing this (without strong justification)
> > after exposing it to sysfs for 10+ years is worth the trouble.
> 
> Agreed. It's a pity this was exported in the first place. I can't see a
> benefit for anyone knowing what the function is called. Should have been at
> most a flag whether there's ctor or not.
> But possibly a justification is not to leak the function size, which might
> be theoretically (although unlikely) a hint to some attack.

Leaking size is a problem for custom kernels but not a problem
for distro kernels. Original format can be put under CAP_SYS_ADMIN.

> Well at least if somebody complains about getting broken, it's trivial to
> revert and we can hear about their usecase.
> In-tree tools (slabinfo etc) were checked to work properly?

I tried to google and grep my local git collection and found nothing.

> >> -	return sysfs_emit(buf, "%pS\n", s->ctor);
> >> +	return sysfs_emit(buf, "%ps\n", s->ctor);

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Alexey Dobriyan]

On Tue, Aug 04, 2026 at 07:25:15PM +0200, Vlastimil Babka (SUSE) wrote:
> On 8/2/26 07:13, Harry Yoo wrote:
> > On Thu, Jul 30, 2026 at 04:15:26PM +0200, Vlastimil Babka (SUSE) wrote:
> >> On 7/27/26 07:27, Harry Yoo wrote:
> >> > 
> >> > 
> >> > On 7/25/26 10:28 PM, Alexey Dobriyan wrote:
> >> >> Sysfs "ctor" file prints offset/length of the cache's ctor function
> >> >> 
> >> >> 	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
> >> >> 	init_once+0x0/0x10
> >> >> 
> >> >> This is not useful:
> >> >> 
> >> >> Offset will always be 0 because ctor is a function.
> >> >> 
> >> >> I'm not sure what ctor function size is doing here, it should be in
> >> >> /proc/kallsyms
> >> >> 
> >> >> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> >> >> ---
> >> > 
> >> > I'm not convinced that changing this (without strong justification)
> >> > after exposing it to sysfs for 10+ years is worth the trouble.
> >> 
> >> Agreed. It's a pity this was exported in the first place. I can't see a
> >> benefit for anyone knowing what the function is called. Should have been at
> >> most a flag whether there's ctor or not.
> > 
> > Agreed.
> > 
> >> But possibly a justification is not to leak the function size, which might
> >> be theoretically (although unlikely) a hint to some attack.
> > 
> > ...but you need to be the owner (root) to read this :P 
> > 
> >> Well at least if somebody complains about getting broken, it's trivial to
> >> revert and we can hear about their usecase.
> > 
> > If we were to experiment with this, we'll change it to print a flag
> > rather than the ctor's name, right?
> 
> Yep, let's try that. Alexey?

I don't mind ctor name, it is internal implementation detail,
but offset/size are kind of useless.

My order of preferences is
1) delete +0x0/... part altogeter,
2) when someone complains, restore it as "+0x0/0x4" which is a minimum
   function size across all archs (or some other fixed fake size).

> 
> >> In-tree tools (slabinfo etc) were checked to work properly?
> > 
> > Looks like it doesn't read ctor at all.
> > 
> > Commit a87615b8f9e2 ("SLUB: slabinfo upgrade") added -o/--ops option
> > that should "Display of ctor / dtor etc.", but it reads "ops" attribute
> > that has never existed? Bit puzzled.
> 
> Might have been stale code from some previous revisions that included dtor.
> 
> >> >>  mm/slub.c |    2 +-
> >> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> 
> >> >> --- a/mm/slub.c
> >> >> +++ b/mm/slub.c
> >> >> @@ -9149,7 +9149,7 @@ static ssize_t ctor_show(struct kmem_cache *s, char *buf)
> >> >>  {
> >> >>  	if (!s->ctor)
> >> >>  		return 0;
> >> >> -	return sysfs_emit(buf, "%pS\n", s->ctor);
> >> >> +	return sysfs_emit(buf, "%ps\n", s->ctor);
> >> >>  }
> >> >>  SLAB_ATTR_RO(ctor);

Re: [PATCH] slub: print just the function name in /sys/kernel/slab/*/ctor

[Harry Yoo]

On Wed, Aug 05, 2026 at 12:22:42PM +0300, Alexey Dobriyan wrote:
> On Tue, Aug 04, 2026 at 07:25:15PM +0200, Vlastimil Babka (SUSE) wrote:
> > On 8/2/26 07:13, Harry Yoo wrote:
> > > On Thu, Jul 30, 2026 at 04:15:26PM +0200, Vlastimil Babka (SUSE) wrote:
> > >> On 7/27/26 07:27, Harry Yoo wrote:
> > >> > 
> > >> > 
> > >> > On 7/25/26 10:28 PM, Alexey Dobriyan wrote:
> > >> >> Sysfs "ctor" file prints offset/length of the cache's ctor function
> > >> >> 
> > >> >> 	$ sudo cat /sys/kernel/slab/bdev_cache/ctor
> > >> >> 	init_once+0x0/0x10
> > >> >> 
> > >> >> This is not useful:
> > >> >> 
> > >> >> Offset will always be 0 because ctor is a function.
> > >> >> 
> > >> >> I'm not sure what ctor function size is doing here, it should be in
> > >> >> /proc/kallsyms
> > >> >> 
> > >> >> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> > >> >> ---
> > >> > 
> > >> > I'm not convinced that changing this (without strong justification)
> > >> > after exposing it to sysfs for 10+ years is worth the trouble.
> > >> 
> > >> Agreed. It's a pity this was exported in the first place. I can't see a
> > >> benefit for anyone knowing what the function is called. Should have been at
> > >> most a flag whether there's ctor or not.
> > > 
> > > Agreed.
> > > 
> > >> But possibly a justification is not to leak the function size, which might
> > >> be theoretically (although unlikely) a hint to some attack.
> > > 
> > > ...but you need to be the owner (root) to read this :P 
> > > 
> > >> Well at least if somebody complains about getting broken, it's trivial to
> > >> revert and we can hear about their usecase.
> > > 
> > > If we were to experiment with this, we'll change it to print a flag
> > > rather than the ctor's name, right?
> > 
> > Yep, let's try that. Alexey?
> 
> I don't mind ctor name, it is internal implementation detail,
> but offset/size are kind of useless.

I thought Vlastimil meant ctor name is also useless and suggested
it making it a flag (0/1) to represent whether the cache has a ctor or
not.

Or do you think there's a scenario where ctor name is useful to know? 

-- 
Cheers,
Harry / Hyeonggon