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

[David Miller]

From: Stephen Rothwell 
Date: Fri, 10 Nov 2017 10:31:00 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/cls_basic.c
>   net/sched/cls_u32.c
> 
> between commits:
> 
>   0b2a59894b76 ("cls_basic: use tcf_exts_get_net() before call_rcu()")
>   35c55fc156d8 ("cls_u32: use tcf_exts_get_net() before call_rcu()")
> 
> from Linus' tree and commit:
> 
>   1d8134fea2eb ("net_sched: use idr to allocate basic filter handles")
> 
> from the net-next tree.

This should be resolved as I've just merged 'net' into 'net-next'.

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

[David Miller]

From: Stephen Rothwell 
Date: Fri, 10 Nov 2017 10:31:00 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/sched/cls_basic.c
>   net/sched/cls_u32.c
> 
> between commits:
> 
>   0b2a59894b76 ("cls_basic: use tcf_exts_get_net() before call_rcu()")
>   35c55fc156d8 ("cls_u32: use tcf_exts_get_net() before call_rcu()")
> 
> from Linus' tree and commit:
> 
>   1d8134fea2eb ("net_sched: use idr to allocate basic filter handles")
> 
> from the net-next tree.

This should be resolved as I've just merged 'net' into 'net-next'.

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

[Cong Wang]

On Thu, Nov 9, 2017 at 3:31 PM, Stephen Rothwell  wrote:
> 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.

It looks good to me.

Thanks!

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

[Cong Wang]

On Thu, Nov 9, 2017 at 3:31 PM, Stephen Rothwell  wrote:
> 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.

It looks good to me.

Thanks!

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

[Mark Brown]

On Mon, Oct 30, 2017 at 10:43:07AM -0700, Jakub Kicinski wrote:
> On Mon, 30 Oct 2017 17:02:24 +, Mark Brown wrote:

> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.

> Unfortunately, this is not a correct resolution.  Please see below.

