On 11/2/06, Andrew Morton <[email protected]> wrote:
On Thu, 2 Nov 2006 14:44:56 +0000
"Miguel Ojeda" <[email protected]> wrote:
> > Now let's say that some of the kernel frame buffer data are in the
> > data cache and never be invalidate during this example. The
>
> Sorry, I don't understand what do you mean with this sentence.
Some CPU architectures experience what Documentation/cachetlb.txt calls
"virtual aliasing in the data cache".
If you map the same physical page at virtual address A1 and also at another
virtual address A2 then writes to address A1 do not necessarily appear
correctly at address A2. This because the write to A1 is stuck in the CPU
cache and the CPU hardware doesn't know that read from A2 is accessing the
same page.
The solutions to this are:
a) add lots of flushing everywhere (see Documentation/cachetlb.txt, I
guess) (this documentation is maddening: it uses the term "flush" for
both writeback and for invalidation. In this context,
flush==writeback).
b) If you select the correct virtual addresses for A1 and A2 (ie: ensure
that the mmap() handler returns an address which correlates with the
page's kernel address) then apparently the aliasing goes away.
So, for example, if the kernel's view of the page is at 0xd0102000
then you make sure that userspace's address for the page is at
0xnnn02000 (for some length of nnn).
I don't know what the mmap handler has to do to arrange for this to
happen.
c) add `depends on x86' to your Kconfig ;)
I really like portable stuff :)
davem and rmk are (amongst others) the guys for this stuff. afaik it isn't
documented anywhere.
Whoa, thanks you for the long explanation. May 2.6.18-new vmalloc
related functions help correlating userspace & kernel addresses? I
will try them and come with an answer tomorrow.
Quoting http://lwn.net/Articles/2.6-kernel-api/
"Some functions have been added to make it easy for kernel code to
allocate a buffer with vmalloc() and map it into user space. They are:
void *vmalloc_user(unsigned long size);
void *vmalloc_32_user(unsigned long size);
int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
unsigned long pgoff);
The first two functions are a form of vmalloc() which obtain memory
intended to be mapped into user space; among other things, they zero
the entire range to avoid leaking data. vmalloc_32_user() allocates
low memory only. A call to remap_vmalloc_range() will complete the
job; it will refuse, however, to remap memory which has not been
allocated with one of the two functions above."
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
