lkml.org 
[lkml]   [2001]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: mmap not working?
Date
From
H. Peter Anvin wrote:
> Rogier Wolff wrote:
>
> >
> > I know about TLBs. I know how they work, and I think I've explained it
> > well enough that rereading my message should allow you to understand
> > what I'm saying. Still, let me try to picture it...
> >
> > Situation A:
> >
> > physical map. XX is the interesting part, | is a page boundary, = is
> > "uninteresting stuff".
> >
> > |========|XX======|========|========|========|
> >
> > virtual map:
> >
> > |--------|XX======|--------|--------|--------|
> > ^
> > | This is the pointer that mmap returns.
> >
> > - is "unmapped".
> >
> >
> > Situation B:
> >
> > |========|======XX|========|========|========|
> >
> > virtual map:
> >
> > |--------|======XX|--------|--------|--------|
> > ^
> > | This is the pointer that mmap returns.
> >
> > In Situation A I get the 1K mapped that I wanted and 3 more because
> > the MMU can't NOT give me access to that. Situation B is exactly the
> > same, except that I get those extra 3K in front of the pointer
> > that I get returned by mmap.
> >
>
>
> Just make the adjustment in userspace, if your application really can
> handle it. This is never going to fly generically (and therefore not
> get integrated into anything), because the PCI BIOS will typically map
> multiple things into that 4K chunk, and thus you have opened up your
> system to messing with a completely "innocent" device.
>
> Since the only way is to avoid this involves moving your device to its
> own 4K chunk of I/O space anyway, you don't really have a choice.

There is this application that was written in '91-93 that works in
situation A and not in situation B. It follows the ruls from "mmap"(*),
but the kernel just doesn't do the obvious thing.

If I address something before my 1k window, in situation A, I'll get a
segfault. If I address something beyond my 1k window in situation B
I'll get a segfault.

If I address something after my 1k window in situation A, I'll access
an innocent other device. Same if I address something before my window
in situation B.

Now in practise, I agree that it is more likely in situation B that
something is actually mapped there.

I'm not sure wether the kernel has been wrong all the time or if
something changed recently. I posted the "workaround" the first time
through, which also works from userspace. I can change my application.
I can modify my libc.

However, I'd rather have "mmap" fixed, as that fixes it for all other
applications too. Not just for mine on my system.

The SGI manpage says:

All implementations interpret an addr value of
zero as granting the system complete freedom in selecting pa, subject to
constraints described below. A non-zero value of addr is taken to be a
suggestion of a process address near which the mapping should be placed.

which hints at a possible non-alignment. It also mentions that
"offset" should be page-aligned, which I disagree with here:
everything has been set up to "do the right thing" when the mapping is
possible with an unaligned offset.

Roger.


(*) Allow mmap to chose the address, to allow mmap the maximum
flexibilty of mapping your object.

--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
-
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:13    [W:0.041 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site