lsmod01: parse a copy of /proc/modules

PATCH New Stanislav Kholmanskikh 3 participants 19 messages Aug 29, 2016 – Nov 10, 2016

lore

Share & tools

lore

Stanislav Kholmanskikh

author

2016-08-29 11:08 UTC #0 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

In my environment, if TMPDIR is on NFSv4, this test case fails with:

lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---

Quoted 1 line

sunrpc 207591 29

To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.

Signed-off-by Stanislav Kholmanskikh <[email protected]>

---
This was found while preparing for the next LTP release.

testcases/commands/lsmod/lsmod01.sh | 3 ++-

 1 files changed, 2 insertions(+), 1 deletions(-)

testcases/commands/lsmod/lsmod01.sh +2 -1

index 5cf2fee..a880b97 100755
@@ -45,7 +45,8 @@ lsmod_test()
 
 	awk '!/Module/{print $1, $2, $3}' temp |sort >temp1
 
-	awk '{print $1, $2, $3}' /proc/modules |sort >temp2
+	cat /proc/modules > temp
+	awk '{print $1, $2, $3}' temp |sort >temp2
 
 	diff temp1 temp2 >temp3
 	if [ $? -ne 0 ]; then

Signature · 1 line

1.7.1

Cyril Hrubis

2016-08-29 12:50 UTC #1 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Hi!

Quoted 10 lines

In my environment, if TMPDIR is on NFSv4, this test case fails with:
lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---
Quoted 1 line
sunrpc 207591 29
To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.

So the sunrpc module gets its ref counter incremented from somewhere of the nfs kernel code once we open file on NFS?

But shouldn't the shell open the temp file the output is redirected to before it executes the command line anyway?

Signature · 2 lines

Cyril Hrubis
[email protected]

Stanislav Kholmanskikh

author

2016-08-29 13:05 UTC #2 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Quoted 9 lines · Cyril Hrubis

Hi!
Quoted 8 lines
In my environment, if TMPDIR is on NFSv4, this test case fails with:
lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---
Quoted 1 line
sunrpc 207591 29

Quoted 5 lines

Quoted 2 lines
To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.
So the sunrpc module gets its ref counter incremented from somewhere of the nfs kernel code once we open file on NFS?

Looks so. I hava a share mounted from localhost:

