netdev - Re: [PATCH net-next 2/2] r8152: adjust rtl_start

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: <20141111.215056.2165761189796303933.davem@davemloft.net>
Date:	Tue, 11 Nov 2014 21:50:56 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	hayeswang@...ltek.com
Cc:	netdev@...r.kernel.org, nic_swsd@...ltek.com,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [PATCH net-next 2/2] r8152: adjust rtl_start_rx

From: Hayes Wang <hayeswang@...ltek.com>
Date: Mon, 10 Nov 2014 03:29:27 +0000

> The behavior is different for PCI(e) and USB ethernet device.
> The PCI nic could know the ring buffer by certain way, so
> the device could fill the data into the buffer one by one
> automatically. However, for usb nic, the driver has to
> indicate (i.e. submit) each buffer for each data. The device
> doesn't know what is the next buffer by itself. That is,
> the driver determines the order by which the data would be
> filled.
> 
> Therefore, when I try to submit 10 rx buffers and some of
> them fail, I could get the data depending on the order of
> the successful ones. Besides, the driver has to submit the
> buffer for next data continually, so the previous unsuccessful
> ones could be tried again for the same time.

Ok, but if we are looping here in rtl_start_rx() and r8152_submit_rx()
fails due to a memory allocation failure, there is nothing which is
going to make such a memory allocation succeed in the next iteration
of the loop.

Unless you can prove that often it can succeed after an initial
failure, this is just wasted work and in fact making it take longer
for the system to reclaim memory when under pressure because these
extra iterations are completely wasted cpu work.
--
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