On Fri, Aug 21, 2020 at 5:00 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > 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. Re-based again on latest next and it was much easier this time around. Will need to do it again once Ondrej's patches and my policy_mutex patch land but hopefully not too much work.
