[PATCH] slab: Fix too strict alignment check in create_cache()

[PATCH] slab: Fix too strict alignment check in create_cache()

[Geert Uytterhoeven]

On m68k, where the minimum alignment of unsigned long is 2 bytes:

    Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
    CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
    Stack from 0102fe5c:
	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
    Call Trace: [<00425e78>] dump_stack+0xc/0x10
     [<0041eb74>] panic+0xd8/0x26c
     [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
     [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
     [<0041e5f0>] memset+0x0/0x8c
     [<005f67c0>] io_uring_init+0x54/0xd2

The minimal alignment of an integral type may differ from its size,
hence is not safe to assume that an arbitrary freeptr_t (which is
basically an unsigned long) is always aligned to 4 or 8 bytes.

As nothing seems to require the additional alignment, it is safe to fix
this by relaxing the check to the actual minimum alignment of freeptr_t.

Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 mm/slab_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/slab_common.c b/mm/slab_common.c
index 893d320599151845..f2f201d865c108bd 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -230,7 +230,7 @@ static struct kmem_cache *create_cache(const char *name,
 	if (args->use_freeptr_offset &&
 	    (args->freeptr_offset >= object_size ||
 	     !(flags & SLAB_TYPESAFE_BY_RCU) ||
-	     !IS_ALIGNED(args->freeptr_offset, sizeof(freeptr_t))))
+	     !IS_ALIGNED(args->freeptr_offset, __alignof(freeptr_t))))
 		goto out;
 
 	err = -ENOMEM;
-- 
2.34.1

[PATCH] slab: Fix too strict alignment check in create_cache()

[Geert Uytterhoeven]

On m68k, where the minimum alignment of unsigned long is 2 bytes:

    Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
    CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
    Stack from 0102fe5c:
	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
    Call Trace: [<00425e78>] dump_stack+0xc/0x10
     [<0041eb74>] panic+0xd8/0x26c
     [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
     [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
     [<0041e5f0>] memset+0x0/0x8c
     [<005f67c0>] io_uring_init+0x54/0xd2

The minimal alignment of an integral type may differ from its size,
hence is not safe to assume that an arbitrary freeptr_t (which is
basically an unsigned long) is always aligned to 4 or 8 bytes.

As nothing seems to require the additional alignment, it is safe to fix
this by relaxing the check to the actual minimum alignment of freeptr_t.

Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 mm/slab_common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/slab_common.c b/mm/slab_common.c
index 893d320599151845..f2f201d865c108bd 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -230,7 +230,7 @@ static struct kmem_cache *create_cache(const char *name,
 	if (args->use_freeptr_offset &&
 	    (args->freeptr_offset >= object_size ||
 	     !(flags & SLAB_TYPESAFE_BY_RCU) ||
-	     !IS_ALIGNED(args->freeptr_offset, sizeof(freeptr_t))))
+	     !IS_ALIGNED(args->freeptr_offset, __alignof(freeptr_t))))
 		goto out;
 
 	err = -ENOMEM;
-- 
2.34.1

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Guenter Roeck]

On Wed, Nov 20, 2024 at 01:46:21PM +0100, Geert Uytterhoeven wrote:
> On m68k, where the minimum alignment of unsigned long is 2 bytes:
> 
>     Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
>     CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
>     Stack from 0102fe5c:
> 	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
> 	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
> 	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
> 	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
> 	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
> 	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
>     Call Trace: [<00425e78>] dump_stack+0xc/0x10
>      [<0041eb74>] panic+0xd8/0x26c
>      [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
>      [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
>      [<0041e5f0>] memset+0x0/0x8c
>      [<005f67c0>] io_uring_init+0x54/0xd2
> 
> The minimal alignment of an integral type may differ from its size,
> hence is not safe to assume that an arbitrary freeptr_t (which is
> basically an unsigned long) is always aligned to 4 or 8 bytes.
> 
> As nothing seems to require the additional alignment, it is safe to fix
> this by relaxing the check to the actual minimum alignment of freeptr_t.
> 
> Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

On m68k:

Tested-by: Guenter Roeck <linux@roeck-us.net>

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Jens Axboe]

On 11/20/24 5:49 AM, Geert Uytterhoeven wrote:
> On m68k, where the minimum alignment of unsigned long is 2 bytes:
> 
>     Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
>     CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
>     Stack from 0102fe5c:
> 	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
> 	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
> 	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
> 	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
> 	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
> 	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
>     Call Trace: [<00425e78>] dump_stack+0xc/0x10
>      [<0041eb74>] panic+0xd8/0x26c
>      [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
>      [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
>      [<0041e5f0>] memset+0x0/0x8c
>      [<005f67c0>] io_uring_init+0x54/0xd2
> 
> The minimal alignment of an integral type may differ from its size,
> hence is not safe to assume that an arbitrary freeptr_t (which is
> basically an unsigned long) is always aligned to 4 or 8 bytes.
> 
> As nothing seems to require the additional alignment, it is safe to fix
> this by relaxing the check to the actual minimum alignment of freeptr_t.
> 
> Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
>  mm/slab_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 893d320599151845..f2f201d865c108bd 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -230,7 +230,7 @@ static struct kmem_cache *create_cache(const char *name,
>  	if (args->use_freeptr_offset &&
>  	    (args->freeptr_offset >= object_size ||
>  	     !(flags & SLAB_TYPESAFE_BY_RCU) ||
> -	     !IS_ALIGNED(args->freeptr_offset, sizeof(freeptr_t))))
> +	     !IS_ALIGNED(args->freeptr_offset, __alignof(freeptr_t))))
>  		goto out;
>  
>  	err = -ENOMEM;

This looks much better, thanks.

Reviewed-by: Jens Axboe <axboe@kernel.dk>

-- 
Jens Axboe

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Vlastimil Babka]

On 11/20/24 13:49, Geert Uytterhoeven wrote:
> On m68k, where the minimum alignment of unsigned long is 2 bytes:
> 
>     Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
>     CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
>     Stack from 0102fe5c:
> 	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
> 	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
> 	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
> 	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
> 	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
> 	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
>     Call Trace: [<00425e78>] dump_stack+0xc/0x10
>      [<0041eb74>] panic+0xd8/0x26c
>      [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
>      [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
>      [<0041e5f0>] memset+0x0/0x8c
>      [<005f67c0>] io_uring_init+0x54/0xd2
> 
> The minimal alignment of an integral type may differ from its size,
> hence is not safe to assume that an arbitrary freeptr_t (which is
> basically an unsigned long) is always aligned to 4 or 8 bytes.
> 
> As nothing seems to require the additional alignment, it is safe to fix
> this by relaxing the check to the actual minimum alignment of freeptr_t.
> 
> Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

Thanks, will add it to slab pull for 6.13.

> ---
>  mm/slab_common.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/slab_common.c b/mm/slab_common.c
> index 893d320599151845..f2f201d865c108bd 100644
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -230,7 +230,7 @@ static struct kmem_cache *create_cache(const char *name,
>  	if (args->use_freeptr_offset &&
>  	    (args->freeptr_offset >= object_size ||
>  	     !(flags & SLAB_TYPESAFE_BY_RCU) ||
> -	     !IS_ALIGNED(args->freeptr_offset, sizeof(freeptr_t))))
> +	     !IS_ALIGNED(args->freeptr_offset, __alignof(freeptr_t))))

Seems only bunch of places uses __alignof but many use __alignoff__ and this
also is what seems to be documented?

>  		goto out;
>  
>  	err = -ENOMEM;

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Guenter Roeck]

On 11/20/24 07:03, Vlastimil Babka wrote:
> On 11/20/24 13:49, Geert Uytterhoeven wrote:
>> On m68k, where the minimum alignment of unsigned long is 2 bytes:
>>
>>      Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
>>      CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
>>      Stack from 0102fe5c:
>> 	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
>> 	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
>> 	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
>> 	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
>> 	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
>> 	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
>>      Call Trace: [<00425e78>] dump_stack+0xc/0x10
>>       [<0041eb74>] panic+0xd8/0x26c
>>       [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
>>       [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
>>       [<0041e5f0>] memset+0x0/0x8c
>>       [<005f67c0>] io_uring_init+0x54/0xd2
>>
>> The minimal alignment of an integral type may differ from its size,
>> hence is not safe to assume that an arbitrary freeptr_t (which is
>> basically an unsigned long) is always aligned to 4 or 8 bytes.
>>
>> As nothing seems to require the additional alignment, it is safe to fix
>> this by relaxing the check to the actual minimum alignment of freeptr_t.
>>
>> Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
>> Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
>> Reported-by: Guenter Roeck <linux@roeck-us.net>
>> Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> 
> Thanks, will add it to slab pull for 6.13.
> 
>> ---
>>   mm/slab_common.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index 893d320599151845..f2f201d865c108bd 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -230,7 +230,7 @@ static struct kmem_cache *create_cache(const char *name,
>>   	if (args->use_freeptr_offset &&
>>   	    (args->freeptr_offset >= object_size ||
>>   	     !(flags & SLAB_TYPESAFE_BY_RCU) ||
>> -	     !IS_ALIGNED(args->freeptr_offset, sizeof(freeptr_t))))
>> +	     !IS_ALIGNED(args->freeptr_offset, __alignof(freeptr_t))))
> 
> Seems only bunch of places uses __alignof but many use __alignoff__ and this
> also is what seems to be documented?

__alignoff__ -> __alignof__

Guenter

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Vlastimil Babka]

On 11/20/24 16:14, Guenter Roeck wrote:
> On 11/20/24 07:03, Vlastimil Babka wrote:
>> On 11/20/24 13:49, Geert Uytterhoeven wrote:
>>> On m68k, where the minimum alignment of unsigned long is 2 bytes:
>>>
>>>      Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
>>>      CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
>>>      Stack from 0102fe5c:
>>> 	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
>>> 	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
>>> 	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
>>> 	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
>>> 	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
>>> 	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
>>>      Call Trace: [<00425e78>] dump_stack+0xc/0x10
>>>       [<0041eb74>] panic+0xd8/0x26c
>>>       [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
>>>       [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
>>>       [<0041e5f0>] memset+0x0/0x8c
>>>       [<005f67c0>] io_uring_init+0x54/0xd2
>>>
>>> The minimal alignment of an integral type may differ from its size,
>>> hence is not safe to assume that an arbitrary freeptr_t (which is
>>> basically an unsigned long) is always aligned to 4 or 8 bytes.
>>>
>>> As nothing seems to require the additional alignment, it is safe to fix
>>> this by relaxing the check to the actual minimum alignment of freeptr_t.
>>>
>>> Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
>>> Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
>>> Reported-by: Guenter Roeck <linux@roeck-us.net>
>>> Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
>>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>> 
>> Thanks, will add it to slab pull for 6.13.
>> 
>>> ---
>>>   mm/slab_common.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>>> index 893d320599151845..f2f201d865c108bd 100644
>>> --- a/mm/slab_common.c
>>> +++ b/mm/slab_common.c
>>> @@ -230,7 +230,7 @@ static struct kmem_cache *create_cache(const char *name,
>>>   	if (args->use_freeptr_offset &&
>>>   	    (args->freeptr_offset >= object_size ||
>>>   	     !(flags & SLAB_TYPESAFE_BY_RCU) ||
>>> -	     !IS_ALIGNED(args->freeptr_offset, sizeof(freeptr_t))))
>>> +	     !IS_ALIGNED(args->freeptr_offset, __alignof(freeptr_t))))
>> 
>> Seems only bunch of places uses __alignof but many use __alignoff__ and this
>> also is what seems to be documented?
> 
> __alignoff__ -> __alignof__

Yeah I meant __alignof__
Will chage it locally then.

> Guenter
> 

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Geert Uytterhoeven]

Hi Vlastimil,

On Wed, Nov 20, 2024 at 4:44 PM Vlastimil Babka <vbabka@suse.cz> wrote:
> On 11/20/24 16:14, Guenter Roeck wrote:
> > On 11/20/24 07:03, Vlastimil Babka wrote:
> >> On 11/20/24 13:49, Geert Uytterhoeven wrote:
> >>> On m68k, where the minimum alignment of unsigned long is 2 bytes:
> >>>
> >>>      Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
> >>>      CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
> >>>      Stack from 0102fe5c:
> >>>         0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
> >>>         0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
> >>>         0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
> >>>         01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
> >>>         00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
> >>>         00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
> >>>      Call Trace: [<00425e78>] dump_stack+0xc/0x10
> >>>       [<0041eb74>] panic+0xd8/0x26c
> >>>       [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
> >>>       [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
> >>>       [<0041e5f0>] memset+0x0/0x8c
> >>>       [<005f67c0>] io_uring_init+0x54/0xd2
> >>>
> >>> The minimal alignment of an integral type may differ from its size,
> >>> hence is not safe to assume that an arbitrary freeptr_t (which is
> >>> basically an unsigned long) is always aligned to 4 or 8 bytes.
> >>>
> >>> As nothing seems to require the additional alignment, it is safe to fix
> >>> this by relaxing the check to the actual minimum alignment of freeptr_t.
> >>>
> >>> Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> >>> Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> >>> Reported-by: Guenter Roeck <linux@roeck-us.net>
> >>> Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> >>> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >>
> >> Thanks, will add it to slab pull for 6.13.
> >>
> >>> ---
> >>>   mm/slab_common.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/mm/slab_common.c b/mm/slab_common.c
> >>> index 893d320599151845..f2f201d865c108bd 100644
> >>> --- a/mm/slab_common.c
> >>> +++ b/mm/slab_common.c
> >>> @@ -230,7 +230,7 @@ static struct kmem_cache *create_cache(const char *name,
> >>>     if (args->use_freeptr_offset &&
> >>>         (args->freeptr_offset >= object_size ||
> >>>          !(flags & SLAB_TYPESAFE_BY_RCU) ||
> >>> -        !IS_ALIGNED(args->freeptr_offset, sizeof(freeptr_t))))
> >>> +        !IS_ALIGNED(args->freeptr_offset, __alignof(freeptr_t))))
> >>
> >> Seems only bunch of places uses __alignof but many use __alignoff__ and this
> >> also is what seems to be documented?
> >
> > __alignoff__ -> __alignof__
>
> Yeah I meant __alignof__
> Will chage it locally then.

Thank you!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Christoph Lameter (Ampere)]

On Wed, 20 Nov 2024, Vlastimil Babka wrote:

> >
> > Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> > Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
>
> Thanks, will add it to slab pull for 6.13.

Note that there are widespread assumptions in kernel code that the
alignment of scalars is the "natural alignment". Other portions of the
kernel may break. The compiler actually goes along with this??

How do you deal with torn reads/writes in such a scenario? Is this UP
only?

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Matthew Wilcox]

On Wed, Nov 20, 2024 at 09:50:47AM -0800, Christoph Lameter (Ampere) wrote:
> On Wed, 20 Nov 2024, Vlastimil Babka wrote:
> 
> > >
> > > Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> > > Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> > > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > > Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Thanks, will add it to slab pull for 6.13.
> 
> Note that there are widespread assumptions in kernel code that the
> alignment of scalars is the "natural alignment". Other portions of the
> kernel may break. The compiler actually goes along with this??

u64s aren't aligned on x86-32.  it's caused some problems over the
years, but things work ok in general.

> How do you deal with torn reads/writes in such a scenario? Is this UP
> only?

there were never a lot of smp m68k.  not sure i can think of one, tbh.
sun3 and hp300/400 seem like the obvious people who might have done an
smp m68k, but neither did.

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Geert Uytterhoeven]

Hi Christoph,

On Wed, Nov 20, 2024 at 6:50 PM Christoph Lameter (Ampere)
<cl@gentwo.org> wrote:
> On Wed, 20 Nov 2024, Vlastimil Babka wrote:
> > > Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> > > Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> > > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > > Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Thanks, will add it to slab pull for 6.13.
>
> Note that there are widespread assumptions in kernel code that the
> alignment of scalars is the "natural alignment". Other portions of the
> kernel may break. The compiler actually goes along with this??

Linux has supported m68k since last century.
Any new such assumptions are fixed quickly (at least in the kernel).
If you need a specific alignment, make sure to use __aligned and/or
appropriate padding in structures.
And yes, the compiler knows, and provides __alignof__.

> How do you deal with torn reads/writes in such a scenario? Is this UP
> only?

Linux does not support (rate) SMP m68k machines.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Christian Brauner]

On Wed, Nov 20, 2024 at 01:46:21PM +0100, Geert Uytterhoeven wrote:
> On m68k, where the minimum alignment of unsigned long is 2 bytes:
> 
>     Kernel panic - not syncing: __kmem_cache_create_args: Failed to create slab 'io_kiocb'. Error -22
>     CPU: 0 UID: 0 PID: 1 Comm: swapper Not tainted 6.12.0-atari-03776-g7eaa1f99261a #1783
>     Stack from 0102fe5c:
> 	    0102fe5c 00514a2b 00514a2b ffffff00 00000001 0051f5ed 00425e78 00514a2b
> 	    0041eb74 ffffffea 00000310 0051f5ed ffffffea ffffffea 00601f60 00000044
> 	    0102ff20 000e7a68 0051ab8e 004383b8 0051f5ed ffffffea 000000b8 00000007
> 	    01020c00 00000000 000e77f0 0041e5f0 005f67c0 0051f5ed 000000b6 0102fef4
> 	    00000310 0102fef4 00000000 00000016 005f676c 0060a34c 00000010 00000004
> 	    00000038 0000009a 01000000 000000b8 005f668e 0102e000 00001372 0102ff88
>     Call Trace: [<00425e78>] dump_stack+0xc/0x10
>      [<0041eb74>] panic+0xd8/0x26c
>      [<000e7a68>] __kmem_cache_create_args+0x278/0x2e8
>      [<000e77f0>] __kmem_cache_create_args+0x0/0x2e8
>      [<0041e5f0>] memset+0x0/0x8c
>      [<005f67c0>] io_uring_init+0x54/0xd2
> 
> The minimal alignment of an integral type may differ from its size,
> hence is not safe to assume that an arbitrary freeptr_t (which is
> basically an unsigned long) is always aligned to 4 or 8 bytes.
> 
> As nothing seems to require the additional alignment, it is safe to fix
> this by relaxing the check to the actual minimum alignment of freeptr_t.
> 
> Fixes: aaa736b186239b7d ("io_uring: specify freeptr usage for SLAB_TYPESAFE_BY_RCU io_kiocb cache")
> Fixes: d345bd2e9834e2da ("mm: add kmem_cache_create_rcu()")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Closes: https://lore.kernel.org/37c588d4-2c32-4aad-a19e-642961f200d7@roeck-us.net
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---

