Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: Kernel OPS when using xattr
Date:   Thu, 3 Dec 2020 18:25:20 +0000
From:   Frank van der Linden <fllinden@amazon.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
CC:     "tigran.mkrtchyan@desy.de" <tigran.mkrtchyan@desy.de>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Message-ID: <20201203182520.GA5535@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
References: <2137763922.1852883.1606983653611.JavaMail.zimbra@desy.de>
 <3e8c5334cca58c92e92d7ac2af95cf4e5141df08.camel@hammerspace.com>
 <305212825.2047189.1607011487661.JavaMail.zimbra@desy.de>
 <3b6276e9afe5e2dc2fa9c1f11b607bc031071554.camel@hammerspace.com>
 <20201203174757.GA2605@dev-dsk-fllinden-2c-c1893d73.us-west-2.amazon.com>
 <43574879eae405b934fa4c37a482b004adbb2aa9.camel@hammerspace.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <43574879eae405b934fa4c37a482b004adbb2aa9.camel@hammerspace.com>
User-Agent: Mutt/1.11.4 (2019-03-13)
Precedence: bulk

On Thu, Dec 03, 2020 at 06:23:24PM +0000, Trond Myklebust wrote:
> 
> 
> On Thu, 2020-12-03 at 17:47 +0000, Frank van der Linden wrote:
> > On Thu, Dec 03, 2020 at 05:13:26PM +0000, Trond Myklebust wrote:
> > [...]
> > > You probably need this one in addition to the first patch.
> > > 8<----------------------------------------------------
> > > From fec77469f373fbccb292c2d522f2ebee3b9011a8 Mon Sep 17 00:00:00
> > > 2001
> > > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > Date: Thu, 3 Dec 2020 12:04:51 -0500
> > > Subject: [PATCH] NFSv4.2: Fix up the get/listxattr calls to
> > >  rpc_prepare_reply_pages()
> > >
> > > Ensure that both getxattr and listxattr page array are correctly
> > > aligned, and that getxattr correctly accounts for the page padding
> > > word.
> > >
> > > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > > ---
> > >  fs/nfs/nfs42xdr.c | 12 +++++++-----
> > >  1 file changed, 7 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/nfs/nfs42xdr.c b/fs/nfs/nfs42xdr.c
> > > index 8432bd6b95f0..103978ff76c9 100644
> > > --- a/fs/nfs/nfs42xdr.c
> > > +++ b/fs/nfs/nfs42xdr.c
> > > @@ -191,7 +191,7 @@
> > >
> > >  #define encode_getxattr_maxsz   (op_encode_hdr_maxsz + 1 + \
> > >                                  nfs4_xattr_name_maxsz)
> > > -#define decode_getxattr_maxsz   (op_decode_hdr_maxsz + 1 + 1)
> > > +#define decode_getxattr_maxsz   (op_decode_hdr_maxsz + 1 +
> > > pagepad_maxsz)
> > >  #define encode_setxattr_maxsz   (op_encode_hdr_maxsz + \
> > >                                  1 + nfs4_xattr_name_maxsz + 1)
> > >  #define decode_setxattr_maxsz   (op_decode_hdr_maxsz +
> > > decode_change_info_maxsz)
> > > @@ -1476,17 +1476,18 @@ static void nfs4_xdr_enc_getxattr(struct
> > > rpc_rqst *req, struct xdr_stream *xdr,
> > >         struct compound_hdr hdr = {
> > >                 .minorversion = nfs4_xdr_minorversion(&args-
> > > > seq_args),
> > >         };
> > > +       uint32_t replen;
> > >         size_t plen;
> > >
> > >         encode_compound_hdr(xdr, req, &hdr);
> > >         encode_sequence(xdr, &args->seq_args, &hdr);
> > >         encode_putfh(xdr, args->fh, &hdr);
> > > +       replen = hdr.replen + op_decode_hdr_maxsz + 1;
> > >         encode_getxattr(xdr, args->xattr_name, &hdr);
> > >
> > >         plen = args->xattr_len ? args->xattr_len : XATTR_SIZE_MAX;
> > >
> > > -       rpc_prepare_reply_pages(req, args->xattr_pages, 0, plen,
> > > -           hdr.replen);
> > > +       rpc_prepare_reply_pages(req, args->xattr_pages, 0, plen,
> > > replen);
> > >         req->rq_rcv_buf.flags |= XDRBUF_SPARSE_PAGES;
> > >
> > >         encode_nops(&hdr);
> > > @@ -1520,14 +1521,15 @@ static void nfs4_xdr_enc_listxattrs(struct
> > > rpc_rqst *req,
> > >         struct compound_hdr hdr = {
> > >                 .minorversion = nfs4_xdr_minorversion(&args-
> > > > seq_args),
> > >         };
> > > +       uint32_t replen;
> > >
> > >         encode_compound_hdr(xdr, req, &hdr);
> > >         encode_sequence(xdr, &args->seq_args, &hdr);
> > >         encode_putfh(xdr, args->fh, &hdr);
> > > +       replen = hdr.replen + op_decode_hdr_maxsz + 2 + 1;
> > >         encode_listxattrs(xdr, args, &hdr);
> > >
> > > -       rpc_prepare_reply_pages(req, args->xattr_pages, 0, args-
> > > > count,
> > > -           hdr.replen);
> > > +       rpc_prepare_reply_pages(req, args->xattr_pages, 0, args-
> > > > count, replen);
> > >
> > >         encode_nops(&hdr);
> > >  }
> > > --
> > > 2.28.0
> >
> > Hm.. that doesn't seem to match other, similar functionality.
> > Why is the additional padding and op_decode_hdr_maxsz needed?
> >
> 
> It isn't extra padding. It is the same padding, but after the cleanup
> that removes the confusing behaviour of rpc_prepare_reply_pages(), the
> caller is supposed to supply the actual offset for the beginning of the
> page data instead of adding the padding to that offset:
> https://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=commitdiff;h=9ed5af268e88f6e5b65376be98d652b37cb20d7b

Ahh, that makes a lot of sense, thanks for fixing rpc_prepare_reply_pages.

- Frank