linux-kernel - Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit 5657933dbb6e

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]

Message-ID: <92adfda3-9242-11e0-152b-081c679a1dd9@lwfinger.net>
Date:   Mon, 6 Mar 2017 18:43:18 -0600
From:   Larry Finger <Larry.Finger@...inger.net>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Bart Van Assche <Bart.VanAssche@...disk.com>,
        "regressions@...mhuis.info" <regressions@...mhuis.info>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Regression in 4.11 - PowerPC crashes on boot, bisected to commit
 5657933dbb6e

On 03/06/2017 03:48 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2017-03-06 at 13:46 -0600, Larry Finger wrote:
>> I was able to create a PPC emulation with debian-8.7.1-powerpc-CD-1.iso
>>> following the instructions in https://gmplib.org/~tege/qemu.html. My only
>> problem was that "-net tap" fails and I did not find any way to get networking
>> working.
>>
>> After looking at the screen through a number of crashes, I have determined that
>> the top entry in the traceback comes from dmam_alloc_coherent(). I have not been
>> able to see the offset to determine which BUG_ON call in that routine is being
>> triggered.
>>
>> I tried to modify panic() to see if I could keep the screen on longer after the
>> failure, but no joy so far.
>
> I think the problem is this code in drivers/macintosh/macio_asic.c:
>
> #ifdef CONFIG_PCI
> 	/* Set the DMA ops to the ones from the PCI device, this could be
> 	 * fishy if we didn't know that on PowerMac it's always direct ops
> 	 * or iommu ops that will work fine
> 	 *
> 	 * To get all the fields, copy all archdata
> 	 */
> 	dev->ofdev.dev.archdata = chip->lbus.pdev->dev.archdata;
> #endif /* CONFIG_PCI */
>
> This is definitely bad. A quick fix is to copy the new dev->dma_ops field
> (as well, there is still stuff in archdata that we need too).
>
> A better long term fix is to have a set of macio_dma_ops wrappers that do
> "the right thing".

The one-line fix that copies dma_ops does indeed fix the problem.

What do you want to do from here? I could prepare a q & d patch to resolve the 
regression, or would you prefer to do "the right thing" now?

Larry