netdev - Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument

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:   Wed, 8 Jan 2020 09:43:04 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Christophe Leroy <christophe.leroy@....fr>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Rich Felker <dalias@...c.org>,
        Jiri Slaby <jirislaby@...il.com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        David Airlie <airlied@...ux.ie>,
        Jason Wang <jasowang@...hat.com>,
        DRI Development <dri-devel@...ts.freedesktop.org>,
        virtualization@...ts.linux-foundation.org,
        "James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
        netdev <netdev@...r.kernel.org>,
        Paul Mackerras <paulus@...ba.org>,
        Linux-Arch <linux-arch@...r.kernel.org>,
        Dave Jiang <dave.jiang@...el.com>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Helge Deller <deller@....de>,
        Linux-sh list <linux-sh@...r.kernel.org>,
        Alexey Brodkin <abrodkin@...opsys.com>,
        Ben Skeggs <bskeggs@...hat.com>, nouveau@...ts.freedesktop.org,
        Dave Airlie <airlied@...hat.com>,
        Matt Turner <mattst88@...il.com>,
        arcml <linux-snps-arc@...ts.infradead.org>,
        Nick Kossifidis <mickflemm@...il.com>,
        Allen Hubbe <allenbh@...il.com>, Arnd Bergmann <arnd@...db.de>,
        alpha <linux-alpha@...r.kernel.org>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Thomas Gleixner <tglx@...utronix.de>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Kalle Valo <kvalo@...eaurora.org>,
        Richard Henderson <rth@...ddle.net>,
        Parisc List <linux-parisc@...r.kernel.org>,
        Vineet Gupta <vgupta@...opsys.com>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Daniel Vetter <daniel@...ll.ch>, Jon Mason <jdmason@...zu.us>,
        linux-ntb@...glegroups.com,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [RFT 00/13] iomap: Constify ioreadX() iomem argument

Hi Christophe,

On Wed, Jan 8, 2020 at 9:35 AM Christophe Leroy <christophe.leroy@....fr> wrote:
> Le 08/01/2020 à 09:18, Krzysztof Kozlowski a écrit :
> > On Wed, 8 Jan 2020 at 09:13, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> >> On Wed, Jan 8, 2020 at 9:07 AM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> >>> On Tue, Jan 7, 2020 at 5:53 PM Krzysztof Kozlowski <krzk@...nel.org> wrote:
> >>>> The ioread8/16/32() and others have inconsistent interface among the
> >>>> architectures: some taking address as const, some not.
> >>>>
> >>>> It seems there is nothing really stopping all of them to take
> >>>> pointer to const.
> >>>
> >>> Shouldn't all of them take const volatile __iomem pointers?
> >>> It seems the "volatile" is missing from all but the implementations in
> >>> include/asm-generic/io.h.
> >>
> >> As my "volatile" comment applies to iowrite*(), too, probably that should be
> >> done in a separate patch.
> >>
> >> Hence with patches 1-5 squashed, and for patches 11-13:
> >> Reviewed-by: Geert Uytterhoeven <geert+renesas@...der.be>
> >
> > I'll add to this one also changes to ioreadX_rep() and add another
> > patch for volatile for reads and writes. I guess your review will be
> > appreciated once more because of ioreadX_rep()
>
> volatile should really only be used where deemed necessary:
>
> https://www.kernel.org/doc/html/latest/process/volatile-considered-harmful.html
>
> It is said: " ...  accessor functions might use volatile on
> architectures where direct I/O memory access does work. Essentially,
> each accessor call becomes a little critical section on its own and
> ensures that the access happens as expected by the programmer."

That is exactly the use case here: all above are accessor functions.

Why would ioreadX() not need volatile, while readY() does?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds