From: Oliver Neukum <oliver@neukum.org>
To: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Cc: linux-usb@vger.kernel.org, Ming Lei <tom.leiming@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Network Development <netdev@vger.kernel.org>
Subject: Re: [RFC PATCH] usb: hcd: warn about URB buffers that are not DMA aligned and are about to be DMA mapped
Date: Fri, 28 Jun 2013 14:58:23 +0200 [thread overview]
Message-ID: <3357770.hCSJD4DdXz@linux-5eaq.site> (raw)
In-Reply-To: <51CD83FF.2030704@iki.fi>
On Friday 28 June 2013 15:39:27 Jussi Kivilinna wrote:
> On 16.06.2013 13:35, Jussi Kivilinna wrote:
> > On 16.06.2013 11:21, Oliver Neukum wrote:
> >> On Saturday 15 June 2013 16:22:30 Jussi Kivilinna wrote:
> >>
> >>> Hm.. rethink this a bit.
> >>>
> >>> Transfer buffer might be dma aligned but shorter than cacheline and end of cacheline
> >>> used as something else. Manual alignment by host driver does not catch that
> >>> or fix that.
> >>> So, yes.. dma mapping should work with unaligned buffers, but maybe the actual
> >>> problem is multiple buffers from same cacheline.
> >>
> >> The buffers kmalloc() returns are OK in that regard. A driver that uses
> >> a buffer for anything but buffering is buggy.
> >
> > Ok, I'll look at that direction. Thanks.
> >
>
> So if I understood correctly, drivers that allocate these as part of larger structures (struct *_device etc) are doing wrong thing and are potentially buggy. And this is because cachelines of buffers can be DMA mapped after usb_submit_urb() and editing same cacheline while URB is in-flight can therefore be hazardous.
>
> I checked setup_packet and transfer_buffer usage of some drivers in 3.9.8 and made some observations. Should these be fixed?
>
> URB setup_packet and transfer_buffer part of same structure (might share same cacheline for same URB):
> * iforce:
> - http://lxr.linux.no/linux+v3.9.8/drivers/input/joystick/iforce/iforce-usb.c#L173
> - http://lxr.linux.no/linux+v3.9.8/drivers/input/joystick/iforce/iforce.h#L101
Buggy
> * usbvision:
> - http://lxr.linux.no/linux+v3.9.8/drivers/media/usb/usbvision/usbvision-core.c#L1445
> - http://lxr.linux.no/linux+v3.9.8/drivers/media/usb/usbvision/usbvision.h#L366
Buggy
> * catc:
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/usb/catc.c#L499
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/usb/catc.c#L500
> - ctrl_buf, ctrl_dr: http://lxr.linux.no/linux+v3.9.8/drivers/net/usb/catc.c#L162
> * rtl8150:
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/usb/rtl8150.c#L200
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/usb/rtl8150.c#L128
> * rt2x000usb:
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/wireless/rt2x00/rt2x00usb.c#L212
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/wireless/rt2x00/rt2x00usb.c#L169
> * rtl8187:
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/wireless/rtl818x/rtl8187/dev.c#L156
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/wireless/rtl818x/rtl8187/dev.c#L130
> * uss720:
> - http://lxr.linux.no/linux+v3.9.8/drivers/usb/misc/uss720.c#L176
> - http://lxr.linux.no/linux+v3.9.8/drivers/usb/misc/uss720.c#L72
Well, I didn't look through them all, but we must assume that they are buggy.
> URB transfer_buffer array (transfer buffers preloaded as array, element size less than cacheline):
> * rtlwifi:
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/wireless/rtlwifi/usb.c#L152
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/wireless/rtlwifi/wifi.h#L1859
> - http://lxr.linux.no/linux+v3.9.8/drivers/net/wireless/rtlwifi/usb.c#L980
Good catch.
This is a very large number. I suggest you split it up.
Regards
Oliver
next prev parent reply other threads:[~2013-06-28 12:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130614133803.25747.98705.stgit@localhost6.localdomain6>
[not found] ` <20130614133803.25747.98705.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
2013-06-15 7:41 ` [RFC PATCH] usb: hcd: warn about URB buffers that are not DMA aligned and are about to be DMA mapped Ming Lei
2013-06-15 10:19 ` Jussi Kivilinna
[not found] ` <51BC3F9E.3010605-X3B1VOXEql0@public.gmane.org>
2013-06-15 12:07 ` Ming Lei
[not found] ` <CACVXFVMe9fgdiDTRC0rWvwZJM8aT7AZY8Q1MwiOTc4ks0PQPOg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-06-15 13:10 ` Jussi Kivilinna
2013-06-15 13:22 ` Jussi Kivilinna
[not found] ` <51BC6A96.7030707-X3B1VOXEql0@public.gmane.org>
2013-06-16 8:21 ` Oliver Neukum
2013-06-16 10:35 ` Jussi Kivilinna
2013-06-28 12:39 ` Jussi Kivilinna
2013-06-28 12:58 ` Oliver Neukum [this message]
2013-06-15 13:47 ` Ming Lei
2013-06-16 10:34 ` Jussi Kivilinna
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=3357770.hCSJD4DdXz@linux-5eaq.site \
--to=oliver@neukum.org \
--cc=gregkh@linuxfoundation.org \
--cc=jussi.kivilinna@iki.fi \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tom.leiming@gmail.com \
/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.