> YAMAMOTO Takashi wrote:
> 
> > your patch doesn't seem to remove the window.
> 
> Are you referring to the lack of locking on the mount itself, in a way
> that allows performing operations on the mount-point right after it was
> mounted and before the traversal on the pending list was done?

yes.

> > i think fileassoc has scalability problems, and this 'pending' thing
> > will make it worse.
>  >
> > how about making fileassoc (or veriexec, or whatever) issue upcalls
> > to userland daemon?  ie. keep databases in userland and consider
> > in-kernel entries as cache.
> 
> First, I'd like to point out that (ideally) this list of pending entries
> will exist about a minute: right after the kernel is alive, and right
> before file-systems are mounted.
> 
> Before I address the second paragraph about userland dameon upcalls, I
> have to know if you're referring to this addition specifically (the
> pending pathnames list), or the entire subsystem(s). If the former, see
> above; if the latter -- I'm afraid that (at least for now) that's out of
> the question.

the latter.

> > for long term i'd like to make filesystem namespace per-process.
> > so, in general, i don't like the idea to keep pathnames in kernel without
> > associating them to a process.
> 
> Nothing is set in stone, introducing functionality now only means we'll
> have to adapt it to a new reality in the future. While I am interested
> in this, I'd like to hear about it in a different thread. :)
> 
> -e.

it isn't always possible to adapt it later in a natural way.
it's better to shake out possible problems when designing api as far as
possible, rather than later.

for your purpose, is it appropriate to associate pathnames to
a namespace of a process which loaded entries?

YAMAMOTO Takashi