Re: linux-next: build failure after merge of the net-next tree

[Christoph Hellwig]

> [Christoph, I noticed that the comment above datagram_poll in
> net/core/datagram.c needs the function name updated]

I'll send a fix for that.

> 
> I have added the following merge fix patch for today:

This looks correct, thanks!

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Mon, 29 Jan 2018 12:50:28 +1100

> I have applied the following merge fix patch for today:
> 
> From: Stephen Rothwell 
> Date: Mon, 29 Jan 2018 12:34:37 +1100
> Subject: [PATCH] net: fixup for "net: tcp: close sock if net namespace is 
> exiting"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  include/net/net_namespace.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
> index 235105afa5e1..f306b2aa15a4 100644
> --- a/include/net/net_namespace.h
> +++ b/include/net/net_namespace.h
> @@ -225,7 +225,7 @@ int net_eq(const struct net *net1, const struct net *net2)
>  
>  static inline int check_net(const struct net *net)
>  {
> - return atomic_read(>count) != 0;
> + return refcount_read(>count) != 0;
>  }
>  
>  void net_drop_ns(void *);

Yep, this is perfect.

Re: linux-next: build failure after merge of the net-next tree

[Alexei Starovoitov]

On Fri, Jan 12, 2018 at 05:21:54PM +0100, Daniel Borkmann wrote:
> On 01/12/2018 04:56 PM, Alexei Starovoitov wrote:
> > On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
> >> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
> >>> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>  From: Alexei Starovoitov 
>  Date: Wed, 10 Jan 2018 17:58:54 -0800
> 
> > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> After merging the net-next tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >>
> >> kernel/bpf/verifier.o: In function `bpf_check':
> >> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
> >>
> >> Caused by commit
> >>
> >>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
> >>
> >> interacting with commit
> >>
> >>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> >>
> >> from the bpf and net trees.
> >>
> >> I have just reverted commit 290af86629b2 for today.  A better solution
> >> would be nice (lie fixing this in a merge between the net-next and net
> >> trees).
> >
> > that's due to 'endif' from 290af86629b2 needs to be moved above
> > bpf_patch_call_args() definition.
> 
>  That doesn't fix it, because then you'd need to expose
>  interpreters_args as well and obviously that can't be right.
> 
>  Instead, we should never call bpf_patch_call_args() when JIT always on
>  is enabled.  So if we fail to JIT the subprogs we should fail
>  immediately.
> >>>
> >>> right, as I was trying to say one extra hunk would be needed for net-next.
> >>> I was reading this patch:
> >>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> >>> index a2b211262c25..ca80559c4ec3 100644
> >>> --- a/kernel/bpf/verifier.c
> >>> +++ b/kernel/bpf/verifier.c
> >>> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
> >>> *env)
> >>> depth = get_callee_stack_depth(env, insn, i);
> >>> if (depth < 0)
> >>> return depth;
> >>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> >>> +   return -ENOTSUPP;
> >>> +#else
> >>> bpf_patch_call_args(insn, depth);
> >>> +#endif
> >>> }
> >>> return 0;
> >>>
> >>> but below should be fine too.
> >>> Will test it asap.
> >>>
>  This is the net --> net-next merge resolution I am about to use to fix
>  this:
> 
>  ...
>   +static int fixup_call_args(struct bpf_verifier_env *env)
>   +{
>   +   struct bpf_prog *prog = env->prog;
>   +   struct bpf_insn *insn = prog->insnsi;
>  -int i, depth;
>  ++   int i, depth, err;
>   +
>  -if (env->prog->jit_requested)
>  -if (jit_subprogs(env) == 0)
>  ++   err = 0;
> >>
> >> Looks fine to me. The only thing I was wondering was whether we should
> >> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
> >> if for some reason we would missed to set prog->jit_requested bit under
> >> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
> >> calls in the prog. But that also means for bpf_prog_load() that right
> >> after bpf_check() returned, we would go into bpf_prog_select_runtime()
> >> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
> >> from there wouldn't do anything either since prog->jit_requested was
> >> not set in the first place, therefore we return with -ENOTSUPP from
> >> there. So the resolution looks fine to me, we can leave it as is.
> > 
> > jit_subprogs() can fail, so err = -ENOTSUPP is necessary.
> 
> But if jit_subprogs() fails, then the err is propagated at the end of
> the function (the 'return err' I mean).

right.
Also, since we do:
fp->jit_requested = ebpf_jit_enabled();
and
static inline bool ebpf_jit_enabled(void)
{
   return bpf_jit_enable && bpf_jit_is_ebpf();
}
and JIT_ALWAYS_ON depends on CONFIG_HAVE_EBPF_JIT
we should be good.

Re: linux-next: build failure after merge of the net-next tree

[Daniel Borkmann]

On 01/12/2018 04:56 PM, Alexei Starovoitov wrote:
> On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
>> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
>>> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
 From: Alexei Starovoitov 
 Date: Wed, 10 Jan 2018 17:58:54 -0800

> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> kernel/bpf/verifier.o: In function `bpf_check':
>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>>
>> Caused by commit
>>
>>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>>
>> interacting with commit
>>
>>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>>
>> from the bpf and net trees.
>>
>> I have just reverted commit 290af86629b2 for today.  A better solution
>> would be nice (lie fixing this in a merge between the net-next and net
>> trees).
>
> that's due to 'endif' from 290af86629b2 needs to be moved above
> bpf_patch_call_args() definition.

 That doesn't fix it, because then you'd need to expose
 interpreters_args as well and obviously that can't be right.

 Instead, we should never call bpf_patch_call_args() when JIT always on
 is enabled.  So if we fail to JIT the subprogs we should fail
 immediately.
>>>
>>> right, as I was trying to say one extra hunk would be needed for net-next.
>>> I was reading this patch:
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index a2b211262c25..ca80559c4ec3 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
>>> *env)
>>> depth = get_callee_stack_depth(env, insn, i);
>>> if (depth < 0)
>>> return depth;
>>> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
>>> +   return -ENOTSUPP;
>>> +#else
>>> bpf_patch_call_args(insn, depth);
>>> +#endif
>>> }
>>> return 0;
>>>
>>> but below should be fine too.
>>> Will test it asap.
>>>
 This is the net --> net-next merge resolution I am about to use to fix
 this:

 ...
  +static int fixup_call_args(struct bpf_verifier_env *env)
  +{
  + struct bpf_prog *prog = env->prog;
  + struct bpf_insn *insn = prog->insnsi;
 -  int i, depth;
 ++ int i, depth, err;
  +
 -  if (env->prog->jit_requested)
 -  if (jit_subprogs(env) == 0)
 ++ err = 0;
>>
>> Looks fine to me. The only thing I was wondering was whether we should
>> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
>> if for some reason we would missed to set prog->jit_requested bit under
>> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
>> calls in the prog. But that also means for bpf_prog_load() that right
>> after bpf_check() returned, we would go into bpf_prog_select_runtime()
>> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
>> from there wouldn't do anything either since prog->jit_requested was
>> not set in the first place, therefore we return with -ENOTSUPP from
>> there. So the resolution looks fine to me, we can leave it as is.
> 
> jit_subprogs() can fail, so err = -ENOTSUPP is necessary.

But if jit_subprogs() fails, then the err is propagated at the end of
the function (the 'return err' I mean).

Re: linux-next: build failure after merge of the net-next tree

[Alexei Starovoitov]

On Fri, Jan 12, 2018 at 11:45:42AM +0100, Daniel Borkmann wrote:
> On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
> > On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
> >> From: Alexei Starovoitov 
> >> Date: Wed, 10 Jan 2018 17:58:54 -0800
> >>
> >>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>  Hi all,
> 
>  After merging the net-next tree, today's linux-next build (x86_64
>  allmodconfig) failed like this:
> 
>  kernel/bpf/verifier.o: In function `bpf_check':
>  verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
> 
>  Caused by commit
> 
>    1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
> 
>  interacting with commit
> 
>    290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> 
>  from the bpf and net trees.
> 
>  I have just reverted commit 290af86629b2 for today.  A better solution
>  would be nice (lie fixing this in a merge between the net-next and net
>  trees).
> >>>
> >>> that's due to 'endif' from 290af86629b2 needs to be moved above
> >>> bpf_patch_call_args() definition.
> >>
> >> That doesn't fix it, because then you'd need to expose
> >> interpreters_args as well and obviously that can't be right.
> >>
> >> Instead, we should never call bpf_patch_call_args() when JIT always on
> >> is enabled.  So if we fail to JIT the subprogs we should fail
> >> immediately.
> > 
> > right, as I was trying to say one extra hunk would be needed for net-next.
> > I was reading this patch:
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index a2b211262c25..ca80559c4ec3 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
> > *env)
> > depth = get_callee_stack_depth(env, insn, i);
> > if (depth < 0)
> > return depth;
> > +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> > +   return -ENOTSUPP;
> > +#else
> > bpf_patch_call_args(insn, depth);
> > +#endif
> > }
> > return 0;
> > 
> > but below should be fine too.
> > Will test it asap.
> > 
> >> This is the net --> net-next merge resolution I am about to use to fix
> >> this:
> >>
> >> ...
> >>  +static int fixup_call_args(struct bpf_verifier_env *env)
> >>  +{
> >>  + struct bpf_prog *prog = env->prog;
> >>  + struct bpf_insn *insn = prog->insnsi;
> >> -  int i, depth;
> >> ++ int i, depth, err;
> >>  +
> >> -  if (env->prog->jit_requested)
> >> -  if (jit_subprogs(env) == 0)
> >> ++ err = 0;
> 
> Looks fine to me. The only thing I was wondering was whether we should
> set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
> if for some reason we would missed to set prog->jit_requested bit under
> CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
> calls in the prog. But that also means for bpf_prog_load() that right
> after bpf_check() returned, we would go into bpf_prog_select_runtime()
> since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
> from there wouldn't do anything either since prog->jit_requested was
> not set in the first place, therefore we return with -ENOTSUPP from
> there. So the resolution looks fine to me, we can leave it as is.

jit_subprogs() can fail, so err = -ENOTSUPP is necessary.

Re: linux-next: build failure after merge of the net-next tree

[Daniel Borkmann]

On 01/12/2018 05:21 AM, Alexei Starovoitov wrote:
> On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
>> From: Alexei Starovoitov 
>> Date: Wed, 10 Jan 2018 17:58:54 -0800
>>
>>> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
 Hi all,

 After merging the net-next tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

 kernel/bpf/verifier.o: In function `bpf_check':
 verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'

 Caused by commit

   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")

 interacting with commit

   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")

 from the bpf and net trees.

 I have just reverted commit 290af86629b2 for today.  A better solution
 would be nice (lie fixing this in a merge between the net-next and net
 trees).
