From: Joe Damato <jdamato@fastly.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch, horms@kernel.org,
shuah@kernel.org, hawk@kernel.org, petrm@nvidia.com,
willemdebruijn.kernel@gmail.com
Subject: Re: [PATCH net-next 2/4] selftests: drv-net: add a way to wait for a local process
Date: Thu, 20 Feb 2025 12:45:53 -0500 [thread overview]
Message-ID: <Z7dqUfPc2N8LZgJz@LQ3V64L9R2> (raw)
In-Reply-To: <20250219144844.1206b1fc@kernel.org>
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.
next prev parent reply other threads:[~2025-02-20 17:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-18 19:50 [PATCH net-next 0/4] selftests: drv-net: improve the queue test for XSK Jakub Kicinski
2025-02-18 19:50 ` [PATCH net-next 1/4] selftests: drv-net: use cfg.rpath() in netlink xsk attr test Jakub Kicinski
2025-02-18 21:24 ` Joe Damato
2025-02-18 19:50 ` [PATCH net-next 2/4] selftests: drv-net: add a way to wait for a local process Jakub Kicinski
2025-02-18 21:10 ` Stanislav Fomichev
2025-02-18 21:21 ` Jakub Kicinski
2025-02-18 21:29 ` Stanislav Fomichev
2025-02-18 21:52 ` Joe Damato
2025-02-18 23:05 ` Jakub Kicinski
2025-02-19 1:37 ` Jakub Kicinski
2025-02-19 18:40 ` Joe Damato
2025-02-19 18:39 ` Joe Damato
2025-02-19 22:48 ` Jakub Kicinski
2025-02-20 17:45 ` Joe Damato [this message]
2025-02-18 19:50 ` [PATCH net-next 3/4] selftests: drv-net: improve the use of ksft helpers in XSK queue test Jakub Kicinski
2025-02-18 21:25 ` Joe Damato
2025-02-18 19:50 ` [PATCH net-next 4/4] selftests: drv-net: rename queues check_xdp to check_xsk Jakub Kicinski
2025-02-18 21:25 ` Joe Damato
2025-02-18 21:29 ` [PATCH net-next 0/4] selftests: drv-net: improve the queue test for XSK Stanislav Fomichev
2025-02-18 21:55 ` Joe Damato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z7dqUfPc2N8LZgJz@LQ3V64L9R2 \
--to=jdamato@fastly.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=petrm@nvidia.com \
--cc=shuah@kernel.org \
--cc=willemdebruijn.kernel@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox