Hi,
> Bart Oldeman wrote:
> > The patch below also does the job.
> Why didn't the mremap() do the trick?
see below.
> > As far as I could see DPMI no longer
> > calls this function
> But it still uses mremap(), although
> not with a shared mem.
yes of course, so that comment should be in dosext/dpmi/memory.c then I
guess.
> > + /* expanded new memory is apparently not shared so can't be aliased.
> Cant this somehow happen that the EMS
> keeps the mapping on some handle and
> does the realloc on the same handle?
> New pages are not aliased, that's for
> sure, but is this always true also for
> the old ones?
I'm not sure what you exactly mean here but it looks like emm.c takes care
of remapping everything.
What happened:
before:
40020000-40024000 rw-s 00000000 00:04 96225 /dev/zero (deleted)
after
40705000-4070d000 rw-s 00000000 00:04 96026 /dev/zero (deleted)
but the second half of this mremapped piece of memory doesn't exist (I get
(gdb) print *(0x40705000)
$2 = 1297889860
(gdb) print *(0x40709000)
Cannot access memory at address 0x40709000
) So my comment needs to be adjusted, the aliasing works but expanding
mremaps of shared memory don't seem to work. It smells a bit like a kernel
bug: the program below gives a bus error...
Bart
#define _GNU_SOURCE 1
#include <unistd.h>
#include <sys/mman.h>
#include <stdio.h>
int main(void)
{
char *p = mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0);
p[0] = '1';
printf("p = %p, p[0] = %c\n", p, p[0]);
p = mremap(p, 4096, 8192, MREMAP_MAYMOVE);
printf("after mremap p = %p, p[0] = %c\n", p, p[0]);
p[4096] = '2';
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
