858  * Allocate a new open/delegation state counter. This is needed for
1082  * When we recall a delegation, we should be careful not to hand it
1086  * If a filehandle appear in either filter, a delegation is blocked.
1087  * When a delegation is recalled, the filehandle is stored in the "new"
1177 	 * delegation seqid's are never incremented.  The 4.1 special  in alloc_init_deleg()
1269  * nfs4_delegation_exists - Discover if this delegation already exists
1270  * @clp:     a pointer to the nfs4_client we're granting a delegation to
1271  * @fp:      a pointer to the nfs4_file we're granting a delegation on
1274  *      On success: true iff an existing delegation is found
1296  * hash_delegation_locked - Add a delegation to the appropriate lists
1298  * @fp:     a pointer to the nfs4_file we're granting a delegation on
1301  *      On success: NULL if the delegation was successfully hashed.
1304  *                 nfs4_client for this nfs4_file. Delegation is not hashed.
4828  *   %true: delegation was returned
4885 		 * granting delegation.  in nfsd4_cb_recall_done()
4943 	 * we'll remove it ourself if a delegation isn't returned  in nfsd_break_deleg_cb()
5410  * It's possible that between opening the dentry and setting the delegation,
5440  * may not notice and continue using the old mode. Avoid giving out a delegation
5476 	 * Try for a write delegation first. RFC8881 section 10.4 says:  in nfs4_set_delegation()
5478 	 *  "An OPEN_DELEGATE_WRITE delegation allows the client to handle,  in nfs4_set_delegation()
5481 	 * Furthermore the client can use a write delegation for most READ  in nfs4_set_delegation()
5484 	 * Offer a write delegation in the case of a BOTH open, and ensure  in nfs4_set_delegation()
5494 	 * file for some reason, then try for a read delegation instead.  in nfs4_set_delegation()
5609  * begins each COMPOUND contains a client ID. Delegation recall can
5611  * GETATTR also holds write delegation it conflicts with.
5615  * conflicting delegation versus coming from some other client. Per
5618  * holds the conflicting delegation.
5624  * eventually revokes the delegation, which can result in loss of
5684 		dprintk("NFSD: WARNING: refusing delegation reclaim\n");  in nfs4_open_delegation()
5688 	/* 4.1 client asking for a delegation? */  in nfs4_open_delegation()
5706 	/* Otherwise the client must be confused wanting a delegation  in nfsd4_deleg_xgrade_none_ext()
5801 	* Attempt to hand out a delegation. No error return, because the  in nfsd4_process_open2()
5809 	/* 4.1 client trying to upgrade/downgrade delegation? */  in nfsd4_process_open2()
8109  * Since the lifetime of a delegation isn't limited to that of an open, a
8110  * client may quite reasonably hang on to a delegation as long as it has
8122 	 * estimates suggest that in the worst case (where every delegation  in set_max_delegations()
8123 	 * is for a different inode), a delegation could take about 1.5K,  in set_max_delegations()
8436  * delegation and a change/size GETATTR from another client. The server
8438  * attributes from the client that holds the delegation or recall the
8439  * delegation before replying to the GETATTR. See RFC 8881 section
8443  * this can avoid recalling the delegation could be added in follow up
8467 			 * we are done; there isn't any write delegation  in nfsd4_deleg_getattr_conflict()