netdev - Re: [PATCH net-next] bnx2x: Revising locking scheme for MAC configuration

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: <20130801.155659.2230904456508730148.davem@davemloft.net>
Date:	Thu, 01 Aug 2013 15:56:59 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	yuvalmin@...adcom.com
Cc:	netdev@...r.kernel.org, ariele@...adcom.com, eilong@...adcom.com
Subject: Re: [PATCH net-next] bnx2x: Revising locking scheme for MAC
 configuration

From: "Yuval Mintz" <yuvalmin@...adcom.com>
Date: Thu, 1 Aug 2013 17:30:59 +0300

> On very rare occasions, repeated load/unload stress test in the presence of
> our storage driver (bnx2i/bnx2fc) causes a kernel panic in bnx2x code
> (NULL pointer dereference). Stack traces indicate the issue happens during MAC
> configuration; thorough code review showed that indeed several races exist
> in which one thread can iterate over the list of configured MACs while another
> deletes entries from the same list.
> 
> This patch adds a varient on the single-writer/Multiple-reader lock mechanism -
> It utilizes an already exsiting bottom-half lock, using it so that Whenever
> a writer is unable to continue due to the existence of another writer/reader,
> it pends its request for future deliverance.
> The writer / last readers will check for the existence of such requests and
> perform them instead of the original initiator.
> This prevents the writer from having to sleep while waiting for the lock
> to be accessible, which might cause deadlocks given the locks already
> held by the writer.
> 
> Another result of this patch is that setting of Rx Mode is now made in
> sleepable context - Setting of Rx Mode is made under a bottom-half lock, which
> was always nontrivial for the bnx2x driver, as the HW/FW configuration requires
> wait for completions.
> Since sleep was impossible (due to the sleepless-context), various mechanisms
> were utilized to prevent the calling thread from sleep, but the truth was that
> when the caller thread (i.e, the one calling ndo_set_rx_mode()) returned, the
> Rx mode was still not set in HW/FW.
> 
> bnx2x_set_rx_mode() will now overtly schedule for the Rx changes to be
> configured by the sp_rtnl_task which hold the RTNL lock and is sleepable
> context. 
> 
> Signed-off-by: Yuval Mintz <yuvalmin@...adcom.com>
> Signed-off-by: Ariel Elior <ariele@...adcom.com>
> Signed-off-by: Eilon Greenstein <eilong@...adcom.com>

Applied to net-next, thanks.
--
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