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: <20110617.001610.2160676566738613200.davem@davemloft.net>
Date:	Fri, 17 Jun 2011 00:16:10 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	scottjg@...are.com
Cc:	netdev@...r.kernel.org, pv-drivers@...are.com
Subject: Re: [PATCH] vmxnet3: fix starving rx ring when alloc_skb fails

From: "Scott J. Goldman" <scottjg@...are.com>
Date: Thu, 16 Jun 2011 15:02:27 -0700

> if the rx ring is completely empty, then the device may never fire an rx
> interrupt. unfortunately, the rx interrupt is what triggers populating
> the rx ring with fresh buffers, so this will cause networking to lock
> up.
> 
> this patch recycles the last skb that we were about to indicate up to
> the network stack (only if the rx ring is completely starved of skbs)
> so the ring will never be completely empty. If we fail to allocate a
> secondary page buffer, we just indicate a 0 length buffer to the device.
> 
> Signed-off-by: Scott J. Goldman <scottjg@...are.com>

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.
--
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