From patchwork Fri Oct 9 08:25:14 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jesper Nilsson X-Patchwork-Id: 7359871 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 13CEA9F1D5 for ; Fri, 9 Oct 2015 08:25:50 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3ECE5203C1 for ; Fri, 9 Oct 2015 08:25:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4750A203B8 for ; Fri, 9 Oct 2015 08:25:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933828AbbJIIZY (ORCPT ); Fri, 9 Oct 2015 04:25:24 -0400 Received: from bes.se.axis.com ([195.60.68.10]:40544 "EHLO bes.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933490AbbJIIZS (ORCPT ); Fri, 9 Oct 2015 04:25:18 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.se.axis.com (Postfix) with ESMTP id 98FEE2E0BA; Fri, 9 Oct 2015 10:25:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bes.se.axis.com Received: from bes.se.axis.com ([IPv6:::ffff:127.0.0.1]) by localhost (bes.se.axis.com [::ffff:127.0.0.1]) (amavisd-new, port 10024) with LMTP id XS8VGhi9UF44; Fri, 9 Oct 2015 10:25:15 +0200 (CEST) Received: from boulder.se.axis.com (boulder.se.axis.com [10.0.2.104]) by bes.se.axis.com (Postfix) with ESMTP id 554EE2E533; Fri, 9 Oct 2015 10:25:15 +0200 (CEST) Received: from boulder.se.axis.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 35DC110E6; Fri, 9 Oct 2015 10:25:15 +0200 (CEST) Received: from thoth.se.axis.com (thoth.se.axis.com [10.0.2.173]) by boulder.se.axis.com (Postfix) with ESMTP id 28597208; Fri, 9 Oct 2015 10:25:15 +0200 (CEST) Received: from battery-1.se.axis.com (battery-1.se.axis.com [10.0.8.110]) by thoth.se.axis.com (Postfix) with ESMTP id 2385C34009; Fri, 9 Oct 2015 10:25:15 +0200 (CEST) Received: by battery-1.se.axis.com (Postfix, from userid 363) id 15C7A624A; Fri, 9 Oct 2015 10:25:15 +0200 (CEST) Date: Fri, 9 Oct 2015 10:25:14 +0200 From: Jesper Nilsson To: Thomas Gleixner , Alexander Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, John Stultz , Michael Kerrisk Subject: [RESEND PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts Message-ID: <20151009082514.GY4919@axis.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Allow TFD_TIMER_CANCEL_ON_SET on timerfd_settime() with relative as well as absolute timeout. Signed-off-by: Jesper Nilsson --- Resending after some discussion with Thomas Gleixner at ELCE, and Cc:ing John Stultz and Michael Kerrisk who may have comments. Longer background: One of the uses for TFD_TIMER_CANCEL_ON_SET is to get an event when the CLOCK_REALTIME changes (as by NTP or user action). In this case, the timeout irrelevant, and the maximum available value would be selected to avoid mis-triggers. However, timerfd uses time_t for configuration, and the maximum value on a 32bit time_t system is actually a valid time (near 2038-01-19 03:14) in the 64bit ktime_t used internally in timerfd. One way of provoking this problem would be to set the time using "date '2038-01-19 03:14'" and letting the time roll over a few seconds later. After this time, a timerfd will continuously fire when configured with a maximum absolute timeout, potentially stealing all CPU and stopping the application from doing what it really should be doing. Which would be fine, unless the application is systemd and loops at startup, leaving the system in a state where the kernel is up, but nothing running in userspace. :-( This problem was further exposed in kernel v3.19 by commit a6d6e1c879efa4b77e250c34fe5fe1c34e6ef070 which introduced 64bit time in the RTC subsystem. On an unconfigured RTC or an RTC with flat/removed battery the date on could be random, and in some cases past 2038. Of course, the proposed patch only allows the setting of relative timeouts with TFD_TIMER_CANCEL_ON_SET, any application using it would also need to be patched to use the relative timer for this solve the described problem. Another solution would be to add a new flag to timerfd_settime() to indicate that the timer value is irrelevant, but I considered it an unnecessary waste of a flag-bit. A third possible solution is to steal the time (0,0) (which currently gives -EINVAL) to indicate that the timeout is irrelevant. This would however be a change in behaviour that a current user wouldn't expect, perhaps making a previously correctly failing application wait until a time change (or forever) Tested on a MIPS 34Kc with kernel v4.1. fs/timerfd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/timerfd.c b/fs/timerfd.c index b94fa6c..8ec3aeb 100644 --- a/fs/timerfd.c +++ b/fs/timerfd.c @@ -134,7 +134,7 @@ static void timerfd_setup_cancel(struct timerfd_ctx *ctx, int flags) { if ((ctx->clockid == CLOCK_REALTIME || ctx->clockid == CLOCK_REALTIME_ALARM) && - (flags & TFD_TIMER_ABSTIME) && (flags & TFD_TIMER_CANCEL_ON_SET)) { + (flags & TFD_TIMER_CANCEL_ON_SET)) { if (!ctx->might_cancel) { ctx->might_cancel = true; spin_lock(&cancel_lock);