On Wed, Jun 11, 2014 at 01:52:46PM +0400, Cyrill Gorcunov wrote: > On Wed, Jun 11, 2014 at 01:09:15PM +0400, Andrew Vagin wrote: > > On Wed, Jun 11, 2014 at 11:51:25AM +0400, Cyrill Gorcunov wrote: > > > On Wed, Jun 11, 2014 at 11:27:43AM +0400, Andrew Vagin wrote: > > > > Setting ticks to zero is equivalent to timerfd_read(), isn't it? > > So do we need to re-arme the timer, if it's periodic? > > I must admit I'm not really sure if we should rearm it in such > case. In general @ticks are zeroified in case of timer-setup/cancel/read. > > - lets consider someone armed the timer it triggered but no read done > yet, instead ioctl called and @ticks are set to zero, then call for > read() and it returns zero to caller not rearming the timer (in > current patch approach and non-block read) > > - in turn if we rearm timer on @ticks = 0 in ioctl this makes it > close to behaviour of read() function (which in turn look to > me as a duplication of read() interface). > > That said, I'm not sure yet...
What if we prohibit setting non-zero values here? @ticks are set to zero on timerfd_setup thus there is always a way to create a timer with fields zeroified. Something like case TFD_IOC_SET_TICKS: { u64 ticks; if (get_user(ticks, (u64 __user *)arg)) return -EFAULT; if (!ticks) return -EINVAL; spin_lock_irq(&ctx->wqh.lock); if (!timerfd_canceled(ctx)) { ctx->ticks = ticks; if (ticks) wake_up_locked(&ctx->wqh); else } else ret = -ECANCELED; spin_unlock_irq(&ctx->wqh.lock); break; } ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/