linux-kernel - Re: Regression in kernel 4.12-rc1 for Powerpc 32

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Jun 2017 13:49:16 -0500
From:   Larry Finger <Larry.Finger@...inger.net>
To:     Al Viro <viro@...IV.linux.org.uk>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thorsten Leemhuis <regressions@...mhuis.info>
Subject: Re: Regression in kernel 4.12-rc1 for Powerpc 32 - bisected to commit
 3448890c32c3

On 06/22/2017 02:25 PM, Al Viro wrote:
> On Thu, Jun 22, 2017 at 09:19:58AM -0500, Larry Finger wrote:
> 
>>> Ugh...  MintPPC appears to be dead.  On KVM with Debian userland (either
>>> jessie or wheezy - no difference in result) booting the commit in
>>> question with your .config oopses as soon as pata_macio is initialized,
>>> due to the bug in "treewide: Move dma_ops from struct dev_archdata into
>>> struct device", and after cherry-picking your own fix for that (commit
>>> 46f401c4297a "powerpc/pmac: Fix crash in dma-mapping.h with NULL dma_ops")
>>> the result boots just fine.
>>>
>>> Again, that happens both for Debian 8 and Debian 7 userlands, so unless
>>> Mint had been doing something very odd there, I would question the accuracy
>>> of your bisect...
>   
>> Any chance that real hardware differs from KVM emulation?
> 
> For that one?  Bloody unlikely; udev could, theoretically, hit different codepaths
> due to different devices being observed, etc., but changes in that commit are
> not in the areas that would be easy to get wrong in emulator.
> 
>> 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.
> 
Sorry I was gone so long. Installing jessie on this box resulted in a crash on 
boot. Lubuntu 14.04 yielded a desktop with a functioning cursor, but nothing 
else. Finally, Ubuntu 12.04 resulted in a working system. I hate Unity, but I 
guess I'm stuck for now.

I know how easy it is to screw up a long bisection by booting the wrong kernel. 
To help that problem and to work around the yaconf/yboot nonsense on the MAC, my 
/etc/yaconf has always had generic kernel stanzas with only default, old, and 
original kernels mentioned. From there I use a local script to finish a kernel 
installation by moving the default links to the old ones and creating the new 
default links pointing to the current kernel. With those long-tested scripts, 
I'm sure that I am booting the one I want.

With the new installation, kernel 4.12-rc6 failed, as did 3448890c with the 
backported 46f401c4 added.

Replacing "if (__builtin_constant_p(n) && (n <= 8))" with "if (0)" had no effect.

Larry