From: Jarek Poplawski <jarkao2@gmail.com>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: David Miller <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH (regression)] Fragments: fix race between inet_frag_find and inet_frag_secret_rebuild
Date: Wed, 25 Jun 2008 11:37:48 +0200 [thread overview]
Message-ID: <20080625093748.GA2455@ami.dom.local> (raw)
In-Reply-To: <4861E8F0.9080507@openvz.org>
On Wed, Jun 25, 2008 at 10:42:56AM +0400, Pavel Emelyanov wrote:
> Jarek Poplawski wrote:
> > Pavel Emelyanov wrote, On 06/24/2008 12:43 PM:
> >
> >> The problem is that while we work w/o the inet_frags.lock even
> >> read-locked the secret rebuild timer may occur (on another CPU,
> > - since BHs are still disables in the inet_frag_find) and change
> >
> > + since BHs are still disabled in the inet_frag_find) and change
> >
> >> the rnd seed for ipv4/6 fragments.
> >>
> >> It was caused by my patch fd9e63544cac30a34c951f0ec958038f0529e244
> >> ([INET]: Omit double hash calculations in xxx_frag_intern) late
> >> in the 2.6.24 kernel, so this should probably be queued to -stable.
> >>
> >> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> >>
> >> ---
> >>
> >> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> >> index 4ed429b..0546a0b 100644
> >> --- a/net/ipv4/inet_fragment.c
> >> +++ b/net/ipv4/inet_fragment.c
> >> @@ -192,14 +192,21 @@ EXPORT_SYMBOL(inet_frag_evictor);
> >>
> >> static struct inet_frag_queue *inet_frag_intern(struct netns_frags *nf,
> >> struct inet_frag_queue *qp_in, struct inet_frags *f,
> >> - unsigned int hash, void *arg)
> >> + void *arg)
> >> {
> >> struct inet_frag_queue *qp;
> >> #ifdef CONFIG_SMP
> >> struct hlist_node *n;
> >> #endif
> >> + unsigned int hash;
> >>
> >> write_lock(&f->lock);
> >> + /*
> >> + * While we stayed w/o the lock other CPU could update
> >> + * the rnd seed, so we need to re-calculate the hash
> >> + * chain. Fortunatelly the qp_in can be used to get one.
> >> + */
> >> + hash = f->hashfn(qp_in);
> >> #ifdef CONFIG_SMP
> >> /* With SMP race we have to recheck hash table, because
> >> * such entry could be created on other cpu, while we
> >
> > Maybe it's a matter of taste: since there is this "#ifdef CONFIG_SMP",
> > and the new comment concerns with "other CPU", why this re-calculation
> > isn't done only for SMP?
>
> Because the hash value is required also *outside* this ifdef and adding
> a fancier logic is probably not good for a -rc7 fix.
I'm not sure what fancier logic do you mean: I've thought about simply
leaving the "hash" as functions argument as it is, and only adding this
recalculation under #ifdef CONFIG_SMP, but I can miss something...
Jarek P.
next prev parent reply other threads:[~2008-06-25 9:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-24 10:43 [PATCH (regression)] Fragments: fix race between inet_frag_find and inet_frag_secret_rebuild Pavel Emelyanov
2008-06-24 18:07 ` Jarek Poplawski
2008-06-25 6:42 ` Pavel Emelyanov
2008-06-25 7:09 ` David Miller
2008-06-25 9:37 ` Jarek Poplawski [this message]
2008-06-28 3:06 ` 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=20080625093748.GA2455@ami.dom.local \
--to=jarkao2@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@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.