From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>,
linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
paulus@samba.org, acme@redhat.com, efault@gmx.de,
npiggin@suse.de, tglx@linutronix.de,
linux-tip-commits@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [tip:perfcounters/core] x86: Add NMI types for kmap_atomic
Date: Mon, 15 Jun 2009 20:19:03 +0200 [thread overview]
Message-ID: <1245089943.13761.19334.camel@twins> (raw)
In-Reply-To: <20090615181555.GA11248@elte.hu>
On Mon, 2009-06-15 at 20:15 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <peterz@infradead.org> wrote:
>
> > +static int kmap_type_to_context(enum km_type type)
> > +{
> > + switch (type) {
> > + case KM_BOUNCE_READ:
> > + return KM_CTX_USER;
> > + case KM_SKB_SUNRPC_DATA:
> > + return KM_CTX_USER;
> > + case KM_SKB_DATA_SOFTIRQ:
> > + return KM_CTX_SOFTIRQ;
> > + case KM_USER0:
> > + return KM_CTX_USER;
> > + case KM_USER1:
> > + return KM_CTX_USER;
> > + case KM_BIO_SRC_IRQ:
> > + return KM_CTX_IRQ;
> > + case KM_BIO_DST_IRQ:
> > + return KM_CTX_IRQ;
> > + case KM_PTE0:
> > + return KM_CTX_USER;
> > + case KM_PTE1:
> > + return KM_CTX_USER;
> > + case KM_IRQ0:
> > + return KM_CTX_IRQ;
> > + case KM_IRQ1:
> > + return KM_CTX_IRQ;
> > + case KM_SOFTIRQ0:
> > + return KM_CTX_SOFTIRQ;
> > + case KM_SOFTIRQ1:
> > + return KM_CTX_SOFTIRQ;
> > + case KM_NMI:
> > + return KM_CTX_NMI;
> > + case KM_NMI_PTE:
> > + return KM_CTX_NMI;
> > + }
> > +
> > + return KM_CTX_MAX;
>
> why not do a very simple stack of atomic kmaps, like Hugh suggested?
>
> That would mean a much simpler interface:
>
> kaddr = kmap_atomic(page);
>
> no index needed. The kunmap pops the entry off the stack:
>
> kunmap_atomic(kaddr);
>
> This becomes simpler too.
>
> Now, a stack can be overflown by imbalance - but that's easy to
> detect and existing entries are easily printed and thus the source
> of the leak is easily identified.
>
> In my book this design beats the current enumeration of kmap types
> indices hands down ... It would likely be much more robust as well,
> and much more easy to extend.
>
> Am i missing any subtlety?
The above is mostly debug code used to validate the kmap_atomic
conditions.
KM_CTX_NMI nests in KM_CTX_IRQ nests in KM_CTX_SOFTIRQ nests in
KM_CTX_USER.
And validate that we indeed are in the context specified by the type.
That is, it will warn if we use KM_IRQ1 with KM_CTX_IRQ from user
context.
Some of this was already captured in the old kmap debug code which I
removed.
But yes, I should write that nicer..
/me goes clean up
next prev parent reply other threads:[~2009-06-15 18:19 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <tip-3ff0141aa3a03ca3388b40b36167d0a37919f3fd@git.kernel.org>
2009-06-15 14:46 ` [tip:perfcounters/core] x86: Add NMI types for kmap_atomic Peter Zijlstra
2009-06-15 15:30 ` Hugh Dickins
2009-06-15 15:41 ` Peter Zijlstra
2009-06-15 15:52 ` Ingo Molnar
2009-06-15 16:02 ` Hugh Dickins
2009-06-15 18:04 ` Peter Zijlstra
2009-06-15 18:15 ` Ingo Molnar
2009-06-15 18:19 ` Peter Zijlstra [this message]
2009-06-15 18:25 ` Ingo Molnar
2009-06-15 18:30 ` Peter Zijlstra
2009-06-15 18:42 ` Ingo Molnar
2009-06-15 18:47 ` Peter Zijlstra
2009-06-15 18:52 ` Ingo Molnar
2009-06-15 19:00 ` Peter Zijlstra
2009-06-16 8:13 ` Ingo Molnar
2009-06-16 12:38 ` Hugh Dickins
2009-06-17 7:58 ` Peter Zijlstra
2009-06-17 8:43 ` Tejun Heo
2009-06-17 9:05 ` Peter Zijlstra
2009-06-17 7:44 ` Peter Zijlstra
2009-06-17 12:28 ` Ingo Molnar
2009-06-15 18:42 ` Andrew Morton
2009-06-15 18:45 ` Peter Zijlstra
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=1245089943.13761.19334.camel@twins \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=hpa@zytor.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=npiggin@suse.de \
--cc=paulus@samba.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.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.