Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool

[Or Gerlitz]

On Tue, Jan 17, 2017 at 1:08 AM, Ariel Levkovich  wrote:
> +   MLX4_PTYS_AN_DISABLE_CAP   = 1 << 5,
>
> It's there.

I'll look, but please bring a cake to the office, we started doing
that in order to prevent people from
replying in top posting to linux mailing list.

Or.

Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool

[Or Gerlitz]

On Tue, Jan 17, 2017 at 1:08 AM, Ariel Levkovich  wrote:
> +   MLX4_PTYS_AN_DISABLE_CAP   = 1 << 5,
>
> It's there.

It would be good to spare few words on that aspect in the change log.

Re: fq_codel and skb->hash

[Tom Herbert]

On Mon, Jan 16, 2017 at 6:34 PM, Eric Dumazet  wrote:
> On Mon, 2017-01-16 at 17:44 -0800, Eric Dumazet wrote:
>> On Mon, 2017-01-16 at 17:04 -0700, Andrew Collins wrote:
>
>> >   Is there a better way to manage flow separation in routed+encapsulated 
>> > traffic?
>>
>> Encapsulated traffic is fine, since flow dissector skips encap header(s)
>> up to the L4 header.
>>
>> Problem is about encrypted traffic, since presumably this L4 header is
>> opaque for flow dissector ;)
>
>
> BTW, how can we make sure skb->hash is populated before IPSEC ?
>
> Relying on forwarding, and skb->hash set by a device might be not
> enough.
>
Should we do skb_get_hash upon entry to IPsec?

Tom

>
>

[PATCH] bpf: Fix test_lru_sanity5() in test_lru_map.c

[Martin KaFai Lau]

test_lru_sanity5() fails when the number of online cpus
is fewer than the number of possible cpus.  It can be
reproduced with qemu by using cmd args "--smp cpus=2,maxcpus=8".

The problem is the loop in test_lru_sanity5() is testing
'i' which is incorrect.

This patch:
1. Make sched_next_online() always return -1 if it cannot
   find a next cpu to schedule the process.
2. In test_lru_sanity5(), the parent process does
   sched_setaffinity() first (through sched_next_online())
   and the forked process will inherit it according to
   the 'man sched_setaffinity'.

Fixes: 5db58faf989f ("bpf: Add tests for the LRU bpf_htab")
Reported-by: Daniel Borkmann 
Signed-off-by: Martin KaFai Lau 
---
 tools/testing/selftests/bpf/test_lru_map.c | 53 +++---
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/tools/testing/selftests/bpf/test_lru_map.c 
b/tools/testing/selftests/bpf/test_lru_map.c
index b13fed534d76..9f7bd1915c21 100644
--- a/tools/testing/selftests/bpf/test_lru_map.c
+++ b/tools/testing/selftests/bpf/test_lru_map.c
@@ -67,21 +67,23 @@ static int map_equal(int lru_map, int expected)
return map_subset(lru_map, expected) && map_subset(expected, lru_map);
 }
 
-static int sched_next_online(int pid, int next_to_try)
+static int sched_next_online(int pid, int *next_to_try)
 {
cpu_set_t cpuset;
+   int next = *next_to_try;
+   int ret = -1;
 
-   if (next_to_try == nr_cpus)
-   return -1;
-
-   while (next_to_try < nr_cpus) {
+   while (next < nr_cpus) {
CPU_ZERO();
-   CPU_SET(next_to_try++, );
-   if (!sched_setaffinity(pid, sizeof(cpuset), ))
+   CPU_SET(next++, );
+   if (!sched_setaffinity(pid, sizeof(cpuset), )) {
+   ret = 0;
break;
+   }
}
 
-   return next_to_try;
+   *next_to_try = next;
+   return ret;
 }
 
 /* Size of the LRU amp is 2
@@ -96,11 +98,12 @@ static void test_lru_sanity0(int map_type, int map_flags)
 {
unsigned long long key, value[nr_cpus];
int lru_map_fd, expected_map_fd;
+   int next_cpu = 0;
 
printf("%s (map_type:%d map_flags:0x%X): ", __func__, map_type,
   map_flags);
 
-   assert(sched_next_online(0, 0) != -1);
+   assert(sched_next_online(0, _cpu) != -1);
 
if (map_flags & BPF_F_NO_COMMON_LRU)
lru_map_fd = create_map(map_type, map_flags, 2 * nr_cpus);
@@ -183,6 +186,7 @@ static void test_lru_sanity1(int map_type, int map_flags, 
unsigned int tgt_free)
int lru_map_fd, expected_map_fd;
unsigned int batch_size;
unsigned int map_size;
+   int next_cpu = 0;
 
if (map_flags & BPF_F_NO_COMMON_LRU)
/* Ther percpu lru list (i.e each cpu has its own LRU
@@ -196,7 +200,7 @@ static void test_lru_sanity1(int map_type, int map_flags, 
unsigned int tgt_free)
printf("%s (map_type:%d map_flags:0x%X): ", __func__, map_type,
   map_flags);
 
-   assert(sched_next_online(0, 0) != -1);
+   assert(sched_next_online(0, _cpu) != -1);
 
batch_size = tgt_free / 2;
assert(batch_size * 2 == tgt_free);
@@ -262,6 +266,7 @@ static void test_lru_sanity2(int map_type, int map_flags, 
unsigned int tgt_free)
int lru_map_fd, expected_map_fd;
unsigned int batch_size;
unsigned int map_size;
+   int next_cpu = 0;
 
if (map_flags & BPF_F_NO_COMMON_LRU)
/* Ther percpu lru list (i.e each cpu has its own LRU
@@ -275,7 +280,7 @@ static void test_lru_sanity2(int map_type, int map_flags, 
unsigned int tgt_free)
printf("%s (map_type:%d map_flags:0x%X): ", __func__, map_type,
   map_flags);
 
-   assert(sched_next_online(0, 0) != -1);
+   assert(sched_next_online(0, _cpu) != -1);
 
batch_size = tgt_free / 2;
assert(batch_size * 2 == tgt_free);
@@ -370,11 +375,12 @@ static void test_lru_sanity3(int map_type, int map_flags, 
unsigned int tgt_free)
int lru_map_fd, expected_map_fd;
unsigned int batch_size;
unsigned int map_size;
+   int next_cpu = 0;
 
printf("%s (map_type:%d map_flags:0x%X): ", __func__, map_type,
   map_flags);
 
-   assert(sched_next_online(0, 0) != -1);
+   assert(sched_next_online(0, _cpu) != -1);
 
batch_size = tgt_free / 2;
assert(batch_size * 2 == tgt_free);
@@ -430,11 +436,12 @@ static void test_lru_sanity4(int map_type, int map_flags, 
unsigned int tgt_free)
int lru_map_fd, expected_map_fd;
unsigned long long key, value[nr_cpus];
unsigned long long end_key;
+   int next_cpu = 0;
 
printf("%s (map_type:%d map_flags:0x%X): ", __func__, map_type,
   map_flags);
 
-   assert(sched_next_online(0, 0) != -1);
+   assert(sched_next_online(0, _cpu) != -1);
 
if 

[PATCH net] lwtunnel: fix autoload of lwt modules

[David Ahern]

Trying to add an mpls encap route when the MPLS modules are not loaded
hangs. For example:

CONFIG_MPLS=y
CONFIG_NET_MPLS_GSO=m
CONFIG_MPLS_ROUTING=m
CONFIG_MPLS_IPTUNNEL=m

$ ip route add 10.10.10.10/32 encap mpls 100 via inet 10.100.1.2

The ip command hangs:
root   880   826  0 21:25 pts/000:00:00 ip route add 10.10.10.10/32 
encap mpls 100 via inet 10.100.1.2

$ cat /proc/880/stack
[] call_usermodehelper_exec+0xd6/0x134
[] __request_module+0x27b/0x30a
[] lwtunnel_build_state+0xe4/0x178
[] fib_create_info+0x47f/0xdd4
[] fib_table_insert+0x90/0x41f
[] inet_rtm_newroute+0x4b/0x52
...

modprobe is trying to load rtnl-lwt-MPLS:

root   881 5  0 21:25 ?00:00:00 /sbin/modprobe -q -- 
rtnl-lwt-MPLS

and it hangs after loading mpls_router:

$ cat /proc/881/stack
[] rtnl_lock+0x12/0x14
[] register_netdevice_notifier+0x16/0x179
[] mpls_init+0x25/0x1000 [mpls_router]
[] do_one_initcall+0x8e/0x13f
[] do_init_module+0x5a/0x1e5
[] load_module+0x13bd/0x17d6
...

The problem is that lwtunnel_build_state is called with rtnl lock
held preventing mpls_init from registering. Fix by dropping the
lock before invoking request_module.

Fixes: 745041e2aaf1 ("lwtunnel: autoload of lwt modules")
Signed-off-by: David Ahern 
---
This is a best guess at the Fixes.

 net/core/lwtunnel.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/core/lwtunnel.c b/net/core/lwtunnel.c
index a5d4e866ce88..c14ee4d62a8a 100644
--- a/net/core/lwtunnel.c
+++ b/net/core/lwtunnel.c
@@ -120,7 +120,9 @@ int lwtunnel_build_state(struct net_device *dev, u16 
encap_type,
 
if (encap_type_str) {
rcu_read_unlock();
+   __rtnl_unlock();
request_module("rtnl-lwt-%s", encap_type_str);
+   rtnl_lock();
rcu_read_lock();
ops = rcu_dereference(lwtun_encaps[encap_type]);
}
-- 
2.1.4

[no subject]

[Andy Lutomirski]

;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with C-x C-f and enter text in its buffer.



On Sun, Jan 15, 2017 at 5:19 PM, Tejun Heo  wrote:
> Hello,
>
> Sorry about the delay.  Some fire fighthing followed the holidays.
>
> On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote:
>> > So from what I understand the proposed cgroup is not in fact
>> > hierarchical at all.
>> >
>> > @TJ, I thought you were enforcing all new cgroups to be properly
>> > hierarchical, that would very much include this one.
>>
>> I would be interested in that as well. We have made that mistake in
>> memcg v1 where hierarchy could be disabled for performance reasons and
>> that turned out to be major PITA in the end. Why do we want to repeat
>> the same mistake here?
>
> Across the different threads on this subject, there have been multiple
> explanations but I'll try to sum it up more clearly.
>
> The big issue here is whether this is a cgroup thing or a bpf thing.
> I don't think there's anything inherently wrong with one approach or
> the other.  Forget about the proposed cgroup bpf extentions but thinkg
> about how iptables does cgroups.  Whether it's the netcls/netprio in
> v1 or direct membership matching in v2, it is the network side testing
> for cgroup membership one way or the other.  The only part where
> cgroup is involved in is answering that test.
>

[...]

>
> None of the issues that people have been raising here is actually an
> issue if one thinks of it as a part of bpf.  Its security model is
> exactly the same as any other bpf programs.  Recursive behavior is
> exactly the same as how other external cgroup descendant membership
> testing work.  There is no issue here whatsoever.

After sleeping on this, here are my thoughts:

First, there are three ways to think about this, not just two.  It
could be a BPF feature, a net feature, or a cgroup feature.

I think that calling it a BPF feature is a cop-out.  BPF is an
assembly language and a mechanism for importing little programs into
the kernel.  BPF maps are a BPF feature.  These new hooks are a
feature that actively changes the behavior of other parts of the
kernel.  I don't see how calling this new feature a "BPF" feature
excuses it from playing by the expected rules of the subsystems it
affects or from generally working well with the rest of the kernel.

Perhaps this is a net feature, though, not a cgroup feature.  This
would IMO make a certain amount of sense.  Iptables cgroup matches,
for example, logically are an iptables (i.e., net) feature.  The
problem here is that network configuration (and this explicitly
includes iptables) is done on a per-netns level, whereas these new
hooks entirely ignore network namespaces.  I've pointed out that
trying to enable them in a namespaced world is problematic (e.g.
switching to ns_capable() will cause serious problems), and Alexei
seems to think that this will never happen.  So I don't think we can
really call this a net feature that works the way that other net
features work.

(Suppose that this actually tried to be netns-enabled.  Then you'd
have to map from (netns, cgroup) -> hook, and this would probably be
slow and messy.)

So I think that leaves it being a cgroup feature.  And it definitely
does *not* play by the rules of cgroups right now.

> I'm sure we'll
> eventually get there but from what I hear it isn't something we can
> pull off in a restricted timeframe.

To me, this sounds like "the API isn't that great, we know how to do
better, but we really really want this feature ASAP so we want to ship
it with a sub-par API."  I think that's a bad idea.

> This also holds true for the perf controller.  While it is implemented
> as a controller, it isn't visible to cgroup users in any way and the
> only function it serves is providing the membership test to perf
> subsystem.  perf is the one which decides whether and how it is to be
> used.  cgroup providing membership test to other subsystems is
> completely acceptable and established.

Unless I'm mistaken, "perf_event" is an actual cgroup controller, and
it explicitly respects the cgroup hierarchy.  It shows up in
/proc/cgroups, and I had no problem mounting a cgroupfs instance with
perf_event enabled.  So I'm not sure what you mean.

Re: [PATCHv3 net-next 2/7] sctp: add support for generating stream reconf ssn reset request chunk

[Xin Long]

On Mon, Jan 16, 2017 at 11:56 AM, Xin Long  wrote:
> On Sun, Jan 15, 2017 at 11:51 PM, Marcelo Ricardo Leitner
>  wrote:
>> On Sat, Jan 14, 2017 at 03:15:36AM +0800, Xin Long wrote:
>>> This patch is to add asoc strreset_outseq and strreset_inseq for
>>> saving the reconf request sequence, initialize them when create
>>> assoc and process init, and also to define Incoming and Outgoing
>>> SSN Reset Request Parameter described in rfc6525 section 4.1 and
>>> 4.2, As they can be in one same chunk as section rfc6525 3.1-3
>>> describes, it makes them in one function.
>>>
>>> Signed-off-by: Xin Long 
>>> ---
>>>  include/linux/sctp.h   | 26 ++
>>>  include/net/sctp/sm.h  |  5 ++-
>>>  include/net/sctp/structs.h |  3 ++
>>>  net/sctp/associola.c   |  1 +
>>>  net/sctp/sm_make_chunk.c   | 88 
>>> ++
>>>  5 files changed, 122 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/sctp.h b/include/linux/sctp.h
>>> index cdc3b05..d5da19c 100644
>>> --- a/include/linux/sctp.h
>>> +++ b/include/linux/sctp.h
>>> @@ -200,6 +200,13 @@ typedef enum {
>>>   SCTP_PARAM_SUCCESS_REPORT   = cpu_to_be16(0xc005),
>>>   SCTP_PARAM_ADAPTATION_LAYER_IND = cpu_to_be16(0xc006),
>>>
>>> + /* RE-CONFIG. Section 4 */
>>> + SCTP_PARAM_RESET_OUT_REQUEST= cpu_to_be16(0x000d),
>>> + SCTP_PARAM_RESET_IN_REQUEST = cpu_to_be16(0x000e),
>>> + SCTP_PARAM_RESET_TSN_REQUEST= cpu_to_be16(0x000f),
>>> + SCTP_PARAM_RESET_RESPONSE   = cpu_to_be16(0x0010),
>>> + SCTP_PARAM_RESET_ADD_OUT_STREAMS= cpu_to_be16(0x0011),
>>> + SCTP_PARAM_RESET_ADD_IN_STREAMS = cpu_to_be16(0x0012),
>>>  } sctp_param_t; /* enum */
>>>
>>>
>>> @@ -716,4 +723,23 @@ struct sctp_reconf_chunk {
>>>   __u8 params[0];
>>>  } __packed;
>>>
>>> +struct sctp_strreset_req {
>>> + sctp_paramhdr_t param_hdr;
>>> + __u32 request_seq;
>>> +} __packed;
>>> +
>>> +struct sctp_strreset_outreq {
>>> + sctp_paramhdr_t param_hdr;
>>> + __u32 request_seq;
>>
>> This should be:
>> +   struct sctp_strreset_req strreset_req;
>> Use the definition you created above for the encapsulation and make the
>> embedding evident.
>> Like it's done for sctp_chunkhdr_t.
> I'm not sure if it's good to do it like sctp_chunkhdr_t.
>
> As sctp_chunkhdr is a very common data:
> Chunk Type  | Chunk  Flags  |  Chunk Length
> and the next must be "Chunk Value"
>
> But here sctp_strreset_req is more used to access
> the request_seq of the params in asoc->strreset_chunk
> without knowing params' type. like in sctp_chunk_lookup_strreset_param()
> and sctp_process_strreset_resp() [see it from the big patchset].
>
> struct sctp_strreset_outreq {
> sctp_paramhdr_t param_hdr;
> __u32 request_seq;
> [1]
> __u32 response_seq;
> __u32 send_reset_at_tsn;
> __u16 list_of_streams[0];
> } __packed;
>
> it seems not good to split it by [1].
> __u32 request_seq;
> __u32 response_seq;
> __u32 send_reset_at_tsn;
> __u16 list_of_streams[0];
> these should to together and equal.
>
> what do you think ?
>
Hi, Marcelo, I'm planning to drop "struct sctp_strreset_req" so
that it will not be confusing here, and only introduce it when
it's used somewhere. agreed ?

Re: [PATCH V2] audit: log 32-bit socketcalls

[Richard Guy Briggs]

On 2017-01-16 13:27, David Miller wrote:
> From: Richard Guy Briggs 
> Date: Fri, 13 Jan 2017 04:51:48 -0500
> 
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 9d4443f..43d8003 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs, unsigned 
> > long *args)
> > return __audit_socketcall(nargs, args);
> > return 0;
> >  }
> > +static inline int audit_socketcall_compat(int nargs, u32 *args)
> > +{
> 
> Please put an empty line between function definitions.

Ok, should I reformat the rest of the file while I'm at it?

> > +   if (unlikely(!audit_dummy_context())) {
> > +   int i;
> > +   unsigned long a[AUDITSC_ARGS];
> 
> Please order local variable declarations from longest to shortest line.

Ok.  Is this a recent addition to a style guide or in checkpatch.pl?

> > +
> > +   for (i=0; i 
> Please put a space around operators such as "=" and "<".

Oops, my bad...

> > +   a[i] = (unsigned long)args[i];
> > +   return __audit_socketcall(nargs, a);
> > +   }
> > +   return 0;
> > +}
> >  static inline int audit_sockaddr(int len, void *addr)
> 
> Again, empty line between function definitions please.
> 
> > @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct 
> > compat_mmsghdr __user *, mmsg,
> >  
> >  COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> >  {
> > +   unsigned int len;
> > int ret;
> > -   u32 a[6];
> > +   u32 a[AUDITSC_ARGS];
> > u32 a0, a1;
> 
> Longest to shortest line for local variable declarations please.

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCH V2] audit: log 32-bit socketcalls

[Richard Guy Briggs]

On 2017-01-16 15:04, Paul Moore wrote:
> On Fri, Jan 13, 2017 at 9:42 AM, Eric Paris  wrote:
> > On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
> >> diff --git a/include/linux/audit.h b/include/linux/audit.h
> >> index 9d4443f..43d8003 100644
> >> --- a/include/linux/audit.h
> >> +++ b/include/linux/audit.h
> >> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs,
> >> unsigned long *args)
> >>   return __audit_socketcall(nargs, args);
> >>   return 0;
> >>  }
> >> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> >> +{
> >> + if (unlikely(!audit_dummy_context())) {
> >
> > I've always hated these likely/unlikely. Mostly because I think they
> > are so often wrong. I believe this says that you compiled audit in but
> > you expect it to be explicitly disabled. While that is (recently) true
> > in Fedora I highly doubt that's true on the vast majority of systems
> > that have audit compiled in.
> 
> Richard and I have talked about the likely/unlikely optimization
> before and I know Richard likes to use them, but I don't for the
> reasons Eric has already mentioned.   Richard, since you're respinning
> the patch, go ahead and yank out the unlikely() call.

I don't "like to use them".  I'm simply following the use and style of
existing code and the arguments of others in places of critical
performance.  If I "fix" that one, then I would feel compelled to yank
out the one in the function immediately above, audit_socketcall() for
consistency to ease my conscience.  Eric conceded that argument.

> paul moore

- RGB

--
Richard Guy Briggs 
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

Re: [PATCHv3 net-next 1/7] sctp: add a common helper function to generate stream reconf chunk

[Xin Long]

On Tue, Jan 17, 2017 at 2:50 AM, David Miller  wrote:
> From: Xin Long 
> Date: Sat, 14 Jan 2017 03:15:35 +0800
>
>> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
>> index a15d824..fd58097 100644
>> --- a/net/sctp/sm_make_chunk.c
>> +++ b/net/sctp/sm_make_chunk.c
>> @@ -3526,3 +3526,36 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct 
>> sctp_association *asoc,
>>
>>   return retval;
>>  }
>> +
>> +/* RE-CONFIG 3.1 (RE-CONFIG chunk)
>> + *   0   1   2   3
>> + *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + *  | Type = 130|  Chunk Flags  |  Chunk Length |
>> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + *  \   \
>> + *  /  Re-configuration Parameter   /
>> + *  \   \
>> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + *  \   \
>> + *  / Re-configuration Parameter (optional) /
>> + *  \   \
>> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + */
>> +static struct sctp_chunk *sctp_make_reconf(
>> + const struct sctp_association *asoc,
>> + int length)
>> +{
>> + struct sctp_reconf_chunk *reconf;
>
> This patch will cause a warning because this new static function is unused.
>
> All patch series must be fully bisectable, that measn at each step of
> the patch series the tree must work properly and not introduce new
> build warnings or build failures.
sorry, will merge patch 1/7 and 2/7

Re: [PATCH] qed: Replace memset with eth_zero_addr

[Shyam Saini]

On Mon, Jan 16, 2017 at 02:58:19PM -0500, David Miller wrote:
> From: Shyam Saini 
> Date: Tue, 17 Jan 2017 00:21:38 +0530
> 
> > Use eth_zero_addr to assign zero address to the given address array
> > instead of memset when the second argument in memset is address
> > of zero. Also, it makes the code clearer
> > 
> > Signed-off-by: Shyam Saini 
> 
> This patch does not apply cleanly to the net-next tree.

I always send patches from linux-next tree and that caused this mistake

I apologize for this.

> Please state if you don't understand what that means instead of
> submitting this patch over and over again against the wrong source
> tree.

Now sent from net-next tree

Thanks a lot,
Shyam

Re: [PATCH] stmicro: rename it to dwc to improve future development

[kbuild test robot]

Hi Joao,

[auto build test WARNING on net-next/master]
[also build test WARNING on next-20170116]
[cannot apply to v4.10-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Joao-Pinto/stmicro-rename-it-to-dwc-to-improve-future-development/20170116-214440
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r 

All warnings (new ones prefixed by >>):

   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/asm-generic/bug.h:13,
from arch/m32r/include/asm/bug.h:3,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from drivers/net/ethernet/dwc/stmmac/dwmac1000_core.c:30:
   drivers/net/ethernet/dwc/stmmac/dwmac1000_core.c: In function 
'dwmac1000_dump_regs':
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
>> drivers/net/ethernet/dwc/stmmac/dwmac1000_core.c:107:3: note: in expansion 
>> of macro 'pr_info'
  pr_info("\tReg No. %d (offset 0x%x): 0x%08x\n", i,
  ^~~
--
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/dwc/stmmac/dwmac1000.h:25,
from drivers/net/ethernet/dwc/stmmac/dwmac1000_dma.c:30:
   drivers/net/ethernet/dwc/stmmac/dwmac1000_dma.c: In function 
'dwmac1000_dump_dma_regs':
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
 ^~~~
   include/linux/printk.h:292:9: note: in expansion of macro 'KERN_ERR'
 printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
>> drivers/net/ethernet/dwc/stmmac/dwmac1000_dma.c:215:4: note: in expansion of 
>> macro 'pr_err'
   pr_err("\t Reg No. %d (offset 0x%x): 0x%08x\n", i,
   ^~
--
   In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/dwc/stmmac/dwmac100.h:28,
from drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:33:
   drivers/net/ethernet/dwc/stmmac/dwmac100_core.c: In function 
'dwmac100_dump_mac_regs':
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
  ^~~~
   include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
 printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^
>> drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:53:2: note: in expansion of 
>> macro 'pr_info'
 pr_info("\tcontrol reg (offset 0x%x): 0x%08x\n", MAC_CONTROL,
 ^~~
   include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of 
type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001"  /* ASCII Start Of Header */
 ^
   include/linux/kern_levels.h:13:19:

[GIT] Networking

[David Miller]

1) Handle multicast packets properly in fast-RX path of mac80211,
   from Johannes Berg.

2) Because of a logic bug, the user can't actually force SW
   checksumming on r8152 devices.  This makes diagnosis of hw
   checksumming bugs really annoying.  Fix from Hayes Wang.

3) VXLAN route lookup does not take the source and destination ports
   into account, which means IPSEC policies cannot be matched
   properly.  Fix from Martynas Pumputis.

4) Do proper RCU locking in netvsc callbacks, from Stephen Hemminger.

5) Fix SKB leaks in mlxsw driver, from Arkadi Sharshevsky.

6) If lwtunnel_fill_encap() fails, we do not abort the netlink message
   construction properly in fib_dump_info(), from David Ahern.

