Date: Fri, 18 Nov 2005 08:12:32 +0000 (GMT)
From: Hugh Dickins <hugh@veritas.com>
To: "David S. Miller" <davem@davemloft.net>
cc: nickpiggin@yahoo.com.au, akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/11] unpaged: COW on VM_UNPAGED
In-Reply-To: <20051118.000414.10534984.davem@davemloft.net>
Message-ID: <Pine.LNX.4.61.0511180809250.5788@goblin.wat.veritas.com>
References: <437D6AD0.5080909@yahoo.com.au> <20051117.224516.118147408.davem@davemloft.net>
 <Pine.LNX.4.61.0511180724060.5435@goblin.wat.veritas.com>
 <20051118.000414.10534984.davem@davemloft.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1302
Lines: 32

On Fri, 18 Nov 2005, David S. Miller wrote:
> 
> 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.

Interesting.  I haven't dared reach that conclusion yet.

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

Yes, they could indeed.  Would save the kernel contortions.

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

Yes, in everything before 2.6.15-rc1, and again with my patches.

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

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/