Re: Crashes if running WordPerfect 5.1

[Stas Sergeev <stsp@aknet.ru>]

Hello.

Bart Oldeman wrote:
>> 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.
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 :(

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

> but it looks like emm.c takes 
> 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.

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

> We would only be able to use
> ftruncate+mremap with explicit /dev/zero mappings or shm_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?