lkml.org 
[lkml]   [2017]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit 3448890c32c3
    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...

    \
     
     \ /
      Last update: 2017-06-22 23:42    [W:4.569 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site