Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp326641imi; Thu, 21 Jul 2022 01:22:56 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sBv3kU7mu6Unck+u+p8mLVqTuqi28C4ewiRncOg9GjbBAU5YLyhSOjoZY6P9ZpL8aW1kOa X-Received: by 2002:a17:907:1c97:b0:6f5:22ae:7024 with SMTP id nb23-20020a1709071c9700b006f522ae7024mr37345384ejc.570.1658391775779; Thu, 21 Jul 2022 01:22:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658391775; cv=none; d=google.com; s=arc-20160816; b=ToFdgrcw8mYRBKcchkyOqwN+V2dxJWQkvDAjuND5CEeOXiqd6qIKK5rx6x1nrH+Dhl RBXqu9psUtPqiMTwYXdsbchsgEeMfbufeHnQOAFNJ6o1ZaReps/hJGnP2MwDx9lWB0gZ NC9pYxrHUPS+4ZmGyMMDGqpEF1moqcaO2hQqLhBwp4LTaDQI/h7cBiV8J1WahtlUdFTQ bqy1PwE923bOU7NYTMxuC+dxuA35P4zUMJdsNF+kgqZywpoahrwHV9KFgzNw8s0iBwTp CE4UKB70S8xmJoAmuSQ2X+fBrerGbXlyrk44WvLB79WrOpmvIFn2gIv1koMEJMZbp8xn QxwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=vcjP/TTiCJtollpq0IPhYOJ7clDYhyVICdNwHyD3LrE=; b=AO8QsCGi3dQm6I73sQG9LquPk+LzP0adn239maTmy6nERo66HILpRg+82vn6QcYsu6 U5emPmccwRoEtBB3lWQdrncDrrrSHGs6gy/WcuuvKT+fJ6SCgvirukjkLLJMbyzTpE+r 8sj/ZiFgmbF5HgxJTTOt5gIGqwCfzXIQdsle7x2TXc0AFlUNbF2+eD5gWz9QJJjgLvxe /uz5y15zCJErgqkxtsEZ5uRdTir0d3tA3XKjQQymmt+eaJn+HqDdxGQ6Lz0mVes0y1c5 F0H/tMGzeMDLJhJPjoFLY4hdHl7sUlWT7k5N6sXymooVQosLIVVYNoQRDbf2voioJuLX IClw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=zSgKsABZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y16-20020a056402441000b0043bbb93fd28si1937662eda.102.2022.07.21.01.22.31; Thu, 21 Jul 2022 01:22:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=zSgKsABZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230092AbiGUIQh (ORCPT + 99 others); Thu, 21 Jul 2022 04:16:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232073AbiGUIQ1 (ORCPT ); Thu, 21 Jul 2022 04:16:27 -0400 Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8F9D07D1F8 for ; Thu, 21 Jul 2022 01:16:26 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id f11so1133412plr.4 for ; Thu, 21 Jul 2022 01:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vcjP/TTiCJtollpq0IPhYOJ7clDYhyVICdNwHyD3LrE=; b=zSgKsABZNHCGDGlRauoWxpAH/o/0gRVuIgQ9ktno6Af3XPNaeY7ZIkQbIP1dODyyW6 SyK/9cq3DiYyhrwSAOBIgFy9YhGgH3oPglY56gT28qdvQij5J8IbvF1G3UAurRqRaLY8 VlNnceYzSRQ59u17FNBweM260mhdf51ls1OGj1DTrVpwjr2ukZ/l+p1ccJvzkhaULMDC VOSTkOS1+lFNpaMcgUJHwvvZ5HSZckSRvTuQrpsQL/Xig2HvGDgJeOkGGVwf8/ezcr07 YEdk1nTyI82qUMYsFB3Rxl6jpyYHSc3z0T6MfwpB33NJWKdp90G2ueFhHfAEMcyEitg8 FkJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=vcjP/TTiCJtollpq0IPhYOJ7clDYhyVICdNwHyD3LrE=; b=XvOYItSNvXRfLRjkHDP2I62jQCC1/JZ+UUKxMibTIBX8YWx6dhzAKu8CqHxXhhjZmv HqaJTfF0DxJwRBgVivYBVjH8GDYJNS7Jkn7oNyjmPPBDQ1f0o6sdx7lstHcIWBsm49J2 ZOvqbInLrYBdE5s5Ir27oUoLe+yuoVA2iYrRK+fydEWAf8cpUooiidkUtvMZK9fOHEIe Wk9HIcilu3LezAtCpV9ZGmK9rigOklRc2jjYYmIxTJNk60raQMSfFGd3TVp3kqgET/VM qDuQFhHfKDAapsnI1gbaoX3E6ut9e9ZGOwnW5ASDG8QvfmliuUzLwTL+JhOWTxUK76ya UJyQ== X-Gm-Message-State: AJIora+tPHWuH0VPLCnp+ACrH/bRWA0uecrZOHDuaqmkMT1Dt1UAaHlk 2NAeJgDGi4sA1wrt2FgvZfS1/Q== X-Received: by 2002:a17:90a:9409:b0:1f0:e171:f2bd with SMTP id r9-20020a17090a940900b001f0e171f2bdmr9758963pjo.245.1658391386081; Thu, 21 Jul 2022 01:16:26 -0700 (PDT) Received: from C02GF2LXMD6R.bytedance.net ([139.177.225.246]) by smtp.gmail.com with ESMTPSA id j2-20020a17090a694200b001f204399045sm837995pjm.17.2022.07.21.01.16.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 01:16:25 -0700 (PDT) From: Zhang Yuchen To: mcgrof@kernel.org, keescook@chromium.org, yzaikin@google.com, songmuchun@bytedance.com Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, Zhang Yuchen Subject: [RFC] proc: fix create timestamp of files in proc Date: Thu, 21 Jul 2022 16:16:17 +0800 Message-Id: <20220721081617.36103-1-zhangyuchen.lcr@bytedance.com> X-Mailer: git-send-email 2.32.1 (Apple Git-133) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A user has reported a problem that the /proc/{pid} directory creation timestamp is incorrect. He believes that the directory was created when the process was started, so the timestamp of the directory creation should also be when the process was created. The file timestamp in procfs is the timestamp when the inode was created. If the inode of a file in procfs is reclaimed, the inode will be recreated when it is opened again, and the timestamp will be changed to the time when it was recreated. In other file systems, this timestamp is typically recorded in the file system and assigned to the inode when the inode is created. This mechanism can be confusing to users who are not familiar with it. For users who know this mechanism, they will choose not to trust this time. So the timestamp now has no meaning other than to confuse the user. It needs fixing. There are three solutions. We don't have to make the timestamp meaningful, as long as the user doesn't trust the timestamp. 1. Add to the kernel documentation that the timestamp in PROC is not reliable and do not use this timestamp. The problem with this solution is that most users don't read the kernel documentation and it can still be misleading. 2. Fix it, change the timestamp of /proc/pid to the timestamp of process creation. This raises new questions. a. Users don't know which kernel version is correct. b. This problem exists not only in the pid directory, but also in other directories under procfs. It would take a lot of extra work to fix them all. There are also easier ways for users to get the creation time information better than this. c. We need to describe the specific meaning of each file under proc in the kernel documentation for the creation time. Because the creation time of various directories has different meanings. For example, PID directory is the process creation time, FD directory is the FD creation time and so on. d. Some files have no associated entity, such as iomem. Unable to give a meaningful time. 3. Instead of fixing it, set the timestamp in all procfs to 0. Users will see it as an error and will not use it. I think 3 is better. Any other suggestions? Signed-off-by: Zhang Yuchen --- fs/proc/base.c | 4 +++- fs/proc/inode.c | 3 ++- fs/proc/proc_sysctl.c | 3 ++- fs/proc/self.c | 3 ++- fs/proc/thread_self.c | 3 ++- 5 files changed, 11 insertions(+), 5 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 0b72a6d8aac3..af440ef13091 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -1892,6 +1892,8 @@ struct inode *proc_pid_make_inode(struct super_block *sb, struct proc_inode *ei; struct pid *pid; + struct timespec64 ts_zero = {0, 0}; + /* We need a new inode */ inode = new_inode(sb); @@ -1902,7 +1904,7 @@ struct inode *proc_pid_make_inode(struct super_block *sb, ei = PROC_I(inode); inode->i_mode = mode; inode->i_ino = get_next_ino(); - inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); + inode->i_mtime = inode->i_atime = inode->i_ctime = ts_zero; inode->i_op = &proc_def_inode_operations; /* diff --git a/fs/proc/inode.c b/fs/proc/inode.c index fd40d60169b5..efb1c935fa8d 100644 --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -642,6 +642,7 @@ const struct inode_operations proc_link_inode_operations = { struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de) { struct inode *inode = new_inode(sb); + struct timespec64 ts_zero = {0, 0}; if (!inode) { pde_put(de); @@ -650,7 +651,7 @@ struct inode *proc_get_inode(struct super_block *sb, struct proc_dir_entry *de) inode->i_private = de->data; inode->i_ino = de->low_ino; - inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); + inode->i_mtime = inode->i_atime = inode->i_ctime = ts_zero; PROC_I(inode)->pde = de; if (is_empty_pde(de)) { make_empty_dir_inode(inode); diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c index 021e83fe831f..c670f9d3b871 100644 --- a/fs/proc/proc_sysctl.c +++ b/fs/proc/proc_sysctl.c @@ -455,6 +455,7 @@ static struct inode *proc_sys_make_inode(struct super_block *sb, struct ctl_table_root *root = head->root; struct inode *inode; struct proc_inode *ei; + struct timespec64 ts_zero = {0, 0}; inode = new_inode(sb); if (!inode) @@ -476,7 +477,7 @@ static struct inode *proc_sys_make_inode(struct super_block *sb, head->count++; spin_unlock(&sysctl_lock); - inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); + inode->i_mtime = inode->i_atime = inode->i_ctime = ts_zero; inode->i_mode = table->mode; if (!S_ISDIR(table->mode)) { inode->i_mode |= S_IFREG; diff --git a/fs/proc/self.c b/fs/proc/self.c index 72cd69bcaf4a..b9e572fdc27c 100644 --- a/fs/proc/self.c +++ b/fs/proc/self.c @@ -44,9 +44,10 @@ int proc_setup_self(struct super_block *s) self = d_alloc_name(s->s_root, "self"); if (self) { struct inode *inode = new_inode(s); + struct timespec64 ts_zero = {0, 0}; if (inode) { inode->i_ino = self_inum; - inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); + inode->i_mtime = inode->i_atime = inode->i_ctime = ts_zero; inode->i_mode = S_IFLNK | S_IRWXUGO; inode->i_uid = GLOBAL_ROOT_UID; inode->i_gid = GLOBAL_ROOT_GID; diff --git a/fs/proc/thread_self.c b/fs/proc/thread_self.c index a553273fbd41..964966387da2 100644 --- a/fs/proc/thread_self.c +++ b/fs/proc/thread_self.c @@ -44,9 +44,10 @@ int proc_setup_thread_self(struct super_block *s) thread_self = d_alloc_name(s->s_root, "thread-self"); if (thread_self) { struct inode *inode = new_inode(s); + struct timespec64 ts_zero = {0, 0}; if (inode) { inode->i_ino = thread_self_inum; - inode->i_mtime = inode->i_atime = inode->i_ctime = current_time(inode); + inode->i_mtime = inode->i_atime = inode->i_ctime = ts_zero; inode->i_mode = S_IFLNK | S_IRWXUGO; inode->i_uid = GLOBAL_ROOT_UID; inode->i_gid = GLOBAL_ROOT_GID; -- 2.30.2