linux-kernel - Re: [PATCH] msleep() with hrtimers

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

Message-ID: <1a297b360708070340i1096a64bp3390aa7272ce9bba@mail.gmail.com>
Date:	Tue, 7 Aug 2007 14:40:45 +0400
From:	"Manu Abraham" <abraham.manu@...il.com>
To:	"Arjan van de Ven" <arjan@...radead.org>
Cc:	"Roman Zippel" <zippel@...ux-m68k.org>,
	"Jonathan Corbet" <corbet@....net>, linux-kernel@...r.kernel.org,
	"Thomas Gleixner" <tglx@...utronix.de>, akpm@...ux-foundation.org,
	"Ingo Molnar" <mingo@...e.hu>
Subject: Re: [PATCH] msleep() with hrtimers

Hi Arjan,

On 8/6/07, Arjan van de Ven <arjan@...radead.org> wrote:
> On Mon, 2007-08-06 at 12:03 +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Sun, 5 Aug 2007, Arjan van de Ven wrote:
> >
> > > > There's no problem to provide a high resolution sleep, but there is also
> > > > no reason to mess with msleep, don't fix what ain't broken...
> > >
> > > John Corbet provided the patch because he had a problem with the current
> > > msleep... in that it didn't provide as good a common case as he
> > > wanted... so I think your statement is wrong ;)
> >
> > Only under the assumptation, that msleep _must_ be "fixed" for all other
> > current users too.
> > Give users a choice to use msleep or nanosleep, how do you know what's
> > "best" for them?
>
> do you have any actual technical objections, or do you just hate
> hrtimers in general?
>
> I really don't see what you hate so much about making the msleep()
> implementation provide a more precise (typical sleep time of 1msec
> rather than 20msec) behavior than the current one. Trying to distract
> that by proposing a very different API (working on a totally different
> time unit, while a lot of kernel users are using miliseconds; don't get
> me wrong, a usleep() and nsleep() might be useful if there's users that
> want to sleep in such times) is just trying to distract the issue.
>
> So, let me ask a direct question: What do you think is specifically
> wrong about changing the msleep() implementation as is done here? The
> behavior is clearly an improvement, so what is your objection on the
> flipside?
>

I think there could be a flipside based on what Roman said, but it is
my guess only.
currently wherever msleep is used now it sleeps with an ambiguous amount.

Eventhough the ambiguous sleep period is not appreciable, fixing
msleep might have a bad side effect. ie, drivers which would be
sleeping for a specified period would sleep less, just as compared to
the more precise sleep.

I think, it would be hard to fix, such breakages. Maybe a newer sleep
method would be much better, such that it doesn't cause any breakage.
-
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/