On (08/04/14 20:22), David Miller wrote: > > In this case I added "sparc64: " for the subsystem prefix when > commiting your change. Thanks, I'll keep that in mind for the future- I wasnt sure of the taxonomy for ldc. > BTW, you'll probably come to notice that not a lot of work has gone > into handling hard disconnect failures properly in LDC and the drivers > that use it. It's the one area where the LDC framework is very weak. > Unfortunately a lot of cooperation is required by the drivers > themselves, because what to do when a LDC connection goes down is > different in different drivers (networking drivers can drop packets, > but block drivers have to redo the I/O when the LDC link comes back > up, for example) Noted - I've not run into this personally, but we'll add it to the list. FWIW, what I'm trying to sort out at the moment is the potential for triggering a soft lockup on a peer (i.e, a DoS vector). If a node sends a burst of data and then never drains its incoming ldc channel, the targetted peer will eventually encounter a tx_has_no_space_for()/EWOULDBLOCK from __vnet_tx_trigger/vnet_send_ack (and also __vdc_tx_trigger?) - all of these are infinite loops, and vnet_send_ack is particularly vicious because it's actually a paradoxical blocking Tx in the Rx path (due to the vnet protocol design, I suppose). Carefully asserting netif_stop_queue() for __vnet_tx_trigger() might possibly help that case (though it flow-controls all ldc_channels, instead of just the blocked one), but recovering gracefully for the other cases needs thought. --Sowmini -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
