[libgpiod][PATCH] tools: tests: replace egrep with grep -E

[libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Bartosz Golaszewski]

From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>

Since version 3.11 egrep emits the following warning to stderr on startup:

  egrep: warning: egrep is obsolescent; using grep -E

This makes the tests fail (though that seems to depend on BATS version)
so replace egrep with grep -E as suggested.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
 tools/gpio-tools-test      | 2 +-
 tools/gpio-tools-test.bats | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/gpio-tools-test b/tools/gpio-tools-test
index 5b6c72e..ed39ed5 100755
--- a/tools/gpio-tools-test
+++ b/tools/gpio-tools-test
@@ -37,7 +37,7 @@ check_prog() {
 check_prog bats
 check_prog modprobe
 check_prog timeout
-check_prog egrep
+check_prog grep
 
 # Check if we're running a kernel at the required version or later
 check_kernel $MIN_KERNEL_VERSION
diff --git a/tools/gpio-tools-test.bats b/tools/gpio-tools-test.bats
index adbce94..c83ca7d 100755
--- a/tools/gpio-tools-test.bats
+++ b/tools/gpio-tools-test.bats
@@ -154,7 +154,7 @@ gpiosim_cleanup() {
 		ls $BANKPATH/line* > /dev/null 2>&1
 		if [ "$?" = "0" ]
 		then
-			for LINE in $(find $BANKPATH/ | egrep "line[0-9]+$")
+			for LINE in $(find $BANKPATH/ | grep -E "line[0-9]+$")
 			do
 				test -e $LINE/hog && rmdir $LINE/hog
 				rmdir $LINE
-- 
2.39.2

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Kent Gibson]

On Thu, Jun 01, 2023 at 04:09:50PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> 
> Since version 3.11 egrep emits the following warning to stderr on startup:
> 
>   egrep: warning: egrep is obsolescent; using grep -E
> 
> This makes the tests fail (though that seems to depend on BATS version)
> so replace egrep with grep -E as suggested.
> 

That works for me, so I don't have any objections.

Though FWIW, my global sim cleanup script looks like:

find /sys/kernel/config/gpio-sim -type d -name hog -print0 2>/dev/null | xargs -0 -r rmdir
find /sys/kernel/config/gpio-sim -type d -name "line*" -print0  2>/dev/null | xargs -0 -r rmdir
find /sys/kernel/config/gpio-sim -type d -name "bank*" -print0 2>/dev/null | xargs -0 -r rmdir
rmdir /sys/kernel/config/gpio-sim/*

So no grep at all, just find and xargs.
That is for all sims, but could easily be reduced to a particular sim,
given the sim name.

Setting live to 0 seems to be optional - deleting everything works fine
for me.

Cheers,
Kent.

> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
>  tools/gpio-tools-test      | 2 +-
>  tools/gpio-tools-test.bats | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/gpio-tools-test b/tools/gpio-tools-test
> index 5b6c72e..ed39ed5 100755
> --- a/tools/gpio-tools-test
> +++ b/tools/gpio-tools-test
> @@ -37,7 +37,7 @@ check_prog() {
>  check_prog bats
>  check_prog modprobe
>  check_prog timeout
> -check_prog egrep
> +check_prog grep
>  
>  # Check if we're running a kernel at the required version or later
>  check_kernel $MIN_KERNEL_VERSION
> diff --git a/tools/gpio-tools-test.bats b/tools/gpio-tools-test.bats
> index adbce94..c83ca7d 100755
> --- a/tools/gpio-tools-test.bats
> +++ b/tools/gpio-tools-test.bats
> @@ -154,7 +154,7 @@ gpiosim_cleanup() {
>  		ls $BANKPATH/line* > /dev/null 2>&1
>  		if [ "$?" = "0" ]
>  		then
> -			for LINE in $(find $BANKPATH/ | egrep "line[0-9]+$")
> +			for LINE in $(find $BANKPATH/ | grep -E "line[0-9]+$")
>  			do
>  				test -e $LINE/hog && rmdir $LINE/hog
>  				rmdir $LINE
> -- 
> 2.39.2
> 

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Andy Shevchenko]

On Thu, Jun 01, 2023 at 10:28:22PM +0800, Kent Gibson wrote:
> On Thu, Jun 01, 2023 at 04:09:50PM +0200, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > 
> > Since version 3.11 egrep emits the following warning to stderr on startup:
> > 
> >   egrep: warning: egrep is obsolescent; using grep -E
> > 
> > This makes the tests fail (though that seems to depend on BATS version)
> > so replace egrep with grep -E as suggested.
> > 
> 
> That works for me, so I don't have any objections.
> 
> Though FWIW, my global sim cleanup script looks like:
> 
> find /sys/kernel/config/gpio-sim -type d -name hog -print0 2>/dev/null | xargs -0 -r rmdir
> find /sys/kernel/config/gpio-sim -type d -name "line*" -print0  2>/dev/null | xargs -0 -r rmdir
> find /sys/kernel/config/gpio-sim -type d -name "bank*" -print0 2>/dev/null | xargs -0 -r rmdir
> rmdir /sys/kernel/config/gpio-sim/*
> 
> So no grep at all, just find and xargs.

Maybe you can even use -exec... :-)
But I don't remember if it forks for each entry (and I don't remember by heart
what -r does for xargs, which usually adds as many parameters as possible to
the command line of the calling tool).

> That is for all sims, but could easily be reduced to a particular sim,
> given the sim name.
> 
> Setting live to 0 seems to be optional - deleting everything works fine
> for me.

-- 
With Best Regards,
Andy Shevchenko

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Kent Gibson]

On Thu, Jun 01, 2023 at 07:58:29PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 01, 2023 at 10:28:22PM +0800, Kent Gibson wrote:
> > On Thu, Jun 01, 2023 at 04:09:50PM +0200, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> > > 
> > > Since version 3.11 egrep emits the following warning to stderr on startup:
> > > 
> > >   egrep: warning: egrep is obsolescent; using grep -E
> > > 
> > > This makes the tests fail (though that seems to depend on BATS version)
> > > so replace egrep with grep -E as suggested.
> > > 
> > 
> > That works for me, so I don't have any objections.
> > 
> > Though FWIW, my global sim cleanup script looks like:
> > 
> > find /sys/kernel/config/gpio-sim -type d -name hog -print0 2>/dev/null | xargs -0 -r rmdir
> > find /sys/kernel/config/gpio-sim -type d -name "line*" -print0  2>/dev/null | xargs -0 -r rmdir
> > find /sys/kernel/config/gpio-sim -type d -name "bank*" -print0 2>/dev/null | xargs -0 -r rmdir
> > rmdir /sys/kernel/config/gpio-sim/*
> > 
> > So no grep at all, just find and xargs.
> 
> Maybe you can even use -exec... :-)
> But I don't remember if it forks for each entry (and I don't remember by heart
> what -r does for xargs, which usually adds as many parameters as possible to
> the command line of the calling tool).
>

You can indeed.  The basic form execs for each file, but the '+' form
execs on the set, which is preferable in this case.

And the redirect is a hangover from a different form I was using
previously, so that isn't necessary either.

So

SIMDIR="/sys/kernel/config/gpio-sim/"
find $SIMDIR -type d -name hog -exec rmdir '{}' '+'
find $SIMDIR -type d -name "line*" -exec rmdir '{}' '+'
find $SIMDIR -type d -name "bank*" -exec rmdir '{}' '+'
rmdir $SIMDIR/*

is working for me.

On a related(??) note, I'm occasionally seeing Oopses when testing this
- when creating a basic sim with a shell script, not when deleting it.
In one case after a fresh reboot and on creating the first sim, so it
looks to be purely the construction.  Yay :-(.

Not sure if this is in anyway related to the other weirdness I've been
experiencing lately.  Wouldn't surprise me.

The aforementioned Oops:

Jun  2 09:49:58 firefly kernel: [  612.194725] gpio-522 (hogster): hogged as input
Jun  2 09:49:58 firefly kernel: [  612.194729] gpio-528 (breath): hogged as output/low
Jun  2 09:49:58 firefly kernel: [  612.213120] BUG: kernel NULL pointer dereference, address: 0000000000000080
Jun  2 09:49:58 firefly kernel: [  612.213436] #PF: supervisor read access in kernel mode
Jun  2 09:49:58 firefly kernel: [  612.213668] #PF: error_code(0x0000) - not-present page
Jun  2 09:49:58 firefly kernel: [  612.213899] PGD 800000015b18b067 P4D 800000015b18b067 PUD 102095067 PMD 0
Jun  2 09:49:58 firefly kernel: [  612.214193] Oops: 0000 [#1] PREEMPT SMP PTI
Jun  2 09:49:58 firefly kernel: [  612.214391] CPU: 3 PID: 25493 Comm: cc1 Not tainted 6.4.0-rc3 #22
Jun  2 09:49:58 firefly kernel: [  612.214657] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
Jun  2 09:49:58 firefly kernel: [  612.215049] RIP: 0010:anon_vma_interval_tree_insert+0xd/0xc0
Jun  2 09:49:58 firefly kernel: [  612.215371] Code: 48 8d 70 c0 eb b5 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 17 49 89 f8 49 89 f2 4d 8d 58 20 <48> 8b ba 80 00 00 00 48 8b 42 08 48 2b 02 48 c1 e8 0c 48 8d 74 07
Jun  2 09:49:58 firefly kernel: [  612.216127] RSP: 0018:ffff92138079fcc8 EFLAGS: 00010202
Jun  2 09:49:58 firefly kernel: [  612.216391] RAX: ffff8fb784053bc8 RBX: ffff92138079fd00 RCX: 000000008010000c
Jun  2 09:49:58 firefly kernel: [  612.216692] RDX: 0000000000000000 RSI: ffff8fb784053c18 RDI: ffff8fb747e7d400
Jun  2 09:49:58 firefly kernel: [  612.216991] RBP: ffff8fb747e7d400 R08: ffff8fb747e7d400 R09: ffffffffa9624c00
Jun  2 09:49:58 firefly kernel: [  612.217289] R10: ffff8fb784053c18 R11: ffff8fb747e7d420 R12: ffff8fb743699c80
Jun  2 09:49:58 firefly kernel: [  612.217589] R13: ffff8fb77fd19f78 R14: 00007fd1a0a99000 R15: 00000007fd1a0a93
Jun  2 09:49:58 firefly kernel: [  612.217891] FS:  00007fd1a0d81ac0(0000) GS:ffff8fb7d9d80000(0000) knlGS:0000000000000000
Jun  2 09:49:58 firefly kernel: [  612.218224] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun  2 09:49:58 firefly kernel: [  612.218531] CR2: 0000000000000080 CR3: 000000013ff40000 CR4: 00000000000006e0
Jun  2 09:49:58 firefly kernel: [  612.218883] Call Trace:
Jun  2 09:49:58 firefly kernel: [  612.219086]  <TASK>
Jun  2 09:49:58 firefly kernel: [  612.219264]  vma_complete+0xba/0x270
Jun  2 09:49:58 firefly kernel: [  612.219496]  vma_expand+0x116/0x190
Jun  2 09:49:58 firefly kernel: [  612.219722]  mmap_region+0x781/0x9d0
Jun  2 09:49:58 firefly kernel: [  612.219974]  ? arch_get_unmapped_area_topdown+0xf6/0x230
Jun  2 09:49:58 firefly kernel: [  612.220274]  do_mmap+0x3ad/0x5d0
Jun  2 09:49:58 firefly kernel: [  612.220492]  vm_mmap_pgoff+0xd8/0x180
Jun  2 09:49:58 firefly kernel: [  612.220726]  do_syscall_64+0x3b/0x90
Jun  2 09:49:58 firefly kernel: [  612.220965]  entry_SYSCALL_64_after_hwframe+0x72/0xdc
Jun  2 09:49:58 firefly kernel: [  612.221247] RIP: 0033:0x7fd1a0e790d2
Jun  2 09:49:58 firefly kernel: [  612.221477] Code: e4 e8 62 64 01 00 66 90 41 f7 c1 ff 0f 00 00 75 27 55 48 89 fd 53 89 cb 48 85 ff 74 3b 41 89 da 48 89 ef b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 66 5b 5d c3 0f 1f 00 48 8b 05 89 8d 0d 00 64
Jun  2 09:49:58 firefly kernel: [  612.222340] RSP: 002b:00007fff20f0a398 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
Jun  2 09:49:58 firefly kernel: [  612.222759] RAX: ffffffffffffffda RBX: 0000000000000022 RCX: 00007fd1a0e790d2
Jun  2 09:49:58 firefly kernel: [  612.223111] RDX: 0000000000000003 RSI: 0000000000002000 RDI: 0000000000000000
Jun  2 09:49:58 firefly kernel: [  612.223463] RBP: 0000000000000000 R08: 00000000ffffffff R09: 0000000000000000
Jun  2 09:49:58 firefly kernel: [  612.223817] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000002000
Jun  2 09:49:58 firefly kernel: [  612.224195] R13: 0000000000000000 R14: 0000000000002000 R15: 000000000000000d
Jun  2 09:49:58 firefly kernel: [  612.224550]  </TASK>
Jun  2 09:49:58 firefly kernel: [  612.224728] Modules linked in: gpio_sim configfs
Jun  2 09:49:58 firefly kernel: [  612.224994] CR2: 0000000000000080
Jun  2 09:49:58 firefly kernel: [  612.225713] ---[ end trace 0000000000000000 ]---
Jun  2 09:49:58 firefly kernel: [  612.226407] RIP: 0010:anon_vma_interval_tree_insert+0xd/0xc0
Jun  2 09:49:58 firefly kernel: [  612.226912] Code: 48 8d 70 c0 eb b5 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 8b 17 49 89 f8 49 89 f2 4d 8d 58 20 <48> 8b ba 80 00 00 00 48 8b 42 08 48 2b 02 48 c1 e8 0c 48 8d 74 07
Jun  2 09:49:58 firefly kernel: [  612.228179] RSP: 0018:ffff92138079fcc8 EFLAGS: 00010202
Jun  2 09:49:58 firefly kernel: [  612.228464] RAX: ffff8fb784053bc8 RBX: ffff92138079fd00 RCX: 000000008010000c
Jun  2 09:49:58 firefly kernel: [  612.228815] RDX: 0000000000000000 RSI: ffff8fb784053c18 RDI: ffff8fb747e7d400
Jun  2 09:49:58 firefly kernel: [  612.229199] RBP: ffff8fb747e7d400 R08: ffff8fb747e7d400 R09: ffffffffa9624c00
Jun  2 09:49:58 firefly kernel: [  612.229555] R10: ffff8fb784053c18 R11: ffff8fb747e7d420 R12: ffff8fb743699c80
Jun  2 09:49:58 firefly kernel: [  612.229917] R13: ffff8fb77fd19f78 R14: 00007fd1a0a99000 R15: 00000007fd1a0a93
Jun  2 09:49:58 firefly kernel: [  612.230285] FS:  00007fd1a0d81ac0(0000) GS:ffff8fb7d9d80000(0000) knlGS:0000000000000000
Jun  2 09:49:58 firefly kernel: [  612.230733] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun  2 09:49:58 firefly kernel: [  612.231040] CR2: 0000000000000080 CR3: 000000013ff40000 CR4: 00000000000006e0

Not sure where to go with that.  Will take another look at it later
unless someone can see something obvious that I'm missing.

Cheers,
Kent.

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Kent Gibson]

On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote:
> 
> On a related(??) note, I'm occasionally seeing Oopses when testing this
> - when creating a basic sim with a shell script, not when deleting it.
> In one case after a fresh reboot and on creating the first sim, so it
> looks to be purely the construction.  Yay :-(.
> 

I had thought it would be difficult to reproduce this and so difficult
to bisect.  Fortunately(??) not.  If I run my setup and cleanup scripts[1]
in a tight loop it occurs very readily.  Haven't bisected it yet, but did
test it on 6.1-rc1 and it Oopsed there too, so I would need to go back
further.  What was the initial release containing gpio-sim?

The sim setp is pretty simple - a couple of banks each with a few lines
and hogs.

Could you confirm that you can repeat the problem?
Otherwise I might start thinking there is something broken in my test
environment.

Btw, the loop script is:

#!/bin/env bash
for (( ; ; ))
do
	echo "create sim..."
	./basic_sim.sh
	echo "destroy sim..."
	./clean_sims.sh
done

Cheers,
Kent.
[1] https://github.com/warthog618/gpiosim-rs

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Bartosz Golaszewski]

On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote:
> >
> > On a related(??) note, I'm occasionally seeing Oopses when testing this
> > - when creating a basic sim with a shell script, not when deleting it.
> > In one case after a fresh reboot and on creating the first sim, so it
> > looks to be purely the construction.  Yay :-(.
> >
>
> I had thought it would be difficult to reproduce this and so difficult
> to bisect.  Fortunately(??) not.  If I run my setup and cleanup scripts[1]
> in a tight loop it occurs very readily.  Haven't bisected it yet, but did
> test it on 6.1-rc1 and it Oopsed there too, so I would need to go back
> further.  What was the initial release containing gpio-sim?
>
> The sim setp is pretty simple - a couple of banks each with a few lines
> and hogs.
>
> Could you confirm that you can repeat the problem?
> Otherwise I might start thinking there is something broken in my test
> environment.
>
> Btw, the loop script is:
>
> #!/bin/env bash
> for (( ; ; ))
> do
>         echo "create sim..."
>         ./basic_sim.sh
>         echo "destroy sim..."
>         ./clean_sims.sh
> done
>
> Cheers,
> Kent.
> [1] https://github.com/warthog618/gpiosim-rs
>

With this script I've been able to trigger an issue but it looks
different from yours: https://pastebin.com/cbsgT2ae

Bart

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Kent Gibson]

On Fri, Jun 02, 2023 at 03:10:18PM +0200, Bartosz Golaszewski wrote:
> On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote:
> > >
> > > On a related(??) note, I'm occasionally seeing Oopses when testing this
> > > - when creating a basic sim with a shell script, not when deleting it.
> > > In one case after a fresh reboot and on creating the first sim, so it
> > > looks to be purely the construction.  Yay :-(.
> > >
> >
> > I had thought it would be difficult to reproduce this and so difficult
> > to bisect.  Fortunately(??) not.  If I run my setup and cleanup scripts[1]
> > in a tight loop it occurs very readily.  Haven't bisected it yet, but did
> > test it on 6.1-rc1 and it Oopsed there too, so I would need to go back
> > further.  What was the initial release containing gpio-sim?
> >
> > The sim setp is pretty simple - a couple of banks each with a few lines
> > and hogs.
> >
> > Could you confirm that you can repeat the problem?
> > Otherwise I might start thinking there is something broken in my test
> > environment.
> >
> > Btw, the loop script is:
> >
> > #!/bin/env bash
> > for (( ; ; ))
> > do
> >         echo "create sim..."
> >         ./basic_sim.sh
> >         echo "destroy sim..."
> >         ./clean_sims.sh
> > done
> >
> > Cheers,
> > Kent.
> > [1] https://github.com/warthog618/gpiosim-rs
> >
> 
> With this script I've been able to trigger an issue but it looks
> different from yours: https://pastebin.com/cbsgT2ae
> 

Looks similar to me.
I would assume that is the same issue - even if the  particulars of the
crash differ.  If you can fix that and my problem remains then we can be
sure they are distinct.

I've been doing a coarse bisect to see how far back this goes -
basically looking for a known good.
5.18 crashes, but it crashed hard, so no syslog.  It did run considerably
longer before crashing, so that could be different issue masked by the
other (later?) one.

Moving on to subsequent releases...

Cheers,
Kent.

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Bartosz Golaszewski]

On Fri, Jun 2, 2023 at 3:26 PM Kent Gibson <warthog618@gmail.com> wrote:
>
> On Fri, Jun 02, 2023 at 03:10:18PM +0200, Bartosz Golaszewski wrote:
> > On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote:
> > >
> > > On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote:
> > > >
> > > > On a related(??) note, I'm occasionally seeing Oopses when testing this
> > > > - when creating a basic sim with a shell script, not when deleting it.
> > > > In one case after a fresh reboot and on creating the first sim, so it
> > > > looks to be purely the construction.  Yay :-(.
> > > >
> > >
> > > I had thought it would be difficult to reproduce this and so difficult
> > > to bisect.  Fortunately(??) not.  If I run my setup and cleanup scripts[1]
> > > in a tight loop it occurs very readily.  Haven't bisected it yet, but did
> > > test it on 6.1-rc1 and it Oopsed there too, so I would need to go back
> > > further.  What was the initial release containing gpio-sim?
> > >
> > > The sim setp is pretty simple - a couple of banks each with a few lines
> > > and hogs.
> > >
> > > Could you confirm that you can repeat the problem?
> > > Otherwise I might start thinking there is something broken in my test
> > > environment.
> > >
> > > Btw, the loop script is:
> > >
> > > #!/bin/env bash
> > > for (( ; ; ))
> > > do
> > >         echo "create sim..."
> > >         ./basic_sim.sh
> > >         echo "destroy sim..."
> > >         ./clean_sims.sh
> > > done
> > >
> > > Cheers,
> > > Kent.
> > > [1] https://github.com/warthog618/gpiosim-rs
> > >
> >
> > With this script I've been able to trigger an issue but it looks
> > different from yours: https://pastebin.com/cbsgT2ae
> >
>
> Looks similar to me.
> I would assume that is the same issue - even if the  particulars of the
> crash differ.  If you can fix that and my problem remains then we can be
> sure they are distinct.
>
> I've been doing a coarse bisect to see how far back this goes -
> basically looking for a known good.
> 5.18 crashes, but it crashed hard, so no syslog.  It did run considerably
> longer before crashing, so that could be different issue masked by the
> other (later?) one.
>
> Moving on to subsequent releases...
>
> Cheers,
> Kent.

I managed to trigger a different crash: https://pastebin.com/6Gx29vHB

This one happened in gpio-sim:

$ ./scripts/faddr2line drivers/gpio/gpio-sim.o
gpio_sim_make_bank_swnode+0x12f/0x220
gpio_sim_make_bank_swnode+0x12f/0x220:
gpio_sim_make_line_names at
/home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:725
(inlined by) gpio_sim_make_bank_swnode at
/home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:837

But to me it looks like some memory corruption if the stack traces are
so random... Where is Rust when you need it? :)

Bart

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Kent Gibson]

On Fri, Jun 02, 2023 at 05:33:08PM +0200, Bartosz Golaszewski wrote:
> On Fri, Jun 2, 2023 at 3:26 PM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > On Fri, Jun 02, 2023 at 03:10:18PM +0200, Bartosz Golaszewski wrote:
> > > On Fri, Jun 2, 2023 at 12:34 PM Kent Gibson <warthog618@gmail.com> wrote:
> > > >
> > > > On Fri, Jun 02, 2023 at 10:13:35AM +0800, Kent Gibson wrote:
> > > > >
> > > > > On a related(??) note, I'm occasionally seeing Oopses when testing this
> > > > > - when creating a basic sim with a shell script, not when deleting it.
> > > > > In one case after a fresh reboot and on creating the first sim, so it
> > > > > looks to be purely the construction.  Yay :-(.
> > > > >
> > > >
> > > > I had thought it would be difficult to reproduce this and so difficult
> > > > to bisect.  Fortunately(??) not.  If I run my setup and cleanup scripts[1]
> > > > in a tight loop it occurs very readily.  Haven't bisected it yet, but did
> > > > test it on 6.1-rc1 and it Oopsed there too, so I would need to go back
> > > > further.  What was the initial release containing gpio-sim?
> > > >
> > > > The sim setp is pretty simple - a couple of banks each with a few lines
> > > > and hogs.
> > > >
> > > > Could you confirm that you can repeat the problem?
> > > > Otherwise I might start thinking there is something broken in my test
> > > > environment.
> > > >
> > > > Btw, the loop script is:
> > > >
> > > > #!/bin/env bash
> > > > for (( ; ; ))
> > > > do
> > > >         echo "create sim..."
> > > >         ./basic_sim.sh
> > > >         echo "destroy sim..."
> > > >         ./clean_sims.sh
> > > > done
> > > >
> > > > Cheers,
> > > > Kent.
> > > > [1] https://github.com/warthog618/gpiosim-rs
> > > >
> > >
> > > With this script I've been able to trigger an issue but it looks
> > > different from yours: https://pastebin.com/cbsgT2ae
> > >
> >
> > Looks similar to me.
> > I would assume that is the same issue - even if the  particulars of the
> > crash differ.  If you can fix that and my problem remains then we can be
> > sure they are distinct.
> >
> > I've been doing a coarse bisect to see how far back this goes -
> > basically looking for a known good.
> > 5.18 crashes, but it crashed hard, so no syslog.  It did run considerably
> > longer before crashing, so that could be different issue masked by the
> > other (later?) one.
> >
> > Moving on to subsequent releases...
> >
> > Cheers,
> > Kent.
> 
> I managed to trigger a different crash: https://pastebin.com/6Gx29vHB
> 
> This one happened in gpio-sim:
> 
> $ ./scripts/faddr2line drivers/gpio/gpio-sim.o
> gpio_sim_make_bank_swnode+0x12f/0x220
> gpio_sim_make_bank_swnode+0x12f/0x220:
> gpio_sim_make_line_names at
> /home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:725
> (inlined by) gpio_sim_make_bank_swnode at
> /home/brgl/workspace/yocto-gpio-sim-crash/build/linux/drivers/gpio/gpio-sim.c:837
> 
> But to me it looks like some memory corruption if the stack traces are
> so random... Where is Rust when you need it? :)
> 

Makes sense.  I'm seeing different behaviour from differnet releases,
so there may be multiple issues here, and some may've been fixed or
introduced at different points.
Or, as you suggest, it could be a corruption that just exhibits
differently depending on what ends up getting corrupted.
Either way, bisecting this is problematic.

e.g.
5.18 crashed hard after a while.
5.19 ran for quite a while - but then crashed when I killed the script.
6.0 behaved similar to 5.19.
6.1 looks to be where the current issue was introduced - that fails
almost immediately.
6.2 crashed hard.
6.3 failed fast like 6.1.

TBH, haven't been paying much attention to the crash details - for the
most part the backtraces are a pretty generic syscall fell in a heap as
a pointer somewhere was null.

Not sure I'm being much help with this one.
Anything specific you want me to try?
Otherwise I'll leave you to it until you do.

One other thing - is it necessary for gpio-sim to log hogs?

Jun  2 23:45:13 firefly kernel: [   39.539144] gpio-522 (hog2): hogged as input
Jun  2 23:45:13 firefly kernel: [   39.539152] gpio-528 (hog3): hogged as output/low
Jun  2 23:45:13 firefly kernel: [   39.600144] gpio-513 (hog1): hogged as output/high
Jun  2 23:45:13 firefly kernel: [   39.600365] gpio-522 (hog2): hogged as input
Jun  2 23:45:13 firefly kernel: [   39.600372] gpio-528 (hog3): hogged as output/low
Jun  2 23:45:13 firefly kernel: [   39.649662] gpio-513 (hog1): hogged as output/high
Jun  2 23:45:13 firefly kernel: [   39.650558] gpio-522 (hog2): hogged as input

For the long running cases this results in a lot of logging, which could
be causing issues in itself, and further muddying the waters.

Cheers,
Kent.

Re: [libgpiod][PATCH] tools: tests: replace egrep with grep -E

[Kent Gibson]

On Sat, Jun 03, 2023 at 12:07:40AM +0800, Kent Gibson wrote:
> 
> One other thing - is it necessary for gpio-sim to log hogs?
> 
> For the long running cases this results in a lot of logging, which could
> be causing issues in itself, and further muddying the waters.
> 

Ah, I've been looking at bisecting the problem the wrong way.
I should've been bisecting the trigger condition.
If I remove the hogs from the basic_sim then the test doesn't fail.

It also explains why I haven't been seeing this more often - most of my
tests don't include hogs. Only the info tests use hogs, the rest just
use bare sims with no named lines or hogs (aka simpletons).

Does that help isolate the root cause?

Cheers,
Kent.