linux-kernel - Re: Problems with timerfd()

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: <20070724074032.298410@gmx.net>
Date:	Tue, 24 Jul 2007 09:40:32 +0200
From:	"Michael Kerrisk" <mtk-manpages@....net>
To:	"Ray Lee" <ray-lk@...rabbit.org>
Cc:	drepper@...hat.com, davidel@...ilserver.org, torvalds@...l.org,
	linux-kernel@...r.kernel.org, akpm@...l.org
Subject: Re: Problems with timerfd()

Ray,

> On 7/22/07, Michael Kerrisk <mtk-manpages@....net> wrote:
> > Problem 1
> > ---------
> >
> > The value returned by read(2)ing from a timerfd file descriptor is 
> > the
> > number of timer overruns.  In 2.6.22, this value is 4 bytes, limiting
> > the overrun count  to 2^32.  Consider an application where the timer
> > frequency
> > was 100 kHz (feasible in the not-too-distant future, I would guess),
> > then
> > the overrun counter would cycle after ~40000 seconds (~11 hours).
> > Furthermore returning 4 bytes from the read() is inconsistent with
> > eventfd
> > file descriptors, which return 8 byte integers from a read().
> 
> I'm feeling slow, and think I'm missing something. Why is this an
> issue? Wouldn't userspace just keep track of the last overrun count,
> and subtract the two to get the overruns-since-last-read? 

The value returned by read() is the number of overruns since
the last read().

> That makes
> it oblivious to rollovers, unless it can't manage to do a read once
> every 11 hours.

That's the point that the change is meant to address.

> (This is the same sort of thing we already have to deal with in
> certain situations, such as network stat counters on 32 bit
> platforms.)

But userspace can't deal with the condition accurately, so why
require userspace to worry about this when we could just use
a 64-bit value instead?

Cheers,

Michael
-- 
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 

Want to help with man page maintenance?  
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages , 
read the HOWTOHELP file and grep the source 
files for 'FIXME'.

-
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/