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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 7, 2018 at 11:41 AM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> From: Paul Moore <paul@xxxxxxxxxxxxxx>
> Date: Wed, 7 Mar 2018 11:34:31 -0500
>> On Mon, Mar 5, 2018 at 2:03 AM, Xin Long <lucien.xin@xxxxxxxxx> wrote:
>>> On Mon, Mar 5, 2018 at 9:40 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
>>>> 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
>>>
>>>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux USB Development]     [Yosemite News]     [Linux SCSI]

  Powered by Linux