* [PATCH] generic/310: slightly improve check for dmesg error
@ 2020-03-17 1:54 Paulo Alcantara (SUSE)
2020-03-17 10:55 ` Zorro Lang
0 siblings, 1 reply; 4+ messages in thread
From: Paulo Alcantara (SUSE) @ 2020-03-17 1:54 UTC (permalink / raw)
To: fstests; +Cc: Paulo Alcantara (SUSE)
The 'grep -c "error"' check was causing false positive results for
cifs.ko when running it with 'echo 1 > /proc/fs/cifs/cifsFYI'.
That is, the test would fail when cifs.ko prints out a non-error
message like this:
[ 2320.903987] fs/cifs/smb2maperror.c: Mapping SMB2 status code
0x80000006 to POSIX err -61
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
---
tests/generic/310 | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/generic/310 b/tests/generic/310
index 1fcd517e4e6f..504f7c44c177 100755
--- a/tests/generic/310
+++ b/tests/generic/310
@@ -49,7 +49,7 @@ _require_command "$KILLALL_PROG" killall
dmesg -c > /dev/null
nr_bug=`dmesg | grep -c "kernel BUG"`
-nr_error=`dmesg | grep -c "error"`
+nr_error=`dmesg | grep -c "EXT[234]-fs error"`
nr_null=`dmesg | grep -c "kernel NULL pointer dereference"`
nr_warning=`dmesg | grep -c "^WARNING"`
nr_lockdep=`dmesg | grep -c "possible recursive locking detected"`
@@ -58,7 +58,7 @@ nr_lockdep=`dmesg | grep -c "possible recursive locking detected"`
check_kernel_bug()
{
new_bug=`dmesg | grep -c "kernel BUG"`
- new_error=`dmesg | grep -c "error"`
+ new_error=`dmesg | grep -c "EXT[234]-fs error"`
new_null=`dmesg | grep -c "kernel NULL pointer dereference"`
new_warning=`dmesg | grep -c "^WARNING"`
new_lockdep=`dmesg | grep -c "possible recursive locking detected"`
--
2.25.1
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH] generic/310: slightly improve check for dmesg error
2020-03-17 1:54 [PATCH] generic/310: slightly improve check for dmesg error Paulo Alcantara (SUSE)
@ 2020-03-17 10:55 ` Zorro Lang
2020-03-17 15:23 ` Paulo Alcantara
0 siblings, 1 reply; 4+ messages in thread
From: Zorro Lang @ 2020-03-17 10:55 UTC (permalink / raw)
To: Paulo Alcantara (SUSE); +Cc: fstests
On Mon, Mar 16, 2020 at 10:54:39PM -0300, Paulo Alcantara (SUSE) wrote:
> The 'grep -c "error"' check was causing false positive results for
> cifs.ko when running it with 'echo 1 > /proc/fs/cifs/cifsFYI'.
>
> That is, the test would fail when cifs.ko prints out a non-error
> message like this:
>
> [ 2320.903987] fs/cifs/smb2maperror.c: Mapping SMB2 status code
> 0x80000006 to POSIX err -61
>
> Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
> ---
> tests/generic/310 | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/generic/310 b/tests/generic/310
> index 1fcd517e4e6f..504f7c44c177 100755
> --- a/tests/generic/310
> +++ b/tests/generic/310
> @@ -49,7 +49,7 @@ _require_command "$KILLALL_PROG" killall
> dmesg -c > /dev/null
>
> nr_bug=`dmesg | grep -c "kernel BUG"`
> -nr_error=`dmesg | grep -c "error"`
> +nr_error=`dmesg | grep -c "EXT[234]-fs error"`
This's a generic test, which is not only for extN filesystem. If only for
"fs/cifs/smb2maperror.c: Mapping SMB2 status ...", how about:
grep -wc "error"
or
grep -c "\berror"
or something better:)
I think it still works for "EXT3-fs error (device loop1): ext3_readdir:
bad entry in ....".
Thanks,
Zorro
> nr_null=`dmesg | grep -c "kernel NULL pointer dereference"`
> nr_warning=`dmesg | grep -c "^WARNING"`
> nr_lockdep=`dmesg | grep -c "possible recursive locking detected"`
> @@ -58,7 +58,7 @@ nr_lockdep=`dmesg | grep -c "possible recursive locking detected"`
> check_kernel_bug()
> {
> new_bug=`dmesg | grep -c "kernel BUG"`
> - new_error=`dmesg | grep -c "error"`
> + new_error=`dmesg | grep -c "EXT[234]-fs error"`
> new_null=`dmesg | grep -c "kernel NULL pointer dereference"`
> new_warning=`dmesg | grep -c "^WARNING"`
> new_lockdep=`dmesg | grep -c "possible recursive locking detected"`
> --
> 2.25.1
>
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH] generic/310: slightly improve check for dmesg error
2020-03-17 10:55 ` Zorro Lang
@ 2020-03-17 15:23 ` Paulo Alcantara
2020-03-18 2:10 ` Eryu Guan
0 siblings, 1 reply; 4+ messages in thread
From: Paulo Alcantara @ 2020-03-17 15:23 UTC (permalink / raw)
To: Zorro Lang, Eryu Guan; +Cc: fstests
Zorro Lang <zlang@redhat.com> writes:
> On Mon, Mar 16, 2020 at 10:54:39PM -0300, Paulo Alcantara (SUSE) wrote:
>> The 'grep -c "error"' check was causing false positive results for
>> cifs.ko when running it with 'echo 1 > /proc/fs/cifs/cifsFYI'.
>>
>> That is, the test would fail when cifs.ko prints out a non-error
>> message like this:
>>
>> [ 2320.903987] fs/cifs/smb2maperror.c: Mapping SMB2 status code
>> 0x80000006 to POSIX err -61
>>
>> Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
>> ---
>> tests/generic/310 | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/generic/310 b/tests/generic/310
>> index 1fcd517e4e6f..504f7c44c177 100755
>> --- a/tests/generic/310
>> +++ b/tests/generic/310
>> @@ -49,7 +49,7 @@ _require_command "$KILLALL_PROG" killall
>> dmesg -c > /dev/null
>>
>> nr_bug=`dmesg | grep -c "kernel BUG"`
>> -nr_error=`dmesg | grep -c "error"`
>> +nr_error=`dmesg | grep -c "EXT[234]-fs error"`
>
> This's a generic test, which is not only for extN filesystem. If only for
> "fs/cifs/smb2maperror.c: Mapping SMB2 status ...", how about:
> grep -wc "error"
> or
> grep -c "\berror"
>
> or something better:)
>
> I think it still works for "EXT3-fs error (device loop1): ext3_readdir:
> bad entry in ....".
Both look good to me. Thanks for pointing it out!
Eryu,
Do you want me to resend or you can just apply one of above suggestions?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] generic/310: slightly improve check for dmesg error
2020-03-17 15:23 ` Paulo Alcantara
@ 2020-03-18 2:10 ` Eryu Guan
0 siblings, 0 replies; 4+ messages in thread
From: Eryu Guan @ 2020-03-18 2:10 UTC (permalink / raw)
To: Paulo Alcantara; +Cc: Zorro Lang, Eryu Guan, fstests
On Tue, Mar 17, 2020 at 12:23:38PM -0300, Paulo Alcantara wrote:
> Zorro Lang <zlang@redhat.com> writes:
>
> > On Mon, Mar 16, 2020 at 10:54:39PM -0300, Paulo Alcantara (SUSE) wrote:
> >> The 'grep -c "error"' check was causing false positive results for
> >> cifs.ko when running it with 'echo 1 > /proc/fs/cifs/cifsFYI'.
> >>
> >> That is, the test would fail when cifs.ko prints out a non-error
> >> message like this:
> >>
> >> [ 2320.903987] fs/cifs/smb2maperror.c: Mapping SMB2 status code
> >> 0x80000006 to POSIX err -61
> >>
> >> Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
> >> ---
> >> tests/generic/310 | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/tests/generic/310 b/tests/generic/310
> >> index 1fcd517e4e6f..504f7c44c177 100755
> >> --- a/tests/generic/310
> >> +++ b/tests/generic/310
> >> @@ -49,7 +49,7 @@ _require_command "$KILLALL_PROG" killall
> >> dmesg -c > /dev/null
> >>
> >> nr_bug=`dmesg | grep -c "kernel BUG"`
> >> -nr_error=`dmesg | grep -c "error"`
> >> +nr_error=`dmesg | grep -c "EXT[234]-fs error"`
> >
> > This's a generic test, which is not only for extN filesystem. If only for
> > "fs/cifs/smb2maperror.c: Mapping SMB2 status ...", how about:
> > grep -wc "error"
> > or
> > grep -c "\berror"
> >
> > or something better:)
> >
> > I think it still works for "EXT3-fs error (device loop1): ext3_readdir:
> > bad entry in ....".
>
> Both look good to me. Thanks for pointing it out!
>
> Eryu,
>
> Do you want me to resend or you can just apply one of above suggestions?
This change seems easy enough, I can fix it on commit. Thanks!
Eryu
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-18 2:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-17 1:54 [PATCH] generic/310: slightly improve check for dmesg error Paulo Alcantara (SUSE)
2020-03-17 10:55 ` Zorro Lang
2020-03-17 15:23 ` Paulo Alcantara
2020-03-18 2:10 ` Eryu Guan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).