From: Duncan Sands <baldrick@free.fr>
To: Oliver Neukum <oliver@neukum.org>, Greg KH <greg@kroah.com>
Cc: linux-usb-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Frederic Detienne <fd@cisco.com>
Subject: Re: [linux-usb-devel] [PATCH 1/9] USB usbfs: take a reference to the usb device
Date: Sun, 18 Apr 2004 11:35:28 +0200 [thread overview]
Message-ID: <200404181136.32308.baldrick@free.fr> (raw)
In-Reply-To: <200404172233.03552.oliver@neukum.org>
On Saturday 17 April 2004 22:33, Oliver Neukum wrote:
> > riddled with races of this kind. The simplest solution is to
> > systematically take ps->dev->serialize when entering the usbfs routines,
> > which is what my patches do. This should be regarded as a first step: it
>
> What is the alternative?
The alternative is to start at the lower levels and work up (while here I propose
starting at the top levels and working down): trying to lock small regions in many
places. I rejected this as too error prone (remember that usbfs is a bit of a mess).
Anyway, if done correctly the end result would be much the same as applying this
patch and doing step (2).
> > gives correctness, but at the cost of a probable performance hit. In
> > later steps we can (1) turn dev->serialize into a rwsem
>
> Rwsems are _slower_ in the normal case of no contention.
Right, but remember that dev->serialize is per device, not per interface. So if two
programs grab different interfaces of the same device using usbfs, or if multiple
threads in the same program beat on the same interface, then they could lose time
fighting for dev->serialize when in fact they could run in parallel. Personally I doubt
it matters much, but since most of usbfs only requires read access to the data structures
protected by dev->serialize, it seems logical to use a rwsem.
> > (2) push the acquisition of dev->serialize down to the lower levels as
> > they are fixed up.
>
> Why?
Efficiency. The main reason is that the copy to/from user calls are inside the locked region :)
As for the other places where the lock could be dropped, I guess measurement is required to
see if it gains anything.
Ciao,
Duncan.
next prev parent reply other threads:[~2004-04-18 9:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-14 10:29 [PATCH 1/9] USB usbfs: take a reference to the usb device Duncan Sands
2004-04-17 20:17 ` [linux-usb-devel] " Duncan Sands
2004-04-17 20:33 ` Oliver Neukum
2004-04-18 9:35 ` Duncan Sands [this message]
2004-04-18 13:57 ` Oliver Neukum
2004-04-18 14:08 ` Duncan Sands
2004-04-18 14:40 ` Alan Stern
2004-04-19 17:25 ` David Brownell
2004-04-23 23:18 ` Greg KH
2004-04-26 14:05 ` Duncan Sands
2004-04-26 22:14 ` Greg KH
2004-04-27 8:58 ` [linux-usb-devel] " Oliver Neukum
2004-04-30 9:04 ` Duncan Sands
2004-05-01 23:01 ` Greg KH
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=200404181136.32308.baldrick@free.fr \
--to=baldrick@free.fr \
--cc=fd@cisco.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=oliver@neukum.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox