From patchwork Mon Sep 7 11:12:22 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jesper Nilsson X-Patchwork-Id: 7133521 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 74F2BBEEC1 for ; Mon, 7 Sep 2015 11:12:31 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 89F21206D4 for ; Mon, 7 Sep 2015 11:12:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 25CDF20680 for ; Mon, 7 Sep 2015 11:12:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751157AbbIGLM0 (ORCPT ); Mon, 7 Sep 2015 07:12:26 -0400 Received: from bes.se.axis.com ([195.60.68.10]:37463 "EHLO bes.se.axis.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750901AbbIGLMZ (ORCPT ); Mon, 7 Sep 2015 07:12:25 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.se.axis.com (Postfix) with ESMTP id 551FA2E4B0; Mon, 7 Sep 2015 13:12:23 +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 4PijVQIeZ-KD; Mon, 7 Sep 2015 13:12:22 +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 705182E4AF; Mon, 7 Sep 2015 13:12:22 +0200 (CEST) Received: from boulder.se.axis.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 5668F10D1; Mon, 7 Sep 2015 13:12:22 +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 49B2FF7E; Mon, 7 Sep 2015 13:12:22 +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 46E2034005; Mon, 7 Sep 2015 13:12:22 +0200 (CEST) Received: by battery-1.se.axis.com (Postfix, from userid 363) id 3BEDA6248; Mon, 7 Sep 2015 13:12:22 +0200 (CEST) Date: Mon, 7 Sep 2015 13:12:22 +0200 From: Jesper Nilsson To: Thomas Gleixner , Alexander Viro , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [PATCH] timerfd: Allow TFD_TIMER_CANCEL_ON_SET with relative timeouts Message-ID: <20150907111222.GK32685@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=ham 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 --- 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 could 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. 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);