summaryrefslogtreecommitdiffstats
path: root/fs/nfsd/nfs4proc.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* nfsd: fix rare symlink decoding bugJ. Bruce Fields2014-06-271-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An NFS operation that creates a new symlink includes the symlink data, which is xdr-encoded as a length followed by the data plus 0 to 3 bytes of zero-padding as required to reach a 4-byte boundary. The vfs, on the other hand, wants null-terminated data. The simple way to handle this would be by copying the data into a newly allocated buffer with space for the final null. The current nfsd_symlink code tries to be more clever by skipping that step in the (likely) case where the byte following the string is already 0. But that assumes that the byte following the string is ours to look at. In fact, it might be the first byte of a page that we can't read, or of some object that another task might modify. Worse, the NFSv4 code tries to fix the problem by actually writing to that byte. In the NFSv2/v3 cases this actually appears to be safe: - nfs3svc_decode_symlinkargs explicitly null-terminates the data (after first checking its length and copying it to a new page). - NFSv2 limits symlinks to 1k. The buffer holding the rpc request is always at least a page, and the link data (and previous fields) have maximum lengths that prevent the request from reaching the end of a page. In the NFSv4 case the CREATE op is potentially just one part of a long compound so can end up on the end of a page if you're unlucky. The minimal fix here is to copy and null-terminate in the NFSv4 case. The nfsd_symlink() interface here seems too fragile, though. It should really either do the copy itself every time or just require a null-terminated string. Reported-by: Jeff Layton <jlayton@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: simplify server xdr->next_page useJ. Bruce Fields2014-06-071-1/+1
| | | | | | | | | | | | | | | | | | | | The rpc code makes available to the NFS server an array of pages to encod into. The server represents its reply as an xdr buf, with the head pointing into the first page in that array, the pages ** array starting just after that, and the tail (if any) sharing any leftover space in the page used by the head. While encoding, we use xdr_stream->page_ptr to keep track of which page we're currently using. Currently we set xdr_stream->page_ptr to buf->pages, which makes the head a weird exception to the rule that page_ptr always points to the page we're currently encoding into. So, instead set it to buf->pages - 1 (the page actually containing the head), and remove the need for a little unintuitive logic in xdr_get_next_encode_buffer() and xdr_truncate_encode. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd: remove unneeded zeroing of fields in nfsd4_proc_compoundJeff Layton2014-06-041-3/+0
| | | | | | | | The memset of resp in svc_process_common should ensure that these are already zeroed by the time they get here. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd: fix setting of NFS4_OO_CONFIRMED in nfsd4_openJeff Layton2014-06-041-2/+1
| | | | | | | | | | | | | | In the NFS4_OPEN_CLAIM_PREVIOUS case, we should only mark it confirmed if the nfs4_check_open_reclaim check succeeds. In the NFS4_OPEN_CLAIM_DELEG_PREV_FH and NFS4_OPEN_CLAIM_DELEGATE_PREV cases, I see no point in declaring the openowner confirmed when the operation is going to fail anyway, and doing so might allow the client to game things such that it wouldn't need to confirm a subsequent open with the same owner. Signed-off-by: Jeff Layton <jlayton@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: better reservation of head space for krb5J. Bruce Fields2014-05-301-2/+2
| | | | | | | | | RPC_MAX_AUTH_SIZE is scattered around several places. Better to set it once in the auth code, where this kind of estimate should be made. And while we're at it we can leave it zero when we're not using krb5i or krb5p. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: estimate sequence response sizeJ. Bruce Fields2014-05-301-0/+6
| | | | | | Otherwise a following patch would turn off all 4.1 zero-copy reads. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: better estimate of getattr response sizeJ. Bruce Fields2014-05-301-0/+44
| | | | | | | | | | We plan to use this estimate to decide whether or not to allow zero-copy reads. Currently we're assuming all getattr's are a page, which can be both too small (ACLs e.g. may be arbitrarily long) and too large (after an upcoming read patch this will unnecessarily prevent zero copy reads in any read compound also containing a getattr). Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: allow large readdirsJ. Bruce Fields2014-05-301-4/+5
| | | | | | | | Currently we limit readdir results to a single page. This can result in a performance regression compared to NFSv3 when reading large directories. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: more precise nfsd4_max_replyJ. Bruce Fields2014-05-301-0/+12
| | | | | | | | | | | It will turn out to be useful to have a more accurate estimate of reply size; so, piggyback on the existing op reply-size estimators. Also move nfsd4_max_reply to nfs4proc.c to get easier access to struct nfsd4_operation and friends. (Thanks to Christoph Hellwig for pointing out that simplification.) Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: don't try to encode conflicting owner if low on spaceJ. Bruce Fields2014-05-301-1/+2
| | | | | | | | | | | | | I ran into this corner case in testing: in theory clients can provide state owners up to 1024 bytes long. In the sessions case there might be a risk of this pushing us over the DRC slot size. The conflicting owner isn't really that important, so let's humor a client that provides a small maxresponsize_cached by allowing ourselves to return without the conflicting owner instead of outright failing the operation. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: allow encoding across page boundariesJ. Bruce Fields2014-05-301-0/+4
| | | | | | | | | | | After this we can handle for example getattr of very large ACLs. Read, readdir, readlink are still special cases with their own limits. Also we can't handle a new operation starting close to the end of a page. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: size-checking cleanupJ. Bruce Fields2014-05-301-3/+6
| | | | | | Better variable name, some comments, etc. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: remove redundant encode buffer size checkingJ. Bruce Fields2014-05-301-14/+0
| | | | | | | | | Now that all op encoders can handle running out of space, we no longer need to check the remaining size for every operation; only nonidempotent operations need that check, and that can be done by nfsd4_check_resp_size. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: teach encoders to handle reserve_space failuresJ. Bruce Fields2014-05-301-1/+1
| | | | | | | | | | | | | | | | | | | We've tried to prevent running out of space with COMPOUND_SLACK_SPACE and special checking in those operations (getattr) whose result can vary enormously. However: - COMPOUND_SLACK_SPACE may be difficult to maintain as we add more protocol. - BUG_ON or page faulting on failure seems overly fragile. - Especially in the 4.1 case, we prefer not to fail compounds just because the returned result came *close* to session limits. (Though perfect enforcement here may be difficult.) - I'd prefer encoding to be uniform for all encoders instead of having special exceptions for encoders containing, for example, attributes. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: keep xdr buf length updatedJ. Bruce Fields2014-05-281-0/+2
| | | | Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: use xdr_stream throughout compound encodingJ. Bruce Fields2014-05-281-1/+1
| | | | | | | Note this makes ADJUST_ARGS useless; we'll remove it in the following patch. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: use xdr_reserve_space in attribute encodingJ. Bruce Fields2014-05-281-0/+1
| | | | | | | | | | | | | | | | | | | This is a cosmetic change for now; no change in behavior. Note we're just depending on xdr_reserve_space to do the bounds checking for us, we're not really depending on its adjustment of iovec or xdr_buf lengths yet, as those are fixed up by as necessary after the fact by read-link operations and by nfs4svc_encode_compoundres. However we do have to update xdr->iov on read-like operations to prevent xdr_reserve_space from messing with the already-fixed-up length of the the head. When the attribute encoding fails partway through we have to undo the length adjustments made so far. We do it manually for now, but later patches will add an xdr_truncate_encode() helper to handle cases like this. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: fix encoding of out-of-space repliesJ. Bruce Fields2014-05-271-4/+9
| | | | | | | | | | | If nfsd4_check_resp_size() returns an error then we should really be truncating the reply here, otherwise we may leave extra garbage at the end of the rpc reply. Also add a warning to catch any cases where our reply-size estimates may be wrong in the case of a non-idempotent operation. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: reserve head space for krb5 integ/priv infoJ. Bruce Fields2014-05-231-1/+1
| | | | | | | | | | | | | | | Currently if the nfs-level part of a reply would be too large, we'll return an error to the client. But if the nfs-level part fits and leaves no room for krb5p or krb5i stuff, then we just drop the request entirely. That's no good. Instead, reserve some slack space at the end of the buffer and make sure we fail outright if we'd come close. The slack space here is a massive overstimate of what's required, we should probably try for a tighter limit at some point. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: move proc_compound xdr encode init to helperJ. Bruce Fields2014-05-231-4/+13
| | | | | | | Mechanical transformation with no change of behavior. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: tweak nfsd4_encode_getattr to take xdr_streamJ. Bruce Fields2014-05-231-3/+3
| | | | | | | | Just change the nfsd4_encode_getattr api. Not changing any code or adding any new functionality yet. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: embed xdr_stream in nfsd4_compoundresJ. Bruce Fields2014-05-231-6/+6
| | | | | | | This is a mechanical transformation with no change in behavior. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: decoding errors can still be cached and require spaceJ. Bruce Fields2014-05-231-0/+2
| | | | | | | | | | | | | | Currently a non-idempotent op reply may be cached if it fails in the proc code but not if it fails at xdr decoding. I doubt there are any xdr-decoding-time errors that would make this a problem in practice, so this probably isn't a serious bug. The space estimates should also take into account space required for encoding of error returns. Again, not a practical problem, though it would become one after future patches which will tighten the space estimates. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: fix write reply size estimateJ. Bruce Fields2014-05-231-1/+1
| | | | | | The write reply also includes count and stable_how. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: read size estimate should include paddingJ. Bruce Fields2014-05-231-1/+1
| | | | Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: READ, READDIR, etc., are idempotentJ. Bruce Fields2014-05-231-8/+3
| | | | | | | | | | | | OP_MODIFIES_SOMETHING flags operations that we should be careful not to initiate without being sure we have the buffer space to encode a reply. None of these ops fall into that category. We could probably remove a few more, but this isn't a very important problem at least for ops whose reply size is easy to estimate. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* NFSd: Clean up nfs4_preprocess_stateid_opTrond Myklebust2014-05-071-11/+0
| | | | | | | | Move the state locking and file descriptor reference out from the callers and into nfs4_preprocess_stateid_op() itself. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* NFSD: Clear wcc data between compound opsKinglong Mee2014-03-301-0/+2
| | | | | | | | | | | | | | | | | | Testing NFS4.0 by pynfs, I got some messeages as, "nfsd: inode locked twice during operation." When one compound RPC contains two or more ops that locks the filehandle,the second op will cause the message. As two SETATTR ops, after the first SETATTR, nfsd will not call fh_put() to release current filehandle, it means filehandle have unlocked with fh_post_saved = 1. The second SETATTR find fh_post_saved = 1, and printk the message. v2: introduce helper fh_clear_wcc(). Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: fix setclientid encode sizeJ. Bruce Fields2014-03-291-1/+2
| | | | | Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* NFSD: simplify saved/current fh uses in nfsd4_proc_compoundKinglong Mee2014-03-281-13/+15
| | | | | Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: session needs room for following op to error outJ. Bruce Fields2014-03-271-0/+6
| | | | | Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* Merge branch 'for-3.14' of git://linux-nfs.org/~bfields/linuxLinus Torvalds2014-01-301-23/+34
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull nfsd updates from Bruce Fields: - Handle some loose ends from the vfs read delegation support. (For example nfsd can stop breaking leases on its own in a fewer places where it can now depend on the vfs to.) - Make life a little easier for NFSv4-only configurations (thanks to Kinglong Mee). - Fix some gss-proxy problems (thanks Jeff Layton). - miscellaneous bug fixes and cleanup * 'for-3.14' of git://linux-nfs.org/~bfields/linux: (38 commits) nfsd: consider CLAIM_FH when handing out delegation nfsd4: fix delegation-unlink/rename race nfsd4: delay setting current_fh in open nfsd4: minor nfs4_setlease cleanup gss_krb5: use lcm from kernel lib nfsd4: decrease nfsd4_encode_fattr stack usage nfsd: fix encode_entryplus_baggage stack usage nfsd4: simplify xdr encoding of nfsv4 names nfsd4: encode_rdattr_error cleanup nfsd4: nfsd4_encode_fattr cleanup minor svcauth_gss.c cleanup nfsd4: better VERIFY comment nfsd4: break only delegations when appropriate NFSD: Fix a memory leak in nfsd4_create_session sunrpc: get rid of use_gssp_lock sunrpc: fix potential race between setting use_gss_proxy and the upcall rpc_clnt sunrpc: don't wait for write before allowing reads from use-gss-proxy file nfsd: get rid of unused function definition Define op_iattr for nfsd4_open instead using macro NFSD: fix compile warning without CONFIG_NFSD_V3 ...
| * nfsd4: fix delegation-unlink/rename raceJ. Bruce Fields2014-01-271-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a file is unlinked or renamed between the time when we do the local open and the time when we get the delegation, then we will return to the client indicating that it holds a delegation even though the file no longer exists under the name it was open under. But a client performing an open-by-name, when it is returned a delegation, must be able to assume that the file is still linked at the name it was opened under. So, hold the parent i_mutex for longer to prevent concurrent renames or unlinks. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
| * nfsd4: delay setting current_fh in openJ. Bruce Fields2014-01-271-17/+20
| | | | | | | | | | | | | | This is basically a no-op, to simplify a following patch. Acked-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
| * nfsd4: better VERIFY commentJ. Bruce Fields2014-01-071-2/+4
| | | | | | | | | | | | This confuses me every time. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
| * SUNRPC/NFSD: Support a new option for ignoring the result of svc_registerKinglong Mee2014-01-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NFSv4 clients can contact port 2049 directly instead of needing the portmapper. Therefore a failure to register to the portmapper when starting an NFSv4-only server isn't really a problem. But Gareth Williams reports that an attempt to start an NFSv4-only server without starting portmap fails: #rpc.nfsd -N 2 -N 3 rpc.nfsd: writing fd to kernel failed: errno 111 (Connection refused) rpc.nfsd: unable to set any sockets for nfsd Add a flag to svc_version to tell the rpc layer it can safely ignore an rpcbind failure in the NFSv4-only case. Reported-by: Gareth Williams <gareth@garethwilliams.me.uk> Reviewed-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
| * nfsd: calculate the missing length of bitmap in EXCHANGE_IDKinglong Mee2014-01-021-1/+2
| | | | | | | | | | | | | | | | | | commit 58cd57bfd9db3bc213bf9d6a10920f82095f0114 "nfsd: Fix SP4_MACH_CRED negotiation in EXCHANGE_ID" miss calculating the length of bitmap for spo_must_enforce and spo_must_allow. Signed-off-by: Kinglong Mee <kinglongmee@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* | nfsd: use get_acl and ->set_aclChristoph Hellwig2014-01-261-0/+1
|/ | | | | | | | | Remove the boilerplate code to marshall and unmarhall ACL objects into xattrs and operate on the posix_acl objects directly. Also move all the ACL handling code into nfs?acl.c where it belongs. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* nfsd: Fix SP4_MACH_CRED negotiation in EXCHANGE_IDWeston Andros Adamson2013-08-071-1/+1
| | | | | | | | - don't BUG_ON() when not SP4_NONE - calculate recv and send reserve sizes correctly Signed-off-by: Weston Andros Adamson <dros@netapp.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: fix minorversion support interfaceJ. Bruce Fields2013-07-121-1/+1
| | | | | | | | | | | | | | | | You can turn on or off support for minorversions using e.g. echo "-4.2" >/proc/fs/nfsd/versions However, the current implementation is a little wonky. For example, the above will turn off 4.2 support, but it will also turn *on* 4.1 support. This didn't matter as long as we only had 2 minorversions, which was true till very recently. And do a little cleanup here. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: delegation-based open reclaims should bypass permissionsJ. Bruce Fields2013-07-011-1/+2
| | | | | | | | | | | | | | | | | | We saw a v4.0 client's create fail as follows: - open create succeeds and gets a read delegation - client attempts to set mode on new file, gets DELAY while server recalls delegation. - client attempts a CLAIM_DELEGATE_CUR open using the delegation, gets error because of new file mode. This probably can't happen on a recent kernel since we're no longer giving out delegations on create opens. Nevertheless, it's a bug--reclaim opens should bypass permission checks. Reported-by: Steve Dickson <steved@redhat.com> Reported-by: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* NFSD: Server implementation of MAC LabelingDavid Quigley2013-05-151-0/+41
| | | | | | | | | | | | | Implement labeled NFS on the server: encoding and decoding, and writing and reading, of file labels. Enabled with CONFIG_NFSD_V4_SECURITY_LABEL. Signed-off-by: Matthew N. Dodd <Matthew.Dodd@sparta.com> Signed-off-by: Miguel Rodel Felipe <Rodel_FM@dsi.a-star.edu.sg> Signed-off-by: Phua Eu Gene <PHUA_Eu_Gene@dsi.a-star.edu.sg> Signed-off-by: Khin Mi Mi Aung <Mi_Mi_AUNG@dsi.a-star.edu.sg> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: don't allow owner override on 4.1 CLAIM_FH opensJ. Bruce Fields2013-05-031-2/+13
| | | | | | | | | | | | | | | | | | | | | | The Linux client is using CLAIM_FH to implement regular opens, not just recovery cases, so it depends on the server to check permissions correctly. Therefore the owner override, which may make sense in the delegation recovery case, isn't right in the CLAIM_FH case. Symptoms: on a client with 49f9a0fafd844c32f2abada047c0b9a5ba0d6255 "NFSv4.1: Enable open-by-filehandle", Bryan noticed this: touch test.txt chmod 000 test.txt echo test > test.txt succeeding. Cc: stable@kernel.org Reported-by: Bryan Schumaker <bjschuma@netapp.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: don't remap EISDIR errors in renameJ. Bruce Fields2013-04-301-15/+5
| | | | | | | | | | | | | | | | | | | | | | We're going out of our way here to remap an error to make rfc 3530 happy--but the rfc itself (nor rfc 1813, which has similar language) gives no justification. And disagrees with local filesystem behavior, with Linux and posix man pages, and knfsd's implemented behavior for v2 and v3. And the documented behavior seems better, in that it gives a little more information--you could implement the 3530 behavior using the posix behavior, but not the other way around. Also, the Linux client makes no attempt to remap this error in the v4 case, so it can end up just returning EEXIST to the application in a case where it should return EISDIR. So honestly I think the rfc's are just buggy here--or in any case it doesn't see worth the trouble to remap this error. Reported-by: Frank S Filz <ffilz@us.ibm.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: more sessions/open-owner-replay cleanupJ. Bruce Fields2013-04-091-12/+16
| | | | | | More logic that's unnecessary in the 4.1 case. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: no need for replay_owner in sessions caseJ. Bruce Fields2013-04-091-1/+1
| | | | | | The replay_owner will never be used in the sessions case. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: cleanup handling of nfsv4.0 closed stateid'sJ. Bruce Fields2013-04-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Closed stateid's are kept around a little while to handle close replays in the 4.0 case. So we stash them in the last-used stateid in the oo_last_closed_stateid field of the open owner. We can free that in encode_seqid_op_tail once the seqid on the open owner is next incremented. But we don't want to do that on the close itself; so we set NFS4_OO_PURGE_CLOSE flag set on the open owner, skip freeing it the first time through encode_seqid_op_tail, then when we see that flag set next time we free it. This is unnecessarily baroque. Instead, just move the logic that increments the seqid out of the xdr code and into the operation code itself. The justification given for the current placement is that we need to wait till the last minute to be sure we know whether the status is a sequence-id-mutating error or not, but examination of the code shows that can't actually happen. Reported-by: Yanchuan Nian <ycnian@gmail.com> Tested-by: Yanchuan Nian <ycnian@gmail.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd: don't run get_file if nfs4_preprocess_stateid_op return errorfanchaoting2013-04-031-4/+4
| | | | | | | | | we should return error status directly when nfs4_preprocess_stateid_op return error. Signed-off-by: fanchaoting <fanchaoting@cn.fujitsu.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: handle seqid-mutating open errors from xdr decodingJ. Bruce Fields2013-04-031-1/+26
| | | | | | | | | | If a client sets an owner (or group_owner or acl) attribute on open for create, and the mapping of that owner to an id fails, then we return BAD_OWNER. But BAD_OWNER is a seqid-mutating error, so we can't shortcut the open processing that case: we have to at least look up the owner so we can find the seqid to bump. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
* nfsd4: remove BUG_ONJ. Bruce Fields2013-04-031-6/+3
| | | | | | | This BUG_ON just crashes the thread a little earlier than it would otherwise--it doesn't seem useful. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-23 08:11:37 +0100