On Wed, Jun 23, 2021 at 10:39:31AM +0800, Chen Huang wrote: > When we access a device memory in userspace, then perform an unaligned write to a file. > For example, we register a uio device and mmap the device, then perform an write to a > file, like that: > > device_addr = mmap(device_fd); > write(file_fd, device_addr + unaligned_num, size); What exactly is this device, and why do you want the kernel to do a direct memcpy from MMIO? Why can't you copy that in userspace (where you have knowledge of the device), then pass the copy to a syscall? Ignoring the lockup below, this isn't going to work in general, since uaccess routines do not guarantee alignment, single-copy, access sizes, monotonically increasing addresses, etc. Any one of those can cause a device to raise an external abort which may or may not be synchronous. It does not make sense to tell the kernel to access this, since the kernel cannot know how to access it safely, and we can;t do that without knowledge of the device that we do not have. Thanks, Mark. > > We found that the infinite loop happened in generic_perform_write function: > > again: > copied = copy_page_from_iter_atomic(); //copied = 0 > status = ops->write_end(); //status = 0 > if (status == 0) > goto again; > > In copy_page_from_iter_atomic, the copyin() function finally call > __arch_copy_from_user which create an exception table entry for 'insn'. > Then when kernel handles the alignment_fault, it will not panic. As the > arm64 memory model spec said, when the address is not a multiple of the > element size, the access is unaligned. Unaligned accesses are allowed to > addresses marked as Normal, but not to Device regions. An unaligned access > to a Device region will trigger an exception (alignment fault). > > do_alignment_fault > do_bad_area > __do_kernel_fault > fixup_exception > > But that fixup cann't handle the unaligned copy, so the > copy_page_from_iter_atomic returns 0 and traps in loop. > > Reported-by: Chen Huang <chenhuang5@xxxxxxxxxx>
