From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jiaxun Yang <jiaxun.yang@flygoat.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Andrew Morton <akpm@linux-foundation.org>,
Ben Hutchings <ben@decadent.org.uk>,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
Xi Ruoyao <xry111@xry111.site>
Subject: Re: [PATCH v2 0/3] Handle delay slot for extable lookup
Date: Sun, 4 Feb 2024 07:41:41 +0000 [thread overview]
Message-ID: <CAHk-=wiUb1oKMHqrxZ6pA7OjNmtgw6giTKWiagUC2kt-ePCakg@mail.gmail.com> (raw)
In-Reply-To: <eeb92d70-44d6-47f4-a059-66546be5f62a@flygoat.com>
On Sat, 3 Feb 2024 at 13:56, Jiaxun Yang <jiaxun.yang@flygoat.com> wrote:
>
> Given that exception_ip is guarded by !user_mode(regs), EPC must points
> to a kernel text address. There is no way accessing kernel text will generate such
> exception..
Sadly, that's not actually likely true.
The thing is, the only reason for the code in
get_mmap_lock_carefully() is for kernel bugs. IOW, some kernel bug
with a wild pointer, and we do not want to deadlock on the mm
semaphore, we want to get back to the fault handler and it should
report an oops.
... and one of the "wild pointers" might in fact be the instruction
pointer, in case we've branched through a NULL function pointer or
similar. IOW, the exception *source* might be the instruction pointer
itself.
So I realy think that MIPS needs to have some kind of "safe kernel
exception pointer" helper. One that is guaranteed not to fault when
evaluating the exception pointer.
Assuming the kernel itself is never built with MIPS16e instructions,
maybe that's a safe assumption thanks to the "get_isa16_mode()" check
of EPC. But all of this makes me nervous.
Linus
next prev parent reply other threads:[~2024-02-04 7:42 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 12:30 Jiaxun Yang
2024-02-02 12:30 ` [PATCH v2 1/3] ptrace: Introduce exception_ip arch hook Jiaxun Yang
2024-02-02 12:30 ` [PATCH v2 2/3] MIPS: Clear Cause.BD in instruction_pointer_set Jiaxun Yang
2024-02-02 12:30 ` [PATCH v2 3/3] mm/memory: Use exception ip to search exception tables Jiaxun Yang
2024-02-02 18:39 ` [PATCH v2 0/3] Handle delay slot for extable lookup Linus Torvalds
2024-02-02 21:31 ` Jiaxun Yang
2024-02-03 13:56 ` Jiaxun Yang
2024-02-04 7:41 ` Linus Torvalds [this message]
2024-02-04 11:03 ` Jiaxun Yang
2024-02-04 11:45 ` Linus Torvalds
2024-02-08 9:20 ` Jiaxun Yang
2024-02-08 9:23 ` Xi Ruoyao
2024-02-08 9:31 ` Jiaxun Yang
2024-02-12 22:10 ` Thomas Bogendoerfer
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='CAHk-=wiUb1oKMHqrxZ6pA7OjNmtgw6giTKWiagUC2kt-ePCakg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=ben@decadent.org.uk \
--cc=jiaxun.yang@flygoat.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=oleg@redhat.com \
--cc=tsbogend@alpha.franken.de \
--cc=xry111@xry111.site \
/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