So I actually ended up just throwing this away (and the rest of what was
going on for net-next, there were just far too many of these self
conflicts.  The tree is one of the bigger time sinks when doing -next
but today was particularly heavy.


signature.asc
Description: PGP signature

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

[Mark Brown]

On Mon, Oct 30, 2017 at 10:43:07AM -0700, Jakub Kicinski wrote:
> On Mon, 30 Oct 2017 17:02:24 +, Mark Brown wrote:

> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.

> Unfortunately, this is not a correct resolution.  Please see below.

So I actually ended up just throwing this away (and the rest of what was
going on for net-next, there were just far too many of these self
conflicts.  The tree is one of the bigger time sinks when doing -next
but today was particularly heavy.


signature.asc
Description: PGP signature

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

[Jakub Kicinski]

On Mon, 30 Oct 2017 17:02:24 +, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/netronome/nfp/flower/action.c
> 
> between commit:
> 
>   d309ae5c6a0064 ("nfp: refuse offloading filters that redirects to upper 
> devices")
> 
> from Linus' tree and commit:
> 
>   62d3f60b4d065c ("nfp: use struct fields for 8 bit-wide access")

Actually the conflict is with a much older commit b27d6a95a70d ("nfp:
compile flower vxlan tunnel set actions").

> from the net-next tree.
> 
> I fixed it up (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.

Unfortunately, this is not a correct resolution.  Please see below.

> diff --cc drivers/net/ethernet/netronome/nfp/flower/action.c
> index 8ea9320014ee,0a5fc9f8545f..
> --- a/drivers/net/ethernet/netronome/nfp/flower/action.c
> +++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
> @@@ -105,19 -104,326 +104,329 @@@ nfp_fl_output(struct nfp_fl_output *out
>   if (!out_dev)
>   return -EOPNOTSUPP;
>   
> - /* Only offload egress ports are on the same device as the ingress
> -  * port.
> + tmp_flags = last ? NFP_FL_OUT_FLAGS_LAST : 0;
> + 
> + if (tun_type) {
> + /* Verify the egress netdev matches the tunnel type. */
> + if (!nfp_fl_netdev_is_tunnel_type(out_dev, tun_type))
> + return -EOPNOTSUPP;
> + 
> + if (*tun_out_cnt)
> + return -EOPNOTSUPP;
> + (*tun_out_cnt)++;
> + 
> + output->flags = cpu_to_be16(tmp_flags |
> + NFP_FL_OUT_FLAGS_USE_TUN);
> + output->port = cpu_to_be32(NFP_FL_PORT_TYPE_TUN | tun_type);
> + } else {
> + /* Set action output parameters. */
> + output->flags = cpu_to_be16(tmp_flags);
> + 
> + /* Only offload if egress ports are on the same device as the
> +  * ingress port.
> +  */
> + if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + return -EOPNOTSUPP;

The code from net should be inserted here.  Note that net-next only
indented this area, the code is unchanged.

if (!nfp_netdev_is_nfp_repr(out_dev))
return -EOPNOTSUPP;

should immediately follow switchdev_port_same_parent_id() check.

> + output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> + if (!output->port)
> + return -EOPNOTSUPP;
> + }
> + nfp_flow->meta.shortcut = output->port;
> + 
> + return 0;
> + }
> + 
> + static bool nfp_fl_supported_tun_port(const struct tc_action *action)
> + {
> + struct ip_tunnel_info *tun = tcf_tunnel_info(action);
> + 
> + return tun->key.tp_dst == htons(NFP_FL_VXLAN_PORT);
> + }
> + 
> + static struct nfp_fl_pre_tunnel *nfp_fl_pre_tunnel(char *act_data, int 
> act_len)
> + {
> + size_t act_size = sizeof(struct nfp_fl_pre_tunnel);
> + struct nfp_fl_pre_tunnel *pre_tun_act;
> + 
> + /* Pre_tunnel action must be first on action list.
> +  * If other actions already exist they need pushed forward.
>*/
> - if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + if (act_len)
> + memmove(act_data + act_size, act_data, act_len);
> + 
> + pre_tun_act = (struct nfp_fl_pre_tunnel *)act_data;
> + 
> + memset(pre_tun_act, 0, act_size);
> + 
> + pre_tun_act->head.jump_id = NFP_FL_ACTION_OPCODE_PRE_TUNNEL;
> + pre_tun_act->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> + 
> + return pre_tun_act;
> + }
> + 
> + static int
> + nfp_fl_set_vxlan(struct nfp_fl_set_vxlan *set_vxlan,
> +  const struct tc_action *action,
> +  struct nfp_fl_pre_tunnel *pre_tun)
> + {
> + struct ip_tunnel_info *vxlan = tcf_tunnel_info(action);
> + size_t act_size = sizeof(struct nfp_fl_set_vxlan);
> + u32 tmp_set_vxlan_type_index = 0;
> + /* Currently support one pre-tunnel so index is always 0. */
> + int pretun_idx = 0;
> + 
> + if (vxlan->options_len) {
> + /* Do not support options e.g. vxlan gpe. */
>   return -EOPNOTSUPP;
> + }
> + 
>  +if (!nfp_netdev_is_nfp_repr(out_dev))
>  +return -EOPNOTSUPP;
>  +
> - output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> - if (!output->port)
> + set_vxlan->head.jump_id = NFP_FL_ACTION_OPCODE_SET_IPV4_TUNNEL;
> + set_vxlan->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> + 
> + /* Set tunnel type and pre-tunnel index. */
> + tmp_set_vxlan_type_index |=
> + FIELD_PREP(NFP_FL_IPV4_TUNNEL_TYPE, 

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

[Jakub Kicinski]

On Mon, 30 Oct 2017 17:02:24 +, Mark Brown wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   drivers/net/ethernet/netronome/nfp/flower/action.c
> 
> between commit:
> 
>   d309ae5c6a0064 ("nfp: refuse offloading filters that redirects to upper 
> devices")
> 
> from Linus' tree and commit:
> 
>   62d3f60b4d065c ("nfp: use struct fields for 8 bit-wide access")

Actually the conflict is with a much older commit b27d6a95a70d ("nfp:
compile flower vxlan tunnel set actions").

> from the net-next tree.
> 
> I fixed it up (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.

Unfortunately, this is not a correct resolution.  Please see below.

> diff --cc drivers/net/ethernet/netronome/nfp/flower/action.c
> index 8ea9320014ee,0a5fc9f8545f..
> --- a/drivers/net/ethernet/netronome/nfp/flower/action.c
> +++ b/drivers/net/ethernet/netronome/nfp/flower/action.c
> @@@ -105,19 -104,326 +104,329 @@@ nfp_fl_output(struct nfp_fl_output *out
>   if (!out_dev)
>   return -EOPNOTSUPP;
>   
> - /* Only offload egress ports are on the same device as the ingress
> -  * port.
> + tmp_flags = last ? NFP_FL_OUT_FLAGS_LAST : 0;
> + 
> + if (tun_type) {
> + /* Verify the egress netdev matches the tunnel type. */
> + if (!nfp_fl_netdev_is_tunnel_type(out_dev, tun_type))
> + return -EOPNOTSUPP;
> + 
> + if (*tun_out_cnt)
> + return -EOPNOTSUPP;
> + (*tun_out_cnt)++;
> + 
> + output->flags = cpu_to_be16(tmp_flags |
> + NFP_FL_OUT_FLAGS_USE_TUN);
> + output->port = cpu_to_be32(NFP_FL_PORT_TYPE_TUN | tun_type);
> + } else {
> + /* Set action output parameters. */
> + output->flags = cpu_to_be16(tmp_flags);
> + 
> + /* Only offload if egress ports are on the same device as the
> +  * ingress port.
> +  */
> + if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + return -EOPNOTSUPP;

The code from net should be inserted here.  Note that net-next only
indented this area, the code is unchanged.

if (!nfp_netdev_is_nfp_repr(out_dev))
return -EOPNOTSUPP;

should immediately follow switchdev_port_same_parent_id() check.

> + output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> + if (!output->port)
> + return -EOPNOTSUPP;
> + }
> + nfp_flow->meta.shortcut = output->port;
> + 
> + return 0;
> + }
> + 
> + static bool nfp_fl_supported_tun_port(const struct tc_action *action)
> + {
> + struct ip_tunnel_info *tun = tcf_tunnel_info(action);
> + 
> + return tun->key.tp_dst == htons(NFP_FL_VXLAN_PORT);
> + }
> + 
> + static struct nfp_fl_pre_tunnel *nfp_fl_pre_tunnel(char *act_data, int 
> act_len)
> + {
> + size_t act_size = sizeof(struct nfp_fl_pre_tunnel);
> + struct nfp_fl_pre_tunnel *pre_tun_act;
> + 
> + /* Pre_tunnel action must be first on action list.
> +  * If other actions already exist they need pushed forward.
>*/
> - if (!switchdev_port_same_parent_id(in_dev, out_dev))
> + if (act_len)
> + memmove(act_data + act_size, act_data, act_len);
> + 
> + pre_tun_act = (struct nfp_fl_pre_tunnel *)act_data;
> + 
> + memset(pre_tun_act, 0, act_size);
> + 
> + pre_tun_act->head.jump_id = NFP_FL_ACTION_OPCODE_PRE_TUNNEL;
> + pre_tun_act->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> + 
> + return pre_tun_act;
> + }
> + 
> + static int
> + nfp_fl_set_vxlan(struct nfp_fl_set_vxlan *set_vxlan,
> +  const struct tc_action *action,
> +  struct nfp_fl_pre_tunnel *pre_tun)
> + {
> + struct ip_tunnel_info *vxlan = tcf_tunnel_info(action);
> + size_t act_size = sizeof(struct nfp_fl_set_vxlan);
> + u32 tmp_set_vxlan_type_index = 0;
> + /* Currently support one pre-tunnel so index is always 0. */
> + int pretun_idx = 0;
> + 
> + if (vxlan->options_len) {
> + /* Do not support options e.g. vxlan gpe. */
>   return -EOPNOTSUPP;
> + }
> + 
>  +if (!nfp_netdev_is_nfp_repr(out_dev))
>  +return -EOPNOTSUPP;
>  +
> - output->port = cpu_to_be32(nfp_repr_get_port_id(out_dev));
> - if (!output->port)
> + set_vxlan->head.jump_id = NFP_FL_ACTION_OPCODE_SET_IPV4_TUNNEL;
> + set_vxlan->head.len_lw = act_size >> NFP_FL_LW_SIZ;
> + 
> + /* Set tunnel type and pre-tunnel index. */
> + tmp_set_vxlan_type_index |=
> + FIELD_PREP(NFP_FL_IPV4_TUNNEL_TYPE, 

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

[David Miller]

From: Stephen Rothwell 
Date: Wed, 3 May 2017 11:07:03 +1000

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   arch/avr32/include/uapi/asm/socket.h
> 
> between commit:
> 
>   26202873bb51 ("avr32: remove support for AVR32 architecture")
> 
> from Linus' tree and commits:
> 
>   a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
>   6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
>   5daab9db7b65 ("New getsockopt option to get socket cookie")
> 
> from the net-next tree.
> 
> I fixed it up (I removed the file) 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.

Duly noted in the pull request I sent to Linus, and now that he took
net-next in it is resolved in his tree.

Thanks!

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

[David Miller]

From: Stephen Rothwell 
Date: Wed, 3 May 2017 11:07:03 +1000

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   arch/avr32/include/uapi/asm/socket.h
> 
> between commit:
> 
>   26202873bb51 ("avr32: remove support for AVR32 architecture")
> 
> from Linus' tree and commits:
> 
>   a2d133b1d465 ("sock: introduce SO_MEMINFO getsockopt")
>   6d4339028b35 ("net: Introduce SO_INCOMING_NAPI_ID"
>   5daab9db7b65 ("New getsockopt option to get socket cookie")
> 
> from the net-next tree.
> 
> I fixed it up (I removed the file) 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.

Duly noted in the pull request I sent to Linus, and now that he took
net-next in it is resolved in his tree.

Thanks!

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

[Alexei Starovoitov]

On 3/23/17 5:10 PM, David Miller wrote:

From: Stephen Rothwell 
Date: Fri, 24 Mar 2017 11:05:14 +1100


Hi all,

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

  kernel/bpf/hashtab.c

between commit:

  8c290e60fa2a ("bpf: fix hashmap extra_elems logic")

from Linus' tree and commit:

  bcc6b1b7ebf8 ("bpf: Add hash of maps support")

from the net-next tree.

I fixed it up (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.


I did the same resolution just an hour ago when merging net into
net-next.


yes. that's correct merge conflict resolution.
Just rebuilt and retested. All looks good.
Thanks!

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

[Alexei Starovoitov]

On 3/23/17 5:10 PM, David Miller wrote:

From: Stephen Rothwell 
Date: Fri, 24 Mar 2017 11:05:14 +1100


Hi all,

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

  kernel/bpf/hashtab.c

between commit:

  8c290e60fa2a ("bpf: fix hashmap extra_elems logic")

from Linus' tree and commit:

  bcc6b1b7ebf8 ("bpf: Add hash of maps support")

from the net-next tree.

I fixed it up (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.


I did the same resolution just an hour ago when merging net into
net-next.


yes. that's correct merge conflict resolution.
Just rebuilt and retested. All looks good.
Thanks!

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

[David Miller]

From: Stephen Rothwell 
Date: Fri, 24 Mar 2017 11:05:14 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   kernel/bpf/hashtab.c
> 
> between commit:
> 
>   8c290e60fa2a ("bpf: fix hashmap extra_elems logic")
> 
> from Linus' tree and commit:
> 
>   bcc6b1b7ebf8 ("bpf: Add hash of maps support")
> 
> from the net-next tree.
> 
> I fixed it up (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.

I did the same resolution just an hour ago when merging net into
net-next.

Thanks!

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

[David Miller]

From: Stephen Rothwell 
Date: Fri, 24 Mar 2017 11:05:14 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   kernel/bpf/hashtab.c
> 
> between commit:
> 
>   8c290e60fa2a ("bpf: fix hashmap extra_elems logic")
> 
> from Linus' tree and commit:
> 
>   bcc6b1b7ebf8 ("bpf: Add hash of maps support")
> 
> from the net-next tree.
> 
> I fixed it up (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.

I did the same resolution just an hour ago when merging net into
net-next.

Thanks!

RE: linux-next: manual merge of the net-next tree with Linus' tree

[Yotam Gigi]

>-Original Message-
>From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
>Behalf Of Stephen Rothwell
>Sent: Thursday, February 02, 2017 3:50 AM
>To: David Miller ; Networking 
>Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Yotam Gigi
>
>Subject: linux-next: manual merge of the net-next tree with Linus' tree
>
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
>  net/sched/cls_matchall.c
>
>between commit:
>
>  fd62d9f5c575 ("net/sched: matchall: Fix configuration race")
>
>from Linus' tree and commit:
>
>  ec2507d2a306 ("net/sched: cls_matchall: Fix error path")
>
>from the net-next tree.
>
>I fixed it up (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.

Looks good. Thanks!

>
>--
>Cheers,
>Stephen Rothwell
>
>diff --cc net/sched/cls_matchall.c
>index b12bc2abea93,fcecf5aac666..
>--- a/net/sched/cls_matchall.c
>+++ b/net/sched/cls_matchall.c
>@@@ -118,19 -141,24 +118,24 @@@ static int mall_set_parms(struct net *n
>   struct tcf_exts e;
>   int err;
>
>-  tcf_exts_init(, TCA_MATCHALL_ACT, 0);
>+  err = tcf_exts_init(, TCA_MATCHALL_ACT, 0);
>+  if (err)
>+  return err;
>   err = tcf_exts_validate(net, tp, tb, est, , ovr);
>   if (err < 0)
>-  return err;
>+  goto errout;
>
>   if (tb[TCA_MATCHALL_CLASSID]) {
> - f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> - tcf_bind_filter(tp, >res, base);
> + head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> + tcf_bind_filter(tp, >res, base);
>   }
>
> - tcf_exts_change(tp, >exts, );
> + tcf_exts_change(tp, >exts, );
>
>   return 0;
>+ errout:
>+  tcf_exts_destroy();
>+  return err;
>  }
>
>  static int mall_change(struct net *net, struct sk_buff *in_skb,
>@@@ -162,39 -194,43 +167,44 @@@
>   return -EINVAL;
>   }
>
> - f = kzalloc(sizeof(*f), GFP_KERNEL);
> - if (!f)
> + new = kzalloc(sizeof(*new), GFP_KERNEL);
> + if (!new)
>   return -ENOBUFS;
>
>-  tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
> - err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
>++ err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
>+  if (err)
>+  goto err_exts_init;
>
>   if (!handle)
>   handle = 1;
> - f->handle = handle;
> - f->flags = flags;
> + new->handle = handle;
> + new->flags = flags;
>
> - err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
> + err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
>   if (err)
>-  goto errout;
>+  goto err_set_parms;
>
>   if (tc_should_offload(dev, tp, flags)) {
> - err = mall_replace_hw_filter(tp, f, (unsigned long) f);
> + err = mall_replace_hw_filter(tp, new, (unsigned long) new);
>   if (err) {
>   if (tc_skip_sw(flags))
>-  goto errout;
>+  goto err_replace_hw_filter;
>   else
>   err = 0;
>   }
>   }
>
> - *arg = (unsigned long) f;
> - rcu_assign_pointer(head->filter, f);
> -
> + *arg = (unsigned long) head;
> + rcu_assign_pointer(tp->root, new);
> + if (head)
> + call_rcu(>rcu, mall_destroy_rcu);
>   return 0;
>
>- errout:
>+ err_replace_hw_filter:
>+ err_set_parms:
> - tcf_exts_destroy(>exts);
>++ tcf_exts_destroy(>exts);
>+ err_exts_init:
> - kfree(f);
> + kfree(new);
>   return err;
>  }
>

RE: linux-next: manual merge of the net-next tree with Linus' tree

[Yotam Gigi]

>-Original Message-
>From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
>Behalf Of Stephen Rothwell
>Sent: Thursday, February 02, 2017 3:50 AM
>To: David Miller ; Networking 
>Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Yotam Gigi
>
>Subject: linux-next: manual merge of the net-next tree with Linus' tree
>
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
>  net/sched/cls_matchall.c
>
>between commit:
>
>  fd62d9f5c575 ("net/sched: matchall: Fix configuration race")
>
>from Linus' tree and commit:
>
>  ec2507d2a306 ("net/sched: cls_matchall: Fix error path")
>
>from the net-next tree.
>
>I fixed it up (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.

Looks good. Thanks!

>
>--
>Cheers,
>Stephen Rothwell
>
>diff --cc net/sched/cls_matchall.c
>index b12bc2abea93,fcecf5aac666..
>--- a/net/sched/cls_matchall.c
>+++ b/net/sched/cls_matchall.c
>@@@ -118,19 -141,24 +118,24 @@@ static int mall_set_parms(struct net *n
>   struct tcf_exts e;
>   int err;
>
>-  tcf_exts_init(, TCA_MATCHALL_ACT, 0);
>+  err = tcf_exts_init(, TCA_MATCHALL_ACT, 0);
>+  if (err)
>+  return err;
>   err = tcf_exts_validate(net, tp, tb, est, , ovr);
>   if (err < 0)
>-  return err;
>+  goto errout;
>
>   if (tb[TCA_MATCHALL_CLASSID]) {
> - f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> - tcf_bind_filter(tp, >res, base);
> + head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> + tcf_bind_filter(tp, >res, base);
>   }
>
> - tcf_exts_change(tp, >exts, );
> + tcf_exts_change(tp, >exts, );
>
>   return 0;
>+ errout:
>+  tcf_exts_destroy();
>+  return err;
>  }
>
>  static int mall_change(struct net *net, struct sk_buff *in_skb,
>@@@ -162,39 -194,43 +167,44 @@@
>   return -EINVAL;
>   }
>
> - f = kzalloc(sizeof(*f), GFP_KERNEL);
> - if (!f)
> + new = kzalloc(sizeof(*new), GFP_KERNEL);
> + if (!new)
>   return -ENOBUFS;
>
>-  tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
> - err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
>++ err = tcf_exts_init(>exts, TCA_MATCHALL_ACT, 0);
>+  if (err)
>+  goto err_exts_init;
>
>   if (!handle)
>   handle = 1;
> - f->handle = handle;
> - f->flags = flags;
> + new->handle = handle;
> + new->flags = flags;
>
> - err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
> + err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
>   if (err)
>-  goto errout;
>+  goto err_set_parms;
>
>   if (tc_should_offload(dev, tp, flags)) {
> - err = mall_replace_hw_filter(tp, f, (unsigned long) f);
> + err = mall_replace_hw_filter(tp, new, (unsigned long) new);
>   if (err) {
>   if (tc_skip_sw(flags))
>-  goto errout;
>+  goto err_replace_hw_filter;
>   else
>   err = 0;
>   }
>   }
>
> - *arg = (unsigned long) f;
> - rcu_assign_pointer(head->filter, f);
> -
> + *arg = (unsigned long) head;
> + rcu_assign_pointer(tp->root, new);
> + if (head)
> + call_rcu(>rcu, mall_destroy_rcu);
>   return 0;
>
>- errout:
>+ err_replace_hw_filter:
>+ err_set_parms:
> - tcf_exts_destroy(>exts);
>++ tcf_exts_destroy(>exts);
>+ err_exts_init:
> - kfree(f);
> + kfree(new);
>   return err;
>  }
>

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

[Gregory CLEMENT]

Hi Stephen,
 
 On mar., mars 15 2016, Stephen Rothwell  wrote:

> Hi all,
>
> Today's linux-next merge of the net-next tree got conflicts in:
>
>   arch/arm/boot/dts/armada-xp-db.dts
>   arch/arm/boot/dts/armada-xp-gp.dts
>   arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
>
> between commit:
>
>   d7d5a43c0d16 ("ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory 
> window")
>
> from Linus' tree and commits:
>
>   9dd7a57e2cbf ("ARM: dts: armada-xp: enable buffer manager support on Armada 
> XP boards")
>   293fdc24fcc9 ("ARM: dts: armada-xp-openblocks-ax3-4: Add BM support")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

This fix is good, thanks!

Gregory

>
> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm/boot/dts/armada-xp-db.dts
> index 45813a5526c8,30657302305d..
> --- a/arch/arm/boot/dts/armada-xp-db.dts
> +++ b/arch/arm/boot/dts/armada-xp-db.dts
> @@@ -76,8 -76,9 +76,9 @@@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> ++  MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>   
>   devbus-bootcs {
>   status = "okay";
> @@@ -229,34 -242,10 +242,38 @@@
>   spi-max-frequency = <2000>;
>   };
>   };
>  +
>  +nand@d {
>  +status = "okay";
>  +num-cs = <1>;
>  +marvell,nand-keep-config;
>  +marvell,nand-enable-arbiter;
>  +nand-on-flash-bbt;
>  +
>  +partitions {
>  +compatible = "fixed-partitions";
>  +#address-cells = <1>;
>  +#size-cells = <1>;
>  +
>  +partition@0 {
>  +label = "U-Boot";
>  +reg = <0 0x80>;
>  +};
>  +partition@80 {
>  +label = "Linux";
>  +reg = <0x80 0x80>;
>  +};
>  +partition@100 {
>  +label = "Filesystem";
>  +reg = <0x100 0x3f00>;
>  +
>  +};
>  +};
>  +};
>   };
> + 
> + bm-bppi {
> + status = "okay";
> + };
>   };
>   };
> diff --cc arch/arm/boot/dts/armada-xp-gp.dts
> index 5730b875c4f5,a1ded01d0c07..
> --- a/arch/arm/boot/dts/armada-xp-gp.dts
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@@ -95,8 -95,9 +95,9 @@@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> ++  MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>   
>   devbus-bootcs {
>   status = "okay";
> diff --cc arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> index 853bd392a4fe,3aa29a91c7b8..
> --- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> +++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> @@@ -65,9 -65,10 +65,10 @@@
>   soc {
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
>  -  MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x01, 0x2f) 0 0 0xe800 0x800
>  +  

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

[Gregory CLEMENT]

Hi Stephen,
 
 On mar., mars 15 2016, Stephen Rothwell  wrote:

> Hi all,
>
> Today's linux-next merge of the net-next tree got conflicts in:
>
>   arch/arm/boot/dts/armada-xp-db.dts
>   arch/arm/boot/dts/armada-xp-gp.dts
>   arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
>
> between commit:
>
>   d7d5a43c0d16 ("ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory 
> window")
>
> from Linus' tree and commits:
>
>   9dd7a57e2cbf ("ARM: dts: armada-xp: enable buffer manager support on Armada 
> XP boards")
>   293fdc24fcc9 ("ARM: dts: armada-xp-openblocks-ax3-4: Add BM support")
>
> from the net-next tree.
>
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

This fix is good, thanks!

Gregory

>
> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm/boot/dts/armada-xp-db.dts
> index 45813a5526c8,30657302305d..
> --- a/arch/arm/boot/dts/armada-xp-db.dts
> +++ b/arch/arm/boot/dts/armada-xp-db.dts
> @@@ -76,8 -76,9 +76,9 @@@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> ++  MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>   
>   devbus-bootcs {
>   status = "okay";
> @@@ -229,34 -242,10 +242,38 @@@
>   spi-max-frequency = <2000>;
>   };
>   };
>  +
>  +nand@d {
>  +status = "okay";
>  +num-cs = <1>;
>  +marvell,nand-keep-config;
>  +marvell,nand-enable-arbiter;
>  +nand-on-flash-bbt;
>  +
>  +partitions {
>  +compatible = "fixed-partitions";
>  +#address-cells = <1>;
>  +#size-cells = <1>;
>  +
>  +partition@0 {
>  +label = "U-Boot";
>  +reg = <0 0x80>;
>  +};
>  +partition@80 {
>  +label = "Linux";
>  +reg = <0x80 0x80>;
>  +};
>  +partition@100 {
>  +label = "Filesystem";
>  +reg = <0x100 0x3f00>;
>  +
>  +};
>  +};
>  +};
>   };
> + 
> + bm-bppi {
> + status = "okay";
> + };
>   };
>   };
> diff --cc arch/arm/boot/dts/armada-xp-gp.dts
> index 5730b875c4f5,a1ded01d0c07..
> --- a/arch/arm/boot/dts/armada-xp-gp.dts
> +++ b/arch/arm/boot/dts/armada-xp-gp.dts
> @@@ -95,8 -95,9 +95,9 @@@
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
> MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> ++  MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1
> +   MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
>   
>   devbus-bootcs {
>   status = "okay";
> diff --cc arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> index 853bd392a4fe,3aa29a91c7b8..
> --- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> +++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
> @@@ -65,9 -65,10 +65,10 @@@
>   soc {
>   ranges =  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
>  -  MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800
>  -  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
>  -  MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
>  +  MBUS_ID(0x01, 0x2f) 0 0 0xe800 0x800
>  +  MBUS_ID(0x09, 0x09) 0 0 0xf110 0x1
> -   MBUS_ID(0x09, 0x05) 0 0 0xf111 0x1>;
> ++  MBUS_ID(0x09, 0x05) 0 

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

[Nikolay Aleksandrov]

On 07/14/2015 03:46 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in:
> 
>   net/bridge/br_mdb.c
> 
> between commit:
> 
>   f1158b74e54f ("bridge: mdb: zero out the local br_ip variable before use")
> 
> from Linus' tree and commit:
> 
>   74fe61f17e99 ("bridge: mdb: add vlan support for user entries")
> 
> from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 

Looks good to me, thanks Stephen!

Cheers,
 Nik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Nikolay Aleksandrov]

On 07/14/2015 03:46 AM, Stephen Rothwell wrote:
 Hi all,
 
 Today's linux-next merge of the net-next tree got a conflict in:
 
   net/bridge/br_mdb.c
 
 between commit:
 
   f1158b74e54f (bridge: mdb: zero out the local br_ip variable before use)
 
 from Linus' tree and commit:
 
   74fe61f17e99 (bridge: mdb: add vlan support for user entries)
 
 from the net-next tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).
 

Looks good to me, thanks Stephen!

Cheers,
 Nik
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tom Lendacky]

On 05/27/2015 11:17 PM, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/amd-xgbe-phy.c between commit 983942a5eaca
("amd-xgbe-phy: Fix initial mode when autoneg is disabled") from Linus'
tree and commit 7c12aa08779c ("amd-xgbe: Move the PHY support into
amd-xgbe") from the net-next tree.

I fixed it up (the latter removed the file, so I did that - there may
be more needed) and can carry the fix as necessary (no action is
required).


I looked over the tree and it appears that everything is good. Deleting
the file is the correct action and it looks like the necessary changes
to the Makefiles and Kconfigs are present to account for that.

Thanks,
Tom




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Tom Lendacky]

On 05/27/2015 11:17 PM, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/phy/amd-xgbe-phy.c between commit 983942a5eaca
(amd-xgbe-phy: Fix initial mode when autoneg is disabled) from Linus'
tree and commit 7c12aa08779c (amd-xgbe: Move the PHY support into
amd-xgbe) from the net-next tree.

I fixed it up (the latter removed the file, so I did that - there may
be more needed) and can carry the fix as necessary (no action is
required).


I looked over the tree and it appears that everything is good. Deleting
the file is the correct action and it looks like the necessary changes
to the Makefiles and Kconfigs are present to account for that.

Thanks,
Tom




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: manual merge of the net-next tree with Linus' tree

[KY Srinivasan]

> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Wednesday, June 4, 2014 8:14 PM
> To: David Miller; net...@vger.kernel.org
> Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; KY Srinivasan;
> Greg Kroah-Hartman; stephen hemminger
> Subject: linux-next: manual merge of the net-next tree with Linus' tree
> 
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/hv/channel_mgmt.c between commit d3ba720dd58c ("Drivers: hv:
> Eliminate the channel spinlock in the callback path") from Linus' tree and
> commit 1b9d48f2a579 ("hyper-v: make uuid_le const") from the net-next
> tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action is
> required).

Thanks Stephen.

Regards,

K. Y
> 
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
> 
> diff --cc drivers/hv/channel_mgmt.c
> index 6c8b032cacba,90d654556437..
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@@ -404,7 -365,7 +404,7 @@@ static u32  next_vp
>* performance critical channels (IDE, SCSI and Network) will be uniformly
>* distributed across all available CPUs.
>*/
> - static void init_vp_index(struct vmbus_channel *channel, uuid_le
> *type_guid)  -static u32 get_vp_index(const uuid_le *type_guid)
> ++static void init_vp_index(struct vmbus_channel *channel, const uuid_le
> ++*type_guid)
>   {
>   u32 cur_cpu;
>   int i;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: linux-next: manual merge of the net-next tree with Linus' tree

[KY Srinivasan]

 -Original Message-
 From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
 Sent: Wednesday, June 4, 2014 8:14 PM
 To: David Miller; net...@vger.kernel.org
 Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; KY Srinivasan;
 Greg Kroah-Hartman; stephen hemminger
 Subject: linux-next: manual merge of the net-next tree with Linus' tree
 
 Hi all,
 
 Today's linux-next merge of the net-next tree got a conflict in
 drivers/hv/channel_mgmt.c between commit d3ba720dd58c (Drivers: hv:
 Eliminate the channel spinlock in the callback path) from Linus' tree and
 commit 1b9d48f2a579 (hyper-v: make uuid_le const) from the net-next
 tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action is
 required).

Thanks Stephen.

Regards,

K. Y
 
 --
 Cheers,
 Stephen Rothwells...@canb.auug.org.au
 
 diff --cc drivers/hv/channel_mgmt.c
 index 6c8b032cacba,90d654556437..
 --- a/drivers/hv/channel_mgmt.c
 +++ b/drivers/hv/channel_mgmt.c
 @@@ -404,7 -365,7 +404,7 @@@ static u32  next_vp
* performance critical channels (IDE, SCSI and Network) will be uniformly
* distributed across all available CPUs.
*/
 - static void init_vp_index(struct vmbus_channel *channel, uuid_le
 *type_guid)  -static u32 get_vp_index(const uuid_le *type_guid)
 ++static void init_vp_index(struct vmbus_channel *channel, const uuid_le
 ++*type_guid)
   {
   u32 cur_cpu;
   int i;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Stephen Rothwell]

Hi Jeff,

On Tue, 17 Dec 2013 17:56:09 -0800 Jeff Kirsher  
wrote:
>
> Your fix is fine, what I have in my tree is the following, so if you
> want to modify your change so that the resultant code looks like this:
> 
> struct rtnl_link_stats64 *vsi_stats =
> i40e_get_vsi_stats_struct(vsi);
> int i;
>   
> if (test_bit(__I40E_DOWN, >state))
>return stats;
> 
> if (!vsi->tx_rings)
>return stats;
>   
> rcu_read_lock();
> for (i = 0; i < vsi->num_queue_pairs; i++) {

OK, I updated my rerere cache, so it will look like that tomorrow.

Thanks.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpmztW73DYNL.pgp
Description: PGP signature

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

[Jeff Kirsher]

On Wed, 2013-12-18 at 12:46 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/intel/i40e/i40e_main.c between commit 3c325ced6aef
> ("i40e: fix null dereference") from Linus' tree and commit bc7d338fbb3f
> ("i40e: reinit flow for the main VSI") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 

Your fix is fine, what I have in my tree is the following, so if you
want to modify your change so that the resultant code looks like this:

struct rtnl_link_stats64 *vsi_stats =
i40e_get_vsi_stats_struct(vsi);
int i;
  
if (test_bit(__I40E_DOWN, >state))
   return stats;

if (!vsi->tx_rings)
   return stats;
  
rcu_read_lock();
for (i = 0; i < vsi->num_queue_pairs; i++) {


signature.asc
Description: This is a digitally signed message part

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

[Jeff Kirsher]

On Wed, 2013-12-18 at 12:46 +1100, Stephen Rothwell wrote:
 Hi all,
 
 Today's linux-next merge of the net-next tree got a conflict in
 drivers/net/ethernet/intel/i40e/i40e_main.c between commit 3c325ced6aef
 (i40e: fix null dereference) from Linus' tree and commit bc7d338fbb3f
 (i40e: reinit flow for the main VSI) from the net-next tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).
 

Your fix is fine, what I have in my tree is the following, so if you
want to modify your change so that the resultant code looks like this:

struct rtnl_link_stats64 *vsi_stats =
i40e_get_vsi_stats_struct(vsi);
int i;
  
if (test_bit(__I40E_DOWN, vsi-state))
   return stats;

if (!vsi-tx_rings)
   return stats;
  
rcu_read_lock();
for (i = 0; i  vsi-num_queue_pairs; i++) {


signature.asc
Description: This is a digitally signed message part

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

[Stephen Rothwell]

Hi Jeff,

On Tue, 17 Dec 2013 17:56:09 -0800 Jeff Kirsher jeffrey.t.kirs...@intel.com 
wrote:

 Your fix is fine, what I have in my tree is the following, so if you
 want to modify your change so that the resultant code looks like this:
 
 struct rtnl_link_stats64 *vsi_stats =
 i40e_get_vsi_stats_struct(vsi);
 int i;
   
 if (test_bit(__I40E_DOWN, vsi-state))
return stats;
 
 if (!vsi-tx_rings)
return stats;
   
 rcu_read_lock();
 for (i = 0; i  vsi-num_queue_pairs; i++) {

OK, I updated my rerere cache, so it will look like that tomorrow.

Thanks.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpmztW73DYNL.pgp
Description: PGP signature

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

[Daniel Borkmann]

On 09/05/2013 07:19 AM, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/bridge/br_multicast.c between commit 2d98c29b6fb3 ("net: bridge:
convert MLDv2 Query MRC into msecs_to_jiffies for max_delay") from Linus'
tree and commit e3f5b17047de ("net: ipv6: mld: get rid of MLDV2_MRC and
simplify calculation") from the net-next tree.

I just used the net-next tree version and can carry the fix as necessary
(no action is required).


Sounds good thanks Stephen!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Daniel Borkmann]

On 09/05/2013 07:19 AM, Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
net/bridge/br_multicast.c between commit 2d98c29b6fb3 (net: bridge:
convert MLDv2 Query MRC into msecs_to_jiffies for max_delay) from Linus'
tree and commit e3f5b17047de (net: ipv6: mld: get rid of MLDV2_MRC and
simplify calculation) from the net-next tree.

I just used the net-next tree version and can carry the fix as necessary
(no action is required).


Sounds good thanks Stephen!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Mon, 22 Apr 2013 13:09:39 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> include/net/scm.h between commit 83f1b4ba917d ("net: fix incorrect
> credentials passing") from Linus' tree and commit 6b0ee8c036ec ("scm:
> Stop passing struct cred") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).  I also applied the following merge fix patch (I am not
> sure if this is correct, but it seems to be consistent):
> 
> From: Stephen Rothwell 
> Date: Mon, 22 Apr 2013 13:06:10 +1000
> Subject: [PATCH] net: af_unix fix for incorrect credentials passing
> 
> Signed-off-by: Stephen Rothwell 

I took care of this during the net --> net-next merge, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Mon, 22 Apr 2013 13:03:24 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> net/ipv4/tcp_input.c between commit 12fb3dd9dc3c ("tcp: call
> tcp_replace_ts_recent() from tcp_ack()") from Linus' tree and commit
> 9b717a8d2450 ("tcp: TLP loss detection") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I took care of this during the net --> net-next merge, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Mon, 22 Apr 2013 12:43:34 +1000

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/emulex/benet/be_main.c between commit f11a869d4e38
> ("be2net: take care of __vlan_put_tag return value") from Linus' tree and
> commit 86a9bad3ab6b ("net: vlan: add protocol argument to packet tagging
> functions") from the net-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

I took care of this during the net --> net-next merge, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 22 Apr 2013 12:43:34 +1000

 Today's linux-next merge of the net-next tree got a conflict in
 drivers/net/ethernet/emulex/benet/be_main.c between commit f11a869d4e38
 (be2net: take care of __vlan_put_tag return value) from Linus' tree and
 commit 86a9bad3ab6b (net: vlan: add protocol argument to packet tagging
 functions) from the net-next tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

I took care of this during the net -- net-next merge, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 22 Apr 2013 13:03:24 +1000

 Today's linux-next merge of the net-next tree got a conflict in
 net/ipv4/tcp_input.c between commit 12fb3dd9dc3c (tcp: call
 tcp_replace_ts_recent() from tcp_ack()) from Linus' tree and commit
 9b717a8d2450 (tcp: TLP loss detection) from the net-next tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).

I took care of this during the net -- net-next merge, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 22 Apr 2013 13:09:39 +1000

 Today's linux-next merge of the net-next tree got a conflict in
 include/net/scm.h between commit 83f1b4ba917d (net: fix incorrect
 credentials passing) from Linus' tree and commit 6b0ee8c036ec (scm:
 Stop passing struct cred) from the net-next tree.
 
 I fixed it up (see below) and can carry the fix as necessary (no action
 is required).  I also applied the following merge fix patch (I am not
 sure if this is correct, but it seems to be consistent):
 
 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Mon, 22 Apr 2013 13:06:10 +1000
 Subject: [PATCH] net: af_unix fix for incorrect credentials passing
 
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au

I took care of this during the net -- net-next merge, thanks!
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Wed, 27 Mar 2013 11:57:43 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> include/net/ipip.h between commit 330305cc4a6b ("pv4: Fix ip-header
> identification for gso packets") from Linus' tree and commit c54419321455
> ("GRE: Refactor GRE tunneling code") from the net-next tree.
> 
> I just dropped the file (as the latter change did) and can carry the fix
> as necessary (no action is required).

Thanks, I'll take care of this when I next merge.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Wed, 27 Mar 2013 11:57:43 +1100

 Today's linux-next merge of the net-next tree got a conflict in
 include/net/ipip.h between commit 330305cc4a6b (pv4: Fix ip-header
 identification for gso packets) from Linus' tree and commit c54419321455
 (GRE: Refactor GRE tunneling code) from the net-next tree.
 
 I just dropped the file (as the latter change did) and can carry the fix
 as necessary (no action is required).

Thanks, I'll take care of this when I next merge.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Tue, 12 Mar 2013 11:33:20 +1100

> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/intel/e1000e/netdev.c between commits 4e0855dff094
> ("e1000e: fix pci-device enable-counter balance") and 66148babe728
> ("e1000e: fix runtime power management transitions") from Linus' tree and
> commit f0ff439872e1 ("e1000e: cleanup CODE_INDENT checkpatch errors")
> from the net-next tree.
> 
> The former removed the line fixed by the latter, so I did that and can
> carry the fix as necessary (no action is required).

I've just merged 'net' into 'net-next' and resolved this merge conflict.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Tue, 12 Mar 2013 11:33:20 +1100

 Hi all,
 
 Today's linux-next merge of the net-next tree got a conflict in
 drivers/net/ethernet/intel/e1000e/netdev.c between commits 4e0855dff094
 (e1000e: fix pci-device enable-counter balance) and 66148babe728
 (e1000e: fix runtime power management transitions) from Linus' tree and
 commit f0ff439872e1 (e1000e: cleanup CODE_INDENT checkpatch errors)
 from the net-next tree.
 
 The former removed the line fixed by the latter, so I did that and can
 carry the fix as necessary (no action is required).

I've just merged 'net' into 'net-next' and resolved this merge conflict.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell 
Date: Fri, 9 Nov 2012 10:53:18 +1100

> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
> 477864ddd365 ("bnx2x: Disable FCoE for 57840 since not yet supported by
> FW") from Linus' tree and commit 55c11941e382 ("bnx2x: Support loading
> cnic resources at run-time") from the net-next tree.
> 
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).

I'm pulling 'net' into 'net-next' and this is exactly how I will resolve
this conflict.  Thanks Stephen.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Fri, 9 Nov 2012 10:53:18 +1100

 Today's linux-next merge of the net-next tree got a conflict in
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c between commit
 477864ddd365 (bnx2x: Disable FCoE for 57840 since not yet supported by
 FW) from Linus' tree and commit 55c11941e382 (bnx2x: Support loading
 cnic resources at run-time) from the net-next tree.
 
 I fixed it up (I think - see below) and can carry the fix as necessary
 (no action is required).

I'm pulling 'net' into 'net-next' and this is exactly how I will resolve
this conflict.  Thanks Stephen.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Jeff Kirsher]

On Thu, 2012-07-19 at 11:15 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c between commit
> 936597631dd3 ("ixgbevf: Prevent RX/TX statistics getting reset to zero")
> from Linus' tree and various commits from the net-next tree.
> 
> I just used the version from the net tree.

I will take a look at it later tonight to verify the conflict resolution
is correct.

Thanks Stephen.


signature.asc
Description: This is a digitally signed message part

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

[Jeff Kirsher]

On Thu, 2012-07-19 at 11:15 +1000, Stephen Rothwell wrote:
 Hi all,
 
 Today's linux-next merge of the net-next tree got a conflict in
 drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c between commit
 936597631dd3 (ixgbevf: Prevent RX/TX statistics getting reset to zero)
 from Linus' tree and various commits from the net-next tree.
 
 I just used the version from the net tree.

I will take a look at it later tonight to verify the conflict resolution
is correct.

Thanks Stephen.


signature.asc
Description: This is a digitally signed message part