From: Steve Chen <schen@mvista.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] Multicast packet reassembly can fail
Date: Wed, 28 Oct 2009 08:32:37 -0500 [thread overview]
Message-ID: <1256736757.3153.412.camel@linux-1lbu> (raw)
In-Reply-To: <4AE81A70.5060307@gmail.com>
On Wed, 2009-10-28 at 11:18 +0100, Eric Dumazet wrote:
> Steve Chen a écrit :
> > Multicast packet reassembly can fail
> >
> > When multicast connections with multiple fragments are received by the same
> > node from more than one Ethernet ports, race condition between fragments
> > from each Ethernet port can cause fragment reassembly to fail leading to
> > packet drop. This is because packets from each Ethernet port appears identical
> > to the the code that reassembles the Ethernet packet.
> >
> > The solution is evaluate the Ethernet interface number in addition to all other
> > parameters so that every packet can be uniquely identified. The existing
> > iif field in struct ipq is now used to generate the hash key, and iif is also
> > used for comparison in case of hash collision.
> >
> > Please note that q->saddr ^ (q->iif << 5) is now being passed into
> > ipqhashfn to generate the hash key. This is borrowed from the routing
> > code.
> >
> > Signed-off-by: Steve Chen <schen@mvista.com>
> > Signed-off-by: Mark Huth <mhuth@mvista.com>
> >
>
> This makes no sense to me, but I need to check the code.
>
> How interface could matter in IP defragmentation ?
> And why multicast is part of the equation ?
>
> If defrag fails, this must be for other reason,
> and probably needs another fix.
>
> Check line 219 of net/ipv4/inet_fragment.c
>
> #ifdef CONFIG_SMP
> /* With SMP race we have to recheck hash table, because
> * such entry could be created on other cpu, while we
> * promoted read lock to write lock.
> */
> hlist_for_each_entry(qp, n, &f->hash[hash], list) {
> if (qp->net == nf && f->match(qp, arg)) {
> atomic_inc(&qp->refcnt);
> write_unlock(&f->lock);
> qp_in->last_in |= INET_FRAG_COMPLETE; <<< HERE >>>
> inet_frag_put(qp_in, f);
> return qp;
> }
> }
> #endif
>
> I really wonder why we set INET_FRAG_COMPLETE here
I sent the specific scenario the patch tries to address to the list in
an earlier e-mail. Would it be beneficial if I post the test code
somewhere so everyone can have access?
Regards,
Steve
next prev parent reply other threads:[~2009-10-28 13:24 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-27 22:46 [PATCH] Multicast packet reassembly can fail Steve Chen
2009-10-27 23:22 ` Rick Jones
2009-10-28 13:29 ` Steve Chen
2009-10-28 16:55 ` Mark Huth
2009-10-28 17:18 ` Rick Jones
2009-10-28 17:50 ` Steve Chen
2009-10-28 18:10 ` Rick Jones
2009-10-28 18:40 ` Steve Chen
2009-10-29 18:04 ` Herbert Xu
2009-10-29 18:33 ` Steve Chen
2009-11-02 18:36 ` Steve Chen
2009-10-28 10:18 ` Eric Dumazet
2009-10-28 13:32 ` Steve Chen [this message]
2009-10-28 13:30 ` Eric Dumazet
2009-10-29 4:57 ` David Miller
2009-10-29 5:31 ` Eric Dumazet
2009-10-28 20:12 ` David Stevens
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=1256736757.3153.412.camel@linux-1lbu \
--to=schen@mvista.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.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.