Dan Malek writes: > > Hitting a BUG() would be more appropriate in these cases. > > I know, but the higher level functions are sufficiently disjoint that you > can't keep context across them to know if someone is doing something bad. > I guess we could just check for an address in the VMALLOC space and not > translate that, but then I'll get criticized for adding code into that > fast virt_to_* path :-)
Not by me, doing a range check in virt_to_* would be perfectly appropriate. > You also don't know, in the case of noncoherent > processors, that the virtual mapping you received is from a 'vmalloc' > space, even though it was done properly for DMA. It's one thing to call > vmalloc() and try to do DMA, and it's another to use an alternate mapping > to properly implement a feature under a standard interface. Drivers shouldn't be doing virt_to_* on the address they get from a consistent-alloc function. Given that doing it the right way is easy (just remember the physical address that the consistent alloc function gives you) I don't have any qualms about breaking drivers that do it the wrong way. (I should note that I'm not intending to break them in 2.4, not even in 2_4_devel; virt_to_* can continue to use iopa there. But in 2.5 we can be more brutal.) > So, just toss iopa(), use the macros in their standard way, and see how > long we run before the system crashes (SCSI drivers, eepro100,... :-) There is the issue of making sure that we don't have DMA buffers and other variables in the same cache line. This is being thrashed out on linux-kernel at the moment. :) Paul. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/