Re: [PATCH 1/1] NFSv4.1: handle decoding of three attribute bitmaps

[Trond Myklebust <Trond.Myklebust@netapp.com>]

On Mon, 2011-07-11 at 14:30 -0400, Andy Adamson wrote: 
> On Jul 11, 2011, at 2:08 PM, Trond Myklebust wrote:
> 
> > On Mon, 2011-07-11 at 13:54 -0400, andros@netapp.com wrote: 
> >> From: Andy Adamson <andros@netapp.com>
> >> 
> >> Attribute IDs assigned in RFC 5661 now require three bitmaps.
> >> 
> >> Signed-off-by: Andy Adamson <andros@netapp.com>
> >> Cc:stable@kernel.org [2.6.39]
> > 
> > Is this really so urgent?
> > 
> > [trondmy@lade linux-2.6]$ git grep FATTR4_WORD2 fs/nfs include/linux
> > include/linux/nfs4.h:#define FATTR4_WORD2_SUPPATTR_EXCLCREAT (1UL << 11)
> > include/linux/nfs4.h:#define FATTR4_WORD2_LAYOUT_BLKSIZE     (1UL << 1)
> > 
> > IOW: we don't appear to be using any of those bits, and so the current
> > default behaviour of just ignoring any bitmap values that we don't
> > recognise would seem to be sufficient.
> 
> I should have given more context :)
> 
> In testing nfs4_getfacl,  OnTap returns three attribute bits which triggered a BUG_ON in xdr_shrink_bufhead
> as the third bitmap was incorrectly interpreted as the length.
> 
> Plus, RFC 5661 defines suppattr_exclcreat bit 75 as a mandatory attribute which means it can/will be returned with any supported attributes query.
> 
> So, I think this needed and is a candidate for stable.

You missed my point. The only part that should make any difference in
your patch is the bit which changes the declaration of
nfs4_fattr_bitmap_maxsz.

The rest shouldn't be needed because the bits in the WORD2 range should
all be zero: our client doesn't ever request any of those attributes.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com