Looks good to me,
Reviewed-by: Christian Brauner <brauner@kernel.org>

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Christoph Lameter (Ampere)]

On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:

> Linux has supported m68k since last century.

Yeah I fondly remember the 80s where 68K systems were always out of reach
for me to have. The dream system that I never could get my hands on. The
creme de la creme du jour. I just had to be content with the 6800 and
6502 processors. Then IBM started the sick road down the 8088, 8086
that led from crap to more crap. Sigh.

> Any new such assumptions are fixed quickly (at least in the kernel).
> If you need a specific alignment, make sure to use __aligned and/or
> appropriate padding in structures.
> And yes, the compiler knows, and provides __alignof__.
>
> > How do you deal with torn reads/writes in such a scenario? Is this UP
> > only?
>
> Linux does not support (rate) SMP m68k machines.

Ah. Ok that explains it.

Do we really need to maintain support for a platform that has been
obsolete for decade and does not even support SMP?

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Guenter Roeck]

On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
> On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
> 
> > Linux has supported m68k since last century.
> 
> Yeah I fondly remember the 80s where 68K systems were always out of reach
> for me to have. The dream system that I never could get my hands on. The
> creme de la creme du jour. I just had to be content with the 6800 and
> 6502 processors. Then IBM started the sick road down the 8088, 8086
> that led from crap to more crap. Sigh.
> 
> > Any new such assumptions are fixed quickly (at least in the kernel).
> > If you need a specific alignment, make sure to use __aligned and/or
> > appropriate padding in structures.
> > And yes, the compiler knows, and provides __alignof__.
> >
> > > How do you deal with torn reads/writes in such a scenario? Is this UP
> > > only?
> >
> > Linux does not support (rate) SMP m68k machines.
> 
> Ah. Ok that explains it.
> 
> Do we really need to maintain support for a platform that has been
> obsolete for decade and does not even support SMP?

