netdev - RE: [PATCH] vmxnet3: fix starving rx ring when alloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <03E840D17E263A48A5766AD576E0423A012911782E@exch-mbx-111.vmware.com>
Date:	Thu, 16 Jun 2011 21:40:15 -0700
From:	Scott Goldman <scottjg@...are.com>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"pv-drivers@...are.com" <pv-drivers@...are.com>
Subject: RE: [PATCH] vmxnet3: fix starving rx ring when alloc_skb fails

Hi David. 

> This is why other drivers allocate the replacement skb _first_ before
> handing the current receive packet to the stack.
> 
> And if the replacement allocation fails, they elide passing the packet
> to the stack, and instead recycle it back onto the RX ring.
> 
> Please implement your RX policy in this manner, as we advise all Linux
> networking drivers to, and you simply won't have this problem.

I'm sorry if my patch description was unclear, but as I understand it, what you are describing is what this patch implements. The patched rx handler does something like:
1) poll the rx ring, peel off a pending skb (don't pass the packet up the stack yet)
2) if the ring needs to be repopulated, we do that
3) if the ring was repopulated successfully, then that's great, and we pass up the pending skb to the network stack.
4) if not and there are no skbs left on the ring, we reuse the pending skb and recycle it back on the ring (effectively dropping the packet we were about to pass up to the network stack)

Maybe the code structure is a bit unclear? Since we don't always repopulate the ring every iteration (only when we hit a low watermark), it's true that we don't strictly always allocate a new skb before passing up the old one, but since this is only a problem when there are no skbs on the ring, and we do elide passing up the pending skb in this case, is that not ok?

thanks,
-sjg--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html