Hello. Jan Kara wrote: > Hello, > <SNIP> > > Which of the following do you mean: > > 1) If using a spinlock in client_releasepage() is only for mount/umount, > > this implementation is not wise. > > 2) There is the fact that a spinlock is necessary for blkdev_releasepage(). > > This fact prevents us from making various implementations of > > client_releasepage(). > > (Without a spinlock, we can implement a client_releasepage() which can release > > the buffers with a sleep. As a result, it may enable more buffers release than > > before.) > > > > There is the fact that a filesystem can be mounted on several places, > > and the lock mechanism is absolutely necessary for this fact. > This is the thing I was wondering about. Why exactly is the spinlock > necessary for blkdev_releasepage()? I understand we have to protect > reading client_releasepage() pointer because it could change but my point > was that it changes only during mount / umount. There are 2 purposes of this lock. 1) The race between filesystem's mount and umount. (So that a filesystem can be mounted on several places concurrently.) ------------------------------------------------------------------ Without this lock, there is a possibility that the pointer of ei->client_releasepage becomes NULL by umount. As a result, a special releasepage for its filesystem is not used even if its filesystem has been mounted. ------------------------------------------------------------------ 2) The race between the usage of blkdev_releasepage() and umount. ------------------------------------------------------------------ Without this lock, there is a possibility that the pointer of ei->client_releasepage becomes NULL by umount. As a result, the process which calls blkdev_releasepage() may experience a page fault. Because blkdev_releasepage() refers the value ei->client_releasepage and then calls it as a function. But even if the pointer is not NULL, there is a possibility that a filesystem which has it has been unmounted. Besides, there is a possibility that the module of the filesystem has been unloaded. In this case, something wrong can happen. (Example: While a filesystem is being unmounted, one of its resources can be touched by using the ei->client_releasepage of the filesystem by the side of calling blkdev_releasepage.) ------------------------------------------------------------------ Therefore some lock mechanisms are necessary to solve the races. Regards, Toshiyuki Okajima -- 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
