[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090209022428.GA10891@suse.de>
Date: Sun, 8 Feb 2009 18:24:28 -0800
From: Greg KH <gregkh@...e.de>
To: mtk.manpages@...il.com
Cc: Davide Libenzi <davidel@...ilserver.org>,
"linux-man@...r.kernel.org" <linux-man@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>, stable@...nel.org
Subject: Re: Why does timerfd() only support CLOCK_REALTIME and
CLOCK_MONOTONIC?
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@...ilserver.org> wrote:
> > On Mon, 9 Feb 2009, Michael Kerrisk wrote:
> >
> >> On Mon, Feb 9, 2009 at 10:50 AM, Davide Libenzi <davidel@...ilserver.org> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists