From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stas Sergeev Subject: Re: Crashes if running WordPerfect 5.1 Date: Sun, 30 May 2004 17:41:25 +0400 Sender: linux-msdos-owner@vger.kernel.org Message-ID: <40B9E485.8060901@aknet.ru> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: linux-msdos@vger.kernel.org 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?