Crashes if running WordPerfect 5.1
Hello.
Quoted 4 lines · Bart Oldeman
Quoted 2 lines
But it still uses
mremap(), although
not with a shared mem.yes of course, so that comment should be in
dosext/dpmi/memory.cthen I guess.
What I was (implicitly) asking is whether it is safe to use mremap() at least in this case. It doesn't work reliably on 2.6 kernels even though it is used on a private mapping and I was wondering whether or not it is safe for 2.4 et al. It looks like mremap() is not something to rely upon :(
Quoted 4 lines
Quoted 3 lines
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
What I mean is:
You have a 4K-region aliased like this:0x40020000 -> 0xe0000
Then you resize it to 8K. With mremap() the above alias should still be valid (I think), and with memcpy() you'll have to update the mapping explicitly.
Quoted 1 line
but it looks like
emm.ctakes care of remapping everything.
Very probably, but that was the subject for cleanups. I think the mapping subsystem should try to preserve the aliases at realloc itself, and if it does so for mapfile, I think it should do that also for mapshm.
Quoted 1 line
a real file you'd have to ftruncate it to the new size first. But here we don't have a fd to call ftruncate.
But I wonder if SIGBUS is a correct behaviour. I would expect mremap() (nopage handler actually) to do everything that necessary, including ftruncate(). Otherwise it looks broken to me.
Quoted 2 lines
We would only be able to use
ftruncate+mremap with explicit/dev/zeromappings orshm_open
So should we get back to pagemalloc for mapshm then? After all we still don't need IPC SHM, and pagemalloc perhaps doesn't really hurt?
Quoted 4 lines · Stas Sergeev
What I mean is: You have a 4K-region aliased like this:
0x40020000->0xe0000Then you resize it to 8K. Withmremap()the above alias should still be valid (I think), and withmemcpy()you'll have to update the mapping explicitly.
Yes that's right. The first 4K still map to the same virtual file with mremap. emm.c I think expects it only to behave as a plain "realloc", historical reasons probably and that's why it works.
Quoted 5 lines
Quoted 2 lines
a real file you'd have to ftruncate it to the new size first. But here we don't have a fd to call ftruncate.
But I wonder if SIGBUS is a correct behaviour. I would expect
mremap()(nopage handler actually) to do everything that necessary, includingftruncate(). Otherwise it looks broken to me.
Maybe, but that's more of a kernel issue. mmap certainly isn't guaranteed to extend a file (it works to create a new file though), so in that way mremap is behaving consistently (i.e. if you mmap bytes 4096-8191 of a file with size 4000 you can't expect that file to be extended to 8192 bytes, the same is true for shm virtual files.
Look at the ftruncate example in "info libc" to see how they really need the ftruncate.
Quoted 2 lines
So should we get back to pagemalloc for mapshm then? After all we still don't need IPC SHM, and pagemalloc perhaps doesn't really hurt?
I think I would personnally like it best if there wasn't a pagealloc either, but just multiple fd's. That way you can have only one mapping backend, it just differs in what the fd opens (i.e. /dev/zero or a temporary file, or perhaps shm_open), and we don't need the mremap trick.
That would mean thatopen_mapping doesn't have to do anything at all.alloc_mapping opens a /dev/zero or tmpfile -- the fd will be remembered (linked list connecting it to the memory address) or it can be returned to the caller.realloc_mapping would have to do ftruncate and then mremap alias_map can mmap from the memory region to the fd.
of course the drawback of this is some overhead taking care of the fd's. But that gets rid of the overhead in pagemalloc.c and only allocates on demand (instead of one big chunk in the beginning).
Bart