On Tue, 2005-11-29 at 09:43 -0800, Tom London wrote: > On 11/29/05, Ivan Gyurdiev <ivg2@xxxxxxxxxxx> wrote: > > > > > Quite the difference, no? > > > > > Maybe this could be generalized (what's special about /dev?). > > "make install" does not need to analyze all the paths on the system > > (per file!)... > > > Hmm.... > > This sort of suggests a different file organization, no? > > How about 'overlaying' something like a trie or some search tree > organized by directory 'prefixes' (e.g., '/dev', '/lib', etc.). Should > be possible to organize the general matching cases into one bucket. IIUC, the primary overhead isn't during the matching phase; it is during initial processing of file_contexts by matchpathcon_init(), when it loads the entire file_contexts configuration into the in-memory representation and compiles all of the regexes. Most of the time is spent in regcomp(). So the only way to reduce it is to reduce the set of entries processed during matchpathcon_init(), which doesn't know what paths you are going to subsequently try matching via matchpathcon(). The expected usage model was that matchpathcon_init() would be invoked once followed by multiple matchpathcon() calls by the application, as in setfiles and restorecon (the original users). IIUC, udev is executed on each event, so it ends up performing matchpathcon_init() on every node creation and we don't get any caching of the data. We could introduce a variant interface that is optimized for the case where you are only going to perform matchpathcon() calls on paths with a common prefix (e.g. /dev), or the SELinux support in udev could be re-visited (leveraging the udevd daemon to cache the data once for all udev instances?). -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
