diff options
author | Stanislav Kinsbursky <skinsbursky@parallels.com> | 2012-02-27 22:05:54 +0400 |
---|---|---|
committer | Trond Myklebust <Trond.Myklebust@netapp.com> | 2012-02-27 13:37:48 -0500 |
commit | 591ad7feaec5417681b4112f8df52fc43bb7c92e (patch) | |
tree | 0555df9d98236f6a63ca109632a277c4458842e3 /fs/nfs/pnfs.c | |
parent | 2c9030eef9dbd0d737a7f55646da70d217fd6255 (diff) | |
download | linux-stable-591ad7feaec5417681b4112f8df52fc43bb7c92e.tar.gz linux-stable-591ad7feaec5417681b4112f8df52fc43bb7c92e.tar.bz2 linux-stable-591ad7feaec5417681b4112f8df52fc43bb7c92e.zip |
SUNRPC: move waitq from RPC pipe to RPC inode
Currently, wait queue, used for polling of RPC pipe changes from user-space,
is a part of RPC pipe. But the pipe data itself can be released on NFS umount
prior to dentry-inode pair, connected to it (is case of this pair is open by
some process).
This is not a problem for almost all pipe users, because all PipeFS file
operations checks pipe reference prior to using it.
Except evenfd. This thing registers itself with "poll" file operation and thus
has a reference to pipe wait queue. This leads to oopses on destroying eventfd
after NFS umount (like rpc_idmapd do) since not pipe data left to the point
already.
The solution is to wait queue from pipe data to internal RPC inode data. This
looks more logical, because this wiat queue used only for user-space processes,
which already holds inode reference.
Note: upcalls have to get pipe->dentry prior to dereferecing wait queue to make
sure, that mount point won't disappear from underneath us.
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Diffstat (limited to 'fs/nfs/pnfs.c')
0 files changed, 0 insertions, 0 deletions