This is a note to let you know that I've just added the patch titled
inet: frags: fix a race between inet_evict_bucket and inet_frag_kill
to the 3.17-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
inet-frags-fix-a-race-between-inet_evict_bucket-and-inet_frag_kill.patch
and it can be found in the queue-3.17 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From foo@baz Tue Nov 18 09:07:25 PST 2014
From: Nikolay Aleksandrov <[email protected]>
Date: Tue, 28 Oct 2014 10:30:34 +0100
Subject: inet: frags: fix a race between inet_evict_bucket and inet_frag_kill
From: Nikolay Aleksandrov <[email protected]>
[ Upstream commit 65ba1f1ec0eff1c25933468e1d238201c0c2cb29 ]
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. 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.
An important note to make is that we're safe w.r.t refcnt because
inet_frag_kill and inet_evict_bucket will sync on the del_timer operation
where only one of the two can succeed (or if the timer is executing -
none of them), the cases are:
1. inet_frag_kill succeeds in del_timer
- then the timer ref is removed, but inet_evict_bucket will not add
this queue to its expire list but will restart eviction in that chain
2. inet_evict_bucket succeeds in del_timer
- then the timer ref is kept until the evictor "expires" the queue, but
inet_frag_kill will remove the initial ref and will set
INET_FRAG_COMPLETE which will make the frag_expire fn just to remove
its ref.
In the end all of the queue users will do an inet_frag_put and the one
that reaches 0 will free it. The refcount balance should be okay.
CC: Florian Westphal <[email protected]>
CC: Eric Dumazet <[email protected]>
CC: Patrick McLean <[email protected]>
Fixes: b13d3cbfb8e8 ("inet: frag: move eviction of queues to work queue")
Suggested-by: Eric Dumazet <[email protected]>
Reported-by: Patrick McLean <[email protected]>
Tested-by: Patrick McLean <[email protected]>
Signed-off-by: Nikolay Aleksandrov <[email protected]>
Reviewed-by: Florian Westphal <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv4/inet_fragment.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -285,7 +285,8 @@ static inline void fq_unlink(struct inet
struct inet_frag_bucket *hb;
hb = get_frag_bucket_locked(fq, f);
- hlist_del(&fq->list);
+ if (!(fq->flags & INET_FRAG_EVICTED))
+ hlist_del(&fq->list);
spin_unlock(&hb->chain_lock);
}
Patches currently in stable-queue which might be from [email protected] are
queue-3.17/inet-frags-fix-a-race-between-inet_evict_bucket-and-inet_frag_kill.patch
queue-3.17/inet-frags-remove-the-warn_on-from-inet_evict_bucket.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
