From: Nimrod Oren <noren@nvidia.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>,
Simon Horman <horms@kernel.org>,
Jacob Keller <jacob.e.keller@intel.com>,
Willem de Bruijn <willemb@google.com>,
netdev@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, Yael Chemla <ychemla@nvidia.com>,
Dragos Tatulea <dtatulea@nvidia.com>
Subject: Re: [PATCH net] selftests: drv-net: pp_alloc_fail: restore ring size after timeout
Date: Sun, 30 Aug 2026 11:05:52 +0300 [thread overview]
Message-ID: <114e426d-431a-445e-addd-dc30b2c70f0c@nvidia.com> (raw)
In-Reply-To: <20260827093109.5b26bac2@kernel.org>
On 27/08/2026 19:31, Jakub Kicinski wrote:
> On Tue, 25 Aug 2026 12:07:58 +0300 Nimrod Oren wrote:
>> Would it be preferable for cmd() to terminate and wait for
>> timed-out subprocesses?
>
> Meaning send a kill signal and then wait? Does it help anything?
It can help isolate tests so unwanted behavior does not carry over, like
the timed-out ethtool command continuing to hold the RTNL lock.
Rebooting would address this too.
> Regarding the patch - I'm not sure we should be complicating
> tests for this. How about we make NIPA reboot the machine if
> it sees subprocess.TimeoutExpired ? Adding defer()s before
> seems like a bit of a whack-a-mole.
Sounds good to me. Rebooting will be cleaner.
next prev parent reply other threads:[~2026-08-30 8:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 9:07 [PATCH net] selftests: drv-net: pp_alloc_fail: restore ring size after timeout Nimrod Oren
2026-08-27 16:31 ` Jakub Kicinski
2026-08-30 8:05 ` Nimrod Oren [this message]
2026-08-31 16:32 ` Jakub Kicinski
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=114e426d-431a-445e-addd-dc30b2c70f0c@nvidia.com \
--to=noren@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=dtatulea@nvidia.com \
--cc=edumazet@google.com \
--cc=horms@kernel.org \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=shuah@kernel.org \
--cc=willemb@google.com \
--cc=ychemla@nvidia.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.