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  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]
Date:	Wed, 5 Nov 2014 09:18:38 +0100
From:	Peter Zijlstra <>
To:	Pavel Machek <>
Subject: Re: [tip:sched/core] sched/wait: Reimplement wait_event_freezable()

On Tue, Nov 04, 2014 at 09:12:03PM +0100, Pavel Machek wrote:
> Hi!
> > Commit-ID:  36df04bc5273a046f53b5e359febc1225f85aa7b
> > Gitweb:
> > Author:     Peter Zijlstra <>
> > AuthorDate: Wed, 29 Oct 2014 12:21:57 +0100
> > Committer:  Ingo Molnar <>
> > CommitDate: Tue, 4 Nov 2014 07:17:45 +0100
> > 
> > sched/wait: Reimplement wait_event_freezable()
> > 
> > Provide better implementations of wait_event_freezable() APIs.
> > 
> > The problem is with freezer_do_not_count(), it hides the thread from
> > the freezer, even though this thread might not actually freeze/sleep
> > at all.
> Can you elaborate?
> The thread will be in freezer_do_not_count() area, but it is just
> waiting for event there, it should not do much damage.

There are wait_event()s for which the cond expands to quite a lot of
code. This code can still be running while the freezer reports success.
This can happen because we're hidden by the do_not_count logic.

Also, I initially overlooked that freezer_count() did a try_to_freeze().

> If this is bugfix, should it be cc-ed to stable?

Its not a bugfix per se, the issue above is rare and extremely hard to
hit, esp since the freezer tries multiple times before giving up. But
its a theoretical possibility.

> Did you test it with suspend/hibernation? Because I can't really see
> how it works.

It calls try_to_freeze() after each schedule(). But no, I've not
actually tried.

If we're stuck in the schedule, waiting for the event, freeze_task()
will wake us up and then we'll find freeing() true and call into

If we're not stuck in schedule() we're running and the freezer
can see us running and will wait for us to hit another freeze point.

> > +#define __wait_event_freezable(wq, condition)				\
> > +	___wait_event(wq, condition, TASK_INTERRUPTIBLE, 0, 0,		\
> > +			    schedule(); try_to_freeze())
> > +

> _Three_ underscores. And two underscore version exists, too,
> fortunately it at least has different number of arguments.

Hehe, yeah, there was a discount on underscores that day. The double
underscore variants can be used in code along with the no underscores
variants. The tripple one is implementation goo.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists