linux-kernel - Re: TFD_CANCEL_ON_SET race when making a wall clock

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]

Date:	Fri, 02 Sep 2011 11:07:37 -0400
From:	Colin Walters <walters@...bum.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: TFD_CANCEL_ON_SET race when making a wall clock

Hi Thomas,

On Fri, 2011-09-02 at 17:00 +0200, Thomas Gleixner wrote:

> There is no way to handle:
> 
>    clock_gettime(a);
> 				clock_settime();
>    timerfd_create();
>    timerfd_settime(a + x);
> 
> And there wont be one ever. 

Well, you can see what I did in userspace - require the processes' idea
of the current time to be passed in, and check after calling
timerfd_settime() - did the clock go backwards?  Ok, treat the timerfd
source as ready.

If we wanted to avoid userspace having to do this, we *could* make a new
system call which also took the "expected current time".  But it's
probably not worth doing so given that the userspace workaround isn't
too difficult.

So, I think you confirmed what I'm saying, we should just document this
and move on.   Thanks!

--
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/