On Mon, Sep 19, 2016 at 4:37 PM, Player, Timmons <timmons.pla...@spirent.com
> wrote:

> Well, KASSERT only actually fails in debug builds, so you’d never see a
> problem with a release build
> (since NDEBUG is defined in conf/release.mk).

So this patch looks like it is doing reasonable things to me, and I don't
see a
reason not to apply it, but I don't know if we're not just plastering over
some more
serious bug which causes this receiving-on-a-closed-connection case.

I can only think of some very unlikely situations where reordered
cause some duplicate packets to be received for a connection after the
was already received, but I wonder if this is really what happens in your
(or in https://github.com/cloudius-systems/osv/issues/726) or we're seeing
evidence for a real bug in netchannels somewhere.

Avi, perhaps you can also look into this patch?

> Well, the only reason you end up in this state is that the net channel
> should have been torn down
> already, but hasn’t (though it could be in the process of doing so).
> Additionally, since the network driver calls directly into this function,
> you
> could potentially have a burst of packets destined for this no longer
> valid net channel.  So, it
> made sense to just close the channel here instead of allowing more packets
> to take this path
> into the stack.

So what worries me is that if this netchannel hasn't been torn down for a
reason - or being torn down in parallel - maybe it's not a good idea to
tear it
down here. Or maybe there is a case where we "leak" netchannels (never
tear them down) and here we're avoiding the leak in just one case but
it in other places?

Again, my worries likely come from not understanding this code enough,
sorry :-(

> Handing the packet off to netisr_dispatch allows the stack to generate a
> reset.

Sorry, I wasn't familiar with this "netisr_dispatch()" function.
Apparently ether_input() calls it, and ifp->if_input is ether_input().
So I guess it is indeed the right function to call.

You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to