[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4533AF6C.6020207@yahoo.com.au>
Date: Tue, 17 Oct 2006 02:12:28 +1000
From: Nick Piggin <nickpiggin@...oo.com.au>
To: Peter Zijlstra <a.p.zijlstra@...llo.nl>
CC: Linux Memory Management <linux-mm@...ck.org>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...l.org>,
David Howells <dhowells@...hat.com>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: pagefault_disable (was Re: [patch 6/6] mm: fix pagecache write
deadlocks)
Peter Zijlstra wrote:
> On Tue, 2006-10-17 at 01:24 +1000, Nick Piggin wrote:
>>Also, the rest of the kernel tree (mainly uaccess and futexes) should be
>>converted ;)
>
>
> Yeah, lotsa places to touch.
>
>
>>>Index: linux-2.6/mm/filemap.h
>>>===================================================================
>>>--- linux-2.6.orig/mm/filemap.h 2006-10-14 20:20:20.000000000 +0200
>>>+++ linux-2.6/mm/filemap.h 2006-10-15 17:17:45.000000000 +0200
>>>@@ -21,6 +21,22 @@ __filemap_copy_from_user_iovec_inatomic(
>>> size_t bytes);
>>>
>>> /*
>>>+ * By increasing the preempt_count we make sure the arch preempt
>>>+ * handler bails out early, before taking any locks, so that the copy
>>>+ * operation gets terminated early.
>>>+ */
>>>+pagefault_static inline void disable(void)
>>>+{
>>>+ inc_preempt_count();
>
>
> I think we also need a barrier(); here. We need to make sure the preempt
> count is written to memory before we hit the fault handler.
It will come from this thread, but I guess the fault is not an event the
compiler can forsee, so indeed it might optimise this into the wrong place.
Perhaps not with any copy*user implementation we have, but at least in
theory...
>>>+pagefault_static inline void enable(void)
>>>+{
>>>+ dec_preempt_count();
>>>+ preempt_check_resched();
>>>+}
You'll want barriers before and after the dec_preempt_count, for similar
reasons.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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