i think if a->rxtsrem > 0 && canrlock(rfc) && a->ifcid != ifc->ifcid, then
we leave ifc locked.

Notes:
this patch follows a pattern i'm wary of.  it's been in plan 9 for
a long time, yet it appears obviously wrong and deadly.  my one
way out is the third condition very rarely happens.  so
i'm posting this note to sources to get y'alls thoughts.
- quanstro


Reference: /n/atom/patch/arplockleak
Date: Sun Sep 27 17:31:12 CES 2015
Signed-off-by: quanstro@quanstro.net
Reviewed-by: quanstro

--- /sys/src/nix/ip/arp.c	Sun Sep 27 17:30:00 2015
+++ /sys/src/nix/ip/arp.c	Sun Sep 27 17:30:02 2015
@@ -561,6 +561,7 @@
 extern int
 rxmitsols(Arp *arp)
 {
+	int u;
 	uint sflag;
 	Block *next, *xp;
 	Arpent *a, *b, **l;
@@ -584,7 +585,11 @@
 	for(; a; a = a->nextrxt){
 		ifc = a->ifc;
 		assert(ifc != nil);
-		if((a->rxtsrem <= 0) || !(canrlock(ifc)) || (a->ifcid != ifc->ifcid)){
+		u = 0;
+		if(a->rxtsrem <= 0 || !canrlock(ifc) || (u = a->ifcid != ifc->ifcid)){
+			if(u)
+				runlock(ifc);
+
 			xp = a->hold;
 			a->hold = nil;