On Wed, Jun 23, 2021 at 11:24:54AM +0800, Xiaoming Ni wrote: > On 2021/6/23 10:50, Al Viro wrote: > > On Wed, Jun 23, 2021 at 10:39:31AM +0800, Chen Huang wrote: > > > > > 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. > > > > Looks like you need to fix your raw_copy_from_user(), then... > > . > > > > Exit loop when iov_iter_copy_from_user_atomic() returns 0. > This should solve the problem, too, and it's easier. It might be easier, but it's not going to work correctly. If the page gets evicted by memory pressure, you are going to get spurious short write. Besides, it's simply wrong - write(2) does *NOT* require an aligned source. It (and raw_copy_from_user()) should act the same way memcpy(3) does.
