On 23.10.20 16:47, 'Greg KH' wrote:

On Fri, Oct 23, 2020 at 02:39:24PM +0000, David Laight wrote:

quoted

From: David Hildenbrand

quoted

Sent: 23 October 2020 15:33

...

quoted

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