Thread (1 message) 1 message, 1 author, 2016-02-17

[PATCH v2] arm64: add alignment fault hanling

From: torvalds@linux-foundation.org (Linus Torvalds)
Date: 2016-02-17 00:28:49
Also in: lkml

On Tue, Feb 16, 2016 at 1:42 PM, Linus Torvalds
[off-list ref] wrote:
On Feb 16, 2016 1:31 PM, "Arjan van de Ven" [off-list ref] wrote:
quoted
but what happens to the read if the page isn't present?
or is execute-only or .. or ..
If we actually get a fault and handle the exception (not handling the
exception was the problem on arm), the exception code will just cut off the
pathname at the page boundary.

So it will see the accessible part, and get zeroes for the inaccessible one.
Actually, looking closer, we only do that for the kernel case (where
pagealloc-debug can cause the unaligned path component in *kernel*
space to trap).

I misremembered because I considered doing it for user accesses too,
but as Catalin correctly says, there we don't actually end up being
that clever, and we just fall back to byte-at-a-time. Which means that
we do get the exact EFAULT behavior even though I'm not 100% convinced
we need to.

See the use of "load_unaligned_zeropad()"  (in the dcache handling) vs
just "get_user()" (in strncpy_from_user()).

The fault case doesn't actually ever happen in practice.

The IS_UNALIGNED() case (on architectures with inefficient unaligned
handling), which also falls back to the byte-at-a-time model, is
likely a much bigger problem. They probably need their own strncpy if
they care about performance. But the common architectures all happily
do efficient unaligneds these days.

             Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help