linux-kernel - Re: [PATCH 1/2] asm-generic: io: remove {read,write} string functions

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: <20120427171433.GE14743@mudshark.cambridge.arm.com>
Date:	Fri, 27 Apr 2012 18:14:33 +0100
From:	Will Deacon <will.deacon@....com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"uclinux-dist-devel@...ckfin.uclinux.org" 
	<uclinux-dist-devel@...ckfin.uclinux.org>,
	Arnd Bergmann <arnd@...db.de>,
	Mike Frysinger <vapier@...too.org>
Subject: Re: [PATCH 1/2] asm-generic: io: remove {read,write} string functions

On Fri, Apr 27, 2012 at 05:23:34PM +0100, H. Peter Anvin wrote:
> On 04/27/2012 03:42 AM, Will Deacon wrote:
> > The {read,write}s{b,w,l} functions are not defined across all
> > architectures and therefore shouldn't be used by portable drivers. We
> > should encourage driver writers to use the io{read,write}{8,16,32}_rep
> > functions instead.
> 
> Why is that?  ioread/write are great if the address space is undefined,
> but do we need the extra overhead in any other cases?

I think it's because in reality not many drivers are using
the {read,write}s{b,w,l} accessors:

drivers/bluetooth/btmrvl_sdio.c
drivers/bluetooth/btsdio.c
drivers/i2c/busses/i2c-tegra.c
drivers/mmc/core/sdio_io.c
drivers/mmc/host/msm_sdcc.c
drivers/mmc/host/mvsdio.c
drivers/mmc/host/omap.c
drivers/mmc/host/tmio_mmc.h
drivers/mtd/nand/atmel_nand.c
drivers/mtd/nand/gpio.c
drivers/mtd/nand/omap2.c
drivers/mtd/nand/pxa3xx_nand.c
drivers/mtd/nand/s3c2410.c
drivers/net/ethernet/8390/ax88796.c
drivers/net/ethernet/8390/etherh.c
drivers/net/ethernet/davicom/dm9000.c
drivers/net/ethernet/seeq/ether3.c
drivers/net/ethernet/smsc/smc911x.h
drivers/net/ethernet/smsc/smc91x.h
drivers/net/ethernet/smsc/smsc911x.c
drivers/net/wireless/ath/ath6kl/sdio.c
drivers/net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c
drivers/net/wireless/libertas/if_sdio.c
drivers/net/wireless/mwifiex/sdio.c
drivers/net/wireless/wl12xx/sdio.c
drivers/parport/parport_ip32.c
drivers/pci/hotplug/ibmphp_core.c
drivers/pci/hotplug/ibmphp_ebda.c
drivers/pci/hotplug/ibmphp.h
drivers/pci/hotplug/ibmphp_hpc.c
drivers/scsi/arm/arxescsi.c
drivers/scsi/arm/cumana_2.c
drivers/scsi/arm/oak.c
drivers/ssb/sdio.c
drivers/usb/gadget/at91_udc.c
drivers/usb/gadget/s3c2410_udc.c
drivers/usb/gadget/s3c-hsotg.c
drivers/usb/host/isp1362.h
drivers/usb/musb/am35x.c
drivers/usb/musb/musb_core.c
drivers/usb/musb/musb_io.h
drivers/usb/musb/tusb6010.c

If you remove the architecture-specific drivers, there's really not a lot left
and, even then, we only need to convert those drivers which are intended to
be portable between architectures where the string functions are not
consistently available.

By overheads, I assume you're referring to the IO_COND check on the address
space? I wouldn't expect this to be noticeable compared to the cost of the
I/O access and I'm not sure it's worth worrying about for the sake of the
small number of drivers affected.

Will
--
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/