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 retransmissions cause some duplicate packets to be received for a connection after the FIN-ACK was already received, but I wonder if this is really what happens in your tests (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 leaving 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.
