YAMAMOTO Takashi wrote:
>> YAMAMOTO Takashi wrote:
>>>> +	error = pathname_get(ndp->ni_dirp, ndp->ni_segflg, &pn);
>>>> +	if (error)
>>>> +		goto bad2;
>>>> +	ndp->ni_dirp = pathname_path(pn);
>>>> +	ndp->ni_segflg = UIO_SYSSPACE;
>>> this ought to be wrapped by #ifdef, IMO.
>>>
>>> YAMAMOTO Takashi
>> why?
>>
>> -e.
> 
> because two allocations and strcpy up to 1k bytes are costly enough.
> 
> YAMAMOTO Takashi

I believe this is part of your "veriexec is slow campaign".

so, for that matter, the pathname_get() routine will, in case the buffer
is in userspace, copy it in (which would happen anyway in namei()). if
it isn't, it will "reuse" it (no strcpy). the UIO_SYSSPACE will tell
namei() to not try and copy it from userspace, resulting in a copystr()
that would happen *anyway* even if the buffer was just passed from
the kernel itself.

so the only additional cost here is the allocation of a pathname_t
object, which contains a pointer and a boolean. given the fact that
the real overhead in vn_open() is the copying of the pathname from
userspace and, well, namei() itself, this is not going to show any
performance impact. definitely not a noticeable one.

of course, if those ~3ms are that meaningful to you, which I doubt,
we can always just open-code pathname_get() in vn_open(), giving the
*exact* same performance you would otherwise get. however, I think
you will have to agree with me that for any use, this pathname_t
allocation is not going to present a noticeable performance impact,
especially not given all the other stuff happening in vn_open().

-e.