YAMAMOTO Takashi wrote:
>> 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.

Okay -- this is something that can be fixed. :)

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

Let's leave this for yet another thread then.

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

Agreed...

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

(yes, process 0. :)

I'm not sure. First you must understand that it's not always guaranteed
that a process will be loading these pending entries: they may be loaded
by the kernel itself, too.

The pathnames loaded are relevant to the entire system, not just a
single process: one process may load Veriexec entries for the entire
system, another may do the same for a different subsystem.

(That said, it's likely that I don't see the logic here because I
misunderstood your question; so if the above seems out of place, please
try to reword.)

-e.