linux-kernel - Re: yield() in i2c non-happy paths hits BUG under -rt patch

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: <1258640154.3931.407.camel@laptop>
Date:	Thu, 19 Nov 2009 15:15:54 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Thomas Gleixner <tglx@...utronix.de>,
	Leon Woestenberg <leon.woestenberg@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Sven-Thorsten Dietrich <sven@...bigcorporation.com>,
	linux-i2c@...r.kernel.org,
	rt-users <linux-rt-users@...r.kernel.org>,
	"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: yield() in i2c non-happy paths hits BUG under -rt patch

On Thu, 2009-11-19 at 15:00 +0100, Jean Delvare wrote:

> > 	cond_resched();
> 
> Are you saying that most calls to yield() should be replaced with calls
> to cond_resched()?

No, depends on the reason yield() is used. Some cases can be replaced by
locking constructs, such as a condition variable.

> I admit I a little skeptical. While the description of cond_resched()
> ("latency reduction via explicit rescheduling in places that are safe")
> sounds promising, following the calls leads me to:
> 
> static inline int need_resched(void)
> {
> 	return unlikely(test_thread_flag(TIF_NEED_RESCHED));
> }
> 
> So apparently the condition for need_resched() to do anything is
> considered unlikely... suggesting that cond_resched() is a no-op in
> most cases? I don't quite get the point of moving away from sched()
> because it is a no-op, if we end up with a no-op under a different name.

TIF_NEED_RESCHED gets set by the scheduler whenever it decides current
needs to get preempted, its unlikely() because that reduces the code
impact of cond_resched() and similar in the case we don't schedule, if
we do schedule() a mis-predicted branch isn't going to be noticed on the
overhead of scheduling.

So there's a few cases,

1) PREEMPT=n
2) Voluntary preempt
3) PREEMPT=y

1) non of this has any effect, if the scheduler wants to reschedule a
task that's in the kernel, it'll have to wait until it gets back to
user-space.

2) uses cond_resched() and similar to have explicit preemption points,
so we don't need to wait as long as 1).

3) preempts directly when !preempt_count(), when IRQs are disabled, the
IPI that will accompany TIF_NEED_RESCHED will be delayed and
local_irq_enable()/restore() will effect a reschedule due to the pending
IPI. If preemption was disabled while the IPI hit nothing will happen,
but preempt_enable() will do the reschedule once preempt_count reaches
0.

--
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/