On Thu, Jun 24, 2021 at 04:09:11PM +0100, Catalin Marinas wrote:

On Thu, Jun 24, 2021 at 12:15:46PM +0100, Matthew Wilcox wrote:

quoted

On Thu, Jun 24, 2021 at 08:04:07AM +0100, Christoph Hellwig wrote:

quoted

On Thu, Jun 24, 2021 at 04:24:46AM +0100, Matthew Wilcox wrote:

quoted

On Thu, Jun 24, 2021 at 11:10:41AM +0800, Chen Huang wrote:

quoted

In userspace, I perform such operation:

 	fd = open("/tmp/test", O_RDWR | O_SYNC);
        access_address = (char *)mmap(NULL, uio_size, PROT_READ, MAP_SHARED, uio_fd, 0);
        ret = write(fd, access_address + 2, sizeof(long));

... you know that accessing this at unaligned offsets isn't going to
work.  It's completely meaningless.  Why are you trying to do it?

We still should not cause an infinite loop in kernel space due to a
a userspace programmer error.

They're running as root and they've mapped some device memory.  We can't
save them from themself.  Imagine if they'd done this to the NVMe BAR.

We could change raw_copy_from_user() to fall back to 1-byte read in case
of a fault or fix this corner case in the generic code. A quick hack,
re-attempting the access with one byte:

No.  If nothing else, iov_iter_single_seg_count() is a bad kludge.
What's more, this "do a single-byte copy" fallback is punishing
a much more common case (memory pressure evicting the page) for the sake
of a corner case specific to one architecture that should've been dealt
with in its raw_copy_from_user().

NAKed-by: Al Viro [off-list ref]

For some context, see include/linux/uaccess.h and description of requirements
for raw_copy_from_user() in there.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel