netdev - Re: [PATCH net-next v2 0/5] gianfar: Device reset and reconfig fixes

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: <20140224.193912.2219449920663424370.davem@davemloft.net>
Date:	Mon, 24 Feb 2014 19:39:12 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	claudiu.manoil@...escale.com
Cc:	netdev@...r.kernel.org, ben@...adent.org.uk
Subject: Re: [PATCH net-next v2 0/5] gianfar: Device reset and reconfig
 fixes

From: Claudiu Manoil <claudiu.manoil@...escale.com>
Date: Mon, 24 Feb 2014 12:13:41 +0200

> These patches end up fixing some notable device reset & reconfig
> related problems.  One issue is on-the-fly (Rx/Tx on) programming
> of interrupt coalescing (IC) registers on the processing path,
> against HW recommendation.  This is an old issue that became visible
> after BQL introduction, as under certain conditions (low traffic)
> one TX interrupt gets lost and BQL fires Tx timeout as a result.
> Another notable issue is a race on the Tx path (xmit, clean_tx)
> during device reset (i.e. during Tx timeout watchdog firing)
> that leads to NULL access.
> Fixing the problematic on-thy-fly register writes (i.e. the IC regs)
> required the implementation of a MAC soft reset procedure.
> The race leading to NULL access was addressed by fixing the
> stop_gfar()/startup_gfar() pair (disable/enable napi a.s.o.)
> and adding the device state DOWN to sync with the TX path.
> 
> Thanks.
> --
> v2: Refactored if() clauses from gfar_set_features(), PATCH 2.

Series applied, thanks Claudiu.
--
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