Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NArnd Bergmann <arnd@arndb.de>

This replaces the use of the BKL in the FAT family of filesystems with the
existing superblock lock instead.

The code already appears to do mostly proper locking with its own private
spinlocks (and mutexes), but while the BKL could possibly have been
dropped entirely, converting it to use the superblock lock (which is just
a regular mutex) is the conservative thing to do.

As a per-filesystem mutex, it not only won't have any of the possible
latency issues related to the BKL, but the lock is obviously private to
the particular filesystem instance and will thus not cause problems for
entirely unrelated users like the BKL can.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Cc: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

All in-kernel char device open() functions now either have their own
lock_kernel() calls or clearly do not need one.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

I stared at this code for a while and almost deleted it before
understanding crept into my slow brain.  Hopefully this makes life easier
for the next person to happen on it.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

All of the open() functions which don't need the BKL on their face may
still depend on its acquisition to serialize opens against driver
initialization.  So make those functions acquire then release the BKL to be
on the safe side.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

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: NJonathan Corbet <corbet@lwn.net>

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: NJonathan Corbet <corbet@lwn.net>