From: Florian Westphal <fw@strlen.de>
To: Nikolay Aleksandrov <nikolay@redhat.com>
Cc: netdev@vger.kernel.org, Florian Westphal <fw@strlen.de>,
Eric Dumazet <eric.dumazet@gmail.com>,
Patrick McLean <chutzpah@gentoo.org>
Subject: Re: [PATCH net] inet: frags: fix a race between inet_evict_bucket and inet_frag_kill
Date: Tue, 28 Oct 2014 11:03:15 +0100 [thread overview]
Message-ID: <20141028100315.GA14863@breakpoint.cc> (raw)
In-Reply-To: <1414488634-28412-1-git-send-email-nikolay@redhat.com>
Nikolay Aleksandrov <nikolay@redhat.com> wrote:
> When the evictor is running it adds some chosen frags to a local list to
> be evicted once the chain lock has been released but at the same time
> the *frag_queue can be running for some of the same queues and it
> may call inet_frag_kill which will wait on the chain lock and
> will then delete the queue from the wrong list since it was added in the
> eviction one.
I had to read that twice...
cpu1 cpu2
inet_evict_bucket inet_frag_kill
chain_lock() chain_lock() ..
for_each_frag_queue spin
set fragqueue INET_FRAG_EVICTED flag [A] .
hlist_del() spin
hlist_add (to private list) .
spin
chain_unlock .
chain_lock returns
for_each_frag_queue_on_private_list hlist_del() [B]
frag_expire(fq) // destroy/free queue
[B] we may delete entry on the evictors private list.
since [A] is only set with chainlock held, other cpus
killing an entry can use INET_FRAG_EVICTED to test if the
entry is about to be removed by the evictor.
> The fix is simple - check if the queue has the evict flag
> set under the chain lock before deleting it, this is safe because the
> evict flag is set only under that lock and having the flag set also means
> that the queue has been detached from the chain list, so no need to delete
> it again.
Right, thanks everyone.
> ---
> A few more eyes to confirm all of this would be much appreciated.
Looks correct,
Reviewed-by: Florian Westphal <fw@strlen.de>
next prev parent reply other threads:[~2014-10-28 10:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-25 8:40 Fw: [Bug 86851] New: Reproducible panic on heavy UDP traffic Stephen Hemminger
2014-10-25 21:44 ` Florian Westphal
2014-10-26 23:28 ` Nikolay Aleksandrov
2014-10-27 0:47 ` Eric Dumazet
2014-10-27 8:48 ` Nikolay Aleksandrov
2014-10-27 9:12 ` Nikolay Aleksandrov
2014-10-27 9:32 ` Nikolay Aleksandrov
2014-10-27 22:59 ` Patrick McLean
2014-10-27 23:06 ` Nikolay Aleksandrov
2014-10-28 0:16 ` Eric Dumazet
2014-10-28 9:30 ` [PATCH net] inet: frags: fix a race between inet_evict_bucket and inet_frag_kill Nikolay Aleksandrov
2014-10-28 10:03 ` Florian Westphal [this message]
2014-10-29 19:21 ` David Miller
2014-10-28 9:44 ` [PATCH net] inet: frags: remove the WARN_ON from inet_evict_bucket Nikolay Aleksandrov
2014-10-29 19:22 ` David Miller
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=20141028100315.GA14863@breakpoint.cc \
--to=fw@strlen.de \
--cc=chutzpah@gentoo.org \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@redhat.com \
/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.