[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070928074200.436463000@chello.nl>
Date: Fri, 28 Sep 2007 09:42:00 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: lkml <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org
Cc: Zach Brown <zach.brown@...cle.com>, Ingo Molnar <mingo@...e.hu>,
akpm@...ux-foundation.org, Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: [PATCH 00/12] various lockdep patches
The first 3 patches provide a new lockdep check, it verifies we don't hold any
locks when returning to userspace.
lockdep-sys_exit.patch
lockdep-i386-sys_exit.patch
lockdep-x86_64-sys_exit.patch
Could the various arch maintainers that have support for lockdep help out
with placing this hook?
A journal_start annotation:
jbd-lock.patch
Up until this point stuff should be safe to merge (assuming there are no
objections and bugs.. :-)
The rest of the series annotates lock_page():
rework lock_page() API:
trylock_page.patch
lock_page.patch
lockdep-page_lock-hooks.patch
actuall lockdep annotation:
lockdep-depth.patch
lockdep-fs-page.patch
lockdep-page-async.patch
set_page_mapping.patch
lockdep-lock_page.patch
Part of that is re-working the lock_page() API a bit. It introduces
trylock_page(), and removes all the raw *PageLock() usage.
I've compile and boot tested this series on x86_64 (with and without lockdep).
And it completes an LTP run with lockdep enabled.
Andrew, can we start by pusing the lock_page() API rework into -mm?
[ this series is against -linus, but if you're willing I'll do some
patches against -mm ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists