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

[Jamie Lokier <jamie@shareable.org>]

David S. Miller wrote:
> On Sun, 31 Aug 2003 23:49:37 +0100
> Jamie Lokier <jamie@shareable.org> wrote:
> 
> > It uses POSIX shared memory and (necessarily) MAP_SHARED, which
> > doesn't constrain the mapping alignment.
> 
> That's wrong.  If a platform needs to, it should properly
> align the mapping when MAP_SHARED is used on a file.
> 
> If you look in arch/sparc64/kernel/sys_sparc.c, you'll see
> that when we're mmap()'ing a file and MAP_SHARED is specified,
> we align things to SHMLBA.

Then you have a bug in the Sparc code.  It looks like it should return
-EINVAL when a misaligned mapping is used with MAP_FIXED|MAP_SHARED,
but the test program is clearly getting mappings that aren't aligned
to SHMLBA.

> If userspace purposefully violates this alignment attempt,
> then it's at it's own peril to keep the mappings coherent,
> there is simply nothing the kernel should be doing to help
> out that case.

I understand that userspace needs to keep it coherent, or map to a
multiple of SHMLBA.  I don't mind whether the kernel constrains the
mapping address or not, with a slight preference for userspace
flexibility.

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.

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

	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.

Thanks,
-- Jamie