[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87o9ws6m4s.fsf@gmail.com>
Date: Thu, 23 Mar 2017 16:36:19 +0100
From: Nicolai Stange <nicstange@...il.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
Nicolai Stange <nicstange@...il.com>,
"Paul E.McKenney" <paulmck@...ux.vnet.ibm.com>,
gregkh <gregkh@...uxfoundation.org>
Subject: Re: deadlock in synchronize_srcu() in debugfs?
Hi Johannes,
On Thu, Mar 23 2017, Johannes Berg wrote:
> Before I go hunting - has anyone seen a deadlock in synchronize_srcu()
> in debugfs_remove() before?
Not yet. How reproducible is this?
> We're observing that with our (backported, but very recent) driver
> against 4.9 (and 4.10, I think),
Do I understand it correctly that this driver has been backported from
4.11-rcX to 4.9/10 and that there isn't any issue with 4.11-rcX?
> but there are no backports of any debugfs things so the backport
> itself doesn't seem like a likely problem.
Right, there haven't been any SRCU related changes to debugfs after
4.8.
> sysrq-w shows a lot of tasks blocked on various locks (e.g. RTNL), but
> the ultimate problem is the wireless stack getting blocked on
> debugfs_remove_recursive(), in __synchronize_srcu(), in
> wait_for_completion() (while holding lots of locks, hence the other
> tasks getting stuck).
Could you share a complete backtrace? For example, is the
debugfs_remove_recursive() called from any debugfs file's fops and thus,
possibly from within a SRCU read side critical section?
Thanks,
Nicolai
Powered by blists - more mailing lists