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

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

On Tue, May 25, 2010 at 02:32:23PM -0400, J. Bruce Fields wrote:
> 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....

Is anyone willing to work on this?

--b.