linux-kernel - Re: [PATCH review for 4.4 12/47] clk: wm831x: fix usleep

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: <20171006100059.725roshck2lwk25z@localhost.localdomain>
Date:   Fri, 6 Oct 2017 11:00:59 +0100
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Nicholas Mc Guire <der.herr@...r.at>
CC:     "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Nicholas Mc Guire <hofrat@...dl.org>,
        Stephen Boyd <sboyd@...eaurora.org>
Subject: Re: [PATCH review for 4.4 12/47] clk: wm831x: fix usleep_range with
 bad range

On Fri, Oct 06, 2017 at 08:03:23AM +0000, Nicholas Mc Guire wrote:
> On Sun, Sep 24, 2017 at 12:18:12AM +0000, Levin, Alexander (Sasha Levin) wrote:
> > On Fri, Sep 22, 2017 at 09:46:28AM +0100, Charles Keepax wrote:
> > >On Wed, Sep 20, 2017 at 04:45:02AM +0000, Levin, Alexander (Sasha Levin) wrote:
> > >Does this patch really make sense for stable, isn't this really
> > >just a small optimisation? The patch is pretty harmless so I
> > >can't see applying it causing any problems, just curious what
> > >problems not having it is causing.
> > 
> > Looking back at this, I think I misunderstood a scenario in the scheduler this might be causing. What you say makes sense, I'll drop it.
> >
> 
> sorry for the delay - was off-line.
> 
> The motivation is that if usleep_range is used with min==max
> then it allows no consolidation of highresolution timers at all
> but as this is not an atomic code-section anyway it is not sensible
> to force a precise timer - the pach relaxes the timing so that
> the highrestimers load can be reduced. 
> 
> Technically this should have no effect at all as the jitter of
> the system is probably a lot higher than the range given anyway
> but the range allows optimization of highresolution timers.
> 

Indeed, which is why it is a good commit that was merged into
mainline.

> So basically you are right its an optimization only but it is not
> only relevant to keep the highrestimers well optimized it is also
> the recommendation in the kernel documentation and since there is
> not drawback with this optimization I think it should be considered even
> if it is not important.
> 

But my understanding is only patches to fix significant issues
should be backported to stable, this doesn't really do that.  As
you say it is fairly harmless though, so I can't see it causing
any problems so I am certainly not nak-ing it.

Thanks,
Charles