Messages in this thread | | | Date | Mon, 1 Sep 2003 07:42:31 +0100 | From | Jamie Lokier <> | Subject | Re: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this |
| |
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 - 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/
| |