>>>
>>> that's due to 'endif' from 290af86629b2 needs to be moved above
>>> bpf_patch_call_args() definition.
>>
>> That doesn't fix it, because then you'd need to expose
>> interpreters_args as well and obviously that can't be right.
>>
>> Instead, we should never call bpf_patch_call_args() when JIT always on
>> is enabled.  So if we fail to JIT the subprogs we should fail
>> immediately.
> 
> right, as I was trying to say one extra hunk would be needed for net-next.
> I was reading this patch:
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index a2b211262c25..ca80559c4ec3 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env 
> *env)
> depth = get_callee_stack_depth(env, insn, i);
> if (depth < 0)
> return depth;
> +#ifdef CONFIG_BPF_JIT_ALWAYS_ON
> +   return -ENOTSUPP;
> +#else
> bpf_patch_call_args(insn, depth);
> +#endif
> }
> return 0;
> 
> but below should be fine too.
> Will test it asap.
> 
>> This is the net --> net-next merge resolution I am about to use to fix
>> this:
>>
>> ...
>>  +static int fixup_call_args(struct bpf_verifier_env *env)
>>  +{
>>  +   struct bpf_prog *prog = env->prog;
>>  +   struct bpf_insn *insn = prog->insnsi;
>> -int i, depth;
>> ++   int i, depth, err;
>>  +
>> -if (env->prog->jit_requested)
>> -if (jit_subprogs(env) == 0)
>> ++   err = 0;

Looks fine to me. The only thing I was wondering was whether we should
set err = -ENOTSUPP here above, but actually that is unnecessary. Say,
if for some reason we would missed to set prog->jit_requested bit under
CONFIG_BPF_JIT_ALWAYS_ON, we would return 0 here even if we would have
calls in the prog. But that also means for bpf_prog_load() that right
after bpf_check() returned, we would go into bpf_prog_select_runtime()
since prog->bpf_func is still NULL at that point, and bpf_int_jit_compile()
from there wouldn't do anything either since prog->jit_requested was
not set in the first place, therefore we return with -ENOTSUPP from
there. So the resolution looks fine to me, we can leave it as is.

>> ++   if (env->prog->jit_requested) {
>> ++   err = jit_subprogs(env);
>> ++   if (err == 0)
>>  +   return 0;
>> - 
>> ++   }
>> ++#ifndef CONFIG_BPF_JIT_ALWAYS_ON
>>  +   for (i = 0; i < prog->len; i++, insn++) {
>>  +   if (insn->code != (BPF_JMP | BPF_CALL) ||
>>  +   insn->src_reg != BPF_PSEUDO_CALL)
>>  +   continue;
>>  +   depth = get_callee_stack_depth(env, insn, i);
>>  +   if (depth < 0)
>>  +   return depth;
>>  +   bpf_patch_call_args(insn, depth);
>>  +   }
>> -return 0;
>> ++   err = 0;
>> ++#endif
>> ++   return err;
>>  +}
>>  +
>>   /* fixup insn->imm field of bpf_call instructions
>>* and inline eligible helpers as explicit sequence of BPF instructions
>>*

Re: linux-next: build failure after merge of the net-next tree

[Alexei Starovoitov]

On Thu, Jan 11, 2018 at 10:11:45PM -0500, David Miller wrote:
> From: Alexei Starovoitov 
> Date: Wed, 10 Jan 2018 17:58:54 -0800
> 
> > On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
> >> Hi all,
> >> 
> >> After merging the net-next tree, today's linux-next build (x86_64
> >> allmodconfig) failed like this:
> >> 
> >> kernel/bpf/verifier.o: In function `bpf_check':
> >> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
> >> 
> >> Caused by commit
> >> 
> >>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
> >> 
> >> interacting with commit
> >> 
> >>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> >> 
> >> from the bpf and net trees.
> >> 
> >> I have just reverted commit 290af86629b2 for today.  A better solution
> >> would be nice (lie fixing this in a merge between the net-next and net
> >> trees).
> > 
> > that's due to 'endif' from 290af86629b2 needs to be moved above
> > bpf_patch_call_args() definition.
> 
> That doesn't fix it, because then you'd need to expose
> interpreters_args as well and obviously that can't be right.
> 
> Instead, we should never call bpf_patch_call_args() when JIT always on
> is enabled.  So if we fail to JIT the subprogs we should fail
> immediately.

right, as I was trying to say one extra hunk would be needed for net-next.
I was reading this patch:
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index a2b211262c25..ca80559c4ec3 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -5267,7 +5267,11 @@ static int fixup_call_args(struct bpf_verifier_env *env)
depth = get_callee_stack_depth(env, insn, i);
if (depth < 0)
return depth;
+#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+   return -ENOTSUPP;
+#else
bpf_patch_call_args(insn, depth);
+#endif
}
return 0;

but below should be fine too.
Will test it asap.

> This is the net --> net-next merge resolution I am about to use to fix
> this:
> 
> ...
>  +static int fixup_call_args(struct bpf_verifier_env *env)
>  +{
>  +struct bpf_prog *prog = env->prog;
>  +struct bpf_insn *insn = prog->insnsi;
> - int i, depth;
> ++int i, depth, err;
>  +
> - if (env->prog->jit_requested)
> - if (jit_subprogs(env) == 0)
> ++err = 0;
> ++if (env->prog->jit_requested) {
> ++err = jit_subprogs(env);
> ++if (err == 0)
>  +return 0;
> - 
> ++}
> ++#ifndef CONFIG_BPF_JIT_ALWAYS_ON
>  +for (i = 0; i < prog->len; i++, insn++) {
>  +if (insn->code != (BPF_JMP | BPF_CALL) ||
>  +insn->src_reg != BPF_PSEUDO_CALL)
>  +continue;
>  +depth = get_callee_stack_depth(env, insn, i);
>  +if (depth < 0)
>  +return depth;
>  +bpf_patch_call_args(insn, depth);
>  +}
> - return 0;
> ++err = 0;
> ++#endif
> ++return err;
>  +}
>  +
>   /* fixup insn->imm field of bpf_call instructions
>* and inline eligible helpers as explicit sequence of BPF instructions
>*

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Alexei Starovoitov 
Date: Wed, 10 Jan 2018 17:58:54 -0800

> On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
>> Hi all,
>> 
>> After merging the net-next tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>> 
>> kernel/bpf/verifier.o: In function `bpf_check':
>> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
>> 
>> Caused by commit
>> 
>>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
>> 
>> interacting with commit
>> 
>>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
>> 
>> from the bpf and net trees.
>> 
>> I have just reverted commit 290af86629b2 for today.  A better solution
>> would be nice (lie fixing this in a merge between the net-next and net
>> trees).
> 
> that's due to 'endif' from 290af86629b2 needs to be moved above
> bpf_patch_call_args() definition.

That doesn't fix it, because then you'd need to expose
interpreters_args as well and obviously that can't be right.

Instead, we should never call bpf_patch_call_args() when JIT always on
is enabled.  So if we fail to JIT the subprogs we should fail
immediately.

This is the net --> net-next merge resolution I am about to use to fix
this:

...
 +static int fixup_call_args(struct bpf_verifier_env *env)
 +{
 +  struct bpf_prog *prog = env->prog;
 +  struct bpf_insn *insn = prog->insnsi;
-   int i, depth;
++  int i, depth, err;
 +
-   if (env->prog->jit_requested)
-   if (jit_subprogs(env) == 0)
++  err = 0;
++  if (env->prog->jit_requested) {
++  err = jit_subprogs(env);
++  if (err == 0)
 +  return 0;
- 
++  }
++#ifndef CONFIG_BPF_JIT_ALWAYS_ON
 +  for (i = 0; i < prog->len; i++, insn++) {
 +  if (insn->code != (BPF_JMP | BPF_CALL) ||
 +  insn->src_reg != BPF_PSEUDO_CALL)
 +  continue;
 +  depth = get_callee_stack_depth(env, insn, i);
 +  if (depth < 0)
 +  return depth;
 +  bpf_patch_call_args(insn, depth);
 +  }
-   return 0;
++  err = 0;
++#endif
++  return err;
 +}
 +
  /* fixup insn->imm field of bpf_call instructions
   * and inline eligible helpers as explicit sequence of BPF instructions
   *

Re: linux-next: build failure after merge of the net-next tree

[Alexei Starovoitov]

On Thu, Jan 11, 2018 at 11:53:55AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> kernel/bpf/verifier.o: In function `bpf_check':
> verifier.c:(.text+0xd86e): undefined reference to `bpf_patch_call_args'
> 
> Caused by commit
> 
>   1ea47e01ad6e ("bpf: add support for bpf_call to interpreter")
> 
> interacting with commit
> 
>   290af86629b2 ("bpf: introduce BPF_JIT_ALWAYS_ON config")
> 
> from the bpf and net trees.
> 
> I have just reverted commit 290af86629b2 for today.  A better solution
> would be nice (lie fixing this in a merge between the net-next and net
> trees).

that's due to 'endif' from 290af86629b2 needs to be moved above
bpf_patch_call_args() definition.
There is another fixup needed for net-next.
I'll send a follow up patch when net gets merged into net-next.

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Wed, 10 Jan 2018 15:06:14 +1100

> From: Stephen Rothwell 
> Date: Wed, 10 Jan 2018 15:01:41 +1100
> Subject: [PATCH] tuntap: fix for "tuntap: XDP transmission"
> 
> Signed-off-by: Stephen Rothwell 

Applied, thanks Stephen.

Re: linux-next: build failure after merge of the net-next tree

[Jason Wang]

On 2018年01月10日 12:06, Stephen Rothwell wrote:

Hi all,

After merging the net-next tree, today's linux-next build (sparc64
defconfig) failed like this:

net/socket.o: In function `tun_xdp_to_ptr':
(.text+0x3180): multiple definition of `tun_xdp_to_ptr'
fs/compat_ioctl.o:compat_ioctl.c:(.text+0x0): first defined here
net/socket.o: In function `tun_ptr_to_xdp':
(.text+0x31a0): multiple definition of `tun_ptr_to_xdp'
fs/compat_ioctl.o:compat_ioctl.c:(.text+0x20): first defined here

Caused by commit

   fc72d1d54dd9 ("tuntap: XDP transmission")

I applied the following fix for today:

From: Stephen Rothwell 
Date: Wed, 10 Jan 2018 15:01:41 +1100
Subject: [PATCH] tuntap: fix for "tuntap: XDP transmission"

Signed-off-by: Stephen Rothwell 
---
  include/linux/if_tun.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/if_tun.h b/include/linux/if_tun.h
index 08e66827ad8e..c5b0a75a7812 100644
--- a/include/linux/if_tun.h
+++ b/include/linux/if_tun.h
@@ -42,11 +42,11 @@ static inline bool tun_is_xdp_buff(void *ptr)
  {
return false;
  }
-void *tun_xdp_to_ptr(void *ptr)
+static inline void *tun_xdp_to_ptr(void *ptr)
  {
return NULL;
  }
-void *tun_ptr_to_xdp(void *ptr)
+static inline void *tun_ptr_to_xdp(void *ptr)
  {
return NULL;
  }


Acked-by: Jason Wang 

David, we need this for net-next, need I repost it?

Thanks

Re: linux-next: build failure after merge of the net-next tree

[Ido Schimmel]

Hi Stephen,

On Fri, Dec 22, 2017 at 11:45:19AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:

[...]

> I have added the following merge fix patch for today (I am guessing
> a bit here):
> 
> From: Stephen Rothwell 
> Date: Fri, 22 Dec 2017 11:25:13 +1100
> Subject: [PATCH] ipv6: fix up for "ipv6: Move dst->from into struct rt6_info"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  net/ipv6/route.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 4efaac956f0c..2490280b3394 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -4321,9 +4321,8 @@ static int inet6_rtm_getroute(struct sk_buff *in_skb, 
> struct nlmsghdr *nlh,
>   goto errout;
>   }
>  
> - if (fibmatch && rt->dst.from) {
> - struct rt6_info *ort = container_of(rt->dst.from,
> - struct rt6_info, dst);
> + if (fibmatch && rt->from) {
> + struct rt6_info *ort = rt->from;

Your merge fix is correct. Thanks!

>  
>   dst_hold(>dst);
>   ip6_rt_put(rt);

Re: linux-next: build failure after merge of the net-next tree

[Jakub Kicinski]

On Thu, 21 Dec 2017 10:43:04 +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/net/netdevsim/bpf.c: In function 'nsim_bpf_setup_tc_block_cb':
> drivers/net/netdevsim/bpf.c:127:7: error: 'TC_CLSBPF_REPLACE' undeclared 
> (first use in this function)
>   case TC_CLSBPF_REPLACE:
>^
> drivers/net/netdevsim/bpf.c:129:7: error: 'TC_CLSBPF_ADD' undeclared (first 
> use in this function)
>   case TC_CLSBPF_ADD:
>^
> drivers/net/netdevsim/bpf.c:131:7: error: 'TC_CLSBPF_DESTROY' undeclared 
> (first use in this function)
>   case TC_CLSBPF_DESTROY:
>^
> 
> Caused by commit
> 
>   31d3ad832948 ("netdevsim: add bpf offload support")
> 
> interacting with commit
> 
>   102740bd9436 ("cls_bpf: fix offload assumptions after callback conversion")
> 
> from the net tree.
> 
> I applied the following merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Thu, 21 Dec 2017 10:18:46 +1100
> Subject: [PATCH] netdevsim: fix up for "cls_bpf: fix offload assumptions after
>  callback conversion"
> 
> Signed-off-by: Stephen Rothwell 

Hi Stephen, sorry about those merges today.  The proper fix is queued
up in patchwork for when net-next is merged in to net:

http://patchwork.ozlabs.org/patch/851063/

I will CC you on patches which may cause/fix merge trouble in the
future, often the information about how to resolve the conflict is
not part of the commit message.

Sorry I didn't think about CCing you earlier!

Re: linux-next: build failure after merge of the net-next tree

[Florian Fainelli]

Le 09/28/17 à 18:36, Stephen Rothwell a écrit :
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/dsa/slave.c: In function 'dsa_slave_create':
> net/dsa/slave.c:1191:18: error: 'struct dsa_slave_priv' has no member named 
> 'phy'
>   phy_disconnect(p->phy);
>   ^
> 
> Caused by commit
> 
>   0115dcd1787d ("net: dsa: use slave device phydev")
> 
> Interacting with commit
> 
>   e804441cfe0b ("net: dsa: Fix network device registration order")
> 
> from the net tree.
> 
> I applied the following merge fix patch (which I am not sure about):

Your resolution looks fine to me, thanks Stephen!

> 
> From: Stephen Rothwell 
> Date: Fri, 29 Sep 2017 11:28:45 +1000
> Subject: [PATCH] net: dsa: merge fix patch for removal of phy
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  net/dsa/slave.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 8869954485db..9191c929c6c8 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -1188,7 +1188,7 @@ int dsa_slave_create(struct dsa_port *port, const char 
> *name)
>   return 0;
>  
>  out_phy:
> - phy_disconnect(p->phy);
> + phy_disconnect(slave_dev->phydev);
>   if (of_phy_is_fixed_link(p->dp->dn))
>   of_phy_deregister_fixed_link(p->dp->dn);
>  out_free:
> 


-- 
Florian

Re: linux-next: build failure after merge of the net-next tree

[Paolo Abeni]

On Thu, 2017-09-21 at 18:37 -0700, David Miller wrote:
> From: Stephen Rothwell 
> Date: Fri, 22 Sep 2017 11:03:55 +1000
> 
> > After merging the net-next tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > net/ipv4/fib_frontend.c: In function 'fib_validate_source':
> > net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member 
> > named 'fib_has_custom_local_routes'
> >if (net->ipv4.fib_has_custom_local_routes)
> > ^
> > net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute':
> > net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member 
> > named 'fib_has_custom_local_routes'
> >net->ipv4.fib_has_custom_local_routes = true;
> > ^
> > 
> > Caused by commit
> > 
> >   6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.")
> 
> Paolo, it seems this struct member should be placed outside of
> IP_MULTIPLE_TABLES protection, since users can insert custom
> local routes even without that set.
> 
> So I'm installing the following fix for this:
> 
> 
> [PATCH] ipv4: Move fib_has_custom_local_routes outside of IP_MULTIPLE_TABLES.
> 
> > net/ipv4/fib_frontend.c: In function 'fib_validate_source':
> > net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member 
> > named 'fib_has_custom_local_routes'
> >if (net->ipv4.fib_has_custom_local_routes)
> > ^
> > net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute':
> > net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member 
> > named 'fib_has_custom_local_routes'
> >net->ipv4.fib_has_custom_local_routes = true;
> > ^
> 
> Fixes: 6e617de84e87 ("net: avoid a full fib lookup when rp_filter is 
> disabled.")
> Reported-by: Stephen Rothwell 
> Signed-off-by: David S. Miller 
> ---
>  include/net/netns/ipv4.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
> index 20720721da4b..8387f099115e 100644
> --- a/include/net/netns/ipv4.h
> +++ b/include/net/netns/ipv4.h
> @@ -49,10 +49,10 @@ struct netns_ipv4 {
>  #ifdef CONFIG_IP_MULTIPLE_TABLES
> struct fib_rules_ops*rules_ops;
> boolfib_has_custom_rules;
> -   boolfib_has_custom_local_routes;
> struct fib_table __rcu  *fib_main;
> struct fib_table __rcu  *fib_default;
>  #endif
> +   boolfib_has_custom_local_routes;
>  #ifdef CONFIG_IP_ROUTE_CLASSID
> int fib_num_tclassid_users;
>  #endif
> -- 
> 2.13.5

My fault, I should have fuzzed the configuration before posting.

Fix looks good, thanks David!

Paolo

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Fri, 22 Sep 2017 11:03:55 +1000

> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/ipv4/fib_frontend.c: In function 'fib_validate_source':
> net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member 
> named 'fib_has_custom_local_routes'
>if (net->ipv4.fib_has_custom_local_routes)
> ^
> net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute':
> net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member 
> named 'fib_has_custom_local_routes'
>net->ipv4.fib_has_custom_local_routes = true;
> ^
> 
> Caused by commit
> 
>   6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.")

Paolo, it seems this struct member should be placed outside of
IP_MULTIPLE_TABLES protection, since users can insert custom
local routes even without that set.

So I'm installing the following fix for this:


[PATCH] ipv4: Move fib_has_custom_local_routes outside of IP_MULTIPLE_TABLES.

> net/ipv4/fib_frontend.c: In function 'fib_validate_source':
> net/ipv4/fib_frontend.c:411:16: error: 'struct netns_ipv4' has no member 
> named 'fib_has_custom_local_routes'
>if (net->ipv4.fib_has_custom_local_routes)
> ^
> net/ipv4/fib_frontend.c: In function 'inet_rtm_newroute':
> net/ipv4/fib_frontend.c:773:12: error: 'struct netns_ipv4' has no member 
> named 'fib_has_custom_local_routes'
>net->ipv4.fib_has_custom_local_routes = true;
> ^

Fixes: 6e617de84e87 ("net: avoid a full fib lookup when rp_filter is disabled.")
Reported-by: Stephen Rothwell 
Signed-off-by: David S. Miller 
---
 include/net/netns/ipv4.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/net/netns/ipv4.h b/include/net/netns/ipv4.h
index 20720721da4b..8387f099115e 100644
--- a/include/net/netns/ipv4.h
+++ b/include/net/netns/ipv4.h
@@ -49,10 +49,10 @@ struct netns_ipv4 {
 #ifdef CONFIG_IP_MULTIPLE_TABLES
struct fib_rules_ops*rules_ops;
boolfib_has_custom_rules;
-   boolfib_has_custom_local_routes;
struct fib_table __rcu  *fib_main;
struct fib_table __rcu  *fib_default;
 #endif
+   boolfib_has_custom_local_routes;
 #ifdef CONFIG_IP_ROUTE_CLASSID
int fib_num_tclassid_users;
 #endif
-- 
2.13.5

Re: linux-next: build failure after merge of the net-next tree

[John Fastabend]

On 07/17/2017 06:09 PM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> net/core/filter.o: In function `xdp_do_flush_map':
> filter.c:(.text+0x3770): undefined reference to `__dev_map_flush'
> net/core/filter.o: In function `__bpf_tx_xdp':
> filter.c:(.text+0x56dc): undefined reference to `__dev_map_insert_ctx'
> net/core/filter.o: In function `xdp_do_redirect_map':
> filter.c:(.text+0x5e24): undefined reference to `__dev_map_lookup_elem'
> 
> Caused by commit
> 
>   11393cc9b9be ("xdp: Add batching support to redirect map")
> 
> This build has
> 
> CONFIG_BPF=y
> # CONFIG_BPF_SYSCALL is not set
> 
> I have used the net-next tree from next-20170717 for today.
> 

I missed testing without CONFIG_BPF_SYSCALL. Patch is posted to netdev
and on patchworks at,

https://patchwork.ozlabs.org/patch/789862/

Thanks,
John

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Mon, 22 May 2017 13:43:00 +1000

> Hi Dave,
> 
> On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller  
> wrote:
>>
>> From: Stephen Rothwell 
>> Date: Mon, 22 May 2017 11:16:05 +1000
>> 
>> > After merging the net-next tree, today's linux-next build (powerpc
>> > ppc64_defconfig) failed like this:
>> > 
>> > net/socket.c: In function 'put_ts_pktinfo':
>> > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first 
>> > use in this function)
>> >   put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
>> > ^
>> > Caused by commit
>> > 
>> >   aad9c8c470f2 ("net: add new control message for incoming HW-timestamped 
>> > packets")
>> > 
>> > This probably broke every architecture that has its own
>> > arch//include/uapi/asm/socket.h that does not include
>> > include/uapi/asm-generic/socket.h :-(
>> > 
>> > I have used the net-next tree from next-20170519 for today.  
>> 
>> I've just pushed the following, thanks for the report:
> 
> Looks good except:
> 
>> diff --git a/arch/parisc/include/uapi/asm/socket.h 
>> b/arch/parisc/include/uapi/asm/socket.h
>> index 5147018..784b871 100644
>> --- a/arch/parisc/include/uapi/asm/socket.h
>> +++ b/arch/parisc/include/uapi/asm/socket.h
>> @@ -97,4 +97,6 @@
>>  
>>  #define SO_COOKIE   0x4032
>>  
>> +#define SCM_TIMESTAMPING_PKTINFO58
> 
> Does this need to be 0x4033 (or something)?

Good catch, I'll fix this up!

Re: linux-next: build failure after merge of the net-next tree

[Willem de Bruijn]

On Sun, May 21, 2017 at 9:16 PM, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use 
> in this function)
>   put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
>
> Caused by commit
>
>   aad9c8c470f2 ("net: add new control message for incoming HW-timestamped 
> packets")
>
> This probably broke every architecture that has its own
> arch//include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(

Indeed. I added the architecture specific versions in patch

  http://patchwork.ozlabs.org/patch/765238/

That fixes the powerpc build for me. The new option is now
defined in every file that also defines the last added such
option SCM_TIMESTAMPING_OPT_STATS. Apologies for
missing this earlier.

Re: linux-next: build failure after merge of the net-next tree

[Stephen Rothwell]

Hi Dave,

On Sun, 21 May 2017 23:14:10 -0400 (EDT) David Miller  
wrote:
>
> From: Stephen Rothwell 
> Date: Mon, 22 May 2017 11:16:05 +1000
> 
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> > 
> > net/socket.c: In function 'put_ts_pktinfo':
> > net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first 
> > use in this function)
> >   put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> > ^
> > Caused by commit
> > 
> >   aad9c8c470f2 ("net: add new control message for incoming HW-timestamped 
> > packets")
> > 
> > This probably broke every architecture that has its own
> > arch//include/uapi/asm/socket.h that does not include
> > include/uapi/asm-generic/socket.h :-(
> > 
> > I have used the net-next tree from next-20170519 for today.  
> 
> I've just pushed the following, thanks for the report:

Looks good except:

> diff --git a/arch/parisc/include/uapi/asm/socket.h 
> b/arch/parisc/include/uapi/asm/socket.h
> index 5147018..784b871 100644
> --- a/arch/parisc/include/uapi/asm/socket.h
> +++ b/arch/parisc/include/uapi/asm/socket.h
> @@ -97,4 +97,6 @@
>  
>  #define SO_COOKIE0x4032
>  
> +#define SCM_TIMESTAMPING_PKTINFO 58

Does this need to be 0x4033 (or something)?

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Mon, 22 May 2017 11:16:05 +1000

> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> net/socket.c: In function 'put_ts_pktinfo':
> net/socket.c:695:28: error: 'SCM_TIMESTAMPING_PKTINFO' undeclared (first use 
> in this function)
>   put_cmsg(msg, SOL_SOCKET, SCM_TIMESTAMPING_PKTINFO,
> ^
> Caused by commit
> 
>   aad9c8c470f2 ("net: add new control message for incoming HW-timestamped 
> packets")
> 
> This probably broke every architecture that has its own
> arch//include/uapi/asm/socket.h that does not include
> include/uapi/asm-generic/socket.h :-(
> 
> I have used the net-next tree from next-20170519 for today.

I've just pushed the following, thanks for the report:


net: Define SCM_TIMESTAMPING_PKTINFO on all architectures.

A definition was only provided for asm-generic/socket.h
using platforms, define it for the others as well

Reported-by: Stephen Rothwell 
Signed-off-by: David S. Miller 
---
 arch/alpha/include/uapi/asm/socket.h   | 2 ++
 arch/frv/include/uapi/asm/socket.h | 2 ++
 arch/ia64/include/uapi/asm/socket.h| 2 ++
 arch/m32r/include/uapi/asm/socket.h| 2 ++
 arch/mips/include/uapi/asm/socket.h| 2 ++
 arch/mn10300/include/uapi/asm/socket.h | 2 ++
 arch/parisc/include/uapi/asm/socket.h  | 2 ++
 arch/powerpc/include/uapi/asm/socket.h | 2 ++
 arch/s390/include/uapi/asm/socket.h| 2 ++
 arch/sparc/include/uapi/asm/socket.h   | 2 ++
 arch/xtensa/include/uapi/asm/socket.h  | 2 ++
 11 files changed, 22 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/socket.h 
b/arch/alpha/include/uapi/asm/socket.h
index 148d7a3..0926de6 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h 
b/arch/frv/include/uapi/asm/socket.h
index 1ccf456..e491ff0 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -98,5 +98,7 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _ASM_SOCKET_H */
 
diff --git a/arch/ia64/include/uapi/asm/socket.h 
b/arch/ia64/include/uapi/asm/socket.h
index 2c3f4b4..8693724 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -107,4 +107,6 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h 
b/arch/m32r/include/uapi/asm/socket.h
index ae6548d..5d97890 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h 
b/arch/mips/include/uapi/asm/socket.h
index 3418ec9..365ff51 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -116,4 +116,6 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h 
b/arch/mn10300/include/uapi/asm/socket.h
index 4526e92..d013c0d 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -98,4 +98,6 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h 
b/arch/parisc/include/uapi/asm/socket.h
index 5147018..784b871 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -97,4 +97,6 @@
 
 #define SO_COOKIE  0x4032
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/powerpc/include/uapi/asm/socket.h 
b/arch/powerpc/include/uapi/asm/socket.h
index 58e2ec0..bc4ca72 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -105,4 +105,6 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h 
b/arch/s390/include/uapi/asm/socket.h
index e8e5ecf..fb9769d 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -104,4 +104,6 @@
 
 #define SO_COOKIE  57
 
+#define SCM_TIMESTAMPING_PKTINFO   58
+
 #endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h 
b/arch/sparc/include/uapi/asm/socket.h
index 3f4ad19..5d67330 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -94,6 +94,8 @@
 
 #define SO_COOKIE  

