[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1377025368.13829.21.camel@jlt4.sipsolutions.net>
Date: Tue, 20 Aug 2013 21:02:48 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Hugh Dickins <hughd@...gle.com>
Cc: Ding Tianhong <dingtianhong@...wei.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg KH <gregkh@...uxfoundation.org>,
"David S. Miller" <davem@...emloft.net>,
"Otcheretianski, Andrei" <andrei.otcheretianski@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
Pravin B Shelar <pshelar@...ira.com>,
Thomas Graf <tgraf@...g.ch>
Subject: Re: 3.11-rc6 genetlink locking fix offends lockdep
On Tue, 2013-08-20 at 10:28 +0200, Johannes Berg wrote:
> The only way to fix this that I see right now (that doesn't rewrite the
> locking completely) would be to make genetlink use parallel_ops itself,
> thereby removing the genl_lock() in genl_rcv_msg() and breaking all
> those lock chains that lockdep reported. After that, it should be safe
> to use genl_lock() inside all the operations. Something like the patch
> below, perhaps? Completely untested so far.
Tested now, and it still causes lockdep to complain, though that's a
lockdep issue I believe, it thinks that genl_mutex and nlk->cb_mutex can
be inverted although nlk->cb_mutex exists per family, so we need to
annotate lockdep there.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists