From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([66.187.233.31]:51212 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757565AbXI1IC3 (ORCPT ); Fri, 28 Sep 2007 04:02:29 -0400 Message-Id: <20070928074200.436463000@chello.nl> Date: Fri, 28 Sep 2007 09:42:00 +0200 From: Peter Zijlstra Subject: [PATCH 00/12] various lockdep patches Sender: linux-arch-owner@vger.kernel.org To: lkml , linux-arch@vger.kernel.org Cc: Zach Brown , Ingo Molnar , akpm@linux-foundation.org, Peter Zijlstra List-ID: 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 ]