Thread (31 messages) 31 messages, 9 authors, 2021-07-07

Re: [BUG] arm64: an infinite loop in generic_perform_write()

From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2021-06-23 13:05:02
Also in: linux-arm-kernel, lkml

On Wed, Jun 23, 2021 at 10:32:21AM +0100, Catalin Marinas wrote:
On arm64, neither memcpy() nor raw_copy_from_user() are expected to work
on Device mappings, we have memcpy_fromio() for this but only for
ioremap(). There's no (easy) way to distinguish in the write() syscall
how the source buffer is mapped. generic_perform_write() does an
iov_iter_fault_in_readable() check but that's not sufficient and it also
breaks the cases where you can get intra-page faults (arm64 MTE or SPARC
ADI). I think in the general case it's racy anyway (another thread doing
an mprotect(PROT_NONE) after the readable check passed).

So I think generic_perform_write() returning -EFAULT if copied == 0
would make sense (well, unless it breaks other cases I'm not aware of).
It does break the cases of source page eviction under memory pressure.
That aside, why the hell is that memory allowed to be mmaped?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help