linux-kernel - Re: [PATCH v2 02/22] asm-generic/io.h: add ioremap

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: <20170406170951.GA10520@red-moon>
Date:   Thu, 6 Apr 2017 18:09:51 +0100
From:   Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Bjorn Helgaas <helgaas@...nel.org>, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Arnd Bergmann <arnd@...db.de>,
        Will Deacon <will.deacon@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Richard Henderson <rth@...ddle.net>,
        Tony Luck <tony.luck@...el.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Haavard Skinnemoen <hskinnemoen@...il.com>,
        Pratyush Anand <pratyush.anand@...il.com>,
        Jingoo Han <jingoohan1@...il.com>,
        Mingkai Hu <mingkai.hu@...escale.com>,
        John Garry <john.garry@...wei.com>,
        Tanmay Inamdar <tinamdar@....com>,
        Murali Karicheri <m-karicheri2@...com>,
        Bharat Kumar Gogada <bharat.kumar.gogada@...inx.com>,
        Ray Jui <rjui@...adcom.com>,
        Wenrui Li <wenrui.li@...k-chips.com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Minghuan Lian <minghuan.Lian@...escale.com>,
        Jon Mason <jonmason@...adcom.com>,
        Gabriele Paoloni <gabriele.paoloni@...wei.com>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Michal Simek <michal.simek@...inx.com>,
        Stanimir Varbanov <svarbanov@...sol.com>,
        Zhou Wang <wangzhou1@...ilicon.com>,
        Roy Zang <tie-fei.zang@...escale.com>
Subject: Re: [PATCH v2 02/22] asm-generic/io.h: add ioremap_nopost remap
 interface

On Thu, Apr 06, 2017 at 05:40:16PM +0100, Russell King - ARM Linux wrote:
> On Thu, Apr 06, 2017 at 05:21:56PM +0100, Lorenzo Pieralisi wrote:
> > Ok, so:
> > 
> > (1) I can do asm-generic/ioremap-nopost.h, which I assume you want to
> >     contain something like
> > 
> > static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
> > {
> > 	return ioremap_nocache(offset, size);
> > }
> > 
> > Funny bit is that it has to be included by asm*/io.h files _after_
> > ioremap_nocache has been #defined (that's the reason my approach was
> > failing miserably even on arches like eg powerpc (see [1] below) that
> > does have ioremap_nocache),
> 
> PowerPC does have ioremap_nocache() though:
> 
> /**
>  * ioremap     -   map bus memory into CPU space
> ...
>  * * ioremap_nocache is identical to ioremap
> extern void __iomem *ioremap(phys_addr_t address, unsigned long size);
> #define ioremap_nocache(addr, size)     ioremap((addr), (size))
> 
> and this include file is included very early on in linux/io.h.  I don't
> see anything that conditionalises it on anything except __KERNEL__.  So,
> the report from 0-day really doesn't make any sense to me.
> 
> Do we know how we're ending up in linux/io.h line 169 without having
> picked up the ioremap_nocache() definition provided by PowerPC's
> asm/io.h ?

I will debug it further but I *think* it is because:

eg arch/powerpc/oprofile/op_model_cell.c includes <asm/io.h>

and <asm/io.h> includes <linux/io.h> before ioremap_nocache is defined

> > not sure it is going to be very nice to have
> > an include in the middle of asm*/io.h include files (and I have to patch
> > all arches which I can do).
> 
> You mean like we already have to do with this asm-generic/io.h thing in
> the ARM io.h header file, because we need to define all the accessors
> first, to prevent the asm-generic/io.h thing defining them for us?
> Given how asm-generic has headed in this regard, having include files
> at all sorts of strange locations within the architecture asm/*.h
> header files has become quite normal, unfortunately.

Yes we won't make it any nicer that's for certain, my worry is that
it would end up being even harder to read.

> > (2) I add:
> > 
> > #ifndef ioremap_nopost
> > static inline void __iomem *ioremap_nopost(phys_addr_t offset, size_t size)
> > {
> > 	return NULL; <-(making it return ioremap_nocache() does not
> > 			work, see [1] for the reason)
> > }
> > #endif
> > 
> > in linux/io.h
> 
> ... which breaks the kernel if ioremap_nopost is missing from the arch
> header, and one of the drivers that you're modifying to use this new
> ioremap variant happens to be built and used on such an architecture.

Yes agree.

> > (3) ioremap_nopost follows Luis' ioremap_uc approach
> 
> Same problem as (2), as I understand correctly.

Agreed. We have to find the lesser evil, that's it.

Thanks !
Lorenzo