make timerfd return a u64 and fix the __put_user
authorDavide Libenzi <davidel@xmailserver.org>
Thu, 26 Jul 2007 17:41:07 +0000 (10:41 -0700)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 9 Aug 2007 21:27:31 +0000 (14:27 -0700)
commit32b49ec23649cc3e59d8c1963919f159eacd1167
tree79225291981edb6169d09f653276491201d47e8b
parent76525808fce1f652a6d8472db5a84d28b0951c90
make timerfd return a u64 and fix the __put_user

Davi fixed a missing cast in the __put_user(), that was making timerfd
return a single byte instead of the full value.

Talking with Michael about the timerfd man page, we think it'd be better to
use a u64 for the returned value, to align it with the eventfd
implementation.

This is an ABI change.  The timerfd code is new in 2.6.22 and if we merge this
into 2.6.23 then we should also merge it into 2.6.22.x.  That will leave a few
early 2.6.22 kernels out in the wild which might misbehave when a future
timerfd-enabled glibc is run on them.

mtk says:
The difference would be that read() will only return 4 bytes,
while the application will expect 8.  If the application is
checking the size of returned value, as it should, then it will
be able to detect the problem (it could even be sophisticated
enough to know that if this is a 4-byte return, then it is
running on an old 2.6.22 kernel).  If the application is not
checking the return from read(), then its 8-byte buffer will not
be filled -- the contents of the last 4 bytes will be undefined,
so the u64 value as a whole will be junk.

When I wrote up that description above, I forgot a crucial
detail.  The above description described the difference between
the new behavior implemented by the patch, and the current
(i.e., 2.6.22) *intended* behavior.  However, as I originally
remarked to Davide, the 2.6.22 read() behavior is broken: it
should return 4 bytes on a read(), but as originally
implemented, only the least significant byte contained valid
information.  (In other words, the top 3 bytes of overrun
information were simply being discarded.)

So the patch both fixes a bug in the originally intended
behavior, and changes the intended behavior (to return 8 bytes
from a read() instead of 4).

Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Cc: Michael Kerrisk <mtk-manpages@gmx.net>
Cc: Davi Arnaut <davi@haxent.com.br>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
fs/timerfd.c