Re: [Dazuko-devel] __d_path export and SMP safeness

[John Ogness]

Tushar wrote:
>> Yes. Increased number of context switches is a problem, but as I see it,
>> building a custom kernel is an even bigger problem. Customers are not happy
>> with that.
> 
> Why there is multiple context switches?  I will like to know more about
> it.

If Dazuko returned a local path, the application would need to build the
full path using the /proc system (/proc/PID/root). Retrieving this data from
the /proc filesytem involves an extra context switch. At the moment, using
Dazuko requires an extra switch (to userspace and back to kernelspace) for
each file event. For chroot'd processes, this would require 2 extra context
switches than without Dazuko.

This is certainly very fast (and negligible in comparison to what a virus
scanner does with the even), but I felt it was worth mentioning.


> As /proc is dynamically generated, it would be great if somehow we can
> manage to get the root entry in kernel space itself and return final
> path to user. This way, we can keep semantics of filename field same for
> all process. Please let me know what u people think about this.

This sounds like a good idea, but I don't know how easy it would be (or if
it is even possible). The 2.6 kernel uses a lot of "internal" locks on its
structures that are not available to kernel modules (statically defined and
available only for non-exported functions). This is why we require a kernel
patch for __d_path() on SMP systems. I haven't looked at the code yet, but I
suspect that a kernel module does not have access to the required locks
needed to get this information.

For Linux 2.6, loadable kernel modules are not nearly as trusted as built-in
modules.

John Ogness

-- 
Dazuko Maintainer