Since this keeps coming up, I think there is a much more important
question to ask:

Do we really need to continue supporting nommu machines ? Is anyone
but me even boot testing those ?

Guenter

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Jens Axboe]

On 11/21/24 11:30 AM, Guenter Roeck wrote:
> On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
>> On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
>>
>>> Linux has supported m68k since last century.
>>
>> Yeah I fondly remember the 80s where 68K systems were always out of reach
>> for me to have. The dream system that I never could get my hands on. The
>> creme de la creme du jour. I just had to be content with the 6800 and
>> 6502 processors. Then IBM started the sick road down the 8088, 8086
>> that led from crap to more crap. Sigh.
>>
>>> Any new such assumptions are fixed quickly (at least in the kernel).
>>> If you need a specific alignment, make sure to use __aligned and/or
>>> appropriate padding in structures.
>>> And yes, the compiler knows, and provides __alignof__.
>>>
>>>> How do you deal with torn reads/writes in such a scenario? Is this UP
>>>> only?
>>>
>>> Linux does not support (rate) SMP m68k machines.
>>
>> Ah. Ok that explains it.
>>
>> Do we really need to maintain support for a platform that has been
>> obsolete for decade and does not even support SMP?

I asked that earlier in this thread too...

> Since this keeps coming up, I think there is a much more important
> question to ask:
> 
> Do we really need to continue supporting nommu machines ? Is anyone
> but me even boot testing those ?

Getting rid of nommu would be nice for sure in terms of maintenance,
it's one of those things that pop up as a build breaking thing because
nobody is using/testing them.

I'm all for axing relics from the codebase. Doesn't mean they can't be
maintained out-of-tree, but that is where they belong imho.

-- 
Jens Axboe

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Geert Uytterhoeven]

On Thu, Nov 21, 2024 at 7:30 PM Guenter Roeck <linux@roeck-us.net> wrote:
> On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
> > On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
> > > Linux has supported m68k since last century.
> >
> > Yeah I fondly remember the 80s where 68K systems were always out of reach
> > for me to have. The dream system that I never could get my hands on. The
> > creme de la creme du jour. I just had to be content with the 6800 and
> > 6502 processors. Then IBM started the sick road down the 8088, 8086
> > that led from crap to more crap. Sigh.
> >
> > > Any new such assumptions are fixed quickly (at least in the kernel).
> > > If you need a specific alignment, make sure to use __aligned and/or
> > > appropriate padding in structures.
> > > And yes, the compiler knows, and provides __alignof__.
> > >
> > > > How do you deal with torn reads/writes in such a scenario? Is this UP
> > > > only?
> > >
> > > Linux does not support (rate) SMP m68k machines.

s/rate/rare/

> > Ah. Ok that explains it.
> >
> > Do we really need to maintain support for a platform that has been
> > obsolete for decade and does not even support SMP?
>
> Since this keeps coming up, I think there is a much more important
> question to ask:
>
> Do we really need to continue supporting nommu machines ? Is anyone
> but me even boot testing those ?

Not all m68k platform are nommu.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Guenter Roeck]

