Messages in this thread | ![/](/images/icornerl.gif) | | Date | Mon, 1 Sep 2003 09:29:11 +0100 | From | Jamie Lokier <> | Subject | Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this |
| |
David S. Miller wrote: > I disagree, MAP_FIXED means "I know what I am doing don't override > this unless the mapping area is not available in my address space." > You should never specify MAP_FIXED unless you _REALLY_ know what you > are doing.
So explain this from the Sparc architecture code:
if (flags & MAP_FIXED) { /* We do not accept a shared mapping if it would violate * cache aliasing constraints. */ if ((flags & MAP_SHARED) && (addr & (SHMLBA - 1))) return -EINVAL; return addr; }
Ok, I'll explain it :) At one time, the code did what the comment says, but nowadays linux/mm/mmap.c doesn't call arch_get_unmapped_area() for MAP_FIXED, so the above code is redundant and misleading. It already mislead me, so please remove it. sparc and sparc64 both have it.
> > Thus I have three Sparc-specific questions: > > > > 1. How does userspace find out the value of SHMLBA? > > On Sparc, it is not a compile-time constant. > > Don't specify MAP_FIXED for MAP_SHARED mapping if you want > proper coherency, that's my answer for this one.
I can't safely set up this kind of mapping without MAP_FIXED, unless I know SHMLBA.
This is my strategy:
mmap MAP_ANON without MAP_FIXED to find a free area mmap MAP_FIXED over the anon area at same address mmap MAP_FIXED over the anon area at larger address
I don't see any strategy that lets me establish this kind of circular mapping on Sparc without either (a) knowing the value of SHMLBA, or (b) risking clobbering another thread's mmap.
> > 3. Is there a kernel bug on Sparc, because the test program > > is either getting mappings that aren't aligned to run time > > SHMLBA, or the kernel's run time SHMLBA value is not correct. > > No, the user is allowed to hang himself with MAP_FIXED. > The bug is in your code :)
Well, my code has no bug because I do run-time tests to see what rubbish the architecture gave me. As we see, they work :)
I don't see any real alternative to doing that. But that's ok, it seems robust and portable. It's a shame about the slow cache flush, because I can sometimes use fast cache flushing to improve my DSP buffering algorithms.
> > 2. Is flushing part of the data cache something I can do from > > userspace? (I'll figure out the exact machine instructions > > myself if I need to do this, but it'd be nice to know if > > it's possible before I have a go). > > There is no efficient way to do this from userspace, only the > kernel has access to the more efficient cache flushing instructions. > You'd need to flush via loads to displace the aliasing cache lines.
Will msync() do it?
Thanks, -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |