[Announce] BKL shifting into drivers and filesystems - beware

From: Alexander Viro (viro@math.psu.edu)
Date: Thu Jul 13 2000 - 00:09:02 EST


        OK, folks - current bunch of changes looks rather interesting from
the scalability point of view, but it means changes in 3rd-party code.
Doing it during the 2.4 is obviously not an option and postponing to
2.5 looks like an overkill since changes are massive but very simple.

        What had been changed recently:

* ->mmap() in file_operations, ->revalidate(), ->readlink() and
->follow_link() in inode_operations and all methods in dentry_operations
are called without the BKL. Take yourself if you need it.

* some instances of ->open() are called without BKL. In near future all of
them will. Again, if you need it - you get it.

* Documentation on locking warranties provided by VFS added. See
Documentation/filesystems/Locking. And watch the changes - this sucker is
supposed to be kept in sync with the kernel changes.

        What is going to happen:

* ->release() will be called without BKL. You need it - you take it.
I've added lock_kernel()/unlock_kernel() in all dubious instances of
->release(). In many cases removal will be trivial (switching a variable
or two from int to atomic_t, etc.), so when it will go into the tree -
check your drivers. Folks with 3rd-party code will have to add BKL
grabbing themselves - sorry, I'm not clairvoyant. Patch submitted to
Linus.

* Probably inode methods for directories are going to be called without
BKL. Again, I'll do the work for in-kernel filesystems, but 3rd-party ones
will have to be fixed by their maintainers.

* Probably ->fasync() is going to be called without BKL - in most cases
BKL is not be needed at all.

BTW, while you are at it - check your ->read() and ->write(). In many
drivers they do not look SMP-safe, AFAICS.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:16 EST