linux-kernel - RE: [PATCH net-next RFC 3/9] net: dsa: mv88e6xxx: add support for GPIO configuration

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]

Date:   Fri, 29 Sep 2017 15:30:08 +0000
From:   Brandon Streiff <brandon.streiff@...com>
To:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
        Richard Cochran <richardcochran@...il.com>,
        Erik Hons <erik.hons@...com>
Subject: RE: [PATCH net-next RFC 3/9] net: dsa: mv88e6xxx: add support for
 GPIO configuration

> From: Andrew Lunn [mailto:andrew@...n.ch]
> Sent: Thursday, September 28, 2017 1:01 PM
>
> > With the write and read acquiring and then releasing the lock
> > immediately, is no there room for this sequence to be interrupted in the
> > middle and end-up returning inconsistent reads?
> 
> The general pattern in this code is that the lock chip->reg_lock is
> taken at a higher level. That protects against other threads. The
> driver tends to do that at the highest levels, at the entry points
> into the driver. I've not yet checked this code follows the pattern
> yet. However, we have a check in the low level to ensure the lock has
> been taken. So it seems likely the lock is held.

Yes, the expectation here is that an upper layer takes the reg_lock. All the functions in ptp.c that call this function do that. If they did not, then assert_reg_lock() gets very angry. :)

Perhaps using __must_hold() and similar annotations would also help document the requirements, but we don't seem to use those in this driver today.
 
-- brandon