linux-kernel - Re: [PATCH] mk68k: Fix broken THREAD_SIZE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdVSK2Ek6=uRE=FwibOqbCYifYsJ5otRXBpA1vW6tBqPMg@mail.gmail.com>
Date: Wed, 28 Feb 2024 11:09:06 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Dawei Li <dawei.li@...ngroup.cn>
Cc: Jiri Slaby <jirislaby@...nel.org>, gerg@...pgear.com, 
	linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org, 
	set_pte_at@...look.com, stable@...r.kernel.org
Subject: Re: [PATCH] mk68k: Fix broken THREAD_SIZE_ORDER

Hi Dawei,

On Wed, Feb 28, 2024 at 10:34 AM Dawei Li <dawei.li@...ngroup.cn> wrote:
> On Wed, Feb 28, 2024 at 10:11:05AM +0100, Jiri Slaby wrote:
> > On 28. 02. 24, 9:58, Dawei Li wrote:
> > > Current THREAD_SIZE_ORDER implementation for m68k is incorrect, fix it
> > > by ilog2().
> >
> > This is not a good commit log. Incorrect in what way and why is the fixed
>
> Agreed.
>
> > version correct? And what is affected? Note you're referring to a change
> > which was done 14 years ago. It definitely must not be that incorrect (for
> > everybody).
>
> It's 'right' just for current PAGE_SIZE & THREAD_SIZE configs:
>
> // arch/m68k/include/asm/thread_info.h
> #if PAGE_SHIFT < 13
> #ifdef CONFIG_4KSTACKS
> #define THREAD_SIZE     4096
> #else
> #define THREAD_SIZE     8192
> #endif
> #else
> #define THREAD_SIZE     PAGE_SIZE
> #endif
> #define THREAD_SIZE_ORDER       ((THREAD_SIZE / PAGE_SIZE) - 1)

Indeed.  The only supported values for THREAD_SIZE_ORDER on m68k are
0 and 1.

> But it's incorrect in generic/mathematical way.

True.  But does it matter much?
I.e. do you plan to add support for larger values of THREAD_SIZE?

What about changing the #ifdeffery to set THREAD_SIZE_ORDER to an
explicit value, and calculating THREAD_SIZE from THREAD_SIZE_ORDER
instead?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68korg

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