Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 27 Aug 2019 09:20:03 -0400 (EDT)
From:   Jan Stancek <jstancek@redhat.com>
To:     Trond Myklebust <trondmy@hammerspace.com>,
        naresh kamboju <naresh.kamboju@linaro.org>
Cc:     the hoang0709 <the_hoang0709@yahoo.com>,
        linux-next@vger.kernel.org, ltp@lists.linux.it,
        linux-kernel@vger.kernel.org, chrubis@suse.cz,
        alexey kodanev <alexey.kodanev@oracle.com>
Message-ID: <241383129.8399897.1566912003912.JavaMail.zimbra@redhat.com>
In-Reply-To: <294428f05e4dba1a6b10b8744cfa5da0637f84a4.camel@hammerspace.com>
References: <CA+G9fYtN2tjHZtjtc8isdsD5hF76teeh2-pngUp+uj3WYdj7jA@mail.gmail.com> <CA+G9fYsHpNKFHr=ZukVvj+uMJDyHj2Xwb9bCfzPQyYzMjZ0rCw@mail.gmail.com> <203971593.8175020.1566830285708.JavaMail.zimbra@redhat.com> <fcd20866bb836d45b1e384dd68080c671bcde938.camel@hammerspace.com> <2039173876.8300255.1566861172742.JavaMail.zimbra@redhat.com> <566e862d9bfaf88cdde6d66f0f59033fe6225a22.camel@hammerspace.com> <866876796.8349197.1566901536625.JavaMail.zimbra@redhat.com> <294428f05e4dba1a6b10b8744cfa5da0637f84a4.camel@hammerspace.com>
Subject: Re: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed
 to run cmd: useradd hsym
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed
 to run cmd: useradd hsym
Thread-Index: YFeV1UC3LeIsRdovt5+kMdO7I/BycvuMo5UAj4lK/k3wd0xbAPZWZFoxiapkYwBjzrsPWQ==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


----- Original Message -----
> On Tue, 2019-08-27 at 06:25 -0400, Jan Stancek wrote:
> > That theory is probably not correct for this case, since EIO I see
> > appears
> > to originate from write and nfs_writeback_result(). This function
> > also
> > produces message we saw in logs from Naresh.
> > 
> > I can't find where/how is resp->count updated on WRITE reply in
> > NFSv2.
> > Issue also goes away with patch below, though I can't speak about its
> > correctness:
> > 
> > NFS version     Type    Test    Return code
> > nfsvers=2       tcp     -b:base         0
> > nfsvers=2       tcp     -g:general      0
> > nfsvers=2       tcp     -s:special      0
> > nfsvers=2       tcp     -l:lock         0
> > Total time: 141
> > 
> > diff --git a/fs/nfs/nfs2xdr.c b/fs/nfs/nfs2xdr.c
> > index cbc17a203248..4913c6da270b 100644
> > --- a/fs/nfs/nfs2xdr.c
> > +++ b/fs/nfs/nfs2xdr.c
> > @@ -897,6 +897,16 @@ static int nfs2_xdr_dec_writeres(struct rpc_rqst
> > *req, struct xdr_stream *xdr,
> >                                  void *data)
> >  {
> >         struct nfs_pgio_res *result = data;
> > +       struct rpc_task *rq_task  = req->rq_task;
> > +
> > +       if (rq_task) {
> > +               struct nfs_pgio_args *args = rq_task-
> > >tk_msg.rpc_argp;
> > +
> > +               if (args) {
> > +                       result->count = args->count;
> > +               }
> > +       }
> >  
> >         /* All NFSv2 writes are "file sync" writes */
> >         result->verf->committed = NFS_FILE_SYNC;
> 
> Thanks! I've moved the above to nfs_write_done() so that we do it only
> on success (see
> http://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=commitdiff;h=3ba5688da709dd0f7d917029c206bc1848a6ae74
> )

Thanks, retested with 3ba5688da, all PASS:

NFS version     Type    Test    Return code
nfsvers=2       tcp     -b:base         0
nfsvers=2       tcp     -g:general      0
nfsvers=2       tcp     -s:special      0
nfsvers=2       tcp     -l:lock         0

NFS version     Type    Test    Return code
nfsvers=3       tcp     -b:base         0
nfsvers=3       tcp     -g:general      0
nfsvers=3       tcp     -s:special      0
nfsvers=3       tcp     -l:lock         0
nfsvers=3       tcp6    -b:base         0
nfsvers=3       tcp6    -g:general      0
nfsvers=3       tcp6    -s:special      0
nfsvers=3       tcp6    -l:lock         0

NFS version     Type    Test    Return code
nfsvers=4       tcp     -b:base         0
nfsvers=4       tcp     -g:general      0
nfsvers=4       tcp     -s:special      0
nfsvers=4       tcp     -l:lock         0
nfsvers=4       tcp6    -b:base         0
nfsvers=4       tcp6    -g:general      0
nfsvers=4       tcp6    -s:special      0
nfsvers=4       tcp6    -l:lock         0

Feel free to add also:

Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Tested-by: Jan Stancek <jstancek@redhat.com>