Re: [patch 2/4] new timerfd API v2 - new timerfd API
Davide Libenzi wrote: > On Tue, 25 Sep 2007, Jonathan Corbet wrote: > >> One quick question: >> >>> Like the previous timerfd API implementation, read(2) and poll(2) are >>> supported >>> (with the same interface). >> Looking at that interface, it appears that a process doing a read() on a >> timerfd with no timer set will block for a very long time. It's an >> obvious "don't do that" situation, but perhaps we could help an >> occasional developer get a clue by returning something like -EINVAL when >> the timer has not been set? > > That is the same as you try to read once more after an expired timer. You > won't wake up until the next timer event will show up. That is, after at > most TP time for periodic timers, or after the time the next > timerfd_settime() will setup. > I'd like to keep the "timerfd not set yet" and the "timerfd already > expired and not re-armed" acting the same way. That is, wait till next > event happen (unless O_NONBLOCK of course). Yes. The timer_settime() and read() might for example be done in separate threads, and it would make sense for the read() to block until the timer has been armed. Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages/ read the HOWTOHELP file and grep the source files for 'FIXME'. - 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/
Re: [patch 2/4] new timerfd API v2 - new timerfd API
Davide Libenzi wrote: On Tue, 25 Sep 2007, Jonathan Corbet wrote: One quick question: Like the previous timerfd API implementation, read(2) and poll(2) are supported (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block for a very long time. It's an obvious don't do that situation, but perhaps we could help an occasional developer get a clue by returning something like -EINVAL when the timer has not been set? That is the same as you try to read once more after an expired timer. You won't wake up until the next timer event will show up. That is, after at most TP time for periodic timers, or after the time the next timerfd_settime() will setup. I'd like to keep the timerfd not set yet and the timerfd already expired and not re-armed acting the same way. That is, wait till next event happen (unless O_NONBLOCK of course). Yes. The timer_settime() and read() might for example be done in separate threads, and it would make sense for the read() to block until the timer has been armed. Cheers, Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7 Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages/ read the HOWTOHELP file and grep the source files for 'FIXME'. - 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/
Re: [patch 2/4] new timerfd API v2 - new timerfd API
On Tue, 25 Sep 2007, Jonathan Corbet wrote: > One quick question: > > > Like the previous timerfd API implementation, read(2) and poll(2) are > > supported > > (with the same interface). > > Looking at that interface, it appears that a process doing a read() on a > timerfd with no timer set will block for a very long time. It's an > obvious "don't do that" situation, but perhaps we could help an > occasional developer get a clue by returning something like -EINVAL when > the timer has not been set? That is the same as you try to read once more after an expired timer. You won't wake up until the next timer event will show up. That is, after at most TP time for periodic timers, or after the time the next timerfd_settime() will setup. I'd like to keep the "timerfd not set yet" and the "timerfd already expired and not re-armed" acting the same way. That is, wait till next event happen (unless O_NONBLOCK of course). - 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/
Re: [patch 2/4] new timerfd API v2 - new timerfd API
One quick question: > Like the previous timerfd API implementation, read(2) and poll(2) are > supported > (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block for a very long time. It's an obvious "don't do that" situation, but perhaps we could help an occasional developer get a clue by returning something like -EINVAL when the timer has not been set? jon - 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/
Re: [patch 2/4] new timerfd API v2 - new timerfd API
One quick question: Like the previous timerfd API implementation, read(2) and poll(2) are supported (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block for a very long time. It's an obvious don't do that situation, but perhaps we could help an occasional developer get a clue by returning something like -EINVAL when the timer has not been set? jon - 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/
Re: [patch 2/4] new timerfd API v2 - new timerfd API
On Tue, 25 Sep 2007, Jonathan Corbet wrote: One quick question: Like the previous timerfd API implementation, read(2) and poll(2) are supported (with the same interface). Looking at that interface, it appears that a process doing a read() on a timerfd with no timer set will block for a very long time. It's an obvious don't do that situation, but perhaps we could help an occasional developer get a clue by returning something like -EINVAL when the timer has not been set? That is the same as you try to read once more after an expired timer. You won't wake up until the next timer event will show up. That is, after at most TP time for periodic timers, or after the time the next timerfd_settime() will setup. I'd like to keep the timerfd not set yet and the timerfd already expired and not re-armed acting the same way. That is, wait till next event happen (unless O_NONBLOCK of course). - 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/
Re: [patch 2/4] new timerfd API v2 - new timerfd API
Davide Libenzi wrote:
> This is the new timerfd API as it is implemented by the following patch:
>
> int timerfd_create(int clockid);
> int timerfd_settime(int ufd, int flags,
> const struct itimerspec *utmr,
> struct itimerspec *otmr);
> int timerfd_gettime(int ufd, struct itimerspec *otmr);
>
> The timerfd_create() API creates an un-programmed timerfd fd. The "clockid"
> parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
> The timerfd_settime() API give new settings by the timerfd fd, by optionally
> retrieving the previous expiration time (in case the "otmr" parameter is not
> NULL).
> The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
> is set in the "flags" parameter. Otherwise it's a relative time.
> The timerfd_gettime() API returns the next expiration time of the timer, or
> {0, 0}
> if the timerfd has not been set yet.
> Like the previous timerfd API implementation, read(2) and poll(2) are
> supported
> (with the same interface).
> Here's a simple test program I used to exercise the new timerfd APIs:
>
> http://www.xmailserver.org/timerfd-test2.c
>
>
>
> Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
>
>
> - Davide
>
>
> ---
> fs/compat.c | 32 ++-
> fs/timerfd.c | 197
> ++-
> include/linux/compat.h |7 +
> include/linux/syscalls.h |7 +
> 4 files changed, 164 insertions(+), 79 deletions(-)
>
> Index: linux-2.6.mod/fs/timerfd.c
> ===
> --- linux-2.6.mod.orig/fs/timerfd.c 2007-09-24 12:26:19.0 -0700
> +++ linux-2.6.mod/fs/timerfd.c2007-09-24 12:31:22.0 -0700
> @@ -25,13 +25,15 @@
> struct hrtimer tmr;
> ktime_t tintv;
> wait_queue_head_t wqh;
> + u64 ticks;
> int expired;
> + int clockid;
> };
>
> /*
> * This gets called when the timer event triggers. We set the "expired"
> * flag, but we do not re-arm the timer (in case it's necessary,
> - * tintv.tv64 != 0) until the timer is read.
> + * tintv.tv64 != 0) until the timer is accessed.
> */
> static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
> {
> @@ -40,13 +42,14 @@
>
> spin_lock_irqsave(>wqh.lock, flags);
> ctx->expired = 1;
> + ctx->ticks++;
> wake_up_locked(>wqh);
> spin_unlock_irqrestore(>wqh.lock, flags);
>
> return HRTIMER_NORESTART;
> }
>
> -static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
> +static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
> const struct itimerspec *ktmr)
> {
> enum hrtimer_mode htmode;
> @@ -57,8 +60,9 @@
>
> texp = timespec_to_ktime(ktmr->it_value);
> ctx->expired = 0;
> + ctx->ticks = 0;
> ctx->tintv = timespec_to_ktime(ktmr->it_interval);
> - hrtimer_init(>tmr, clockid, htmode);
> + hrtimer_init(>tmr, ctx->clockid, htmode);
> ctx->tmr.expires = texp;
> ctx->tmr.function = timerfd_tmrproc;
> if (texp.tv64 != 0)
> @@ -83,7 +87,7 @@
> poll_wait(file, >wqh, wait);
>
> spin_lock_irqsave(>wqh.lock, flags);
> - if (ctx->expired)
> + if (ctx->ticks)
> events |= POLLIN;
> spin_unlock_irqrestore(>wqh.lock, flags);
>
> @@ -102,11 +106,11 @@
> return -EINVAL;
> spin_lock_irq(>wqh.lock);
> res = -EAGAIN;
> - if (!ctx->expired && !(file->f_flags & O_NONBLOCK)) {
> + if (!ctx->ticks && !(file->f_flags & O_NONBLOCK)) {
> __add_wait_queue(>wqh, );
> for (res = 0;;) {
> set_current_state(TASK_INTERRUPTIBLE);
> - if (ctx->expired) {
> + if (ctx->ticks) {
> res = 0;
> break;
> }
> @@ -121,22 +125,21 @@
> __remove_wait_queue(>wqh, );
> __set_current_state(TASK_RUNNING);
> }
> - if (ctx->expired) {
> - ctx->expired = 0;
> - if (ctx->tintv.tv64 != 0) {
> + if (ctx->ticks) {
> + ticks = ctx->ticks;
> + if (ctx->expired && ctx->tintv.tv64) {
> /*
>* If tintv.tv64 != 0, this is a periodic timer that
>* needs to be re-armed. We avoid doing it in the timer
>* callback to avoid DoS attacks specifying a very
>* short timer period.
>*/
> - ticks = (u64)
> - hrtimer_forward(>tmr,
> - hrtimer_cb_get_time(>tmr),
> - ctx->tintv);
> + ticks += (u64) hrtimer_forward_now(>tmr,
> +ctx->tintv) - 1;
>
[patch 2/4] new timerfd API v2 - new timerfd API
This is the new timerfd API as it is implemented by the following patch:
int timerfd_create(int clockid);
int timerfd_settime(int ufd, int flags,
const struct itimerspec *utmr,
struct itimerspec *otmr);
int timerfd_gettime(int ufd, struct itimerspec *otmr);
The timerfd_create() API creates an un-programmed timerfd fd. The "clockid"
parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
The timerfd_settime() API give new settings by the timerfd fd, by optionally
retrieving the previous expiration time (in case the "otmr" parameter is not
NULL).
The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
is set in the "flags" parameter. Otherwise it's a relative time.
The timerfd_gettime() API returns the next expiration time of the timer, or {0,
0}
if the timerfd has not been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi <[EMAIL PROTECTED]>
- Davide
---
fs/compat.c | 32 ++-
fs/timerfd.c | 197 ++-
include/linux/compat.h |7 +
include/linux/syscalls.h |7 +
4 files changed, 164 insertions(+), 79 deletions(-)
Index: linux-2.6.mod/fs/timerfd.c
===
--- linux-2.6.mod.orig/fs/timerfd.c 2007-09-24 12:26:19.0 -0700
+++ linux-2.6.mod/fs/timerfd.c 2007-09-24 12:31:22.0 -0700
@@ -25,13 +25,15 @@
struct hrtimer tmr;
ktime_t tintv;
wait_queue_head_t wqh;
+ u64 ticks;
int expired;
+ int clockid;
};
/*
* This gets called when the timer event triggers. We set the "expired"
* flag, but we do not re-arm the timer (in case it's necessary,
- * tintv.tv64 != 0) until the timer is read.
+ * tintv.tv64 != 0) until the timer is accessed.
*/
static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
{
@@ -40,13 +42,14 @@
spin_lock_irqsave(>wqh.lock, flags);
ctx->expired = 1;
+ ctx->ticks++;
wake_up_locked(>wqh);
spin_unlock_irqrestore(>wqh.lock, flags);
return HRTIMER_NORESTART;
}
-static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
+static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
const struct itimerspec *ktmr)
{
enum hrtimer_mode htmode;
@@ -57,8 +60,9 @@
texp = timespec_to_ktime(ktmr->it_value);
ctx->expired = 0;
+ ctx->ticks = 0;
ctx->tintv = timespec_to_ktime(ktmr->it_interval);
- hrtimer_init(>tmr, clockid, htmode);
+ hrtimer_init(>tmr, ctx->clockid, htmode);
ctx->tmr.expires = texp;
ctx->tmr.function = timerfd_tmrproc;
if (texp.tv64 != 0)
@@ -83,7 +87,7 @@
poll_wait(file, >wqh, wait);
spin_lock_irqsave(>wqh.lock, flags);
- if (ctx->expired)
+ if (ctx->ticks)
events |= POLLIN;
spin_unlock_irqrestore(>wqh.lock, flags);
@@ -102,11 +106,11 @@
return -EINVAL;
spin_lock_irq(>wqh.lock);
res = -EAGAIN;
- if (!ctx->expired && !(file->f_flags & O_NONBLOCK)) {
+ if (!ctx->ticks && !(file->f_flags & O_NONBLOCK)) {
__add_wait_queue(>wqh, );
for (res = 0;;) {
set_current_state(TASK_INTERRUPTIBLE);
- if (ctx->expired) {
+ if (ctx->ticks) {
res = 0;
break;
}
@@ -121,22 +125,21 @@
__remove_wait_queue(>wqh, );
__set_current_state(TASK_RUNNING);
}
- if (ctx->expired) {
- ctx->expired = 0;
- if (ctx->tintv.tv64 != 0) {
+ if (ctx->ticks) {
+ ticks = ctx->ticks;
+ if (ctx->expired && ctx->tintv.tv64) {
/*
* If tintv.tv64 != 0, this is a periodic timer that
* needs to be re-armed. We avoid doing it in the timer
* callback to avoid DoS attacks specifying a very
* short timer period.
*/
- ticks = (u64)
- hrtimer_forward(>tmr,
- hrtimer_cb_get_time(>tmr),
- ctx->tintv);
+ ticks += (u64) hrtimer_forward_now(>tmr,
+ ctx->tintv) - 1;
hrtimer_restart(>tmr);
- } else
- ticks = 1;
+ }
+ ctx->expired = 0;
+
[patch 2/4] new timerfd API v2 - new timerfd API
This is the new timerfd API as it is implemented by the following patch:
int timerfd_create(int clockid);
int timerfd_settime(int ufd, int flags,
const struct itimerspec *utmr,
struct itimerspec *otmr);
int timerfd_gettime(int ufd, struct itimerspec *otmr);
The timerfd_create() API creates an un-programmed timerfd fd. The clockid
parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
The timerfd_settime() API give new settings by the timerfd fd, by optionally
retrieving the previous expiration time (in case the otmr parameter is not
NULL).
The time value specified in utmr is absolute, if the TFD_TIMER_ABSTIME bit
is set in the flags parameter. Otherwise it's a relative time.
The timerfd_gettime() API returns the next expiration time of the timer, or {0,
0}
if the timerfd has not been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs/compat.c | 32 ++-
fs/timerfd.c | 197 ++-
include/linux/compat.h |7 +
include/linux/syscalls.h |7 +
4 files changed, 164 insertions(+), 79 deletions(-)
Index: linux-2.6.mod/fs/timerfd.c
===
--- linux-2.6.mod.orig/fs/timerfd.c 2007-09-24 12:26:19.0 -0700
+++ linux-2.6.mod/fs/timerfd.c 2007-09-24 12:31:22.0 -0700
@@ -25,13 +25,15 @@
struct hrtimer tmr;
ktime_t tintv;
wait_queue_head_t wqh;
+ u64 ticks;
int expired;
+ int clockid;
};
/*
* This gets called when the timer event triggers. We set the expired
* flag, but we do not re-arm the timer (in case it's necessary,
- * tintv.tv64 != 0) until the timer is read.
+ * tintv.tv64 != 0) until the timer is accessed.
*/
static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
{
@@ -40,13 +42,14 @@
spin_lock_irqsave(ctx-wqh.lock, flags);
ctx-expired = 1;
+ ctx-ticks++;
wake_up_locked(ctx-wqh);
spin_unlock_irqrestore(ctx-wqh.lock, flags);
return HRTIMER_NORESTART;
}
-static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
+static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
const struct itimerspec *ktmr)
{
enum hrtimer_mode htmode;
@@ -57,8 +60,9 @@
texp = timespec_to_ktime(ktmr-it_value);
ctx-expired = 0;
+ ctx-ticks = 0;
ctx-tintv = timespec_to_ktime(ktmr-it_interval);
- hrtimer_init(ctx-tmr, clockid, htmode);
+ hrtimer_init(ctx-tmr, ctx-clockid, htmode);
ctx-tmr.expires = texp;
ctx-tmr.function = timerfd_tmrproc;
if (texp.tv64 != 0)
@@ -83,7 +87,7 @@
poll_wait(file, ctx-wqh, wait);
spin_lock_irqsave(ctx-wqh.lock, flags);
- if (ctx-expired)
+ if (ctx-ticks)
events |= POLLIN;
spin_unlock_irqrestore(ctx-wqh.lock, flags);
@@ -102,11 +106,11 @@
return -EINVAL;
spin_lock_irq(ctx-wqh.lock);
res = -EAGAIN;
- if (!ctx-expired !(file-f_flags O_NONBLOCK)) {
+ if (!ctx-ticks !(file-f_flags O_NONBLOCK)) {
__add_wait_queue(ctx-wqh, wait);
for (res = 0;;) {
set_current_state(TASK_INTERRUPTIBLE);
- if (ctx-expired) {
+ if (ctx-ticks) {
res = 0;
break;
}
@@ -121,22 +125,21 @@
__remove_wait_queue(ctx-wqh, wait);
__set_current_state(TASK_RUNNING);
}
- if (ctx-expired) {
- ctx-expired = 0;
- if (ctx-tintv.tv64 != 0) {
+ if (ctx-ticks) {
+ ticks = ctx-ticks;
+ if (ctx-expired ctx-tintv.tv64) {
/*
* If tintv.tv64 != 0, this is a periodic timer that
* needs to be re-armed. We avoid doing it in the timer
* callback to avoid DoS attacks specifying a very
* short timer period.
*/
- ticks = (u64)
- hrtimer_forward(ctx-tmr,
- hrtimer_cb_get_time(ctx-tmr),
- ctx-tintv);
+ ticks += (u64) hrtimer_forward_now(ctx-tmr,
+ ctx-tintv) - 1;
hrtimer_restart(ctx-tmr);
- } else
- ticks = 1;
+ }
+ ctx-expired = 0;
+
Re: [patch 2/4] new timerfd API v2 - new timerfd API
Davide Libenzi wrote:
This is the new timerfd API as it is implemented by the following patch:
int timerfd_create(int clockid);
int timerfd_settime(int ufd, int flags,
const struct itimerspec *utmr,
struct itimerspec *otmr);
int timerfd_gettime(int ufd, struct itimerspec *otmr);
The timerfd_create() API creates an un-programmed timerfd fd. The clockid
parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
The timerfd_settime() API give new settings by the timerfd fd, by optionally
retrieving the previous expiration time (in case the otmr parameter is not
NULL).
The time value specified in utmr is absolute, if the TFD_TIMER_ABSTIME bit
is set in the flags parameter. Otherwise it's a relative time.
The timerfd_gettime() API returns the next expiration time of the timer, or
{0, 0}
if the timerfd has not been set yet.
Like the previous timerfd API implementation, read(2) and poll(2) are
supported
(with the same interface).
Here's a simple test program I used to exercise the new timerfd APIs:
http://www.xmailserver.org/timerfd-test2.c
Signed-off-by: Davide Libenzi [EMAIL PROTECTED]
- Davide
---
fs/compat.c | 32 ++-
fs/timerfd.c | 197
++-
include/linux/compat.h |7 +
include/linux/syscalls.h |7 +
4 files changed, 164 insertions(+), 79 deletions(-)
Index: linux-2.6.mod/fs/timerfd.c
===
--- linux-2.6.mod.orig/fs/timerfd.c 2007-09-24 12:26:19.0 -0700
+++ linux-2.6.mod/fs/timerfd.c2007-09-24 12:31:22.0 -0700
@@ -25,13 +25,15 @@
struct hrtimer tmr;
ktime_t tintv;
wait_queue_head_t wqh;
+ u64 ticks;
int expired;
+ int clockid;
};
/*
* This gets called when the timer event triggers. We set the expired
* flag, but we do not re-arm the timer (in case it's necessary,
- * tintv.tv64 != 0) until the timer is read.
+ * tintv.tv64 != 0) until the timer is accessed.
*/
static enum hrtimer_restart timerfd_tmrproc(struct hrtimer *htmr)
{
@@ -40,13 +42,14 @@
spin_lock_irqsave(ctx-wqh.lock, flags);
ctx-expired = 1;
+ ctx-ticks++;
wake_up_locked(ctx-wqh);
spin_unlock_irqrestore(ctx-wqh.lock, flags);
return HRTIMER_NORESTART;
}
-static void timerfd_setup(struct timerfd_ctx *ctx, int clockid, int flags,
+static void timerfd_setup(struct timerfd_ctx *ctx, int flags,
const struct itimerspec *ktmr)
{
enum hrtimer_mode htmode;
@@ -57,8 +60,9 @@
texp = timespec_to_ktime(ktmr-it_value);
ctx-expired = 0;
+ ctx-ticks = 0;
ctx-tintv = timespec_to_ktime(ktmr-it_interval);
- hrtimer_init(ctx-tmr, clockid, htmode);
+ hrtimer_init(ctx-tmr, ctx-clockid, htmode);
ctx-tmr.expires = texp;
ctx-tmr.function = timerfd_tmrproc;
if (texp.tv64 != 0)
@@ -83,7 +87,7 @@
poll_wait(file, ctx-wqh, wait);
spin_lock_irqsave(ctx-wqh.lock, flags);
- if (ctx-expired)
+ if (ctx-ticks)
events |= POLLIN;
spin_unlock_irqrestore(ctx-wqh.lock, flags);
@@ -102,11 +106,11 @@
return -EINVAL;
spin_lock_irq(ctx-wqh.lock);
res = -EAGAIN;
- if (!ctx-expired !(file-f_flags O_NONBLOCK)) {
+ if (!ctx-ticks !(file-f_flags O_NONBLOCK)) {
__add_wait_queue(ctx-wqh, wait);
for (res = 0;;) {
set_current_state(TASK_INTERRUPTIBLE);
- if (ctx-expired) {
+ if (ctx-ticks) {
res = 0;
break;
}
@@ -121,22 +125,21 @@
__remove_wait_queue(ctx-wqh, wait);
__set_current_state(TASK_RUNNING);
}
- if (ctx-expired) {
- ctx-expired = 0;
- if (ctx-tintv.tv64 != 0) {
+ if (ctx-ticks) {
+ ticks = ctx-ticks;
+ if (ctx-expired ctx-tintv.tv64) {
/*
* If tintv.tv64 != 0, this is a periodic timer that
* needs to be re-armed. We avoid doing it in the timer
* callback to avoid DoS attacks specifying a very
* short timer period.
*/
- ticks = (u64)
- hrtimer_forward(ctx-tmr,
- hrtimer_cb_get_time(ctx-tmr),
- ctx-tintv);
+ ticks += (u64) hrtimer_forward_now(ctx-tmr,
+ctx-tintv) - 1;
hrtimer_restart(ctx-tmr);
- } else
- ticks = 1;
+ }
+