On Thu, Nov 21, 2024 at 07:50:33PM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 21, 2024 at 7:30 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
> > > On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
> > > > Linux has supported m68k since last century.
> > >
> > > Yeah I fondly remember the 80s where 68K systems were always out of reach
> > > for me to have. The dream system that I never could get my hands on. The
> > > creme de la creme du jour. I just had to be content with the 6800 and
> > > 6502 processors. Then IBM started the sick road down the 8088, 8086
> > > that led from crap to more crap. Sigh.
> > >
> > > > Any new such assumptions are fixed quickly (at least in the kernel).
> > > > If you need a specific alignment, make sure to use __aligned and/or
> > > > appropriate padding in structures.
> > > > And yes, the compiler knows, and provides __alignof__.
> > > >
> > > > > How do you deal with torn reads/writes in such a scenario? Is this UP
> > > > > only?
> > > >
> > > > Linux does not support (rate) SMP m68k machines.
> 
> s/rate/rare/
> 
> > > Ah. Ok that explains it.
> > >
> > > Do we really need to maintain support for a platform that has been
> > > obsolete for decade and does not even support SMP?
> >
> > Since this keeps coming up, I think there is a much more important
> > question to ask:
> >
> > Do we really need to continue supporting nommu machines ? Is anyone
> > but me even boot testing those ?
> 
> Not all m68k platform are nommu.
> 
Yes, I wasn't trying to point to m68k, but to nommu in general.

Guenter

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Guenter Roeck]

On Thu, Nov 21, 2024 at 11:08:54AM -0800, Guenter Roeck wrote:
> On Thu, Nov 21, 2024 at 07:50:33PM +0100, Geert Uytterhoeven wrote:
> > On Thu, Nov 21, 2024 at 7:30 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
> > > > On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
> > > > > Linux has supported m68k since last century.
> > > >
> > > > Yeah I fondly remember the 80s where 68K systems were always out of reach
> > > > for me to have. The dream system that I never could get my hands on. The
> > > > creme de la creme du jour. I just had to be content with the 6800 and
> > > > 6502 processors. Then IBM started the sick road down the 8088, 8086
> > > > that led from crap to more crap. Sigh.
> > > >
> > > > > Any new such assumptions are fixed quickly (at least in the kernel).
> > > > > If you need a specific alignment, make sure to use __aligned and/or
> > > > > appropriate padding in structures.
> > > > > And yes, the compiler knows, and provides __alignof__.
> > > > >
> > > > > > How do you deal with torn reads/writes in such a scenario? Is this UP
> > > > > > only?
> > > > >
> > > > > Linux does not support (rate) SMP m68k machines.
> > 
> > s/rate/rare/
> > 
> > > > Ah. Ok that explains it.
> > > >
> > > > Do we really need to maintain support for a platform that has been
> > > > obsolete for decade and does not even support SMP?
> > >
> > > Since this keeps coming up, I think there is a much more important
> > > question to ask:
> > >
> > > Do we really need to continue supporting nommu machines ? Is anyone
> > > but me even boot testing those ?
> > 
> > Not all m68k platform are nommu.
> > 
> Yes, I wasn't trying to point to m68k, but to nommu in general.
> 

For some more context: I think it is highly unlikely that anyone is really
using a recent version of Linux on a nommu machine. Maybe that was the case
10 or 20 years ago, but nowadays there are other operating systems which are
much better suited than Linux for such systems. Yet, there is a _lot_ of
nommu code in the kernel. In comparison, supporting m68k (mmu based) is a no
brainer, plus there are actually people like Geert actively supporting it.

If we are talking about dropping m68k support, we should really talk about
dropping nommu support first to get some _real_ benefit.

Guenter

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[John Paul Adrian Glaubitz]

On Wed, 2024-11-20 at 13:46 +0100, Geert Uytterhoeven wrote:
> On m68k, where the minimum alignment of unsigned long is 2 bytes:

Well, well, well, my old friend strikes again ;-).

These will always come up until we fix the alignment issue on m68k.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Greg Ungerer]

On 22/11/24 04:30, Guenter Roeck wrote:
> On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
>> On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
>>
>>> Linux has supported m68k since last century.
>>
>> Yeah I fondly remember the 80s where 68K systems were always out of reach
>> for me to have. The dream system that I never could get my hands on. The
>> creme de la creme du jour. I just had to be content with the 6800 and
>> 6502 processors. Then IBM started the sick road down the 8088, 8086
>> that led from crap to more crap. Sigh.
>>
>>> Any new such assumptions are fixed quickly (at least in the kernel).
>>> If you need a specific alignment, make sure to use __aligned and/or
>>> appropriate padding in structures.
>>> And yes, the compiler knows, and provides __alignof__.
>>>
>>>> How do you deal with torn reads/writes in such a scenario? Is this UP
>>>> only?
>>>
>>> Linux does not support (rate) SMP m68k machines.
>>
>> Ah. Ok that explains it.
>>
>> Do we really need to maintain support for a platform that has been
>> obsolete for decade and does not even support SMP?
> 
> Since this keeps coming up, I think there is a much more important
> question to ask:
> 
> Do we really need to continue supporting nommu machines ? Is anyone
> but me even boot testing those ?

