* [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 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
* [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
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.