Re: Kernel OPS when using xattr

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxx>
> > > ---
> > >  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



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux