[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <00d1b813-c55f-4365-8d81-d70258e10b16@app.fastmail.com>
Date: Thu, 25 Jan 2024 09:28:41 +0000
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Linus Torvalds" <torvalds@...ux-foundation.org>,
"Xi Ruoyao" <xry111@...111.site>, tsbogend@...ha.franken.de
Cc: "Andreas Schwab" <schwab@...e.de>, "Ben Hutchings" <ben@...adent.org.uk>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
linux-kernel@...r.kernel.org, libc-alpha@...rceware.org
Subject: Re: Strange EFAULT on mips64el returned by syscall when another thread is
forking
在2024年1月24日一月 下午10:10,Linus Torvalds写道:
[...]
>
> Anyway, I'm pretty sure this is the bug, now some MIPS person just
> needs to fix the MIPS version of "instruction_pointer()" to do what
> "exception_epc()" already does.
Hi folks,
Kinda MIPS person here, I looked into the problem, and it's not that
easy to fix.
I inspected some existing usage of "instruction_pointer()", and some
of them do want exception return address (which is always CP0_EPC).
Others like this case they want the precise exception instruction
pointer ("exception_epc()" for MIPS).
I'm planning to make "instruction_pointer()" always point to exception
instructions, and implemented a new function called "return_pc()"or
whatever for "exception_epc()". Do you have a better name in mind?
Besides isa16 stuff do require kernel to read user space fault
instruction to determine delay slot size... I don't think it's always
possible when "instruction_pointer()" is called. MIPS16/microMIPS
is rarely used today though.
Thanks
>
> Linus
--
- Jiaxun
Powered by blists - more mailing lists