On Thu, Mar 26, 2020 at 12:37 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Wed, Mar 25, 2020 at 10:28 PM Joe Stringer <joe@xxxxxxxxxxx> wrote:
> >
> > On Wed, Mar 25, 2020 at 7:16 PM Andrii Nakryiko
> > <andrii.nakryiko@xxxxxxxxx> wrote:
> > >
> > > On Tue, Mar 24, 2020 at 10:58 PM Joe Stringer <joe@xxxxxxxxxxx> wrote:
> > > >
> > > > From: Lorenz Bauer <lmb@xxxxxxxxxxxxxx>
> > > >
> > > > Attach a tc direct-action classifier to lo in a fresh network
> > > > namespace, and rewrite all connection attempts to localhost:4321
> > > > to localhost:1234 (for port tests) and connections to unreachable
> > > > IPv4/IPv6 IPs to the local socket (for address tests).
> > > >
> > > > Keep in mind that both client to server and server to client traffic
> > > > passes the classifier.
> > > >
> > > > Signed-off-by: Lorenz Bauer <lmb@xxxxxxxxxxxxxx>
> > > > Co-authored-by: Joe Stringer <joe@xxxxxxxxxxx>
> > > > Signed-off-by: Joe Stringer <joe@xxxxxxxxxxx>
> > > > ---
> >
> > <snip>
> >
> > > > +static void handle_timeout(int signum)
> > > > +{
> > > > + if (signum == SIGALRM)
> > > > + fprintf(stderr, "Timed out while connecting to server\n");
> > > > + kill(0, SIGKILL);
> > > > +}
> > > > +
> > > > +static struct sigaction timeout_action = {
> > > > + .sa_handler = handle_timeout,
> > > > +};
> > > > +
> > > > +static int connect_to_server(const struct sockaddr *addr, socklen_t len)
> > > > +{
> > > > + int fd = -1;
> > > > +
> > > > + fd = socket(addr->sa_family, SOCK_STREAM, 0);
> > > > + if (CHECK_FAIL(fd == -1))
> > > > + goto out;
> > > > + if (CHECK_FAIL(sigaction(SIGALRM, &timeout_action, NULL)))
> > > > + goto out;
> > >
> > > no-no-no, we are not doing this. It's part of prog_tests and shouldn't
> > > install its own signal handlers and sending asynchronous signals to
> > > itself. Please find another way to have a timeout.
> >
> > I realise it didn't clean up after itself. How about signal(SIGALRM,
> > SIG_DFL); just like other existing tests do?
>
> You have alarm(3), which will deliver SIGALARM later, when other test
> is running. Once you clean up this custom signal handler it will cause
> test_progs to coredump. So still no, please find another way to do
> timeouts.
FWIW I hit this issue and alarm(0) afterwards fixed it up.
That said the SO_SNDTIMEO / SO_RCVTIMEO alternative should work fine
for this use case instead so I'll switch to that, it's marginally
cleaner.
