Received-SPF: pass (google.com: domain of linux-kernel+bounces-84810-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240228085824.74639-1-dawei.li@shingroup.cn> <754c3acb-538d-45a1-84a1-0bebd02fd945@kernel.org>
 <673EAB52C5659E99+Zd799lrOHAVIdm3S@centos8>
In-Reply-To: <673EAB52C5659E99+Zd799lrOHAVIdm3S@centos8>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Wed, 28 Feb 2024 11:09:06 +0100
Message-ID: <CAMuHMdVSK2Ek6=uRE=FwibOqbCYifYsJ5otRXBpA1vW6tBqPMg@mail.gmail.com>
Subject: Re: [PATCH] mk68k: Fix broken THREAD_SIZE_ORDER
To: Dawei Li <dawei.li@shingroup.cn>
Cc: Jiri Slaby <jirislaby@kernel.org>, gerg@snapgear.com, 
	linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org, 
	set_pte_at@outlook.com, stable@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dawei,

On Wed, Feb 28, 2024 at 10:34=E2=80=AFAM Dawei Li <dawei.li@shingroup.cn> w=
rote:
> 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 i=
t
> > > by ilog2().
> >
> > This is not a good commit log. Incorrect in what way and why is the fix=
ed
>
> Agreed.
>
> > version correct? And what is affected? Note you're referring to a chang=
e
> > 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

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

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