Re: Looping in EAGAIN

Re: Looping in EAGAIN

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 2316 bytes --]

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/001777.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@pps.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;
>          }
>      }



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

[-- Attachment #1.2: Type: text/html, Size: 3100 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [Babel-users] Looping in EAGAIN

[Simon Kelley]

-----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-InGYJPFgxhmQrp73wey5nH9PKDog5E0sUBSOeVevoDU@public.gmane.org> 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-----