Messages in this thread | | | From | "Stephen C. Tweedie" <> | Date | Fri, 2 Apr 1999 22:07:05 +0100 (BST) | Subject | Re: Address spaces on a i386 - Getting Confused (fwd) |
| |
Hi,
On Thu, 1 Apr 1999 03:55:41 +0200, Jamie Lokier <lkd@tantalophile.demon.co.uk> said:
> What if I do > (a) mmap(/dev/fb) > (b) read file into mmaped area.
> This is currently valid: anything the CPU can read/write is fair game > for a system call. And /dev/fb is a fairly sane device.
/dev/fb in principle is fine.
> /dev/ramdisk is another, that needn't be in the kernel address range.
Block devices are not mmapable, so there is no issue here.
> Currently But the pte entries will not point to addresses which are > valid kernel addresses.
They _are_ valid physical addresses in every case.
> It can be detected but you must make a point of doing so for safety.
We already do so.
Jamie, there are actually two sets of macros for doing phys/virt address translation on Intel. The __io_phys and __io_virt macros in asm-i386/io.h use bitops to convert between the addressp spaces, but in asm-i386/page.h, __va and __pa use only addition and subtraction. All the VM checks for page addresses use MAP_NR() and pte_page(), both of which are coded using __va/__pa, so we can never confuse a valid physical address with an IO region address in the PCI upper memory.
>> Again, we're using exactly the same techniques which (say) ptrace uses >> to walk the user VA. It had _better_ work!
> Nice detective work, us :-) > -- ptrace has exactly this bug. No-one noticed yet.
Actually, I'm not sure that ptrace is even defined for mmaps of such devices, so I don't think there will be a problem here. As you noticed, the code
if (MAP_NR(page) >= max_mapnr) return 0;
in the ptrace functions will deal with this quite safely. However, for mmap()ed ISA-hole addresses, ptrace will just go ahead and do the memory access anyway, which is inconsistent I agree, but it's not necessarily _wrong_!
> No, memory-mapped devices don't have kernel virtual addresses in their > ptes, however they are still fair game for system calls. The kernel, > for the most part, is fine with that.
> It looks like, for your purposes, it is easy enough to detect this and > fall back to not doing direct DMA.
For now, yes.
> It is not so easy for me as I wish to support DMA transparently between > devices the way that bttv -> framebuffer does it now.
Me too. It gets worse: I really want to be able to do block device IO anywhere in the first 4G of physical memory. That suddenly requires that bh->b_data must support virt_to_phys() operations correctly for any physical memory. Ultimately that is something we can deal with, but it does complicate matters and reqquires us to live with temporary virt/phys mappings for IOs in progress.
> Agreed 100%. Your strategy is brilliant! Avoid the general problem :-)
Heck yes, every time. :) Ultimately if we can do the dynamic mapping issue right (and I've spoken to Linus about this, there _are_ ways we can deal with this) then dma to/from framebuffer becomes possible.
>> Converting a virtual address to a bus >> address is a standard function in the architecture-dependent code.
> I disagree -- in the general case of "an address visible to the kernel", > such as vmalloc() memory, this is a prominently absent standard > function.
vmalloc as a special case is one case which is completely out of the scope of this project: we _always_ have a physical address to start off with, as a that is what we get from the pte. Whether it was vmalloced or not in the first place, we always start this particular part of the problem with a canonical physical address and the only problem is how do we make sure that we can also deal with it as a virtual address which is what bh->b_data needs. (For things like programmed IO, we *must* have a viable virtual address for the duration of the IO, but there's no need to have that virtual address persist after the IO.)
>> OK, we probably need to talk about this offline. I'll follow up on this >> tomorrow.
> Me need sleep. Real bad :) Moving house later :)
Good luck!
--Stephen
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |