On Tue, 17 Jul 2007, Davi Arnaut wrote:
> 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 <[email protected]
>
>
> 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;
> }
Yeah, thanks. But talking to Michael, we think it's better to use an u64
like we do in the eventfd.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]