netdev - Re: [PATCH 1/1] net-next/hinic:optmize rx refill buffer mechanism

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] [day] [month] [year] [list]

Message-Id: <20181215.113124.804119837626697932.davem@davemloft.net>
Date:   Sat, 15 Dec 2018 11:31:24 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     xuechaojing@...wei.com
Cc:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        wulike1@...wei.com, chiqijun@...wei.com, fy.wang@...wei.com,
        tony.qu@...wei.com, luoshaokai@...wei.com
Subject: Re: [PATCH 1/1] net-next/hinic:optmize rx refill buffer mechanism

From: Xue Chaojing <xuechaojing@...wei.com>
Date: Sun, 9 Dec 2018 19:14:19 +0000

> There is no need to schedule a different tasklet for refill,
> This patch remove it.
> 
> Suggested-by: Neil Horman <nhorman@...hat.com>
> Signed-off-by: Xue Chaojing <xuechaojing@...wei.com>

I completely agree with Neil's analysis.

You should never receive a packet if refilling the ring entry
resources fails.

It is so dangerous to allow the RX ring to reach an empty state,
not only does it mean that the device will stop receiving frames
but also this is probably one of the least tested conditions in
ring based networking designs and it proabably has bugs that hang
the chip and require a HW reset to recover from.