[root@skholman-m7 mnt]# mount|grep mnt
127.0.0.1:/opt on /mnt type nfs (rw,vers=4,addr=127.0.0.1,clientaddr=127.0.0.1) [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > /tmp/not_nfs
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# grep sunrpc /tmp/not_nfs
sunrpc 207591 28
[root@skholman-m7 mnt]#

Quoted 4 lines

But shouldn't the shell open the temp file the output is redirected to before it executes the command line anyway?

Jan Stancek

2016-08-29 13:34 UTC #3 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

----- Original Message -----

Quoted 26 lines

From: "Stanislav Kholmanskikh" <[email protected]>
To: "Cyril Hrubis" <[email protected]>
Cc: "vasily isaenko" <[email protected]>, [email protected]
Sent: Monday, 29 August, 2016 3:05:11 PM
Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
Quoted 9 lines · Cyril Hrubis
Hi!
Quoted 8 lines
In my environment, if TMPDIR is on NFSv4, this test case fails with:
lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---
Quoted 1 line
sunrpc 207591 29
Quoted 5 lines
Quoted 2 lines
To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.
So the sunrpc module gets its ref counter incremented from somewhere of the nfs kernel code once we open file on NFS?
Looks so. I hava a share mounted from localhost:

Quoted 11 lines

[root@skholman-m7 mnt]# mount|grep mnt
127.0.0.1:/opt on /mnt type nfs (rw,vers=4,addr=127.0.0.1,clientaddr=127.0.0.1) [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > /tmp/not_nfs
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# grep sunrpc /tmp/not_nfs
sunrpc 207591 28
[root@skholman-m7 mnt]#

And if you do that with just "cat /proc/modules", then there's no difference? Could it be that it's actually first write that takes extra ref? cat is reading in 65536 byte chunks for me, awk only 1024.

Regards,
Jan

Quoted 11 lines

Quoted 7 lines
But shouldn't the shell open the temp file the output is redirected to before it executes the command line anyway?
--
Mailing list info: https://lists.linux.it/listinfo/ltp

Stanislav Kholmanskikh

author

2016-08-29 14:00 UTC #4 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Quoted 43 lines · Jan Stancek

----- Original Message -----
Quoted 26 lines
From: "Stanislav Kholmanskikh" <[email protected]>
To: "Cyril Hrubis" <[email protected]>
Cc: "vasily isaenko" <[email protected]>, [email protected]
Sent: Monday, 29 August, 2016 3:05:11 PM
Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
Quoted 9 lines · Cyril Hrubis
Hi!
Quoted 8 lines
In my environment, if TMPDIR is on NFSv4, this test case fails with:
lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---
Quoted 1 line
sunrpc 207591 29
Quoted 5 lines
Quoted 2 lines
To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.
So the sunrpc module gets its ref counter incremented from somewhere of the nfs kernel code once we open file on NFS?
Looks so. I hava a share mounted from localhost:
Quoted 11 lines
[root@skholman-m7 mnt]# mount|grep mnt
127.0.0.1:/opt on /mnt type nfs (rw,vers=4,addr=127.0.0.1,clientaddr=127.0.0.1) [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > /tmp/not_nfs
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# grep sunrpc /tmp/not_nfs
sunrpc 207591 28
[root@skholman-m7 mnt]#

Quoted 3 lines

And if you do that with just "cat /proc/modules", then there's no difference? Could it be that it's actually first write that takes extra ref? cat is reading in 65536 byte chunks for me, awk only 1024.

Yes, there is no difference if I use "cat /proc/modules":

[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# cat /proc/modules > temp [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' temp|sort > nfs [root@skholman-m7 mnt]# grep sunrpc temp
sunrpc 207591 28 nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0x00000000101ec000 [root@skholman-m7 mnt]#

As for 1024. lsmod also reads /proc/modules in 1024 bytes chunks.

Quoted 15 lines

Regards,
Jan
Quoted 11 lines
Quoted 7 lines
But shouldn't the shell open the temp file the output is redirected to before it executes the command line anyway?
--
Mailing list info: https://lists.linux.it/listinfo/ltp

Stanislav Kholmanskikh

author

2016-08-29 14:03 UTC #5 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Quoted 61 lines · Stanislav Kholmanskikh

Quoted 43 lines · Jan Stancek
----- Original Message -----
Quoted 26 lines
From: "Stanislav Kholmanskikh" <[email protected]>
To: "Cyril Hrubis" <[email protected]>
Cc: "vasily isaenko" <[email protected]>, [email protected]
Sent: Monday, 29 August, 2016 3:05:11 PM
Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
Quoted 9 lines · Cyril Hrubis
Hi!
Quoted 8 lines
In my environment, if TMPDIR is on NFSv4, this test case fails with:
lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---
Quoted 1 line
sunrpc 207591 29
Quoted 5 lines
Quoted 2 lines
To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.
So the sunrpc module gets its ref counter incremented from somewhere of the nfs kernel code once we open file on NFS?
Looks so. I hava a share mounted from localhost:
Quoted 11 lines
[root@skholman-m7 mnt]# mount|grep mnt
127.0.0.1:/opt on /mnt type nfs (rw,vers=4,addr=127.0.0.1,clientaddr=127.0.0.1) [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > /tmp/not_nfs
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# grep sunrpc /tmp/not_nfs
sunrpc 207591 28
[root@skholman-m7 mnt]#
Quoted 3 lines
And if you do that with just "cat /proc/modules", then there's no difference? Could it be that it's actually first write that takes extra ref? cat is reading in 65536 byte chunks for me, awk only 1024.
Yes, there is no difference if I use "cat /proc/modules":
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# cat /proc/modules > temp [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' temp|sort > nfs [root@skholman-m7 mnt]# grep sunrpc temp
sunrpc 207591 28 nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0x00000000101ec000 [root@skholman-m7 mnt]#

Quoted 1 line

As for 1024. lsmod also reads /proc/modules in 1024 bytes chunks.

I suppose it's something related to using the pipe construction, since this change also "fixes" the issue:

[root@skholman-m7 lsmod]# git diff

(quoted diff) +0 -0

b/testcases/commands/lsmod/lsmod01.sh
index 5cf2fee..0970d2f 100755

testcases/commands/lsmod/lsmod01.sh +2 -1

@@ -45,7 +45,8 @@ lsmod_test()
 
        awk '!/Module/{print $1, $2, $3}' temp |sort >temp1
 
-       awk '{print $1, $2, $3}' /proc/modules |sort >temp2
+       awk '{print $1, $2, $3}' /proc/modules > temp
+       sort temp >temp2
 
        diff temp1 temp2 >temp3
        if [ $? -ne 0 ]; then

[root@skholman-m7 lsmod]#

Quoted 17 lines

Quoted 16 lines
Regards,
Jan
Quoted 11 lines
Quoted 7 lines
But shouldn't the shell open the temp file the output is redirected to before it executes the command line anyway?
--
Mailing list info: https://lists.linux.it/listinfo/ltp

Cyril Hrubis

2016-08-29 15:17 UTC #6 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Hi!
Looking into the kernel/module.c the /proc/modules is implemented with seq_* operations and the list of modules is iterated one by one util there is a space in buffer. And it looks like the module_mutex is acquired and released each time we call read(), so there is a chance that we race against something that loads/unloads kernel modules between the reads we do. Which would explain why we hit this only under certain conditions...

But I still do not see how writing to NFS triggers module load/unload or module refcount increment/decrement. I guess that this would be very hard to figure out without somebody who is familiar with the nfs code.

Signature · 2 lines

Cyril Hrubis
[email protected]

Jan Stancek

2016-08-29 15:49 UTC #7 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

In reply to Stanislav Kholmanskikh

----- Original Message -----

Quoted 72 lines

From: "Stanislav Kholmanskikh" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: "vasily isaenko" <[email protected]>, [email protected]
Sent: Monday, 29 August, 2016 4:03:44 PM
Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
Quoted 63 lines · Stanislav Kholmanskikh
Quoted 43 lines · Jan Stancek
----- Original Message -----
Quoted 26 lines
From: "Stanislav Kholmanskikh" <[email protected]>
To: "Cyril Hrubis" <[email protected]>
Cc: "vasily isaenko" <[email protected]>, [email protected]
Sent: Monday, 29 August, 2016 3:05:11 PM
Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
Quoted 9 lines · Cyril Hrubis
Hi!
Quoted 8 lines
In my environment, if TMPDIR is on NFSv4, this test case fails with:
lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---
Quoted 1 line
sunrpc 207591 29
Quoted 5 lines
Quoted 2 lines
To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.
So the sunrpc module gets its ref counter incremented from somewhere of the nfs kernel code once we open file on NFS?
Looks so. I hava a share mounted from localhost:
Quoted 11 lines
[root@skholman-m7 mnt]# mount|grep mnt
127.0.0.1:/opt on /mnt type nfs (rw,vers=4,addr=127.0.0.1,clientaddr=127.0.0.1) [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > /tmp/not_nfs
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# grep sunrpc /tmp/not_nfs
sunrpc 207591 28
[root@skholman-m7 mnt]#
Quoted 4 lines
And if you do that with just "cat /proc/modules", then there's no difference?
Could it be that it's actually first write that takes extra ref? cat is reading in 65536 byte chunks for me, awk only 1024.
Yes, there is no difference if I use "cat /proc/modules":
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# cat /proc/modules > temp [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' temp|sort > nfs [root@skholman-m7 mnt]# grep sunrpc temp
sunrpc 207591 28 nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0x00000000101ec000
[root@skholman-m7 mnt]#

Quoted 4 lines

Quoted 1 line
As for 1024. lsmod also reads /proc/modules in 1024 bytes chunks.
I suppose it's something related to using the pipe construction, since this change also "fixes" the issue:

I'm suspecting this to be some kind of race between opening file on nfs and reading /proc/modules at the same time:

# sh -c "cat /proc/modules | cat > temp2"; grep sunrpc temp2
sunrpc 300464 31 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

# taskset -c 0 sh -c "cat /proc/modules | cat > temp2"; grep sunrpc temp2
sunrpc 300464 30 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

# dd if=/proc/modules bs=1 | cat > temp2; grep sunrpc temp2
6332+0 records in
6332+0 records out
6332 bytes (6.3 kB) copied, 0.00288249 s, 2.2 MB/s
sunrpc 300464 30 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

# dd if=/proc/modules bs=2 | cat > temp2; grep sunrpc temp2
3166+0 records in
3166+0 records out
6332 bytes (6.3 kB) copied, 0.00148174 s, 4.3 MB/s
sunrpc 300464 31 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

# cat /proc/modules | sh -c cat > temp2; grep sunrpc temp2
sunrpc 300464 31 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

# cat /proc/modules | sh -c "cat > temp2"; grep sunrpc temp2
sunrpc 300464 30 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

Stanislav Kholmanskikh

author

2016-10-11 12:03 UTC #8 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Recovering an old thread. Please, see below:

Quoted 104 lines · Jan Stancek

----- Original Message -----
Quoted 72 lines
From: "Stanislav Kholmanskikh" <[email protected]>
To: "Jan Stancek" <[email protected]>
Cc: "vasily isaenko" <[email protected]>, [email protected]
Sent: Monday, 29 August, 2016 4:03:44 PM
Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
Quoted 63 lines · Stanislav Kholmanskikh
Quoted 43 lines · Jan Stancek
----- Original Message -----
Quoted 26 lines
From: "Stanislav Kholmanskikh" <[email protected]>
To: "Cyril Hrubis" <[email protected]>
Cc: "vasily isaenko" <[email protected]>, [email protected]
Sent: Monday, 29 August, 2016 3:05:11 PM
Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
Quoted 9 lines · Cyril Hrubis
Hi!
Quoted 8 lines
In my environment, if TMPDIR is on NFSv4, this test case fails with:
lsmod01 1 TFAIL : lsmod output different from /proc/modules.
21c21
< sunrpc 207591 28
---
Quoted 1 line
sunrpc 207591 29
Quoted 5 lines
Quoted 2 lines
To avoid such problems I separate the process of getting data from /proc/modules and the process of parsing it in the pipe structure.
So the sunrpc module gets its ref counter incremented from somewhere of the nfs kernel code once we open file on NFS?
Looks so. I hava a share mounted from localhost:
Quoted 11 lines
[root@skholman-m7 mnt]# mount|grep mnt
127.0.0.1:/opt on /mnt type nfs (rw,vers=4,addr=127.0.0.1,clientaddr=127.0.0.1) [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > /tmp/not_nfs
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# grep sunrpc /tmp/not_nfs
sunrpc 207591 28
[root@skholman-m7 mnt]#
Quoted 4 lines
And if you do that with just "cat /proc/modules", then there's no difference?
Could it be that it's actually first write that takes extra ref? cat is reading in 65536 byte chunks for me, awk only 1024.
Yes, there is no difference if I use "cat /proc/modules":
[root@skholman-m7 mnt]# awk '{print $1, $2, $3}' /proc/modules|sort > nfs [root@skholman-m7 mnt]# grep sunrpc nfs
sunrpc 207591 29
[root@skholman-m7 mnt]# cat /proc/modules > temp [root@skholman-m7 mnt]# awk '{print $1, $2, $3}' temp|sort > nfs [root@skholman-m7 mnt]# grep sunrpc temp
sunrpc 207591 28 nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0x00000000101ec000
[root@skholman-m7 mnt]#
Quoted 4 lines
Quoted 1 line
As for 1024. lsmod also reads /proc/modules in 1024 bytes chunks.
I suppose it's something related to using the pipe construction, since this change also "fixes" the issue:
I'm suspecting this to be some kind of race between opening file on nfs and reading /proc/modules at the same time:
# sh -c "cat /proc/modules | cat > temp2"; grep sunrpc temp2
sunrpc 300464 31 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000
# taskset -c 0 sh -c "cat /proc/modules | cat > temp2"; grep sunrpc temp2
sunrpc 300464 30 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000
or
# dd if=/proc/modules bs=1 | cat > temp2; grep sunrpc temp2
6332+0 records in
6332+0 records out
6332 bytes (6.3 kB) copied, 0.00288249 s, 2.2 MB/s
sunrpc 300464 30 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000
# dd if=/proc/modules bs=2 | cat > temp2; grep sunrpc temp2
3166+0 records in
3166+0 records out
6332 bytes (6.3 kB) copied, 0.00148174 s, 4.3 MB/s
sunrpc 300464 31 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

Quoted 8 lines

# cat /proc/modules | sh -c cat > temp2; grep sunrpc temp2
sunrpc 300464 31 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

# cat /proc/modules | sh -c "cat > temp2"; grep sunrpc temp2
sunrpc 300464 30 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,auth_rpcgss,nfs_acl,lockd, Live 0xffffffffa03a4000

Tried this all again.

This is from a 4.1-based kernel in a VirtualBox host:

[root@ol6-x64 mnt]# mount|grep mnt
127.0.0.1:/opt/ on /mnt type nfs (rw,vers=3,addr=127.0.0.1) [root@ol6-x64 mnt]# grep sunrpc /proc/modules
sunrpc 329262 28 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]# dd if=/dev/zero of=file bs=512

While the above dd command is running, in a separate shell I see:

[stas@ol6-x64 ~]$ lsmod|grep sunrpc
sunrpc 329262 36
nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss [stas@ol6-x64 ~]$

[root@ol6-x64 mnt]# grep sunrpc /proc/modules
sunrpc 329262 28 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]# dd if=/proc/modules bs=1 | cat > temp2; grep sunrpc temp2
2564+0 records in
2564+0 records out
2564 bytes (2.6 kB) copied, 0.00313203 s, 819 kB/s
sunrpc 329262 29 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]#

The same situation is with NFSv4.

So it turns out that writing to a file on NFS increases the sunrpc module reference counter. I don't observe this with ext4.ko.

So I find that my original patch is fine, it just needs a proper description.

Thoughts?

Cyril Hrubis

2016-10-11 13:38 UTC #9 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Hi!

Quoted 12 lines

Tried this all again.
This is from a 4.1-based kernel in a VirtualBox host:
[root@ol6-x64 mnt]# mount|grep mnt
127.0.0.1:/opt/ on /mnt type nfs (rw,vers=3,addr=127.0.0.1) [root@ol6-x64 mnt]# grep sunrpc /proc/modules
sunrpc 329262 28 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]# dd if=/dev/zero of=file bs=512

Quoted 6 lines

While the above dd command is running, in a separate shell I see:
[stas@ol6-x64 ~]$ lsmod|grep sunrpc
sunrpc 329262 36
nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss [stas@ol6-x64 ~]$

Hmm, 36, really increased by 8 because of the one dd?

That sounds even more strange.

Quoted 16 lines

[root@ol6-x64 mnt]# grep sunrpc /proc/modules
sunrpc 329262 28 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]# dd if=/proc/modules bs=1 | cat > temp2; grep sunrpc temp2
2564+0 records in
2564+0 records out
2564 bytes (2.6 kB) copied, 0.00313203 s, 819 kB/s
sunrpc 329262 29 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]#
The same situation is with NFSv4.

Quoted 7 lines

So it turns out that writing to a file on NFS increases the sunrpc module reference counter. I don't observe this with ext4.ko.
So I find that my original patch is fine, it just needs a proper description.
Thoughts?

Isn't the original patch just workaround? Since we write to the nfs TMPDIR as well, just differently, there is always possibility that we only made the problem less probable and that it will fail in one of thousand runs. Have you tried to run the test in a loop for some time?

Signature · 2 lines

Cyril Hrubis
[email protected]

Stanislav Kholmanskikh

author

2016-10-11 15:47 UTC #10 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Quoted 46 lines · Cyril Hrubis

Hi!
Quoted 12 lines
Tried this all again.
This is from a 4.1-based kernel in a VirtualBox host:
[root@ol6-x64 mnt]# mount|grep mnt
127.0.0.1:/opt/ on /mnt type nfs (rw,vers=3,addr=127.0.0.1) [root@ol6-x64 mnt]# grep sunrpc /proc/modules
sunrpc 329262 28 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]# dd if=/dev/zero of=file bs=512
Quoted 6 lines
While the above dd command is running, in a separate shell I see:
[stas@ol6-x64 ~]$ lsmod|grep sunrpc
sunrpc 329262 36
nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss [stas@ol6-x64 ~]$
Hmm, 36, really increased by 8 because of the one dd?
That sounds even more strange.
Quoted 22 lines
[root@ol6-x64 mnt]# grep sunrpc /proc/modules
sunrpc 329262 28 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]# dd if=/proc/modules bs=1 | cat > temp2; grep sunrpc temp2
2564+0 records in
2564+0 records out
2564 bytes (2.6 kB) copied, 0.00313203 s, 819 kB/s
sunrpc 329262 29 nfsv3,rpcsec_gss_krb5,nfsv4,nfs,nfsd,lockd,nfs_acl,auth_rpcgss, Live 0xffffffffa0366000
[root@ol6-x64 mnt]#
The same situation is with NFSv4.
So it turns out that writing to a file on NFS increases the sunrpc module reference counter. I don't observe this with ext4.ko.
So I find that my original patch is fine, it just needs a proper description.

