netdev - Re: [PATCH] RFC: ptp: add comment about register access race

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

Message-Id: <7fd3c712-4c31-435c-80c1-1e042c9b5999@app.fastmail.com>
Date: Tue, 04 Mar 2025 09:24:35 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Richard Cochran" <richardcochran@...il.com>,
 "Andy Shevchenko" <andriy.shevchenko@...ux.intel.com>
Cc: "Arnd Bergmann" <arnd@...nel.org>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 "Andrew Lunn" <andrew+netdev@...n.ch>,
 "David S . Miller" <davem@...emloft.net>,
 "Eric Dumazet" <edumazet@...gle.com>, "Jakub Kicinski" <kuba@...nel.org>,
 "Paolo Abeni" <pabeni@...hat.com>, "Tianfei Zhang" <tianfei.zhang@...el.com>,
 "Jonathan Lemon" <jonathan.lemon@...il.com>,
 "Vadim Fedorenko" <vadim.fedorenko@...ux.dev>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 Thomas Weißschuh <linux@...ssschuh.net>,
 "Calvin Owens" <calvin@...nvd.org>, "Philipp Stanner" <pstanner@...hat.com>,
 Netdev <netdev@...r.kernel.org>, linux-kernel@...r.kernel.org,
 linux-fpga@...r.kernel.org
Subject: Re: [PATCH] RFC: ptp: add comment about register access race

On Tue, Mar 4, 2025, at 05:09, Richard Cochran wrote:
> On Mon, Mar 03, 2025 at 09:50:01AM +0200, Andy Shevchenko wrote:
>> Perhaps it's still good to have a comment, but rephrase it that the code is
>> questionable depending on the HW behaviour that needs to be checked.
>
> IIRC both ixp4xx and the PCH are the same design and latch high reg on
> read of low.

Ok, if that's a common thing, let's assume that the drivers are
all correct for the respective hardware and discard my patch.

With the patch I have queued up in the asm-generic tree, the
behavior changes so ioread64_lo_hi() no longer gets turned
into a single 64-bit access, and that is then more likely to
be correct for both 32-bit and 64-bit architectures in case the
device doesn't actually implement 64-bit transactions but does
correctly latch the contents.

      Arnd