21 Jun, 2008
40 commits
-
A number of driver functions are so obviously trivial that they do not need
the big kernel lock - at least not overtly. It turns out that the
acquisition of the BKL in driver open() functions can perform a sort of
poor-hacker's serialization function, delaying the open operation until the
driver is certain to have completed its initialization. Add a simple
cycle_kernel_lock() function for these cases to make it clear that there is
no need to *hold* the BKL, just to be sure that we can acquire it.Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel() calls into videodev_open(). That function
itself seems OK, but one never knows about all the open() functions
provided by underlying video drivers.Signed-off-by: Jonathan Corbet
-
Add explicit lock_kernel() calls to usbdev_open()
Signed-off-by: Jonathan Corbet
-
Add explicit lock_kernel() calls to mon_bin_open()
Signed-off-by: Jonathan Corbet
-
Add explicit lock_kernel() calls to printer_open()
Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel() calls in adb_open(). The fact that
adb_release() already has them suggests this is necessary.Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel() calls into maint_open().
Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel() calls into capi_open()
Signed-off-by: Jonathan Corbet
-
Add lock_kernel() calls to ch_open(), though the existing locking looks
adequate.Signed-off-by: Jonathan Corbet
-
Add lock_kernel() calls to adpt_open()
Signed-off-by: Jonathan Corbet
-
Add explicit lock_kernel() calls to vfc_open().
Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel() calls into bpp_open(). It has locking, but I'm
not convinced it won't race with ioctl().Signed-off-by: Jonathan Corbet
-
Add explicit lock_kernel calls to phantom_open().
Signed-off-by: Jonathan Corbet
-
Be extra-cautious and protect the remaining open() functions.
Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel calls into dsp56k_open().
[Stupid missing label error fixed]
Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel() calls into raw_open(), even though the existing
locking looks adequate.Signed-off-by: Jonathan Corbet
-
Put explicit lock_kernel calls into tlclk_open()
Signed-off-by: Jonathan Corbet
-
Add explicit lock_kernel() calls to hwicap_open() even though the existing
locking looks adequate.Signed-off-by: Jonathan Corbet
-
Add explicit BKL to vcs_open().
Signed-off-by: Jonathan Corbet
-
Add the BKL to spidev_open(), even though the existing locking looks
adequate.Signed-off-by: Jonathan Corbet
-
This documents the fact that somebody looked at the relevant open()
functions and concluded that, due to their trivial nature, no locking was
needed.Signed-off-by: Jonathan Corbet
-
Parts of the serial code actually BUG() if we don't do this.
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
usb_open() is protected by a down_read(&minor_rwsem), but I'm not sure I
trust it to protect everything including subsidiary open() functions.Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
->release() already has explicit lock_kernel() calls...
Signed-off-by: Jonathan Corbet
-
phone_open() looks OK, but I don't trust the subsidiary drivers (and ixj in
particular).Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
This driver would appear to have no internal locking at all.
Signed-off-by: Jonathan Corbet
-
Signed-off-by: Jonathan Corbet
-
misc_open() looks fine, but who knows what all of the misc drivers are
doing in their open() functions?Signed-off-by: Jonathan Corbet
