On 23.10.20 16:47, 'Greg KH' wrote: > On Fri, Oct 23, 2020 at 02:39:24PM +0000, David Laight wrote: >> From: David Hildenbrand >>> Sent: 23 October 2020 15:33 >> ... >>> I just checked against upstream code generated by clang 10 and it >>> properly discards the upper 32bit via a mov w23 w2. >>> >>> So at least clang 10 indeed properly assumes we could have garbage and >>> masks it off. >>> >>> Maybe the issue is somewhere else, unrelated to nr_pages ... or clang 11 >>> behaves differently. >> >> We'll need the disassembly from a failing kernel image. >> It isn't that big to hand annotate. > > I've worked around the merge at the moment in the android tree, but it > is still quite reproducable, and will try to get a .o file to > disassemble on Monday or so... I just compiled pre and post fb041b598997d63c0f7d7305dfae70046bf66fe1 with clang version 11.0.0 (Fedora 11.0.0-0.2.rc1.fc33) for aarch64 with defconfig and extracted import_iovec and rw_copy_check_uvector (skipping the compat things) Pre fb041b598997d63c0f7d7305dfae70046bf66fe1 import_iovec -> https://pastebin.com/LtnYMLJt Post fb041b598997d63c0f7d7305dfae70046bf66fe1 import_iovec -> https://pastebin.com/BWPmXrAf Pre fb041b598997d63c0f7d7305dfae70046bf66fe1 rw_copy_check_uvector -> https://pastebin.com/4nSBYRbf Post fb041b598997d63c0f7d7305dfae70046bf66fe1 rw_copy_check_uvector -> https://pastebin.com/hPtEgaEW I'm only able to spot minor differences ... less gets inlined than I would have expected. But there are some smaller differences. Maybe someone wants to have a look before we have object files as used by Greg ... -- Thanks, David / dhildenb
