On Sat, Feb 04, 2023 at 12:26:39AM +0000, Al Viro wrote:
On Thu, Feb 02, 2023 at 05:56:22PM -0500, Peter Xu wrote:
IMHO it'll be merely impossible to merge things across most (if not to say,
all) archs. It will need to be start from one or at least a few that still
shares a major common base - I would still rely on x86 as a start - then we
try to use the helper in as much archs as possible.
Even on x86, I do also see challenges so I'm not sure whether a common
enough routine can be abstracted indeed. But I believe there's a way to do
this because obviously we still see tons of duplicated logics falling
around. It may definitely need time to think out where's the best spot to
start, and how to gradually move towards covering more archs starting from
one.
FWIW, after going through everything from alpha to loongarch (in alphabetic
order, skipping the itanic) the following seems to be suitable for all of
them:
generic_fault(address, flags, vm_flags, regs)
[snip]
After looking through other architectures: that needs changes.
AFAICS, the right approach would be to add a pointer to (uninitialized)
kernel_siginfo. And let it pass the signal number, etc. through that.
That way all "we want to raise a signal" return values fold together.
*IF* the page fault wants to do something extra on SIGSEGV, but not on
SIGBUS (we have several such), it can key that upon info.si_signo.
Speaking of SIGSEGV, there's a fun situation with VM_FAULT_SIGSEGV:
1) Only x86 and ppc generate VM_FAULT_SIGSEGV in handle_mm_fault()
without hitting WARN_ON_ONCE(). And neither actually returns it
to page fault handler - the conditions that would've led to that
return value (pkey stuff) are checked in the page fault handler
and handle_mm_fault() is not called in such cases.
2) on alpha, hexagon, itanic, loongarch, microblaze, mips, nios2,
openrisc, sparc, um and xtensa #PF handler would end up with SEGV_ACCERR
if it saw VM_FAULT_SIGNAL.
3) on arm, arm64, arc, m68k, powerpc, s390, sh and x86 - SEGV_MAPERR
(except that neither x86 nor powerpc #PF ever see it)
4) on csky and riscv it would end up with BUG()
5) on parisc it's complicated^Wbroken - it tries to decide which
one to use after having unlocked mmap and looking at vma in process.
As it is, VM_FAULT_SIGSEGV had ended up as "we need to report some
error to get_user_pages() and similar callers in cases when
page fault handler would've detected pkey problem and refused
to call handle_mm_fault()", with several places where it's
"we had been called with bogus arguments; printk and return
something to indicate the things had gone wrong". It used to
have other uses, but this is what it had become now - grep and
you'll see.
AFAICS, all checks for it in page fault handlers are pretty much
dead code...
