Re: linux-next: manual merge of the selinux tree with the net-next tree

On Wed, Mar 7, 2018 at 11:41 AM, David Miller [off-list ref] wrote:

From: Paul Moore <paul@paul-moore.com>
Date: Wed, 7 Mar 2018 11:34:31 -0500

quoted

On Mon, Mar 5, 2018 at 2:03 AM, Xin Long [off-list ref] wrote:

quoted

On Mon, Mar 5, 2018 at 9:40 AM, Stephen Rothwell [off-list ref] wrote:

quoted

Hi Paul,

Today's linux-next merge of the selinux tree got a conflict in:

  net/sctp/socket.c

between several refactoring commits from the net-next tree and commit:

  2277c7cd75e3 ("sctp: Add LSM hooks")

from the selinux tree.

I fixed it up (I think - see below) and can carry the fix as

The fixup is great!  the same as I mentioned in:
https://patchwork.ozlabs.org/patch/879898/
for net-next.git

quoted

necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

[net-next,0/9] sctp: clean up sctp_sendmsg, this patchset was just applied
in net-next. So I just guess it might not yet be there when selinux tree was
being submitted.

The selinux/next branch is based on v4.16-rc1 and doesn't feed into
the netdev tree, it goes straight to Linus during the merge window so
unfortunately I think we may need to carry this for some time and
relay this fix-up patch up to Linus during the merge window.

What a mess.

The SCTP option changes should have gone through my tree in retrospect.

It's unfortunate.

I'm not sure we could have cleanly separated the core network stack
changes from the rest of the SELinux/SCTP enablement, regardless it's
a bit late at this point.  The only other thought would have been to
simply push Xin Long's cleanup patches until after the next merge
window, but that would only be worth considering if they truly were
just cleanup patches, and even then it doesn't seem very fair to Xin
Long to have to wait.

Thankfully stuff like this is rare (at least from a netdev/SELinux POV).

-- 
paul moore
www.paul-moore.com