Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1673075

Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3

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

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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