linux-kernel - Re: [PATCH V7 02/24] coresight: associating path with session rather than tracer

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-next>] [day] [month] [year] [list]

Message-ID: <20160110154326.GB13903@debian>
Date:	Sun, 10 Jan 2016 16:43:26 +0100
From:	Rabin Vincent <rabin@....in>
To:	Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH V7 02/24] coresight: associating path with session rather
 than tracer

On Tue, Jan 05, 2016 at 03:23:20PM -0700, Mathieu Poirier wrote:
> On 5 January 2016 at 06:15, Rabin Vincent <rabin@....in> 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()