Quoted 6 lines

Quoted 1 line
Thoughts?
Isn't the original patch just workaround? Since we write to the nfs TMPDIR as well, just differently, there is always possibility that we only made the problem less probable and that it will fail in one of thousand runs. Have you tried to run the test in a loop for some time?

Yes, the original patch is a workaround.

On my system I met 1 failure of 20000 runs (~1 hour).

Maybe we need to follow your proposal and test only the first two fields from lsmod.

Quoted 1 line

Cyril Hrubis

2016-10-11 16:15 UTC #11 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Hi!

Quoted 11 lines

Quoted 4 lines
Isn't the original patch just workaround? Since we write to the nfs TMPDIR as well, just differently, there is always possibility that we only made the problem less probable and that it will fail in one of thousand runs. Have you tried to run the test in a loop for some time?
Yes, the original patch is a workaround.
On my system I met 1 failure of 20000 runs (~1 hour).
Maybe we need to follow your proposal and test only the first two fields from lsmod.

We may also try to store the output from lsmod and /proc/modules to shell variables. Something as:

a=$(awk '{print $1, $2, $3}' /proc/modules |sort) b=$(lsmod | awk '!/Module/{print $1, $2, $3}' |sort)

Then compare $a and $b.

Signature · 2 lines

Cyril Hrubis
[email protected]

Stanislav Kholmanskikh

author

2016-11-09 14:34 UTC #12 lore raw

PATCH 1/1 lsmod01: keep the output in variables

Operations with a file on NFS may increase the reference counter of the corresponding module.

This test case creates temporary files in $TMPDIR, so if $TMPDIR is on NFS, it may fail with output similar to:

21c21
< sunrpc 207591 28
---

Quoted 1 line

sunrpc 207591 29

To overcome this problem it was proposed in [1] to keep the output in variables.

[1] http://lists.linux.it/pipermail/ltp/2016-October/002803.html

Signed-off-by Stanislav Kholmanskikh <[email protected]>

---
 testcases/commands/lsmod/lsmod01.sh |   24 ++++++++++++++----------
 1 files changed, 14 insertions(+), 10 deletions(-)

testcases/commands/lsmod/lsmod01.sh +14 ~~-10~~

index 5cf2fee..cd19ca4 100755
@@ -36,21 +36,25 @@ cleanup()
 
 lsmod_test()
 {
-	lsmod >temp 2>&1
-	if [ $? -ne 0 ]; then
-		tst_resm TFAIL "'lsmod' failed."
-		cat temp
+	lsmod_output=$(lsmod | awk '!/Module/{print $1, $2, $3}' | sort)
+	if [ -z "$lsmod_output" ]; then
+		tst_resm TFAIL "Failed to parse the output from lsmod"
 		return
 	fi
 
-	awk '!/Module/{print $1, $2, $3}' temp |sort >temp1
-
-	awk '{print $1, $2, $3}' /proc/modules |sort >temp2
+	modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)
+	if [ -z "$modules_output" ]; then
+		tst_resm TFAIL "Failed to parse /proc/modules"
+		return
+	fi
 