Yes. Across many architectures. And yes on every release, and for m68k building
and testing on every rc for nommu at a minimum.

I rarely hit build or testing problems on nonmmu targets. At least every kernel
release I build and test armnommu (including thumb2 on cortex), m68k, RISC-V and
xtensa. They are all easy, qemu targets for them all. Thats just me. So I would
guess there are others building and testing too.

But what has that got to do with this thread, seems somewhat tangential to the
discussions here so far...

Regards
Greg

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Finn Thain]

On Thu, 21 Nov 2024, John Paul Adrian Glaubitz wrote:

> On Wed, 2024-11-20 at 13:46 +0100, Geert Uytterhoeven wrote:
> > On m68k, where the minimum alignment of unsigned long is 2 bytes:
> 
> Well, well, well, my old friend strikes again ;-).
> 
> These will always come up until we fix the alignment issue on m68k.
> 

Hmmm. That patch you're replying too. Does it make the kernel source code 
better or worse?

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Geert Uytterhoeven]

On Fri, Nov 22, 2024 at 3:11 AM Finn Thain <fthain@linux-m68k.org> wrote:
> On Thu, 21 Nov 2024, John Paul Adrian Glaubitz wrote:
> > On Wed, 2024-11-20 at 13:46 +0100, Geert Uytterhoeven wrote:
> > > On m68k, where the minimum alignment of unsigned long is 2 bytes:
> >
> > Well, well, well, my old friend strikes again ;-).
> >
> > These will always come up until we fix the alignment issue on m68k.
>
> Hmmm. That patch you're replying too. Does it make the kernel source code
> better or worse?

Touché ;-)

The same can be said about commit d811ac148f0afd2f ("virtchnl: fix
m68k build."): if you rely on a specific alignment, make sure to use
__aligned__ and/or struct padding.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Geert Uytterhoeven]

On Fri, Nov 22, 2024 at 1:23 AM Greg Ungerer <gerg@kernel.org> wrote:
> On 22/11/24 04:30, Guenter Roeck wrote:
> > Do we really need to continue supporting nommu machines ? Is anyone
> > but me even boot testing those ?
>
> Yes. Across many architectures. And yes on every release, and for m68k building
> and testing on every rc for nommu at a minimum.
>
> I rarely hit build or testing problems on nonmmu targets. At least every kernel
> release I build and test armnommu (including thumb2 on cortex), m68k, RISC-V and
> xtensa. They are all easy, qemu targets for them all. Thats just me. So I would
> guess there are others building and testing too.

FTR, I do regular boot tests on K210 (SiPEED MAiX BiT RISC-V nommu).
Getting harder, as 8 MiB of RAM is not much...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Max Filippov]

On Thu, Nov 21, 2024 at 10:30 AM Guenter Roeck <linux@roeck-us.net> wrote:
> Do we really need to continue supporting nommu machines ? Is anyone
> but me even boot testing those ?

I do rather regular boot tests on nommu xtensa (esp32, esp32-s3).

-- 
Thanks.
-- Max

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Lorenzo Stoakes]

On Thu, Nov 21, 2024 at 11:22:58AM -0800, Guenter Roeck wrote:
> On Thu, Nov 21, 2024 at 11:08:54AM -0800, Guenter Roeck wrote:
> > On Thu, Nov 21, 2024 at 07:50:33PM +0100, Geert Uytterhoeven wrote:
> > > On Thu, Nov 21, 2024 at 7:30 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > > On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
> > > > > On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
> > > > > > Linux has supported m68k since last century.
> > > > >
> > > > > Yeah I fondly remember the 80s where 68K systems were always out of reach
> > > > > for me to have. The dream system that I never could get my hands on. The
> > > > > creme de la creme du jour. I just had to be content with the 6800 and
> > > > > 6502 processors. Then IBM started the sick road down the 8088, 8086
> > > > > that led from crap to more crap. Sigh.
> > > > >
> > > > > > Any new such assumptions are fixed quickly (at least in the kernel).
> > > > > > If you need a specific alignment, make sure to use __aligned and/or
> > > > > > appropriate padding in structures.
> > > > > > And yes, the compiler knows, and provides __alignof__.
> > > > > >
> > > > > > > How do you deal with torn reads/writes in such a scenario? Is this UP
> > > > > > > only?
> > > > > >
> > > > > > Linux does not support (rate) SMP m68k machines.
> > >
> > > s/rate/rare/
> > >
> > > > > Ah. Ok that explains it.
> > > > >
> > > > > Do we really need to maintain support for a platform that has been
> > > > > obsolete for decade and does not even support SMP?
> > > >
> > > > Since this keeps coming up, I think there is a much more important
> > > > question to ask:
> > > >
> > > > Do we really need to continue supporting nommu machines ? Is anyone
> > > > but me even boot testing those ?
> > >
> > > Not all m68k platform are nommu.
> > >
> > Yes, I wasn't trying to point to m68k, but to nommu in general.
> >
>
> For some more context: I think it is highly unlikely that anyone is really
> using a recent version of Linux on a nommu machine. Maybe that was the case
> 10 or 20 years ago, but nowadays there are other operating systems which are
> much better suited than Linux for such systems. Yet, there is a _lot_ of
> nommu code in the kernel. In comparison, supporting m68k (mmu based) is a no
> brainer, plus there are actually people like Geert actively supporting it.
>
> If we are talking about dropping m68k support, we should really talk about
> dropping nommu support first to get some _real_ benefit.
>
> Guenter
>
>

