From patchwork Fri Apr 8 15:55:33 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepa Dinamani X-Patchwork-Id: 8784311 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 D2F39C0553 for ; Fri, 8 Apr 2016 15:55:52 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E8DE62021A for ; Fri, 8 Apr 2016 15:55:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 05B1A2026D for ; Fri, 8 Apr 2016 15:55:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755464AbcDHPzq (ORCPT ); Fri, 8 Apr 2016 11:55:46 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:33269 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751924AbcDHPzp (ORCPT ); Fri, 8 Apr 2016 11:55:45 -0400 Received: by mail-pf0-f194.google.com with SMTP id e190so9773931pfe.0 for ; Fri, 08 Apr 2016 08:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=VGlp+eIi7aQhdIxNoNFhOxdhHwOf5Hlkiq1DX138GWo=; b=XtUMTXHx5gc2pLKg298e9CJIF7sLWS2FjCja0IAcqacFwarYEZC+kmMlQB0Ve9qElW AqyUjTnq7Frl7B0DplhC/zwFjRUBEHkzBYxctyFQY88JI6e4SD+VJvws+OHT6yiUGj9z 0n3ssQjYM9R8QUuou4WWaYEtTNYUNhA9AkqFEZGxx508Odl6c+c4+VCsoEwVrHJ2JDHG +fZx89tjnvmUrxxee6rn/bOfs0qMdMtzrKniivOrnPz5WwXGGnbWfXa/73+10dg1AK5D O2RYmacM6UcDOKdE1POZA0IpRGbMeLdCLNOJh94cbLAkg9Fcr8mKSyG/ZqYmwLvyLj4x 6syA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=VGlp+eIi7aQhdIxNoNFhOxdhHwOf5Hlkiq1DX138GWo=; b=XyDqhKP9WdW7Eamr01hatFzAsdLScOQiF0PjGcSWWp9O3Nw9WqgFp0dGWmVW0FYkJJ VVbdn6aGqXT1mAi/06L+miEd/BLqpjj/4HcRF/mQlK6OZJFANpMqDqWyjTPw8KB9xLdB VhBJuNW3tglSxD4k0oVtlrnCEXQLSY6ghdhvI5JUz1bJ4XdGvhklU9RLiaLClPtB/6fu lygagMnGiAFOOU+/zrFfG7kkrvcevZt591NZQhBXBn/RClkQXAA3r2pgagTe69Iu7+lg 9ZktLtNAI5DK1sGXHk1x6dz+P/6uNvbYxJpcHkuUdoxIglW2OipxXL6SW3sRBv6E8rxa ym9Q== X-Gm-Message-State: AD7BkJIqsWpm/mJnOYsiXILfQfvuC1ibi/bgTo2pHVntVRBdFlmhAQAIoVlHuZUudW7WCg== X-Received: by 10.98.7.135 with SMTP id 7mr13566202pfh.124.1460130944396; Fri, 08 Apr 2016 08:55:44 -0700 (PDT) Received: from deepa-ubuntu.hsd1.ca.comcast.net (c-73-252-251-201.hsd1.ca.comcast.net. [73.252.251.201]) by smtp.gmail.com with ESMTPSA id q2sm19624595pfq.88.2016.04.08.08.55.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 08 Apr 2016 08:55:43 -0700 (PDT) From: Deepa Dinamani To: linux-fsdevel@vger.kernel.org, y2038@lists.linaro.org Cc: tglx@linutronix.de, arnd@arndb.de, viro@zeniv.linux.org.uk Subject: [PATCH RESEND] vfs: Add support to document max and min inode times Date: Fri, 8 Apr 2016 08:55:33 -0700 Message-Id: <1460130933-8307-1-git-send-email-deepa.kernel@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, 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 This is a preparation patch to add range checking for inode timestamps. Extend struct super_block to include information about the max and min inode times each filesystem can hold. These are dependent on the on-disk format of filesystems. These range checks will be used to clamp timestamps to filesystem allowed ranges. Individual filesystems do not have the same on disk format as the in memory inodes. Range checking and clamping times assigned to inodes will help keep in memory and on-disk timestamps to be in sync. Another series will initialize these fields to appropriate values for every filesystem. The fields are not used by vfs yet. The exact policy and behavior will be decided in a separate patch. The original idea for the feature comes from the discussion: https://lkml.org/lkml/2014/5/30/669 Signed-off-by: Deepa Dinamani Reviewed-by: Arnd Bergmann --- Resending for inclusion in Thomas's tree. include/linux/fs.h | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/include/linux/fs.h b/include/linux/fs.h index d0bf64f..c936314 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1374,7 +1374,14 @@ struct super_block { /* Granularity of c/m/atime in ns. Cannot be worse than a second */ - u32 s_time_gran; + u32 s_time_gran; + + /* + * Max and min values for timestamps + * according to the range supported by filesystems. + */ + time64_t s_time_min; + time64_t s_time_max; /* * The next field is for VFS *only*. No filesystems have any business