Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool
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
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
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
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(&cpuset);
- CPU_SET(next_to_try++, &cpuset);
- if (!sched_setaffinity(pid, sizeof(cpuset), &cpuset))
+ CPU_SET(next++, &cpuset);
+ if (!sched_setaffinity(pid, sizeof(cpuset), &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, &next_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, &next_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, &next_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, &next_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, &next_cpu) !
[PATCH net] lwtunnel: fix autoload of lwt modules
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]
;; 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
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
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
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
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
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
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' expec
[GIT] Networking
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
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
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
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, &info->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
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, &info); >> } >> >> +/* 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(&rt->dst); >> -read_unlock_bh(&table->tb6_lock); >> >> -return __ip6_del_rt(rt, &cfg->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
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
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
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, &info); >>> } >>> >>> +/* 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(&rt->dst); >>> - read_unlock_bh(&table->tb6_lock); >>> >>> - return __ip6_del_rt(rt, &cfg->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(&table->lock); fib6_del(); is invalid. write_lock_bh(&table->lock); fib6_del(); is required.
Re: [PATCH v2 net-next 0/2] mvneta xmit_more and bql support
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
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, &info); > } > > +/* 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(&rt->dst); > - read_unlock_bh(&table->tb6_lock); > > - return __ip6_del_rt(rt, &cfg->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
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
> -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
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
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.index, 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 *)&m.addr.data, &m.users);
--
2.11.0
[PATCH net] vxlan: fix byte order of vxlan-gpe port number
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(&vxlan->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
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 justify this rearrangement based upon the consequences and how much activity happens in this driver. >>> >>> Ri
[PATCH net-next] bridge: sparse fixes in br_ip6_multicast_alloc_query()
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
+ 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
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
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
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
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
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.
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
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
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
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
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
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
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.
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
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(&advertising,
+ 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 net_devi
Re: [patch net-next] stmmac: indent an if statement
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
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
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
On Mon, Jan 16, 2017 at 7:09 PM, kbuild test robot 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(&x->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 # inclu
[PATCH v3] net/irda: fix lockdep annotation
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(&hashbin->hb_spinlock, flags,
-hashbin_lock_depth++);
+#ifdef CONFIG_LOCKDEP
+ depth = atomic_inc_return(&hashbin_lock_depth) - 1;
+#endif
+ spin_lock_irqsave_nested(&hashbin->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(&hashbin->hb_spinlock, flags);
#ifdef CONFIG_LOCKDEP
- hashbin_lock_depth--;
+ atomic_dec(&hashbin_lock_depth);
#endif
}
--
2.11.0.483.g087da7b7c-goog
Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
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 you. >> Saeed.
Re: [PATCH] net: constify mdiobb_ops structures
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
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 = &priv->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
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
> -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
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
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
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
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.
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 qed_eth_cb_ops *eth;
+ struct qed_fcoe_cb_ops
[PATCH 0/2] Add QLogic FastLinQ FCoE (qedf) driver
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
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
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
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()
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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, &info->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
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
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
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()
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
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
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
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
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
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
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
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
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
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(&x->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 &lock->rlock;
290 }
291
292 #define spin_lock_init(_lock) \
293 do {\
294 spinlock_check(_lock); \
295 raw_spin_lock_init(&(_lock)->rlock);\
296 }
[PATCH] qed: Replace memset with eth_zero_addr
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, &info->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
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
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
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
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
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
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
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(&eq->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
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
