linux-kernel - Re: BUG in drivers/dma/ioat/dma

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4C2CCE67.6070600@intel.com>
Date:	Thu, 01 Jul 2010 10:20:39 -0700
From:	Dan Williams <dan.j.williams@...el.com>
To:	"Woodhouse, David" <david.woodhouse@...el.com>
CC:	Chris Li <lkml@...isli.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: BUG in drivers/dma/ioat/dma_v2.c:314

On 7/1/2010 1:15 AM, Woodhouse, David wrote:
> On Thu, 2010-07-01 at 08:26 +0100, Williams, Dan J wrote:
>> On 7/1/2010 12:12 AM, Woodhouse, David wrote:
>>> On Thu, 2010-07-01 at 07:51 +0100, Williams, Dan J wrote:
>>>> This version of the device only exists on the 5400 chipset and always
>>>> has its own iommu, but since other platforms get the DMAR entry right I
>>>> think this hammer is too big?  Wouldn't this break VT-d operation on
>>>> non-busted platforms?
>>>
>>> That just means we have to get the quirk right. Does 'this version' of
>>> the device have its own PCI ID? We can always fall back to checking the
>>> ID of the device at 0000:00:00.0 to check which chipset we're on.
>>>
>>
>> PCI_DEVICE_ID_INTEL_IOAT_SNB only exists on this chipset
>
> Something like this, then?
>

Thanks David!

Chris, attached is a combined patch with David's catch for the VT-d 
misconfiguration, and some code to more gracefully handle this init 
failure in the driver.  Can you see if this resolves the problem? 
(remove the prior patches I have sent).

Thanks,
Dan


View attachment "ioat-catch-broken-vtd.patch" of type "text/plain" (4091 bytes)