From: Jan Stancek <jstancek@redhat.com>
To: Trond Myklebust <trondmy@hammerspace.com>
Cc: naresh kamboju <naresh.kamboju@linaro.org>,
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>
Subject: Re: Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym
Date: Mon, 26 Aug 2019 19:12:52 -0400 (EDT) [thread overview]
Message-ID: <2039173876.8300255.1566861172742.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <fcd20866bb836d45b1e384dd68080c671bcde938.camel@hammerspace.com>
----- Original Message -----
> On Mon, 2019-08-26 at 10:38 -0400, Jan Stancek wrote:
> > ----- Original Message -----
> > > Hi Jan and Cyril,
> > >
> > > On Mon, 26 Aug 2019 at 16:35, Jan Stancek <jstancek@redhat.com>
> > > wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > Hi!
> > > > > > Do you see this LTP prot_hsymlinks failure on linux next
> > > > > > 20190823 on
> > > > > > x86_64 and i386 devices?
> > > > > >
> > > > > > test output log,
> > > > > > useradd: failure while writing changes to /etc/passwd
> > > > > > useradd: /home/hsym was created, but could not be removed
> > > > >
> > > > > This looks like an unrelated problem, failure to write to
> > > > > /etc/passwd
> > > > > probably means that filesystem is full or some problem happend
> > > > > and how
> > > > > is remounted RO.
> > > >
> > > > In Naresh' example, root is on NFS:
> > > > root=/dev/nfs rw
> > > >
> > > > nfsroot=10.66.16.123:/var/lib/lava/dispatcher/tmp/886412/extract-
> > > > nfsrootfs-tyuevoxm,tcp,hard,intr
> > >
> > > Right !
> > > root is mounted on NFS.
> > >
> > > > 10.66.16.123:/var/lib/lava/dispatcher/tmp/886412/extract-
> > > > nfsrootfs-tyuevoxm
> > > > on / type nfs
> > > > (rw,relatime,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nolock,
> > > > proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.66.16.123,moun
> > > > tvers=1,mountproto=tcp,local_lock=all,addr=10.66.16.123)
> > > > devtmpfs on /dev type devtmpfs
> > > > (rw,relatime,size=3977640k,nr_inodes=994410,mode=755)
> > > >
>
> The only thing I can think of that might cause an EIO on NFSv2 would be
> this patch
> http://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=commitdiff;h=627d48e597ec5993c4abb3b81dc75e554a07c7c0
> assuming that a bind-related error is leaking through.
>
> I'd suggest something like the following to fix it up:
No change with that patch,
but following one fixes it for me:
diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index 20b3717cd7ca..56cefa0ab804 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -590,7 +590,7 @@ static void nfs_pgio_rpcsetup(struct nfs_pgio_header *hdr,
}
hdr->res.fattr = &hdr->fattr;
- hdr->res.count = 0;
+ hdr->res.count = count;
hdr->res.eof = 0;
hdr->res.verf = &hdr->verf;
nfs_fattr_init(&hdr->fattr);
which is functionally revert of "NFS: Fix initialisation of I/O result struct in nfs_pgio_rpcsetup".
This hunk caught my eye, could res.eof == 0 explain those I/O errors?
/* Emulate the eof flag, which isn't normally needed in NFSv2
* as it is guaranteed to always return the file attributes
*/
if (hdr->args.offset + hdr->res.count >= hdr->res.fattr->size)
hdr->res.eof = 1;
WARNING: multiple messages have this Message-ID (diff)
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym
Date: Mon, 26 Aug 2019 19:12:52 -0400 (EDT) [thread overview]
Message-ID: <2039173876.8300255.1566861172742.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <fcd20866bb836d45b1e384dd68080c671bcde938.camel@hammerspace.com>
----- Original Message -----
> On Mon, 2019-08-26 at 10:38 -0400, Jan Stancek wrote:
> > ----- Original Message -----
> > > Hi Jan and Cyril,
> > >
> > > On Mon, 26 Aug 2019 at 16:35, Jan Stancek <jstancek@redhat.com>
> > > wrote:
> > > >
> > > >
> > > > ----- Original Message -----
> > > > > Hi!
> > > > > > Do you see this LTP prot_hsymlinks failure on linux next
> > > > > > 20190823 on
> > > > > > x86_64 and i386 devices?
> > > > > >
> > > > > > test output log,
> > > > > > useradd: failure while writing changes to /etc/passwd
> > > > > > useradd: /home/hsym was created, but could not be removed
> > > > >
> > > > > This looks like an unrelated problem, failure to write to
> > > > > /etc/passwd
> > > > > probably means that filesystem is full or some problem happend
> > > > > and how
> > > > > is remounted RO.
> > > >
> > > > In Naresh' example, root is on NFS:
> > > > root=/dev/nfs rw
> > > >
> > > > nfsroot=10.66.16.123:/var/lib/lava/dispatcher/tmp/886412/extract-
> > > > nfsrootfs-tyuevoxm,tcp,hard,intr
> > >
> > > Right !
> > > root is mounted on NFS.
> > >
> > > > 10.66.16.123:/var/lib/lava/dispatcher/tmp/886412/extract-
> > > > nfsrootfs-tyuevoxm
> > > > on / type nfs
> > > > (rw,relatime,vers=2,rsize=4096,wsize=4096,namlen=255,hard,nolock,
> > > > proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.66.16.123,moun
> > > > tvers=1,mountproto=tcp,local_lock=all,addr=10.66.16.123)
> > > > devtmpfs on /dev type devtmpfs
> > > > (rw,relatime,size=3977640k,nr_inodes=994410,mode=755)
> > > >
>
> The only thing I can think of that might cause an EIO on NFSv2 would be
> this patch
> http://git.linux-nfs.org/?p=trondmy/linux-nfs.git;a=commitdiff;h=627d48e597ec5993c4abb3b81dc75e554a07c7c0
> assuming that a bind-related error is leaking through.
>
> I'd suggest something like the following to fix it up:
No change with that patch,
but following one fixes it for me:
diff --git a/fs/nfs/pagelist.c b/fs/nfs/pagelist.c
index 20b3717cd7ca..56cefa0ab804 100644
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -590,7 +590,7 @@ static void nfs_pgio_rpcsetup(struct nfs_pgio_header *hdr,
}
hdr->res.fattr = &hdr->fattr;
- hdr->res.count = 0;
+ hdr->res.count = count;
hdr->res.eof = 0;
hdr->res.verf = &hdr->verf;
nfs_fattr_init(&hdr->fattr);
which is functionally revert of "NFS: Fix initialisation of I/O result struct in nfs_pgio_rpcsetup".
This hunk caught my eye, could res.eof == 0 explain those I/O errors?
/* Emulate the eof flag, which isn't normally needed in NFSv2
* as it is guaranteed to always return the file attributes
*/
if (hdr->args.offset + hdr->res.count >= hdr->res.fattr->size)
hdr->res.eof = 1;
next prev parent reply other threads:[~2019-08-26 23:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 9:47 Linux-next-20190823: x86_64/i386: prot_hsymlinks.c:325: Failed to run cmd: useradd hsym Naresh Kamboju
2019-08-26 9:47 ` [LTP] " Naresh Kamboju
2019-08-26 10:41 ` Cyril Hrubis
2019-08-26 10:41 ` [LTP] " Cyril Hrubis
2019-08-26 11:05 ` Jan Stancek
2019-08-26 11:05 ` [LTP] " Jan Stancek
2019-08-26 13:50 ` Naresh Kamboju
2019-08-26 13:50 ` [LTP] " Naresh Kamboju
2019-08-26 14:38 ` Jan Stancek
2019-08-26 14:38 ` [LTP] " Jan Stancek
2019-08-26 15:58 ` Trond Myklebust
2019-08-26 15:58 ` [LTP] " Trond Myklebust
2019-08-26 23:12 ` Jan Stancek [this message]
2019-08-26 23:12 ` Jan Stancek
2019-08-27 0:59 ` Trond Myklebust
2019-08-27 0:59 ` [LTP] " Trond Myklebust
2019-08-27 10:25 ` Jan Stancek
2019-08-27 10:25 ` [LTP] " Jan Stancek
2019-08-27 12:58 ` Trond Myklebust
2019-08-27 12:58 ` [LTP] " Trond Myklebust
2019-08-27 13:20 ` Jan Stancek
2019-08-27 13:20 ` [LTP] " Jan Stancek
2019-08-27 6:34 ` Naresh Kamboju
2019-08-27 6:34 ` [LTP] " Naresh Kamboju
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=2039173876.8300255.1566861172742.JavaMail.zimbra@redhat.com \
--to=jstancek@redhat.com \
--cc=alexey.kodanev@oracle.com \
--cc=chrubis@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=naresh.kamboju@linaro.org \
--cc=the_hoang0709@yahoo.com \
--cc=trondmy@hammerspace.com \
/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.