Date: Thu, 13 Jul 2000 01:09:02 -0400 (EDT) From: Alexander Viro <viro@math.psu.edu> To: linux-kernel@vger.rutgers.edu Subject: [Announce] BKL shifting into drivers and filesystems - beware 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/