linux-kernel - Re: About commit "io: change inX() to have their own IO barrier overrides"

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Feb 2020 18:57:01 -0500
From:   Sinan Kaya <okaya@...nel.org>
To:     John Garry <john.garry@...wei.com>, Arnd Bergmann <arnd@...db.de>
Cc:     "xuwei (O)" <xuwei5@...ilicon.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>
Subject: Re: About commit "io: change inX() to have their own IO barrier
 overrides"

Hi John,

On 2/28/2020 4:52 AM, John Garry wrote:
> About the commit in the $subject 87fe2d543f81, would there be any
> specific reason why the logic pio versions of these functions did not
> get the same treatment or should not? I'm talking about lib/logic_pio.c
> here - commit 031e3601869c ("lib: Add generic PIO mapping method")
> introduced this.
> 
> In fact, logic pio will override these for arm64 with the vanilla
> defconfig these days.

We only looked at inX()/inY() and readX()/writeX() API because the
semantics of these API are defined in the kernel documentation.
We looked at how to generalize this so that there is a uniform
behavior across different architectures.

Is logic PIO subject to ordering issues?
How is the behavior on different architectures?

As long as the expectations are set, I see no reason why it shouldn't
but, I'll let Arnd comment on it too.

Sinan