linux-kernel - Re: Wrong atime on recent kernels

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-next>] [day] [month] [year] [list]

Message-ID: <1261020388.7245.27.camel@localhost.localdomain>
Date:	Wed, 16 Dec 2009 19:26:28 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Petr Titěra <petr@...era.eu>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Wrong atime on recent kernels

On Wed, 2009-12-16 at 21:55 +0100, Petr Titěra wrote:
> john stultz napsal(a): 
> > 2009/12/14 Petr Titěra <petr@...era.eu>:
> >   
> > > Hello,
> > > 
> > >      I see some strange file modification times recently. It seems to me
> > > that in some situations, kernel allows to set nanoseconds part of  file
> > > access, modification or change time  to 100000000 ns. Problem seems to be in
> > > some generic part of kernel because I see it on several different
> > > filesysytems (ext4 and nilf2). These is I've got during my testing on kernel
> > >  2.6.32-tip-08309-gad8e75a.
> > > 
> > >  File: `./Documentation/dvb/contributors.txt'
> > >  Size: 3035            Blocks: 8          IO Block: 4096   regular file
> > > Device: fe04h/65028d    Inode: 818         Links: 1
> > > Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
> > > Access: 2009-12-14 10:29:04.1000000000 +0100
> > > Modify: 2009-12-14 10:29:04.1000000000 +0100
> > > Change: 2009-12-14 10:29:04.1000000000 +0100
> > > 
> > > See that all times of that file ends with 1e6 nanoseconds.
>
>     I did not test reverting this patch yet, because I did not find
> reliable way how to reproduce these strange modify times. But as I
> read your description. Would it be possible that if there would be bug
> in your patch i would be observer on mostly quiet system? I'm asking
> because full day of testing of the system under load did not produce
> any result, but then when I tried to run "find / | xargs stat" on idle
> system I've got several new instances of wrong access time (filesystem
> is mounted without noatime)

Another quick question:

What is the normal behavior you see when this issue is not cropping up?

Do you normally see all 0's in the ns field? Or do you expect to see an
actual ns value?

I'm asking as all the filesystems I've played with have all zeros, so
I'm not sure if I need to try a different filesystem (I tried ext4, but
it was with a disk that was originally ext3), or if the issue is just
the stray 1sec value in the ns field. 

thanks
-john


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/