All of lore.kernel.org
 help / color / mirror / Atom feed
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;
 }


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.