Re: futex(0x1ffffff81300000) on risc-v -> mm panic

From: Nam Cao <namcao@linutronix.de>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: rtm@csail.mit.edu, Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	linux-riscv@lists.infradead.org
Subject: Re: futex(0x1ffffff81300000) on risc-v -> mm panic
Date: Thu, 19 Jun 2025 18:02:14 +0200	[thread overview]
Message-ID: <20250619160214.CuDLtJ3p@linutronix.de> (raw)
In-Reply-To: <21e7809a-ef55-4b4d-aa29-f6ef2bb429ee@ghiti.fr>

On Thu, Jun 19, 2025 at 02:35:21PM +0200, Alexandre Ghiti wrote:
> On 6/18/25 12:10, rtm@csail.mit.edu wrote:
> > This program on risc-v:
> > 
> > main(){
> >    futex((void*) 0x1ffffff81300000, FUTEX_WAIT, 0, 0, 0, 0);
> 
> 
> This address is far beyond what userspace is supposed to be able to access,
> even in sv57, see Documentation/arch/riscv/vm-layout.rst.
> 
> The problem is that access_ok() lets it go through and then gup returns a
> kernel mapping, which isn't good at all.
> 
> I can't reproduce the issue, but it seems like commit ad5643cf2f69 ("riscv:
> Define TASK_SIZE_MAX for __access_ok()") is the culprit, can you try
> reverting it?

Yeah my git bisect said the same thing. At first I thought that commit just
uncovered some deeper problem; but staring at it, I think that is the bug.

Just send a patch.

Best regards,
Nam

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv