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

it's sad to hear that you are considering my attempts to improve it
as a negative 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.

in the case of UIO_USERSPACE, currently namei() does copyinstr().
ie. one copy.
with your change, pathname_get() does copyinstr, and then namei() does
copystr().  ie. two copies.
don't you consider it as an additional cost at all?

> 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.

i don't see how open-coding solve it.
isn't it what we have currently with #ifdef?

YAMAMOTO Takashi