-	diff temp1 temp2 >temp3
-	if [ $? -ne 0 ]; then
+	if [ "$lsmod_output" != "$modules_output" ]; then
 		tst_resm TFAIL "lsmod output different from /proc/modules."
-		cat temp3
+
+		echo "$lsmod_output" > temp1
+		echo "$modules_output" > temp2
+		diff temp1 temp2
+
 		return
 	fi

Signature · 1 line

1.7.1

Cyril Hrubis

2016-11-09 16:49 UTC #13 lore raw

PATCH 1/1 lsmod01: keep the output in variables

Quoted 20 lines

lsmod_test()
{

testcases/commands/lsmod/lsmod01.sh +8 -7

-	lsmod >temp 2>&1
-	if [ $? -ne 0 ]; then
-		tst_resm TFAIL "'lsmod' failed."
-		cat temp
+	lsmod_output=$(lsmod | awk '!/Module/{print $1, $2, $3}' | sort)
+	if [ -z "$lsmod_output" ]; then
+		tst_resm TFAIL "Failed to parse the output from lsmod"
 		return
 	fi
 
-	awk '!/Module/{print $1, $2, $3}' temp |sort >temp1
-
-	awk '{print $1, $2, $3}' /proc/modules |sort >temp2
+	modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)
+	if [ -z "$modules_output" ]; then
+		tst_resm TFAIL "Failed to parse /proc/modules"
+		return
+	fi

