On Mon, Aug 24, 2020 at 5:29 PM Lakshmi Ramasubramanian <nramas@xxxxxxxxxxxxxxxxxxx> wrote: > On 8/24/20 1:01 PM, Ondrej Mosnacek wrote: > > On Mon, Aug 24, 2020 at 9:30 PM Stephen Smalley > > <stephen.smalley.work@xxxxxxxxx> wrote: > >> On Mon, Aug 24, 2020 at 2:13 PM Lakshmi Ramasubramanian > >> <nramas@xxxxxxxxxxxxxxxxxxx> wrote: > >>> On 8/24/20 7:00 AM, Stephen Smalley wrote: ... > >>> Is Ondrej's re-try approach I need to use to workaround policy reload issue? > >> > >> No, I think perhaps we should move the mutex to selinux_state instead > >> of selinux_fs_info. selinux_fs_info has a pointer to selinux_state so > >> it can then use it indirectly. Note that your patches are going to > >> conflict with other ongoing work in the selinux next branch that is > >> refactoring policy load and converting the policy rwlock to RCU. > > > > Yeah, and I'm experimenting with a patch on top of Stephen's RCU work > > that would allow you to do this in a straightforward way without even > > messing with the fsi->mutex. My patch may or may not be eventually > > committed, but either way I'd recommend holding off on this for a > > while until the dust settles around the RCU conversion. > > I can make the SELinux\IMA changes in "selinux next branch" taking > dependencies on Stephen's patches + relevant IMA patches. I know it can be frustrating to hear what I'm about to say, but the best option is probably just to wait a little to let things settle in the SELinux -next branch. There is a lot of stuff going on right now with patches flooding in (at least "flooding" from a SELinux kernel development perspective) and we/I've haven't gotten through all of them yet. > Could you please let me know the URL to the "selinux next branch"? git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git next -- paul moore www.paul-moore.com
