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:	Wed, 06 Mar 2013 15:18:10 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	ja@....bg
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

From: Julian Anastasov <ja@....bg>
Date: Wed,  6 Mar 2013 10:42:16 +0200

> 	Currently when forwarding requests to real servers
> we use dst_lock and atomic operations when cloning the
> dst_cache value. As the dst_cache value does not change
> most of the time it is better to use RCU and to lock
> dst_lock only when we need to replace the obsoleted dst.
> For this to work we keep dst_cache in new structure protected
> by RCU. For packets to remote real servers we will use noref
> version of dst_cache, it will be valid while we are in RCU
> read-side critical section because now dst_release for replaced
> dsts will be invoked after the grace period. NAT-ed packets
> via loopback that are not sent but are passed to local stack
> with NF_ACCEPT need a dst clone (skb_dst_force).
> 
> Signed-off-by: Julian Anastasov <ja@....bg>

It think it's much cleaner to have the callers of route lookups do
skb_set_dst_noref().

Then you don't need any new interfaces, and you therefore don't need
to expose bits of the noref implementation and semantics at all.
--
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