Linux Serial subsystem development
 help / color / mirror / Atom feed
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>,
	linux-mips@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [PATCH v3 02/10] MIPS: DEC: Prevent initial console buffer from landing in XKPHYS
Date: Tue, 26 May 2026 16:46:12 +0200	[thread overview]
Message-ID: <ahWyNMag6EZNyykS@alpha.franken.de> (raw)
In-Reply-To: <alpine.DEB.2.21.2605062253010.46195@angie.orcam.me.uk>

On Wed, May 06, 2026 at 11:42:27PM +0100, Maciej W. Rozycki wrote:
> In 64-bit configurations calling the initial console output handler 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 and 
> consequently so has been the buffer allocated there that is used as the 
> argument corresponding to the `%s' output conversion specifier for the 
> firmware's printf() entry point.
> 
> This 64-bit address will then be truncated by 32-bit firmware, resulting 
> in an attempt to access the wrong memory location, which in turn will 
> cause all kinds of unpredictable behaviour, such as a kernel crash:
> 
>   Console: colour dummy device 160x64
>   Calibrating delay loop... 49.36 BogoMIPS (lpj=192512)
>   pid_max: default: 32768 minimum: 301
>   CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800
>   Oops[#1]:
>   CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121
>   $ 0   : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0
>   $ 4   : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073
>   $ 8   : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473
>   $12   : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000
>   $16   : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240
>   $20   : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b
>   $24   : ffffffffffffffbf 000000000203bd00                                  
>   $28   : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800
>   Hi    : 0000000000000000
>   Lo    : 0000000000000aa8
>   epc   : ffffffffbfc08364 0xffffffffbfc08364
>   ra    : ffffffffbfc08800 0xffffffffbfc08800
>   Status: 140120e2        KX SX UX KERNEL EXL 
>   Cause : 00000008 (ExcCode 02)
>   BadVA : 000000000203bd00
>   PrId  : 00000430 (R4000SC)
>   Modules linked in:
>   Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)
>   Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d
>           80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38
>           0000000000000000 000000000203bd00 0000000000000000 0000000000000000
>           0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000
>           0000000000000000 0000000000000000 0000000000000000 0000000000000000
>           0000000000000000 0000000000000000 0000000000000000 0000000000000000
>           0000002500000000 0000000000000000 0000000000000000 802c1a7400000000
>           0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172
>           6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320
>           806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000
>           ...
>   Call Trace:
>   
>   
>   Code: a082ffff  03e00008  00601021 <80820000> 00001821  10400005  24840001  80820000  24630001 
>   
>   ---[ end trace 0000000000000000 ]---
>   Kernel panic - not syncing: Fatal exception in interrupt
>   
>   KN04 V2.1k    (PC: 0xa0026768, SP: 0x806848e8)
>   >>
> 
> In this case the pointer in $4 was truncated from 0x980000000203bd00 to 
> 0x000000000203bd00.
> 
> 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.
> 
> Fix the issue by making the buffer static and initdata, and therefore 
> placed in the CKSEG0 32-bit compatibility segment, observing that the 
> console output handler is called with the console lock held, implying 
> no need for this code to be reentrant.  Add an assertion to verify the 
> buffer actually has been placed in a compatibility segment.
> 
> 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+
> ---
> Changes from v2, 
> <https://lore.kernel.org/r/alpine.DEB.2.21.2605010059310.38805@angie.orcam.me.uk/>:
> 
> - Cast `buf' to `long' before casting to `int', fixing:
> 
>   In file included from ./include/linux/bug.h:5,
>                    from arch/mips/dec/prom/console.c:7:
>   arch/mips/dec/prom/console.c: In function 'prom_console_write':
>   arch/mips/dec/prom/console.c:21:29: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
>      21 |         BUG_ON((long)buf != (int)buf);
>         |                             ^
>   ./arch/mips/include/asm/bug.h:34:44: note: in definition of macro 'BUG_ON'
>      34 | #define BUG_ON(C) __BUG_ON((unsigned long)(C))
>         |                                            ^
> 
> New change in v2.
> ---
>  arch/mips/dec/prom/console.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 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 ]

  reply	other threads:[~2026-05-26 14:51 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06 22:42 [PATCH v3 00/10] MIPS: DEC: Fix serial device regressions + RTC cleanup Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 01/10] MIPS: DEC: Ensure 32-bit stack location for o32 prom_printf() Maciej W. Rozycki
2026-05-26 14:45   ` Thomas Bogendoerfer
2026-05-06 22:42 ` [PATCH v3 02/10] MIPS: DEC: Prevent initial console buffer from landing in XKPHYS Maciej W. Rozycki
2026-05-26 14:46   ` Thomas Bogendoerfer [this message]
2026-05-06 22:42 ` [PATCH v3 03/10] serial: dz: Fix bootconsole message clobbering at chip reset Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 04/10] serial: dz: Fix bootconsole handover lockup Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 05/10] serial: zs: " Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 06/10] serial: zs: Switch to using channel reset Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 07/10] serial: dz: Convert to use a platform device Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 08/10] serial: zs: " Maciej W. Rozycki
2026-05-06 22:42 ` [PATCH v3 09/10] serial: dz: Enable modular build Maciej W. Rozycki
2026-05-06 22:43 ` [PATCH v3 10/10] MIPS: DEC: Ensure RTC platform device deregistration upon failure Maciej W. Rozycki
2026-05-26 14:49   ` Thomas Bogendoerfer
2026-05-22 15:15 ` [PATCH v3 00/10] MIPS: DEC: Fix serial device regressions + RTC cleanup Maciej W. Rozycki
2026-05-26 14:48   ` Thomas Bogendoerfer
2026-05-26 15:08     ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ahWyNMag6EZNyykS@alpha.franken.de \
    --to=tsbogend@alpha.franken.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=macro@orcam.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox