|
Hello Wensong,
On Fri, 20 Apr 2001, Wensong Zhang wrote:
> Yeah, there is race between ip_vs_unbind_dest and __ip_vs_del_dest. I
> didn't think about it carefully when I felt there was somethings wrong in
> ip_vs_unbind_dest last time. :)
>
> > I vote this code to be replaced with atomic_dec(&dest->refcnt).
> > The destinations must be released only from user space. This is an
> > old(2.2?)/unused/buggy stuff.
> >
>
> IPVS for kernel 2.2 probably need a fix too.
Yes, I still don't remember why we keep this code.
> I also see any other problem in ipvs for kernel 2.4. Since ipvs for kernel
> 2.4 can be built as module, the ipvs module can be removed while the
> destination trash isn't empty, which will cause a little bit memory
> leakage. We need add ip_vs_trash_cleanup to cleanup all the destinations
> in the trash, let ip_vs_control_cleanup call ip_vs_trash_cleanup, before
> the ipvs module is removed.
Yes, *USE_COUNT counter misses the trash entries. This is the only
dark place in the LVS code. In theory, at cleanup, all dest->refcnt in the
trash must be 1 because the module can be deleted only when there are no
more services and connections. In this case the only referer is the trash
list.
> It seems that we will release another version soon, but now I need have a
> sleep. :)
>
> Regards,
>
> Wensong
Regards
--
Julian Anastasov <ja@xxxxxx>
|
