Messages in this thread |  | | Subject | Re: mmap not working? | Date | Sat, 17 Nov 2001 10:07:57 +0100 (MET) | From | (Rogier Wolff) |
| |
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/
|  |