Re: [PATCH v3 01/10] MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf()

[Thomas Bogendoerfer <tsbogend@alpha.franken.de>]

On Wed, May 06, 2026 at 11:42:23PM +0100, Maciej W. Rozycki wrote:
> In 64-bit configurations calling any firmware entry points from a kernel 
> thread other than the initial one will result in a situation where the 
> stack has been placed in the XKPHYS 64-bit memory segment.
> 
> Consequently the stack pointer is no longer a 32-bit value and when the 
> 32-bit firmware code called uses 32-bit ALU operations to manipulate the 
> stack pointer, the calculated result is incorrect (in fact in the 64-bit 
> MIPS ISA almost all 32-bit ALU operations will produce an unpredictable 
> result when executed on 64-bit data) and control goes astray.
> 
> This may happen when no final console driver has been enabled in the
> configuration and consequently the initial console continues being used
> late into bootstrap, or with an upcoming change that will switch the zs
> driver to use a platform device, which in turn will make the console
> handover happen only after other kernel threads have already been
> started, and the kernel will hang at:
> 
>   pid_max: default: 32768 minimum: 301
> 
> or somewhat later, but always before:
> 
>   cblist_init_generic: Setting adjustable number of callback queues.
> 
> has been printed.
> 
> It seems that only the prom_printf() entry point is affected.  Of all 
> the other entry points wired only rex_slot_address() and rex_gettcinfo() 
> are called from a kernel thread other than the initial one, specifically 
> kernel_init(), and they are leaf functions that do no business with the 
> stack, having worked with no issue ever since 64-bit support was added 
> for the platform back in 2002.
> 
> To address this issue then, arrange for the stack to be switched in the 
> o32 wrapper as required for prom_printf() only, by supplying call_o32() 
> with a pointer to a chunk of initdata space, which is placed in the 
> CKSEG0 32-bit compatibility segment, observing that prom_printf() is 
> only called from console output handler and therefore with the console 
> lock held, implying no need for this code to be reentrant.
> 
> Other firmware entry points may be called with interrupts enabled and no 
> lock held, and may therefore require that call_o32() be reentrant.  They 
> trigger no issue at this point and "if it ain't broke, don't fix it," so 
> just leave them alone.
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
> Cc: stable@vger.kernel.org # v2.6.12+
> ---
> No change from v2, 
> <https://lore.kernel.org/r/alpine.DEB.2.21.2605010132340.38805@angie.orcam.me.uk/>.
> 
> New change in v2.
> ---
>  arch/mips/dec/prom/init.c        |    6 +++++-
>  arch/mips/include/asm/dec/prom.h |   15 +++++++++++++--
>  2 files changed, 18 insertions(+), 3 deletions(-)

applied to mips-next

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]