linux-kernel - Re: [PATCH v2] timers: Fix usleep_range() in the context of wake_up

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.20.1610201150510.5073@nanos>
Date:   Thu, 20 Oct 2016 11:51:12 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Daniel Kurtz <djkurtz@...omium.org>
cc:     Doug Anderson <dianders@...omium.org>,
        John Stultz <john.stultz@...aro.org>,
        Tao Huang <huangtao@...k-chips.com>,
        Brian Norris <briannorris@...omium.org>,
        Andreas Mohr <andi@...as.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        Tony Xie <tony.xie@...k-chips.com>,
        Akihiro Tsukada <tskd08@...il.com>
Subject: Re: [PATCH v2] timers: Fix usleep_range() in the context of
 wake_up_process()

On Thu, 20 Oct 2016, Daniel Kurtz wrote:
> On Wed, Oct 19, 2016 at 4:29 AM, Doug Anderson <dianders@...omium.org> wrote:
> > ...but I'm not sure I agree with you about what to do here.
> > Specifically I think that whatever we do we need to try to keep
> > schedule_hrtimeout_range() and schedule_timeout() parallel.  For
> > schedule_timeout() we have the same comments but it's my understanding
> > that you'd expect that wake_up_process() would wake it up.  In any
> > case, if wake_up_process() doesn't wake it up then it seems like
> > msleep() and schedule_timeout_uninterruptible() are the same function
> > with two names, when in fact one is implemented in terms o the other.
> 
> Sounds reasonable.
> It would be nice to add a note to all of those function comments
> though to make them sound less absolute -
> "at least @timeout time is guaranteed to pass before the routine
> returns unless the current task is explicitly woken up, (e.g. by
> wake_up_process())"

Agreed.