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/
