On Tue, Jun 2, 2020 at 4:42 PM Siarhei Liakh <siarhei.liakh@xxxxxxxxxxxxxxxxx> wrote: > The 05/13/2020 17:55, Paul Moore wrote: > > On Wed, Apr 29, 2020 at 4:29 PM <siarhei.liakh@xxxxxxxxxxxxxxxxx> wrote: > > > > > > From: Siarhei Liakh <siarhei.liakh@xxxxxxxxxxxxxxxxx> > > > > > > This change introduces a median() function which is then used to report > > > 25th, 50th, and 75th percentile metrics within distributions of hash table > > > bucket chain lengths. This allows to better assess and compare relative > > > effectiveness of different hash functions. Specifically, it allows to > > > ensure new functions not only reduce the maximum, but also improve (or, at > > > least, have no negative impact) on the median. > [ . . . ] > > > diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig > > > index 9e921fc72538..57c427e019c9 100644 > > > --- a/security/selinux/Kconfig > > > +++ b/security/selinux/Kconfig > > > @@ -115,3 +115,13 @@ config SECURITY_SELINUX_SID2STR_CACHE_SIZE > > > conversion. Setting this option to 0 disables the cache completely. > > > > > > If unsure, keep the default value. > > > + > > > +config SECURITY_SELINUX_DEBUG_HASHES > > > + bool "Print additional information about hash tables" > > > + depends on SECURITY_SELINUX > > > + default n > > > + help > > > + This option allows to gather and display additional information about > > > + some of the key hash tables within SELinux. > > > + > > > + If unsure, keep the default value. > > > > I forgot to mention this earlier, but I think this is another case > > where we don't need to add another Kconfig option. > > Right. What is your preferred way to control conditional inclusion of > code spread out across several files? Sorry for the delay. Instead of talking about the mechanics of how to make the code conditional, I would first like to have a discussion about if the code should even be conditional, and if it is unconditional, do we need it? More on this below. > My issue is that there already are two different symbols which require > coordination to activate this functionality: DEBUG_HASHES defined and used > locally within policydb.c and simple DEBUG which is needed for pr_debug() > statements throughout the code. My general thinking is that if the information is useful to a user to manage and tune their system then we should include the code. If the information is only useful to kernel developers to play with different designs or implementation then we can, and should, leave that code out. Developers are likely going to need to add their own instrumentation anyway for testing, no sense in us cluttering up the kernel for something that may never be useful to anyone. > Personally, I prefer something global and controlled from a single well-known > place, hence the Kconfig. However, I also see your point about reducing > Kconfig... But if not Kconfig, then what? Should I just create an additional > .h file with all SELinux-specific debug symbols and have it included > everywhere in SELinux? > > How would you approach this? I *think* the answers above should help, but if not let me know :) -- paul moore www.paul-moore.com
