> Using the BKL in llseek() does not protect the inode's i_size from > modification since the i_size is protected by a seqlock nowadays. Since > default_llseek() is already using the i_size_read() wrapper it is not the > BKL which is serializing the access here. > The access to file->f_pos is not protected by the BKL either since its > access in vfs_write()/vfs_read() is not protected by any lock. If the BKL > is not protecting anything here it can clearly get removed. No. Your logic is flawed The BKL is protected something here - it protects the change of offset with respect to other BKL users within drivers. The question is what if anything in any other driver code depends upon the BKL and uses it to protect f_pos. Probably very little if anything but a grep for f_pos through the drivers might not be a bad idea before assuming this. Very few touch f_pos except in their own llseek method. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