testcases/commands/lsmod/lsmod01.sh cleanup() · line 56

Quoted 10 lines

testcases/commands/lsmod/lsmod01.sh +5 -3

 
-	diff temp1 temp2 >temp3
-	if [ $? -ne 0 ]; then
+	if [ "$lsmod_output" != "$modules_output" ]; then
 		tst_resm TFAIL "lsmod output different from /proc/modules."
-		cat temp3
+
+		echo "$lsmod_output" > temp1
+		echo "$modules_output" > temp2
+		diff temp1 temp2

Hmm since the foo=$() flattened the text into single line this diff would be pretty much useless.

So we can either just print these two lines, or split them again so that exactly three words/numbers are on each line before we do the diff.

Quoted 6 lines

(quoted diff) +0 -0
 		return
 	fi
Signature · 2 lines
-- 
1.7.1

Signature · 2 lines

Cyril Hrubis
[email protected]

Stanislav Kholmanskikh

author

2016-11-10 10:07 UTC #14 lore raw

PATCH 1/1 lsmod01: keep the output in variables

Quoted 21 lines · Cyril Hrubis

Quoted 21 lines

lsmod_test()
{

testcases/commands/lsmod/lsmod01.sh +8 -7

-	lsmod >temp 2>&1
-	if [ $? -ne 0 ]; then
-		tst_resm TFAIL "'lsmod' failed."
-		cat temp
+	lsmod_output=$(lsmod | awk '!/Module/{print $1, $2, $3}' | sort)
+	if [ -z "$lsmod_output" ]; then
+		tst_resm TFAIL "Failed to parse the output from lsmod"
 		return
 	fi
 
-	awk '!/Module/{print $1, $2, $3}' temp |sort >temp1
-
-	awk '{print $1, $2, $3}' /proc/modules |sort >temp2
+	modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)
+	if [ -z "$modules_output" ]; then
+		tst_resm TFAIL "Failed to parse /proc/modules"
+		return
+	fi

