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]

Date:   Tue, 07 Mar 2017 08:48:48 +1100
From:   Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:     Larry Finger <Larry.Finger@...inger.net>,
        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 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".

Cheers,
Ben.