Re: linux-next: build failure after merge of the net-next tree

[Stephen Rothwell]

Hi all,

On Tue, 10 Jan 2017 10:59:27 +1100 Stephen Rothwell  
wrote:
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> net/smc/af_smc.c: In function 'smc_splice_read':
> net/smc/af_smc.c:1258:39: error: passing argument 1 of 
> 'smc->clcsock->ops->splice_read' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
>^
> net/smc/af_smc.c:1258:39: note: expected 'struct file *' but argument is of 
> type 'struct socket *'
> net/smc/af_smc.c: At top level:
> net/smc/af_smc.c:1288:17: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .splice_read = smc_splice_read,   
>  ^
> net/smc/af_smc.c:1288:17: note: (near initialization for 
> 'smc_sock_ops.splice_read')
> 
> Caused by commit
> 
>   ac7138746e14 ("smc: establish new socket family")
> 
> interacting with commit
> 
>   15a8f657c71d ("switch socket ->splice_read() to struct file *")
> 
> from the vfs tree.
> 
> I applied the following merge fix patch which could well be incorrect ...
> 
> From: Stephen Rothwell 
> Date: Tue, 10 Jan 2017 10:52:38 +1100
> Subject: [PATCH] smc: merge fix for "switch socket ->splice_read() to struct 
> file *"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  net/smc/af_smc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 5d4208ad029e..4875e65f0c4a 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1242,10 +1242,11 @@ static ssize_t smc_sendpage(struct socket *sock, 
> struct page *page,
>   return rc;
>  }
>  
> -static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos,
> +static ssize_t smc_splice_read(struct file *file, loff_t *ppos,
>  struct pipe_inode_info *pipe, size_t len,
>   unsigned int flags)
>  {
> + struct socket *sock = file->private_data;
>   struct sock *sk = sock->sk;
>   struct smc_sock *smc;
>   int rc = -ENOTCONN;
> @@ -1255,7 +1256,7 @@ static ssize_t smc_splice_read(struct socket *sock, 
> loff_t *ppos,
>   if ((sk->sk_state != SMC_ACTIVE) && (sk->sk_state != SMC_CLOSED))
>   goto out;
>   if (smc->use_fallback) {
> - rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
> + rc = smc->clcsock->ops->splice_read(file, ppos,
>   pipe, len, flags);
>   } else {
>   rc = -EOPNOTSUPP;
> -- 
> 2.10.2

This fix up is now needed when the vfs tree is merged with Linus' tree.

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the net-next tree

[Ursula Braun]

ACK - smc_splice_read() is just a place holder at the moment. Its 
implementation for AF_SMC will follow.

Regards, Ursula Braun

On 01/10/2017 12:59 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> net/smc/af_smc.c: In function 'smc_splice_read':
> net/smc/af_smc.c:1258:39: error: passing argument 1 of 
> 'smc->clcsock->ops->splice_read' from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
>^
> net/smc/af_smc.c:1258:39: note: expected 'struct file *' but argument is of 
> type 'struct socket *'
> net/smc/af_smc.c: At top level:
> net/smc/af_smc.c:1288:17: error: initialization from incompatible pointer 
> type [-Werror=incompatible-pointer-types]
>   .splice_read = smc_splice_read,   
>  ^
> net/smc/af_smc.c:1288:17: note: (near initialization for 
> 'smc_sock_ops.splice_read')
> 
> Caused by commit
> 
>   ac7138746e14 ("smc: establish new socket family")
> 
> interacting with commit
> 
>   15a8f657c71d ("switch socket ->splice_read() to struct file *")
> 
> from the vfs tree.
> 
> I applied the following merge fix patch which could well be incorrect ...
> 
> From: Stephen Rothwell 
> Date: Tue, 10 Jan 2017 10:52:38 +1100
> Subject: [PATCH] smc: merge fix for "switch socket ->splice_read() to struct 
> file *"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  net/smc/af_smc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 5d4208ad029e..4875e65f0c4a 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -1242,10 +1242,11 @@ static ssize_t smc_sendpage(struct socket *sock, 
> struct page *page,
>   return rc;
>  }
> 
> -static ssize_t smc_splice_read(struct socket *sock, loff_t *ppos,
> +static ssize_t smc_splice_read(struct file *file, loff_t *ppos,
>  struct pipe_inode_info *pipe, size_t len,
>   unsigned int flags)
>  {
> + struct socket *sock = file->private_data;
>   struct sock *sk = sock->sk;
>   struct smc_sock *smc;
>   int rc = -ENOTCONN;
> @@ -1255,7 +1256,7 @@ static ssize_t smc_splice_read(struct socket *sock, 
> loff_t *ppos,
>   if ((sk->sk_state != SMC_ACTIVE) && (sk->sk_state != SMC_CLOSED))
>   goto out;
>   if (smc->use_fallback) {
> - rc = smc->clcsock->ops->splice_read(smc->clcsock, ppos,
> + rc = smc->clcsock->ops->splice_read(file, ppos,
>   pipe, len, flags);
>   } else {
>   rc = -EOPNOTSUPP;
> 

Re: QRTR merge conflict resolution (was: Re: linux-next: build failure after merge of the net-next tree)

[Arnd Bergmann]

On Friday 13 May 2016 17:47:17 Andy Gross wrote:
> On 13 May 2016 at 17:19, Bjorn Andersson  wrote:
> > On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:
> >
> >> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> > [..]
> >> > I assume we could have the QRTR go through Andy and arm-soc, with
> >> > David's approval and this fix squashed in. But we're running rather late
> >> > in this cycle, perhaps we should just back the QRTR patches out and I
> >> > can respin and resend them after the merge window (for v4.8 instead)?
> >>
> >> I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
> >> we have in arm-soc and resolve the conflict in the merge, then send
> >> a pull request with the merge to davem.
> >>
> >
> > Hi David,
> >
> > In case you missed this thread, linux-next highlighted an upcoming merge
> > conflict between the net-next and one of the branches included in the
> > arm-soc trees.
> >
> > I have prepared the merge of net-next and the conflicting tag from the
> > Qualcomm SOC, please include this in your pull towards Linus to avoid
> > the merge conflict.
> >
> > Regards,
> > Bjorn
> >
> > The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771:
> >
> >   udp: Resolve NULL pointer dereference over flow-based vxlan device 
> > (2016-05-13 01:56:14 -0400)
> 
> 
> OK. The contents look good to me.
> 
> Acked-by: Andy Gross 

Acked-by: Arnd Bergmann 

Re: QRTR merge conflict resolution (was: Re: linux-next: build failure after merge of the net-next tree)

[Andy Gross]

On 13 May 2016 at 17:19, Bjorn Andersson  wrote:
> On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:
>
>> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> [..]
>> > I assume we could have the QRTR go through Andy and arm-soc, with
>> > David's approval and this fix squashed in. But we're running rather late
>> > in this cycle, perhaps we should just back the QRTR patches out and I
>> > can respin and resend them after the merge window (for v4.8 instead)?
>>
>> I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
>> we have in arm-soc and resolve the conflict in the merge, then send
>> a pull request with the merge to davem.
>>
>
> Hi David,
>
> In case you missed this thread, linux-next highlighted an upcoming merge
> conflict between the net-next and one of the branches included in the
> arm-soc trees.
>
> I have prepared the merge of net-next and the conflicting tag from the
> Qualcomm SOC, please include this in your pull towards Linus to avoid
> the merge conflict.
>
> Regards,
> Bjorn
>
> The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771:
>
>   udp: Resolve NULL pointer dereference over flow-based vxlan device 
> (2016-05-13 01:56:14 -0400)


OK. The contents look good to me.

Acked-by: Andy Gross 

QRTR merge conflict resolution (was: Re: linux-next: build failure after merge of the net-next tree)

[Bjorn Andersson]

On Fri 13 May 14:01 PDT 2016, Arnd Bergmann wrote:

> On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
[..]
> > I assume we could have the QRTR go through Andy and arm-soc, with
> > David's approval and this fix squashed in. But we're running rather late
> > in this cycle, perhaps we should just back the QRTR patches out and I
> > can respin and resend them after the merge window (for v4.8 instead)?
> 
> I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
> we have in arm-soc and resolve the conflict in the merge, then send
> a pull request with the merge to davem.
> 

Hi David,

In case you missed this thread, linux-next highlighted an upcoming merge
conflict between the net-next and one of the branches included in the
arm-soc trees.

I have prepared the merge of net-next and the conflicting tag from the
Qualcomm SOC, please include this in your pull towards Linus to avoid
the merge conflict.

Regards,
Bjorn

The following changes since commit ed7cbbce544856b20e5811de373cf92e92499771:

  udp: Resolve NULL pointer dereference over flow-based vxlan device 
(2016-05-13 01:56:14 -0400)

are available in the git repository at:

  git://github.com/andersson/kernel tags/net-next-qcom-soc-4.7-2-merge

for you to fetch changes up to f79a917e69e1f5cd86e864b67f06147f1b0340f4:

  Merge tag 'qcom-soc-for-4.7-2' into net-next (2016-05-13 14:42:23 -0700)


Merge tag 'qcom-soc-for-4.7-2' into net-next

This merges the Qualcomm SOC tree with the net-next, solving the
merge conflict in the SMD API between the two.


Andy Gross (1):
  Merge tag 'qcom-soc-for-4.7' into soc-for-4.7-p2

Bjorn Andersson (9):
  soc: qcom: smem_state: Add stubs for disabled smem_state
  soc: qcom: smd: Introduce callback setter
  soc: qcom: smd: Split discovery and state change work
  soc: qcom: smd: Refactor channel open and close handling
  soc: qcom: smd: Support multiple channels per sdev
  soc: qcom: smd: Support opening additional channels
  soc: qcom: smem: Use write-combine remap for SMEM
  soc: qcom: smd: Make callback pass channel reference
  Merge tag 'qcom-soc-for-4.7-2' into net-next

Lina Iyer (1):
  drivers: qcom: spm: avoid module usage in non-modular SPM driver

Srinivas Kandagatla (2):
  MAINTAINERS: add qcom i2c and spi drivers to list
  MAINTAINERS: add qcom clocks to the maintainers list

 MAINTAINERS |   3 +
 drivers/soc/qcom/smd-rpm.c  |   9 +-
 drivers/soc/qcom/smd.c  | 247 +++-
 drivers/soc/qcom/smem.c |   3 +-
 drivers/soc/qcom/spm.c  |   8 +-
 drivers/soc/qcom/wcnss_ctrl.c   |   8 +-
 include/linux/soc/qcom/smd.h|  33 -
 include/linux/soc/qcom/smem_state.h |  35 +
 net/qrtr/smd.c  |   9 +-
 9 files changed, 278 insertions(+), 77 deletions(-)

> Alternatively, in case Linus merges net-next before we get that fix
> in, I could send Stephen's fix to Linus along with the pull requests.
> 
>   Arnd

Re: linux-next: build failure after merge of the net-next tree

[Arnd Bergmann]

On Tuesday 10 May 2016 11:39:34 Bjorn Andersson wrote:
> On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:
> 
> > Hi all,
> > 
> > After merging the net-next tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type 
> > [-Werror=incompatible-pointer-types]
> >   .callback = qcom_smd_qrtr_callback,
> >   ^
> > net/qrtr/smd.c:106:14: note: (near initialization for 
> > 'qcom_smd_qrtr_driver.callback')
> > 
> > Caused by commit
> > 
> >   bdabad3e363d ("net: Add Qualcomm IPC router")
> > 
> > interacting with commit
> > 
> >   b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")
> > 
> > from the arm-soc tree.
> > 
> > I added the following merge fix patch (and it turned out I needed the
> > new stubs).
> > 
> 
> Sorry for not spotting this issue earlier, I missed Andy's second pull
> request towards arm-soc and thought the SMD changes missed this cycle.
> 
> 
> Your patch looks good, but I'm not sure how we should approach the merge
> window; Andy can't pick the patch because he doesn't have the qrtr code
> and David doesn't have the SMD patches coming through Andy.
> 
> FWIW, Reviewed-by: Bjorn Andersson 
> 
> 
> I assume we could have the QRTR go through Andy and arm-soc, with
> David's approval and this fix squashed in. But we're running rather late
> in this cycle, perhaps we should just back the QRTR patches out and I
> can respin and resend them after the merge window (for v4.8 instead)?

I'd suggest you do a merge of next-next with the qcom/soc-2 branch that
we have in arm-soc and resolve the conflict in the merge, then send
a pull request with the merge to davem.

Alternatively, in case Linus merges net-next before we get that fix
in, I could send Stephen's fix to Linus along with the pull requests.

Arnd

Re: linux-next: build failure after merge of the net-next tree

[Bjorn Andersson]

On Mon 09 May 18:29 PDT 2016, Stephen Rothwell wrote:

> Hi all,
> 
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   .callback = qcom_smd_qrtr_callback,
>   ^
> net/qrtr/smd.c:106:14: note: (near initialization for 
> 'qcom_smd_qrtr_driver.callback')
> 
> Caused by commit
> 
>   bdabad3e363d ("net: Add Qualcomm IPC router")
> 
> interacting with commit
> 
>   b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")
> 
> from the arm-soc tree.
> 
> I added the following merge fix patch (and it turned out I needed the
> new stubs).
> 

Sorry for not spotting this issue earlier, I missed Andy's second pull
request towards arm-soc and thought the SMD changes missed this cycle.


Your patch looks good, but I'm not sure how we should approach the merge
window; Andy can't pick the patch because he doesn't have the qrtr code
and David doesn't have the SMD patches coming through Andy.

FWIW, Reviewed-by: Bjorn Andersson 


I assume we could have the QRTR go through Andy and arm-soc, with
David's approval and this fix squashed in. But we're running rather late
in this cycle, perhaps we should just back the QRTR patches out and I
can respin and resend them after the merge window (for v4.8 instead)?

Suggestions are welcome.

Regards,
Bjorn

Re: linux-next: build failure after merge of the net-next tree

[Andy Gross]

On 9 May 2016 at 20:29, Stephen Rothwell  wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> net/qrtr/smd.c:106:14: error: initialization from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   .callback = qcom_smd_qrtr_callback,
>   ^
> net/qrtr/smd.c:106:14: note: (near initialization for 
> 'qcom_smd_qrtr_driver.callback')
>
> Caused by commit
>
>   bdabad3e363d ("net: Add Qualcomm IPC router")
>
> interacting with commit
>
>   b853cb9628bf ("soc: qcom: smd: Make callback pass channel reference")
>
> from the arm-soc tree.
>
> I added the following merge fix patch (and it turned out I needed the
> new stubs).

Thanks for fixing this up.  I'll work with Bjorn to get this resolved.
I'll have something up for tomorrow's next pull.


Regards,

Andy Gross

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Tue, 10 May 2016 11:29:14 +1000

> Caused by commit
> 
>   e800072c18f0 ("Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> 
> which seems to have reversed some of the merge fixes in commit
> 
>   cba653210056 ("Merge 
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net")
> 
> But I am not reaaly sure what has happened here :-(
> 
> I tried to use the net-next tree from next-20160509 but that now has
> conflicts agains other changes, so I applied the following fix patch
> for today.
> 
> From: Stephen Rothwell 
> Date: Tue, 10 May 2016 11:20:23 +1000
> Subject: [PATCH] net-next: fix bad merge
> 
> Signed-off-by: Stephen Rothwell 

Thanks Stephen, I'll try to sort this out.

Re: linux-next: build failure after merge of the net-next tree

[Mark Brown]

On Fri, Apr 22, 2016 at 04:20:43PM -0700, Jeff Kirsher wrote:
> On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote:

> > > Jeff, please have your folks look into this.  Probably just a
> > simple
> > > conversion to mdelay().

> > This is still present, it's been breaking ARM allmodconfig builds for
> > about two weeks now.

> Interesting that no one spoke up until just a week ago.  I have a fix
> and I ready to push it to David Miller.

Like Stephen said it had been there for a couple of days already at the
time it was reported; I happened to be busy at the time it came up so
wasn't looking at the build reports myself.  If you've got a fix please
get it submitted ASAP, having common test configurations broken for any
length of time does get disruptive.


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the net-next tree

[Jeff Kirsher]

On Fri, 2016-04-22 at 10:20 +0100, Mark Brown wrote:
> On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote:
> > From: Stephen Rothwell 
> 
> > > After merging the net-next tree, today's linux-next build (arm
> > > allmodconfig) failed like thisi (this has actually been failing
> for a
> > > few days, now):
> 
> > > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko]
> undefined!
> 
> > > Caused by commit
> 
> > >   49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
> 
> > > arm only allows udelay()s up to 2 milliseconds.  This commit
> > > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> > > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.
> 
> > Jeff, please have your folks look into this.  Probably just a
> simple
> > conversion to mdelay().
> 
> This is still present, it's been breaking ARM allmodconfig builds for
> about two weeks now.

Interesting that no one spoke up until just a week ago.  I have a fix
and I ready to push it to David Miller.

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

Re: linux-next: build failure after merge of the net-next tree

[Mark Brown]

On Wed, Apr 13, 2016 at 11:15:13AM -0400, David Miller wrote:
> From: Stephen Rothwell 

> > After merging the net-next tree, today's linux-next build (arm
> > allmodconfig) failed like thisi (this has actually been failing for a
> > few days, now):

> > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!

> > Caused by commit

> >   49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")

> > arm only allows udelay()s up to 2 milliseconds.  This commit
> > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.

> Jeff, please have your folks look into this.  Probably just a simple
> conversion to mdelay().

This is still present, it's been breaking ARM allmodconfig builds for
about two weeks now.


signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the net-next tree

[Arnd Bergmann]

On Wednesday 13 April 2016 11:15:13 David Miller wrote:
> From: Stephen Rothwell 
> Date: Wed, 13 Apr 2016 17:50:28 +1000
> 
> > After merging the net-next tree, today's linux-next build (arm
> > allmodconfig) failed like thisi (this has actually been failing for a
> > few days, now):
> > 
> > ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!
> > 
> > Caused by commit
> > 
> >   49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
> > 
> > arm only allows udelay()s up to 2 milliseconds.  This commit
> > adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> > drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.
> 
> Jeff, please have your folks look into this.  Probably just a simple
> conversion to mdelay().
> 

I sent a patch, pretty sure we can use msleep() here rather than
a wasteful mdelay().

Arnd

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Wed, 13 Apr 2016 17:50:28 +1000

> After merging the net-next tree, today's linux-next build (arm
> allmodconfig) failed like thisi (this has actually been failing for a
> few days, now):
> 
> ERROR: "__bad_udelay" [drivers/net/ethernet/intel/ixgbe/ixgbe.ko] undefined!
> 
> Caused by commit
> 
>   49425dfc7451 ("ixgbe: Add support for x550em_a 10G MAC type")
> 
> arm only allows udelay()s up to 2 milliseconds.  This commit
> adds a 5 ms udelay in ixgbe_acquire_swfw_sync_x550em_a() in
> drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c.

Jeff, please have your folks look into this.  Probably just a simple
conversion to mdelay().

Thanks!

RE: linux-next: build failure after merge of the net-next tree

[Yuval Mintz]

> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x.h:56:0,
> >  from drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:30:
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c: In function
> 'bnx2x_dcbx_get_ap_feature':
> > drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: error:
> 'DCBX_APP_SF_DEFAULT' undeclared (first use in this function)
> >DCBX_APP_SF_DEFAULT) &&
> >^
> > Caused by commit
> >
> >   e5d3a51cefbb ("This adds support for default application priority.")
> >
> > This build is big endian.
> 
> Yuval and Ariel, you _MUST_ fix this.
> 
> This build failure has been in the tree for 24 hours and I haven't heard 
> anything
> from you two yet.

Hi Dave,

Perhaps I wasn't clear enough in the title I've provided for the fixing patch,
but I've sent it yesterday and it's marked as 'under review' for net-next.
The patch is "bnx2x: Add missing HSI for big-endian machines".

Sorry about all the noise.

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell 
Date: Thu, 18 Feb 2016 12:28:55 +1100

> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
> 
> In file included from drivers/net/ethernet/broadcom/bnx2x/bnx2x.h:56:0,
>  from drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:30:
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c: In function 
> 'bnx2x_dcbx_get_ap_feature':
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: error: 
> 'DCBX_APP_SF_DEFAULT' undeclared (first use in this function)
>DCBX_APP_SF_DEFAULT) &&  
>^
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.h:120:45: note: in definition 
> of macro 'GET_FLAGS'
>  #define GET_FLAGS(flags, bits)  ((flags) & (bits))
>  ^
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.c:224:11: note: each undeclared 
> identifier is reported only once for each function it appears in
>DCBX_APP_SF_DEFAULT) &&  
>^
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_dcb.h:120:45: note: in definition 
> of macro 'GET_FLAGS'
>  #define GET_FLAGS(flags, bits)  ((flags) & (bits))
>  ^
> 
> Caused by commit
> 
>   e5d3a51cefbb ("This adds support for default application priority.")
> 
> This build is big endian.

Yuval and Ariel, you _MUST_ fix this.

This build failure has been in the tree for 24 hours and I haven't heard 
anything
from you two yet.

If this persists for another day I'm reverting all of your changes.

Re: linux-next: build failure after merge of the net-next tree

[Stephen Rothwell]

Hi Dave,

On Sun, 23 Aug 2015 20:33:25 -0700 (PDT) David Miller da...@davemloft.net 
wrote:

 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Mon, 24 Aug 2015 13:21:11 +1000
 
  After merging the net-next tree, today's linux-next build (arm
  multi_v7_defconfig) failed like this:
 
 Fixed by:
 
 
 [PATCH] route: fix breakage after moving lwtunnel state

Thanks, I will get that tomorrow.  I must try to remember to check to
see if you have added fixes to your tree when I get these errors (not
that it happens all that often).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Thu, 20 Aug 2015 12:57:34 +1000

 After merging the net-next tree, today's linux-next build (arm
 multi_v7_defconfig) failed like this:
 
 net/ipv4/fib_semantics.c: In function 'fib_encap_match':
 net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function 
 'lwtstate_free' [-Werror=implicit-function-declaration]
