From: Peter Zijlstra <peterz@infradead.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Russell King <rmk@arm.linux.org.uk>,
David Howells <dhowells@redhat.com>,
Ralf Baechle <ralf@linux-mips.org>,
David Miller <davem@davemloft.net>,
Paul Mackerras <paulus@samba.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Hugh Dickins <hughd@google.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-arch@vger.kernel.org
Subject: Re: [RFC][PATCH 0/6] mm, highmem: kmap_atomic rework
Date: Fri, 20 Aug 2010 16:38:12 +0200 [thread overview]
Message-ID: <1282315092.2605.1134.camel@laptop> (raw)
In-Reply-To: <20100819143129.81274c03.akpm@linux-foundation.org>
On Thu, 2010-08-19 at 14:31 -0700, Andrew Morton wrote:
> On Thu, 19 Aug 2010 22:13:17 +0200
> Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> >
> > This patch-set reworks the kmap_atomic API to be a stack based, instead of
> > static slot based. Some might remember this from last year, some not ;-)
> >
> > The advantage is that you no longer need to worry about KM_foo, the
> > disadvantage is that kmap_atomic/kunmap_atomic now needs to be strictly
> > nested (CONFIG_HIGHMEM_DEBUG should complain in case its not) -- and of
> > course its a big massive patch changing a widely used API.
>
> Nice. That fixes the "use of irq-only slots from interrupts-on
> context" bugs which people keep adding.
Ah, I should add a:
WARN_ON_ONCE(in_irq() && !irqs_disabled());
like check to ensure people don't use kmap_atomic() in nestable IRQ
contexts (nestable IRQ context is bad anyway) the old debug code I
deleted did something similar.
> We don't have any checks in there for the stack overflowing?
+#ifdef CONFIG_DEBUG_HIGHMEM
+ BUG_ON(idx > KM_TYPE_NR);
+#endif
Seems to be that.
> Did you add every runtime check you could possibly think of?
> kmap_atomic_idx_push() and pop() don't have much in there. It'd be
> good to lard it up with runtime checks for at least a few weeks.
Right, so I currently have:
- stack size check in push/pop
- proper nesting check in pop (verifies that the vaddr you try to
unmap is indeed the top most on the stack)
Aside from the proposed no irq-nesting thing to avoid unbounded
recursion I can't really come up with more creative abuse.
> Well, there's that monster conversion patch. How's about you
> temporarily do
>
> #define kmap_atomic(x, arg...) __kmap_atomic(x)
>
> so for a while, both kmap_atomic(a, KM_foo) and kmap_atomic(a) are
> turned into __kmap_atomic(a). Once all the dust has settled, pull that
> out again?
Ah, that's a nifty trick, let me try that.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2010-08-20 14:38 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 20:13 Peter Zijlstra
2010-08-19 20:13 ` [RFC][PATCH 1/6] mm: strictly nested kmap_atomic Peter Zijlstra
2010-08-20 20:50 ` Rik van Riel
2010-08-24 7:09 ` KAMEZAWA Hiroyuki
2010-08-19 20:13 ` [RFC][PATCH 2/6] mm: stack based kmap_atomic Peter Zijlstra
2010-08-20 21:34 ` Rik van Riel
2010-08-24 7:24 ` KAMEZAWA Hiroyuki
2010-08-24 7:35 ` KAMEZAWA Hiroyuki
2010-08-24 8:04 ` Peter Zijlstra
2010-08-19 20:13 ` [RFC][PATCH 3/6] mm, frv: Out-of-line kmap-atomic Peter Zijlstra
2010-08-20 21:48 ` Rik van Riel
2010-08-19 20:13 ` [RFC][PATCH 4/6] mm: Remove all KM_type arguments Peter Zijlstra
2010-08-20 21:44 ` Rik van Riel
2010-08-19 20:13 ` [RFC][PATCH 5/6] mm: Fix up KM_type argument removal fallout Peter Zijlstra
2010-08-20 21:45 ` Rik van Riel
2010-08-19 20:13 ` [RFC][PATCH 6/6] mm: Remove pte_*map_nested() Peter Zijlstra
2010-08-20 21:47 ` Rik van Riel
2010-08-19 21:31 ` [RFC][PATCH 0/6] mm, highmem: kmap_atomic rework Andrew Morton
2010-08-20 14:38 ` Peter Zijlstra [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=1282315092.2605.1134.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rmk@arm.linux.org.uk \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox