----- Original Message ----- From: Chris Wright <chrisat_private> To: Mike Wray <mike_wrayat_private> Cc: Chris Wright <chrisat_private>; <linux-security-moduleat_private> Sent: 08 October 2002 09:29 Subject: Re: graft_tree/attach_mnt rfc > * Mike Wray (mike_wrayat_private) wrote: > > > > BTW, in Serge and Chris's patches moving the sb_post_addmount hook > > > > from the end of graft_tree() into attach_mount() means that it > > > > would be called with the dcache_lock held - whereas before > > > > it wasn't. > > > > > > Yes, this is a known side effect. > > > > > > > This is a problem for us because our present code for handling a mount > > involves looking up filenames, which will be bad if the dcache_lock is held... > > Was Serge's recommendation sufficient? > Unfortunately no, because we have a user-space daemon doing a lot of the work - which it can't do if kernel locks are held. If the kernel locks really _have_ to be held the only way out I can see at the moment is to set a flag in the kernel that our tables need to be rebuilt and do them next time we get called from context not holding the locks (if that's possible). > > > > It also means that sb_post_addmount() might be called > > > > multiple times on one mount (via copy_tree()). > > > > > > This is rather intentional so that recursive bind mounts and > > > copy_namespace operations get the full picture. > > > > OK, but it means that we don't have a clear idea when a mount is finished - > > because we can't tell which of the sb_post_addmount() calls is the last. > > We'd like a hook that is called when the mount is done - so we can do all our > > work once. > > Is this a preference or a true need? I'd say it's a need. Current when a mount happens we rebuild our file tables. This is moderately expensive, so we'd rather do it once rather than many times. Mike _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue Oct 08 2002 - 08:42:37 PDT