LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: Re: [v2 PATCH 0/6] IPVS: init and cleanup.

To: Hans Schillstrom <hans@xxxxxxxxxxxxxxx>
Subject: Re: Re: [v2 PATCH 0/6] IPVS: init and cleanup.
Cc: horms@xxxxxxxxxxxx, ebiederm@xxxxxxxxxxxx, lvs-devel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxxxxxx, netfilter-devel@xxxxxxxxxxxxxxx, hans.schillstrom@xxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 22 Apr 2011 19:49:13 +0300 (EEST)
        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@xxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

<Prev in Thread] Current Thread [Next in Thread>