7) Do not use kernel stack for DMA buffers in atusb driver, from
   Stefan Schmidt.

8) Openvswitch conntack actions need to maintain a correct checksum,
   fix from Lance Richardson.

9) ax25_disconnect() is missing a check for ax25->sk being NULL, in fact
   it already checks this, but not in all of the necessary spots.  Fix
   from Basil Gunn.

10) Action GET operations in the packet scheduler can erroneously bump
the reference count of the entry, making it unreleasable.  Fix
from Jamal Hadi Salim.  Jamal gives a great set of example command
lines that trigger this in the commit message.

Please pull, thanks a lot!

The following changes since commit ba836a6f5ab1243ff5e08a941a2d1de8b31244e1:

  Merge branch 'akpm' (patches from Andrew) (2017-01-11 11:15:15 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 0faa9cb5b3836a979864a6357e01d2046884ad52:

  net sched actions: fix refcnt when GETing of action after bind (2017-01-16 
19:43:19 -0500)


Andrey Smirnov (1):
  at86rf230: Allow slow GPIO pins for "rstn"

Arkadi Sharshevsky (2):
  mlxsw: spectrum: Fix memory leak at skb reallocation
  mlxsw: switchx2: Fix memory leak at skb reallocation

Arnd Bergmann (2):
  cpmac: remove hopeless #warning
  net/mlx5e: Fix a -Wmaybe-uninitialized warning

Basil Gunn (1):
  ax25: Fix segfault after sock connection timeout

Beni Lev (1):
  cfg80211: consider VHT opmode on station update

Cedric Izoard (1):
  mac80211: Fix headroom allocation when forwarding mesh pkt

Daniel Borkmann (1):
  bpf: rework prog_digest into prog_tag

David Ahern (2):
  net: lwtunnel: Handle lwtunnel_fill_encap failure
  net: ipv4: fix table id in getroute response

David Lebrun (1):
  ipv6: sr: fix several BUGs when preemption is enabled

David S. Miller (4):
  Merge branch 'mlxsw-fixes'
  Merge tag 'mac80211-for-davem-2017-01-13' of 
git://git.kernel.org/.../jberg/mac80211
  Merge branch 'for-upstream' of 
git://git.kernel.org/.../bluetooth/bluetooth
  Merge branch 'mlx4-core-fixes'

Elad Raz (1):
  mlxsw: pci: Fix EQE structure definition

Emmanuel Grumbach (1):
  mac80211: fix the TID on NDPs sent as EOSP carrier

Eric Dumazet (1):
  mlx4: do not call napi_schedule() without care

Felix Fietkau (1):
  mac80211: initialize SMPS field in HT capabilities

Florian Fainelli (1):
  net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim

Hangbin Liu (1):
  mld: do not remove mld souce list info when set link down

Heiner Kallweit (1):
  net: stmmac: don't use netdev_[dbg, info, ..] before net_device is 
registered

Ivan Vecera (3):
  be2net: fix status check in be_cmd_pmac_add()
  be2net: don't delete MAC on close on unprivileged BE3 VFs
  be2net: fix MAC addr setting on privileged BE3 VFs

Jack Morgenstein (3):
  net/mlx4_core: Fix racy CQ (Completion Queue) free
  net/mlx4_core: Fix when to save some qp context flags for dynamic VST to 
VGT transitions
  net/mlx4_core: Eliminate warning messages for SRQ_LIMIT under SRIOV

Jakub Sitnicki (1):
  ip6_tunnel: Account for tunnel header in tunnel MTU

Jamal Hadi Salim (1):
  net sched actions: fix refcnt when GETing of action after bind

Johannes Berg (3):
  mac80211: implement multicast forwarding on fast-RX path
  mac80211: calculate min channel width correctly
  mac80211: recalculate min channel width on VHT opmode changes

Karicheri, Muralidharan (1):
  net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types

Kazuya Mizuguchi (1):
  ravb: Remove Rx overflow log messages

Lance Richardson (1):
  openvswitch: maintain correct checksum state in conntrack actions

Martynas Pumputis (1):
  vxlan: Set ports in flow key when doing route lookups

Masaru Nagai (1):
  ravb: do not use zero-length alignment DMA descriptor

Michal Kazior (1):
  mac80211: prevent skb/txq mismatch

Parthasarathy Bhuvaragan (1):
  tipc: allocate user memory with GFP_KERNEL flag

Shannon Nelson (1):
  tcp: fix tcp_fastopen unaligned access complaints on sparc

Stefan Schmidt (4):
 

Re: fq_codel and skb->hash

[Eric Dumazet]

On Mon, 2017-01-16 at 17:44 -0800, Eric Dumazet wrote:
> On Mon, 2017-01-16 at 17:04 -0700, Andrew Collins wrote:

> >   Is there a better way to manage flow separation in routed+encapsulated 
> > traffic?
> 
> Encapsulated traffic is fine, since flow dissector skips encap header(s)
> up to the L4 header.
> 
> Problem is about encrypted traffic, since presumably this L4 header is
> opaque for flow dissector ;)


BTW, how can we make sure skb->hash is populated before IPSEC ?

Relying on forwarding, and skb->hash set by a device might be not
enough.

[PATCH net-next 1/1] net: ping: Use right format specifier to avoid type casting

[fgao]

From: Gao Feng 

The inet_num is u16, so use %hu instead of casting it to int. And
the sk_bound_dev_if is int actually, so it needn't cast to int.

Signed-off-by: Gao Feng 
---
 net/ipv4/ping.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 86cca61..592db6a 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -433,9 +433,9 @@ int ping_bind(struct sock *sk, struct sockaddr *uaddr, int 
addr_len)
goto out;
}
 
-   pr_debug("after bind(): num = %d, dif = %d\n",
-(int)isk->inet_num,
-(int)sk->sk_bound_dev_if);
+   pr_debug("after bind(): num = %hu, dif = %d\n",
+isk->inet_num,
+sk->sk_bound_dev_if);
 
err = 0;
if (sk->sk_family == AF_INET && isk->inet_rcv_saddr)
-- 
1.9.1

[PATCH] qed: Replace memset with eth_zero_addr

[Shyam Saini]

Use eth_zero_addr to assign zero address to the given address array
instead of memset when the second argument in memset is address
of zero. Also, it makes the code clearer

Signed-off-by: Shyam Saini 
---
 drivers/net/ethernet/qlogic/qed/qed_l2.c| 2 +-
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 7 +++
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c 
b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index c92a850..7520eb3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1846,7 +1846,7 @@ static int qed_fill_eth_dev_info(struct qed_dev *cdev,
qed_fill_dev_info(cdev, >common);
 
if (IS_VF(cdev))
-   memset(info->common.hw_mac, 0, ETH_ALEN);
+   eth_zero_addr(info->common.hw_mac);
 
return 0;
 }
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index b121364..3f4bf31 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -1224,7 +1224,7 @@ static void qed_iov_clean_vf(struct qed_hwfn *p_hwfn, u8 
vfid)
return;
 
/* Clear the VF mac */
-   memset(vf_info->mac, 0, ETH_ALEN);
+   eth_zero_addr(vf_info->mac);
 
vf_info->rx_accept_mode = 0;
vf_info->tx_accept_mode = 0;
@@ -2626,8 +2626,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn 
*p_hwfn,
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++) {
if (ether_addr_equal(p_vf->shadow_config.macs[i],
 p_params->mac)) {
-   memset(p_vf->shadow_config.macs[i], 0,
-  ETH_ALEN);
+   eth_zero_addr(p_vf->shadow_config.macs[i]);
break;
}
}
@@ -2640,7 +2639,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn 
*p_hwfn,
} else if (p_params->opcode == QED_FILTER_REPLACE ||
   p_params->opcode == QED_FILTER_FLUSH) {
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++)
-   memset(p_vf->shadow_config.macs[i], 0, ETH_ALEN);
+   eth_zero_addr(p_vf->shadow_config.macs[i]);
}
 
/* List the new MAC address */
-- 
2.7.4

Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route

[David Ahern]

On 1/16/17 5:51 PM, David Miller wrote:
> From: David Ahern 
> Date: Sun, 15 Jan 2017 12:07:04 -0800
> 
>> @@ -2143,6 +2143,26 @@ int ip6_del_rt(struct rt6_info *rt)
>>  return __ip6_del_rt(rt, );
>>  }
>>  
>> +/* called with table lock held */
>  ...
>> @@ -2176,10 +2196,9 @@ static int ip6_route_del(struct fib6_config *cfg)
>>  continue;
>>  if (cfg->fc_protocol && cfg->fc_protocol != 
>> rt->rt6i_protocol)
>>  continue;
>> -dst_hold(>dst);
>> -read_unlock_bh(>tb6_lock);
>>  
>> -return __ip6_del_rt(rt, >fc_nlinfo);
>> +err = __ip6_route_del(rt, cfg);
>> +break;
>>  }
> 
> fib6_del() (invoked by __ip6_route_del()) has to be invoked with the
> table lock held a sa writer, but here you are only holding it as a
> reader.

That table lock is still held. If you look up 2 lines I remove the line that 
releases the lock.

> 
> I also think some more thought has to be put into whether we can
> change behavior like this without using a flag, as suggested by Roopa.
> 

I'm all for changing the behavior by default, but AIUI that breaks the golden 
rule.

libnl as of libnl3_2_16-16-g29b71371e764  (a patch by Roopa) already handles 
both flavors -- if RTA_MULTIPATH is sent it handles it fine and if a series of 
routes are sent they are consolidated to 1 object with next hops.

iproute2 can handle it just fine as well. I made no changes to get the display 
format consistent. The problem here is scripts that rely on the old format.

quagga does *not* correctly handle the RTA_MULTIPATH attribute for IPv6 but 
then it does not properly handle IPv6 multipath routes it receives from the 
kernel at all. Same result with current kernel code or with this patch set - 
only the last nexthop is retained. (quagga routes pushed to kernel works, but 
kernel routes fed to quagga does not)

--

Notifications are still single route based. There is no user input to handle 
backwards compatibility in converting those to RTA_MULTIPATH. A global sysctl 
is the only real option I guess.


Anyways, I am open to either; just looking to further close the ipv4 / ipv6 gap.

Re: fq_codel and skb->hash

[Eric Dumazet]

On Mon, 2017-01-16 at 17:04 -0700, Andrew Collins wrote:
> The fq_codel packet scheduler always regenerates the skb flow hash.  Is there 
> any reason
> to do this other than the recent hash perturbation additions?
> 
> I ask because I have a case where an incoming set of TCP flows is 
> encapsulated in a
> single ipsec tunnel, which is then classified on egress into a single flow by 
> fq_codel
> resulting in poor behavior.
> 
> Reusing the skb hash set in receive results in much better behavior, as the 
> value is
> determined pre-encapsulation and flows end up being distributed more 
> naturally across
> codel queues.



> 
> Is opportunistically using the pre-existing skb hash (if available) 
> problematic?

I guess this would be fine.

We never exported the 'perturbation' or allowed to change/set it.

The only 'risk' would be having a buggy device setting a wrong L4
skb->hash, or buggy protocol messing with skb->hash for a given flow.

>   Is there a better way to manage flow separation in routed+encapsulated 
> traffic?

Encapsulated traffic is fine, since flow dissector skips encap header(s)
up to the L4 header.

Problem is about encrypted traffic, since presumably this L4 header is
opaque for flow dissector ;)

Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route

[David Ahern]

On 1/16/17 6:37 PM, David Miller wrote:
> Is it clear now?

yes. time for a trip to the eye doctor

Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route

[David Miller]

From: David Ahern 
Date: Mon, 16 Jan 2017 18:27:36 -0700

> On 1/16/17 5:51 PM, David Miller wrote:
>> From: David Ahern 
>> Date: Sun, 15 Jan 2017 12:07:04 -0800
>> 
>>> @@ -2143,6 +2143,26 @@ int ip6_del_rt(struct rt6_info *rt)
>>> return __ip6_del_rt(rt, );
>>>  }
>>>  
>>> +/* called with table lock held */
>>  ...
>>> @@ -2176,10 +2196,9 @@ static int ip6_route_del(struct fib6_config *cfg)
>>> continue;
>>> if (cfg->fc_protocol && cfg->fc_protocol != 
>>> rt->rt6i_protocol)
>>> continue;
>>> -   dst_hold(>dst);
>>> -   read_unlock_bh(>tb6_lock);
>>>  
>>> -   return __ip6_del_rt(rt, >fc_nlinfo);
>>> +   err = __ip6_route_del(rt, cfg);
>>> +   break;
>>> }
>> 
>> fib6_del() (invoked by __ip6_route_del()) has to be invoked with the
>> table lock held a sa writer, but here you are only holding it as a
>> reader.
> 
> That table lock is still held. If you look up 2 lines I remove the line that 
> releases the lock.

It's held in this function as a reader, it needs to be held as a writer.

That's why the lock is dropped in the current code and the existing
wrapper around fib6_del() takes it as a writer.

Is it clear now?

read_lock_bh(>lock);
fib6_del();

is invalid.

write_lock_bh(>lock);
fib6_del();

is required.

Re: [PATCH v2 net-next 0/2] mvneta xmit_more and bql support

[David Miller]

From: Marcin Wojtas 
Date: Mon, 16 Jan 2017 18:08:30 +0100

> This is a delayed v2 of short patchset, which introduces xmit_more and BQL
> to mvneta driver. The only one change was added in xmit_more support -
> condition check preventing excessive descriptors concatenation before
> flushing in HW.
> 
> Any comments or feedback would be welcome.
 ...
> Changelog:
> v1 -> v2:
> 
> * Add checking condition that ensures too much descriptors are not
>   concatenated before flushing in HW.

Looks good, series applied, thanks.

Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route

[David Miller]

