On Thu, 12 Apr 2012 18:01:20 +0800yeah, it's really not necessary. I slipped up..
handai.szj@xxxxxxxxx wrote:
From: Sha Zhengju<handai.szj@xxxxxxxxxx>Changing `n' to an unsigned type makes the "if (n< 0)" test a no-op.
From: Sha Zhengju<handai.szj@xxxxxxxxxx>
eventfd_ctx->count is an __u64 counter which is allowed to reach ULLONG_MAX.
Now eventfd_write() add an __u64 value to "count", but kernel side
eventfd_signal() only add an int value to it. So make them consistent here.
...
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -51,7 +51,7 @@ struct eventfd_ctx {
*
* -EINVAL : The value of @n is negative.
*/
-int eventfd_signal(struct eventfd_ctx *ctx, int n)
+__u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
{
unsigned long flags;
@@ -59,7 +59,7 @@ int eventfd_signal(struct eventfd_ctx *ctx, int n)
return -EINVAL;
spin_lock_irqsave(&ctx->wqh.lock, flags);
if (ULLONG_MAX - ctx->count< n)
- n = (int) (ULLONG_MAX - ctx->count);
+ n = ULLONG_MAX - ctx->count;
ctx->count += n;
if (waitqueue_active(&ctx->wqh))
wake_up_locked_poll(&ctx->wqh, POLLIN);
Every in-kernel caller of eventfd_signal() passes n=1. All of them.A userspace write(2) performing on an eventfd can pass an u64 value to
Perhaps we can just remove that argument and hard-wire the +1
assumption into eventfd_signal().