linux-kernel - Re: [PATCHv2 01/10] net: eth: altera: tse_start_xmit ignores tx

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: <20200504.103935.1584665284135386530.davem@davemloft.net>
Date:   Mon, 04 May 2020 10:39:35 -0700 (PDT)
From:   David Miller <davem@...emloft.net>
To:     joyce.ooi@...el.com
Cc:     thor.thayer@...ux.intel.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, dalon.westergreen@...el.com,
        ley.foon.tan@...el.com, chin.liang.see@...el.com,
        dinh.nguyen@...el.com
Subject: Re: [PATCHv2 01/10] net: eth: altera: tse_start_xmit ignores
 tx_buffer call response

From: Joyce Ooi <joyce.ooi@...el.com>
Date: Mon,  4 May 2020 16:25:49 +0800

> The return from tx_buffer call in tse_start_xmit is
> inapropriately ignored.  tse_buffer calls should return
> 0 for success or NETDEV_TX_BUSY.  tse_start_xmit should
> return not report a successful transmit when the tse_buffer
> call returns an error condition.

>From driver.txt:

====================
1) The ndo_start_xmit method must not return NETDEV_TX_BUSY under
   any normal circumstances.  It is considered a hard error unless
   there is no way your device can tell ahead of time when it's
   transmit function will become busy.
====================

The problem is that when you return this error code, something has
to trigger restarting the transmit queue to start sending packets
to your device again.  The usual mechanism is waking the transmit
queue, but it's obviously already awake since your transmit routine
is being called.  Therefore nothing will reliably restart the queue
when you return this error code.

The best thing to do honestly is to drop the packet and return
NETDEV_TX_OK, meanwhile bumping a statistic counter to record this
event.