Subject: Re: eliminating veriexec #ifdefs in vfs_vnops.c
To: YAMAMOTO Takashi <email@example.com>
From: Elad Efrat <elad@NetBSD.org>
Date: 12/29/2006 19:30:10
YAMAMOTO Takashi wrote:
>> 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.
> - 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?