nfs4: fix stateid handling for the NFS v4.2 operations
authorChristoph Hellwig <hch@lst.de>
Wed, 17 Feb 2016 14:48:28 +0000 (15:48 +0100)
committerTrond Myklebust <trond.myklebust@primarydata.com>
Wed, 17 Feb 2016 16:38:07 +0000 (11:38 -0500)
commit4bdf87ebda016b864b388f96ae349e76983ebac4
tree59fd9b5f6831f85e01c07565a09656e5d9623b8c
parentd9dfd8d741683347ee159d25f5b50c346a0df557
nfs4: fix stateid handling for the NFS v4.2 operations

The newly added NFS v4.2 operations (ALLOCATE, DEALLOCATE, SEEK and CLONE)
use a helper called nfs42_set_rw_stateid to select a stateid that is sent
to the server.  But they don't set the inode and state fields in the
nfs4_exception structure, and this don't partake in the stateid recovery
protocol.  Because of this they will simply return errors insted of trying
to recover a stateid when the server return a BAD_STATEID error.

Additionally CLONE has the problem that it operates on two files and thus
two stateids, and thus needs to call the exception handler twice to
recover stateids.

While we're at it stop grabbing an addititional reference to the open
context in all these operations - having the file open guarantees that
the open context won't go away.

All this can be produces with the generic/168 and generic/170 tests in
xfstests which stress the CLONE stateid handling.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
fs/nfs/nfs42proc.c