linux-kernel - Re: [PATCH] fs, pseudo: Do not update atime for pseudo inodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20200619160407.GL3183@techsingularity.net>
Date:   Fri, 19 Jun 2020 17:04:07 +0100
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] fs, pseudo: Do not update atime for pseudo inodes

On Fri, Jun 19, 2020 at 04:45:09PM +0300, Amir Goldstein wrote:
> > proxy measure is the proc fd representations of such inodes which do not
> > appear to change once they are created. This patch sets the S_NOATIME
> > on inode->i_flags for inodes created by new_inode_pseudo() so that atime
> > will not be updated.
> >
> 
> new_inode() calls new_inode_pseudo() ...
> You need to factor out a new helper.
> 

You're right, it's broken as it stands. Even though I don't think direct
users of alloc_file_pseudo use simple_getattr, it doesn't matter.

> Either you can provide callers analysis of all new_inode_pseudo() users
> or use a new helper to set S_NOATIME and call it from the relevant users
> (pipe, socket).
> 

Relevant users makes sense as it's less likely to cause surprises.

> How about S_NOCMTIME while you are at it?
> Doesn't file_update_time() show in profiling?

I can look into it, I don't recall seeing file_update_time() in the
profile but maybe it was just too small.

> Is there a valid use case for updating c/mtime of anonymous socket/pipe?
> 

Not that I can think of but that could be a failure of imagination.

-- 
Mel Gorman
SUSE Labs