From patchwork Fri Apr 1 20:58:06 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepa Dinamani X-Patchwork-Id: 8727721 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 446939F38C for ; Fri, 1 Apr 2016 21:00:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 54947203A1 for ; Fri, 1 Apr 2016 21:00:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 27C9B203A0 for ; Fri, 1 Apr 2016 21:00:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752337AbcDAVAd (ORCPT ); Fri, 1 Apr 2016 17:00:33 -0400 Received: from mail-pa0-f68.google.com ([209.85.220.68]:35582 "EHLO mail-pa0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751516AbcDAVAd (ORCPT ); Fri, 1 Apr 2016 17:00:33 -0400 Received: by mail-pa0-f68.google.com with SMTP id hn5so12346767pac.2 for ; Fri, 01 Apr 2016 14:00:32 -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=dc0+3lIYIMJ9v8NgJ/3by6okFVvQaiLJjIhDEwB5J3Q=; b=xTH5oaH9Qhjo+y+z5dZDkCyXvBA30Iev8hrCnnVQN7thpSnJZZKJu/kpQN4ebwdmPe zLPPjDNPN5qlQOIAbjE5jItUuhHJcX6c+kn0Euuokk6VoFbMHaMSygkYPqYSbnNzC66+ xRozPhPgKfize8nzFN/lRNx2QozI8+ny8Tn9fFrrakrM4ynnFb2qQ/ZGya67Zyx1oJlQ yXjB6Zsk7cqctxPSN36xfQNZvbDYehWVTZrep1zZxQwbGsRIspnNSQv/IfvmdrkqlLQm zwMTGtLyAkLSvJQMkiAkSgn3/QBzodlrSbaoAN0Tx74KatpqsMFW1DxwvX/z3fDeJ90Y e3fg== 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=dc0+3lIYIMJ9v8NgJ/3by6okFVvQaiLJjIhDEwB5J3Q=; b=PivLUhFEFauDsBddftjw+bzjux/cC8YdP8RC8n0XVMqcy4IqaCPvilb0oAs1S/Yg3X j2zhIGanXSrW0rJMjjrrqcHkYW4ySNcTx96KtRKBSKZ+BwaSjNcY/m0LzjrBTsa/5yWB d5oX1R99XS8ZL2dzRIOP1G5AY2QObd3Yx675m7SANZ70OaxvLsPUV72BPAsVbjMLTikb wIFmH/LDU0xbqq2mRzfQVm1ItDjCGfw8fxHj5rnFXNL9p99/4zMQnyQ7crkBgJL20mlt U8LOWlb65SxbO1vQKUVjjoYkdm9+9Xf3rCupiPu2PnBKSK1dypOROTbvoo0e6+kf0hN0 pyuw== X-Gm-Message-State: AD7BkJIM/rGbUg+90vBAomyhJhscoKxBC/xYGnVP7bP1VAm1Wux1xoLaLOy1PD7UZTG5Kw== X-Received: by 10.66.243.35 with SMTP id wv3mr33894033pac.93.1459544432158; Fri, 01 Apr 2016 14:00:32 -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 s197sm21991973pfs.62.2016.04.01.14.00.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Apr 2016 14:00:31 -0700 (PDT) From: Deepa Dinamani To: linux-fsdevel@vger.kernel.org, y2038@lists.linaro.org Cc: arnd@arndb.de, tglx@linutronix.de, viro@zeniv.linux.org.uk, elder@ieee.org Subject: [PATCH v3] vfs: Add support to document max and min inode times Date: Fri, 1 Apr 2016 13:58:06 -0700 Message-Id: <1459544286-589-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 --- Changes from v2: * Only add fields in the structure. * All other logic moved to a different patch. Changes from v1: * Delete INVALID macros, use VFS_TIME macros directly. * Add comment in alloc_super() to explain range checking. * Reword the commit text to reflect the above. 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 5cef14a..2ceed39 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