Re: Linux 6.8-rc6

Re: Linux 6.8-rc6

[Geert Uytterhoeven]

Hi Günter,

CC Kees

On Mon, Feb 26, 2024 at 6:52 PM Guenter Roeck <linux@roeck-us.net> wrote:
> stackinit
> ---------
>
> Seen with m68k:q800 emulation.
>
>     # test_char_array_zero: ASSERTION FAILED at lib/stackinit_kunit.c:333
>     Expected stackinit_range_contains(fill_start, fill_size, target_start, target_size) to be true, but is false
> stack fill missed target!? (fill 16 wide, target offset by -12)
>
>     # test_char_array_none: ASSERTION FAILED at lib/stackinit_kunit.c:343
>     Expected stackinit_range_contains(fill_start, fill_size, target_start, target_size) to be true, but is false
> stack fill missed target!? (fill 16 wide, target offset by -12)
>
> Report:
> https://lore.kernel.org/lkml/a0d10d50-2720-4ecd-a2c6-c2c5e5aeee65@roeck-us.net/

I don't think these have ever succeeded before, see
https://lore.kernel.org/all/CAMuHMdX_g1tbiUL9PUQdqaegrEzCNN3GtbSvSBFYAL4TzvstFg@mail.gmail.com

> I suspect this may be caused by the test assuming that stack growth is
> downward, but I don't really understand the test well enough to be sure.
> I'll disable this set of tests for m68k going forward, so I am not going
> to report the problem again in the future.

On m68k, the stack does grow downward.
AFAIK only parisc has a stack that grows upward.

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: Linux 6.8-rc6

[Guenter Roeck]

On 2/26/24 23:41, Geert Uytterhoeven wrote:
> Hi Günter,
> 
> CC Kees
> 
> On Mon, Feb 26, 2024 at 6:52 PM Guenter Roeck <linux@roeck-us.net> wrote:
>> stackinit
>> ---------
>>
>> Seen with m68k:q800 emulation.
>>
>>      # test_char_array_zero: ASSERTION FAILED at lib/stackinit_kunit.c:333
>>      Expected stackinit_range_contains(fill_start, fill_size, target_start, target_size) to be true, but is false
>> stack fill missed target!? (fill 16 wide, target offset by -12)
>>
>>      # test_char_array_none: ASSERTION FAILED at lib/stackinit_kunit.c:343
>>      Expected stackinit_range_contains(fill_start, fill_size, target_start, target_size) to be true, but is false
>> stack fill missed target!? (fill 16 wide, target offset by -12)
>>
>> Report:
>> https://lore.kernel.org/lkml/a0d10d50-2720-4ecd-a2c6-c2c5e5aeee65@roeck-us.net/
> 
> I don't think these have ever succeeded before, see
> https://lore.kernel.org/all/CAMuHMdX_g1tbiUL9PUQdqaegrEzCNN3GtbSvSBFYAL4TzvstFg@mail.gmail.com
> 
>> I suspect this may be caused by the test assuming that stack growth is
>> downward, but I don't really understand the test well enough to be sure.
>> I'll disable this set of tests for m68k going forward, so I am not going
>> to report the problem again in the future.
> 
> On m68k, the stack does grow downward.

Sorry, I meant to say upward, but apparently I was wrong.

> AFAIK only parisc has a stack that grows upward.
> 
... and the tests work there, so that isn't the problem.

As mentioned, I stopped running those tests on m68k.

Thanks,
Guenter

RE: Linux 6.8-rc6

[David Laight]

...
> >> I suspect this may be caused by the test assuming that stack growth is
> >> downward, but I don't really understand the test well enough to be sure.
> >> I'll disable this set of tests for m68k going forward, so I am not going
> >> to report the problem again in the future.
> >
> > On m68k, the stack does grow downward.
> 
> Sorry, I meant to say upward, but apparently I was wrong.

Maybe because m68k only has 2 byte alignment for 32 bit items.
That causes grief in many places.
Although kmalloc() returning a larger alignment would fix some
of them without using much more memory?

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Linux 6.8-rc6

[John Paul Adrian Glaubitz]

On Thu, 2024-02-29 at 22:19 +0000, David Laight wrote:
> ...
> > > > I suspect this may be caused by the test assuming that stack growth is
> > > > downward, but I don't really understand the test well enough to be sure.
> > > > I'll disable this set of tests for m68k going forward, so I am not going
> > > > to report the problem again in the future.
> > > 
> > > On m68k, the stack does grow downward.
> > 
> > Sorry, I meant to say upward, but apparently I was wrong.
> 
> Maybe because m68k only has 2 byte alignment for 32 bit items.
> That causes grief in many places.
> Although kmalloc() returning a larger alignment would fix some
> of them without using much more memory?

We're actually planning to switch the default alignment in Gentoo and Debian on m68k
to 32 bits since a lot of upstream projects such as OpenJDK, Qt, LLVM, Firebird and
Mold and many more expect 32-bit alignment.

Adrian

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

Re: Linux 6.8-rc6

[Andreas Schwab]

On Feb 29 2024, David Laight wrote:

> Maybe because m68k only has 2 byte alignment for 32 bit items.

Nope.  Its simply undefined behavior.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."