lkml.org 
[lkml]   [2003]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: x86, ARM, PARISC, PPC, MIPS and Sparc folks please run this
On Mon, 1 Sep 2003 07:42:31 +0100
Jamie Lokier <jamie@shareable.org> wrote:

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

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.

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

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

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

\
 
 \ /
  Last update: 2005-03-22 13:48    [W:0.149 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site