On Wed, 26 Oct 2005, Russell King wrote:
> On Tue, Oct 25, 2005 at 11:00:09AM -0400, Nicolas Pitre wrote:
>
> > Argh... So only suffice to s/pte_write/pte_dirty/ I'd guess?
>
> No. If we're emulating a cmpxchg() on a clean BSS page, this code
> as it stands today will write to the zero page making it a page which
> is mostly zero. Bad news when it's mapped into other processes BSS
> pages.
>
> Changing this for pte_dirty() means that we'll refuse to do a cmpxchg()
> on a clean BSS page. The data may compare correctly, but because it
> isn't already dirty, you'll fail.
Does it matter? I'd say no. OK we _know_ that it should have worked,
but user space must be ready to deal with cmpxchg failing and reattempt
the operation. It never cares about the reason for which it might have
failed in all the cases I've seen. The second time, the page will have
been marked dirty and things will proceed normally.
This is of course not perfect but should be pretty damn good enough
given that the number of machine instances on this planet that _might_
need to rely on that code are truely non standard (i.e. pre ARMv6 SMP)
and can be counted on my fingers. The only other "solution" is to
always return failure and simply deny NPTL support for those classes of
machines.
Nicolas
-
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]
