public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Andi Kleen <andi@firstfloor.org>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] kmemcheck: trap uses of uninitialized memory (v2)
Date: Thu, 29 Nov 2007 14:45:35 +0100	[thread overview]
Message-ID: <20071129134535.GA28180@one.firstfloor.org> (raw)
In-Reply-To: <19f34abd0711290524k49628a0dja8a5a04d10253157@mail.gmail.com>

> We don't need to flush all CPUs. This is my rationale: The debug
> exception (single-step trap) will always happen on the same CPU that
> the page fault occurred on. Page fault shows the page, debug exception
> hides the page again. Between those two operations, nothing else can

You're ignoring preemptible kernels for once.

Also there is always a race. e.g. consider another CPU fetches
the entry into its TLB while you have it temporarily unprotected.
Then you protect it again but the other CPU still keeps the unprotected
entry in its TLBs which you don't flush.

In general any changes to the direct mapping have to be done globally.

> happen that will use the TLB entry in question (unless you have some
> weird race condition, but then the code is in error anyway).
> 
> What is c_p_a() and what is a flush object?

change_page_attr() is designed to queue flush requests for later which
are then done by global_tlb_flush() For that it creates a list of pages.
It cannot be safely used without global_flush_tlb() otherwise the flush
list will just grow unbounded.

You could in theory write an equivalent optimized for your case that does
not require that, but it's not even safe for your case anyways.

-Andi


      reply	other threads:[~2007-11-29 13:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-27 15:16 [RFC] kmemcheck: trap uses of uninitialized memory (v2) Vegard Nossum
2007-11-28  6:51 ` Richard Knutsson
2007-11-28 18:31   ` Vegard Nossum
2007-11-29  4:49     ` Richard Knutsson
2007-11-29  8:02 ` Pekka Enberg
2007-11-29  9:10   ` Vegard Nossum
2007-11-29  9:39     ` Pekka J Enberg
2007-11-29 10:04       ` Vegard Nossum
2007-11-29 12:05         ` Pekka J Enberg
2007-11-29 10:29 ` Andi Kleen
2007-11-29 13:24   ` Vegard Nossum
2007-11-29 13:45     ` Andi Kleen [this message]

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=20071129134535.GA28180@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vegard.nossum@gmail.com \
    /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