From: David Ahern 
Date: Sun, 15 Jan 2017 12:07:04 -0800

> @@ -2143,6 +2143,26 @@ int ip6_del_rt(struct rt6_info *rt)
>   return __ip6_del_rt(rt, );
>  }
>  
> +/* called with table lock held */
 ...
> @@ -2176,10 +2196,9 @@ static int ip6_route_del(struct fib6_config *cfg)
>   continue;
>   if (cfg->fc_protocol && cfg->fc_protocol != 
> rt->rt6i_protocol)
>   continue;
> - dst_hold(>dst);
> - read_unlock_bh(>tb6_lock);
>  
> - return __ip6_del_rt(rt, >fc_nlinfo);
> + err = __ip6_route_del(rt, cfg);
> + break;
>   }

fib6_del() (invoked by __ip6_route_del()) has to be invoked with the
table lock held a sa writer, but here you are only holding it as a
reader.

I also think some more thought has to be put into whether we can
change behavior like this without using a flag, as suggested by Roopa.

Re: [PATCH net 1/1] net sched actions: fix refcnt when GETing of action after bind

[David Miller]

From: Jamal Hadi Salim 
Date: Sun, 15 Jan 2017 10:14:06 -0500

> From: Jamal Hadi Salim 
 ...
> Fixes: aecc5cefc389 ("net sched actions: fix GETing actions")
> Signed-off-by: Jamal Hadi Salim 

Applied and queued up for -stable, thanks Jamal.

RE: [PATCH] net: add regs attribute to phy device for user diagnose

[YUAN Linyu]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, January 17, 2017 5:54 AM
> To: f.faine...@gmail.com
> Cc: cug...@163.com; and...@lunn.ch; netdev@vger.kernel.org; YUAN Linyu
> Subject: Re: [PATCH] net: add regs attribute to phy device for user diagnose
> 
> From: Florian Fainelli 
> Date: Mon, 16 Jan 2017 12:22:16 -0800
> 
> >
> > So why not add support in ethtool for reading PHY registers if you need
> > it? There are handful of PHY "things" in ethtool, such as reading
> > counters, configuring downshift etc., adding support for dumping
> > registers does not sound out of space.
Thanks, I will try this direction.
> 
> Agreed.

fq_codel and skb->hash

[Andrew Collins]

The fq_codel packet scheduler always regenerates the skb flow hash.  Is there 
any reason
to do this other than the recent hash perturbation additions?

I ask because I have a case where an incoming set of TCP flows is encapsulated 
in a
single ipsec tunnel, which is then classified on egress into a single flow by 
fq_codel
resulting in poor behavior.

Reusing the skb hash set in receive results in much better behavior, as the 
value is
determined pre-encapsulation and flows end up being distributed more naturally 
across
codel queues.

Is opportunistically using the pre-existing skb hash (if available) 
problematic?  Is
there a better way to manage flow separation in routed+encapsulated traffic?

Thanks,
Andrew Collins

[PATCH 1/1] ip: fix igmp parsing when iface is long

[Petr Vorel]

Entries with long vhost names in /proc/net/igmp have no whitespace
between name and colon, so sscanf() adds it to vhost and
'ip maddr show iface' doesn't include inet result.

Signed-off-by: Petr Vorel 
---
 ip/ipmaddr.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ip/ipmaddr.c b/ip/ipmaddr.c
index 22eb407..4f726fd 100644
--- a/ip/ipmaddr.c
+++ b/ip/ipmaddr.c
@@ -136,13 +136,17 @@ static void read_igmp(struct ma_info **result_p)
 
while (fgets(buf, sizeof(buf), fp)) {
struct ma_info *ma;
+   size_t len;
 
if (buf[0] != '\t') {
sscanf(buf, "%d%s", , m.name);
+   len = strlen(m.name);
+   if (m.name[len - 1] == ':')
+   len--;
continue;
}
 
-   if (filter.dev && strcmp(filter.dev, m.name))
+   if (filter.dev && strncmp(filter.dev, m.name, len))
continue;
 
sscanf(buf, "%08x%d", (__u32 *), );
-- 
2.11.0

[PATCH net] vxlan: fix byte order of vxlan-gpe port number

[Lance Richardson]

vxlan->cfg.dst_port is in network byte order, so an htons()
is needed here. Also reduced comment length to stay closer
to 80 column width (still slightly over, however).

Fixes: e1e5314de08b ("vxlan: implement GPE")
Signed-off-by: Lance Richardson 
---
 drivers/net/vxlan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca7196c..8a79cfc 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2890,7 +2890,7 @@ static int vxlan_dev_configure(struct net *src_net, 
struct net_device *dev,
memcpy(>cfg, conf, sizeof(*conf));
if (!vxlan->cfg.dst_port) {
if (conf->flags & VXLAN_F_GPE)
-   vxlan->cfg.dst_port = 4790; /* IANA assigned VXLAN-GPE 
port */
+   vxlan->cfg.dst_port = htons(4790); /* IANA VXLAN-GPE 
port */
else
vxlan->cfg.dst_port = default_port;
}
-- 
2.5.5

Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout

[Saeed Mahameed]

On Mon, Jan 16, 2017 at 11:06 PM, Tom Herbert  wrote:
> On Mon, Jan 16, 2017 at 12:30 PM, Saeed Mahameed
>  wrote:
>> On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
>>  wrote:
>>> On Fri, Jan 13, 2017 at 7:14 PM, David Miller  wrote:
 From: Saeed Mahameed 
 Date: Thu, 12 Jan 2017 19:22:34 +0200

> This pull request includes one patch from Leon, this patch as described
> below will change the driver directory structure and layout for better,
> logical and modular driver files separation.
>
> This change is important to both rdma and net maintainers in order to
> have smoother management of driver patches for different mlx5 sub modules
> and smoother rdma-next vs. net-next features submissions.
>
> Please find more info below -in the tag commit message-,
> review and let us know if there's any problem.
>
> This change doesn't introduce any conflicts with the current mlx5
> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
> worked flawlessly with no issues.
>
> This is the last pull request meant for both rdma-next and net-next.
> Once pulled, this will be the base shared code for both trees.

 This is pretty crazy, it will make all bug fix backporting to -stable
 a complete nightmare for myself, Doug, various distribution maintainers
 and many other people who quietly have to maintain their own trees and
 do backporting.

>>>
>>> I hear you,
>>> But please bear with me here, what if we queue this patch up to -stable ? 
>>> and we
>>> (Mellanox) and specifically our dedicated inbox team, will make sure
>>> that this patch
>>> will land on the various distributions and for those maintaining their
>>> own trees.
>>> This patch is really straight forward (rename files) and I already
>>> tried to cherry-pick it
>>> on older kernels, I only got a couple of conflicts on some of the
>>> "#inlcude" lines we've
>>> changed, and they are pretty straightforward to fix, we can even avoid
>>> this if we decide to
>>> not move mlx5 header files in this phase.
>>>
>>> If this is possible then all trees will be aligned and it will be a
>>> win win situation.
>>>
>>
>> Hi Dave,
>>
>> Any chance you saw my -stable suggestion above ?
>> I think it would really close the backporting gap.
>>
>> Sorry i am bothering you with this topic, but we really desire the new
>> structure and
>> I never got your feedback on this suggestion, so i would like to hear
>> your thoughts.
>>
> Saeed,
>
> I've already you specific suggestions on your new structure, please
> consider your reviewers feedback more carefully. Again, the starting

I know, sorry i didn't respond on time, I though Leno's response was sufficient.

> point for your restructuring should be to separate out the minimum set
> of files required to build reasonable driver and then cleanly
> compartmentalize the rest of the features to make it easy for your
> users to include or not include those in their build. Unless you've

I see your point and i am 100% with you on this, we are all on the
same page here,
we all want to achieve the same goal -modular break down and features
logic separation-.

And in order to achieve this we need to do some big steps.
some of them will have real benefits and others are just moving code around.

One thing I need to point out (that Leon already mentioned) that the
current driver files sitting flat
in mlx5/core directory can be categorized to 4 categories
1. core related & init flows
2. common (infinband/ethernet resource management API)
3. infiniband related logic and FW commands
4. ethernet related logic and FW commands

so we figured that first we should split the bigger chunks (ethernet
vs. inifniband) into their own directories.
then i can follow up with ethernet features break down and kconfig separation.

> done this I'm not seeing much benefit for this restructuring. Also, I
> would rather see this done in one shot then expecting some sort of
> evolution over time to the right solution-- as Dave said the
> complexity of this driver is to far down the road to do that.
>

Well, I also prefer to do this in one shot, but I don't want to start
wasting time doing such a huge change
then get a NACK on submission.

Let's assume we did this in one shot i.e:
1. restructure  files and directories
2. re-arrange code (separate logic)
3. Kconfig features control - to show the immediate benefit of this change

If this is acceptable by you and we get Dave's blessing on this then i
would be happy to provide (as this is our
long term plan), but if Dave doesn't approve, then ... I don't really know.

Also for 1. backporting is really easy since such patch can be applied
easily to any kernel release back to 4.4.
but 2. and 3. are really tricky ones.

> Tom
>
>> Thanks,
>> Saeed.
>>
 I really don't think you can 

[PATCH net-next] bridge: sparse fixes in br_ip6_multicast_alloc_query()

[Lance Richardson]

Changed type of csum field in struct igmpv3_query from __be16 to
__sum16 to eliminate type warning, made same change in struct
igmpv3_report for consistency.

Fixed up an ntohs() where htons() should have been used instead.

Signed-off-by: Lance Richardson 
---
 include/uapi/linux/igmp.h | 4 ++--
 net/bridge/br_multicast.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/igmp.h b/include/uapi/linux/igmp.h
index ccbb32a..a97f9a7 100644
--- a/include/uapi/linux/igmp.h
+++ b/include/uapi/linux/igmp.h
@@ -53,7 +53,7 @@ struct igmpv3_grec {
 struct igmpv3_report {
__u8 type;
__u8 resv1;
-   __be16 csum;
+   __sum16 csum;
__be16 resv2;
__be16 ngrec;
struct igmpv3_grec grec[0];
@@ -62,7 +62,7 @@ struct igmpv3_report {
 struct igmpv3_query {
__u8 type;
__u8 code;
-   __be16 csum;
+   __sum16 csum;
__be32 group;
 #if defined(__LITTLE_ENDIAN_BITFIELD)
__u8 qrv:3,
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b30e77e..f6634612 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -540,7 +540,7 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct 
net_bridge *br,
break;
case 2:
mld2q = (struct mld2_query *)icmp6_hdr(skb);
-   mld2q->mld2q_mrc = ntohs((u16)jiffies_to_msecs(interval));
+   mld2q->mld2q_mrc = htons((u16)jiffies_to_msecs(interval));
mld2q->mld2q_type = ICMPV6_MGM_QUERY;
mld2q->mld2q_code = 0;
mld2q->mld2q_cksum = 0;
-- 
2.5.5

RE: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool

[Ariel Levkovich]

+   MLX4_PTYS_AN_DISABLE_CAP   = 1 << 5,

It's there.

Best Regards,

Ariel Levkovich
Staff Engineer, SW
Mellanox Technologies
Beit Mellanox, Yokneam, P.O.Box 586, Israel 20692 
Office: +972-74723-7652, Mobile: +972-52-3947-704 
www.mellanox.com 
Follow us on Facebook and Twitter

> -Original Message-
> From: Or Gerlitz [mailto:gerlitz...@gmail.com]
> Sent: Monday, January 16, 2017 4:48 PM
> To: Tariq Toukan ; Ariel Levkovich
> 
> Cc: David S. Miller ; Linux Netdev List
> ; Eran Ben Elisha 
> Subject: Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning
> off link autonegotiation via ethtool
> 
> On Mon, Jan 16, 2017 at 7:30 PM, Tariq Toukan 
> wrote:
> 0644
> > --- a/include/linux/mlx4/device.h
> > +++ b/include/linux/mlx4/device.h
> > @@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
> > MLX4_PTYS_EN = 1<<2,
> >  };
> >
> > +enum mlx4_ptys_flags {
> > +   MLX4_PTYS_AN_DISABLE_CAP   = 1 << 5,
> > +   MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6, };
> > +
> >  struct mlx4_ptys_reg {
> > -   u8 resrvd1;
> > +   u8 flags;
> > u8 local_port;
> > u8 resrvd2;
> > u8 proto_mask;
> 
> Hi Ariel,
> 
> I didn't see any new dev cap bit, what happens with FW version which don't
> support this, is the result well defined? what is it?
> 
> Or.

Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs

[Daniel Jurgens]

On 1/16/2017 3:59 PM, Or Gerlitz wrote:
> On Mon, Jan 16, 2017 at 11:54 PM, Daniel Jurgens  wrote:
>> On 1/16/2017 3:44 PM, Or Gerlitz wrote:
>>> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan  wrote:
 From: Daniel Jurgens 

 Use CPUs on the close NUMA when setting the EQ affinity hints.
>>> Dan, are we sure there are no down-sides for always doing this? this
>>> code is probably there for many years and we're introducing here new
>>> behaviour to potentially to many Ms installs when they get distro
>>> update that includes this patch.
>
>> I don't see a downside, this just favors using the node local CPUs before 
>> others.
> OK, so this just favors before others and not limits (not in front of
> the code now)? would be good to improve the change log and make this
> clear.
Right, doesn't limit.  Just favors the local node.  I can work with Tariq to 
update the commit message if you think it necessary.

Re: [patch net-next] stmmac: indent an if statement

[Julia Lawall]

On Tue, 17 Jan 2017, Dan Carpenter wrote:

> On Mon, Jan 16, 2017 at 10:46:22PM +0100, Julia Lawall wrote:
> >
> >
> > On Mon, 16 Jan 2017, Dan Carpenter wrote:
> >
> > > On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > > > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > > > From: Dan Carpenter 
> > > > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > > > >
> > > > > > The break statement should be indented one more tab.
> > > > > >
> > > > > > Signed-off-by: Dan Carpenter 
> > > > >
> > > > > Applied, but like Julia I think we might have a missing of_node_put()
> > > > > here.
> > > >
> > > > Of course, sorry for dropping the ball on this.  I'll send a patch for
> > > > that.
> > > >
> > >
> > > Actually, I've looked at it some more and I think this function is OK.
> > > We're supposed to do an of_node_put() later...  I can't find where that
> > > happens, but presumably that's because I don't know stmmac well.  This
> > > code here, though, is fine.
> >
> > Why do you think it is fine?  Does anyone in the calling context know
> > which child would have caused the break?
>
> Yeah.  It's saved in plat->mdio_node and we expect to be holding on
> either path through the function.
>
> (It would be better if one of the stmmac people were responding here
> insead of a random fix the indenting weenie like myself.)

OK, I agree that there should not be an of_node_put with the break.

Perhaps there should be an of_node_put on plat->mdio_node in
stmmac_remove_config_dt, like there is an of_node_put on plat->phy_node.
But it would certainly be helpful to hear from someone who knows the code
better.

julia

Re: [patch net-next] stmmac: indent an if statement

[David Miller]

From: Dan Carpenter 
Date: Tue, 17 Jan 2017 00:56:15 +0300

> (It would be better if one of the stmmac people were responding here
> insead of a random fix the indenting weenie like myself.)

They are all too busy trying to rename the driver, because that's so
much more important.

Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs

[Or Gerlitz]

On Mon, Jan 16, 2017 at 11:54 PM, Daniel Jurgens  wrote:
> On 1/16/2017 3:44 PM, Or Gerlitz wrote:
>> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan  wrote:
>>> From: Daniel Jurgens 
>>>
>>> Use CPUs on the close NUMA when setting the EQ affinity hints.
>> Dan, are we sure there are no down-sides for always doing this? this
>> code is probably there for many years and we're introducing here new
>> behaviour to potentially to many Ms installs when they get distro
>> update that includes this patch.


> I don't see a downside, this just favors using the node local CPUs before 
> others.

OK, so this just favors before others and not limits (not in front of
the code now)? would be good to improve the change log and make this
clear.

> I don't understand your 2nd sentence there.  "Ms installs"?

Millions of installs that run Linux driver.

Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs

[David Miller]

From: Daniel Jurgens 
Date: Mon, 16 Jan 2017 21:54:36 +

> I don't understand your 2nd sentence there.  "Ms installs"?

I think he meant "Mellanox's installs", meaning installations of Linux
using Mellanox hardware.  At least that's how I read it.

Re: [PATCH 1/2] qed: Add support for hardware offloaded FCoE.

[David Miller]

From: Chad Dupuis 
Date: Mon, 16 Jan 2017 16:47:52 -0500

> I forgot to add netdev-next to the subject line.  Is a repost needed
> here?

Not this time, no.

Re: [patch net-next] stmmac: indent an if statement

[Dan Carpenter]

On Mon, Jan 16, 2017 at 10:46:22PM +0100, Julia Lawall wrote:
> 
> 
> On Mon, 16 Jan 2017, Dan Carpenter wrote:
> 
> > On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > > From: Dan Carpenter 
> > > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > > >
> > > > > The break statement should be indented one more tab.
> > > > >
> > > > > Signed-off-by: Dan Carpenter 
> > > >
> > > > Applied, but like Julia I think we might have a missing of_node_put()
> > > > here.
> > >
> > > Of course, sorry for dropping the ball on this.  I'll send a patch for
> > > that.
> > >
> >
> > Actually, I've looked at it some more and I think this function is OK.
> > We're supposed to do an of_node_put() later...  I can't find where that
> > happens, but presumably that's because I don't know stmmac well.  This
> > code here, though, is fine.
> 
> Why do you think it is fine?  Does anyone in the calling context know
> which child would have caused the break?

Yeah.  It's saved in plat->mdio_node and we expect to be holding on
either path through the function.

(It would be better if one of the stmmac people were responding here
insead of a random fix the indenting weenie like myself.)

regards,
dan caprenter

Re: [PATCH V2] audit: log 32-bit socketcalls

[David Miller]

From: Paul Moore 
Date: Mon, 16 Jan 2017 15:38:33 -0500

> David, assuming Richard makes your requested changes, any objection if
> I merge this via the audit tree instead of the netdev tree?  It's a
> bit easier for us from a testing perspective this way ...

No objection.

Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs

[Daniel Jurgens]

On 1/16/2017 3:44 PM, Or Gerlitz wrote:
> On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan  wrote:
>> From: Daniel Jurgens 
>>
>> Use CPUs on the close NUMA when setting the EQ affinity hints.
> Dan, are we sure there are no down-sides for always doing this? this
> code is probably there for many years and we're introducing here new
> behaviour to potentially to many Ms installs when they get distro
> update that includes this patch.
>
I don't see a downside, this just favors using the node local CPUs before 
others.  I don't understand your 2nd sentence there.  "Ms installs"?

Re: [net-next 0/3] tipc: improve interaction socket-link

[David Miller]

From: Jon Maloy 
Date: Mon, 16 Jan 2017 20:35:08 +

> 
> 
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
>> On Behalf Of David Miller
>> Sent: Monday, 16 January, 2017 14:45
>> To: Jon Maloy 
>> Cc: netdev@vger.kernel.org; v...@zeniv.linux.org.uk; Parthasarathy Bhuvaragan
>> ; Ying Xue
>> ; ma...@donjonn.com; tipc-
>> discuss...@lists.sourceforge.net
>> Subject: Re: [net-next 0/3] tipc: improve interaction socket-link
>> 
>> From: Jon Maloy 
>> Date: Tue,  3 Jan 2017 10:26:45 -0500
>> 
>> > We fix a very real starvation problem that may occur when a link
>> > encounters send buffer congestion. At the same time we make the
>> > interaction between the socket and link layer simpler and more
>> > consistent.
>> 
>> This doesn't apply to net-next, also the Date in your emails is 10 days
>> in the past.  What's going on here?
> 
> I don't know. This series was sent in on Jan 3rd, and applied by you the same 
> day. Maybe the mail server decided to send you a duplicate?

If you look in the headers, they have "Received-by: " fields with
January 13th in the date.  So something pushed them out again.

Really strange...

Re: [PATCH] net: add regs attribute to phy device for user diagnose

[David Miller]

From: Florian Fainelli 
Date: Mon, 16 Jan 2017 12:22:16 -0800

> On 01/16/2017 04:59 AM, yuan linyu wrote:
>> On 日, 2017-01-15 at 18:21 +0100, Andrew Lunn wrote:
>>> On Sun, Jan 15, 2017 at 09:51:03AM +0800, yuan linyu wrote:
  
 I hope user/developer can read this attribute file "regs" to do
 a full check of all registers value, and they can write any register
 inside PHY through this file.
>>> Since this is intended for debug, it should not be sysfs, but debugfs.
>> agree,
>>> However, in general, Linux does not allow user space to peek and poke
>>> device registers. Can you point me at examples where i can do the same
>>> to my GPU? SATA controller? Ethernet controller, I2C temperature
>>> sensor? Any device?
>> we can read registers of ethernet controller(memory register accessed) 
>> through devmem or ethtool
> 
> So why not add support in ethtool for reading PHY registers if you need
> it? There are handful of PHY "things" in ethtool, such as reading
> counters, configuring downshift etc., adding support for dumping
> registers does not sound out of space.

Agreed.

Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool

[Or Gerlitz]

On Mon, Jan 16, 2017 at 7:30 PM, Tariq Toukan  wrote:
0644
> --- a/include/linux/mlx4/device.h
> +++ b/include/linux/mlx4/device.h
> @@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
> MLX4_PTYS_EN = 1<<2,
>  };
>
> +enum mlx4_ptys_flags {
> +   MLX4_PTYS_AN_DISABLE_CAP   = 1 << 5,
> +   MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6,
> +};
> +
>  struct mlx4_ptys_reg {
> -   u8 resrvd1;
> +   u8 flags;
> u8 local_port;
> u8 resrvd2;
> u8 proto_mask;

Hi Ariel,

I didn't see any new dev cap bit, what happens with FW version which
don't support this, is the result well defined? what is it?

Or.

Re: [PATCH 1/2] qed: Add support for hardware offloaded FCoE.

[Chad Dupuis]

I forgot to add netdev-next to the subject line.  Is a repost needed here?

On Mon, 16 Jan 2017, 7:53pm -, Dupuis, Chad wrote:

> From: Arun Easi 
> 
> This adds the backbone required for the various HW initalizations
> which are necessary for the FCoE driver (qedf) for QLogic FastLinQ
> 4 line of adapters - FW notification, resource initializations, etc.
> 
> Signed-off-by: Arun Easi 
> Signed-off-by: Yuval Mintz 
> ---
>  drivers/net/ethernet/qlogic/Kconfig   |   3 +
>  drivers/net/ethernet/qlogic/qed/Makefile  |   1 +
>  drivers/net/ethernet/qlogic/qed/qed.h |  11 +
>  drivers/net/ethernet/qlogic/qed/qed_cxt.c |  98 ++-
>  drivers/net/ethernet/qlogic/qed/qed_cxt.h |   3 +
>  drivers/net/ethernet/qlogic/qed/qed_dcbx.c|  11 +
>  drivers/net/ethernet/qlogic/qed/qed_dcbx.h|   1 +
>  drivers/net/ethernet/qlogic/qed/qed_dev.c | 205 -
>  drivers/net/ethernet/qlogic/qed/qed_dev_api.h |  42 +
>  drivers/net/ethernet/qlogic/qed/qed_fcoe.c| 990 
> ++
>  drivers/net/ethernet/qlogic/qed/qed_fcoe.h|  52 ++
>  drivers/net/ethernet/qlogic/qed/qed_hsi.h | 781 -
>  drivers/net/ethernet/qlogic/qed/qed_hw.c  |   3 +
>  drivers/net/ethernet/qlogic/qed/qed_ll2.c |  25 +
>  drivers/net/ethernet/qlogic/qed/qed_ll2.h |   2 +-
>  drivers/net/ethernet/qlogic/qed/qed_main.c|   7 +
>  drivers/net/ethernet/qlogic/qed/qed_mcp.c |   3 +
>  drivers/net/ethernet/qlogic/qed/qed_mcp.h |   1 +
>  drivers/net/ethernet/qlogic/qed/qed_reg_addr.h|   8 +
>  drivers/net/ethernet/qlogic/qed/qed_sp.h  |   4 +
>  drivers/net/ethernet/qlogic/qed/qed_sp_commands.c |   3 +
>  include/linux/qed/common_hsi.h|  10 +-
>  include/linux/qed/fcoe_common.h   | 715 
>  include/linux/qed/qed_fcoe_if.h   | 145 
>  include/linux/qed/qed_if.h|  39 +
>  25 files changed, 3152 insertions(+), 11 deletions(-)
>  create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.c
>  create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.h
>  create mode 100644 include/linux/qed/fcoe_common.h
>  create mode 100644 include/linux/qed/qed_fcoe_if.h
> 

[PATCH v2] net: marvell: skge: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

The callback set_link_ksettings no longer update the value
of advertising, as the struct ethtool_link_ksettings is
defined as const.

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
Changelog:
v2:
- update the commit log with a note to explain that this code
  was not tested on hardware (feedback from Stephen Hemminger)

 drivers/net/ethernet/marvell/skge.c |   63 --
 1 files changed, 37 insertions(+), 26 deletions(-)

diff --git a/drivers/net/ethernet/marvell/skge.c 
b/drivers/net/ethernet/marvell/skge.c
index 9146a51..81106b7 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -300,65 +300,76 @@ static u32 skge_supported_modes(const struct skge_hw *hw)
return supported;
 }
 
-static int skge_get_settings(struct net_device *dev,
-struct ethtool_cmd *ecmd)
+static int skge_get_link_ksettings(struct net_device *dev,
+  struct ethtool_link_ksettings *cmd)
 {
struct skge_port *skge = netdev_priv(dev);
struct skge_hw *hw = skge->hw;
+   u32 supported, advertising;
 
-   ecmd->transceiver = XCVR_INTERNAL;
-   ecmd->supported = skge_supported_modes(hw);
+   supported = skge_supported_modes(hw);
 
if (hw->copper) {
-   ecmd->port = PORT_TP;
-   ecmd->phy_address = hw->phy_addr;
+   cmd->base.port = PORT_TP;
+   cmd->base.phy_address = hw->phy_addr;
} else
-   ecmd->port = PORT_FIBRE;
+   cmd->base.port = PORT_FIBRE;
+
+   advertising = skge->advertising;
+   cmd->base.autoneg = skge->autoneg;
+   cmd->base.speed = skge->speed;
+   cmd->base.duplex = skge->duplex;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.advertising,
+   advertising);
 
-   ecmd->advertising = skge->advertising;
-   ecmd->autoneg = skge->autoneg;
-   ethtool_cmd_speed_set(ecmd, skge->speed);
-   ecmd->duplex = skge->duplex;
return 0;
 }
 
-static int skge_set_settings(struct net_device *dev, struct ethtool_cmd *ecmd)
+static int skge_set_link_ksettings(struct net_device *dev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct skge_port *skge = netdev_priv(dev);
const struct skge_hw *hw = skge->hw;
u32 supported = skge_supported_modes(hw);
int err = 0;
+   u32 advertising;
+
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.advertising);
 
-   if (ecmd->autoneg == AUTONEG_ENABLE) {
-   ecmd->advertising = supported;
+   if (cmd->base.autoneg == AUTONEG_ENABLE) {
+   advertising = supported;
skge->duplex = -1;
skge->speed = -1;
} else {
u32 setting;
-   u32 speed = ethtool_cmd_speed(ecmd);
+   u32 speed = cmd->base.speed;
 
switch (speed) {
case SPEED_1000:
-   if (ecmd->duplex == DUPLEX_FULL)
+   if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_1000baseT_Full;
-   else if (ecmd->duplex == DUPLEX_HALF)
+   else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_1000baseT_Half;
else
return -EINVAL;
break;
case SPEED_100:
-   if (ecmd->duplex == DUPLEX_FULL)
+   if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_100baseT_Full;
-   else if (ecmd->duplex == DUPLEX_HALF)
+   else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_100baseT_Half;
else
return -EINVAL;
break;
 
case SPEED_10:
-   if (ecmd->duplex == DUPLEX_FULL)
+   if (cmd->base.duplex == DUPLEX_FULL)
setting = SUPPORTED_10baseT_Full;
-   else if (ecmd->duplex == DUPLEX_HALF)
+   else if (cmd->base.duplex == DUPLEX_HALF)
setting = SUPPORTED_10baseT_Half;
else
return -EINVAL;
@@ -371,11 +382,11 @@ static int skge_set_settings(struct 

Re: [patch net-next] stmmac: indent an if statement

[Julia Lawall]

On Mon, 16 Jan 2017, Dan Carpenter wrote:

> On Mon, Jan 16, 2017 at 12:19:24PM +0300, Dan Carpenter wrote:
> > On Sun, Jan 15, 2017 at 10:14:38PM -0500, David Miller wrote:
> > > From: Dan Carpenter 
> > > Date: Thu, 12 Jan 2017 21:46:32 +0300
> > >
> > > > The break statement should be indented one more tab.
> > > >
> > > > Signed-off-by: Dan Carpenter 
> > >
> > > Applied, but like Julia I think we might have a missing of_node_put()
> > > here.
> >
> > Of course, sorry for dropping the ball on this.  I'll send a patch for
> > that.
> >
>
> Actually, I've looked at it some more and I think this function is OK.
> We're supposed to do an of_node_put() later...  I can't find where that
> happens, but presumably that's because I don't know stmmac well.  This
> code here, though, is fine.

Why do you think it is fine?  Does anyone in the calling context know
which child would have caused the break?  An extra put is only needed on
that one.  Is there a guarantee that the break is always taken?

julia

Re: [PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs

[Or Gerlitz]

On Mon, Jan 16, 2017 at 7:29 PM, Tariq Toukan  wrote:
> From: Daniel Jurgens 
>
> Use CPUs on the close NUMA when setting the EQ affinity hints.

Dan, are we sure there are no down-sides for always doing this? this
code is probably there for many years and we're introducing here new
behaviour to potentially to many Ms installs when they get distro
update that includes this patch.

Re: [PATCH] net: marvell: skge: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

Hi Stephen,

On 1/16/17, Stephen Hemminger  wrote:
> On Mon, 16 Jan 2017 12:36:17 -0500 (EST)
> David Miller  wrote:
>
>> From: Stephen Hemminger 
>> Date: Mon, 16 Jan 2017 09:29:51 -0800
>>
>> > On Sat, 14 Jan 2017 13:08:28 +0100
>> > Philippe Reynes  wrote:
>> >
>> >> The ethtool api {get|set}_settings is deprecated.
>> >> We move this driver to new api {get|set}_link_ksettings.
>> >>
>> >> The callback set_link_ksettings no longer update the value
>> >> of advertising, as the struct ethtool_link_ksettings is
>> >> defined as const.
>> >>
>> >> Signed-off-by: Philippe Reynes 
>> >
>> > Did you test this on real hardware?
>>
>> Philippe probably doesn't have physical access to most of the
>> drivers he is converting.
>>
>> But, he is the only person working on converting all of the drivers,
>> and therefore when the change looks straightforward I am going to
>> reward his work and effort by applying his changes and hope there
>> isn't any fallout.
>>
>> Those who really care can test his patches and give a Tested-by:
>>
>> Thanks.
>
> Yes, it looks mechanical and should be applied. There are lots of pieces of
> old hardware that no developer is running, and if we required full test
> suite runs
> on all drivers, then no refactoring would ever be possible.
>
> My preference is to always add commit note that the patch was compile
> tested only so that if someone has a problem with real hardware then they
> know
> what to suspect.

David is right, I don't have the hardware to test all drivers.
I haven't added a little note on all commit, because I was
thinking it would be a lot of noise. But if you prefer (and
David agrees), I'll add a note on all the following patches.

Btw, thanks David for applying my patches.

Philippe

Re: [PATCH v2] net/irda: fix lockdep annotation

[Dmitry Vyukov]

On Mon, Jan 16, 2017 at 7:09 PM, kbuild test robot <l...@intel.com> wrote:
> Hi Dmitry,
>
> [auto build test ERROR on tip/locking/core]
> [also build test ERROR on v4.10-rc4 next-20170116]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Dmitry-Vyukov/net-irda-fix-lockdep-annotation/20170117-001737
> config: i386-defconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All error/warnings (new ones prefixed by >>):
>
>In file included from include/linux/mmzone.h:7:0,
> from include/linux/gfp.h:5,
> from include/linux/slab.h:14,
> from drivers/gpu/drm/i915/i915_sw_fence.c:10:
>drivers/gpu/drm/i915/i915_sw_fence.c: In function 
> '__i915_sw_fence_wake_up_all':
>>> include/linux/spinlock.h:217:3: error: void value not ignored as it ought 
>>> to be
>   (void)subclass;  \
>
>>> include/linux/spinlock.h:335:2: note: in expansion of macro 
>>> 'raw_spin_lock_irqsave_nested'
>  raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
>  ^~~~
>>> drivers/gpu/drm/i915/i915_sw_fence.c:68:2: note: in expansion of macro 
>>> 'spin_lock_irqsave_nested'
>  spin_lock_irqsave_nested(>lock, flags, 1 + !!continuation);
>  ^~~~


Mailed v3.

> vim +217 include/linux/spinlock.h
>
>211  typecheck(unsigned long, flags);  
>   \
>212  flags = _raw_spin_lock_irqsave_nested(lock, 
> subclass);  \
>213  } while (0)
>214  #else
>215  #define raw_spin_lock_irqsave_nested(lock, flags, subclass)   
>   \
>216  do {  
>   \
>  > 217  (void)subclass;   
>   \
>218  typecheck(unsigned long, flags);  
>   \
>219  flags = _raw_spin_lock_irqsave(lock); 
>   \
>220  } while (0)
>221  #endif
>222
>223  #else
>224
>225  #define raw_spin_lock_irqsave(lock, flags)  \
>226  do {\
>227  typecheck(unsigned long, flags);\
>228  _raw_spin_lock_irqsave(lock, flags);\
>229  } while (0)
>230
>231  #define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
>232  raw_spin_lock_irqsave(lock, flags)
>233
>234  #endif
>235
>236  #define raw_spin_lock_irq(lock) _raw_spin_lock_irq(lock)
>237  #define raw_spin_lock_bh(lock)  _raw_spin_lock_bh(lock)
>238  #define raw_spin_unlock(lock)   _raw_spin_unlock(lock)
>239  #define raw_spin_unlock_irq(lock)   _raw_spin_unlock_irq(lock)
>240
>241  #define raw_spin_unlock_irqrestore(lock, flags) \
>242  do {\
>243  typecheck(unsigned long, flags);\
>244  _raw_spin_unlock_irqrestore(lock, flags);   \
>245  } while (0)
>246  #define raw_spin_unlock_bh(lock)_raw_spin_unlock_bh(lock)
>247
>248  #define raw_spin_trylock_bh(lock) \
>249  __cond_lock(lock, _raw_spin_trylock_bh(lock))
>250
>251  #define raw_spin_trylock_irq(lock) \
>252  ({ \
>253  local_irq_disable(); \
>254  raw_spin_trylock(lock) ? \
>255  1 : ({ local_irq_enable(); 0;  }); \
>256  })
>257
>258  #define raw_spin_trylock_irqsave(lock, flags) \
>259  ({ \
>260  local_irq_save(flags); \
>261  raw_spin_trylock(lock) ? \
>262  1 : ({ local_irq_restore(flags); 0; }); \
>263  })
>264
>265  /**
>266   * raw_spin_can_lock - would raw_spin_trylock() succeed?
>267   * @lock: the spinlock in question.
>268   */
>269  #define raw_spin_can_lock(lock) (!raw_spin_is_locked(lock))
>270
>271  /* Include rwlock functions */
>272  #include 
>273
>274  /*
>275   * Pull the _spin_*()/_read_*()/_write_*() functions/declarations:
>276   */
>277  #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
>278  # include 
>279  #else

[PATCH v3] net/irda: fix lockdep annotation

[Dmitry Vyukov]

The current annotation uses a global variable as recursion counter.
The variable is not atomic nor protected with a mutex, but mutated
by multiple threads. This causes lockdep bug reports episodically:

BUG: looking up invalid subclass: 4294967295
...
_raw_spin_lock_irqsave_nested+0x120/0x180
hashbin_delete+0x4fe/0x750
__irias_delete_object+0xab/0x170
irias_delete_object+0x5f/0xc0
ircomm_tty_detach_cable+0x1d5/0x3f0
...

Make the hashbin_lock_depth variable atomic to prevent bug reports.

As is this causes "unused variable 'depth'" warning without LOCKDEP.
So also change raw_spin_lock_irqsave_nested() macro to not cause
the warning without LOCKDEP. Similar to what raw_spin_lock_nested()
already does.

Signed-off-by: Dmitry Vyukov 
Cc: Dave Jones 
Cc: Samuel Ortiz 
Cc: David S. Miller 
Cc: netdev@vger.kernel.org
Fixes: c7630a4b932af ("[IrDA]: irda lockdep annotation")

---

Changes since v1:
 - Added raw_spin_lock_irqsave_nested() change
   as 0-DAY bot reported compiler warning without LOCKDEP.

Changes since v2:
 - Use ((void)(subclass), (lock)) instead of (void)subclass
   to prevent unused variable warning. Now 0-DAY complaints
   "error: void value not ignored as it ought to be".
   My compiler does not produce warning with W=1 either way,
   but the comma trick is what already used in raw_spin_lock_nested().
---
 include/linux/spinlock.h |  2 +-
 net/irda/irqueue.c   | 12 +++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
index 47dd0cebd204..beeb5a39bd8b 100644
--- a/include/linux/spinlock.h
+++ b/include/linux/spinlock.h
@@ -218,7 +218,7 @@ static inline void do_raw_spin_unlock(raw_spinlock_t *lock) 
__releases(lock)
 #define raw_spin_lock_irqsave_nested(lock, flags, subclass)\
do {\
typecheck(unsigned long, flags);\
-   flags = _raw_spin_lock_irqsave(lock);   \
+   flags = _raw_spin_lock_irqsave(((void)(subclass), (lock))); \
} while (0)
 #endif
 
diff --git a/net/irda/irqueue.c b/net/irda/irqueue.c
index acbe61c7e683..b9fd74e6ca99 100644
--- a/net/irda/irqueue.c
+++ b/net/irda/irqueue.c
@@ -384,21 +384,23 @@ EXPORT_SYMBOL(hashbin_new);
  *just supply kfree, which should take care of the job.
  */
 #ifdef CONFIG_LOCKDEP
-static int hashbin_lock_depth = 0;
+static atomic_t hashbin_lock_depth = ATOMIC_INIT(0);
 #endif
 int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
 {
irda_queue_t* queue;
unsigned long flags = 0;
-   int i;
+   int i, depth = 0;
 
IRDA_ASSERT(hashbin != NULL, return -1;);
IRDA_ASSERT(hashbin->magic == HB_MAGIC, return -1;);
 
/* Synchronize */
if ( hashbin->hb_type & HB_LOCK ) {
-   spin_lock_irqsave_nested(>hb_spinlock, flags,
-hashbin_lock_depth++);
+#ifdef CONFIG_LOCKDEP
+   depth = atomic_inc_return(_lock_depth) - 1;
+#endif
+   spin_lock_irqsave_nested(>hb_spinlock, flags, depth);
}
 
/*
@@ -423,7 +425,7 @@ int hashbin_delete( hashbin_t* hashbin, FREE_FUNC free_func)
if ( hashbin->hb_type & HB_LOCK) {
spin_unlock_irqrestore(>hb_spinlock, flags);
 #ifdef CONFIG_LOCKDEP
-   hashbin_lock_depth--;
+   atomic_dec(_lock_depth);
 #endif
}
 
-- 
2.11.0.483.g087da7b7c-goog

Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout

[Tom Herbert]

On Mon, Jan 16, 2017 at 12:30 PM, Saeed Mahameed
 wrote:
> On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
>  wrote:
>> On Fri, Jan 13, 2017 at 7:14 PM, David Miller  wrote:
>>> From: Saeed Mahameed 
>>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>>
 This pull request includes one patch from Leon, this patch as described
 below will change the driver directory structure and layout for better,
 logical and modular driver files separation.

 This change is important to both rdma and net maintainers in order to
 have smoother management of driver patches for different mlx5 sub modules
 and smoother rdma-next vs. net-next features submissions.

 Please find more info below -in the tag commit message-,
 review and let us know if there's any problem.

 This change doesn't introduce any conflicts with the current mlx5
 fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
 worked flawlessly with no issues.

 This is the last pull request meant for both rdma-next and net-next.
 Once pulled, this will be the base shared code for both trees.
>>>
>>> This is pretty crazy, it will make all bug fix backporting to -stable
>>> a complete nightmare for myself, Doug, various distribution maintainers
>>> and many other people who quietly have to maintain their own trees and
>>> do backporting.
>>>
>>
>> I hear you,
>> But please bear with me here, what if we queue this patch up to -stable ? 
>> and we
>> (Mellanox) and specifically our dedicated inbox team, will make sure
>> that this patch
>> will land on the various distributions and for those maintaining their
>> own trees.
>> This patch is really straight forward (rename files) and I already
>> tried to cherry-pick it
>> on older kernels, I only got a couple of conflicts on some of the
>> "#inlcude" lines we've
>> changed, and they are pretty straightforward to fix, we can even avoid
>> this if we decide to
>> not move mlx5 header files in this phase.
>>
>> If this is possible then all trees will be aligned and it will be a
>> win win situation.
>>
>
> Hi Dave,
>
> Any chance you saw my -stable suggestion above ?
> I think it would really close the backporting gap.
>
> Sorry i am bothering you with this topic, but we really desire the new
> structure and
> I never got your feedback on this suggestion, so i would like to hear
> your thoughts.
>
Saeed,

I've already you specific suggestions on your new structure, please
consider your reviewers feedback more carefully. Again, the starting
point for your restructuring should be to separate out the minimum set
of files required to build reasonable driver and then cleanly
compartmentalize the rest of the features to make it easy for your
users to include or not include those in their build. Unless you've
done this I'm not seeing much benefit for this restructuring. Also, I
would rather see this done in one shot then expecting some sort of
evolution over time to the right solution-- as Dave said the
complexity of this driver is to far down the road to do that.

Tom

> Thanks,
> Saeed.
>
>>> I really don't think you can justify this rearrangement based upon the
>>> consequences and how much activity happens in this driver.
>>>
>>
>> Right, but this is not the only justification, I can sum it up to that
>> we would like
>> to lay out the foundation for many years to come for a well designed
>> driver with a modular
>> sub modules break down and scalable infrastructure. We already plan to
>> submit more mlx5
>> independent  sub modules - just like mlx5e (en_*) files and mlx5_ib
>> driver- so this was also
>> a reason for us to consider this re-engagement at this stage.
>>
>>> You should have thought long and hard about the layout a long time ago
>>> rather than after the driver has been in the tree for many years.
>>>
>>
>> I had this Idea for the separation before the mlx5 Ethernet
>> submission, but I wasn't the maintainer
>> back then, and i have been itching to submit such patch for long as
>> well, still i don't think
>> it is too late, We (Me and Leon) will keep maintaining this driver for
>> only god knows how many years to come,
>> and the mlx5 drivers are meant to serve at least 3-4 more future HW 
>> generations.
>>
>> Long story short, We would like to re-arrange the driver in a way that
>> would serve us (the maintainers) and serve those
>> who are going do develop the future Stack features and the future HW
>> generations over the well designed (Hopefully)
>> mlx5 infrastructure.
>> Keeping it as it is today, will only make the situation worst in the
>> future and it will be really hard to avoid having a spaghetti code
>> in the mlx5 driver. All i want to point out here is that maintaining
>> such a flat subtree is also nightmare.
>>
>> So i am only asking you to reconsider this change and give my -stable
>> suggestion a thought.
>>
>> Thank 

Re: [PATCH] net: constify mdiobb_ops structures

[Sergei Shtylyov]

Hello!

On 01/13/2017 09:02 PM, Bhumika Goyal wrote:


Declare mdiobb_ops structures as const as they are only stored in the
ops field of mdiobb_ctrl structures. This field is of type const, so
mdiobb_ops structures having this property can be declared const too.
Done using Coccinelle:


[...]


Signed-off-by: Bhumika Goyal 

[...]


diff --git a/drivers/net/ethernet/renesas/ravb_main.c 
b/drivers/net/ethernet/renesas/ravb_main.c
index 92d7692..1b0acd1 100644
--- a/drivers/net/ethernet/renesas/ravb_main.c
+++ b/drivers/net/ethernet/renesas/ravb_main.c
@@ -171,7 +171,7 @@ static int ravb_get_mdio_data(struct mdiobb_ctrl *ctrl)
 }

 /* MDIO bus control struct */
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = ravb_set_mdc,
.set_mdio_dir = ravb_set_mdio_dir,
diff --git a/drivers/net/ethernet/renesas/sh_eth.c 
b/drivers/net/ethernet/renesas/sh_eth.c
index 00fafab..6ef5dd8 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1052,7 +1052,7 @@ static void sh_mdc_ctrl(struct mdiobb_ctrl *ctrl, int bit)
 }

 /* mdio bus control struct */
-static struct mdiobb_ops bb_ops = {
+static const struct mdiobb_ops bb_ops = {
.owner = THIS_MODULE,
.set_mdc = sh_mdc_ctrl,
.set_mdio_dir = sh_mmd_ctrl,

[...]

   For the above 2 drivers:

Acked-by: Sergei Shtylyov 

MBR, Sergei

Re: [PATCH/RFC v2 net-next] ravb: unmap descriptors when freeing rings

[Sergei Shtylyov]

Hello!

On 01/12/2017 04:18 PM, Simon Horman wrote:


...



  Here, it stop once an untransmitted buffer is encountered...


Yes, I see that now.

I wonder if we should:

a) paramatise ravb_tx_free() so it may either clear all transmitted buffers
  (current behaviour) or all buffers (new behaviour).
b) provide a different version of this loop in ravb_ring_free()

What are your thoughts?


   I'm voting for (b).


   After looking at this issue for another time, I'll vote for (a). Sorry for 
back-and-forth on this matter -- I somehow thought we could do a better job by 
scanning all the TX ring...



Ok, something like this?

@@ -215,6 +225,30 @@ static void ravb_ring_free(struct net_device *ndev, int q)
}

if (priv->tx_ring[q]) {
+   for (; priv->cur_tx[q] - priv->dirty_tx[q] > 0; 
priv->dirty_tx[q]++) {
+   struct ravb_tx_desc *desc;
+   int entry;
+
+   entry = priv->dirty_tx[q] % (priv->num_tx_ring[q] *
+NUM_TX_DESC);
+   desc = >tx_ring[q][entry];
+
+   /* Free the original skb. */
+   if (priv->tx_skb[q][entry / NUM_TX_DESC]) {
+   u32 size = le16_to_cpu(desc->ds_tagl) & TX_DS;
+
+   dma_unmap_single(ndev->dev.parent,
+le32_to_cpu(desc->dptr),
+size, DMA_TO_DEVICE);
+   /* Last packet descriptor? */
+   if (entry % NUM_TX_DESC == NUM_TX_DESC - 1) {
+   entry /= NUM_TX_DESC;
+   
dev_kfree_skb_any(priv->tx_skb[q][entry]);
+   priv->tx_skb[q][entry] = NULL;
+   }
+   }
+   }
+


   This is only different from ravb_tx_free() by not stopping on unfinished 
descriptor, so we must be good with adding an extra param to it...


[...]

MBR, Sergei

Re: [PATCH V2] audit: log 32-bit socketcalls

[Paul Moore]

On Mon, Jan 16, 2017 at 1:27 PM, David Miller  wrote:
> From: Richard Guy Briggs 
> Date: Fri, 13 Jan 2017 04:51:48 -0500
>
>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>> index 9d4443f..43d8003 100644
>> --- a/include/linux/audit.h
>> +++ b/include/linux/audit.h
>> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs, unsigned 
>> long *args)
>>   return __audit_socketcall(nargs, args);
>>   return 0;
>>  }
>> +static inline int audit_socketcall_compat(int nargs, u32 *args)
>> +{
>
> Please put an empty line between function definitions.

David, assuming Richard makes your requested changes, any objection if
I merge this via the audit tree instead of the netdev tree?  It's a
bit easier for us from a testing perspective this way ...

>> + if (unlikely(!audit_dummy_context())) {
>> + int i;
>> + unsigned long a[AUDITSC_ARGS];
>
> Please order local variable declarations from longest to shortest line.
>
>> +
>> + for (i=0; i
> Please put a space around operators such as "=" and "<".
>
>> + a[i] = (unsigned long)args[i];
>> + return __audit_socketcall(nargs, a);
>> + }
>> + return 0;
>> +}
>>  static inline int audit_sockaddr(int len, void *addr)
>
> Again, empty line between function definitions please.
>
>> @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct 
>> compat_mmsghdr __user *, mmsg,
>>
>>  COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
>>  {
>> + unsigned int len;
>>   int ret;
>> - u32 a[6];
>> + u32 a[AUDITSC_ARGS];
>>   u32 a0, a1;
>
> Longest to shortest line for local variable declarations please.
>
> --
> Linux-audit mailing list
> linux-au...@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit



-- 
paul moore
www.paul-moore.com

RE: [net-next 0/3] tipc: improve interaction socket-link

[Jon Maloy]

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of David Miller
> Sent: Monday, 16 January, 2017 14:45
> To: Jon Maloy 
> Cc: netdev@vger.kernel.org; v...@zeniv.linux.org.uk; Parthasarathy Bhuvaragan
> ; Ying Xue
> ; ma...@donjonn.com; tipc-
> discuss...@lists.sourceforge.net
> Subject: Re: [net-next 0/3] tipc: improve interaction socket-link
> 
> From: Jon Maloy 
> Date: Tue,  3 Jan 2017 10:26:45 -0500
> 
> > We fix a very real starvation problem that may occur when a link
> > encounters send buffer congestion. At the same time we make the
> > interaction between the socket and link layer simpler and more
> > consistent.
> 
> This doesn't apply to net-next, also the Date in your emails is 10 days
> in the past.  What's going on here?

I don't know. This series was sent in on Jan 3rd, and applied by you the same 
day. Maybe the mail server decided to send you a duplicate?

///jon

Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout

[Saeed Mahameed]

On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
 wrote:
> On Fri, Jan 13, 2017 at 7:14 PM, David Miller  wrote:
>> From: Saeed Mahameed 
>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>
>>> This pull request includes one patch from Leon, this patch as described
>>> below will change the driver directory structure and layout for better,
>>> logical and modular driver files separation.
>>>
>>> This change is important to both rdma and net maintainers in order to
>>> have smoother management of driver patches for different mlx5 sub modules
>>> and smoother rdma-next vs. net-next features submissions.
>>>
>>> Please find more info below -in the tag commit message-,
>>> review and let us know if there's any problem.
>>>
>>> This change doesn't introduce any conflicts with the current mlx5
>>> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>>> worked flawlessly with no issues.
>>>
>>> This is the last pull request meant for both rdma-next and net-next.
>>> Once pulled, this will be the base shared code for both trees.
>>
>> This is pretty crazy, it will make all bug fix backporting to -stable
>> a complete nightmare for myself, Doug, various distribution maintainers
>> and many other people who quietly have to maintain their own trees and
>> do backporting.
>>
>
> I hear you,
> But please bear with me here, what if we queue this patch up to -stable ? and 
> we
> (Mellanox) and specifically our dedicated inbox team, will make sure
> that this patch
> will land on the various distributions and for those maintaining their
> own trees.
> This patch is really straight forward (rename files) and I already
> tried to cherry-pick it
> on older kernels, I only got a couple of conflicts on some of the
> "#inlcude" lines we've
> changed, and they are pretty straightforward to fix, we can even avoid
> this if we decide to
> not move mlx5 header files in this phase.
>
> If this is possible then all trees will be aligned and it will be a
> win win situation.
>

Hi Dave,

Any chance you saw my -stable suggestion above ?
I think it would really close the backporting gap.

Sorry i am bothering you with this topic, but we really desire the new
structure and
I never got your feedback on this suggestion, so i would like to hear
your thoughts.

Thanks,
Saeed.

>> I really don't think you can justify this rearrangement based upon the
>> consequences and how much activity happens in this driver.
>>
>
> Right, but this is not the only justification, I can sum it up to that
> we would like
> to lay out the foundation for many years to come for a well designed
> driver with a modular
> sub modules break down and scalable infrastructure. We already plan to
> submit more mlx5
> independent  sub modules - just like mlx5e (en_*) files and mlx5_ib
> driver- so this was also
> a reason for us to consider this re-engagement at this stage.
>
>> You should have thought long and hard about the layout a long time ago
>> rather than after the driver has been in the tree for many years.
>>
>
> I had this Idea for the separation before the mlx5 Ethernet
> submission, but I wasn't the maintainer
> back then, and i have been itching to submit such patch for long as
> well, still i don't think
> it is too late, We (Me and Leon) will keep maintaining this driver for
> only god knows how many years to come,
> and the mlx5 drivers are meant to serve at least 3-4 more future HW 
> generations.
>
> Long story short, We would like to re-arrange the driver in a way that
> would serve us (the maintainers) and serve those
> who are going do develop the future Stack features and the future HW
> generations over the well designed (Hopefully)
> mlx5 infrastructure.
> Keeping it as it is today, will only make the situation worst in the
> future and it will be really hard to avoid having a spaghetti code
> in the mlx5 driver. All i want to point out here is that maintaining
> such a flat subtree is also nightmare.
>
> So i am only asking you to reconsider this change and give my -stable
> suggestion a thought.
>
> Thank you.
> Saeed.

Re: [PATCH] net: add regs attribute to phy device for user diagnose

[Florian Fainelli]

On 01/16/2017 04:59 AM, yuan linyu wrote:
> On 日, 2017-01-15 at 18:21 +0100, Andrew Lunn wrote:
>> On Sun, Jan 15, 2017 at 09:51:03AM +0800, yuan linyu wrote:
>>>  
>>> I hope user/developer can read this attribute file "regs" to do
>>> a full check of all registers value, and they can write any register
>>> inside PHY through this file.
>> Since this is intended for debug, it should not be sysfs, but debugfs.
> agree,
>> However, in general, Linux does not allow user space to peek and poke
>> device registers. Can you point me at examples where i can do the same
>> to my GPU? SATA controller? Ethernet controller, I2C temperature
>> sensor? Any device?
> we can read registers of ethernet controller(memory register accessed) 
> through devmem or ethtool

So why not add support in ethtool for reading PHY registers if you need
it? There are handful of PHY "things" in ethtool, such as reading
counters, configuring downshift etc., adding support for dumping
registers does not sound out of space.
-- 
Florian

Re: [PATCH net 0/3] mlx4 core fixes

[David Miller]

From: Tariq Toukan 
Date: Mon, 16 Jan 2017 18:31:36 +0200

> This patchset contains bug fixes from Jack to the mlx4 Core driver.
> 
> Patch 1 solves a race in the flow of CQ free.
> Patch 2 moves some qp context flags update to the correct qp transition.
> Patch 3 eliminates warnings from the path of SRQ_LIMIT that flood the message 
> log,
> and keeps them only in the path of SRQ_CATAS_ERROR.
> 
> Series generated against net commit:
> 1a717fcf8bbe Merge tag 'mac80211-for-davem-2017-01-13' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

Series applied, thanks.

Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout

[Saeed Mahameed]

On Sat, Jan 14, 2017 at 12:56 AM, Tom Herbert  wrote:
> On Fri, Jan 13, 2017 at 2:45 PM, Saeed Mahameed
>  wrote:
>> On Sat, Jan 14, 2017 at 12:06 AM, Tom Herbert  wrote:
>>> Btw, we did hit one issue in the backport. We started to get rx csum
>>> faults (checksum complete value indicates TCP checksum is bad, but
>>> host computation says checksum is good). I ran against 4.9 upstream
>>> kernel and do see these, however don't see them in 4.10. I haven't
>>> bisected yet. Is this a known issue?
>>>
>>
>> Not to me, I don't recall any csum related fixes or feature submitted
>> lately to mlx5,
>> Maybe something changed in the stack ?
>>
>> what configuration are you running ? what traffic ?
>>
> Nothing fancy. 8 queues and 20 concurrent netperf TCP_STREAMs trips
> it. Not a lot of them, but I don't think we really should ever see
> these errors.
>

Hi Tom

I've been trying to repro with no luck with kernel v4.9.
I am looking for checksum errors in dmesg, is that the place where you
saw the errors ?

can you dump the error in here ?

[PATCH 1/2] qed: Add support for hardware offloaded FCoE.

[Dupuis, Chad]

From: Arun Easi 

This adds the backbone required for the various HW initalizations
which are necessary for the FCoE driver (qedf) for QLogic FastLinQ
4 line of adapters - FW notification, resource initializations, etc.

Signed-off-by: Arun Easi 
Signed-off-by: Yuval Mintz 
---
 drivers/net/ethernet/qlogic/Kconfig   |   3 +
 drivers/net/ethernet/qlogic/qed/Makefile  |   1 +
 drivers/net/ethernet/qlogic/qed/qed.h |  11 +
 drivers/net/ethernet/qlogic/qed/qed_cxt.c |  98 ++-
 drivers/net/ethernet/qlogic/qed/qed_cxt.h |   3 +
 drivers/net/ethernet/qlogic/qed/qed_dcbx.c|  11 +
 drivers/net/ethernet/qlogic/qed/qed_dcbx.h|   1 +
 drivers/net/ethernet/qlogic/qed/qed_dev.c | 205 -
 drivers/net/ethernet/qlogic/qed/qed_dev_api.h |  42 +
 drivers/net/ethernet/qlogic/qed/qed_fcoe.c| 990 ++
 drivers/net/ethernet/qlogic/qed/qed_fcoe.h|  52 ++
 drivers/net/ethernet/qlogic/qed/qed_hsi.h | 781 -
 drivers/net/ethernet/qlogic/qed/qed_hw.c  |   3 +
 drivers/net/ethernet/qlogic/qed/qed_ll2.c |  25 +
 drivers/net/ethernet/qlogic/qed/qed_ll2.h |   2 +-
 drivers/net/ethernet/qlogic/qed/qed_main.c|   7 +
 drivers/net/ethernet/qlogic/qed/qed_mcp.c |   3 +
 drivers/net/ethernet/qlogic/qed/qed_mcp.h |   1 +
 drivers/net/ethernet/qlogic/qed/qed_reg_addr.h|   8 +
 drivers/net/ethernet/qlogic/qed/qed_sp.h  |   4 +
 drivers/net/ethernet/qlogic/qed/qed_sp_commands.c |   3 +
 include/linux/qed/common_hsi.h|  10 +-
 include/linux/qed/fcoe_common.h   | 715 
 include/linux/qed/qed_fcoe_if.h   | 145 
 include/linux/qed/qed_if.h|  39 +
 25 files changed, 3152 insertions(+), 11 deletions(-)
 create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.c
 create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.h
 create mode 100644 include/linux/qed/fcoe_common.h
 create mode 100644 include/linux/qed/qed_fcoe_if.h

diff --git a/drivers/net/ethernet/qlogic/Kconfig 
b/drivers/net/ethernet/qlogic/Kconfig
index 3cfd105..737b303 100644
--- a/drivers/net/ethernet/qlogic/Kconfig
+++ b/drivers/net/ethernet/qlogic/Kconfig
@@ -113,4 +113,7 @@ config QED_RDMA
 config QED_ISCSI
bool
 
+config QED_FCOE
+   bool
+
 endif # NET_VENDOR_QLOGIC
diff --git a/drivers/net/ethernet/qlogic/qed/Makefile 
b/drivers/net/ethernet/qlogic/qed/Makefile
index 729e437..e234083 100644
--- a/drivers/net/ethernet/qlogic/qed/Makefile
+++ b/drivers/net/ethernet/qlogic/qed/Makefile
@@ -7,3 +7,4 @@ qed-$(CONFIG_QED_SRIOV) += qed_sriov.o qed_vf.o
 qed-$(CONFIG_QED_LL2) += qed_ll2.o
 qed-$(CONFIG_QED_RDMA) += qed_roce.o
 qed-$(CONFIG_QED_ISCSI) += qed_iscsi.o qed_ooo.o
+qed-$(CONFIG_QED_FCOE) += qed_fcoe.o
diff --git a/drivers/net/ethernet/qlogic/qed/qed.h 
b/drivers/net/ethernet/qlogic/qed/qed.h
index 1f61cf3..08f2885 100644
--- a/drivers/net/ethernet/qlogic/qed/qed.h
+++ b/drivers/net/ethernet/qlogic/qed/qed.h
@@ -60,6 +60,7 @@
 #define QED_WFQ_UNIT   100
 
 #define ISCSI_BDQ_ID(_port_id) (_port_id)
+#define FCOE_BDQ_ID(_port_id) ((_port_id) + 2)
 #define QED_WID_SIZE(1024)
 #define QED_PF_DEMS_SIZE(4)
 
@@ -167,6 +168,7 @@ struct qed_tunn_update_params {
  */
 enum qed_pci_personality {
QED_PCI_ETH,
+   QED_PCI_FCOE,
QED_PCI_ISCSI,
QED_PCI_ETH_ROCE,
QED_PCI_DEFAULT /* default in shmem */
@@ -204,6 +206,7 @@ enum QED_FEATURE {
QED_VF,
QED_RDMA_CNQ,
QED_VF_L2_QUE,
+   QED_FCOE_CQ,
QED_MAX_FEATURES,
 };
 
@@ -221,6 +224,7 @@ enum QED_PORT_MODE {
 
 enum qed_dev_cap {
QED_DEV_CAP_ETH,
+   QED_DEV_CAP_FCOE,
QED_DEV_CAP_ISCSI,
QED_DEV_CAP_ROCE,
 };
@@ -255,6 +259,10 @@ struct qed_hw_info {
u32 part_num[4];
 
unsigned char   hw_mac_addr[ETH_ALEN];
+   u64 node_wwn;
+   u64 port_wwn;
+
+   u16 num_fcoe_conns;
 
struct qed_igu_info *p_igu_info;
 
@@ -410,6 +418,7 @@ struct qed_hwfn {
struct qed_ooo_info *p_ooo_info;
struct qed_rdma_info*p_rdma_info;
struct qed_iscsi_info   *p_iscsi_info;
+   struct qed_fcoe_info*p_fcoe_info;
struct qed_pf_paramspf_params;
 
bool b_rdma_enabled_in_prs;
@@ -618,11 +627,13 @@ struct qed_dev {
 
u8  protocol;
 #define IS_QED_ETH_IF(cdev) ((cdev)->protocol == QED_PROTOCOL_ETH)
+#define IS_QED_FCOE_IF(cdev)((cdev)->protocol == QED_PROTOCOL_FCOE)
 
/* Callbacks to protocol driver */
union {
struct qed_common_cb_ops*common;
struct 

[PATCH 0/2] Add QLogic FastLinQ FCoE (qedf) driver

[Dupuis, Chad]

From: "Dupuis, Chad" 

This series introduces the hardware offload FCoE initiator driver for the
41000 Series Converged Network Adapters (579xx chip) by Cavium. The overall
driver design includes a common module ('qed') and protocol specific
dependent modules ('qedf' for FCoE).

This driver uses the kernel components of libfc and libfcoe as is and does not
make use of the open-fcoe user space components.  Therefore, no changes will 
need to be
made to any open-fcoe components.

The 'qed' common module, under drivers/net/ethernet/qlogic/qed/, is
enhanced with functionality required for FCoE support.

Changes from RFC -> V1

- Squash qedf patches to one patch now that the initial review has taken place
- Convert qedf to use hotplug state machine
- Return via va_end to match corresponding va_start in logging functions
- Convert qedf_ctx offloaded port list to a RCU list so searches do not need
  to make use of spinlocks.  Also eliminates the need to fcport conn_id's.
- Use IS_ERR(fp) in qedf_flogi_resp() instead of checking individual FC_EX_* 
errors.
- Remove scsi_block_target when executing TMF request.
- Checkpatch fixes in the qed and qedf patches

At the current time I couldn't make use of Christoph's IRQ allocation changes
as changes are needed to the core module (qed) which would affect other drivers
that are already in tree (qede, qedr, qedi).

Arun Easi (1):
  qed: Add support for hardware offloaded FCoE.

Dupuis, Chad (1):
  qedf: Add QLogic FastLinQ offload FCoE driver framework.

 MAINTAINERS   |6 +
 drivers/net/ethernet/qlogic/Kconfig   |3 +
 drivers/net/ethernet/qlogic/qed/Makefile  |1 +
 drivers/net/ethernet/qlogic/qed/qed.h |   11 +
 drivers/net/ethernet/qlogic/qed/qed_cxt.c |   98 +-
 drivers/net/ethernet/qlogic/qed/qed_cxt.h |3 +
 drivers/net/ethernet/qlogic/qed/qed_dcbx.c|   11 +
 drivers/net/ethernet/qlogic/qed/qed_dcbx.h|1 +
 drivers/net/ethernet/qlogic/qed/qed_dev.c |  205 +-
 drivers/net/ethernet/qlogic/qed/qed_dev_api.h |   42 +
 drivers/net/ethernet/qlogic/qed/qed_fcoe.c|  990 ++
 drivers/net/ethernet/qlogic/qed/qed_fcoe.h|   52 +
 drivers/net/ethernet/qlogic/qed/qed_hsi.h |  781 -
 drivers/net/ethernet/qlogic/qed/qed_hw.c  |3 +
 drivers/net/ethernet/qlogic/qed/qed_ll2.c |   25 +
 drivers/net/ethernet/qlogic/qed/qed_ll2.h |2 +-
 drivers/net/ethernet/qlogic/qed/qed_main.c|7 +
 drivers/net/ethernet/qlogic/qed/qed_mcp.c |3 +
 drivers/net/ethernet/qlogic/qed/qed_mcp.h |1 +
 drivers/net/ethernet/qlogic/qed/qed_reg_addr.h|8 +
 drivers/net/ethernet/qlogic/qed/qed_sp.h  |4 +
 drivers/net/ethernet/qlogic/qed/qed_sp_commands.c |3 +
 drivers/scsi/Kconfig  |1 +
 drivers/scsi/qedf/Kconfig |   11 +
 drivers/scsi/qedf/Makefile|5 +
 drivers/scsi/qedf/qedf.h  |  555 
 drivers/scsi/qedf/qedf_attr.c |  165 +
 drivers/scsi/qedf/qedf_dbg.c  |  195 ++
 drivers/scsi/qedf/qedf_dbg.h  |  154 +
 drivers/scsi/qedf/qedf_debugfs.c  |  471 +++
 drivers/scsi/qedf/qedf_els.c  |  984 ++
 drivers/scsi/qedf/qedf_fip.c  |  267 ++
 drivers/scsi/qedf/qedf_hsi.h  |  427 +++
 drivers/scsi/qedf/qedf_io.c   | 2301 ++
 drivers/scsi/qedf/qedf_main.c | 3483 +
 drivers/scsi/qedf/qedf_version.h  |   15 +
 include/linux/qed/common_hsi.h|   10 +-
 include/linux/qed/fcoe_common.h   |  715 +
 include/linux/qed/qed_fcoe_if.h   |  145 +
 include/linux/qed/qed_if.h|   39 +
 40 files changed, 12192 insertions(+), 11 deletions(-)
 create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.c
 create mode 100644 drivers/net/ethernet/qlogic/qed/qed_fcoe.h
 create mode 100644 drivers/scsi/qedf/Kconfig
 create mode 100644 drivers/scsi/qedf/Makefile
 create mode 100644 drivers/scsi/qedf/qedf.h
 create mode 100644 drivers/scsi/qedf/qedf_attr.c
 create mode 100644 drivers/scsi/qedf/qedf_dbg.c
 create mode 100644 drivers/scsi/qedf/qedf_dbg.h
 create mode 100644 drivers/scsi/qedf/qedf_debugfs.c
 create mode 100644 drivers/scsi/qedf/qedf_els.c
 create mode 100644 drivers/scsi/qedf/qedf_fip.c
 create mode 100644 drivers/scsi/qedf/qedf_hsi.h
 create mode 100644 drivers/scsi/qedf/qedf_io.c
 create mode 100644 drivers/scsi/qedf/qedf_main.c
 create mode 100644 drivers/scsi/qedf/qedf_version.h
 create mode 100644 include/linux/qed/fcoe_common.h
 create mode 100644 include/linux/qed/qed_fcoe_if.h

-- 
1.8.5.6

Re: [PATCH net-next] net/sched: cls_flower: Disallow duplicate internal elements

[David Miller]

From: Paul Blakey 
Date: Mon, 16 Jan 2017 10:45:13 +0200

> Flower currently allows having the same filter twice with the same
> priority. Actions (and statistics update) will always execute on the
> first inserted rule leaving the second rule unused.
> This patch disallows that.
> 
> Signed-off-by: Paul Blakey 
> Acked-by: Jiri Pirko 

Applied, thanks.

Re: [PATCH V2] audit: log 32-bit socketcalls

[Paul Moore]

On Fri, Jan 13, 2017 at 9:42 AM, Eric Paris  wrote:
> On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
>> diff --git a/include/linux/audit.h b/include/linux/audit.h
>> index 9d4443f..43d8003 100644
>> --- a/include/linux/audit.h
>> +++ b/include/linux/audit.h
>> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs,
>> unsigned long *args)
>>   return __audit_socketcall(nargs, args);
>>   return 0;
>>  }
>> +static inline int audit_socketcall_compat(int nargs, u32 *args)
>> +{
>> + if (unlikely(!audit_dummy_context())) {
>
> I've always hated these likely/unlikely. Mostly because I think they
> are so often wrong. I believe this says that you compiled audit in but
> you expect it to be explicitly disabled. While that is (recently) true
> in Fedora I highly doubt that's true on the vast majority of systems
> that have audit compiled in.

Richard and I have talked about the likely/unlikely optimization
before and I know Richard likes to use them, but I don't for the
reasons Eric has already mentioned.   Richard, since you're respinning
the patch, go ahead and yank out the unlikely() call.

-- 
paul moore
www.paul-moore.com

Re: [PATCH] net: stmmac: don't use netdev_[dbg, info, ..] before net_device is registered

[David Miller]

From: Heiner Kallweit 
Date: Sun, 15 Jan 2017 19:19:00 +0100

> Don't use netdev_info and friends before the net_device is registered.
> This avoids ugly messages like
> "meson8b-dwmac c941.ethernet (unnamed net_device) (uninitialized):
> Enable RX Mitigation via HW Watchdog Timer"
> 
> Signed-off-by: Heiner Kallweit 

Indeed, this is a side-effect of the MDIO vs. register_netdev race fix
that went in the other week.

Applied, thanks.

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

[Florian Fainelli]

On 01/15/2017 11:16 AM, Andrew Lunn wrote:
>>> What exactly is the relationship between these devices (a ascii-art tree
>>> or sysfs tree output might be nice) so I can try to understand what is
>>> going on here.
> 
> Hi Greg, Florian
> 
> A few diagrams and trees which might help understand what is going on.
> 
> The first diagram comes from the 2008 patch which added all this code:
> 
> +---+   +---+
> |   | RGMII |   |
> |   +---+   +-- 1000baseT MDI ("WAN")
> |   |   |  6-port   +-- 1000baseT MDI ("LAN1")
> |CPU|   |  ethernet +-- 1000baseT MDI ("LAN2")
> |   |MIImgmt|  switch   +-- 1000baseT MDI ("LAN3")
> |   +---+  w/5 PHYs +-- 1000baseT MDI ("LAN4")
> |   |   |   |
> +---+   +---+
> 
> We have an ethernet switch and a host CPU. The switch is connected to
> the CPU in two different ways. RGMII allows us to get Ethernet frames
> from the CPU into the switch. MIImgmt, is the management bus normally
> used for Ethernet PHYs, but Marvell switches also use it for Managing
> switches.
> 
> The diagram above is the simplest setup. You can have multiple
> Ethernet switches, connected together via switch ports. Each switch
> has its own MIImgmt connect to the CPU, but there is only one RGMII
> link.
> 
> When this code was designed back in 2008, it was decided to represent
> this is a platform device, and it has a platform_data, which i have
> slightly edited to keep it simple:
> 
> struct dsa_platform_data {
> /*
>  * Reference to a Linux network interface that connects
>  * to the root switch chip of the tree.
>  */
> struct device   *netdev;
> 
> /*
>  * Info structs describing each of the switch chips
>  * connected via this network interface.
>  */
> int nr_chips;
> struct dsa_chip_data*chip;
> };
> 
> This netdev is the CPU side of the RGMII interface.
> 
> Each switch has a dsa_chip_data, again edited:
> 
> struct dsa_chip_data {
> /*
>  * How to access the switch configuration registers.
>  */
> struct device   *host_dev;
> int sw_addr;
> ...
> }
> 
> The host_dev is the CPU side of the MIImgmt, and we have the address
> the switch is using on the bus.
> 
> During probe of this platform device, we need to get from the
> struct device *netdev to a struct net_device *dev.
> 
> So the code looks in the device net class to find the device
> 
> |   |   |   |-- f1074000.ethernet
> |   |   |   |   |-- deferred_probe
> |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/mvneta
> |   |   |   |   |-- driver_override
> |   |   |   |   |-- modalias
> |   |   |   |   |-- net
> |   |   |   |   |   `-- eth1
> |   |   |   |   |   |-- addr_assign_type
> |   |   |   |   |   |-- address
> |   |   |   |   |   |-- addr_len
> |   |   |   |   |   |-- broadcast
> |   |   |   |   |   |-- carrier
> |   |   |   |   |   |-- carrier_changes
> |   |   |   |   |   |-- deferred_probe
> |   |   |   |   |   |-- device -> ../../../f1074000.ethernet
> 
> and then use container_of() to get the net_device.
> 
> Similarly, the code needs to get from struct device *host_dev to a struct 
> mii_bus *.
> 
> |   |   |   |-- f1072004.mdio
> |   |   |   |   |-- deferred_probe
> |   |   |   |   |-- driver -> ../../../../../bus/platform/drivers/orion-mdio
> |   |   |   |   |-- driver_override
> |   |   |   |   |-- mdio_bus
> |   |   |   |   |   `-- f1072004.mdio-mi
> |   |   |   |   |   |-- deferred_probe
> |   |   |   |   |   |-- device -> ../../../f1072004.mdio
> 

Thanks Andrew! Greg, does that make it clearer how these devices
references are used, do you still think the way this is done is wrong,
too cautious, or valid?
-- 
Florian

Re: [PATCH] qed: Replace memset with eth_zero_addr

[David Miller]

From: Shyam Saini 
Date: Tue, 17 Jan 2017 00:21:38 +0530

> Use eth_zero_addr to assign zero address to the given address array
> instead of memset when the second argument in memset is address
> of zero. Also, it makes the code clearer
> 
> Signed-off-by: Shyam Saini 

This patch does not apply cleanly to the net-next tree.

Please state if you don't understand what that means instead of
submitting this patch over and over again against the wrong source
tree.

Thanks.

Re: [PATCH net V2] net/mlx5e: Fix a -Wmaybe-uninitialized warning

[David Miller]

From: Or Gerlitz 
Date: Sun, 15 Jan 2017 19:50:46 +0200

> From: Arnd Bergmann 
> 
> As found by Olof's build bot, we gain a harmless warning about a
> potential uninitialized variable reference in mlx5:
> 
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 
> 'parse_tc_fdb_actions':
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:769:13: warning: 'out_dev' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:811:21: note: 'out_dev' was 
> declared here
> 
> This was introduced through the addition of an 'IS_ERR/PTR_ERR' pair
> that gcc is unfortunately unable to completely figure out.
> 
> The problem being gcc cannot tell that if(IS_ERR()) in
> mlx5e_route_lookup_ipv4() is equivalent to checking if(err) later,
> so it assumes that 'out_dev' is used after the 'return PTR_ERR(rt)'.
> 
> The PTR_ERR_OR_ZERO() case by comparison is fairly easy to detect
> by gcc, so it can't get that wrong, so it no longer warns.
> 
> Hadar Hen Zion already attempted to fix the warning earlier by adding fake
> initializations, but that ended up not fully addressing all warnings, so
> I'm reverting it now that it is no longer needed.
> 
> Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.10-rc3-98-gcff3b2c/
> Fixes: a42485eb0ee4 ("net/mlx5e: TC ipv4 tunnel encap offload error flow 
> fixes")
> Fixes: a757d108dc1a ("net/mlx5e: Fix kbuild warnings for uninitialized 
> parameters")
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: Or Gerlitz 
> ---
> changes from V1:
>  - kept calling ip_route_output_key() only when CONFIG_INET is defined

Applied.

Re: [PATCH net-next v2] ipv6: sr: add missing Kbuild export for header files

[David Miller]

From: David Lebrun 
Date: Sun, 15 Jan 2017 15:26:16 +0100

> Add missing IPv6-SR header files in include/uapi/linux/Kbuild.
> 
> Also, prevent seg6_lwt_headroom() from being exported and add
> missing linux/types.h include.
> 
> Signed-off-by: David Lebrun 

Applied, thanks.

Re: [PATCH net-next v3 1/1] net sched actions: Add support for user cookies

[David Miller]

Jamal, please don't mix coding style and real changes.

Have one patch that adds the user cookies and one that cleans up the
coding style stuff.

Thanks.

Re: [net-next 0/3] tipc: improve interaction socket-link

[David Miller]

From: Jon Maloy 
Date: Tue,  3 Jan 2017 10:26:45 -0500

> We fix a very real starvation problem that may occur when a link
> encounters send buffer congestion. At the same time we make the 
> interaction between the socket and link layer simpler and more 
> consistent.

This doesn't apply to net-next, also the Date in your emails is 10 days
in the past.  What's going on here?

Re: [PATCH net-next] bpf, trace: make ctx access checks more robust

[David Miller]

From: Daniel Borkmann 
Date: Sun, 15 Jan 2017 01:34:25 +0100

> Make sure that ctx cannot potentially be accessed oob by asserting
> explicitly that ctx access size into pt_regs for BPF_PROG_TYPE_KPROBE
> programs must be within limits. In case some 32bit archs have pt_regs
> not being a multiple of 8, then BPF_DW access could cause such access.
> 
> BPF_PROG_TYPE_KPROBE progs don't have a ctx conversion function since
> there's no extra mapping needed. kprobe_prog_is_valid_access() didn't
> enforce sizeof(long) as the only allowed access size, since LLVM can
> generate non BPF_W/BPF_DW access to regs from time to time.
> 
> For BPF_PROG_TYPE_TRACEPOINT we don't have a ctx conversion either, so
> add a BUILD_BUG_ON() check to make sure that BPF_DW access will not be
> a similar issue in future (ctx works on event buffer as opposed to
> pt_regs there).
> 
> Fixes: 2541517c32be ("tracing, perf: Implement BPF programs attached to 
> kprobes")
> Signed-off-by: Daniel Borkmann 
> Acked-by: Alexei Starovoitov 

Applied.

Re: [PATCH 1/1] ax25: Fix segfault after sock connection timeout

[David Miller]

From: Basil Gunn 
Date: Sat, 14 Jan 2017 12:18:55 -0800

> The ax.25 socket connection timed out & the sock struct has been
> previously taken down ie. sock struct is now a NULL pointer. Checking
> the sock_flag causes the segfault.  Check if the socket struct pointer
> is NULL before checking sock_flag. This segfault is seen in
> timed out netrom connections.
> 
> Please submit to -stable.
> 
> Signed-off-by: Basil Gunn 

This is consistent with the ax25->sk NULL check later in this function.

Applied and queued up for -stable, thanks.

Re: [PATCH next] ipvlan: fix dev_id creation corner case.

[David Miller]

From: Mahesh Bandewar 
Date: Fri, 13 Jan 2017 15:48:30 -0800

> From: Mahesh Bandewar 
> 
> In the last patch da36e13cf65 ("ipvlan: improvise dev_id generation
> logic in IPvlan") I missed some part of Dave's suggestion and because
> of that the dev_id creation could fail in a corner case scenario. This
> would happen when more or less 64k devices have been already created and
> several have been deleted. If the devices that are still sticking around
> are the last n bits from the bitmap. So in this scenario even if lower
> bits are available, the dev_id search is so narrow that it always fails.
> 
> Fixes: da36e13cf65 ("ipvlan: improvise dev_id generation logic in IPvlan")
> CC: David Miller 
> CC: Eric Dumazet 
> Signed-off-by: Mahesh Bandewar 

Applied, thanks.

Re: [PATCH net] bpf: rework prog_digest into prog_tag

[David Miller]

From: Daniel Borkmann 
Date: Fri, 13 Jan 2017 23:38:15 +0100

> Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
> fdinfo/netlink") was recently discussed, partially due to
> admittedly suboptimal name of "prog_digest" in combination
> with sha1 hash usage, thus inevitably and rightfully concerns
> about its security in terms of collision resistance were
> raised with regards to use-cases.
> 
> The intended use cases are for debugging resp. introspection
> only for providing a stable "tag" over the instruction sequence
> that both kernel and user space can calculate independently.
> It's not usable at all for making a security relevant decision.
> So collisions where two different instruction sequences generate
> the same tag can happen, but ideally at a rather low rate. The
> "tag" will be dumped in hex and is short enough to introspect
> in tracepoints or kallsyms output along with other data such
> as stack trace, etc. Thus, this patch performs a rename into
> prog_tag and truncates the tag to a short output (64 bits) to
> make it obvious it's not collision-free.
> 
> Should in future a hash or facility be needed with a security
> relevant focus, then we can think about requirements, constraints,
> etc that would fit to that situation. For now, rework the exposed
> parts for the current use cases as long as nothing has been
> released yet. Tested on x86_64 and s390x.
> 
> Fixes: 7bd509e311f4 ("bpf: add prog_digest and expose it via fdinfo/netlink")
> Signed-off-by: Daniel Borkmann 
> Acked-by: Alexei Starovoitov 

Applied, thanks.

Re: [PATCH net-next 0/2] sfc: TX PIO fixes

[David Miller]

From: Edward Cree 
Date: Fri, 13 Jan 2017 21:18:38 +

> Edward Cree (2):
>   sfc: allow PIO more often
>   sfc: get PIO buffer size from the NIC

Both patches applied, thanks.

When you give me a completely content free header posting like this, it
is basically worthless to me and I don't even use it.

Please put some real content into this header posting, explaining what
the series is doing at a high level, how it is doing it, and why it is
doing it that way.

Thanks.

Re: [PATCH] stmicro: rename it to dwc to improve future development

[David Miller]

From: Joao Pinto 
Date: Mon, 16 Jan 2017 13:26:31 +

> The goal of this patch is to create an oficial Designware Ethernet place
> to deploy new drivers based on this family of IPs. stmmac was left
> untouched since it is a designware based driver. New ethernet designware
> IP based drivers should be placed in this place, improving code organization
> and it becomes clear to the kernel user the purpose and scope of each driver.
> 
> Signed-off-by: Joao Pinto 

Sorry, I am not applying this.

This would mean that every single -stable backport of a fix to this
driver would require fixing up the directory and/or file name of every
single change without any exception.

This is an unreasonable burdon to put upon me, and every single person
who has to backport bug fixes into older releases of the kernel.

Please stop submitting this rename change.  It is fine to leave the
driver with the stmmac name, and there is zero user benefit to the
rename and only negatives for people who have to work on backports.

I saw no agreement reached between yourself and anyone who voiced
opposition to this driver rename.  Therefore it was entirely
inappropriate for you to resubmit this change again.

I heard very clearly your argument that you would help with the problem
with the backports, but that is a completely empty gesture.  Here's why.

You cannot help with the problem, nor can any other developer working
on this driver.  People all over the world are going to want to
backport this patch or that, and I myself work in my own little
routine and can't depend on having to have a back and forth with you
over and over again for every single fix to this driver I decide is
reasonable for a -stable backport.

Re: [PATCH net-next] sctp: remove useless code from sctp_apply_peer_addr_params

[David Miller]

From: Marcelo Ricardo Leitner 
Date: Fri, 13 Jan 2017 18:31:15 -0200

> sctp_frag_point() doesn't store anything, and thus just calling it
> cannot do anything useful.
> 
> sctp_apply_peer_addr_params is only called by
> sctp_setsockopt_peer_addr_params. When operating on an asoc,
> sctp_setsockopt_peer_addr_params will call sctp_apply_peer_addr_params
> once for the asoc, and then once for each transport this asoc has,
> meaning that the frag_point will be recomputed when updating the
> transports and calling it when updating the asoc is not necessary.
> IOW, no action is needed here and we can remove this call.
> 
> Signed-off-by: Marcelo Ricardo Leitner 

Applied, but please put "[PATCH net-next v2]" or some other indication
in your Subject line so that new revisions of a patch are easily
discernable.

Thanks.

Re: [PATCH net-next] sctp: remove unused var from sctp_process_asconf

[David Miller]

From: Marcelo Ricardo Leitner 
Date: Fri, 13 Jan 2017 18:27:33 -0200

> Assigned but not used.
> 
> Signed-off-by: Marcelo Ricardo Leitner 

Applied.

[PATCH] qed: Replace memset with eth_zero_addr

[Shyam Saini]

Use eth_zero_addr to assign zero address to the given address array
instead of memset when the second argument in memset is address
of zero. Also, it makes the code clearer

Signed-off-by: Shyam Saini 
---
 drivers/net/ethernet/qlogic/qed/qed_l2.c| 2 +-
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 7 +++
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c 
b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 6a3727c..778c52c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1776,7 +1776,7 @@ static int qed_fill_eth_dev_info(struct qed_dev *cdev,
qed_fill_dev_info(cdev, >common);
 
if (IS_VF(cdev))
-   memset(info->common.hw_mac, 0, ETH_ALEN);
+   eth_zero_addr(info->common.hw_mac);
 
return 0;
 }
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 85b09dd..a15fff4 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -1199,7 +1199,7 @@ static void qed_iov_clean_vf(struct qed_hwfn *p_hwfn, u8 
vfid)
return;
 
/* Clear the VF mac */
-   memset(vf_info->mac, 0, ETH_ALEN);
+   eth_zero_addr(vf_info->mac);
 }
 
 static void qed_iov_vf_cleanup(struct qed_hwfn *p_hwfn,
@@ -2539,8 +2539,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn 
*p_hwfn,
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++) {
if (ether_addr_equal(p_vf->shadow_config.macs[i],
 p_params->mac)) {
-   memset(p_vf->shadow_config.macs[i], 0,
-  ETH_ALEN);
+   eth_zero_addr(p_vf->shadow_config.macs[i]);
break;
}
}
@@ -2553,7 +2552,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn 
*p_hwfn,
} else if (p_params->opcode == QED_FILTER_REPLACE ||
   p_params->opcode == QED_FILTER_FLUSH) {
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++)
-   memset(p_vf->shadow_config.macs[i], 0, ETH_ALEN);
+   eth_zero_addr(p_vf->shadow_config.macs[i]);
}
 
/* List the new MAC address */
-- 
2.7.4

Re: [PATCHv3 net-next 1/7] sctp: add a common helper function to generate stream reconf chunk

[David Miller]

From: Xin Long 
Date: Sat, 14 Jan 2017 03:15:35 +0800

> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> index a15d824..fd58097 100644
> --- a/net/sctp/sm_make_chunk.c
> +++ b/net/sctp/sm_make_chunk.c
> @@ -3526,3 +3526,36 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct 
> sctp_association *asoc,
>  
>   return retval;
>  }
> +
> +/* RE-CONFIG 3.1 (RE-CONFIG chunk)
> + *   0   1   2   3
> + *   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> + *  | Type = 130|  Chunk Flags  |  Chunk Length |
> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> + *  \   \
> + *  /  Re-configuration Parameter   /
> + *  \   \
> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> + *  \   \
> + *  / Re-configuration Parameter (optional) /
> + *  \   \
> + *  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> + */
> +static struct sctp_chunk *sctp_make_reconf(
> + const struct sctp_association *asoc,
> + int length)
> +{
> + struct sctp_reconf_chunk *reconf;

This patch will cause a warning because this new static function is unused.

All patch series must be fully bisectable, that measn at each step of
the patch series the tree must work properly and not introduce new
build warnings or build failures.

Re: [PATCH][V2] flow dissector: check if arp_eth is null rather than arp

[David Miller]

From: Colin King 
Date: Fri, 13 Jan 2017 18:48:20 +

> From: Colin Ian King 
> 
> arp is being checked instead of arp_eth to see if the call to
> __skb_header_pointer failed. Fix this by checking arp_eth is
> null instead of arp.   Also fix to use length hlen rather than
> hlen - sizeof(_arp); thanks to Eric Dumazet for spotting
> this latter issue.
> 
> CoverityScan CID#1396428 ("Logically dead code") on 2nd
> arp comparison (which should be arp_eth instead).
> 
> Fixes: commit 55733350e5e8b70c5 ("flow disector: ARP support")
> Signed-off-by: Colin Ian King 

Applied, thanks.

Re: [PATCH] net: constify mdiobb_ops structures

[David Miller]

From: Bhumika Goyal 
Date: Fri, 13 Jan 2017 23:32:26 +0530

> Declare mdiobb_ops structures as const as they are only stored in the
> ops field of mdiobb_ctrl structures. This field is of type const, so
> mdiobb_ops structures having this property can be declared const too.

This patch doesn't apply cleanly to net-next, please respin.

Re: [PATCH net-next] netlink: do not enter direct reclaim from netlink_trim()

[David Miller]

From: Eric Dumazet 
Date: Fri, 13 Jan 2017 09:11:22 -0800

> From: Eric Dumazet 
> 
> In commit d35c99ff77ecb ("netlink: do not enter direct reclaim from
> netlink_dump()") we made sure to not trigger expensive memory reclaim.
> 
> Problem is that a bit later, netlink_trim() might be called and
> trigger memory reclaim.
> 
> netlink_trim() should be best effort, and really as fast as possible.
> Under memory pressure, it is fine to not trim this skb.
> 
> Signed-off-by: Eric Dumazet 

Applied, thanks Eric.

Re: [PATCH 1/3] powerpc: bpf: remove redundant check for non-null image

[David Miller]

I'm assuming these patches will go via the powerpc tree.

If you want them to go into net-next, I kindly ask that you always
explicitly say so, and furthermore always submit a patch series with
a proper "[PATCH 0/N] ..." header posting.

Thanks.

Re: [PATCH V2] audit: log 32-bit socketcalls

[David Miller]

From: Richard Guy Briggs 
Date: Fri, 13 Jan 2017 04:51:48 -0500

> diff --git a/include/linux/audit.h b/include/linux/audit.h
> index 9d4443f..43d8003 100644
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs, unsigned 
> long *args)
>   return __audit_socketcall(nargs, args);
>   return 0;
>  }
> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> +{

Please put an empty line between function definitions.

> + if (unlikely(!audit_dummy_context())) {
> + int i;
> + unsigned long a[AUDITSC_ARGS];

Please order local variable declarations from longest to shortest line.

> +
> + for (i=0; i + a[i] = (unsigned long)args[i];
> + return __audit_socketcall(nargs, a);
> + }
> + return 0;
> +}
>  static inline int audit_sockaddr(int len, void *addr)

Again, empty line between function definitions please.

> @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct 
> compat_mmsghdr __user *, mmsg,
>  
>  COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
>  {
> + unsigned int len;
>   int ret;
> - u32 a[6];
> + u32 a[AUDITSC_ARGS];
>   u32 a0, a1;

Longest to shortest line for local variable declarations please.

Re: [PATCH net-next] cxgb4: Shutdown adapter if firmware times out or errors out

[David Miller]

From: Hariprasad Shenai 
Date: Fri, 13 Jan 2017 21:55:26 +0530

> Perform an emergency shutdown of the adapter and stop it from
> continuing any further communication on the ports or DMA to the
> host. This is typically used when the adapter and/or firmware
> have crashed and we want to prevent any further accidental
> communication with the rest of the world. This will also force
> the port Link Status to go down -- if register writes work --
> which should help our peers figure out that we're down.
> 
> Signed-off-by: Hariprasad Shenai 

Applied, thank you.

Re: [PATCH net v1 1/1] tipc: allocate user memory with GFP_KERNEL flag

[David Miller]

From: Parthasarathy Bhuvaragan 
Date: Fri, 13 Jan 2017 15:46:25 +0100

> Until now, we allocate memory always with GFP_ATOMIC flag.
> When the system is under memory pressure and a user tries to send,
> the send fails due to low memory. However, the user application
> can wait for free memory if we allocate it using GFP_KERNEL flag.
> 
> In this commit, we use allocate memory with GFP_KERNEL for all user
> allocation.
> 
> Reported-by: Rune Torgersen 
> Acked-by: Jon Maloy 
> Signed-off-by: Parthasarathy Bhuvaragan 
> 

Applied.

Re: [PATCH net-next] afs: Conditionalise a new unused variable

[David Miller]

From: David Howells 
Date: Fri, 13 Jan 2017 14:46:19 +

> From: Arnd Bergmann 
> 
> The bulk readpages support introduced a harmless warning:
> 
> fs/afs/file.c: In function 'afs_readpages_page_done':
> fs/afs/file.c:270:20: error: unused variable 'vnode' [-Werror=unused-variable]
> 
> This adds an #ifdef to match the user of that variable.  The user of the
> variable has to be conditional because it accesses a member of a struct
> that is also conditional.
> 
> Fixes: 91b467e0a3f5 ("afs: Make afs_readpages() fetch data in bulk")
> Signed-off-by: Arnd Bergmann 
> Signed-off-by: David Howells 

Applied.

Re: [PATCH] net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types

[David Miller]

From: Murali Karicheri 
Date: Fri, 13 Jan 2017 09:32:34 -0500

> Currently dp83867 driver returns error if phy interface type
> PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
> delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
> Fix this by checking also the interface type if a particular delay
> value is missing in the phy dt bindings. Also update the DT document
> accordingly.
> 
> Signed-off-by: Murali Karicheri 
> Signed-off-by: Sekhar Nori 

Applied, thanks.

Re: [PATCH] qed: Replace memset with eth_zero_addr

[David Miller]

From: Shyam Saini 
Date: Mon, 16 Jan 2017 23:33:30 +0530

> Use eth_zero_addr to assign zero address to the given address array
> instead of memset when the second argument in memset is address
> of zero. Also, it makes the code clearer
> 
> Signed-off-by: Shyam Saini 

This doesn't apply cleanly to net-next, please respin.

Re: [PATCH net] ip6_tunnel: Account for tunnel header in tunnel MTU

[David Miller]

From: Jakub Sitnicki 
Date: Fri, 13 Jan 2017 10:12:20 +0100

> With ip6gre we have a tunnel header which also makes the tunnel MTU
> smaller. We need to reserve room for it. Previously we were using up
> space reserved for the Tunnel Encapsulation Limit option
> header (RFC 2473).
> 
> Also, after commit b05229f44228 ("gre6: Cleanup GREv6 transmit path,
> call common GRE functions") our contract with the caller has
> changed. Now we check if the packet length exceeds the tunnel MTU after
> the tunnel header has been pushed, unlike before.
> 
> This is reflected in the check where we look at the packet length minus
> the size of the tunnel header, which is already accounted for in tunnel
> MTU.
> 
> Fixes: b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE 
> functions")
> Signed-off-by: Jakub Sitnicki 

Applied and queued up for -stable, thanks.

Re: [PATCH v2] net/irda: fix lockdep annotation

[kbuild test robot]

Hi Dmitry,

[auto build test ERROR on tip/locking/core]
[also build test ERROR on v4.10-rc4 next-20170116]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dmitry-Vyukov/net-irda-fix-lockdep-annotation/20170117-001737
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/linux/mmzone.h:7:0,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/gpu/drm/i915/i915_sw_fence.c:10:
   drivers/gpu/drm/i915/i915_sw_fence.c: In function 
'__i915_sw_fence_wake_up_all':
>> include/linux/spinlock.h:217:3: error: void value not ignored as it ought to 
>> be
  (void)subclass;  \
   
>> include/linux/spinlock.h:335:2: note: in expansion of macro 
>> 'raw_spin_lock_irqsave_nested'
 raw_spin_lock_irqsave_nested(spinlock_check(lock), flags, subclass); \
 ^~~~
>> drivers/gpu/drm/i915/i915_sw_fence.c:68:2: note: in expansion of macro 
>> 'spin_lock_irqsave_nested'
 spin_lock_irqsave_nested(>lock, flags, 1 + !!continuation);
 ^~~~

vim +217 include/linux/spinlock.h

   211  typecheck(unsigned long, flags);
\
   212  flags = _raw_spin_lock_irqsave_nested(lock, subclass);  
\
   213  } while (0)
   214  #else
   215  #define raw_spin_lock_irqsave_nested(lock, flags, subclass) 
\
   216  do {
\
 > 217  (void)subclass; 
 > \
   218  typecheck(unsigned long, flags);
\
   219  flags = _raw_spin_lock_irqsave(lock);   
\
   220  } while (0)
   221  #endif
   222  
   223  #else
   224  
   225  #define raw_spin_lock_irqsave(lock, flags)  \
   226  do {\
   227  typecheck(unsigned long, flags);\
   228  _raw_spin_lock_irqsave(lock, flags);\
   229  } while (0)
   230  
   231  #define raw_spin_lock_irqsave_nested(lock, flags, subclass) \
   232  raw_spin_lock_irqsave(lock, flags)
   233  
   234  #endif
   235  
   236  #define raw_spin_lock_irq(lock) _raw_spin_lock_irq(lock)
   237  #define raw_spin_lock_bh(lock)  _raw_spin_lock_bh(lock)
   238  #define raw_spin_unlock(lock)   _raw_spin_unlock(lock)
   239  #define raw_spin_unlock_irq(lock)   _raw_spin_unlock_irq(lock)
   240  
   241  #define raw_spin_unlock_irqrestore(lock, flags) \
   242  do {\
   243  typecheck(unsigned long, flags);\
   244  _raw_spin_unlock_irqrestore(lock, flags);   \
   245  } while (0)
   246  #define raw_spin_unlock_bh(lock)_raw_spin_unlock_bh(lock)
   247  
   248  #define raw_spin_trylock_bh(lock) \
   249  __cond_lock(lock, _raw_spin_trylock_bh(lock))
   250  
   251  #define raw_spin_trylock_irq(lock) \
   252  ({ \
   253  local_irq_disable(); \
   254  raw_spin_trylock(lock) ? \
   255  1 : ({ local_irq_enable(); 0;  }); \
   256  })
   257  
   258  #define raw_spin_trylock_irqsave(lock, flags) \
   259  ({ \
   260  local_irq_save(flags); \
   261  raw_spin_trylock(lock) ? \
   262  1 : ({ local_irq_restore(flags); 0; }); \
   263  })
   264  
   265  /**
   266   * raw_spin_can_lock - would raw_spin_trylock() succeed?
   267   * @lock: the spinlock in question.
   268   */
   269  #define raw_spin_can_lock(lock) (!raw_spin_is_locked(lock))
   270  
   271  /* Include rwlock functions */
   272  #include 
   273  
   274  /*
   275   * Pull the _spin_*()/_read_*()/_write_*() functions/declarations:
   276   */
   277  #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK)
   278  # include 
   279  #else
   280  # include 
   281  #endif
   282  
   283  /*
   284   * Map the spin_lock functions to the raw variants for PREEMPT_RT=n
   285   */
   286  
   287  static __always_inline raw_spinlock_t *spinlock_check(spinlock_t *lock)
   288  {
   289  return >rlock;
   290  }
   291  
   292  #define spin_lock_init(_lock)   \
   293  do {\
   294  spinlock_check(_lock);  \
   295  raw_spin_lock_init(&(_lock)->rlock);\
   296  } while (0)
   297  
   298  static __al

[PATCH] qed: Replace memset with eth_zero_addr

[Shyam Saini]

Use eth_zero_addr to assign zero address to the given address array
instead of memset when the second argument in memset is address
of zero. Also, it makes the code clearer

Signed-off-by: Shyam Saini 
---
 drivers/net/ethernet/qlogic/qed/qed_l2.c| 2 +-
 drivers/net/ethernet/qlogic/qed/qed_sriov.c | 7 +++
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c 
b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 6a3727c..778c52c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1776,7 +1776,7 @@ static int qed_fill_eth_dev_info(struct qed_dev *cdev,
qed_fill_dev_info(cdev, >common);
 
if (IS_VF(cdev))
-   memset(info->common.hw_mac, 0, ETH_ALEN);
+   eth_zero_addr(info->common.hw_mac);
 
return 0;
 }
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c 
b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index 85b09dd..a15fff4 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -1199,7 +1199,7 @@ static void qed_iov_clean_vf(struct qed_hwfn *p_hwfn, u8 
vfid)
return;
 
/* Clear the VF mac */
-   memset(vf_info->mac, 0, ETH_ALEN);
+   eth_zero_addr(vf_info->mac);
 }
 
 static void qed_iov_vf_cleanup(struct qed_hwfn *p_hwfn,
@@ -2539,8 +2539,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn 
*p_hwfn,
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++) {
if (ether_addr_equal(p_vf->shadow_config.macs[i],
 p_params->mac)) {
-   memset(p_vf->shadow_config.macs[i], 0,
-  ETH_ALEN);
+   eth_zero_addr(p_vf->shadow_config.macs[i]);
break;
}
}
@@ -2553,7 +2552,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn 
*p_hwfn,
} else if (p_params->opcode == QED_FILTER_REPLACE ||
   p_params->opcode == QED_FILTER_FLUSH) {
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++)
-   memset(p_vf->shadow_config.macs[i], 0, ETH_ALEN);
+   eth_zero_addr(p_vf->shadow_config.macs[i]);
}
 
/* List the new MAC address */
-- 
2.7.4

Re: [PATCH iproute2 1/1] utils: make hex2mem available to all users

[Stephen Hemminger]

On Sat, 14 Jan 2017 17:09:58 -0500
Jamal Hadi Salim  wrote:

> Sorry, messed up Stephen's address. Resending..
> 
> cheers,
> jamal

No problem. I get almost all patches only from patchwork anyway.

Re: [PATCH] net: marvell: skge: use new api ethtool_{get|set}_link_ksettings

[Stephen Hemminger]

On Mon, 16 Jan 2017 12:36:17 -0500 (EST)
David Miller  wrote:

> From: Stephen Hemminger 
> Date: Mon, 16 Jan 2017 09:29:51 -0800
> 
> > On Sat, 14 Jan 2017 13:08:28 +0100
> > Philippe Reynes  wrote:
> >   
> >> The ethtool api {get|set}_settings is deprecated.
> >> We move this driver to new api {get|set}_link_ksettings.
> >> 
> >> The callback set_link_ksettings no longer update the value
> >> of advertising, as the struct ethtool_link_ksettings is
> >> defined as const.
> >> 
> >> Signed-off-by: Philippe Reynes   
> > 
> > Did you test this on real hardware?  
> 
> Philippe probably doesn't have physical access to most of the
> drivers he is converting.
> 
> But, he is the only person working on converting all of the drivers,
> and therefore when the change looks straightforward I am going to
> reward his work and effort by applying his changes and hope there
> isn't any fallout.
> 
> Those who really care can test his patches and give a Tested-by:
> 
> Thanks.

Yes, it looks mechanical and should be applied. There are lots of pieces of
old hardware that no developer is running, and if we required full test suite 
runs
on all drivers, then no refactoring would ever be possible.

My preference is to always add commit note that the patch was compile
tested only so that if someone has a problem with real hardware then they know
what to suspect.

Re: [PATCH net] mld: do not remove mld souce list info when set link down

[David Miller]

From: Hangbin Liu 
Date: Thu, 12 Jan 2017 21:19:37 +0800

> This is an IPv6 version of commit 24803f38a5c0 ("igmp: do not remove igmp
> souce list..."). In mld_del_delrec(), we will restore back all source filter
> info instead of flush them.
> 
> Move mld_clear_delrec() from ipv6_mc_down() to ipv6_mc_destroy_dev() since
> we should not remove source list info when set link down. Remove
> igmp6_group_dropped() in ipv6_mc_destroy_dev() since we have called it in
> ipv6_mc_down().
> 
> Also clear all source info after igmp6_group_dropped() instead of in it
> because ipv6_mc_down() will call igmp6_group_dropped().
> 
> Signed-off-by: Hangbin Liu 

Applied.

Re: [PATCH net-next 3/3] net: ipv6: Add option to dump multipath routes via RTA_MULTIPATH attribute

[David Ahern]

upon further review ...

On 1/15/17 1:07 PM, David Ahern wrote:
> To maintain backwards compatibility, a user has to request the change
> in behavior. Unfortunately, adding a flag to the header similar to a
> previous patch does not work here as the netlink header for route dumps
> can be either rtgenmsg or ifinfomsg. sysctl is the other commonly used
> option for backwards compatibility but it is overly abused and is not
> really appropriate for this situation since each request should be able
> to specify the preference for the RTA_MULTIPATH attribute (e.g, one
> command may understand RTA_MULTIPATH for IPv6 while another may not).

The ancillary header is supposed to be struct rtmsg, so the change in behavior 
can be done by requiring the rtmsg struct and then passing the 
RTM_F_ALL_NEXTHOPS flag in rtm_flags. This makes the user api for delete 
requests and dumps consistent.

...

> @@ -422,9 +436,22 @@ static int inet6_dump_fib(struct sk_buff *skb, struct 
> netlink_callback *cb)
>   cb->args[2] = (long)w;
>   }
>  
> + hdrlen = nlmsg_len(cb->nlh) < sizeof(struct ifinfomsg) ?
> +  sizeof(struct rtgenmsg) : sizeof(struct ifinfomsg);
> +
> + if (nlmsg_parse(cb->nlh, hdrlen, nlattr, RTA_MAX, NULL) >= 0) {
> + /* existence of RTA_MULTIPATH attribute in dump
> +  * request means user wants multipath routes
> +  * returned using RTA_MULTIPATH attribute
> +  */
> + if (nlattr[RTA_MULTIPATH])
> + flags |= RTM_F_ALL_NEXTHOPS;
> + }
> +

And the above becomes:

+   /* sadly, the size of the ancillary header can vary: the correct
+* header is struct rtmsg as passed by libnl. iproute2 sends
+* ifinfomsg [+ filter]. Technically, passing only rtgenmsg is
+* sufficient since the header has not been parsed before. Luckily,
+* the struct sizes sufficiently vary to detect the permutations.
+* For the dump request to contain flags require rtmsg header.
+*/
+   if (nlmsg_len(cb->nlh) == sizeof(struct rtmsg)) {
+   struct rtmsg *rtm = nlmsg_data(cb->nlh);
+
+   flags = rtm->rtm_flags;
+   }

Re: [PATCH 1/2] qed: Replace memset with eth_zero_addr

[Shyam Saini]

On Mon, Jan 16, 2017 at 11:46:06AM -0500, David Miller wrote:
> From: Shyam Saini 
> Date: Mon, 16 Jan 2017 14:54:35 +0530
> 
> > On Sun, Jan 15, 2017 at 11:38:30PM -0500, David Miller wrote:
> >> 
> >> Please do not ever submit two patches which have the same exact commit
> >> header line, as these two patches do.
> >> 
> >> When someone looks into the shortlog of GIT history all they will see
> >> is "qed: Replace memset with eth_zero_addr" twice.
> >> 
> >> This gives the reader no idea what might be different between those
> >> two changes.
> >> 
> >> Therefore you must give unique a commit header text for each change,
> >> which communicates sufficiently what is different in each change.
> > 
> > Thanks a lot for correcting me. I'll take care of this thing.
> > 
> > I'm resending these two patches as 
> > 1). qed: Replace memset with eth_zero_addr
> > 2). qed: Use eth_zero_addr
> > 
> > I hope it resolves same commit header line conflict.
> 
> You aren't understanding the point.
> 
> Those two lines still say exactly the same thing.
> 
> What is different about these two changes?  The answer to that question
> must propagate into those lines of text.

I got your point now. As pointed by you and Mintz,  I'll resend it
as a single patch. 

I sincerely appreciate your efforts for making things clearer and
correcting me.

Thanks a lot,
Shyam

[PATCH net-next 1/9] net/mlx4: Replace ENOSYS with better fitting error codes

[Tariq Toukan]

Conform the following warning:
WARNING: ENOSYS means 'invalid syscall nr' and nothing else.

Signed-off-by: Tariq Toukan 
---
 drivers/net/ethernet/mellanox/mlx4/en_ethtool.c   | 2 +-
 drivers/net/ethernet/mellanox/mlx4/fw.c   | 2 +-
 drivers/net/ethernet/mellanox/mlx4/main.c | 6 +++---
 drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c 
b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index d9c9f86a30df..63f5b0ab95d6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -1985,7 +1985,7 @@ static int mlx4_en_get_module_info(struct net_device *dev,
modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
break;
default:
-   return -ENOSYS;
+   return -EINVAL;
}
 
return 0;
diff --git a/drivers/net/ethernet/mellanox/mlx4/fw.c 
b/drivers/net/ethernet/mellanox/mlx4/fw.c
index 84bab9f0732e..25b5b32e958f 100644
--- a/drivers/net/ethernet/mellanox/mlx4/fw.c
+++ b/drivers/net/ethernet/mellanox/mlx4/fw.c
@@ -672,7 +672,7 @@ int mlx4_QUERY_FUNC_CAP(struct mlx4_dev *dev, u8 
gen_or_port,
MLX4_GET(field, outbox, QUERY_FUNC_CAP_PHYS_PORT_OFFSET);
func_cap->physical_port = field;
if (func_cap->physical_port != gen_or_port) {
-   err = -ENOSYS;
+   err = -EINVAL;
goto out;
}
 
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c 
b/drivers/net/ethernet/mellanox/mlx4/main.c
index bffa6f345f2f..6efd66b0b822 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -838,7 +838,7 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
 */
if (hca_param.global_caps) {
mlx4_err(dev, "Unknown hca global capabilities\n");
-   return -ENOSYS;
+   return -EINVAL;
}
 
mlx4_log_num_mgm_entry_size = hca_param.log_mc_entry_sz;
@@ -896,7 +896,7 @@ static int mlx4_slave_cap(struct mlx4_dev *dev)
PF_CONTEXT_BEHAVIOUR_MASK) {
mlx4_err(dev, "Unknown pf context behaviour %x known flags 
%x\n",
 func_cap.pf_context_behaviour, 
PF_CONTEXT_BEHAVIOUR_MASK);
-   return -ENOSYS;
+   return -EINVAL;
}
 
dev->caps.num_ports = func_cap.num_ports;
@@ -3492,7 +3492,7 @@ static int mlx4_load_one(struct pci_dev *pdev, int 
pci_dev_data,
mlx4_enable_msi_x(dev);
if ((mlx4_is_mfunc(dev)) &&
!(dev->flags & MLX4_FLAG_MSI_X)) {
-   err = -ENOSYS;
+   err = -ENOTSUPP;
mlx4_err(dev, "INTx is not supported in multi-function mode, 
aborting\n");
goto err_free_eq;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c 
b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 56185a0b827d..13cb47363db6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -1396,7 +1396,7 @@ static int remove_ok(struct res_common *res, enum 
mlx4_resource type, int extra)
case RES_MTT:
return remove_mtt_ok((struct res_mtt *)res, extra);
case RES_MAC:
-   return -ENOSYS;
+   return -ENOTSUPP;
case RES_EQ:
return remove_eq_ok((struct res_eq *)res);
case RES_COUNTER:
-- 
1.8.3.1

[PATCH net-next 3/9] net/mlx4_core: Set EQ affinity hint to local NUMA CPUs

[Tariq Toukan]

From: Daniel Jurgens 

Use CPUs on the close NUMA when setting the EQ affinity hints.

Signed-off-by: Daniel Jurgens 
Signed-off-by: Tariq Toukan 
---
 drivers/net/ethernet/mellanox/mlx4/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c 
b/drivers/net/ethernet/mellanox/mlx4/main.c
index 6efd66b0b822..058531bf7947 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -2843,7 +2843,8 @@ static int mlx4_init_affinity_hint(struct mlx4_dev *dev, 
int port, int eqn)
if (!zalloc_cpumask_var(>affinity_mask, GFP_KERNEL))
return -ENOMEM;
 
-   cpumask_set_cpu(requested_cpu, eq->affinity_mask);
+   cpumask_set_cpu(cpumask_local_spread(requested_cpu, dev->numa_node),
+   eq->affinity_mask);
 
return 0;
 }
-- 
1.8.3.1

[PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool

[Tariq Toukan]

From: Ariel Levkovich 

This feature will allow the user to disable auto negotiation
on the port for mlx4 devices while setting the speed is limited
to 1GbE speeds.
Other speeds will not be accepted in autoneg off mode.

Signed-off-by: Ariel Levkovich 
Signed-off-by: Tariq Toukan 
---
 drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 24 +++-
 include/linux/mlx4/device.h |  7 ++-
 2 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c 
b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
index 0ab644b6c2e6..5d11433fcc37 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
@@ -902,6 +902,7 @@ static __be32 speed_set_ptys_admin(struct mlx4_en_priv 
*priv, u32 speed,
struct mlx4_en_priv *priv = netdev_priv(dev);
struct mlx4_ptys_reg ptys_reg;
__be32 proto_admin;
+   u8 cur_autoneg;
int ret;
 
u32 ptys_adv = ethtool2ptys_link_modes(
@@ -931,10 +932,21 @@ static __be32 speed_set_ptys_admin(struct mlx4_en_priv 
*priv, u32 speed,
return 0;
}
 
-   proto_admin = link_ksettings->base.autoneg == AUTONEG_ENABLE ?
-   cpu_to_be32(ptys_adv) :
-   speed_set_ptys_admin(priv, speed,
-ptys_reg.eth_proto_cap);
+   cur_autoneg = ptys_reg.flags & MLX4_PTYS_AN_DISABLE_ADMIN ?
+   AUTONEG_DISABLE : AUTONEG_ENABLE;
+
+   if (link_ksettings->base.autoneg == AUTONEG_DISABLE) {
+   proto_admin = speed_set_ptys_admin(priv, speed,
+  ptys_reg.eth_proto_cap);
+   if ((be32_to_cpu(proto_admin) &
+(MLX4_PROT_MASK(MLX4_1000BASE_CX_SGMII) |
+ MLX4_PROT_MASK(MLX4_1000BASE_KX))) &&
+   (ptys_reg.flags & MLX4_PTYS_AN_DISABLE_CAP))
+   ptys_reg.flags |= MLX4_PTYS_AN_DISABLE_ADMIN;
+   } else {
+   proto_admin = cpu_to_be32(ptys_adv);
+   ptys_reg.flags &= ~MLX4_PTYS_AN_DISABLE_ADMIN;
+   }
 
proto_admin &= ptys_reg.eth_proto_cap;
if (!proto_admin) {
@@ -942,7 +954,9 @@ static __be32 speed_set_ptys_admin(struct mlx4_en_priv 
*priv, u32 speed,
return -EINVAL; /* nothing to change due to bad input */
}
 
-   if (proto_admin == ptys_reg.eth_proto_admin)
+   if ((proto_admin == ptys_reg.eth_proto_admin) &&
+   ((ptys_reg.flags & MLX4_PTYS_AN_DISABLE_CAP) &&
+(link_ksettings->base.autoneg == cur_autoneg)))
return 0; /* Nothing to change */
 
en_dbg(DRV, priv, "mlx4_ACCESS_PTYS_REG SET: ptys_reg.eth_proto_admin = 
0x%x\n",
diff --git a/include/linux/mlx4/device.h b/include/linux/mlx4/device.h
index 6533c16e27ad..c3ac945b2759 100644
--- a/include/linux/mlx4/device.h
+++ b/include/linux/mlx4/device.h
@@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
MLX4_PTYS_EN = 1<<2,
 };
 
+enum mlx4_ptys_flags {
+   MLX4_PTYS_AN_DISABLE_CAP   = 1 << 5,
+   MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6,
+};
+
 struct mlx4_ptys_reg {
-   u8 resrvd1;
+   u8 flags;
u8 local_port;
u8 resrvd2;
u8 proto_mask;
-- 
1.8.3.1