lwtstate_free(lwtstate);
^
 
 Caused by commit
 
   df383e6240ef (lwtunnel: fix memory leak)
 
 CONFIG_LWTUNNEL is not set for this build.
 
 I reverted that commit for today.

Ought to already be fixed by:


From 824e7383e92815cb591793c74cc836aa5165f7f8 Mon Sep 17 00:00:00 2001
From: Ying Xue ying@windriver.com
Date: Wed, 19 Aug 2015 15:46:17 +0800
Subject: [PATCH 1/2] lwtunnel: Fix the sparse warnings in fib_encap_match
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

When CONFIG_LWTUNNEL config is not enabled, the lwtstate_free() is not
declared in lwtunnel.h at all. However, even in this case, the function
is still referenced in fib_semantics.c so that there appears the
following sparse warnings:

net/ipv4/fib_semantics.c:553:17: error: undefined identifier 'lwtstate_free'
  CC  net/ipv4/fib_semantics.o
  net/ipv4/fib_semantics.c: In function ‘fib_encap_match’:
  net/ipv4/fib_semantics.c:553:3: error: implicit declaration of function 
‘lwtstate_free’ [-Werror=implicit-function-declaration]
  cc1: some warnings being treated as errors
  make[1]: *** [net/ipv4/fib_semantics.o] Error 1
  make: *** [net/ipv4/fib_semantics.o] Error 2

