Remove explicit lock_kernel() calls and document why the code is safe.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Remove explicit lock_kernel() calls and document why the code is safe.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

According to Mike Frysinger:

	http://permalink.gmane.org/gmane.linux.kernel/699279

open() does not need the BKL, so take it back out.

lock_kernel() calls have been pushed down into code which needs it, so
there is no need to take the BKL at this level anymore.

This work inspired and aided by Andi Kleen's unlocked_fasync() patches.
Acked-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Chances are this is unneeded, but the code is twisty enough that it is hard
to tell.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This driver really needs it to avoid races against open()
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This driver appears to really need the BKL to protect open_files.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

It looks like this driver really needs the BKL here.
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

- Replace remote_llseek with generic_file_llseek_unlocked (to force compilation
failures in all users)
- Change all users to either use generic_file_llseek_unlocked directly or
take the BKL around. I changed the file systems who don't use the BKL
for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS
take the BKL, but explicitely in their own source now.

I moved them all over in a single patch to avoid unbisectable sections.

Open problem: 32bit kernels can corrupt fpos because its modification
is not atomic, but they can do that anyways because there's other paths who
modify it without BKL.

Do we need a special lock for the pos/f_version = 0 checks?

Trond says the NFS BKL is likely not needed, but keep it for now
until his full audit.

v2: Use generic_file_llseek_unlocked instead of remote_llseek_unlocked
    and factor duplicated code (suggested by hch)

Cc: Trond.Myklebust@netapp.com
Cc: swhiteho@redhat.com
Cc: sfrench@samba.org
Cc: vandrove@vc.cvut.cz
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The FAT BKL removal patch can cause deadlocks.  It turns out that the new
lock_super() calls are unneeded, remove them (as directed by Linus).
Reported-by: N"Tony Luck" <tony.luck@intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

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>

[jmc: added <linux/smp_lock.h>]
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

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>