The Linux Kernel Mailing List
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox