linux-kernel - Re: [PATCH/RFC] 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: <29495f1d0707181053n13c3a1b4r8b05a5e20de59e22@mail.gmail.com>
Date:	Wed, 18 Jul 2007 10:53:34 -0700
From:	"Nish Aravamudan" <nish.aravamudan@...il.com>
To:	"Nick Piggin" <nickpiggin@...oo.com.au>
Cc:	"Ray Lee" <ray-lk@...rabbit.org>,
	"Roman Zippel" <zippel@...ux-m68k.org>,
	"Jonathan Corbet" <corbet@....net>, linux-kernel@...r.kernel.org,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>
Subject: Re: [PATCH/RFC] msleep() with hrtimers

On 7/16/07, Nick Piggin <nickpiggin@...oo.com.au> wrote:
> Nish Aravamudan wrote:
>
> > Well, before these changes, the only guarantee msleep() could make,
> > just like the only guarantee schedule_timeout() could make, was that
> > it would not return early. The 1-jiffy sleep was always tough to deal
> > with, because of rounding and such. And it's simply exacerbated with
> > HZ=100. It's not technically 20 times longer in all cases, it's 2
> > jiffies longer, which depends on HZ, so varies from 2 msecs longer to
> > 20 msecs longer.
>
> I don't think you should rely on anything else actually, because Linux
> is not an RT OS. If your driver needs a specific sequence in a given
> amount of time, you have to do something like disable interrupts and
> use delays.

I agree -- I wasn't trying to indicate what one should or should not
do. Just tried to provide some insight into the intent behind the
interfaces. They were never meant to be precise, per se -- simply
guaranteeing the request would be satisfied, with no upper bound. I
agree that if timing really is that critical then delays or more
accurate timing specifications would be appropriate (one reason to use
msecs_to_jiffies() and co. rather than jiffies directly in drivers,
perhaps).

Thanks,
Nish
-
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/