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, 25 Jul 2018 18:14:20 +0530
From:   Suresh Kumar Reddy Reddygari <suresh.reddy@...adcom.com>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] be2net: Collect the transmit queue data in
 Tx timeout

On Mon, Jul 23, 2018 at 11:53 PM, David Miller <davem@...emloft.net> wrote:
> 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.

The current patch does recover from a TX-timeout by resetting the chip itself
that *includes* resetting the TX block. Freeing up TX SKBs and rings and
re-creating/registering them is also being done.

Now, this recovery is not supported in  BE3 and Skyhawk NICs but is supported
in Lancer NICs. That's why this patch performs recovery in the case of
Lancer NICs
but only gathers diagnostic information in the case of BE3 and Skyhawk NICs.

Regards,
Suresh.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