DragonFly bugs List (threaded) for 2008-05
Re: atimes of binaries not properly updated
:The issue is that FSCRED and NOCRED are checked in the kern_prot.c
:helper functions, but the vnops functions in the various file systems
:dereference the struct ucred pointers without checking for a
:NULL(NOCRED) or 0xFFFFFFFF(FSCRED) pointers. So what is the ideal
:solution? Should the ucred API be extended in kern_prot to do the uid
:check that the file systems do (while taking into account NOCRED and
:And I thought this was such a simple patch ;)
No, I would not change the API.
There are three 'real' creds available that can be used. First, there
is the current process cred. Second, there is the cred stored with
the file pointer (struct file -> f_cred), and third there is the
cred associated with the proc0 (proc0.p_ucred).
After looking at your patch I think we actually should avoid using
SETATTR to update the atime. That is a very active and expensive VOP
and kinda messes up the critical path.
If we want to update the atime from exec*() and from mmap() we should
have access to the cred in the file pointer. What I would then do is
actually create a new VOP op and let the filesystem do whatever internal
actions it feels is reasonable to do the update. So, e.g. we would
implement a new VOP called, say, VOP_SIGNAL_ACCESS(vp, cred) (maybe you
can come up with a better name), with a default operation which is just
a NOP. UFS and HAMMER would then implement that VOP (the only two
filesystems we really care about insofar as atime goes), allowing them
to optimize the operation.
Our exec and mmap code would then call the VOP.
How does that sound for a plan?