Date: Thu, 30 Mar 2006 09:13:22 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: emin ak <eminak71@gmail.com>, linux-kernel@vger.kernel.org
Subject: Re: 2.6.16-rt10 crash on ppc
Message-ID: <20060330071322.GA3137@elte.hu>
References: <2cf1ee820603270656w6697778ai83935217ea5ab3a5@mail.gmail.com> <2cf1ee820603271231l69187925j3150098097c7ca15@mail.gmail.com> <44288FB3.5030208@yahoo.com.au> <20060329150815.GA24741@elte.hu> <442B4890.6000905@yahoo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <442B4890.6000905@yahoo.com.au>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 851
Lines: 29


* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> Yes, that patch is basically what I had in mind.
> 
> Is -rt ever allocating memory from really-hard-don't-preempt-me 
> context? I guess not, unless the zone->lock is one of those locks too, 
> right?

no. zone->lock (and all the slab locks, and all the other MM locks) are 
fully preemptible too.

> Should you add a
> 
>  #else
>     BUG_ON(_really_dont_preempt_me());
>  #endif
> 
> just for safety, or will such misusage get caught elsewhere (eg. when 
> attempting to take zone->lock).

it should be caught immediately, by the cond_resched().

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/