Re: Why does timerfd() only support CLOCK_REALTIME andCLOCK_MONOTONIC?

[Greg KH]

On Mon, Feb 09, 2009 at 11:12:21AM +1300, Michael Kerrisk wrote:
> On Mon, Feb 9, 2009 at 11:06 AM, Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote:
> > On Mon, 9 Feb 2009, Michael Kerrisk wrote:
> >
> >> On Mon, Feb 9, 2009 at 10:50 AM, Davide Libenzi <davidel@xxxxxxxxxxxxxxx> wrote:
> >> > On Mon, 9 Feb 2009, Michael Kerrisk wrote:
> >> >
> >> >> > @@ -186,12 +187,9 @@ SYSCALL_DEFINE2(timerfd_create, int, clo
> >> >> >        BUILD_BUG_ON(TFD_CLOEXEC != O_CLOEXEC);
> >> >> >        BUILD_BUG_ON(TFD_NONBLOCK != O_NONBLOCK);
> >> >> >
> >> >> > -       if (flags & ~(TFD_CLOEXEC | TFD_NONBLOCK))
> >> >> > +       if ((flags & ~TFD_FLAGS_SET) ||
> >> >> > +           invalid_clockid(clockid))
> >> >> >                return -EINVAL;
> >> >>
> >> >> Oh!  Does this mean that in 2.6.2[789] it wasn't possible to use
> >> >> TFD_TIMER_ABSTIME?
> >> >
> >> > No, sorry, my fault. Patch is wrong. In "create" ATM we accept only
> >> > FCNTL-like flags. In "settime" we get TFD_TIMER_ABSTIME (that needs a
> >> > check too for EINVAL).
> >>
> >> That last piece should be a separate patch, that also gets pushed back
> >> into -stable.  Do you agree?
> >
> > Hmm, it's a check for extra bits that do not cause any harm. Dunno if it
> > fits -stable requirements. You should ask Greg.
> 
> I agree that it's not a critical fix.  The point is of course that if
> other flags are evntually added to timerfd_settime(), an application
> needs a way of checking for kernel support / lack of support (a la the
> recent discussion of eventfd "[patch/rfc] eventfd semaphore-like
> behavior").  It seems to me it would be good to have that check work
> as far back as possible in older kernels. If that check is to be added
> to 2.6.29, it seems reasonable to push it back to the current -stable
> kernels.
> 
> Greg?

Sounds reasonable to me.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/