svn commit: r194586 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs kern sys

[Bruce Evans]

On Mon, 22 Jun 2009, Kostik Belousov wrote:

> On Mon, Jun 22, 2009 at 02:12:57PM +1000, Bruce Evans wrote:
>> On Sun, 21 Jun 2009, Konstantin Belousov wrote:
>>
>>> Log:
>>> Add another flags argument to vn_open_cred. Use it to specify that some
>>> vn_open_cred invocations shall not audit namei path.
>>
>>> Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c
>>> ==============================================================================
>>> --- head/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c	Sun Jun 21
>>> 13:15:56 2009	(r194585)
>>> +++ head/sys/cddl/compat/opensolaris/kern/opensolaris_kobj.c	Sun Jun 21
>>> 13:41:32 2009	(r194586)
>>> @@ -85,7 +85,8 @@ kobj_open_file_vnode(const char *file)
>>>
>>> 	flags = FREAD;
>>> 	NDINIT(&nd, LOOKUP, MPSAFE, UIO_SYSSPACE, file, td);
>>> -	error = vn_open_cred(&nd, &flags, O_NOFOLLOW, curthread->td_ucred,
>>> NULL);
>>> +	error = vn_open_cred(&nd, &flags, O_NOFOLLOW, 0, curthread->td_ucred,
>>> +	    NULL);
>>
>> I was going to ask "why not put the flag in the existing flags arg,
>> like O_NOFOLLOW here?", but it seems that there is no existing flags
>> arg and the above O_NOFOLLOW is garbage.  O_NOFOLLOW happens to be
>> 0x100, so I think the above asks for mode S_IRUSR.
> I fixed this, O_NOFOLLOW is set in flags.
>
>>
>> Now I will ask "why not put O_NOFOLLOW here and the new flag in the
>> existing pointer-to-flags arg?".
> I do not quite understand what is named by "here". O_NOFOLLOW is defined
> as a user-supplied flag for the mode argument of the open(2), that
> determines that it must go in the flags.

"here" is above.

> I do not want to put kernel-only flags into the mode argument, at least
> because it shrinks the space available for further additions of the open(2)
> mode flags, that is periodically done by the standards freebsd tries to
> follow.

Not a problem, since the kernel flags can easily be moved later if
necessary.  Just don't repeat the mistake for F_HASLOCK, of putting
them in the middle of user flags.

Bruce