Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 05/25/04

  • Next message: David S. Miller: "Re: VLAN startup info patch" 
    Date:	Tue, 25 May 2004 11:05:09 -0700 (PDT)
To: "David S. Miller" <davem@redhat.com>

    On Tue, 25 May 2004, David S. Miller wrote:
    > On Tue, 25 May 2004 10:49:21 -0700 (PDT)
    > Linus Torvalds <torvalds@osdl.org> wrote:
    >
    > > So what I can tell, the fix is really something like this (this does both
    > > x86 and ppc64 just to show how two different approaches would handle it,
    > > but I have literally _tested_ neither).
    > >
    > > What do people think?
    >
    > So on sparc32 sun4m we'd implement ptep_update_dirty_accessed() with
    > some kind of loop using the swap instruction?

    Yes. Except that if everybody else uses atomic updates (including the hw
    walkers), _and_ "dirty" is true, then you can optimize that case to just
    to an atomic write (since we don't care what the previous contents were,
    and everybody else is guaranteed to honor the fact that we set all the
    bits.

    (And an independent optimization is obviously to not do the store at all
    if it is already has the new value, although that _should_ be the rare
    case, since if that was true I don't see why you got a page fault in the
    first place).

    So _if_ such an atomic loop is fundamentally expensive for some reason, it
    should be perfectly ok to do

            if (dirty) {
                    one atomic write with all the bits set;
            } else {
                    cmpxchg until successful;
            }

    Oh - btw - my suggested patch was totally broken for ppc64, because that
    "ptep_update_dirty_accessed()" thing obviously also needs to that damn
    hpte_update() crud etc.

    BenH - I'm leaving that ppc64 code to somebody knows what the hell he is
    doing. Ie you or Anton or something. Ok? I can act as a collector the
    different architecture things for that "ptep_update_dirty_accessed()"
    function.

                    Linus
    -
    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/

  • Next message: David S. Miller: "Re: VLAN startup info patch"

    Relevant Pages

    • wait_event and preemption in 2.6
      ... I'm writing a device driver for PPC Linux and I'm using wait_event. ... preemption is turned on. ... check the condition and break out of the loop. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • [PATCH] NULL pointer deref in tcp_do_twkill_work()
      ... Shouldn't the loop always restart from the beginning instead of using the ... The alternative is to not drop the lock, but I'm guessing we need to do ... Proposed patch is attached. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • x86 build issue with software suspend code
      ... collision and the relocation from and alloc section targeting targeting ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 2.6.9-rc2-mm1 0/2] mm: memory policy for page cache allocation
      ... Patches done with the 'diff -p' option are slightly easier to ... Could you explain the for loop in alloc_page_roundrobin? ... pseudo-uniform distribution, without any need for the additional rr_next ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Fw: x86 build issue with software suspend code
      ... since otherwise problems with this code path should have been ... > incorrectly line wrapped) patch changes the attributes of the section to ... 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/ ...
      (Linux-Kernel)