linux-kernel - Re: [v11,1/4] drivers: jtag: Add JTAG core driver

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

Message-ID: <20171114111916.GO12318@n2100.armlinux.org.uk>
Date:   Tue, 14 Nov 2017 11:19:16 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
Cc:     Oleksandr Shamray <oleksandrs@...lanox.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "jiri@...nulli.us" <jiri@...nulli.us>,
        'Chip Bilbrey' <chip@...brey.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "openbmc@...ts.ozlabs.org" <openbmc@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "openocd-devel-owner@...ts.sourceforge.net" 
        <openocd-devel-owner@...ts.sourceforge.net>,
        "mec@...ut.net" <mec@...ut.net>, Jiri Pirko <jiri@...lanox.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "joel@....id.au" <joel@....id.au>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "tklauser@...tanz.ch" <tklauser@...tanz.ch>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [v11,1/4] drivers: jtag: Add JTAG core driver

On Tue, Nov 14, 2017 at 12:10:46PM +0100, gregkh@...uxfoundation.org wrote:
> On Tue, Nov 14, 2017 at 10:34:49AM +0000, Oleksandr Shamray wrote:
> > Greg, what you can suggest about it. May be better to add again single-open()-per-device lock with right locking way like:
> > 
> > >if (mutex_lock_interruptible(&jtag->open_lock)) {
> 
> You would stall an open?  Why not just return saying you can't do that?

Greg, I think you need to look at the code again.

>From the snippet in the email, this lock is not held while the device is
open, as you apparently think it is.  It's a short-term lock that is
held to ensure atomic access to the jtag->opened member, so that two
concurrent opens are unable to operate lock-step, resulting in
jtag->opened becoming 2.

The open function snippet in the email drops the lock as soon as it has
incremented jtag->opened, or encounters an error.

It seems entirely sensible, rather than using an atomic_t counter, as
it means that other openers are held off until the current opener has
either succeeded in opening the device or failed to open it.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up