All of lore.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: 30+ 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 10:41   ` Joerg Roedel
2009-06-05 11:38   ` FUJITA Tomonori
2009-06-05 11:38     ` FUJITA Tomonori
2009-06-05 12:44     ` Joerg Roedel
2009-06-05 12:44       ` Joerg Roedel
2009-06-05 14:57     ` Arnd Bergmann
2009-06-05 15:52   ` Torsten Kaiser
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  8:10       ` Joerg Roedel
2009-06-11 17:38       ` Torsten Kaiser
2009-06-12  7:50         ` Joerg Roedel
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.