Re: [PATCH 07/11] unpaged: COW on VM_UNPAGED

["David S. Miller" <davem@davemloft.net>]

From: Hugh Dickins <hugh@veritas.com>
Date: Fri, 18 Nov 2005 07:27:36 +0000 (GMT)

> On Thu, 17 Nov 2005, David S. Miller wrote:
> > From: Nick Piggin <nickpiggin@yahoo.com.au>
> > Date: Fri, 18 Nov 2005 16:46:56 +1100
> > 
> > > I think for 2.6.15, yes. We [read: I :(] was too hasty in removing
> > > this completely.
> 
> No, that was not too hasty: we all agreed that the case _ought_ not to
> arise, and we hadn't worked out the right code to handle it if it did
> arise.  What was disappointing is that nobody reported the messages
> while it was in -mm, but

The recent vbetool suspend-from-ram datapoint shows that it might be
important that the BIOS data area is application local,
ie. MAP_PRIVATE.  Ie. it works only if the writes are not performed
to the real BIOS data page.

If true, that means the MAP_PRIVATE+VM_UNPAGED case has legit users.
Although, such applications could just copy the interrupt vector plus
BIOS data area into an anonymously mapped region and have the vm86
execution work off that instead of the /dev/mem mapping.

So, just to make sure this all adds up, a PROT_WRITE+MAP_PRIVATE
mapping of /dev/mem results in any pages written to being COW'd.
Right?

It is a good question as to which cases doing stuff like this want to
make modifications to the real BIOS data area, and which ones do not.
Aparently vbetool does not.