netdev - Re: [Babel-users] Looping in EAGAIN

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <551540C6.6070500@thekelleys.org.uk>
Date:	Fri, 27 Mar 2015 11:36:38 +0000
From:	Simon Kelley <simon@...kelleys.org.uk>
To:	Dave Taht <dave.taht@...il.com>,
	Juliusz Chroboczek <jch@....univ-paris-diderot.fr>
CC:	"babel-users@...ts.alioth.debian.org" 
	<babel-users@...ts.alioth.debian.org>,
	dnsmasq-discuss <Dnsmasq-discuss@...ts.thekelleys.org.uk>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [Babel-users] Looping in EAGAIN

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dnsmasq loops awaiting a return other than EAGAIN for at most one
second, then logs an error and gives up. (The initial version of the
fix could give up in much less than one second, under certain rare
circumstances, that's fixed in 2.73rc1.)



Cheers,


Simon.


On 27/03/15 02:55, Dave Taht wrote:
> I see this patch for EAGAIN on an interface going away did not make
> the babel-ss-merge branch apparently.  (for those new to this bug,
> see: 
> http://lists.alioth.debian.org/pipermail/babel-users/2014-October/0017
77.html
>
> 
for more details. )
> 
> No, I haven't had time to test this patch, nor have I come up with
> a better idea.
> 
> I am curious if there could be some other *more robust* means of
> detecting when an interface has gone away, and/or how dnsmasq was
> coping with this situation nowadays.
> 
> (I'd mentioned this problem on the endless homenet thread
> 
> http://www.ietf.org/mail-archive/web/homenet/current/msg05156.html
> 
> and, thought I'd check to see if it was mainlined!)
> 
> I certainly hate any possibility anywhere in routing code where a 
> possibility for infinite loop existed. are there any checkers for
> such loops in the world?
> 
> On Wed, Oct 15, 2014 at 2:00 PM, Juliusz Chroboczek < 
> jch@....univ-paris-diderot.fr> wrote:
>> Dave,
>> 
>> I'm not going to have time to test this for a while.  In the
>> meantime, here's a proposed patch, please let me know if you find
>> the time to test it. have -- Juliusz
>> 
>> diff --git a/net.c b/net.c index 6f9728f..9b0b738 100644 ---
>> a/net.c +++ b/net.c @@ -141,7 +141,7 @@ babel_send(int s, { 
>> struct iovec iovec[2]; struct msghdr msg; -    int rc; +    int
>> rc, count = 0;
>> 
>> iovec[0].iov_base = (void*)buf1; iovec[0].iov_len = buflen1; @@
>> -156,13 +156,18 @@ babel_send(int s, again: rc = sendmsg(s, &msg,
>> 0); if(rc < 0) { -        if(errno == EINTR) -            goto
>> again; -        else if(errno == EAGAIN) { +        if(errno ==
>> EINTR) { +            count++; +            if(count < 1000) +
>> goto again; +        } else if(errno == EAGAIN) { int rc2; rc2 =
>> wait_for_fd(1, s, 5); -            if(rc2 > 0) -
>> goto again; +            if(rc2 > 0) { +                count++; 
>> +                if(count < 1000) +                    goto
>> again; +            } errno = EAGAIN; } }
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlUVQMYACgkQKPyGmiibgrcS5gCfR33LxmCLH0XGyUZJn7uVNrmf
6CoAn229oPy6L/x5UuwziB5ODxGdBDUS
=9tMC
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html