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] [day] [month] [year] [list]

Message-ID: <703fddf1-223f-409c-a8d1-bc9468537429@default>
Date:	Sun, 5 Jun 2011 12:28:18 -0700 (PDT)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Hugh Dickins <hughd@...gle.com>
Cc:	Luis Henriques <luis.henrix@...il.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] "mustnotsleep"

> Luis is surely on the right lines, but maybe CONFIG_DEBUG_PREEMPT was
> not the crucial option.
> 
> You should be building with CONFIG_PREEMPT and
> CONFIG_DEBUG_SPINLOCK_SLEEP for best testing, and it would be good to
> throw in CONFIG_DEBUG_PREEMPT too.
> 
> You need to preempt_disable() instead of mustnotsleep_start(), and
> preempt_enable() instead of mustnotsleep_done().  You cannot even
> safely use their smp_processor_id() without disabling preemption -
> otherwise that task might on a different cpu by the time you get to
> use the cpu it told you.  It's essential to disable preemption if you
> cannot bear to be rescheduled.
> 
> Then, if I've read the ifdefs correctly (please verify),
> cond_resched() will include a __might_sleep() to report "BUG: sleeping
> function called from invalid context..." from cond_resched() and other
> useful places.

Excellent!  Thanks, I will give it a try!  In my case,
preemption is indeed already disabled for all this code
(but irq's and bottom halves are enabled).
 
> But please don't disable preemption unnecessarily, nor for very long:
> it's better to remain preemptible wherever possible.

Sure, but what I'm arguing is that in many cases (and contrary
to conventional wisdom), a "somewhat fast" access to a page of data
with preemption DISabled is better than a "slow" disk read
with preemption ENabled.  Naturally this depends on if
all of the CPUs have useful work to do while waiting for the
disk read to complete... but as cores proliferate, CPU saturation
is becoming less likely.

Thanks again!
Dan
--
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/