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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).