* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
@ 2016-08-29 11:08 Stanislav Kholmanskikh
2016-08-29 12:50 ` Cyril Hrubis
2016-08-31 13:55 ` [LTP] [PATCH] lsmod01: parse a copy of /proc/modules Cyril Hrubis
0 siblings, 2 replies; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-08-29 11:08 UTC (permalink / raw)
To: ltp
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
---
> 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 <stanislav.kholmanskikh@oracle.com>
---
This was found while preparing for the next LTP release.
testcases/commands/lsmod/lsmod01.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/testcases/commands/lsmod/lsmod01.sh b/testcases/commands/lsmod/lsmod01.sh
index 5cf2fee..a880b97 100755
--- a/testcases/commands/lsmod/lsmod01.sh
+++ b/testcases/commands/lsmod/lsmod01.sh
@@ -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
--
1.7.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 11:08 [LTP] [PATCH] lsmod01: parse a copy of /proc/modules Stanislav Kholmanskikh
@ 2016-08-29 12:50 ` Cyril Hrubis
2016-08-29 13:05 ` Stanislav Kholmanskikh
2016-08-31 13:55 ` [LTP] [PATCH] lsmod01: parse a copy of /proc/modules Cyril Hrubis
1 sibling, 1 reply; 19+ messages in thread
From: Cyril Hrubis @ 2016-08-29 12:50 UTC (permalink / raw)
To: ltp
Hi!
> 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
> ---
> > 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?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 12:50 ` Cyril Hrubis
@ 2016-08-29 13:05 ` Stanislav Kholmanskikh
2016-08-29 13:34 ` Jan Stancek
0 siblings, 1 reply; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-08-29 13:05 UTC (permalink / raw)
To: ltp
On 08/29/2016 03:50 PM, Cyril Hrubis wrote:
> Hi!
>> 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
>> ---
>> > 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?
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]#
>
> But shouldn't the shell open the temp file the output is redirected to
> before it executes the command line anyway?
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 13:05 ` Stanislav Kholmanskikh
@ 2016-08-29 13:34 ` Jan Stancek
2016-08-29 14:00 ` Stanislav Kholmanskikh
0 siblings, 1 reply; 19+ messages in thread
From: Jan Stancek @ 2016-08-29 13:34 UTC (permalink / raw)
To: ltp
----- Original Message -----
> From: "Stanislav Kholmanskikh" <stanislav.kholmanskikh@oracle.com>
> To: "Cyril Hrubis" <chrubis@suse.cz>
> Cc: "vasily isaenko" <vasily.isaenko@oracle.com>, ltp@lists.linux.it
> Sent: Monday, 29 August, 2016 3:05:11 PM
> Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
>
>
>
> On 08/29/2016 03:50 PM, Cyril Hrubis wrote:
> > Hi!
> >> 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
> >> ---
> >> > 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?
>
> 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]#
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
>
>
>
> >
> > 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
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 13:34 ` Jan Stancek
@ 2016-08-29 14:00 ` Stanislav Kholmanskikh
2016-08-29 14:03 ` Stanislav Kholmanskikh
0 siblings, 1 reply; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-08-29 14:00 UTC (permalink / raw)
To: ltp
On 08/29/2016 04:34 PM, Jan Stancek wrote:
>
>
>
>
> ----- Original Message -----
>> From: "Stanislav Kholmanskikh" <stanislav.kholmanskikh@oracle.com>
>> To: "Cyril Hrubis" <chrubis@suse.cz>
>> Cc: "vasily isaenko" <vasily.isaenko@oracle.com>, ltp@lists.linux.it
>> Sent: Monday, 29 August, 2016 3:05:11 PM
>> Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
>>
>>
>>
>> On 08/29/2016 03:50 PM, Cyril Hrubis wrote:
>>> Hi!
>>>> 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
>>>> ---
>>>> > 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?
>>
>> 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]#
>
> 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.
>
> Regards,
> Jan
>
>>
>>
>>
>>>
>>> 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
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 14:00 ` Stanislav Kholmanskikh
@ 2016-08-29 14:03 ` Stanislav Kholmanskikh
2016-08-29 15:17 ` Cyril Hrubis
2016-08-29 15:49 ` Jan Stancek
0 siblings, 2 replies; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-08-29 14:03 UTC (permalink / raw)
To: ltp
On 08/29/2016 05:00 PM, Stanislav Kholmanskikh wrote:
>
>
> On 08/29/2016 04:34 PM, Jan Stancek wrote:
>>
>>
>>
>>
>> ----- Original Message -----
>>> From: "Stanislav Kholmanskikh" <stanislav.kholmanskikh@oracle.com>
>>> To: "Cyril Hrubis" <chrubis@suse.cz>
>>> Cc: "vasily isaenko" <vasily.isaenko@oracle.com>, ltp@lists.linux.it
>>> Sent: Monday, 29 August, 2016 3:05:11 PM
>>> Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
>>>
>>>
>>>
>>> On 08/29/2016 03:50 PM, Cyril Hrubis wrote:
>>>> Hi!
>>>>> 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
>>>>> ---
>>>>> > 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?
>>>
>>> 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]#
>>
>> 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.
I suppose it's something related to using the pipe construction, since
this change also "fixes" the issue:
[root@skholman-m7 lsmod]# git diff
diff --git a/testcases/commands/lsmod/lsmod01.sh
b/testcases/commands/lsmod/lsmod01.sh
index 5cf2fee..0970d2f 100755
--- a/testcases/commands/lsmod/lsmod01.sh
+++ b/testcases/commands/lsmod/lsmod01.sh
@@ -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]#
>
>>
>> Regards,
>> Jan
>>
>>>
>>>
>>>
>>>>
>>>> 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
>>>
>
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 14:03 ` Stanislav Kholmanskikh
@ 2016-08-29 15:17 ` Cyril Hrubis
2016-08-29 15:49 ` Jan Stancek
1 sibling, 0 replies; 19+ messages in thread
From: Cyril Hrubis @ 2016-08-29 15:17 UTC (permalink / raw)
To: ltp
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.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 14:03 ` Stanislav Kholmanskikh
2016-08-29 15:17 ` Cyril Hrubis
@ 2016-08-29 15:49 ` Jan Stancek
2016-10-11 12:03 ` Stanislav Kholmanskikh
1 sibling, 1 reply; 19+ messages in thread
From: Jan Stancek @ 2016-08-29 15:49 UTC (permalink / raw)
To: ltp
----- Original Message -----
> From: "Stanislav Kholmanskikh" <stanislav.kholmanskikh@oracle.com>
> To: "Jan Stancek" <jstancek@redhat.com>
> Cc: "vasily isaenko" <vasily.isaenko@oracle.com>, ltp@lists.linux.it
> Sent: Monday, 29 August, 2016 4:03:44 PM
> Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
>
>
>
> On 08/29/2016 05:00 PM, Stanislav Kholmanskikh wrote:
> >
> >
> > On 08/29/2016 04:34 PM, Jan Stancek wrote:
> >>
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Stanislav Kholmanskikh" <stanislav.kholmanskikh@oracle.com>
> >>> To: "Cyril Hrubis" <chrubis@suse.cz>
> >>> Cc: "vasily isaenko" <vasily.isaenko@oracle.com>, ltp@lists.linux.it
> >>> Sent: Monday, 29 August, 2016 3:05:11 PM
> >>> Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
> >>>
> >>>
> >>>
> >>> On 08/29/2016 03:50 PM, Cyril Hrubis wrote:
> >>>> Hi!
> >>>>> 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
> >>>>> ---
> >>>>> > 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?
> >>>
> >>> 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]#
> >>
> >> 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.
>
> 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
or
# 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 11:08 [LTP] [PATCH] lsmod01: parse a copy of /proc/modules Stanislav Kholmanskikh
2016-08-29 12:50 ` Cyril Hrubis
@ 2016-08-31 13:55 ` Cyril Hrubis
2016-09-02 14:12 ` Stanislav Kholmanskikh
1 sibling, 1 reply; 19+ messages in thread
From: Cyril Hrubis @ 2016-08-31 13:55 UTC (permalink / raw)
To: ltp
Hi!
Thinking of this again, why don't we just compare the first two fields
of the output?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-31 13:55 ` [LTP] [PATCH] lsmod01: parse a copy of /proc/modules Cyril Hrubis
@ 2016-09-02 14:12 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-09-02 14:12 UTC (permalink / raw)
To: ltp
Hi,
On 08/31/2016 04:55 PM, Cyril Hrubis wrote:
> 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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-08-29 15:49 ` Jan Stancek
@ 2016-10-11 12:03 ` Stanislav Kholmanskikh
2016-10-11 13:38 ` Cyril Hrubis
0 siblings, 1 reply; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-10-11 12:03 UTC (permalink / raw)
To: ltp
Recovering an old thread. Please, see below:
On 08/29/2016 06:49 PM, Jan Stancek wrote:
>
>
>
> ----- Original Message -----
>> From: "Stanislav Kholmanskikh" <stanislav.kholmanskikh@oracle.com>
>> To: "Jan Stancek" <jstancek@redhat.com>
>> Cc: "vasily isaenko" <vasily.isaenko@oracle.com>, ltp@lists.linux.it
>> Sent: Monday, 29 August, 2016 4:03:44 PM
>> Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
>>
>>
>>
>> On 08/29/2016 05:00 PM, Stanislav Kholmanskikh wrote:
>>>
>>>
>>> On 08/29/2016 04:34 PM, Jan Stancek wrote:
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stanislav Kholmanskikh" <stanislav.kholmanskikh@oracle.com>
>>>>> To: "Cyril Hrubis" <chrubis@suse.cz>
>>>>> Cc: "vasily isaenko" <vasily.isaenko@oracle.com>, ltp@lists.linux.it
>>>>> Sent: Monday, 29 August, 2016 3:05:11 PM
>>>>> Subject: Re: [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
>>>>>
>>>>>
>>>>>
>>>>> On 08/29/2016 03:50 PM, Cyril Hrubis wrote:
>>>>>> Hi!
>>>>>>> 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
>>>>>>> ---
>>>>>>> > 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?
>>>>>
>>>>> 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]#
>>>>
>>>> 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.
>>
>> 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
>
> or
>
> # 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?
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-10-11 12:03 ` Stanislav Kholmanskikh
@ 2016-10-11 13:38 ` Cyril Hrubis
2016-10-11 15:47 ` Stanislav Kholmanskikh
0 siblings, 1 reply; 19+ messages in thread
From: Cyril Hrubis @ 2016-10-11 13:38 UTC (permalink / raw)
To: ltp
Hi!
> 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 ~]$
Hmm, 36, really increased by 8 because of the one dd?
That sounds even more strange.
> [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?
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?
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-10-11 13:38 ` Cyril Hrubis
@ 2016-10-11 15:47 ` Stanislav Kholmanskikh
2016-10-11 16:15 ` Cyril Hrubis
0 siblings, 1 reply; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-10-11 15:47 UTC (permalink / raw)
To: ltp
On 10/11/2016 04:38 PM, Cyril Hrubis wrote:
> Hi!
>> 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 ~]$
>
> Hmm, 36, really increased by 8 because of the one dd?
>
> That sounds even more strange.
>
>> [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?
>
> 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.
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: parse a copy of /proc/modules
2016-10-11 15:47 ` Stanislav Kholmanskikh
@ 2016-10-11 16:15 ` Cyril Hrubis
2016-11-09 14:34 ` [LTP] [PATCH] lsmod01: keep the output in variables Stanislav Kholmanskikh
0 siblings, 1 reply; 19+ messages in thread
From: Cyril Hrubis @ 2016-10-11 16:15 UTC (permalink / raw)
To: ltp
Hi!
> > 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.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: keep the output in variables
2016-10-11 16:15 ` Cyril Hrubis
@ 2016-11-09 14:34 ` Stanislav Kholmanskikh
2016-11-09 16:49 ` Cyril Hrubis
0 siblings, 1 reply; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-11-09 14:34 UTC (permalink / raw)
To: ltp
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
---
> 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 <stanislav.kholmanskikh@oracle.com>
---
testcases/commands/lsmod/lsmod01.sh | 24 ++++++++++++++----------
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/testcases/commands/lsmod/lsmod01.sh b/testcases/commands/lsmod/lsmod01.sh
index 5cf2fee..cd19ca4 100755
--- a/testcases/commands/lsmod/lsmod01.sh
+++ b/testcases/commands/lsmod/lsmod01.sh
@@ -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
--
1.7.1
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: keep the output in variables
2016-11-09 14:34 ` [LTP] [PATCH] lsmod01: keep the output in variables Stanislav Kholmanskikh
@ 2016-11-09 16:49 ` Cyril Hrubis
2016-11-10 10:07 ` Stanislav Kholmanskikh
0 siblings, 1 reply; 19+ messages in thread
From: Cyril Hrubis @ 2016-11-09 16:49 UTC (permalink / raw)
To: ltp
> 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
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.
> return
> fi
>
> --
> 1.7.1
>
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: keep the output in variables
2016-11-09 16:49 ` Cyril Hrubis
@ 2016-11-10 10:07 ` Stanislav Kholmanskikh
2016-11-10 11:39 ` Cyril Hrubis
0 siblings, 1 reply; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-11-10 10:07 UTC (permalink / raw)
To: ltp
On 11/09/2016 07:49 PM, Cyril Hrubis wrote:
>> 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
>
> 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.
>
> 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.
>
>> return
>> fi
>>
>> --
>> 1.7.1
>>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: keep the output in variables
2016-11-10 10:07 ` Stanislav Kholmanskikh
@ 2016-11-10 11:39 ` Cyril Hrubis
2016-11-10 14:15 ` Stanislav Kholmanskikh
0 siblings, 1 reply; 19+ messages in thread
From: Cyril Hrubis @ 2016-11-10 11:39 UTC (permalink / raw)
To: ltp
Hi!
> > 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.
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.
--
Cyril Hrubis
chrubis@suse.cz
^ permalink raw reply [flat|nested] 19+ messages in thread
* [LTP] [PATCH] lsmod01: keep the output in variables
2016-11-10 11:39 ` Cyril Hrubis
@ 2016-11-10 14:15 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 19+ messages in thread
From: Stanislav Kholmanskikh @ 2016-11-10 14:15 UTC (permalink / raw)
To: ltp
On 11/10/2016 02:39 PM, Cyril Hrubis wrote:
> Hi!
>>> 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.
>
> 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.
Thank you. Pushed.
>
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2016-11-10 14:15 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-29 11:08 [LTP] [PATCH] lsmod01: parse a copy of /proc/modules Stanislav Kholmanskikh
2016-08-29 12:50 ` Cyril Hrubis
2016-08-29 13:05 ` Stanislav Kholmanskikh
2016-08-29 13:34 ` Jan Stancek
2016-08-29 14:00 ` Stanislav Kholmanskikh
2016-08-29 14:03 ` Stanislav Kholmanskikh
2016-08-29 15:17 ` Cyril Hrubis
2016-08-29 15:49 ` Jan Stancek
2016-10-11 12:03 ` Stanislav Kholmanskikh
2016-10-11 13:38 ` Cyril Hrubis
2016-10-11 15:47 ` Stanislav Kholmanskikh
2016-10-11 16:15 ` Cyril Hrubis
2016-11-09 14:34 ` [LTP] [PATCH] lsmod01: keep the output in variables Stanislav Kholmanskikh
2016-11-09 16:49 ` Cyril Hrubis
2016-11-10 10:07 ` Stanislav Kholmanskikh
2016-11-10 11:39 ` Cyril Hrubis
2016-11-10 14:15 ` Stanislav Kholmanskikh
2016-08-31 13:55 ` [LTP] [PATCH] lsmod01: parse a copy of /proc/modules Cyril Hrubis
2016-09-02 14:12 ` Stanislav Kholmanskikh
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.