* 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).