All of lore.kernel.org
 help / color / mirror / Atom feed
From: corbet@lwn.net (Jonathan Corbet)
To: Pekka Paalanen <pq@iki.fi>
Cc: Ingo Molnar <mingo@elte.hu>,
	Christoph Hellwig <hch@infradead.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Pavel Roskin <proski@gnu.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC] mmiotrace full patch, preview 1
Date: Tue, 26 Feb 2008 10:20:08 -0700	[thread overview]
Message-ID: <1892.1204046408@vena.lwn.net> (raw)
In-Reply-To: Your message of "Sun, 24 Feb 2008 19:03:23 +0200." <20080224190323.77adf683@daedalus.pq.iki.fi>

Hey, Pekka,

A couple of little things I noticed...

> +static int post_kmmio_handler(unsigned long condition, struct pt_regs *regs)
> +{
> +	int ret = 0;
> +	struct kmmio_probe *probe;
> +	struct kmmio_fault_page *faultpage;
> +	struct kmmio_context *ctx = &get_cpu_var(kmmio_ctx);
> +
> +	if (!ctx->active)
> +		goto out;

Should that text read something like:

	if (condition != DIE_TRAP || !ctx->active)

Presumably you won't be active if something else is going wrong, but one
never knows.

> +int register_kmmio_probe(struct kmmio_probe *p)
> +{
> +	int ret = 0;
> +	unsigned long size = 0;
> +
> +	spin_lock_irq(&kmmio_lock);
> +	kmmio_count++;
> +	if (get_kmmio_probe(p->addr)) {
> +		ret = -EEXIST;
> +		goto out;
> +	}

That only checks the first page; if the probed region partially overlaps
another one found later in memory, the registration will succeed.

Maybe you want to decrement kmmio_count if you decide to return -EEXIST
(or hold off on the increment until after the test)?

In general, I worry about what happens if an interrupt handler generates
traced MMIO traffic while a fault handler is active.  It looks a lot
like the "all hell breaks loose" scenario mentioned in the comments.  Is
there some way of preventing that which I missed?  Otherwise, maybe,
should the ioremap() wrappers take an additional argument, being an IRQ
to disable while trace handlers are active?

jon

  parent reply	other threads:[~2008-02-26 17:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-24 17:03 [RFC] mmiotrace full patch, preview 1 Pekka Paalanen
2008-02-24 17:59 ` Sam Ravnborg
2008-02-25 22:49 ` Andrew Morton
2008-02-25 23:34   ` Christoph Hellwig
2008-02-26  2:42     ` Pavel Roskin
2008-02-26  8:57       ` Andy Whitcroft
2008-02-26 17:10       ` Christoph Hellwig
2008-02-26 10:21     ` Andy Whitcroft
2008-02-26 10:49       ` Ingo Molnar
2008-02-26 15:20         ` Andy Whitcroft
2008-02-26 20:02   ` Pekka Paalanen
2008-02-26 17:20 ` Jonathan Corbet [this message]
2008-02-27 20:28   ` Pekka Paalanen

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=1892.1204046408@vena.lwn.net \
    --to=corbet@lwn.net \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan@infradead.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=pq@iki.fi \
    --cc=proski@gnu.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.