Re: [PATCH -v3] vfs: add releasepages hooks to block devices which can be used by file systems

[Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com>]

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