Re: [PATCH 2/9] mm: arm ready for split ptlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]
  Powered by Linux