Quoted 12 lines

testcases/commands/lsmod/lsmod01.sh cleanup() · line 56
Quoted 9 lines
testcases/commands/lsmod/lsmod01.sh +5 -3
-	diff temp1 temp2 >temp3
-	if [ $? -ne 0 ]; then
+	if [ "$lsmod_output" != "$modules_output" ]; then
 		tst_resm TFAIL "lsmod output different from /proc/modules."
-		cat temp3
+
+		echo "$lsmod_output" > temp1
+		echo "$modules_output" > temp2
+		diff temp1 temp2
Hmm since the foo=$() flattened the text into single line this diff would be pretty much useless.

Sorry, but are you sure about that?

[stas@kholmanskikh ~]$ lsmod_output=$(lsmod | awk '!/Module/{print $1, $2, $3}' | sort)
[stas@kholmanskikh ~]$ echo "$lsmod_output" > /tmp/gg [stas@kholmanskikh ~]$ tail -n 2 /tmp/gg
xt_state 1370 3
zlib_deflate 21991 1
[stas@kholmanskikh ~]$ modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)
[stas@kholmanskikh ~]$ echo "$modules_output" > /tmp/zz [stas@kholmanskikh ~]$ tail -n 2 /tmp/zz
xt_state 1370 3
zlib_deflate 21991 1
[stas@kholmanskikh ~]$

