On Thu, Aug 20, 2020 at 9:17 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On Thu, Aug 20, 2020 at 8:10 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > Unfortunately I need to re-base it again and manually fix conflicts > > with my patch to avoid deferencing the policy prior to initialization. > > And I'll need to do it again when/if the patch to convert the policy > > rwlock to rcu lands. So you might want to wait. I'm starting to > > wonder if the first patch in the series to rename selinux_state/state > > to selinux_ns/ns throughout is a mistake because it produces a lot of > > unnecessary conflicts. Originally I did it because that was the > > original naming since the encapsulation started to support namespacing > > and then I did a mass rename to selinux_state/state for upstreaming > > since I wasn't yet upstreaming the actual namespace support. Renaming > > it back again reduces conflicts in the later patches but makes the > > first one a pain. But if I just do a mass rename on all the later > > patches then I can drop the first one and avoid these unnecessary > > conflicts. Thoughts? > > I agree, the first patch is the one that always causes me the most > pain; considering the work-in-progress state of the patches I think it > would make the most sense to drop that initial cosmetic patch for now > and we can always reinstate it at the end when this work finally > lands. I've made a pass at this and force-pushed it to my working-selinuxns-rebase branch. It turned out that the first patch did two things: it renamed state to ns and it changed all direct references to &selinux_state to use a new current_selinux_state pointer to a static init_selinux_state variable (in preparation for multiple states/namespaces). I had to retain the latter so I just dropped the renaming part of it, rewrote the description, and did a mass rename in all the subsequent patches back to state. So the first patch may still produce some conflicts but there should be fewer of them. This is relative to your current next branch but it will need to be manually re-based again when/if the policy rcu patches land, so feel free to wait if you want. Since every patch required modification and many of them required manual fixups, I dropped all of your Signed-off-by lines and rewrote all of mine with my current preferred email address.
