From: Hugh Dickins <[email protected]>
Date: Fri, 18 Nov 2005 08:13:54 +0000 (GMT)
> On Fri, 18 Nov 2005, David S. Miller wrote:
> > From: Hugh Dickins <[email protected]>
> > Date: Fri, 18 Nov 2005 08:02:02 +0000 (GMT)
> >
> > > That code is necessary to reproduce the existing behaviour, which has
> > > always done COW on PageReserved mappings without complaint - if the
> > > vm_page_prot didn't already let you slip through without a WP fault.
> >
> > And there is evidence today that this is really needed, at least
> > by vbetool.
> >
> > Ok, we need COW on VM_UNPAGED. :)
>
> Are you so sure of that, that we should even skip adding a warning?
Yes, I'm pretty sure. The datapoints are like this:
1) Existing vbetool with 2.6.14 and previous works
2) 2.6.15 w/no-COW-on-reserved makes existing vbetool fail
immediately (of course)
3) 2.6.15 w/no-COW-on-reserved still fails with MAP_SHARED
patched vbetool
4) 2.6.15 w/COW-on-VM_UNPAGED works with existing vbetool
5) 2.6.15 w/COW-on-VM_UNPAGED _FAILS_ with MAP_SHARED patched
vbetool
That #5 is the key.
If we use MAP_SHARED and let vbetool modify the real BIOS data
area, resume fails. That's convincing enough for me :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