i.e. the content of /tmp/gg and /tmp/zz are in the form ready to be diff-ed.

Quoted 12 lines

So we can either just print these two lines, or split them again so that exactly three words/numbers are on each line before we do the diff.
Quoted 6 lines
(quoted diff) +0 -0
 		return
 	fi
Signature · 2 lines
-- 
1.7.1

Cyril Hrubis

2016-11-10 11:39 UTC #15 lore raw

PATCH 1/1 lsmod01: keep the output in variables

Hi!

Quoted 19 lines

Quoted 2 lines
Hmm since the foo=$() flattened the text into single line this diff would be pretty much useless.
Sorry, but are you sure about that?
[stas@kholmanskikh ~]$ lsmod_output=$(lsmod | awk '!/Module/{print $1, $2, $3}' | sort)
[stas@kholmanskikh ~]$ echo "$lsmod_output" > /tmp/gg [stas@kholmanskikh ~]$ tail -n 2 /tmp/gg
xt_state 1370 3
zlib_deflate 21991 1
[stas@kholmanskikh ~]$ modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)
[stas@kholmanskikh ~]$ echo "$modules_output" > /tmp/zz [stas@kholmanskikh ~]$ tail -n 2 /tmp/zz
xt_state 1370 3
zlib_deflate 21991 1
[stas@kholmanskikh ~]$

Quoted 1 line

i.e. the content of /tmp/gg and /tmp/zz are in the form ready to be diff-ed.

You are right, the double quotes makes the difference here.

$ modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)

$ echo $modules_output
bluetooth 320499 5 btbcm 5506 1 btintel 2739 1 ...

$ echo "$modules_output"
bluetooth 320499 5
btbcm 5506 1
btintel 2739 1
...

Consider the patch acked then.

Signature · 2 lines

Cyril Hrubis
[email protected]

Stanislav Kholmanskikh

author

2016-11-10 14:15 UTC #16 lore raw

PATCH 1/1 lsmod01: keep the output in variables

Quoted 29 lines · Cyril Hrubis

Hi!
Quoted 19 lines
Quoted 2 lines
Hmm since the foo=$() flattened the text into single line this diff would be pretty much useless.
Sorry, but are you sure about that?
[stas@kholmanskikh ~]$ lsmod_output=$(lsmod | awk '!/Module/{print $1, $2, $3}' | sort)
[stas@kholmanskikh ~]$ echo "$lsmod_output" > /tmp/gg [stas@kholmanskikh ~]$ tail -n 2 /tmp/gg
xt_state 1370 3
zlib_deflate 21991 1
[stas@kholmanskikh ~]$ modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)
[stas@kholmanskikh ~]$ echo "$modules_output" > /tmp/zz [stas@kholmanskikh ~]$ tail -n 2 /tmp/zz
xt_state 1370 3
zlib_deflate 21991 1
[stas@kholmanskikh ~]$
Quoted 1 line
i.e. the content of /tmp/gg and /tmp/zz are in the form ready to be diff-ed.
You are right, the double quotes makes the difference here.
$ modules_output=$(awk '{print $1, $2, $3}' /proc/modules | sort)
$ echo $modules_output
bluetooth 320499 5 btbcm 5506 1 btintel 2739 1 ...

Quoted 8 lines

$ echo "$modules_output"
bluetooth 320499 5
btbcm 5506 1
btintel 2739 1
...

Consider the patch acked then.

Thank you. Pushed.

Quoted 1 line

Cyril Hrubis

2016-08-31 13:55 UTC #17 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

In reply to Stanislav Kholmanskikh

Hi!
Thinking of this again, why don't we just compare the first two fields of the output?

Signature · 2 lines

Cyril Hrubis
[email protected]

Stanislav Kholmanskikh

author

2016-09-02 14:12 UTC #18 lore raw

PATCH 1/1 lsmod01: parse a copy of /proc/modules

Hi,

Quoted 4 lines · Cyril Hrubis

Hi!
Thinking of this again, why don't we just compare the first two fields of the output?

I thought it would be an unnecessary narrowing of the test scope, i.e. why test 2 fields if we can test 3.