linux-kernel - RE: [RFC] "mustnotsleep"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <58c0ab81-5c63-4d41-957b-df02e15aeba5@default>
Date:	Thu, 2 Jun 2011 17:00:29 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Luis Henriques <luis.henrix@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: RE: [RFC] "mustnotsleep"

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