From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757305AbcAJPnc (ORCPT ); Sun, 10 Jan 2016 10:43:32 -0500 Received: from mail-wm0-f66.google.com ([74.125.82.66]:35744 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757124AbcAJPna (ORCPT ); Sun, 10 Jan 2016 10:43:30 -0500 Date: Sun, 10 Jan 2016 16:43:26 +0100 From: Rabin Vincent To: Mathieu Poirier Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH V7 02/24] coresight: associating path with session rather than tracer Message-ID: <20160110154326.GB13903@debian> References: <1450472361-426-1-git-send-email-mathieu.poirier@linaro.org> <1450472361-426-3-git-send-email-mathieu.poirier@linaro.org> <20151220152939.GA11552@debian> <20160105131505.GA32528@debian> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 05, 2016 at 03:23:20PM -0700, Mathieu Poirier wrote: > On 5 January 2016 at 06:15, Rabin Vincent wrote: > > The command sequence is exactly as mentioned above. The kernel is > > v4.4rc-8 + all your patches from this thread + the OMAP coresight patch > > I mentioned earlier. > > What patch was that? Would mind providing me with more information? http://www.spinics.net/lists/kernel/msg2150809.html > I fixed the kmalloc bug - it stemmed from a rebase conflict in the > etm3x driver. On the flip side I haven't been able to reproduce the > lockdep problem. But looking at the log you provided I can understand > why the kernel is complaining. > > I produced a patch [1] and added you as a reporter. It would be great > if you could give it a quick spin to see if the problem still persist. > [1]. https://git.linaro.org/people/mathieu.poirier/coresight.git/commit/914353d1b625eccb0d1dda71047408a52f8811d3 It does silence the warning but simply using mutex_trylock() instead of mutex_lock() does not seem like the correct fix. The lock dependency problem lockdep is complaining about can be fixed for example by not holding the coresight_mutex around the device_unregister() coresight_unregister(). I don't quite see what the mutex is protecting there? BTW, there seem to be several problems with the unregistration: - csdev->refcnt which is allocated with kcalloc() in coresight_register() is never freed. - csdev->conns is freed before device_unregister() rather than in the release function. - put_device() is not done on the csdev' conn->child_devs when it is unregistered, so the reference taken by the bus_find_device() in coresight_fixup_device_conns() is never released. - There is no reference taken for the csdev when it is assigned as some other device's child_dev in coresight_orphan_match()