Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this

[Jamie Lokier]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/