netdev - Re: [PATCH net-next 1/2] be2net: Collect the transmit queue data in Tx timeout

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: <20180723.112313.949079144194651345.davem@davemloft.net>
Date:   Mon, 23 Jul 2018 11:23:13 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     suresh.reddy@...adcom.com
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] be2net: Collect the transmit queue data
 in Tx timeout

From: Suresh Reddy <suresh.reddy@...adcom.com>
Date: Mon, 23 Jul 2018 10:25:23 -0400

> Driver dumps tx_queue, tx_compl, pending SKBs information in tx_timeout.
> This debug data used to idenfiy the cause of the time out.
> 
> Also reset Lancer chip in tx_timeout.
> 
> Signed-off-by: Suresh Reddy <suresh.reddy@...adcom.com>

The purpose of the tx timeout NDO operation is to do whatever is
necessary to handle the TX timeout.

Outputting debugging information is useful, but is secondary.

I see that you do reset the Lancer, but that is far from what really
needs to happen here.

When you get a TX timeout, the hardware is not processing TX ring
entries, nor signalling completion any longer.

Therefore the only way to get things going again is to reset all of
the TX side data structure and logic.  This means shutting down the TX
engine, freeing up all of the TX SKBs in the ring, resetting the TX
ring software state, and then finally reprogramming the head/tail
pointer registers and re-enabling TX DMA processing.