On Wed, May 21, 2008 at 4:03 PM, Dionysus Blazakis <[EMAIL PROTECTED]> wrote: > On Tue, May 20, 2008 at 3:53 PM, Dionysus Blazakis > <[EMAIL PROTECTED]> wrote: >> On Mon, May 19, 2008 at 2:26 PM, Simon 'corecode' Schubert >> <[EMAIL PROTECTED]> wrote: >>> Hey, >>> >>> something is wrong with our atimes update: >>> >>> % stat -x `which mplayer` >>> File: "/usr/pkg/bin/mplayer" >>> Size: 21084730 FileType: Regular File >>> Mode: (0555/-r-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ wheel) >>> Device: 91,3 Inode: 579162 Links: 1 >>> Access: Fri May 2 01:00:44 2008 >>> Modify: Wed Apr 30 00:16:03 2008 >>> Change: Wed Apr 30 00:16:03 2008 >>> >>> But I'm sure I watched MacGyver yesterday night, with mplayer. Maybe it was >>> in the buffer cache since May 2nd and thus was not updated? Actually >>> running mplayer right now (after reboot) does not update the atime either. >> >> I took a look and it seems like bumping atime on a execve or mmap was >> never done. The other BSDs and Linux _do_. I took a shot at a patch. >> It is based on FBSD. >> >> The patch against HEAD is at: >> http://dblaz.beevomit.org/dfly/atime.patch > > Based on some discussion in IRC, I added a check in case vn_mark_atime > was called without a process context. For now, it will use NOCRED in > this case (equivalent to NULL). > > I also added the note to the man page. > > Updated patch: > http://dblaz.beevomit.org/dfly/atime-2.patch > > -- Dion > >> >> I wasn't sure if the atime update in mmap should happen further below >> or not. Also, not sure if I had to mess with vnode locking in >> kern_exec -- please let me know. >> >> -- Dion >> >> Ah, and I just thought that maybe our stat(2) man page should be >> updated to add execve and mmap in the atime blurb. >> >>> >>> cheers >>> simon >>> >>> -- >>> Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\ >>> Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / >>> Party Enjoy Relax | http://dragonflybsd.org Against HTML \ >>> Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ >>> >>> >> >
Hrm. Nevermind. The ucred's passed to the fs vnops are dereferenced without check.
