From: Benny Halevy <bhalevy@panasas.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-nfs@vger.kernel.org, nfsv4@linux-nfs.org
Subject: Re: [PATCH 0/2 v4] nfs: return nfs4 compound header status on op header decoding error
Date: Wed, 16 Jul 2008 11:21:03 +0300 [thread overview]
Message-ID: <487DAF6F.10404@panasas.com> (raw)
In-Reply-To: <1216159035.7981.70.camel@localhost>
On Jul. 16, 2008, 0:57 +0300, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> On Thu, 2008-07-03 at 20:49 +0300, Benny Halevy wrote:
>> Trond, following our conversation during the Connectathon
>> I reduced this patch as much as possible and restricted the
>> use of the compound header status to cases where op_hdr
>> decoding hit an error.
>>
>> This is needed for nfs41 for graceful fallback when trying
>> to mount a 4.0 server with 4.1. In this case the server
>> returns no ops and the hdr status is set to
>> NFS4ERR_MINOR_VERS_MISMATCH.
>>
>> Please consider these patches:
>>
>> [PATCH 1/2] nfs: return nfs4 compound header status on op header decoding error
>
> No, this patch doesn't look right either. If we overrun the end of the
> reply buffer, then xdr_inline_decode() will return a NULL pointer, so
> you should never hit the your (opnum != expected) case.
In patch 1, this is supposed to be handled like this:
decode_compound_hdr:
+ xdr->status = hdr->status;
decode_op_hdr:
+ p = xdr_inline_decode(xdr, 8);
+ if (unlikely(!p)) {
...
+ goto err;
+ }
+err:
+ if (xdr->status != NFS_OK)
+ return nfs4_stat_to_errno(xdr->status);
>
> So given that your concern is primarily the case where nops==0, why
> don't you just add that particular case to decode_compound_hdr?
>
> IOW: something like
>
>
> @@static int decode_compound_hdr(
> p += XDR_QUADLEN(hdr->taglen);
> READ32(hdr->nops);
> + if (hdr->nops < 1)
> + return nfs4_stat_to_errno(hdr->status);
> return 0;
> }
>
This certainly provides a shortcut for the nops==0 case.
However, it doesn't solve the OP_ILLEGAL case all other
cases where xdr_inline_decode failed or opnum != expected,
we can easily handle the OP_ILLEGAL case explicitly in
decode_op_hdr. Are you ok with the approach of
carrying the hdr.status in xdr->status for decode_op_hdr
use, or do you rather prefer to leave things as they are
for the invalid cases and explicitly handle only the
nops==0 and OP_ILLEGAL cases?
Benny
next prev parent reply other threads:[~2008-07-16 8:21 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 14:35 [PATCH 0/2] nfsv4 compound status Benny Halevy
2008-03-31 14:39 ` [PATCH 1/2] nfs: return negative error value from nfs{,4}_stat_to_errno Benny Halevy
2008-03-31 14:48 ` [PATCH 2/2] nfs: use compound hdr.status to override op status Benny Halevy
2008-03-31 22:25 ` Trond Myklebust
[not found] ` <1207002349.15341.15.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org>
2008-04-01 9:37 ` Benny Halevy
2008-04-01 9:41 ` [PATCH 2/2 v1] " Benny Halevy
2008-05-09 22:21 ` [PATCH 1/1 v2] " Benny Halevy
2008-05-09 23:32 ` Benny Halevy
2008-05-10 6:11 ` Benny Halevy
2008-05-09 23:38 ` [PATCH " Benny Halevy
2008-05-10 17:24 ` Trond Myklebust
2008-05-11 23:21 ` [PATCH v3] " Benny Halevy
2008-05-11 23:26 ` Trond Myklebust
2008-05-12 1:54 ` Benny Halevy
2008-07-03 17:49 ` [PATCH 0/2 v4] nfs: return nfs4 compound header status on op header decoding error Benny Halevy
2008-07-03 17:52 ` [PATCH 1/2] " Benny Halevy
2008-07-03 18:42 ` [PATCH 2/2] nfs: remove incorrect usage of nfs4 compound response hdr.status Benny Halevy
2008-07-15 21:57 ` [PATCH 0/2 v4] nfs: return nfs4 compound header status on op header decoding error Trond Myklebust
2008-07-16 8:21 ` Benny Halevy [this message]
2008-07-16 12:57 ` Trond Myklebust
2008-07-16 13:22 ` Benny Halevy
2008-07-17 12:09 ` Trond Myklebust
2008-07-17 13:20 ` Benny Halevy
2008-07-21 16:59 ` [PATCH] nfs: return compound hdr.status when there are no op replies Benny Halevy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=487DAF6F.10404@panasas.com \
--to=bhalevy@panasas.com \
--cc=linux-nfs@vger.kernel.org \
--cc=nfsv4@linux-nfs.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox