Re: [RFC net-next PATCH V1 7/9] net: frag queue locking per hash bucket
flat view
From: Jesper Dangaard Brouer <hidden>
Date: 2012-11-27 09:09:19
On Fri, 2012-11-23 at 14:08 +0100, Jesper Dangaard Brouer wrote:
DO NOT apply - patch not finished, can cause on OOPS/PANIC during hash rebuild
Think I have fixed this issue. And its even fixed in this patch, as the oops occurred, when testing, with a slightly older version of this patch.
This patch implements per hash bucket locking for the frag queue hash. This removes two write locks, and the only remaining write lock is for protecting hash rebuild. This essentially reduce the readers-writer lock to a rebuild lock.
[... cut ...]
quoted hunk ↗ jump to hunk
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c index 1620a21..447423f 100644 --- a/net/ipv4/inet_fragment.c +++ b/net/ipv4/inet_fragment.c
[...]
quoted hunk ↗ jump to hunk
@@ -102,9 +112,17 @@ EXPORT_SYMBOL(inet_frags_exit_net); static inline void fq_unlink(struct inet_frag_queue *fq, struct inet_frags *f) { - write_lock(&f->lock); + struct inet_frag_bucket *hb; + unsigned int hash; + + read_lock(&f->lock); + hash = f->hashfn(fq); + hb = &f->hash[hash];
Before the read_lock, were _here_ below then hash calc. Which is wrong, and caused the oops, as the hash result can change, when rnd is changed, during hash rebuild.
quoted hunk ↗ jump to hunk
+ + spin_lock_bh(&hb->chain_lock); hlist_del(&fq->list); - write_unlock(&f->lock); + spin_unlock_bh(&hb->chain_lock); + read_unlock(&f->lock); inet_frag_lru_del(fq); }
[... cut ...]