| Message ID | 20200116120439.303034-1-omosnace@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | selinux: Assorted simplifications and cleanups | expand |
On 1/16/2020 4:04 AM, Ondrej Mosnacek wrote: > This series contains some simplifications that I discovered while > working on another patch. I believe they also save some run time > (although not in any perf-critical paths) and some memory overhead. > > The first patch is a cleanup in security_load_policy() It's a real nuisance that the security server code uses the prefix "security_". If you're making significant changes in the security server it would be really nice to clean up the namespace collision. > that avoids a > pointless allocation during initial policy load. The rest are > cleanups/simplifications of the booleans-related code - mostly > converting linked lists to arrays. > > Ondrej Mosnacek (6): > selinux: do not allocate ancillary buffer on first load > selinux: simplify security_preserve_bools() > selinux: convert cond_list to array > selinux: convert cond_av_list to array > selinux: convert cond_expr to array > selinux: generalize evaluate_cond_node() > > security/selinux/include/conditional.h | 6 +- > security/selinux/selinuxfs.c | 4 +- > security/selinux/ss/conditional.c | 252 ++++++++++--------------- > security/selinux/ss/conditional.h | 27 +-- > security/selinux/ss/policydb.c | 2 +- > security/selinux/ss/policydb.h | 3 +- > security/selinux/ss/services.c | 95 ++++------ > 7 files changed, 160 insertions(+), 229 deletions(-) >
On Thu, Jan 16, 2020 at 6:09 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 1/16/2020 4:04 AM, Ondrej Mosnacek wrote: > > This series contains some simplifications that I discovered while > > working on another patch. I believe they also save some run time > > (although not in any perf-critical paths) and some memory overhead. > > > > The first patch is a cleanup in security_load_policy() > > It's a real nuisance that the security server code uses the > prefix "security_". If you're making significant changes in > the security server it would be really nice to clean up the > namespace collision. For all the people lurking on the mailing list reading Casey's response, *please* do not do this (without discussion). That change has the potential to wreck a development cycle.
On 1/16/2020 3:59 PM, Paul Moore wrote: > On Thu, Jan 16, 2020 at 6:09 PM Casey Schaufler <casey@schaufler-ca.com> wrote: >> On 1/16/2020 4:04 AM, Ondrej Mosnacek wrote: >>> This series contains some simplifications that I discovered while >>> working on another patch. I believe they also save some run time >>> (although not in any perf-critical paths) and some memory overhead. >>> >>> The first patch is a cleanup in security_load_policy() >> It's a real nuisance that the security server code uses the >> prefix "security_". If you're making significant changes in >> the security server it would be really nice to clean up the >> namespace collision. > For all the people lurking on the mailing list reading Casey's > response, *please* do not do this (without discussion). That change > has the potential to wreck a development cycle. Of course discussion is critical, and breaking a development cycle would be a Bad Thing. I only suggested this because I'm seeing a bit of clean-up I would consider to be in the same vein. I was not advocating disruption. Carry on.
On Thu, Jan 16, 2020 at 7:49 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > On 1/16/2020 3:59 PM, Paul Moore wrote: > > On Thu, Jan 16, 2020 at 6:09 PM Casey Schaufler <casey@schaufler-ca.com> wrote: > >> On 1/16/2020 4:04 AM, Ondrej Mosnacek wrote: > >>> This series contains some simplifications that I discovered while > >>> working on another patch. I believe they also save some run time > >>> (although not in any perf-critical paths) and some memory overhead. > >>> > >>> The first patch is a cleanup in security_load_policy() > >> It's a real nuisance that the security server code uses the > >> prefix "security_". If you're making significant changes in > >> the security server it would be really nice to clean up the > >> namespace collision. > > For all the people lurking on the mailing list reading Casey's > > response, *please* do not do this (without discussion). That change > > has the potential to wreck a development cycle. > > Of course discussion is critical, and breaking a development cycle > would be a Bad Thing. I only suggested this because I'm seeing a bit > of clean-up I would consider to be in the same vein. I was not > advocating disruption. Carry on. FWIW, the cleanup you've seen lately has been mostly removing empty wrapper functions and changing how we allocate/manage things; what you are proposing is mostly a bulk rename which is quite different in my mind.