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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190222150020.GA14465@laptop.jcline.org>
Date:   Fri, 22 Feb 2019 10:00:20 -0500
From:   Jeremy Cline <jcline@...hat.com>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     David Both <dboth@...lennium-technology.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] proc: update i_atime when reading files

On Fri, Feb 22, 2019 at 08:37:42AM +0300, Alexey Dobriyan wrote:
> On Thu, Feb 21, 2019 at 11:37:14AM -0500, Jeremy Cline wrote:
> > Prior to commit 1da4d377f943 ("proc: revalidate misc dentries"), the
> > access, modify, and change times of files in /proc were just the current
> > time.
> 
> Ehh, actually no. Doing
> 
> 	$(which sleep) infinity </proc/foo &
> 
> will sabotage atime updates because dentry and inode will be pinned in
> caches.
> 
> "revalidate misc denries" commit simply makes the effect (much) more
> visible by making objects stay in caches for longer.

Indeed. It wasn't my intention to imply there's anything wrong with that
commit, just that that's what caused this apparent change in behavior
for users. In the "common" case when something hasn't pinned the dentry
and inode what users saw was the current time.

> 
> > Now the mtime and ctime values change mostly as a user would
> > expect, but the atime isn't updated when the file read. This patch
> > updates the access time of /proc files when they are read.
> 
> >  			rv = read(file, buf, count, ppos);
> > +			if (rv >= 0)
> > +				inode->i_atime = current_time(inode);
> > +		}
> 
> Maybe it should be done given /proc is virtual so there are no concerns
> about scheduling writes noone cares about to the filesystem.

Sorry, maybe I've not had enough coffee yet, but I don't understand this
sentence.

Thanks,
Jeremy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