Lines Matching full:delegation

842  * Allocate a new open/delegation state counter. This is needed for
1063 * When we recall a delegation, we should be careful not to hand it
1067 * If a filehandle appear in either filter, a delegation is blocked.
1068 * When a delegation is recalled, the filehandle is stored in the "new"
1159 * delegation seqid's are never incremented. The 4.1 special in alloc_init_deleg()
1251 * nfs4_delegation_exists - Discover if this delegation already exists
1252 * @clp: a pointer to the nfs4_client we're granting a delegation to
1253 * @fp: a pointer to the nfs4_file we're granting a delegation on
1256 * On success: true iff an existing delegation is found
1278 * hash_delegation_locked - Add a delegation to the appropriate lists
1280 * @fp: a pointer to the nfs4_file we're granting a delegation on
1283 * On success: NULL if the delegation was successfully hashed.
1286 * nfs4_client for this nfs4_file. Delegation is not hashed.
1352 * revoke_delegation - perform nfs4 delegation structure cleanup
1353 * @dp: pointer to the delegation
1356 * interface (nfsd4_revoke_states()) that's revoking a specific delegation
1370 * for removing it from the list. Inspection of where the delegation state
1732 * All nfs4 states (open, lock, delegation, layout) held by the server instance
5332 * %true: delegation was returned
5389 * granting delegation. in nfsd4_cb_recall_done()
5456 * we'll remove it ourself if a delegation isn't returned in nfsd_break_deleg_cb()
5915 * It's possible that between opening the dentry and setting the delegation,
5945 * may not notice and continue using the old mode. Avoid giving out a delegation
5994 * Try for a write delegation first. RFC8881 section 10.4 says: in nfs4_set_delegation()
5996 * "An OPEN_DELEGATE_WRITE delegation allows the client to handle, in nfs4_set_delegation()
5999 * Furthermore the client can use a write delegation for most READ in nfs4_set_delegation()
6002 * Offer a write delegation in the case of a BOTH open, and ensure in nfs4_set_delegation()
6012 * file for some reason, then try for a read delegation instead. in nfs4_set_delegation()
6161 * begins each COMPOUND contains a client ID. Delegation recall can
6163 * GETATTR also holds write delegation it conflicts with.
6167 * conflicting delegation versus coming from some other client. Per
6170 * holds the conflicting delegation.
6176 * eventually revokes the delegation, which can result in loss of
6247 dprintk("NFSD: WARNING: refusing delegation reclaim\n"); in nfs4_open_delegation()
6251 /* 4.1 client asking for a delegation? */ in nfs4_open_delegation()
6269 /* Otherwise the client must be confused wanting a delegation in nfsd4_deleg_xgrade_none_ext()
6275 /* Are we returning only a delegation stateid? */
6280 /* Did we actually get a delegation? */ in open_xor_delegation()
6379 * Attempt to hand out a delegation. No error return, because the in nfsd4_process_open2()
6398 /* 4.1 client trying to upgrade/downgrade delegation? */ in nfsd4_process_open2()
8755 * Since the lifetime of a delegation isn't limited to that of an open, a
8756 * client may quite reasonably hang on to a delegation as long as it has
8768 * estimates suggest that in the worst case (where every delegation in set_max_delegations()
8769 * is for a different inode), a delegation could take about 1.5K, in set_max_delegations()
9155 * @pdp: returned WRITE delegation, if one was found
9158 * delegation and a change/size GETATTR from another client. The server
9160 * attributes from the client that holds the delegation or recall the
9161 * delegation before replying to the GETATTR. See RFC 8881 section
9220 /* Recall delegation only if client didn't respond */ in nfsd4_deleg_getattr_conflict()