netdev - Re: [PATCH v3 5/6] net: calxedaxgmac: rework transmit ring handling

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:	Tue, 06 Nov 2012 18:29:11 -0600
From:	Rob Herring <rob.herring@...xeda.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH v3 5/6] net: calxedaxgmac: rework transmit ring handling

David,

On 11/06/2012 05:57 PM, David Miller wrote:
> From: Rob Herring <robherring2@...il.com>
> Date: Mon,  5 Nov 2012 10:22:23 -0600
> 
>> Only generate tx interrupts on every ring size / 4 descriptors.
> 
> I thought we told you that you cannot do this.
> 
> With this change if we get a few packets, then stop generating any
> traffic, there will be SKBs that just sit dead in your TX queue.

And as I previously mentioned, we do get a tx complete interrupt in
addition. The h/w will interrupt when all packets are transmitted and
there is not another descriptor ready. That is the only tx interrupt we
get without this patch. With this patch, we will get interrupts for
every N descriptors in addition to a tx complete/idle interrupt. This
patch is to avoid the transmitter from going idle and only refilling the
tx ring after finishing sending all frames. I can repost this patch and
make the commit message more clear, but I don't think there is any
functional change needed. This one is not so important compared to the
rest of the series, so you can just drop it if you still don't agree.

Rob

> 
> This cannot ever happen.  All TX SKBs must be freed up in a short,
> finite, amount of time.  Under all conditions, and in every situation.
> 
> Otherwise memory accounted to sockets is not liberated, and such
> sockets cannot be destroyed or closed.
> 
> SKBs also hold onto other kinds of resources, for which it is critical
> to liberate in a finite amount of time.
> 
> I'm not applying this series, it still needs more 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