MIME-Version: 1.0
Message-ID: <58c0ab81-5c63-4d41-957b-df02e15aeba5@default>
Date: Thu, 2 Jun 2011 17:00:29 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Luis Henriques <luis.henrix@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: RE: [RFC] "mustnotsleep"
References: <1af7a43d-84fa-47c4-a145-409e5bac585b@default
 87hb87lsb0.fsf@gmail.com>
In-Reply-To: <87hb87lsb0.fsf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1646
Lines: 49

> From: Luis Henriques [mailto:luis.henrix@gmail.com]
> Subject: Re: [RFC] "mustnotsleep"
> 
> Dan Magenheimer <dan.magenheimer@oracle.com> writes:
> 
> > In development of RAMster, I have frequently been bitten
> > by indirect use of existing kernel subsystems that
> > unexpectedly sleep.  As such, I have hacked the
> > following "debug" code fragments for use where I need to
> > ensure that doesn't happen.
> >
> > DEFINE_PER_CPU(int, mustnotsleep_count);
> >
> > void mustnotsleep_start(void)
> > {
> > 	int cpu = smp_processor_id();
> > 	per_cpu(mustnotsleep_count, cpu)++;
> > }
> >
> > void mustnotsleep_done(void)
> > {
> > 	int cpu = smp_processor_id();
> > 	per_cpu(mustnotsleep_count, cpu)--;
> > }
> >
> > and in schedule.c in schedule():
> >
> > if (per_cpu(mustnotsleep_count))
> > 	panic("scheduler called in mustnotsleep code");
> >
> > This has enabled me to start identifying code that
> > is causing me problems.  (I know this is a horrible
> > hack, but that's OK right now.)
> 
> I'm pretty sure I'm missing something here but... what if you just use
> CONFIG_DEBUG_PREEMPT?  Isn't that good enough?

Thanks for the reply Luis.

Looking at the code enabled by CONFIG_DEBUG_PREEMPT,
I don't think it does what I'm looking for.  I need
to ensure that no code called inside the boundaries
of mustnotsleep_start/done ever calls the scheduler,
e.g. cond_resched is never called etc.
--
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/