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] [day] [month] [year] [list]
Date:	Fri, 22 Apr 2011 19:49:13 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Hans Schillstrom <hans@...illstrom.com>
cc:	horms@...ge.net.au, ebiederm@...ssion.com,
	lvs-devel@...r.kernel.org, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org, hans.schillstrom@...csson.com
Subject: Re: Re: [v2 PATCH 0/6] IPVS: init and cleanup.


	Hello,

On Fri, 22 Apr 2011, Hans Schillstrom wrote:

> Hello Julian
> 
> >From what I can see there is nothing in the rs_table except for NAT:ed dest, or ?
> so the code fragment below will not work.
> 
> I.e. my double list_for_each that goes throug the service table must be there...
> or do we need both?

	Yes, I now see that dests are added to rs_table only for
NAT. So, we have no choice, we have to walk svc->destinations.
To remove usage of dest_trash in ip_vs_dst_event we can move
the ip_vs_dst_reset call in __ip_vs_del_dest() above the
atomic_dec_and_test check. But it is not a safe operation.
While with svc->usecnt we know if packet accesses the svc,
the same for dest is not possible. Packet can hit existing
connection (without searching for svc), conn has reference to
dest, so the packet can refresh dest->dst_cache at any point
of time, eg. while we move dest to trash. That is why
__ip_vs_del_dest calls ip_vs_dst_reset only when dest->refcnt
reaches 0, i.e. when no conn refers to dest. So, even if we
call ip_vs_dst_reset() before the atomic_dec_and_test check,
it is still possible some packet to attach new dst_cache
entry. As result, we can not assume that dests in trash have
no dst_cache entry. So, ip_vs_dst_event() needs to walk
both svc->destinations and ipvs->dest_trash under mutex lock.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