From patchwork Fri Feb 12 09:35:56 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Deepa Dinamani X-Patchwork-Id: 8289541 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 C8E49BEEE5 for ; Fri, 12 Feb 2016 09:41:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id E5F9F203C1 for ; Fri, 12 Feb 2016 09:41:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 056C0203B7 for ; Fri, 12 Feb 2016 09:41:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751453AbcBLJgg (ORCPT ); Fri, 12 Feb 2016 04:36:36 -0500 Received: from mail-pa0-f42.google.com ([209.85.220.42]:33788 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751402AbcBLJgd (ORCPT ); Fri, 12 Feb 2016 04:36:33 -0500 Received: by mail-pa0-f42.google.com with SMTP id fl4so32349701pad.0; Fri, 12 Feb 2016 01:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=1X3o9wylqTEJpKQfdaV0ccw26k3pthOIowPeRKXnTkw=; b=bq30NPhojzb+3p22QxhPSeCPImFRyO2xX8b6lsptzimh/2lK1nubeOMWabKNyjJnL8 ye4zFZCeJMqz2hivB/VlfOr1ev24k8+eKnpOGeXrkQGT9ZF8pF500Rv9Iji1y243/zDl xZKKPjcKC2kQMXT9H5+NHbj1NvC7gxCphvGyg2v6KNLlMk66X4Rw2QyPykAtqfuJVzMr bgMujz3wFrRObXPWGKhkdx/DuDIiETuAnH2sghmr7wxjfQ68VfccL7TyTC58Ws+F4woG nKFtgSAhf04qEI1JyqI6Qi5uecseHNTlVhRPGYeI3hLLW1tPFQexvWe2cj5ArNKVkiP5 J6bw== 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:in-reply-to :references; bh=1X3o9wylqTEJpKQfdaV0ccw26k3pthOIowPeRKXnTkw=; b=mA/c0kzE4cs3kaAB07oUuiJ3DRgZwtyisdpLQmb53pCG3gQOZknACjh5dzzbMyLF68 HbF+cg0oz+XlJJ46yFo2Cj2qTVC/gfJrt1EqU5yk/kCc5r4lQaF9Umz9+VSXjM4xporf zAyhtR1tYPn4Bys9DxaR82CCQhzyPJ365xtKgaLcDMeMdqIellWWsUwlvsZRNzfpOwqI /dj410U+qS1gzNMKTDz6NYqbG1tifgaIcwiW8oOzlOjumN3rq55Y9jzfqoK3okMM30Bk xpBsz+tQq7cZwlb+XraYQ+WDOhzkpig8gtOqForNT7oSJjxo8f8Zezj5zviQRrYm8kzy 6NBA== X-Gm-Message-State: AG10YOS71gOUbfgdpV6542dGdoCB+p3zqEpTFspfB9ECAu1jnDI/G7CxxBILdC6i69UyFQ== X-Received: by 10.66.218.225 with SMTP id pj1mr592728pac.83.1455269792624; Fri, 12 Feb 2016 01:36:32 -0800 (PST) Received: from localhost.localdomain ([106.51.31.162]) by smtp.gmail.com with ESMTPSA id g25sm17972250pfg.35.2016.02.12.01.36.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Feb 2016 01:36:32 -0800 (PST) From: Deepa Dinamani To: linux-fsdevel@vger.kernel.org, y2038@lists.linaro.org Cc: Arnd Bergmann , Dave Chinner , "Theodore Ts'o" , linux-kernel@vger.kernel.org Subject: [RFC v2a 02/12] fs: cifs: Change cifs_fscache_inode_auxdata to use vfs_time data type Date: Fri, 12 Feb 2016 01:35:56 -0800 Message-Id: <1455269766-2994-3-git-send-email-deepa.kernel@gmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1455269766-2994-1-git-send-email-deepa.kernel@gmail.com> References: <20160212092153.GA2368@deepa-ubuntu> <1455269766-2994-1-git-send-email-deepa.kernel@gmail.com> 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, 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 The VFS inode timestamps are not y2038 safe as they use struct timespec. These will be changed to use struct timespec64 instead and that is y2038 safe. But, since the above data type conversion will break the end file systems, use vfs_time aliases here to access inode times. aux data timestamps are only used to read in inode timestamps. Hence, they need to change data type along with vfs times. struct timespec64 is the same as struct timespec on 64 bit systems. So it is a no-op on 64 bit systems. The buffer length(datalen) passed in to read in auxdata in cifs_fscache_inode_get_aux() and cifs_fscache_inode_check_aux() should be big enough for the data type change from struct timespec to struct timespec64 to be safe on 32 bit systems. Following provide support for safe usage on 32 bit systems: 1. datalen already accounts for struct timespec64 on 64 bit systems. 2. datalen passed in is a constant with sufficient space to accommodate auxdata. 3. The keylen subtracted from datalen is a constant and also leaves in sufficient space for increase. Signed-off-by: Deepa Dinamani --- fs/cifs/cache.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/cifs/cache.c b/fs/cifs/cache.c index 6c665bf..f0892ac 100644 --- a/fs/cifs/cache.c +++ b/fs/cifs/cache.c @@ -221,8 +221,8 @@ const struct fscache_cookie_def cifs_fscache_super_index_def = { * Auxiliary data attached to CIFS inode within the cache */ struct cifs_fscache_inode_auxdata { - struct timespec last_write_time; - struct timespec last_change_time; + struct vfs_time last_write_time; + struct vfs_time last_change_time; u64 eof; };