linux-kernel - Re: [PATCH] swiotlb: add kernel error message to track iobtlb overflow buffer usage

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1346855913.2589.10.camel@lorien2>
Date:	Wed, 05 Sep 2012 08:38:33 -0600
From:	Shuah Khan <shuah.khan@...com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	fujita.tomonori@....ntt.co.jp, paul.gortmaker@...driver.com,
	bhelgaas@...gle.com, amwang@...hat.com,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	linux-kernel@...r.kernel.org, shuahkhan@...il.com
Subject: Re: [PATCH] swiotlb: add kernel error message to track iobtlb
 overflow buffer usage

On Tue, 2012-09-04 at 16:28 -0700, Andrew Morton wrote:
> On Fri, 31 Aug 2012 18:55:59 -0600
> Shuah Khan <shuah.khan@...com> wrote:
> 
> > Add kernel error message to track iotlb overflow buffer triggers to understand
> > how often the overflow buffer gets used.
> > 
> > Signed-off-by: Shuah Khan <shuah.khan@...com>
> > ---
> >  lib/swiotlb.c |    1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> > index 45bc1f8..597d7b9 100644
> > --- a/lib/swiotlb.c
> > +++ b/lib/swiotlb.c
> > @@ -682,6 +682,7 @@ dma_addr_t swiotlb_map_page(struct device *dev, struct page *page,
> >  	if (!map) {
> >  		swiotlb_full(dev, size, dir, 1);
> >  		map = io_tlb_overflow_buffer;
> > +		dev_err(dev, "SWIOTLB is full. Mapping overflow buffer.\n");
> >  	}
> >  
> >  	dev_addr = swiotlb_virt_to_bus(dev, map);
> 
> hm.  I would view this as a developer-only debugging thing which
> shouldn't be present in production code.  Plus there's a potential that
> some poor person will have his logs flooded with this message.

Yes. I agree.
> 
> A more typical way of handling this would be to increment a stats
> counter, accessible in procfs or debugfs.
> 

Right. I will work on it. Maybe there is a way to combine this with
dma-debug dma mapping error tracking work I am doing - will look into.

-- Shuah


--
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/