lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