RE: [RFC] "mustnotsleep"

[Dan Magenheimer]

> From: Luis Henriques [mailto:luis.henrix@xxxxxxxxx]
> Subject: Re: [RFC] "mustnotsleep"
> 
> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/