Subject: Re: eliminating veriexec #ifdefs in vfs_vnops.c
To: YAMAMOTO Takashi <>
From: Elad Efrat <>
List: tech-kern
Date: 12/29/2006 19:30:10
YAMAMOTO Takashi wrote:
>> hi,
>> attached diff does, well, what the subject line says.
>> it works here, but I'd like some more eyes on it (locking issues? I
>> dunno), so please review.
>> if no one objects, I'll just go ahead and commit it.
>> -e.
> - it introduces more overhead for non veriexec users...

of course. eventually, if the measured overhead is critical, we can
always turn off veriexec by default.

> - it seems quite racy.  i don't know if it's a problem for veriexec, tho.
>   first and second namei() can see different
>   pathnames (if userland pathname buffer is modified) and/or
>   vnode (if any components in the pathname is renamed).

that's what I was worried about: we do two consequtive namei() calls.

do you think there's a way we could have a single namei() in vn_open()
to avoid it? or maybe we can copy the pathname to the kernel in
vn_open(), and then in consequent namei() calls just use that. because
veriexec doesn't care about permissions but relies on internal tables
it shouldn't matter, I *think*.

does any of the above make sense?