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

["David S. Miller" <davem@redhat.com>]

On Mon, 1 Sep 2003 09:29:11 +0100
Jamie Lokier <jamie@shareable.org> wrote:

> 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.

I take back what I said, I think the -EINVAL behavior is better
and mmap.c should call into this code to verify the requested
mmap() parameters.

> 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.

Why do you need the same piece of data mapped to multiple places
in the first place, and why at specific addresses?  It's purely an
optimization of some sort, right?

> 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 :)

It doesn't work in just the right set of circumstances, if interrupts
arrive at just the right moment it might flush the bad aliases out
of the cache via displacement during your 'check' phase.

Then during your actual computation you can hit the aliasing problem
silently.

That's just a bad way to do this.

> I don't see any real alternative to doing that.

I'd suggest instead to hardcode the SHMLBA stuff into your sources.

> But that's ok, it seems robust and portable.

Unfortunately, it is anything but robust.

> > 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?

No.