linux-kernel - Re: [PATCH] libata-sff: Don't call bmdma

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: <1170025283.26655.101.camel@localhost.localdomain>
Date:	Mon, 29 Jan 2007 10:01:23 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jgarzik@...ox.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Alan <alan@...rguk.ukuu.org.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] libata-sff: Don't call bmdma_stop on non DMA capable
	controllers

> However, in all honesty, we have triggered bugs in that area too, simply 
> because some driver code "knew" that PIO addresses could fit in 16 bits, 
> and used u16 or "unsigned short" to remember the PIO address. Both ARM and 
> Sparc was bitten by this, although usually the issue is trivial to fix 
> once found.
> 
> Also, many ISA-only drivers actually have hardcoded PIO numbers (eg 
> "0x1f0").
> 
> But yes, I would generally suggest that architectures where the PIO range 
> is really just another magic MMIO range (which is most of the non-x86 
> world, as you point out) might as well at least aim for doing the 
> remapping early (ie with "pci_resource_start()")
> 
> Making that easy was one of my goals for the "new" IO accessor functions, 
> in fact.
> 
> Not that many people actually use them.

Well, as I said, I prefer keeping PIO numbers 0 based so that legacy
crap works. If 0 is to be illegal, then remap any devive that's sitting
there, but don't do weirder remapping tricks than necessary ;-) 

Note that on PowerPC, we do actually remap PIO on non-primary busses
(well, we have to since we have to present a flat space to inx/outx).

What we do there is basically we "pick" a bus as beeing primary
(typically the one that has an ISA bridge and/or SuperIO on it) and
that's the one that gets PIO 0. Resources for device on that domain
aren't fixed up.

All other ones are fixed up in such a way that pointer arithmeric gives
you an inx/outx landing in the right spot for PCI devices.

> So *if* you use the new "iomap" interfaces, and the new "pci_iomap()" 
> things, that should actually not just allow drivers (like the ATA layer) 
> to share much more code between the PIO and MMIO cases, but it hopefully 
> actually makes it easier for strange architectures to do it all.

Yes. Though adoption of iomap is a bit slow on the driver side of
things.

> So traditionally, we've had PIO be "limited integer addresses, and some 
> drivers know magic numbers", but hopefully new drivers could at least try 
> to use some of the infrastructure where we try to help people not have to 
> deal with it so much as a special case any more.

Well, hopefully new drivers don't need PIO as it's about time people
stop releasing devices that do PIO, bloody hell ! That should have been
"deprecated use for compatibility only" from day #1 :-) In fact, if I'm
not mistaken, the PCI spec mandates that device should have an MMIO way
of doing everything that can be done via PIO nowadays no ?

Ben.

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