linux-kernel - Re: [PATCH] usb: fix number of mapped SG DMA entries

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1112151058090.1644-100000@iolanthe.rowland.org>
Date:	Thu, 15 Dec 2011 11:01:41 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
cc:	Clemens Ladisch <clemens@...isch.de>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: fix number of mapped SG DMA entries

On Thu, 15 Dec 2011, Sebastian Andrzej Siewior wrote:

> * Alan Stern | 2011-12-04 11:59:32 [-0500]:
> 
> >On Sat, 3 Dec 2011, Clemens Ladisch wrote:
> >
> >> Add a new field num_mapped_sgs to struct urb so that we have a place to
> >> store the number of mapped entries and can also retain the original
> >> value of entries in num_sgs.  Previously, usb_hcd_map_urb_for_dma()
> >> would overwrite this with the number of mapped entries, which would
> >> break dma_unmap_sg() because it requires the original number of entries.
> >> 
> >> This fixes warnings like the following when using USB storage devices:
> >>  ------------[ cut here ]------------
> >>  WARNING: at lib/dma-debug.c:902 check_unmap+0x4e4/0x695()
> >>  ehci_hcd 0000:00:12.2: DMA-API: device driver frees DMA sg list with different entry count [map count=4] [unmap count=1]
> >
> >Interesting.  Do you have any idea why this warning didn't show up 
> >earlier?  Is there perhaps a Kconfig option I ought to be using?
> 
> My question here is why don't we map the complete sg list but only
> one entry. What happens to the remaining few sg list entries? Don't we
> sent too less data?

I don't know exactly what happened in this particular case -- probably 
there's no way to find out.  However, all the data is supposed to be 
mapped, regardless of the number of entries.

> Is there anything special you do to get into this kind of situation?
> Like 16GiB of memory on 32bit with highmem and a brutal disk/io test
> case so?

As I understand it, the typical case is that two SG entries in a row 
refer to adjacent pages of physical memory.  The mapping routine then 
collapses them into a single entry referring to all the pages.

However, this is not the sort of thing you can deliberately cause, 
unless you set up your SG list by hand.

Alan Stern

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