* Re: [PATCH][NETFILTER]: Fix race between clusterip_config_find_get and _entry_put.
[not found] <48009282.9040808@openvz.org>
@ 2008-04-13 4:55 ` Patrick McHardy
0 siblings, 0 replies; only message in thread
From: Patrick McHardy @ 2008-04-13 4:55 UTC (permalink / raw)
To: Pavel Emelyanov
Cc: Linux Netdev List, David Miller,
Netfilter Development Mailinglist
[Please remeber to CC netfilter-devel]
Pavel Emelyanov wrote:
> Consider we are putting a clusterip_config entry with the "entries"
> count == 1, and on the other CPU there's a clusterip_config_find_get
> in progress:
>
> CPU1: CPU2:
> clusterip_config_entry_put: clusterip_config_find_get:
> if (atomic_dec_and_test(&c->entries)) {
> /* true */
> read_lock_bh(&clusterip_lock);
> c = __clusterip_config_find(clusterip);
> /* found - it's still in list */
> ...
> atomic_inc(&c->entries);
> read_unlock_bh(&clusterip_lock);
>
> write_lock_bh(&clusterip_lock);
> list_del(&c->list);
> write_unlock_bh(&clusterip_lock);
> ...
> dev_put(c->dev);
>
> Oops! We have an entry returned by the clusterip_config_find_get,
> which is a) not in list b) has a stale dev pointer.
>
> The problems will happen when the CPU2 will release the entry - it
> will remove it from the list for the 2nd time, thus spoiling it, and
> will put a stale dev pointer.
>
> The fix is to make atomic_dec_and_test under the clusterip_lock.
I guess an alternative would have been to use atomic_inc_not_zero
in clusterip_config_find_get. But this is only called very rarely,
so it doesn't really matter.
Applied, thanks.
^ permalink raw reply [flat|nested] only message in thread