* load_unaligned_zeropad() on x86-64 @ 2020-11-14 15:53 David Laight 2020-11-14 18:02 ` Linus Torvalds 0 siblings, 1 reply; 3+ messages in thread From: David Laight @ 2020-11-14 15:53 UTC (permalink / raw) To: linux-kernel, x86, 'Linus Torvalds' The change e419b4cc585680940bc42f8ca8a071d6023fb1bb added asm code for load_unaligned_zeropad(). However it doesn't look right for 64bit. It masks the address with ~3 not ~7 so the second access could still cross a page boundary and fault. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: load_unaligned_zeropad() on x86-64 2020-11-14 15:53 load_unaligned_zeropad() on x86-64 David Laight @ 2020-11-14 18:02 ` Linus Torvalds 2020-11-14 23:17 ` David Laight 0 siblings, 1 reply; 3+ messages in thread From: Linus Torvalds @ 2020-11-14 18:02 UTC (permalink / raw) To: David Laight; +Cc: linux-kernel, x86 On Sat, Nov 14, 2020 at 7:53 AM David Laight <David.Laight@aculab.com> wrote: > > The change e419b4cc585680940bc42f8ca8a071d6023fb1bb added > asm code for load_unaligned_zeropad(). > > However it doesn't look right for 64bit. > It masks the address with ~3 not ~7 so the second > access could still cross a page boundary and fault. Can you explain more what you think is wrong? It uses "and %3,%1\n\t" for the masking, but note how that's a "%3", not a "$3". And %3 is this asm argument "i" (-sizeof(unsigned long)), which is -4 or -8 (which is the same as ~3 or ~7). The other masking is to get the byte offset within the unsigned long, to do the shifting. Again, that uses '%4', which is "i" (sizeof(unsigned long)-1)); so 3 or 7. So on my build, the code expands to 1: mov (%rsi),%rdx # MEM[(long unsigned int *)ct_58], ret 2: .section .fixup,"ax" 3: lea (%rsi),%rcx # MEM[(long unsigned int *)ct_58], dummy and $-8,%rcx #, dummy mov (%rcx),%rdx # dummy, ret leal (%rsi),%ecx # MEM[(long unsigned int *)ct_58] andl $7,%ecx # shll $3,%ecx shr %cl,%rdx # ret jmp 2b .previous which looks ok to me. It's possible that it's buggy (that page crossing basically never happens - only with PAGEALLOC debugging, and even then only in some really odd and unlikely situations). So it gets basically zero test coverage, which is never a good thing. But if it's buggy, it's not obvious to me, and I don't see any ~3 issue. Linus ^ permalink raw reply [flat|nested] 3+ messages in thread
* RE: load_unaligned_zeropad() on x86-64 2020-11-14 18:02 ` Linus Torvalds @ 2020-11-14 23:17 ` David Laight 0 siblings, 0 replies; 3+ messages in thread From: David Laight @ 2020-11-14 23:17 UTC (permalink / raw) To: 'Linus Torvalds'; +Cc: linux-kernel, x86 From: Linus Torvalds > Sent: 14 November 2020 18:02 > > On Sat, Nov 14, 2020 at 7:53 AM David Laight <David.Laight@aculab.com> wrote: > > > > The change e419b4cc585680940bc42f8ca8a071d6023fb1bb added > > asm code for load_unaligned_zeropad(). > > > > However it doesn't look right for 64bit. > > It masks the address with ~3 not ~7 so the second > > access could still cross a page boundary and fault. > > Can you explain more what you think is wrong? > > It uses > > "and %3,%1\n\t" > > for the masking, but note how that's a "%3", not a "$3". Maybe I need to get better glasses. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-11-14 23:17 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-11-14 15:53 load_unaligned_zeropad() on x86-64 David Laight 2020-11-14 18:02 ` Linus Torvalds 2020-11-14 23:17 ` David Laight
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).