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

From: Benjamin Herrenschmidt (benh_at_kernel.crashing.org)
Date: 05/24/04

  • Next message: Benjamin Herrenschmidt: "Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE" 
    To: Linus Torvalds <torvalds@osdl.org>
Date:	Mon, 24 May 2004 15:34:49 +1000

    > Ahh.. That's a bug, methinks.
    >
    > The reason it's a bug is that if you do this, you can lose the dirty bit
    > being written on some other CPU asynchronously.

    Hrm... right indeed.

    > In other words, I think it's pretty much always a bug to do a "set_pte()"
    > with an existing pte in place, exactly because you lose information. You
    > are trying to cover up the bug in ppc64-specific code, but I think that
    > what you found is actually a (really really) unlikely race condition that
    > can have serious consequences.
    >
    > Or am I missing something else?

    Well, the original scenario triggering that from userland is, imho, so
    broken, that we may just not care losing that dirty bit ... Oh well :)
    Anyway, apply my patch. If pte is not present, this will have no effect,
    if it is, it makes sure we never leave a stale HPTE in the hash, which
    is fatal in far worse ways.

    > [ grep grep grep ]
    >
    > Looks like "break_cow()" and "do_wp_page()" are safe, but only because
    > they always sets the dirty bit, and any other bits end up being pretty
    > much "don't care if we miss an accessed bit update" or something.
    >
    > Hmm. Maybe I'm wrong. If this really is buggy, it's been buggy this way
    > basically forever. That code is _not_ new, it's some of the oldes code in
    > the whole VM since the original three-level code rewrite. I think. Of
    > course, back then SMP wasn't an issue, and this seems to have survived all
    > the SMP fixes.
    >
    > Who else has been working on the page tables that could verify this for
    > me? Ingo? Ben LaHaise? I forget who even worked on this, because it's so
    > long ago we went through all the atomicity issues with the page table
    > updates on SMP. There may be some reason that I'm overlooking that
    > explains why I'm full of sh*t.

    Ben.

    -
    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: Benjamin Herrenschmidt: "Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE"

    Relevant Pages

    • Re: Mouse function lost within Word 2003 document
      ... dirty workarounds but in this case there really isn't a reason to keep ... troubleshooting mode which prevents Normal.dot, add-in, and personal ... Your Winword is chewed. ... but I found a dirty work around that I am using ... ...
      (microsoft.public.word.application.errors)
    • Re: Accessing data from a subform in the parent forms recordset
      ... I had asked why you opening this form in dialog mode? ... About the only reason why you would use dialog is if you ... KEEP IN MIND if you do not edit any field in this newly opened ... And, if the above is the case, the best approach is do dirty the record ...
      (microsoft.public.access.formscoding)
    • Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE
      ... places want to actually update just the dirty and accessed bits. ... we should be able to have a BUG() in "set_pte" if the entry ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Eng v Samoa
      ... Brent Hadley wrote: ... >>> garryowen is precisely that reason, to give you a better chance of taking a ... >>> clean ball with out getting belted a nanosecond after having caught it. ... > 'tackled in the air so must be dirty play' reaction. ...
      (rec.sport.rugby.union)
    • Re: 2.6.19 file content corruption on ext3
      ... write(1, mapping, 40); ... In 2.6.19, because we actually track dirty data so much better, "sync" ... since the user program has only allocated ten bytes for it in the file, ... this bug can just be made to trigger the bug much more easily. ...
      (Linux-Kernel)