To eliminate the error, we define an empty function for lwtstate_free()
in lwtunnel.h when CONFIG_LWTUNNEL is disabled.

Fixes: df383e6240ef (lwtunnel: fix memory leak)
Cc: Jiri Benc jb...@redhat.com
Reported-by: kbuild test robot fengguang...@intel.com
Signed-off-by: Ying Xue ying@windriver.com
Acked-by: Jiri Benc jb...@redhat.com
Signed-off-by: David S. Miller da...@davemloft.net
---
 include/net/lwtunnel.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/net/lwtunnel.h b/include/net/lwtunnel.h
index 34fd8f7..cfee539 100644
--- a/include/net/lwtunnel.h
+++ b/include/net/lwtunnel.h
@@ -93,6 +93,10 @@ int lwtunnel_input6(struct sk_buff *skb);
 
 #else
 
+static inline void lwtstate_free(struct lwtunnel_state *lws)
+{
+}
+
 static inline struct lwtunnel_state *
 lwtstate_get(struct lwtunnel_state *lws)
 {
-- 
2.1.0

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Tue, 18 Aug 2015 18:39:17 +1000

 drivers/net/built-in.o: In function `.vnic_wq_devcmd2_alloc':
 (.text+0x49fe40): multiple definition of `.vnic_wq_devcmd2_alloc'
 drivers/scsi/built-in.o:(.text+0xb4318): first defined here
 drivers/net/built-in.o:(.opd+0x2af00): multiple definition of 
 `vnic_wq_devcmd2_alloc'
 drivers/scsi/built-in.o:(.opd+0xad70): first defined here
 drivers/net/built-in.o: In function `.vnic_wq_init_start':
 (.text+0x49f9c0): multiple definition of `.vnic_wq_init_start'
 drivers/scsi/built-in.o:(.text+0xb3b58): first defined here
 drivers/net/built-in.o:(.opd+0x2ae88): multiple definition of 
 `vnic_wq_init_start'
 drivers/scsi/built-in.o:(.opd+0xace0): first defined here

I've committed the following to fix this:


[PATCH] enic: Fix namespace pollution causing build errors.

drivers/net/built-in.o: In function `.vnic_wq_devcmd2_alloc':
(.text+0x49fe40): multiple definition of `.vnic_wq_devcmd2_alloc'
drivers/scsi/built-in.o:(.text+0xb4318): first defined here
drivers/net/built-in.o:(.opd+0x2af00): multiple definition of 
`vnic_wq_devcmd2_alloc'
drivers/scsi/built-in.o:(.opd+0xad70): first defined here
drivers/net/built-in.o: In function `.vnic_wq_init_start':
(.text+0x49f9c0): multiple definition of `.vnic_wq_init_start'
drivers/scsi/built-in.o:(.text+0xb3b58): first defined here
drivers/net/built-in.o:(.opd+0x2ae88): multiple definition of 
`vnic_wq_init_start'
drivers/scsi/built-in.o:(.opd+0xace0): first defined here

Rename these to 'enic_*' to avoid the conflict with the functiosn of
the same name in the snic scsi driver.

Reported-by: Stephen Rothwell s...@canb.auug.org.au
Signed-off-by: David S. Miller da...@davemloft.net
---
 drivers/net/ethernet/cisco/enic/vnic_dev.c | 4 ++--
 drivers/net/ethernet/cisco/enic/vnic_wq.c  | 6 +++---
 drivers/net/ethernet/cisco/enic/vnic_wq.h  | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/cisco/enic/vnic_dev.c 
b/drivers/net/ethernet/cisco/enic/vnic_dev.c
index 9f6c641..19a49a6 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_dev.c
+++ b/drivers/net/ethernet/cisco/enic/vnic_dev.c
@@ -388,7 +388,7 @@ static int vnic_dev_init_devcmd2(struct vnic_dev *vdev)
 
vdev-devcmd2-color = 1;
vdev-devcmd2-result_size = DEVCMD2_RING_SIZE;
-   err = vnic_wq_devcmd2_alloc(vdev, vdev-devcmd2-wq, DEVCMD2_RING_SIZE,
+   err = enic_wq_devcmd2_alloc(vdev, vdev-devcmd2-wq, DEVCMD2_RING_SIZE,
DEVCMD2_DESC_SIZE);
if (err)
goto err_free_devcmd2;
@@ -400,7 +400,7 @@ static int vnic_dev_init_devcmd2(struct vnic_dev *vdev)
return -ENODEV;
}
 
-   vnic_wq_init_start(vdev-devcmd2-wq, 0, fetch_index, fetch_index, 0,
+   enic_wq_init_start(vdev-devcmd2-wq, 0, fetch_index, fetch_index, 0,
   0);
vnic_wq_enable(vdev-devcmd2-wq);
 
diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.c 
b/drivers/net/ethernet/cisco/enic/vnic_wq.c
index 627f3b1..05ad16a 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_wq.c
+++ b/drivers/net/ethernet/cisco/enic/vnic_wq.c
@@ -114,7 +114,7 @@ int vnic_wq_alloc(struct vnic_dev *vdev, struct vnic_wq 
*wq, unsigned int index,
return 0;
 }
 
-int vnic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq,
+int enic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq,
  unsigned int desc_count, unsigned int desc_size)
 {
int err;
@@ -131,7 +131,7 @@ int vnic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct 
vnic_wq *wq,
return err;
 }
 
-void vnic_wq_init_start(struct vnic_wq *wq, unsigned int cq_index,
+void enic_wq_init_start(struct vnic_wq *wq, unsigned int cq_index,
unsigned int fetch_index, unsigned int posted_index,
unsigned int error_interrupt_enable,
unsigned int error_interrupt_offset)
@@ -158,7 +158,7 @@ void vnic_wq_init(struct vnic_wq *wq, unsigned int cq_index,
unsigned int error_interrupt_enable,
unsigned int error_interrupt_offset)
 {
-   vnic_wq_init_start(wq, cq_index, 0, 0,
+   enic_wq_init_start(wq, cq_index, 0, 0,
error_interrupt_enable,
error_interrupt_offset);
 }
diff --git a/drivers/net/ethernet/cisco/enic/vnic_wq.h 
b/drivers/net/ethernet/cisco/enic/vnic_wq.h
index c9b25d3..8944af9 100644
--- a/drivers/net/ethernet/cisco/enic/vnic_wq.h
+++ b/drivers/net/ethernet/cisco/enic/vnic_wq.h
@@ -185,9 +185,9 @@ void vnic_wq_enable(struct vnic_wq *wq);
 int vnic_wq_disable(struct vnic_wq *wq);
 void vnic_wq_clean(struct vnic_wq *wq,
void (*buf_clean)(struct vnic_wq *wq, struct vnic_wq_buf *buf));
-int vnic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq,
+int enic_wq_devcmd2_alloc(struct vnic_dev *vdev, struct vnic_wq *wq,
  unsigned int desc_count, 

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Wed, 24 Jun 2015 17:37:10 +1000

 I have applied this patch for today:
 
 From: Stephen Rothwell s...@canb.auug.org.au
 Date: Wed, 24 Jun 2015 17:29:51 +1000
 Subject: [PATCH] drivers: net: xgene: fix for ACPI support without ACPI
 
 Signed-off-by: Stephen Rothwell s...@canb.auug.org.au

Applied, thanks Stephen.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-next: build failure after merge of the net-next tree

[David Miller]

From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 1 Jun 2015 13:44:13 +1000

 After merging the net-next tree, today's linux-next build (x86_64
 allmodconfig) failed like this:
 
 drivers/net/ethernet/mellanox/mlx5/core/main.c: In function 
 'mlx5_irq_set_affinity_hint':
 drivers/net/ethernet/mellanox/mlx5/core/main.c:474:2: error: implicit 
 declaration of function 'cpumask_set_cpu_local_first' 
 [-Werror=implicit-function-declaration]
   err = cpumask_set_cpu_local_first(i, numa_node, priv-irq_info[i].mask);
   ^
 
 Caused by commit db058a186f98 (net/mlx5_core: Set irq affinity hints)
 interacting with commit f36963c9d3f6 (cpumask_set_cpu_local_first =
 cpumask_local_spread, lament) from Linus' tree.
 
 I have applied the following merge fix patch (Dave, you could do this
 by back merging commit f36963c9d3f6 from Linus' tree - which is based
 on v4.1-rc2 if that worries you).  Please yell if this is not correct
 (it does build).

Thanks Stephen, I'll take care of this next time I merge.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html