mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@cam.org>
To: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Hugh Dickins <hugh@veritas.com>, Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/9] mm: arm ready for split ptlock
Date: Tue, 25 Oct 2005 21:26:33 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0510252049410.5288@localhost.localdomain> (raw)
In-Reply-To: <20051026002016.GB25420@flint.arm.linux.org.uk>

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

  reply	other threads:[~2005-10-26  1:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-22 16:18 [PATCH 0/9] mm: page fault scalability Hugh Dickins
2005-10-22 16:19 ` [PATCH 1/9] mm: i386 sh sh64 ready for split ptlock Hugh Dickins
2005-10-22 18:24   ` Paul Mundt
2005-10-22 16:22 ` [PATCH 2/9] mm: arm " Hugh Dickins
2005-10-22 17:02   ` Russell King
2005-10-23  8:27     ` Hugh Dickins
2005-10-25  2:45     ` Nicolas Pitre
2005-10-25  6:31       ` Hugh Dickins
2005-10-25 14:55         ` Nicolas Pitre
2005-10-25  7:55       ` Russell King
2005-10-25 15:00         ` Nicolas Pitre
2005-10-26  0:20           ` Russell King
2005-10-26  1:26             ` Nicolas Pitre [this message]
2005-10-31 22:19             ` Jesper Juhl
2005-10-31 22:27               ` Russell King
2005-10-31 22:34                 ` Jesper Juhl
2005-10-31 22:50                   ` Russell King
2005-10-22 16:23 ` [PATCH 3/9] mm: parisc pte atomicity Hugh Dickins
2005-10-22 16:33   ` Matthew Wilcox
2005-10-22 17:08     ` [parisc-linux] " James Bottomley
2005-10-23  9:02       ` Hugh Dickins
2005-10-23 15:05         ` James Bottomley
2005-10-24  4:36           ` Hugh Dickins
2005-10-24 14:56             ` James Bottomley
2005-10-24 16:49               ` Hugh Dickins
2005-10-22 16:24 ` [PATCH 4/9] mm: cris v32 mmu_context_lock Hugh Dickins
2005-10-22 16:25 ` [PATCH 5/9] mm: uml pte atomicity Hugh Dickins
2005-10-22 16:27 ` [PATCH 6/9] mm: uml kill unused Hugh Dickins
2005-10-22 19:23   ` Jeff Dike
2005-10-22 16:29 ` [PATCH 7/9] mm: split page table lock Hugh Dickins
2005-10-23 16:54   ` Nikita Danilov
2005-10-23 21:27   ` Andrew Morton
2005-10-23 22:22     ` Andrew Morton
2005-10-24  3:38       ` Hugh Dickins
2005-10-24  4:16         ` Andrew Morton
2005-10-24  4:58           ` Hugh Dickins
2005-10-24  3:09     ` Hugh Dickins
2005-10-23 21:49   ` Andrew Morton
2005-10-24  3:12     ` Hugh Dickins
2005-10-22 16:30 ` [PATCH 8/9] mm: fix rss and mmlist locking Hugh Dickins
2005-10-22 16:31 ` [PATCH 9/9] mm: update comments to pte lock Hugh Dickins
2005-10-23  7:49 ` [PATCH 6/9 take 2] mm: uml kill unused Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0510252049410.5288@localhost.localdomain \
    --to=nico@cam.org \
    --cc=akpm@osdl.org \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rmk+lkml@arm.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®