netdev - Re: [PATCH] net: mvneta: fix refilling for Rx DMA buffers

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]

Date:	Wed, 15 Jul 2015 15:52:56 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	simon.guinot@...uanux.org
Cc:	thomas.petazzoni@...e-electrons.com, jason@...edaemon.net,
	andrew@...n.ch, gregory.clement@...e-electrons.com,
	sebastian.hesselbarth@...il.com, netdev@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, vdonnefort@...il.com,
	yoann@...lo.fr, stable@...r.kernel.org
Subject: Re: [PATCH] net: mvneta: fix refilling for Rx DMA buffers

From: Simon Guinot <simon.guinot@...uanux.org>
Date: Mon, 13 Jul 2015 00:04:57 +0200

> On some Armada 370-based NAS, I have experimented kernel bugs and
> crashes when the mvneta Ethernet driver fails to refill Rx DMA buffers
> due to memory shortage.
> 
> With the actual code, if the memory allocation fails while refilling a
> Rx DMA buffer, then the corresponding descriptor is let with the address
> of an unmapped DMA buffer already passed to the network stack. Since the
> driver still increments the non-occupied counter for Rx descriptor (if a
> next packet is handled successfully), then the Ethernet controller is
> allowed to reuse the unfilled Rx descriptor...
> 
> As a fix, this patch first refills a Rx descriptor before handling the
> stored data and unmapping the associated Rx DMA buffer. Additionally the
> occupied and non-occupied counters for the Rx descriptors queues are now
> both updated with the rx_done value: the number of descriptors ready to
> be returned to the networking controller. Moreover note that there is no
> point in using different values for this counters because both the
> mvneta driver and the Ethernet controller are unable to handle holes in
> the Rx descriptors queues.
> 
> Signed-off-by: Simon Guinot <simon.guinot@...uanux.org>
> Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP network unit")
> Cc: <stable@...r.kernel.org> # v3.8+
> Tested-by: Yoann Sculo <yoann@...lo.fr>

Failed memory allocations, are normal and if necessary kernel log
messages will be triggered by the core memory allocator.  So there is
zero reason to do anything other than bump the drop counter in your
driver.

If I understand the rest of your logic, if the allocator fails, we
will reuse the original SKB and place it back into the RX ring?
Right?

If not, that's the approach you should be using and it is what we
advise all networking driver authors to do.
--
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