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