Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1673075
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 |
| Date | 2017-06-22 23:50 +0200 |
| Message-ID | <tVi9c-1Mr-9@gated-at.bofh.it> (permalink) |
| References | (4 earlier) <tUVvY-3sm-37@gated-at.bofh.it> <tUVFD-3xy-7@gated-at.bofh.it> <tVb7H-5Qr-5@gated-at.bofh.it> <tVbhp-5Uv-37@gated-at.bofh.it> <tVfXH-uK-17@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Jun 22, 2017 at 08:25:16PM +0100, Al Viro wrote:
> > All I know at this
> > point is that commit f2ed8beb with 46f401c4 backported boots OK and commit
> > 3448890c with the same backport fails.
> >
> > I will try loading jessie and see what happens.
>
> I would recheck which kernels are being booted - I had screwed that up during long
> bisects often enough...
>
> BTW, could you try to check what happens if you kill the
> if (__builtin_constant_p(n) && (n <= 8))
> bits in raw_copy_{to,from}_user()? The usefulness of those (in __copy_from_user()
> originally) had always been dubious and the things are simpler without them.
> If _that_ turns out to cure breakage, I would be very surprised, though.
FWIW, having dug through the __copy_tofrom_user() change in 3448890c, I don't see
anything that would be likely to cause that effect, be it on hardware or emulated.
Moreover, had that been fucked up, I would've expected lots and lots of folks
screaming by now - boot being broken since -rc1 tends to have such effect, even
if nobody had noticed that in -next last cycle.
What I can prove is that
* __copy_tofrom_user() return value is unchanged in all cases
* the only difference in its behaviour is that prior to that commit
some cases when it returns non-zero used to do memset(dest + something, 0,
retval) and now they do not. _All_ such cases must have stepped into a fault
on load from src + something.
And looking through arch/powerpc callers of all that bunch, I don't see any
candidates for being buggered by disappearing memset() on partial copy with
faulting read; note that copy_from_user() *will* memset() explicitly if
raw_copy_from_user() returns non-zero. I wondered if it could be a weird
case when copy_to_user() had been running into an unmapped area of *source*
and proceeded to zero the tail of destination, but I don't see anything
likely in arch/powerpc and anything in arch-independent code would've been
oopsing on that all along for some architectures...
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Larry Finger <Larry.Finger@lwfinger.net> - 2017-06-21 17:20 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-21 23:30 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-21 23:40 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Larry Finger <Larry.Finger@lwfinger.net> - 2017-06-21 23:50 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-22 16:20 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Larry Finger <Larry.Finger@lwfinger.net> - 2017-06-22 16:30 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-22 21:30 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-22 23:50 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Larry Finger <Larry.Finger@lwfinger.net> - 2017-06-23 20:50 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-23 22:40 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Larry Finger <Larry.Finger@lwfinger.net> - 2017-06-24 19:30 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-25 12:00 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-25 13:20 +0200
gcc 4.6.3 miscompile on ppc32 (was Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3) Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-25 23:00 +0200
Re: gcc 4.6.3 miscompile on ppc32 (was Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3) Segher Boessenkool <segher@kernel.crashing.org> - 2017-06-25 23:50 +0200
Re: gcc 4.6.3 miscompile on ppc32 (was Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3) Al Viro <viro@ZenIV.linux.org.uk> - 2017-06-26 00:30 +0200
Re: gcc 4.6.3 miscompile on ppc32 (was Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3) Michael Ellerman <mpe@ellerman.id.au> - 2017-06-26 15:40 +0200
Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3 Michael Ellerman <mpe@ellerman.id.au> - 2017-06-26 15:50 +0200
csiph-web