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

[Marcelo Ricardo Leitner]

On Thu, Mar 08, 2018 at 01:07:03PM +1100, Stephen Rothwell wrote:
> The resolution now looks like below (there were more changes to this
> file in the net-next tree).  It will keep changing every time this file
> is touched :-(

Ugh, sorry for that, Stephen.

Considering how much of a hassle this already is, I'll hold off the
mtu refactoring I have and only post it when all this reaches Linus'
tree.  This refactoring is touching nearly every single line that the
SELinux patches touched too (where it added accounting for the IP
options) and the fixup would be a complete nightmare.

Probably I won't be able to post the sctp_outq_flush refactoring too,
but I have to check that more carefully.

  Marcelo

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

[Xin Long]

On Thu, Mar 8, 2018 at 10:07 AM, Stephen Rothwell  wrote:
> Hi all,
>
> On Mon, 5 Mar 2018 12:40:54 +1100 Stephen Rothwell  
> wrote:
>>
>> 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
>> 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.
>>
>> --
>> Cheers, it
>> Stephen Rothwell
>
> The resolution now looks like below (there were more changes to this
> file in the net-next tree).  It will keep changing every time this file
> is touched :-(
This is the last change causing this conflict, as it touched
sctp_sendmsg_new_asoc.
The following patches for sctp update that will be posted soon will
NOT touch this function again.

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

[Xin Long]

On Thu, Mar 8, 2018 at 9:00 PM, Paul Moore  wrote:
> On Wed, Mar 7, 2018 at 9:07 PM, Stephen Rothwell  
> wrote:
>> Hi all,
>>
>> On Mon, 5 Mar 2018 12:40:54 +1100 Stephen Rothwell  
>> wrote:
>>>
>>> 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
>>> 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.
>>>
>>> --
>>> Cheers,
>>> Stephen Rothwell
>>
>> The resolution now looks like below (there were more changes to this
>> file in the net-next tree).  It will keep changing every time this file
>> is touched :-(
>
> Xin Long, does this still look okay to you?
Yes, it's good.

I forgot "struct sctp_af *af;" would be there there when submitting:

   commit 2c0dbaa sctp: add support for SCTP_DSTADDRV4/6 Information for sendmsg

and should have put some notes for David.

Thanks for your reminding.

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

[Paul Moore]

On Wed, Mar 7, 2018 at 9:07 PM, Stephen Rothwell  wrote:
> Hi all,
>
> On Mon, 5 Mar 2018 12:40:54 +1100 Stephen Rothwell  
> wrote:
>>
>> 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
>> 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.
>>
>> --
>> Cheers,
>> Stephen Rothwell
>
> The resolution now looks like below (there were more changes to this
> file in the net-next tree).  It will keep changing every time this file
> is touched :-(

Xin Long, does this still look okay to you?

> diff --cc net/sctp/socket.c
> index 7d3476a4860d,73b34a6b5b09..
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@@ -1606,200 -1622,308 +1622,216 @@@ static int sctp_error(struct sock *sk,
>   static int sctp_msghdr_parse(const struct msghdr *msg,
>  struct sctp_cmsgs *cmsgs);
>
>  -static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
>  +static int sctp_sendmsg_parse(struct sock *sk, struct sctp_cmsgs *cmsgs,
>  +struct sctp_sndrcvinfo *srinfo,
>  +const struct msghdr *msg, size_t msg_len)
>   {
>  -  struct net *net = sock_net(sk);
>  -  struct sctp_sock *sp;
>  -  struct sctp_endpoint *ep;
>  -  struct sctp_association *new_asoc = NULL, *asoc = NULL;
>  -  struct sctp_transport *transport, *chunk_tp;
>  -  struct sctp_chunk *chunk;
>  -  union sctp_addr to;
>  -  struct sctp_af *af;
>  -  struct sockaddr *msg_name = NULL;
>  -  struct sctp_sndrcvinfo default_sinfo;
>  -  struct sctp_sndrcvinfo *sinfo;
>  -  struct sctp_initmsg *sinit;
>  -  sctp_assoc_t associd = 0;
>  -  struct sctp_cmsgs cmsgs = { NULL };
>  -  enum sctp_scope scope;
>  -  bool fill_sinfo_ttl = false, wait_connect = false;
>  -  struct sctp_datamsg *datamsg;
>  -  int msg_flags = msg->msg_flags;
>  -  __u16 sinfo_flags = 0;
>  -  long timeo;
>  +  __u16 sflags;
> int err;
>
>  -  err = 0;
>  -  sp = sctp_sk(sk);
>  -  ep = sp->ep;
>  +  if (sctp_sstate(sk, LISTENING) && sctp_style(sk, TCP))
>  +  return -EPIPE;
>
>  -  pr_debug("%s: sk:%p, msg:%p, msg_len:%zu ep:%p\n", __func__, sk,
>  -   msg, msg_len, ep);
>  -
>  -  /* We cannot send a message over a TCP-style listening socket. */
>  -  if (sctp_style(sk, TCP) && sctp_sstate(sk, LISTENING)) {
>  -  err = -EPIPE;
>  -  goto out_nounlock;
>  -  }
>  +  if (msg_len > sk->sk_sndbuf)
>  +  return -EMSGSIZE;
>
>  -  /* Parse out the SCTP CMSGs.  */
>  -  err = sctp_msghdr_parse(msg, );
>  +  memset(cmsgs, 0, sizeof(*cmsgs));
>  +  err = sctp_msghdr_parse(msg, cmsgs);
> if (err) {
> pr_debug("%s: msghdr parse err:%x\n", __func__, err);
>  -  goto out_nounlock;
>  +  return err;
> }
>
>  -  /* Fetch the destination address for this packet.  This
>  -   * address only selects the association--it is not necessarily
>  -   * the address we will send to.
>  -   * For a peeled-off socket, msg_name is ignored.
>  -   */
>  -  if (!sctp_style(sk, UDP_HIGH_BANDWIDTH) && msg->msg_name) {
>  -  int msg_namelen = msg->msg_namelen;
>  +  memset(srinfo, 0, sizeof(*srinfo));
>  +  if (cmsgs->srinfo) {
>  +  srinfo->sinfo_stream = cmsgs->srinfo->sinfo_stream;
>  +  srinfo->sinfo_flags = cmsgs->srinfo->sinfo_flags;
>  +  srinfo->sinfo_ppid = cmsgs->srinfo->sinfo_ppid;
>  +  srinfo->sinfo_context = cmsgs->srinfo->sinfo_context;
>  +  srinfo->sinfo_assoc_id = cmsgs->srinfo->sinfo_assoc_id;
>  +  srinfo->sinfo_timetolive = cmsgs->srinfo->sinfo_timetolive;
>  +  }
>
>  -  err = sctp_verify_addr(sk, (union sctp_addr *)msg->msg_name,
>  - msg_namelen);
>  -  if (err)
>  -  return err;
>  +  if (cmsgs->sinfo) {
>  +  srinfo->sinfo_stream = cmsgs->sinfo->snd_sid;
>  +  srinfo->sinfo_flags = cmsgs->sinfo->snd_flags;
>  +  srinfo->sinfo_ppid = cmsgs->sinfo->snd_ppid;
>  +  srinfo->sinfo_context = cmsgs->sinfo->snd_context;
>  +  srinfo->sinfo_assoc_id = cmsgs->sinfo->snd_assoc_id;
>  +  }
>
>  -  if 

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

[Stephen Rothwell]

Hi all,

On Mon, 5 Mar 2018 12:40:54 +1100 Stephen Rothwell  
wrote:
>
> 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
> 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.
> 
> -- 
> Cheers,
> Stephen Rothwell

The resolution now looks like below (there were more changes to this
file in the net-next tree).  It will keep changing every time this file
is touched :-(

-- 
Cheers,
Stephen Rothwell

diff --cc net/sctp/socket.c
index 7d3476a4860d,73b34a6b5b09..
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@@ -1606,200 -1622,308 +1622,216 @@@ static int sctp_error(struct sock *sk, 
  static int sctp_msghdr_parse(const struct msghdr *msg,
 struct sctp_cmsgs *cmsgs);
  
 -static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
 +static int sctp_sendmsg_parse(struct sock *sk, struct sctp_cmsgs *cmsgs,
 +struct sctp_sndrcvinfo *srinfo,
 +const struct msghdr *msg, size_t msg_len)
  {
 -  struct net *net = sock_net(sk);
 -  struct sctp_sock *sp;
 -  struct sctp_endpoint *ep;
 -  struct sctp_association *new_asoc = NULL, *asoc = NULL;
 -  struct sctp_transport *transport, *chunk_tp;
 -  struct sctp_chunk *chunk;
 -  union sctp_addr to;
 -  struct sctp_af *af;
 -  struct sockaddr *msg_name = NULL;
 -  struct sctp_sndrcvinfo default_sinfo;
 -  struct sctp_sndrcvinfo *sinfo;
 -  struct sctp_initmsg *sinit;
 -  sctp_assoc_t associd = 0;
 -  struct sctp_cmsgs cmsgs = { NULL };
 -  enum sctp_scope scope;
 -  bool fill_sinfo_ttl = false, wait_connect = false;
 -  struct sctp_datamsg *datamsg;
 -  int msg_flags = msg->msg_flags;
 -  __u16 sinfo_flags = 0;
 -  long timeo;
 +  __u16 sflags;
int err;
  
 -  err = 0;
 -  sp = sctp_sk(sk);
 -  ep = sp->ep;
 +  if (sctp_sstate(sk, LISTENING) && sctp_style(sk, TCP))
 +  return -EPIPE;
  
 -  pr_debug("%s: sk:%p, msg:%p, msg_len:%zu ep:%p\n", __func__, sk,
 -   msg, msg_len, ep);
 -
 -  /* We cannot send a message over a TCP-style listening socket. */
 -  if (sctp_style(sk, TCP) && sctp_sstate(sk, LISTENING)) {
 -  err = -EPIPE;
 -  goto out_nounlock;
 -  }
 +  if (msg_len > sk->sk_sndbuf)
 +  return -EMSGSIZE;
  
 -  /* Parse out the SCTP CMSGs.  */
 -  err = sctp_msghdr_parse(msg, );
 +  memset(cmsgs, 0, sizeof(*cmsgs));
 +  err = sctp_msghdr_parse(msg, cmsgs);
if (err) {
pr_debug("%s: msghdr parse err:%x\n", __func__, err);
 -  goto out_nounlock;
 +  return err;
}
  
 -  /* Fetch the destination address for this packet.  This
 -   * address only selects the association--it is not necessarily
 -   * the address we will send to.
 -   * For a peeled-off socket, msg_name is ignored.
 -   */
 -  if (!sctp_style(sk, UDP_HIGH_BANDWIDTH) && msg->msg_name) {
 -  int msg_namelen = msg->msg_namelen;
 +  memset(srinfo, 0, sizeof(*srinfo));
 +  if (cmsgs->srinfo) {
 +  srinfo->sinfo_stream = cmsgs->srinfo->sinfo_stream;
 +  srinfo->sinfo_flags = cmsgs->srinfo->sinfo_flags;
 +  srinfo->sinfo_ppid = cmsgs->srinfo->sinfo_ppid;
 +  srinfo->sinfo_context = cmsgs->srinfo->sinfo_context;
 +  srinfo->sinfo_assoc_id = cmsgs->srinfo->sinfo_assoc_id;
 +  srinfo->sinfo_timetolive = cmsgs->srinfo->sinfo_timetolive;
 +  }
  
 -  err = sctp_verify_addr(sk, (union sctp_addr *)msg->msg_name,
 - msg_namelen);
 -  if (err)
 -  return err;
 +  if (cmsgs->sinfo) {
 +  srinfo->sinfo_stream = cmsgs->sinfo->snd_sid;
 +  srinfo->sinfo_flags = cmsgs->sinfo->snd_flags;
 +  srinfo->sinfo_ppid = cmsgs->sinfo->snd_ppid;
 +  srinfo->sinfo_context = cmsgs->sinfo->snd_context;
 +  srinfo->sinfo_assoc_id = cmsgs->sinfo->snd_assoc_id;
 +  }
  
 -  if (msg_namelen > sizeof(to))
 -  msg_namelen = sizeof(to);
 -  memcpy(, msg->msg_name, msg_namelen);
 -  msg_name = msg->msg_name;
 +  if (cmsgs->prinfo) {
 +  srinfo->sinfo_timetolive = cmsgs->prinfo->pr_value;
 +  

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

[Paul Moore]

On Wed, Mar 7, 2018 at 3:26 PM, David Miller  wrote:
> From: Paul Moore 
> Date: Wed, 7 Mar 2018 15:20:33 -0500
>
>>> So you would only have to wait until my tree went in before
>>> sending your pull request.
>>
>> So you would want me to rebase selinux/next on top of Linus' tree in
>> the middle of the merge window?  I'm sure that isn't what you meant,
>> but that's how I keep reading the above ... which can't be right,
>> because in my experience that's one way to piss off Linus.  Help me
>> understand what you are saying.
>
> I never said you rebase anything.  I wonder where you get that from.

As I said, I was just trying to figure out what you were suggesting.
Your email was not very clear in my opinion.

> I'm saying, you just defer your pull request until Linus takes my
> networking tree in.
>
> No changes or rebasing of your tree is necessary whatsoever.  You just
> ask him to pull your tree as-is.
>
> Again, this is what other smaller subsystem trees do when they have a
> situation like this.

Which gets us back to what I originally suggested in my first email of
this thread: linux-next carries the fixup patch and when we send the
pull requests to Linus we mention this fixup/thread.

For what it's worth, if you mention the potential merge conflict, and
the fixup that Stephen provided, it shouldn't matter when the pull
requests are sent to Linus; he's a smart guy, he'll merge things in
the order he wants.  I've seen more than a few people get burned by
deferring pull requests, I don't intend to have SELinux, or audit for
that matter, run into the same problem.

-- 
paul moore
www.paul-moore.com

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

[David Miller]

From: Paul Moore 
Date: Wed, 7 Mar 2018 15:20:33 -0500

>> So you would only have to wait until my tree went in before
>> sending your pull request.
> 
> So you would want me to rebase selinux/next on top of Linus' tree in
> the middle of the merge window?  I'm sure that isn't what you meant,
> but that's how I keep reading the above ... which can't be right,
> because in my experience that's one way to piss off Linus.  Help me
> understand what you are saying.

I never said you rebase anything.  I wonder where you get that from.

I'm saying, you just defer your pull request until Linus takes my
networking tree in.

No changes or rebasing of your tree is necessary whatsoever.  You just
ask him to pull your tree as-is.

Again, this is what other smaller subsystem trees do when they have a
situation like this.

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

[David Miller]

From: Paul Moore 
Date: Wed, 7 Mar 2018 15:20:33 -0500

> I suppose the right thing would have been for net-next
> to pull selinux/next, yes?

Nope.

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

[Paul Moore]

On Wed, Mar 7, 2018 at 12:45 PM, David Miller  wrote:
> From: Paul Moore 
> Date: Wed, 7 Mar 2018 12:27:52 -0500
>
>> 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.
>
> I think you wanted to have more integration, rather than less.

I'm not quite sure where you are going here, I think we *all* want
integration - subtrees merge patches/trees, Linus merges subtrees,
etc. - and I don't believe I've said anything to the contrary.

> What others have done in the past, is they simply pull my networking
> tree into their's.

I only base the SELinux and audit trees on Linus' tree.  Perhaps I'm
wrong, but a quick look at net-next makes me believe you do the same.

I think it is also worth mentioning that the SELinux/SCTP patches have
been in the selinux/next branch for several days now; from what I can
tell they predate these net-next cleanup patches.  Not that it
matters, I just don't believe that pulling net-next would have solved
this problem; I suppose the right thing would have been for net-next
to pull selinux/next, yes?

> I never rebase, ever.

I've learned that saying "never" (or "never X, ever" in this case) is
a recipe for disaster, but if it works for you, go for it.

FWIW, I try to avoid rebases as much as possible; it's the nuclear
option as far as I'm concerned and the only time I regularly rebase
the SELinux and audit trees is after the merge window (e.g. we need
something in -rc1, or we are simply too far out of date).

Looking quickly at net-next, it looks like net-next/master is
refreshed/rebased on a regular basis too (it contains the
selinux-pr-20180130 tag)... and perhaps rebase is a term you don't
want to use, but I think we are on the same page here.

> My tree often goes in reasonable early in the merge window.

Generally speaking I send my pull request to Linus early in the merge
window too.  It obviously tends to vary on when he does the pull, but
we generally haven't had any major problems.

> So you would only have to wait until my tree went in before
> sending your pull request.

So you would want me to rebase selinux/next on top of Linus' tree in
the middle of the merge window?  I'm sure that isn't what you meant,
but that's how I keep reading the above ... which can't be right,
because in my experience that's one way to piss off Linus.  Help me
understand what you are saying.

> That's really the way to handle something like this.

-- 
paul moore
www.paul-moore.com

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

[David Miller]

From: Paul Moore 
Date: Wed, 7 Mar 2018 12:27:52 -0500

> 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.

I think you wanted to have more integration, rather than less.

What others have done in the past, is they simply pull my networking
tree into their's.

I never rebase, ever.

My tree often goes in reasonable early in the merge window.

So you would only have to wait until my tree went in before
sending your pull request.

That's really the way to handle something like this.

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

[Paul Moore]

On Wed, Mar 7, 2018 at 11:41 AM, David Miller  wrote:
> From: Paul Moore 
> Date: Wed, 7 Mar 2018 11:34:31 -0500
>> On Mon, Mar 5, 2018 at 2:03 AM, Xin Long  wrote:
>>> On Mon, Mar 5, 2018 at 9:40 AM, Stephen Rothwell  
>>> 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

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

[David Miller]

From: Paul Moore 
Date: Wed, 7 Mar 2018 11:34:31 -0500

> On Mon, Mar 5, 2018 at 2:03 AM, Xin Long  wrote:
>> On Mon, Mar 5, 2018 at 9:40 AM, Stephen Rothwell  
>> 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.

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

[Paul Moore]

On Mon, Mar 5, 2018 at 2:03 AM, Xin Long  wrote:
> On Mon, Mar 5, 2018 at 9:40 AM, Stephen Rothwell  
> 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.

-- 
paul moore
www.paul-moore.com

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

[Xin Long]

On Mon, Mar 5, 2018 at 9:40 AM, Stephen Rothwell  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.

>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc net/sctp/socket.c
> index 7fa76031bb08,73b34a6b5b09..
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@@ -1606,193 -1622,362 +1622,209 @@@ static int sctp_error(struct sock *sk,
>   static int sctp_msghdr_parse(const struct msghdr *msg,
>  struct sctp_cmsgs *cmsgs);
>
>  -static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
>  +static int sctp_sendmsg_parse(struct sock *sk, struct sctp_cmsgs *cmsgs,
>  +struct sctp_sndrcvinfo *srinfo,
>  +const struct msghdr *msg, size_t msg_len)
>   {
>  -  struct net *net = sock_net(sk);
>  -  struct sctp_sock *sp;
>  -  struct sctp_endpoint *ep;
>  -  struct sctp_association *new_asoc = NULL, *asoc = NULL;
>  -  struct sctp_transport *transport, *chunk_tp;
>  -  struct sctp_chunk *chunk;
>  -  union sctp_addr to;
>  -  struct sctp_af *af;
>  -  struct sockaddr *msg_name = NULL;
>  -  struct sctp_sndrcvinfo default_sinfo;
>  -  struct sctp_sndrcvinfo *sinfo;
>  -  struct sctp_initmsg *sinit;
>  -  sctp_assoc_t associd = 0;
>  -  struct sctp_cmsgs cmsgs = { NULL };
>  -  enum sctp_scope scope;
>  -  bool fill_sinfo_ttl = false, wait_connect = false;
>  -  struct sctp_datamsg *datamsg;
>  -  int msg_flags = msg->msg_flags;
>  -  __u16 sinfo_flags = 0;
>  -  long timeo;
>  +  __u16 sflags;
> int err;
>
>  -  err = 0;
>  -  sp = sctp_sk(sk);
>  -  ep = sp->ep;
>  -
>  -  pr_debug("%s: sk:%p, msg:%p, msg_len:%zu ep:%p\n", __func__, sk,
>  -   msg, msg_len, ep);
>  +  if (sctp_sstate(sk, LISTENING) && sctp_style(sk, TCP))
>  +  return -EPIPE;
>
>  -  /* We cannot send a message over a TCP-style listening socket. */
>  -  if (sctp_style(sk, TCP) && sctp_sstate(sk, LISTENING)) {
>  -  err = -EPIPE;
>  -  goto out_nounlock;
>  -  }
>  +  if (msg_len > sk->sk_sndbuf)
>  +  return -EMSGSIZE;
>
>  -  /* Parse out the SCTP CMSGs.  */
>  -  err = sctp_msghdr_parse(msg, );
>  +  memset(cmsgs, 0, sizeof(*cmsgs));
>  +  err = sctp_msghdr_parse(msg, cmsgs);
> if (err) {
> pr_debug("%s: msghdr parse err:%x\n", __func__, err);
>  -  goto out_nounlock;
>  +  return err;
> }
>
>  -  /* Fetch the destination address for this packet.  This
>  -   * address only selects the association--it is not necessarily
>  -   * the address we will send to.
>  -   * For a peeled-off socket, msg_name is ignored.
>  -   */
>  -  if (!sctp_style(sk, UDP_HIGH_BANDWIDTH) && msg->msg_name) {
>  -  int msg_namelen = msg->msg_namelen;
>  -
>  -  err = sctp_verify_addr(sk, (union sctp_addr *)msg->msg_name,
>  - msg_namelen);
>  -  if (err)
>  -  return err;
>  -
>  -  if (msg_namelen > sizeof(to))
>  -  msg_namelen = sizeof(to);
>  -  memcpy(, msg->msg_name, msg_namelen);
>  -  msg_name = msg->msg_name;
>  +  memset(srinfo, 0, sizeof(*srinfo));
>  +  if (cmsgs->srinfo) {
>  +  srinfo->sinfo_stream = cmsgs->srinfo->sinfo_stream;
>  +  srinfo->sinfo_flags = cmsgs->srinfo->sinfo_flags;
>  +  srinfo->sinfo_ppid = cmsgs->srinfo->sinfo_ppid;
>  +  srinfo->sinfo_context = cmsgs->srinfo->sinfo_context;
>  +  srinfo->sinfo_assoc_id = cmsgs->srinfo->sinfo_assoc_id;
>  +  srinfo->sinfo_timetolive = cmsgs->srinfo->sinfo_timetolive;
> }
>
>  -  sinit = cmsgs.init;
>  -  if (cmsgs.sinfo != NULL) {
>  -  memset(_sinfo, 0, sizeof(default_sinfo));
>  -  default_sinfo.sinfo_stream = cmsgs.sinfo->snd_sid;
>  -  

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

[Stephen Rothwell]

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
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.

-- 
Cheers,
Stephen Rothwell

diff --cc net/sctp/socket.c
index 7fa76031bb08,73b34a6b5b09..
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@@ -1606,193 -1622,362 +1622,209 @@@ static int sctp_error(struct sock *sk, 
  static int sctp_msghdr_parse(const struct msghdr *msg,
 struct sctp_cmsgs *cmsgs);
  
 -static int sctp_sendmsg(struct sock *sk, struct msghdr *msg, size_t msg_len)
 +static int sctp_sendmsg_parse(struct sock *sk, struct sctp_cmsgs *cmsgs,
 +struct sctp_sndrcvinfo *srinfo,
 +const struct msghdr *msg, size_t msg_len)
  {
 -  struct net *net = sock_net(sk);
 -  struct sctp_sock *sp;
 -  struct sctp_endpoint *ep;
 -  struct sctp_association *new_asoc = NULL, *asoc = NULL;
 -  struct sctp_transport *transport, *chunk_tp;
 -  struct sctp_chunk *chunk;
 -  union sctp_addr to;
 -  struct sctp_af *af;
 -  struct sockaddr *msg_name = NULL;
 -  struct sctp_sndrcvinfo default_sinfo;
 -  struct sctp_sndrcvinfo *sinfo;
 -  struct sctp_initmsg *sinit;
 -  sctp_assoc_t associd = 0;
 -  struct sctp_cmsgs cmsgs = { NULL };
 -  enum sctp_scope scope;
 -  bool fill_sinfo_ttl = false, wait_connect = false;
 -  struct sctp_datamsg *datamsg;
 -  int msg_flags = msg->msg_flags;
 -  __u16 sinfo_flags = 0;
 -  long timeo;
 +  __u16 sflags;
int err;
  
 -  err = 0;
 -  sp = sctp_sk(sk);
 -  ep = sp->ep;
 -
 -  pr_debug("%s: sk:%p, msg:%p, msg_len:%zu ep:%p\n", __func__, sk,
 -   msg, msg_len, ep);
 +  if (sctp_sstate(sk, LISTENING) && sctp_style(sk, TCP))
 +  return -EPIPE;
  
 -  /* We cannot send a message over a TCP-style listening socket. */
 -  if (sctp_style(sk, TCP) && sctp_sstate(sk, LISTENING)) {
 -  err = -EPIPE;
 -  goto out_nounlock;
 -  }
 +  if (msg_len > sk->sk_sndbuf)
 +  return -EMSGSIZE;
  
 -  /* Parse out the SCTP CMSGs.  */
 -  err = sctp_msghdr_parse(msg, );
 +  memset(cmsgs, 0, sizeof(*cmsgs));
 +  err = sctp_msghdr_parse(msg, cmsgs);
if (err) {
pr_debug("%s: msghdr parse err:%x\n", __func__, err);
 -  goto out_nounlock;
 +  return err;
}
  
 -  /* Fetch the destination address for this packet.  This
 -   * address only selects the association--it is not necessarily
 -   * the address we will send to.
 -   * For a peeled-off socket, msg_name is ignored.
 -   */
 -  if (!sctp_style(sk, UDP_HIGH_BANDWIDTH) && msg->msg_name) {
 -  int msg_namelen = msg->msg_namelen;
 -
 -  err = sctp_verify_addr(sk, (union sctp_addr *)msg->msg_name,
 - msg_namelen);
 -  if (err)
 -  return err;
 -
 -  if (msg_namelen > sizeof(to))
 -  msg_namelen = sizeof(to);
 -  memcpy(, msg->msg_name, msg_namelen);
 -  msg_name = msg->msg_name;
 +  memset(srinfo, 0, sizeof(*srinfo));
 +  if (cmsgs->srinfo) {
 +  srinfo->sinfo_stream = cmsgs->srinfo->sinfo_stream;
 +  srinfo->sinfo_flags = cmsgs->srinfo->sinfo_flags;
 +  srinfo->sinfo_ppid = cmsgs->srinfo->sinfo_ppid;
 +  srinfo->sinfo_context = cmsgs->srinfo->sinfo_context;
 +  srinfo->sinfo_assoc_id = cmsgs->srinfo->sinfo_assoc_id;
 +  srinfo->sinfo_timetolive = cmsgs->srinfo->sinfo_timetolive;
}
  
 -  sinit = cmsgs.init;
 -  if (cmsgs.sinfo != NULL) {
 -  memset(_sinfo, 0, sizeof(default_sinfo));
 -  default_sinfo.sinfo_stream = cmsgs.sinfo->snd_sid;
 -  default_sinfo.sinfo_flags = cmsgs.sinfo->snd_flags;
 -  default_sinfo.sinfo_ppid = cmsgs.sinfo->snd_ppid;
 -  default_sinfo.sinfo_context = cmsgs.sinfo->snd_context;
 -  default_sinfo.sinfo_assoc_id = cmsgs.sinfo->snd_assoc_id;
 -
 -  sinfo = _sinfo;
 -  fill_sinfo_ttl = true;
 -  } else {
 -  sinfo = cmsgs.srinfo;
 -  }
 -  /* Did the user specify SNDINFO/SNDRCVINFO? */
 -  if (sinfo) {
 -  sinfo_flags = sinfo->sinfo_flags;
 -  associd = sinfo->sinfo_assoc_id;
 +