From: Patrick McHardy <kaber@trash.net>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: Linux Netdev List <netdev@vger.kernel.org>,
David Miller <davem@davemloft.net>,
Netfilter Development Mailinglist
<netfilter-devel@vger.kernel.org>
Subject: Re: [PATCH][NETFILTER]: Fix race between clusterip_config_find_get and _entry_put.
Date: Sun, 13 Apr 2008 06:55:47 +0200 [thread overview]
Message-ID: <48019253.2090007@trash.net> (raw)
In-Reply-To: <48009282.9040808@openvz.org>
[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.
prev parent reply other threads:[~2008-04-13 4:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-12 10:44 [PATCH][NETFILTER]: Fix race between clusterip_config_find_get and _entry_put Pavel Emelyanov
2008-04-13 4:55 ` Patrick McHardy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48019253.2090007@trash.net \
--to=kaber@trash.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=xemul@openvz.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.