netdev - Re: [PATCH]: Fix ipv6 round-robin locking

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070324234030.GG521@postel.suug.ch>
Date:	Sun, 25 Mar 2007 00:40:30 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH]: Fix ipv6 round-robin locking

* David Miller <davem@...emloft.net> 2007-03-24 12:44
>     As per RFC2461, section 6.3.6, item #2, when no routers on the
>     matching list are known to be reachable or probably reachable we
>     do round robin on those available routes so that we make sure
>     to probe as many of them as possible to detect when one becomes
>     reachable faster.
>     
> +static struct rt6_info *find_match(struct rt6_info *rt, int oif, int strict,
> +				   int *mpri, struct rt6_info *match)
>  {
> +	int m;
> +
> +	if (rt6_check_expired(rt))
> +		goto out;
> +
> +	m = rt6_score_route(rt, oif, strict);
> +	if (m < 0)
> +		goto out;
> +
> +	if (m > *mpri) {
> +		if (strict & RT6_LOOKUP_F_REACHABLE)
> +			rt6_probe(match);
> +		*mpri = m;
> +		match = rt;
> +	} else if (strict & RT6_LOOKUP_F_REACHABLE) {
> +		rt6_probe(rt);
> +	}
> +
> +out:
> +	return match;
> +}

First of all, I haven't spotted any errors in your patch.

Seondly, I'm not sure I've fully understood why this round robin mechanism
is needed to ensure as many routers as possible are probed as soon as
possible. I'd understand it if we'd only probe just one router per selection
process but to my undertanding we try and probe _all_ routers as long as
its score is positive (and rate limitation doesn't step in). The score can
only be negative  if rt6_check_dev() returns 0, the neighbour state is
NUD_FAILED or not present at all. I don't see how the position in the list
would have any affect on this. rt6_select() is called for all routers
regardless of its score, the position of a router doesn't matter.

The only effect of this code I can see is that we return a different
_probably_ reachable router while no router is reachable. This would implement
what item #1 of 6.3.6 proposes.

I'm just making sure we know what we're doing :-)
-
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