linux-kernel - Re: [PATCH] dma-debug: disable DMA_API

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: <20090607194506J.fujita.tomonori@lab.ntt.co.jp>
Date:	Sun, 7 Jun 2009 19:45:12 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	mingo@...e.hu
Cc:	joerg.roedel@....com, fujita.tomonori@....ntt.co.jp,
	torvalds@...ux-foundation.org, lethal@...ux-sh.org,
	just.for.lkml@...glemail.com, hancockrwd@...il.com,
	jens.axboe@...cle.com, bharrosh@...asas.com,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] dma-debug: disable DMA_API_DEBUG for now

On Sun, 7 Jun 2009 10:13:05 +0200
Ingo Molnar <mingo@...e.hu> wrote:

> 
> * Joerg Roedel <joerg.roedel@....com> wrote:
> 
> > 
> > On Fri, Jun 05, 2009 at 05:33:14PM +0900, FUJITA Tomonori wrote:
> > > dma-debugs wrongly assumes that no multiple DMA transfers are
> > > performed against the same dma address on one device at the same
> > > time. However it's true only with hardware IOMMUs. For example, an
> > > application can easily send the same buffer twice with different
> > > lengths to one device by using DIO and AIO. If these requests are not
> > > unmapped in the same order in which they were mapped,
> > > hash_bucket_find() finds a wrong entry and gives a false warning.
> > > 
> > > We should fix this before 2.6.30 release. Seems that there is no
> > > easy way to fix it. I think that it's better to just disable
> > > dma-debug for now.
> > > 
> > > Torsten Kaiser found this bug with the RAID1 configuration:
> > > 
> > > http://marc.info/?t=124336541900008&r=1&w=2
> > > 
> > 
> > Argh, I never thought that this can happen. But its not explicitly 
> > forbidden so we have to handle this situation. Thanks for tracking 
> > down the bug to this issue.
> >
> > However, I think there is a somehow simple fix for the issue. 
> > Patch is attached. Its the least intrusive way I can think of to 
> > fix this problem.
> >
> > But its up to Linus/Ingo to decide if it can be accepted at this 
> > very late point in the cycle. Since dma-debug is new with 2.6.30 
> > it will at least not introduce any regression. [...]
> 
> I think it's too late for v2.6.30 to do any of the changes - and the 
> DMA debug facility is off by default.

Fedora enables it by default and seems that we got some bogus bug
reports. I like not to see any bogus bug reports about v2.6.30. So I
prefer to disable dma-debug feature.


> Also, i think such DMA patterns, while 'allowed' can be quite 
> dangerous as its such a rare usage combination really. AIO and DIO 
> are crazy to begin with, mixing AIO and DIO for the same buffer is 
> madness square two. (It can result in 3 agents for the same memory 
> address: CPU, dma1 and dma2. How many interesting chipset erratums 
> could there be related to such scenarios?)

As Torsten pointed out, this bug happens on common and sane
configurations. And if you want to write the same contents to two
places on disk, AIO and DIO is a reasonable solution, I think.


> But it is certainly not the task of a debug facility to restrict 
> existing user-visible ABIs, so fixing the false positive is correct.
> 
> So i've applied your fix to the iommu branch for v2.6.31 and marked 
> it for -stable backporting, that way 2.6.30.1 will be able to pick 
> the patch up (if it remains problem-free in testing).
> 

Joerg patch weakens the checking capability. IMHO, it's the wrong
direction.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/