Re: [PATCH] nfs4: allow server to change forechannel max_ops

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, May 25, 2010 at 12:57:04PM -0400, Trond Myklebust wrote:
> On Tue, 2010-05-25 at 12:42 -0400, J. Bruce Fields wrote: 
> > From: J. Bruce Fields <bfields@citi.umich.edu>
> > 
> > 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@citi.umich.edu>
> > ---
> >  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...

Sounds good to me.  I'm hoping Andy can be roped into it....

--b.