zero layout stateid on last layout segment removal

This is a piece of the "pnfs-submit Re-initialize pnfs_layout_type when segs list is emtpy" patch set that I think is not being argued about.

More initialization needs to occur when the layout->segs list is empty.

This patch fixes the bug where a layoutreturn would empty the nfs_inode->layout segs list, and a future layoutget would use a (now-stale) stateid instead of creating a new layout stateid from an existing open/lock/deleg stateid.

layoutget decides to get a new stateid when the nfs_layout->layout->stateid is zeroed.

Testing;

CONFIG_NFS_V4_1 set:
Passes Connectathon (pnfs mount).
Behaves correctly in pyNFS file layout server tests where return-on-close is set - every layoutget uses a new stateid.

CONFIG_NFS_V4_1 not set:
NFsv4.0 passses connectathon

-->Andy

From: Andy Adamson <[email protected]>

Section 12.5.3 RFC 5661

"Once a client has no more layouts on a file, the layout stateid is no longer valid and MUST NOT be used. Any attempt to use such a layout stateid will result in NFS4ERR_BAD_STATEID."

---
 fs/nfs/pnfs.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

index 8b26104..3018ed6 100644
@@ -625,6 +625,7 @@ pnfs_free_layout(struct pnfs_layout_type *lo,
 		spin_lock(&clp->cl_lock);
 		list_del_init(&lo->lo_layouts);
 		spin_unlock(&clp->cl_lock);
+		pnfs_set_layout_stateid(lo, &zero_stateid);
 	}
 
 	dprintk("%s:Return\n", __func__);

1.6.6