linux-kernel - Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases

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: <20150709185441.GE7021@wotan.suse.de>
Date:	Thu, 9 Jul 2015 20:54:41 +0200
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	arnd@...db.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
	tglx@...utronix.de, ross.zwisler@...ux.intel.com,
	akpm@...ux-foundation.org, jgross@...e.com, x86@...nel.org,
	toshi.kani@...com, linux-nvdimm@...ts.01.org,
	benh@...nel.crashing.org, konrad.wilk@...cle.com,
	linux-kernel@...r.kernel.org, stefan.bader@...onical.com,
	luto@...capital.net, linux-mm@...ck.org, geert@...ux-m68k.org,
	ralf@...ux-mips.org, hmh@....eng.br, mpe@...erman.id.au,
	tj@...nel.org, paulus@...ba.org, hch@....de
Subject: Re: [PATCH v5 2/6] arch: unify ioremap prototypes and macro aliases

On Mon, Jun 22, 2015 at 04:24:27AM -0400, Dan Williams wrote:
> diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
> index d8f8622fa044..4789b1cec313 100644
> --- a/include/asm-generic/iomap.h
> +++ b/include/asm-generic/iomap.h
> @@ -62,14 +62,6 @@ extern void __iomem *ioport_map(unsigned long port, unsigned int nr);
>  extern void ioport_unmap(void __iomem *);
>  #endif
>  
> -#ifndef ARCH_HAS_IOREMAP_WC
> -#define ioremap_wc ioremap_nocache
> -#endif
> -
> -#ifndef ARCH_HAS_IOREMAP_WT
> -#define ioremap_wt ioremap_nocache
> -#endif
> -
>  #ifdef CONFIG_PCI
>  /* Destroy a virtual mapping cookie for a PCI BAR (memory or IO) */
>  struct pci_dev;

While at it we should also detangle ioremap() variants default implementations
from requiring !CONFIG_MMU, so to be clear, if you have CONFIG_MMU you should
implement ioremap() and iounmap(), then additionally if you have a way to
support an ioremap_*() variant you should do so as well. You can
include asm-generic/iomap.h to help complete ioremap_*() variants you may not
have defined but note below.

***Big fat note**: this however assumes we have a *safe* general ioremap() to
default to for all architectures but for a slew of reasons we cannot have this
today and further discussion is needed to see if it may be possible one day. In
the meantime we must then settle to advocate architecture developers to
provide their own ioremap_*() variant implementations. We can do this two ways:

  1) make new defaults return NULL - to avoid improper behaviour
  2) revisit current default implementations on asm-generic for
     ioremap_*() variants and vet that they are safe for each architecture
     actually using them, if they are safe tuck under each arch its own
     mapping. After all this then convert default to return NULL. This
     will prevent future issues with other architectures.
  3) long term: work towards the lofty objective of defining an architecturally
     sane iorema_*() variant default. This can only be done once all the
     semantics of all the others are well established.

I'll provide a small demo patch with a very specific fix. We can either
address this as separate work prior to your patchset or mesh this work
together.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/