Re: [PATCH net-next 2/4] selftests: drv-net: add a way to wait for a local process

Joe Damato
2025-02-20T17:45:56Z

On Wed, Feb 19, 2025 at 02:48:44PM -0800, Jakub Kicinski wrote:
> On Wed, 19 Feb 2025 13:39:51 -0500 Joe Damato wrote:
> > On Tue, Feb 18, 2025 at 03:05:12PM -0800, Jakub Kicinski wrote:
> > > On Tue, 18 Feb 2025 16:52:39 -0500 Joe Damato wrote:

[...]

> <snip>
> > [pid 448278] 18:27:15 kill(448303, SIGTERM) = 0
> > [...]
> > [pid 448303] 18:27:15 +++ killed by SIGTERM +++
> >
> > But pid 448304 is xdp_helper, which is still running and should be
> > the one to get the TERM.
>
> Very interesting. I dug deeper into this, and it turns out its shell
> dependent. I'm guessing you're using one of the cool shells, I use
> bash. bash does a direct exec for "sh -c X", other shells fork first.

I am using bash, as well. The version comes with Ubuntu 24.04.1:

GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)

I wonder if it's something about the environment that causes bash to
act this on my machine and NIPA but not yours?

> I'll add a warning in bkg() for combining shell=True and terminate=True.
>
> > I have no idea why this would be different on your system vs mine.
> > Maybe something changed with Python between Python versions?
>
> More digging still necessary here, as NIPA also runs on bash.
> So your problem is different than NIPA's.
> NIPA runs:
>
> make -C tools/testing/selftests TARGETS="drivers/net" \
> TEST_PROGS=queues.py TEST_GEN_PROGS="" run_tests
>
> which runs thru a layer of perl for output prefixing:
>
> tools/testing/selftests/kselftest/prefix.pl
>
> which in turn send a SIGTTIN when we call read(), and hangs the helper.
>
> > > We shall find out if NIPA agrees with my local system at 4p.
> >
> > Sorry for the noob question, but is there a NIPA url or something I
> > can look at to see if this worked / if future tests I submit work?
>
> https://netdev.bots.linux.dev/status.html
>
> With the disclaimer that we discourage people from looking at it.
> It tests everything on the list combined, we can't support the
> corporate "try until CI is green" development model. Not that
> I'd accuse you of such practices :)

Yea I wasn't sure what the right process is for selftests; the ones
I've hacked on or written I've run locally until they passed, but I
suppose it is possible that in cases like this upstream CI will fail
for some reason or another.