netdev - Re: [PATCH net-next 06/12] ipvs: optimize dst usage for real server

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]

Date:	Thu, 7 Mar 2013 02:14:00 +0200 (EET)
From:	Julian Anastasov <ja@....bg>
To:	David Miller <davem@...emloft.net>
cc:	horms@...ge.net.au, lvs-devel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 06/12] ipvs: optimize dst usage for real
 server


	Hello,

On Wed, 6 Mar 2013, David Miller wrote:

> From: Julian Anastasov <ja@....bg>
> Date: Wed, 6 Mar 2013 23:58:09 +0200 (EET)
> 
> > 	There are two choices: __ip_vs_get_out_rt
> > to return refdst as implemented in this patchset or
> > to return dst with additional 'bool *noref' argument,
> > so that caller can decide between skb_dst_set or
> > skb_set_dst_noref. Then may be we will need just
> > a new skb_dst_set_noref_{always,force} func that will
> > contain the old skb_set_dst_noref code, i.e. without
> > dst_hold? Not sure which variant sounds better.
> 
> Both variants are starting to sound equally ugly :-)
> 
> Let me ask about this situation in another way.
> 
> IP input route lookup clients handle this transparently,
> even for routes with next-hop exceptions and nocache
> routes, by passing the SKB into the lookup function and
> there it will sort out whether noref is actually possible.
> 
> Is there a reason that IPVS's route lookup architecture
> can't work this way too?

	May be it is possible, eg. by adding more
arguments to __ip_vs_get_out_rt and moving all dst
checks and icmp_send there. But there are some dst
checks specific to the forwarding method, so I'm not
sure in the end result yet.

	For IPVS, noref is always possible because the
dst_cache var holds reference, even for the NOCACHE case
which is more likely to occur. So, some new variant of
skb_dst_set_noref that supports NOCACHE without dst_hold
is still needed.

Regards

--
Julian Anastasov <ja@....bg>
--
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