| 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
| ||
|
Message-ID: <4B2A1051.9010808@century.cz> Date: Thu, 17 Dec 2009 12:04:49 +0100 From: Petr Titěra <P.Titera@...tury.cz> To: john stultz <johnstul@...ibm.com> CC: Petr Titěra <petr@...era.eu>, linux-kernel@...r.kernel.org Subject: Re: Wrong atime on recent kernels john stultz napsal(a): > 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? > > Sorry to reply again. Previous message did not get to list: I see values which seems to be ns times there. My root filesystem is ext4 too (recently I do not remeber if I formated it from scratch when I reinstalled that system) but I see this happen on other filesystems too Root filesystem (ext4 may be converted from ext3) File: `/etc/sysconfig' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fe00h/65024d Inode: 65282 Links: 7 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-12-16 21:14:00.172000000 +0100 Modify: 2009-12-12 11:01:48.1000000000 +0100 Change: 2009-12-12 11:01:48.1000000000 +0100 File: `/etc/sysconfig/prelink' Size: 1459 Blocks: 8 IO Block: 4096 regular file Device: fe00h/65024d Inode: 22706 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-12-14 10:27:46.912000002 +0100 Modify: 2004-11-23 11:43:08.000000000 +0100 Change: 2009-12-08 22:57:24.656000002 +0100 File: `/etc/sysconfig/i18n' Size: 47 Blocks: 8 IO Block: 4096 regular file Device: fe00h/65024d Inode: 48962 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2010-08-27 18:07:21.500013018 +0200 Modify: 2009-06-22 23:33:43.113581313 +0200 Change: 2009-06-22 23:58:39.936318201 +0200 /home (nilfs2) File: `/home/linux-2.6/include/linux/netfilter_ipv4/ipt_tos.h' Size: 184 Blocks: 8 IO Block: 4096 regular file Device: fe04h/65028d Inode: 20141 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-12-15 18:59:33.1000000000 +0100 Modify: 2009-12-15 18:59:33.1000000000 +0100 Change: 2009-12-15 18:59:33.1000000000 +0100 File: `/home/linux-2.6/include/linux/netfilter_ipv4/ipt_ttl.h' Size: 350 Blocks: 8 IO Block: 4096 regular file Device: fe04h/65028d Inode: 20547 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-12-15 00:23:58.135760901 +0100 Modify: 2009-12-15 00:23:58.135760901 +0100 Change: 2009-12-15 00:23:58.135760901 +0100 /sources (btrfs) File: `/sources/linux-2.6/.git/objects/pack/pack-9aea3a0847debb83ad688214f648799fc46af3d3.pack' Size: 6255096 Blocks: 12224 IO Block: 4096 regular file Device: 13h/19d Inode: 2129247 Links: 1 Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-12-16 21:16:09.424000000 +0100 Modify: 2009-12-16 21:17:20.1000000000 +0100 Change: 2009-12-16 21:17:21.564000000 +0100 File: `/sources/linux-2.6/.git/objects/pack/pack-9aea3a0847debb83ad688214f648799fc46af3d3.idx' Size: 159552 Blocks: 312 IO Block: 4096 regular file Device: 13h/19d Inode: 2129248 Links: 1 Access: (0444/-r--r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-12-16 21:17:21.296000000 +0100 Modify: 2009-12-16 21:17:21.324000001 +0100 Change: 2009-12-16 21:17:21.592000001 +0100 Now when I'm looking through stat /stats.file I was able to find some really old instances of this error from October: File: `/mnt/data/linux-2.6/.git/refs/remotes/origin' Size: 4096 Blocks: 8 IO Block: 4096 directory Device: fe00h/65024d Inode: 130953 Links: 2 Access: (0775/drwxrwxr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-12-16 21:21:52.776000002 +0100 Modify: 2009-10-14 07:57:03.1000000000 +0200 Change: 2009-10-14 07:57:03.1000000000 +0200 File: `/mnt/data/linux-2.6/.git/refs/remotes/origin/master' Size: 41 Blocks: 8 IO Block: 4096 regular file Device: fe00h/65024d Inode: 147522 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2009-10-14 07:57:04.040000000 +0200 Modify: 2009-10-14 07:57:03.970000000 +0200 Change: 2009-10-14 07:57:03.1000000000 +0200 So this happened before but only recently it started to happen in places where it hurts. I found this trange behaviour because I was unable to create initramfs of new kernels. mkinitrd command could not copy files and preserve their times because of timestamp validity check in cp. I will try to revert commit you told me and will test. Petr > 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 > > > > > __________ Informace od ESET Smart Security, verze databaze 4694 (20091216) __________ > > Tuto zpravu proveril ESET Smart Security. > > http://www.eset.cz > > > __________ Informace od ESET Smart Security, verze databaze 4694 (20091216) __________ Tuto zpravu proveril ESET Smart Security. http://www.eset.cz -- 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/
Powered by blists - more mailing lists