On Tue, 2010-05-25 at 12:42 -0400, J. Bruce Fields wrote: > From: J. Bruce Fields <bfields@xxxxxxxxxxxxxx> > > Section 18.36.3 of rfc 5661 says that "For the fore channel, the server > MAY change the requested value." > > Also, there's no reason why the client would have to care if the server > is willing to accept *more* operations per compound than the client > requested. > > Signed-off-by: J. Bruce Fields <bfields@xxxxxxxxxxxxxx> > --- > fs/nfs/nfs4proc.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > On the other hand, if the server *decreases* max_ops on the forechannel, > the client may need to do something. (Probably just fail for now.) Why > aren't we checking for that case? > > --b. > > diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c > index 071fced..a5a3690 100644 > --- a/fs/nfs/nfs4proc.c > +++ b/fs/nfs/nfs4proc.c > @@ -4880,7 +4880,6 @@ static int nfs4_verify_channel_attrs(struct nfs41_create_session_args *args, > > ret |= _verify_fore_channel_attr(headerpadsz); > ret |= _verify_fore_channel_attr(max_resp_sz); > - ret |= _verify_fore_channel_attr(max_ops); > > ret |= _verify_back_channel_attr(headerpadsz); > ret |= _verify_back_channel_attr(max_rqst_sz); Yes. That all looks wrong. Can we please just get rid of that senseless macro, and open code those checks instead of the above patch? The current code is just pure obfuscation... Trond -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