I couldn't agree more re: nommu, it is the real source of maintenance
issues at least for us in mm, and one I've personally run into many times.

An aside, but note that there is a proposal to add nommu support to UML,
which would entirely prevent our ability to eliminate it [0] (though it
would make testing it easier! :)

[0]:https://lore.kernel.org/all/cover.1731290567.git.thehajime@gmail.com/

Re: [PATCH] slab: Fix too strict alignment check in create_cache()

[Lorenzo Stoakes]

On Fri, Nov 22, 2024 at 09:45:52AM +0000, Lorenzo Stoakes wrote:
> On Thu, Nov 21, 2024 at 11:22:58AM -0800, Guenter Roeck wrote:
> > On Thu, Nov 21, 2024 at 11:08:54AM -0800, Guenter Roeck wrote:
> > > On Thu, Nov 21, 2024 at 07:50:33PM +0100, Geert Uytterhoeven wrote:
> > > > On Thu, Nov 21, 2024 at 7:30 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > On Thu, Nov 21, 2024 at 09:23:28AM -0800, Christoph Lameter (Ampere) wrote:
> > > > > > On Thu, 21 Nov 2024, Geert Uytterhoeven wrote:
> > > > > > > Linux has supported m68k since last century.
> > > > > >
> > > > > > Yeah I fondly remember the 80s where 68K systems were always out of reach
> > > > > > for me to have. The dream system that I never could get my hands on. The
> > > > > > creme de la creme du jour. I just had to be content with the 6800 and
> > > > > > 6502 processors. Then IBM started the sick road down the 8088, 8086
> > > > > > that led from crap to more crap. Sigh.
> > > > > >
> > > > > > > Any new such assumptions are fixed quickly (at least in the kernel).
> > > > > > > If you need a specific alignment, make sure to use __aligned and/or
> > > > > > > appropriate padding in structures.
> > > > > > > And yes, the compiler knows, and provides __alignof__.
> > > > > > >
> > > > > > > > How do you deal with torn reads/writes in such a scenario? Is this UP
> > > > > > > > only?
> > > > > > >
> > > > > > > Linux does not support (rate) SMP m68k machines.
> > > >
> > > > s/rate/rare/
> > > >
> > > > > > Ah. Ok that explains it.
> > > > > >
> > > > > > Do we really need to maintain support for a platform that has been
> > > > > > obsolete for decade and does not even support SMP?
> > > > >
> > > > > Since this keeps coming up, I think there is a much more important
> > > > > question to ask:
> > > > >
> > > > > Do we really need to continue supporting nommu machines ? Is anyone
> > > > > but me even boot testing those ?
> > > >
> > > > Not all m68k platform are nommu.
> > > >
> > > Yes, I wasn't trying to point to m68k, but to nommu in general.
> > >
> >
> > For some more context: I think it is highly unlikely that anyone is really
> > using a recent version of Linux on a nommu machine. Maybe that was the case
> > 10 or 20 years ago, but nowadays there are other operating systems which are
> > much better suited than Linux for such systems. Yet, there is a _lot_ of
> > nommu code in the kernel. In comparison, supporting m68k (mmu based) is a no
> > brainer, plus there are actually people like Geert actively supporting it.
> >
> > If we are talking about dropping m68k support, we should really talk about
> > dropping nommu support first to get some _real_ benefit.
> >
> > Guenter
> >
> >
>
> I couldn't agree more re: nommu, it is the real source of maintenance
> issues at least for us in mm, and one I've personally run into many times.
>
> An aside, but note that there is a proposal to add nommu support to UML,
> which would entirely prevent our ability to eliminate it [0] (though it
> would make testing it easier! :)
>
> [0]:https://lore.kernel.org/all/cover.1731290567.git.thehajime@gmail.com/

To update, some interesting discussion in this thread suggests that indeed,
there is an ongoing need for nommu regardless [1].

In which case this nommu uml series is rather helpful for testing :)

[1]:https://lore.kernel.org/linux-mm/09060fcf-47e4-424f-9ab7-ee2f7919dbf5@lucifer.local/T/#m0cb0ace28f3905182369790ddc1b494d408587b9