All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Adamson <andros@netapp.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/1] NFSv4.1: handle decoding of three attribute bitmaps
Date: Mon, 11 Jul 2011 14:30:14 -0400	[thread overview]
Message-ID: <C42C21AC-EABC-48F2-85DE-79EF1EEEA13B@netapp.com> (raw)
In-Reply-To: <1310407708.12660.2.camel@lade.trondhjem.org>


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.

-->Andy

> 
> Cheers
>  Trond
> -- 
> Trond Myklebust
> Linux NFS client maintainer
> 
> NetApp
> Trond.Myklebust@netapp.com
> www.netapp.com
> 


  reply	other threads:[~2011-07-11 18:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11 17:54 [PATCH 1/1] NFSv4.1: handle decoding of three attribute bitmaps andros
2011-07-11 18:08 ` Trond Myklebust
2011-07-11 18:30   ` Andy Adamson [this message]
2011-07-11 18:49     ` Trond Myklebust
2011-07-11 20:59       ` Andy Adamson

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=C42C21AC-EABC-48F2-85DE-79EF1EEEA13B@netapp.com \
    --to=andros@netapp.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=linux-nfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.