lkml.org 
[lkml]   [1999]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.435 / U:2.376 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site