netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guillaume Nault <gnault@redhat.com>
To: David Ahern <dsahern@gmail.com>
Cc: David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH net] selftests: pmtu.sh: Kill tcpdump processes launched by subshell.
Date: Tue, 8 Mar 2022 20:09:49 +0100	[thread overview]
Message-ID: <20220308190949.GA3544@debian.home> (raw)
In-Reply-To: <d5a67e6a-6e1b-8f69-8d2a-e05708dfa3c9@gmail.com>

On Tue, Mar 08, 2022 at 11:21:58AM -0700, David Ahern wrote:
> On 3/7/22 3:38 PM, Guillaume Nault wrote:
> > The cleanup() function takes care of killing processes launched by the
> > test functions. It relies on variables like ${tcpdump_pids} to get the
> > relevant PIDs. But tests are run in their own subshell, so updated
> > *_pids values are invisible to other shells. Therefore cleanup() never
> > sees any process to kill:
> > 
> > $ ./tools/testing/selftests/net/pmtu.sh -t pmtu_ipv4_exception
> > TEST: ipv4: PMTU exceptions                                         [ OK ]
> > TEST: ipv4: PMTU exceptions - nexthop objects                       [ OK ]
> > 
> > $ pgrep -af tcpdump
> > 6084 tcpdump -s 0 -i veth_A-R1 -w pmtu_ipv4_exception_veth_A-R1.pcap
> > 6085 tcpdump -s 0 -i veth_R1-A -w pmtu_ipv4_exception_veth_R1-A.pcap
> > 6086 tcpdump -s 0 -i veth_R1-B -w pmtu_ipv4_exception_veth_R1-B.pcap
> > 6087 tcpdump -s 0 -i veth_B-R1 -w pmtu_ipv4_exception_veth_B-R1.pcap
> > 6088 tcpdump -s 0 -i veth_A-R2 -w pmtu_ipv4_exception_veth_A-R2.pcap
> > 6089 tcpdump -s 0 -i veth_R2-A -w pmtu_ipv4_exception_veth_R2-A.pcap
> > 6090 tcpdump -s 0 -i veth_R2-B -w pmtu_ipv4_exception_veth_R2-B.pcap
> > 6091 tcpdump -s 0 -i veth_B-R2 -w pmtu_ipv4_exception_veth_B-R2.pcap
> > 6228 tcpdump -s 0 -i veth_A-R1 -w pmtu_ipv4_exception_veth_A-R1.pcap
> > 6229 tcpdump -s 0 -i veth_R1-A -w pmtu_ipv4_exception_veth_R1-A.pcap
> > 6230 tcpdump -s 0 -i veth_R1-B -w pmtu_ipv4_exception_veth_R1-B.pcap
> > 6231 tcpdump -s 0 -i veth_B-R1 -w pmtu_ipv4_exception_veth_B-R1.pcap
> > 6232 tcpdump -s 0 -i veth_A-R2 -w pmtu_ipv4_exception_veth_A-R2.pcap
> > 6233 tcpdump -s 0 -i veth_R2-A -w pmtu_ipv4_exception_veth_R2-A.pcap
> > 6234 tcpdump -s 0 -i veth_R2-B -w pmtu_ipv4_exception_veth_R2-B.pcap
> > 6235 tcpdump -s 0 -i veth_B-R2 -w pmtu_ipv4_exception_veth_B-R2.pcap
> > 
> > Fix this by running cleanup() in the context of the test subshell.
> > Now that each test cleans the environment after completion, there's no
> > need for calling cleanup() again when the next test starts. So let's
> > drop it from the setup() function. This is okay because cleanup() is
> > also called when pmtu.sh starts, so even the first test starts in a
> > clean environment.
> > 
> > Note: PAUSE_ON_FAIL is still evaluated before cleanup(), so one can
> > still inspect the test environment upon failure when using -p.
> > 
> > Fixes: a92a0a7b8e7c ("selftests: pmtu: Simplify cleanup and namespace names")
> > Signed-off-by: Guillaume Nault <gnault@redhat.com>
> > ---
> >  tools/testing/selftests/net/pmtu.sh | 5 ++++-
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> 
> Reviewed-by: David Ahern <dsahern@kernel.org>

Hum, looks like for such short lived tcpdump sessions, we also need to
disable buffered mode. Otherwise tcpdump can be killed before it
actually processed the packets.

Also there's another problem, with the xfrmudp tests not recording the
correct PID in ${nettest_pids}.

I'll send v2 to also fix all these problems.


      reply	other threads:[~2022-03-08 19:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 22:38 [PATCH net] selftests: pmtu.sh: Kill tcpdump processes launched by subshell Guillaume Nault
2022-03-08 18:21 ` David Ahern
2022-03-08 19:09   ` Guillaume Nault [this message]

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=20220308190949.GA3544@debian.home \
    --to=gnault@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dsahern@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=shuah@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).