linux-kernel - Re: Fwd: timerfd read only gets single byte?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0707171218120.26781@alien.or.mcafeemobile.com>
Date:	Tue, 17 Jul 2007 12:19:39 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Davi Arnaut <davi@...ent.com.br>
cc:	Michael Kerrisk <mtk-manpages@....net>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: Fwd: timerfd read only gets single byte?

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 <davi@...ent.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;
>  }

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/