Date: Sat, 17 Aug 2002 10:30:02 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/25777: atime not updated on exec Message-ID: <200208171730.g7HHU23q031297@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/25777; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Jens Schweikhardt <schweikh@FreeBSD.org>
Cc: pdp@nl.demon.net, <freebsd-bugs@FreeBSD.org>
Subject: Re: kern/25777: atime not updated on exec
Date: Sun, 18 Aug 2002 02:59:59 +1000 (EST)
On Sat, 17 Aug 2002, Jens Schweikhardt wrote:
> State-Changed-Why:
> It is not clear if atime needs to be updated upon exec'ing a file.
Er, this is clear.
> Here's what the current IEEE Std 1003.1-2001 has to say:
>
> "File Times Update
Look in the section on exec:
9746 Upon successful completion, the exec functions shall mark for update the st_atime field of the file.
9747 If an exec function failed but was able to locate the process image file, whether the st_atime field is
9748 marked for update is unspecified. Should the exec function succeed, the process image file shall
9749 be considered to have been opened with open( ). The corresponding close( ) shall be considered
9750 to occur at a time after this open, but before process termination or successful completion of a
9751 subsequent call to one of the exec functions, posix_spawn( ), or posix_spawnp( ). The argv[ ] and
I tried to fix this many years ago, and fixed it enough to prevent
NIST PCTS (a test suite for POSIX.1-1990 + FIPS.mumble) from reporting
this bug, but dg didn't like the overheads for this and I didn't like
them either for nfs. For ufs, the atime update is done using delayed
writes, so I think it was efficient enough unless lots of _different_
files are exec'ed. I subsequently implemented lazy atime updates and
these make the problem for ufs even smaller. The updates still have to
be done sometime so accessing lots of _different_ files still causes
lots of i/o. For nfs, atime updates at least used to involve an nfs
transaction each. The nfs attribute cache may help here.
Here is part of my old patch. It depends on other patches for VOP_SETTATR()
and probably doesn't even compile now.
%%%
Index: kern_exec.c
===================================================================
RCS file: /home/ncvs/src/sys/kern/kern_exec.c,v
retrieving revision 1.180
diff -u -2 -r1.180 kern_exec.c
--- kern_exec.c 13 Aug 2002 06:55:28 -0000 1.180
+++ kern_exec.c 15 Aug 2002 14:07:51 -0000
@@ -547,4 +537,18 @@
pargs_drop(newargs);
+#if 0
+ if (!(ndp->ni_vp->v_mount->mnt_flag & MNT_NOATIME)) {
+ struct vattr vattr;
+
+ VATTR_NULL(&vattr);
+ vfs_timestamp(&vattr.va_atime);
+ vattr.va_vaflags |= VA_EXECVE_ATIME;
+ VOP_LEASE(ndp->ni_vp, p, p->p_ucred, LEASE_WRITE);
+ vn_lock(ndp->ni_vp, LK_EXCLUSIVE | LK_RETRY, p);
+ (void) VOP_SETATTR(ndp->ni_vp, &vattr, p->p_ucred, p);
+ VOP_UNLOCK(ndp->ni_vp, 0, p);
+ }
+#endif
+
exec_fail_dealloc:
%%%
The patch in the PR is not good since it assumes that all filesystems are ufs.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208171730.g7HHU23q031297>