All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Shuah Khan <shuah.khan@hp.com>
Cc: Joerg Roedel <joerg.roedel@amd.com>, Greg KH <greg@kroah.com>,
	tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	rob@landley.net, akpm@linux-foundation.org, bhelgaas@google.com,
	stern@rowland.harvard.edu, LKML <linux-kernel@vger.kernel.org>,
	linux-doc@vger.kernel.org, devel@linuxdriverproject.org,
	x86@kernel.org, shuahkhan@gmail.com
Subject: Re: [PATCH] dma-debug: New interfaces to debug dma mapping errors
Date: Tue, 18 Sep 2012 15:45:09 -0400	[thread overview]
Message-ID: <20120918194509.GA14655@phenom.dumpdata.com> (raw)
In-Reply-To: <1347997369.2747.68.camel@lorien2>

On Tue, Sep 18, 2012 at 01:42:49PM -0600, Shuah Khan wrote:
> On Tue, 2012-09-18 at 15:34 +0200, Joerg Roedel wrote:
> > On Mon, Sep 17, 2012 at 04:45:15PM -0600, Shuah Khan wrote:
> > > Yeah. I will firm up my ideas a bit and summarize in a day or two. Would
> > > like to hear your ideas as well at that time, so we can pick the one
> > > that works the best.
> > 
> > I think the best approach for this functionality is to add a flag to
> > 'struct dma_debug_entry' which tells whether the address has been
> > checked with dma_mapping error or not. On unmap or driver unload you can
> > then check for that flag and print a warning when an unchecked address
> > is detected.
> 
> Was hoping to get comments from you as well. You are original author for
> this dam-debug module.
> 
> Are you ok with the system wide and per device error counts I added? Any
> comments on the overall approach?
> 
> The approach you suggested will cover the cases where drivers fail to
> check good map cases. We won't able to catch failed maps that get used
> without checks. Are you not concerned about these cases? These could
> cause a silent error with wild writes or could bring the system down. Or
> are you recommending changing the infrastructure to track failed maps as
> well?
> 
> I am still pursuing a way to track failed map cases. I combined the flag
> idea with one of the ideas I am looking into. Details below: (if this
> sounds like a reasonable approach, I can do v2 patch and we can discuss
> the code)
> 
> . Add new fields dma_map_errors, dma_map_errors_not_checked,
> dma_unmap_errors, iotlb_overflow_cnt, and flag to struct
> dma_debug_entry. Maybe flag is not even needed if
> dma_map_errors_not_checked can double as status.

Not sure if you need the iotlb_overflow_cnt anymore. Just having
dma_map_errors_not_checked and the dma_map_errors
(which you can increment/decrement) would suffice. Unless you
were thinking to check that dma_map_errors == dma_unmap_errors and
if they != then produce a warning?
> 
> . Enhance dma_debug_init() to create a second table to track failed maps
> with PREALLOC_DMA_DEBUG_ENTRIES/64 = 64. 64 devices probably is good
> enough.
> 
> . Entries added to this new table when debug_dma_map_page() detects
> error when mapping error is detected for the first time. Subsequent
> errors, will increment dma_map_errors, dma_map_errors_not_checked for
> that the device that is tracked by this entry. Note: paddr field could
> work as an index into this table (existing table uses dma_addr)

> 
> . Decrement dma_map_errors_not_checked from debug_dma_mapping_error(),
> clear the flag.
> 
> . check_unmap() when it detects mapping error, checks flag (status) and
> prints warn message.

<nods>
> 
> -- Shuah

  reply	other threads:[~2012-09-18 19:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-17  0:52 [PATCH] dma-debug: New interfaces to debug dma mapping errors Shuah Khan
2012-09-17  2:07 ` Greg KH
2012-09-17 14:45   ` Shuah Khan
2012-09-17 15:25     ` Greg KH
2012-09-17 13:39 ` Konrad Rzeszutek Wilk
2012-09-17 15:52   ` Shuah Khan
2012-09-17 17:23     ` Konrad Rzeszutek Wilk
2012-09-17 22:45       ` Shuah Khan
2012-09-18 13:34         ` Joerg Roedel
2012-09-18 19:42           ` Shuah Khan
2012-09-18 19:45             ` Konrad Rzeszutek Wilk [this message]
2012-09-18 20:34               ` Shuah Khan
2012-09-19 13:08             ` Joerg Roedel
2012-09-19 19:16               ` Shuah Khan
2012-09-26  1:05 ` [PATCH v2] " Shuah Khan
2012-09-26 13:12   ` Konrad Rzeszutek Wilk
2012-09-26 16:23     ` Shuah Khan
2012-09-27 10:20   ` Joerg Roedel
2012-09-27 14:13     ` Shuah Khan
2012-10-03 14:55   ` [PATCH v3] " Shuah Khan
2012-10-03 21:45     ` Andrew Morton
2012-10-04 14:01       ` Konrad Rzeszutek Wilk
2012-10-04 22:16         ` Shuah Khan
2012-10-04 17:38     ` Konrad Rzeszutek Wilk
2012-10-04 22:19       ` Shuah Khan
2012-10-05  1:23     ` [PATCH v4] " Shuah Khan
2012-10-05 22:51       ` Andrew Morton
2012-10-08 17:07         ` Shuah Khan
2012-10-09 21:02           ` Andrew Morton
2012-10-10 21:50             ` Shuah Khan

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=20120918194509.GA14655@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhelgaas@google.com \
    --cc=devel@linuxdriverproject.org \
    --cc=greg@kroah.com \
    --cc=hpa@zytor.com \
    --cc=joerg.roedel@amd.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rob@landley.net \
    --cc=shuah.khan@hp.com \
    --cc=shuahkhan@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.