From: Stephen Hemminger <stephen@networkplumber.org>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>
Cc: dev@dpdk.org, phil.yang@arm.com
Subject: Re: [PATCH v4] testpmd: cleanup cleanly from signal
Date: Wed, 9 Nov 2022 14:53:23 -0800 [thread overview]
Message-ID: <20221109145323.7ac2a1b4@hermes.local> (raw)
In-Reply-To: <097a2759-f958-84ed-0ddf-4b23eb1eee04@lysator.liu.se>
On Wed, 9 Nov 2022 22:46:55 +0100
Mattias Rönnblom <hofors@lysator.liu.se> wrote:
> On 2022-11-09 05:10, Stephen Hemminger wrote:
> > Do a clean shutdown of testpmd when a signal is received;
> > instead of having testpmd kill itself.
> > This fixes problem where a signal could be received
> > in the middle of a PMD and then the signal handler would call
> > PMD's close routine which could cause a deadlock.
> >
> > Added benefit is it gets rid of Windows specific code.
> >
> > Fixes: d9a191a00e81 ("app/testpmd: fix quitting in container")
> > Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
> > ---
> > v4 - use select() because that is available on Windows; and other
> > functions poll() and sigaction() are not.
> >
> > app/test-pmd/testpmd.c | 63 +++++++++++++++++++++++-------------------
> > 1 file changed, 34 insertions(+), 29 deletions(-)
> >
> > diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
> > index cf5942d0c422..274e96cac2d4 100644
> > --- a/app/test-pmd/testpmd.c
> > +++ b/app/test-pmd/testpmd.c
> > @@ -12,6 +12,7 @@
> > #ifndef RTE_EXEC_ENV_WINDOWS
> > #include <sys/mman.h>
> > #endif
> > +#include <sys/select.h>
> > #include <sys/types.h>
> > #include <errno.h>
> > #include <stdbool.h>
> > @@ -4251,26 +4252,11 @@ print_stats(void)
> > static void
> > signal_handler(int signum)
> > {
> > - if (signum == SIGINT || signum == SIGTERM) {
> > - fprintf(stderr, "\nSignal %d received, preparing to exit...\n",
> > - signum);
> > -#ifdef RTE_LIB_PDUMP
> > - /* uninitialize packet capture framework */
> > - rte_pdump_uninit();
> > -#endif
> > -#ifdef RTE_LIB_LATENCYSTATS
> > - if (latencystats_enabled != 0)
> > - rte_latencystats_uninit();
> > -#endif
> > - force_quit();
> > - /* Set flag to indicate the force termination. */
> > - f_quit = 1;
> > - /* exit with the expected status */
> > -#ifndef RTE_EXEC_ENV_WINDOWS
> > - signal(signum, SIG_DFL);
> > - kill(getpid(), signum);
> > -#endif
> > - }
> > + fprintf(stderr, "\nSignal %d %s received, preparing to exit...\n",
> > + signum, strsignal(signum));
>
> fprintf() is not async signal safe, and neither is strsignal().
>
> This is not a regression introduced by this patch, but I thought it
> might be worth fixing.
>
> > +
> > + /* Set flag to indicate the force termination. */
> > + f_quit = 1;
> > }
> >
> > int
> > @@ -4449,9 +4435,6 @@ main(int argc, char** argv)
> > } else
> > #endif
> > {
> > - char c;
> > - int rc;
> > -
> > f_quit = 0;
> >
> > printf("No commandline core given, start packet forwarding\n");
> > @@ -4476,15 +4459,37 @@ main(int argc, char** argv)
> > prev_time = cur_time;
> > rte_delay_us_sleep(US_PER_S);
> > }
> > - }
> > + } else {
> > + char c;
> > + fd_set fds;
> >
> > - printf("Press enter to exit\n");
> > - rc = read(0, &c, 1);
> > - pmd_test_exit();
> > - if (rc < 0)
> > - return 1;
> > + printf("Press enter to exit\n");
> > +
> > + FD_ZERO(&fds);
> > + FD_SET(0, &fds);
> > +
> > + if (select(1, &fds, NULL, NULL, NULL) <= 0) {
> > + fprintf(stderr, "Select failed: %s\n",
> > + strerror(errno));
>
> Why is select() needed? Wouldn't a blocking read suffice? Or getchar().
On Linux, signal set SA_RESTART so a simple read is not interrupted.
One option was to use sigaction() which allows controlling flags, but that
won't work on Windows. Using select() works on both.
next prev parent reply other threads:[~2022-11-09 22:53 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-14 17:23 [RFC 1/2] testpmd: make f_quit flag volatile Stephen Hemminger
2022-10-14 17:23 ` [RFC 2/2] testpmd: cleanup cleanly from signal Stephen Hemminger
2022-11-06 10:50 ` Andrew Rybchenko
2022-11-08 18:16 ` Stephen Hemminger
2022-11-08 18:53 ` [PATCH v2] " Stephen Hemminger
2022-11-08 20:24 ` [PATCH v3] " Stephen Hemminger
2022-11-09 4:10 ` [PATCH v4] " Stephen Hemminger
2022-11-09 21:46 ` Mattias Rönnblom
2022-11-09 22:53 ` Stephen Hemminger [this message]
2022-11-10 7:50 ` Mattias Rönnblom
2022-11-10 16:14 ` Stephen Hemminger
2022-11-10 22:06 ` Mattias Rönnblom
2022-11-09 17:29 ` [PATCH v5] " Stephen Hemminger
2022-11-10 7:14 ` Andrew Rybchenko
2022-11-10 16:13 ` Stephen Hemminger
2022-11-10 16:53 ` [PATCH v6] " Stephen Hemminger
2022-11-11 8:05 ` Andrew Rybchenko
2022-11-11 16:49 ` Stephen Hemminger
2022-11-11 16:51 ` [PATCH v7] " Stephen Hemminger
2022-11-12 17:28 ` [PATCH v8] " Stephen Hemminger
2023-01-19 15:53 ` Ferruh Yigit
2023-01-25 18:32 ` [PATCH v9] " Stephen Hemminger
2023-01-30 18:48 ` Ferruh Yigit
2023-01-30 20:11 ` Stephen Hemminger
2022-11-06 10:48 ` [RFC 1/2] testpmd: make f_quit flag volatile Andrew Rybchenko
2022-11-08 18:07 ` [PATCH v2] " Stephen Hemminger
2022-11-09 10:11 ` Ruifeng Wang
2022-11-09 10:37 ` Andrew Rybchenko
2023-01-30 20:09 ` [PATCH v10 0/2] testpmd: handle signals safely Stephen Hemminger
2023-01-30 20:09 ` [PATCH v10 1/2] cmdline: handle EOF in cmdline_poll Stephen Hemminger
2023-01-30 22:12 ` Ferruh Yigit
2023-01-31 2:54 ` Stephen Hemminger
2023-01-30 20:09 ` [PATCH v10 2/2] testpmd: cleanup cleanly from signal Stephen Hemminger
2023-01-31 9:30 ` Ferruh Yigit
2023-01-30 22:13 ` [PATCH v10 0/2] testpmd: handle signals safely Ferruh Yigit
2023-02-03 19:14 ` [PATCH v11 0/3] Fix cmdline_poll and testpmd signal handling Stephen Hemminger
2023-02-03 19:14 ` [PATCH v11 1/3] cmdline: make rdline status not private Stephen Hemminger
2023-02-06 2:31 ` fengchengwen
2023-02-03 19:14 ` [PATCH v11 2/3] cmdline: handle EOF in cmdline_poll Stephen Hemminger
2023-02-03 19:14 ` [PATCH v11 3/3] testpmd: cleanup cleanly from signal Stephen Hemminger
2023-02-07 14:49 ` Ferruh Yigit
2023-02-07 14:48 ` [PATCH v11 0/3] Fix cmdline_poll and testpmd signal handling Ferruh Yigit
2023-02-19 17:53 ` Stephen Hemminger
2023-03-11 10:17 ` Thomas Monjalon
2023-03-12 17:18 ` Tal Shnaiderman
2023-03-13 10:34 ` Ling, WeiX
2023-03-13 15:53 ` Stephen Hemminger
2023-03-14 7:05 ` Ling, WeiX
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=20221109145323.7ac2a1b4@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=hofors@lysator.liu.se \
--cc=phil.yang@arm.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;
as well as URLs for NNTP newsgroup(s).