Date: Thu, 22 Jun 2017 22:41:59 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
        Thorsten Leemhuis <regressions@leemhuis.info>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>
Subject: Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to
 commit 3448890c32c3
Message-ID: <20170622214159.GR10672@ZenIV.linux.org.uk>
References: <69187aa4-611f-b08a-8d14-b8fa47b4c464@lwfinger.net>
 <1588557c-2706-0c0e-3387-4ae65d0b5790@lwfinger.net>
 <20170621212257.GN10672@ZenIV.linux.org.uk>
 <5f4b9fa4-262a-31b1-32ba-a2f6e789b3d6@lwfinger.net>
 <20170621213415.GO10672@ZenIV.linux.org.uk>
 <655d304e-e455-6e0c-56e1-f127653ea13c@lwfinger.net>
 <20170622141203.GP10672@ZenIV.linux.org.uk>
 <7bbd4c87-e8ff-5f83-8c4c-e205872083bf@lwfinger.net>
 <20170622192515.GQ10672@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170622192515.GQ10672@ZenIV.linux.org.uk>
User-Agent: Mutt/1.8.0 (2017-02-23)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2005
Lines: 37

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