From: Davi Arnaut <davi@haxent.com.br>
To: Michael Kerrisk <mtk-manpages@gmx.net>
Cc: Davide Libenzi <davidel@xmailserver.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: Fwd: timerfd read only gets single byte?
Date: Tue, 17 Jul 2007 08:31:19 -0300 [thread overview]
Message-ID: <469CA887.1080801@haxent.com.br> (raw)
In-Reply-To: <750c918d0707170424v5e4187dducb1dcaeea5ad9db7@mail.gmail.com>
Michael Kerrisk wrote:
>
> Hi Davide,
>
> While writing a test program to incorporate into the timerfd.2 man page, I
> think I've found a bug. It looks like only the least significant byte of
> ticks is being returned from read(2), even though I am providing a 4 byte
> buffer.
>
> The test program takes 3 command line arguments:
>
> 1) seconds for the initial expiration
> 2) seconds for the timer interval
> 3) number of timer expirations to catch before terminating
>
> I tried running this program and suspending it for a few minutes, to see if
> I could get a large overrun value. When I do this on 2.6.22-rc4 (the built
> kernel I have to hand), I see the following:
>
> ============
> $ ./timerfd_demo 1 1 500
> 0.000: timer started
> 1.005: read: 1; total=1
> 2.005: read: 1; total=2
> 3.005: read: 1; total=3
> 4.005: read: 1; total=4
> 5.006: read: 1; total=5
> ^Z
> [1]+ Stopped ./timerfd_demo 1 1 500
> $ date
> Tue Jul 17 09:18:11 CEST 2007
> $ date
> Tue Jul 17 09:23:40 CEST 2007
> $ fg
> ./timerfd_demo 1 1 500
> 339.769: read: 78; total=83
> 340.004: read: 1; total=84
> 341.004: read: 1; total=85
> ^C
> ==============
>
> The after bringing the program back into the foreground, I would have
> expected to get an overrun count of 334 or thereabouts, but it looks as
> though I'm only getting the least significant byte from read(2).
>
> Cheers,
>
> Michael
>
> [...]
put_user copies sizeof(*ptr) bytes to user space.
Signed-off-by: Davi Arnaut <davi@haxent.com.br
diff --git a/fs/timerfd.c b/fs/timerfd.c
index af9eca5..e9f73f5 100644
--- a/fs/timerfd.c
+++ b/fs/timerfd.c
@@ -140,7 +140,8 @@ static ssize_t timerfd_read(struct file *file, char
__user *buf, size_t count,
}
spin_unlock_irq(&ctx->wqh.lock);
if (ticks)
- res = put_user(ticks, buf) ? -EFAULT: sizeof(ticks);
+ res = put_user(ticks, ((u32 __user *)buf)) ? -EFAULT :
+ sizeof(ticks);
return res;
}
next prev parent reply other threads:[~2007-07-17 11:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-17 7:28 timerfd read only gets single byte? Michael Kerrisk
[not found] ` <750c918d0707170424v5e4187dducb1dcaeea5ad9db7@mail.gmail.com>
2007-07-17 11:31 ` Davi Arnaut [this message]
2007-07-17 19:19 ` Fwd: " Davide Libenzi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=469CA887.1080801@haxent.com.br \
--to=davi@haxent.com.br \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk-manpages@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox