public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro@8bytes.org>
To: Torsten Kaiser <just.for.lkml@googlemail.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>,
	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	mingo@elte.hu, lethal@linux-sh.org, hancockrwd@gmail.com,
	jens.axboe@oracle.com, bharrosh@panasas.com,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] dma-debug: disable DMA_API_DEBUG for now
Date: Fri, 5 Jun 2009 20:20:17 +0200	[thread overview]
Message-ID: <20090605182015.GA10342@8bytes.org> (raw)
In-Reply-To: <64bb37e0906050852g2be64c7elb2872a6129d13f56@mail.gmail.com>

On Fri, Jun 05, 2009 at 05:52:27PM +0200, Torsten Kaiser wrote:
> 
> This doesn't look right to me.
> The comment above says "returns the entry from the hash which fits
> best", but this will always return NULL, if there are are multiple
> entrys, but no perfect match.

This is intentional. If there is no perfect-fit there is no way to tell
which entry was meant. So we potentially report wrong errors with a
wrong mapping backtrace which confuses even more than the wrong
"DMA-API: device driver tries to free DMA memory it has not allocated".

> Should there be a warning if more then one possible match were found?

True. That would be better. But I tried to keep the code change as small
as possible without disabling the feature completly.

> * driver maps address 'a' with size 1
> * driver maps same address 'a' with size 2
> * driver wrongly unmaps the second allocation with size 1
>   -> no warning, because the first allocation is returned

Hmm, I am not sure if we can handle this situation correctly in the
dma-debug code. There is no unique key to identify a mapping request
which allows to assign an unmap request to it. Currently dma-debug uses
device and dma-address. But that seems not to be sufficient. The
best-fit algorithm is also a but fuzzy of course.

> * driver wants to correctly unmap the first allocation
>   -> wrong warning about this unmap because size mismatch

Ok, at least we get a warning about a bug. Not very useful because it
reports the wrong bug. Is this the situation which triggered the
original bug report?

> Also what about sg_call_ents and sg_mapped_ents?
> Could it be possible to get the same address/size with different sg-counts.

It looks not forbidden in the API. So I guess this can happen too.

Regards,

	Joerg

  reply	other threads:[~2009-06-05 18:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-05  8:33 [PATCH] dma-debug: disable DMA_API_DEBUG for now FUJITA Tomonori
2009-06-05 10:41 ` Joerg Roedel
2009-06-05 11:38   ` FUJITA Tomonori
2009-06-05 12:44     ` Joerg Roedel
2009-06-05 14:57     ` Arnd Bergmann
2009-06-05 15:52   ` Torsten Kaiser
2009-06-05 18:20     ` Joerg Roedel [this message]
2009-06-05 20:25       ` Torsten Kaiser
2009-06-05 22:11       ` Torsten Kaiser
2009-06-07  8:13   ` Ingo Molnar
2009-06-07  8:22     ` Torsten Kaiser
2009-06-07 10:45     ` FUJITA Tomonori
2009-06-07 10:22   ` [tip:core/iommu] dma-debug: change hash_bucket_find from first-fit to best-fit tip-bot for Joerg Roedel
2009-06-10 20:41   ` [PATCH] dma-debug: disable DMA_API_DEBUG for now Torsten Kaiser
2009-06-11  8:10     ` Joerg Roedel
2009-06-11 17:38       ` Torsten Kaiser
2009-06-12  7:50         ` Joerg Roedel
2009-06-12 14:13         ` Joerg Roedel
2009-06-12 14:51           ` Torsten Kaiser
2009-06-13 11:10             ` Joerg Roedel
2009-06-13 14:26               ` Torsten Kaiser
2009-06-13 17:34                 ` Joerg Roedel
2009-06-13 17:08           ` Torsten Kaiser
2009-06-15  7:46             ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090605182015.GA10342@8bytes.org \
    --to=joro@8bytes.org \
    --cc=bharrosh@panasas.com \
    --cc=fujita.tomonori@lab.ntt.co.jp \
    --cc=hancockrwd@gmail.com \
    --cc=jens.axboe@oracle.com \
    --cc=joerg.roedel@amd.com \
    --cc=just.for.lkml@googlemail.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox