* Re: [PATCH net-next] net: core: Traverse the adjacency list from first entry
From: David Ahern @ 2016-10-26 15:05 UTC (permalink / raw)
To: idosch, davem; +Cc: netdev, mlxsw, Ido Schimmel
In-Reply-To: <1477463962-2802-1-git-send-email-idosch@idosch.org>
On 10/26/16 12:39 AM, idosch@idosch.org wrote:
> From: Ido Schimmel <idosch@mellanox.com>
>
> netdev_next_lower_dev() returns NULL when we finished traversing the
> adjacency list ('iter' points to the list's head). Therefore, we must
> start traversing the list from the first entry and not its head.
>
> Fixes: 1a3f060c1a47 ("net: Introduce new api for walking upper and lower devices")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> ---
> net/core/dev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f55fb45..d9c937f 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5419,7 +5419,7 @@ int netdev_walk_all_lower_dev(struct net_device *dev,
> struct list_head *iter;
> int ret;
>
> - for (iter = &dev->adj_list.lower,
> + for (iter = dev->adj_list.lower.next,
> ldev = netdev_next_lower_dev(dev, &iter);
> ldev;
> ldev = netdev_next_lower_dev(dev, &iter)) {
>
How about this instead? It keeps the 3 walk functions in sync modulo the rcu reference:
diff --git a/net/core/dev.c b/net/core/dev.c
index f55fb4536016..6aa43cd8cbb5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5400,12 +5400,12 @@ static struct net_device *netdev_next_lower_dev(struct net_device *dev,
{
struct netdev_adjacent *lower;
- lower = list_entry(*iter, struct netdev_adjacent, list);
+ lower = list_entry((*iter)->next, struct netdev_adjacent, list);
if (&lower->list == &dev->adj_list.lower)
return NULL;
- *iter = lower->list.next;
+ *iter = &lower->list;
return lower->dev;
}
^ permalink raw reply related
* Re: [RFC v4 00/18] Landlock LSM: Unprivileged sandboxing
From: Jann Horn @ 2016-10-26 14:52 UTC (permalink / raw)
To: Mickaël Salaün
Cc: linux-kernel, Alexei Starovoitov, Andy Lutomirski,
Daniel Borkmann, Daniel Mack, David Drysdale, David S . Miller,
Eric W . Biederman, James Morris, Kees Cook, Paul Moore,
Sargun Dhillon, Serge E . Hallyn, Tejun Heo, Thomas Graf,
Will Drewry, kernel-hardening, linux-api, linux-security-module,
netdev, cgroups
In-Reply-To: <20161026065654.19166-1-mic@digikod.net>
[-- Attachment #1: Type: text/plain, Size: 387 bytes --]
On Wed, Oct 26, 2016 at 08:56:36AM +0200, Mickaël Salaün wrote:
> The loaded Landlock eBPF programs can be triggered by a seccomp filter
> returning RET_LANDLOCK. In addition, a cookie (16-bit value) can be passed from
> a seccomp filter to eBPF programs. This allow flexible security policies
> between seccomp and Landlock.
Is this still up to date, or was that removed in v3?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: nfs NULL-dereferencing in net-next
From: Anna Schumaker @ 2016-10-26 14:40 UTC (permalink / raw)
To: Yotam Gigi, Jakub Kicinski, Andy Adamson, Anna Schumaker,
linux-nfs@vger.kernel.org
Cc: netdev@vger.kernel.org, Trond Myklebust, Yotam Gigi, mlxsw
In-Reply-To: <DB3PR05MB0764DF28BC53A4A4E78A4DD8ACA80@DB3PR05MB0764.eurprd05.prod.outlook.com>
On 10/25/2016 01:19 PM, Yotam Gigi wrote:
>
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
>> Behalf Of Jakub Kicinski
>> Sent: Monday, October 17, 2016 10:20 PM
>> To: Andy Adamson <andros@netapp.com>; Anna Schumaker
>> <Anna.Schumaker@Netapp.com>; linux-nfs@vger.kernel.org
>> Cc: netdev@vger.kernel.org; Trond Myklebust <Trond.Myklebust@netapp.com>
>> Subject: nfs NULL-dereferencing in net-next
>>
>> Hi!
>>
>> I'm hitting this reliably on net-next, HEAD at 3f3177bb680f
>> ("fsl/fman: fix error return code in mac_probe()").
>
>
> I see the same thing. It happens constantly on some of my machines, making them
> completely unusable.
>
> I bisected it and got to the commit:
>
> commit 04ea1b3e6d8ed4978bb608c1748530af3de8c274
> Author: Andy Adamson <andros@netapp.com>
> Date: Fri Sep 9 09:22:27 2016 -0400
>
> NFS add xprt switch addrs test to match client
>
> Signed-off-by: Andy Adamson <andros@netapp.com>
> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Thanks for reporting on this everyone! Does this patch help?
>From 96376ca1dd4077a1d341bdcb9cc86426ee3844f1 Mon Sep 17 00:00:00 2001
From: Anna Schumaker <Anna.Schumaker@Netapp.com>
Date: Wed, 26 Oct 2016 10:33:31 -0400
Subject: [PATCH] SUNRPC: Fix suspicious RCU usage
We need to hold the rcu_read_lock() when calling rcu_dereference(),
otherwise we can't guarantee that the object being dereferenced still
exists.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
---
net/sunrpc/clnt.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 34dd7b2..62a4827 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -2753,14 +2753,18 @@ EXPORT_SYMBOL_GPL(rpc_cap_max_reconnect_timeout);
void rpc_clnt_xprt_switch_put(struct rpc_clnt *clnt)
{
+ rcu_read_lock();
xprt_switch_put(rcu_dereference(clnt->cl_xpi.xpi_xpswitch));
+ rcu_read_unlock();
}
EXPORT_SYMBOL_GPL(rpc_clnt_xprt_switch_put);
void rpc_clnt_xprt_switch_add_xprt(struct rpc_clnt *clnt, struct rpc_xprt *xprt)
{
+ rcu_read_lock();
rpc_xprt_switch_add_xprt(rcu_dereference(clnt->cl_xpi.xpi_xpswitch),
xprt);
+ rcu_read_unlock();
}
EXPORT_SYMBOL_GPL(rpc_clnt_xprt_switch_add_xprt);
@@ -2770,9 +2774,8 @@ bool rpc_clnt_xprt_switch_has_addr(struct rpc_clnt *clnt,
struct rpc_xprt_switch *xps;
bool ret;
- xps = rcu_dereference(clnt->cl_xpi.xpi_xpswitch);
-
rcu_read_lock();
+ xps = rcu_dereference(clnt->cl_xpi.xpi_xpswitch);
ret = rpc_xprt_switch_has_addr(xps, sap);
rcu_read_unlock();
return ret;
--
2.10.1
>
>
>>
>> [ 23.409633] BUG: unable to handle kernel NULL pointer dereference at
>> 0000000000000172
>> [ 23.418716] IP: [<ffffffffc041776c>] rpc_clnt_xprt_switch_has_addr+0xc/0x40
>> [sunrpc]
>> [ 23.427574] PGD 859020067 [ 23.430472] PUD 858f2d067
>> PMD 0 [ 23.434311]
>> [ 23.436133] Oops: 0000 [#1] PREEMPT SMP
>> [ 23.440506] Modules linked in: nfsv4 ip6table_filter ip6_tables iptable_filter
>> ip_tables ebtable_nat ebtables x_tables intel_ri
>> [ 23.505915] CPU: 1 PID: 1067 Comm: mount.nfs Not tainted 4.8.0-perf-13951-
>> g3f3177bb680f #51
>> [ 23.515363] Hardware name: Dell Inc. PowerEdge T630/0W9WXC, BIOS 1.2.10
>> 03/10/2015
>> [ 23.523937] task: ffff983e9086ea00 task.stack: ffffac6c0a57c000
>> [ 23.530641] RIP: 0010:[<ffffffffc041776c>] [<ffffffffc041776c>]
>> rpc_clnt_xprt_switch_has_addr+0xc/0x40 [sunrpc]
>> [ 23.542229] RSP: 0018:ffffac6c0a57fb28 EFLAGS: 00010a97
>> [ 23.548255] RAX: 00000000c80214ac RBX: ffff983e97c7b000 RCX: ffff983e9b3bc180
>> [ 23.556320] RDX: 0000000000000001 RSI: ffff983e9928ed28 RDI: ffffffffffffffea
>> [ 23.564386] RBP: ffffac6c0a57fb38 R08: ffff983e97090630 R09: ffff983e9928ed30
>> [ 23.572452] R10: ffffac6c0a57fba0 R11: 0000000000000010 R12: ffffac6c0a57fba0
>> [ 23.580517] R13: ffff983e9928ed28 R14: 0000000000000000 R15: ffff983e91360560
>> [ 23.588585] FS: 00007f4c348aa880(0000) GS:ffff983e9f240000(0000)
>> knlGS:0000000000000000
>> [ 23.597742] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> [ 23.604251] CR2: 0000000000000172 CR3: 0000000850a5f000 CR4:
>> 00000000001406e0
>> [ 23.612316] Stack:
>> [ 23.614648] ffff983e97c7b000 ffffac6c0a57fba0 ffffac6c0a57fb90 ffffffffc04d38c3
>> [ 23.623331] ffff983e91360500 ffff983e9928ed30 ffffffffc0b9e560
>> ffff983e913605b8
>> [ 23.632016] ffff983e9882e800 ffff983e9882e800 ffffac6c0a57fc30 ffffac6c0a57fdb8
>> [ 23.640706] Call Trace:
>> [ 23.643535] [<ffffffffc04d38c3>] nfs_get_client+0x123/0x340 [nfs]
>> [ 23.650542] [<ffffffffc0b8f070>] nfs4_set_client+0x80/0xb0 [nfsv4]
>> [ 23.657642] [<ffffffffc0b90305>] nfs4_create_server+0x115/0x2a0 [nfsv4]
>> [ 23.665230] [<ffffffffc0b888ce>] nfs4_remote_mount+0x2e/0x60 [nfsv4]
>> [ 23.672519] [<ffffffffba1e590a>] mount_fs+0x3a/0x160
>> [ 23.678254] [<ffffffffba201a5e>] ? alloc_vfsmnt+0x19e/0x230
>> [ 23.684669] [<ffffffffba201b57>] vfs_kern_mount+0x67/0x110
>> [ 23.690990] [<ffffffffc0b887f4>] nfs_do_root_mount+0x84/0xc0 [nfsv4]
>> [ 23.698284] [<ffffffffc0b88b97>] nfs4_try_mount+0x37/0x50 [nfsv4]
>> [ 23.705287] [<ffffffffc04dfbd1>] nfs_fs_mount+0x2d1/0xa70 [nfs]
>> [ 23.712092] [<ffffffffba3a6228>] ? find_next_bit+0x18/0x20
>> [ 23.718413] [<ffffffffc04deac0>] ? nfs_remount+0x3c0/0x3c0 [nfs]
>> [ 23.725316] [<ffffffffc04dedb0>] ? nfs_clone_super+0x130/0x130 [nfs]
>> [ 23.732606] [<ffffffffba1e590a>] mount_fs+0x3a/0x160
>> [ 23.738340] [<ffffffffba201a5e>] ? alloc_vfsmnt+0x19e/0x230
>> [ 23.744755] [<ffffffffba201b57>] vfs_kern_mount+0x67/0x110
>> [ 23.751071] [<ffffffffba2041df>] do_mount+0x1bf/0xc70
>> [ 23.756904] [<ffffffffba203e9b>] ? copy_mount_options+0xbb/0x220
>> [ 23.763803] [<ffffffffba204fa3>] SyS_mount+0x83/0xd0
>> [ 23.769538] [<ffffffffba6f1ea4>] entry_SYSCALL_64_fastpath+0x17/0x98
>> [ 23.776817] Code: 01 00 48 8b 93 f8 04 00 00 44 89 e6 48 c7 c7 98 b2 43 c0 e8 9f 0d d4
>> f9 eb c0 0f 1f 44 00 00 0f 1f 44 00 00
>> [ 23.802909] RIP [<ffffffffc041776c>] rpc_clnt_xprt_switch_has_addr+0xc/0x40
>> [sunrpc]
>> [ 23.811857] RSP <ffffac6c0a57fb28>
>> [ 23.815839] CR2: 0000000000000172
>> [ 23.819629] ---[ end trace 9958eca92c9eeafe ]---
>> [ 23.827345] note: mount.nfs[1067] exited with preempt_count 1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply related
* Re: [PATCH net-next 1/1] driver: tun: Use new macro SOCK_IOC_MAGIC instead of literal number 0x89
From: Gao Feng @ 2016-10-26 14:10 UTC (permalink / raw)
To: David Laight
Cc: davem@davemloft.net, jasowang@redhat.com, edumazet@google.com,
pabeni@redhat.com, netdev@vger.kernel.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB020AC7B@AcuExch.aculab.com>
Hi David,
On Wed, Oct 26, 2016 at 7:12 PM, David Laight <David.Laight@aculab.com> wrote:
> From: fgao@ikuai8.com
>> Sent: 25 October 2016 13:56
>> The current codes use _IOC_TYPE(cmd) == 0x89 to check if the cmd is one
>> socket ioctl command like SIOCGIFHWADDR. But the literal number 0x89 may
>> confuse readers. So create one macro SOCK_IOC_MAGIC like SPI_IOC_MAGIC to
>> enhance the readability.
>>
>> Signed-off-by: Gao Feng <fgao@ikuai8.com>
>> ---
>> drivers/net/tun.c | 2 +-
>> include/uapi/linux/sockios.h | 2 ++
>> 2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 9328568..9efd185 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1985,7 +1985,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
>> int le;
>> int ret;
>>
>> - if (cmd == TUNSETIFF || cmd == TUNSETQUEUE || _IOC_TYPE(cmd) == 0x89) {
>> + if (cmd == TUNSETIFF || cmd == TUNSETQUEUE || _IOC_TYPE(cmd) == SOCK_IOC_MAGIC) {
>> if (copy_from_user(&ifr, argp, ifreq_len))
>> return -EFAULT;
>> } else {
>> diff --git a/include/uapi/linux/sockios.h b/include/uapi/linux/sockios.h
>> index 8e7890b..b8f42f2 100644
>> --- a/include/uapi/linux/sockios.h
>> +++ b/include/uapi/linux/sockios.h
>> @@ -24,6 +24,8 @@
>> #define SIOCINQ FIONREAD
>> #define SIOCOUTQ TIOCOUTQ /* output queue size (not sent + not acked) */
>>
>> +#define SOCK_IOC_MAGIC 0x89
>> +
>> /* Routing table calls. */
>> #define SIOCADDRT 0x890B /* add routing table entry */
>> #define SIOCDELRT 0x890C /* delete routing table entry */
>
> Shouldn't these constants be defined in terms of SOCK_IOC_MAGIC?
> And there must be a better name!
>
> David
>
How about the SOCK_IOC_TYPE or SOCK_IOC_BASE ?
There are ETRAXGPIO_IOCTYPE and HARDWALL_IOCTL_BASE already.
Regards
Feng
^ permalink raw reply
* Question: Why only 1 VTI per src/dest-pair allowed
From: Dario Ernst @ 2016-10-26 13:45 UTC (permalink / raw)
To: netdev
Hi,
I’m currently running into a limitation where I’d like to have multiple
VTI interfaces with the same source / destination address. It seems like
that this is not possible by default.
To elaborate a bit on my use-case: I’m trying to set up multiple tunnels
(SAs) between two endpoints, be it for load-balancing and fail-over, or
for complex routing in software-defined networking scenarios — or simply
multiple different peers behind a NAT. I would like to retain the
flexibility (and debuggability) that having a VTI provides.
I’ve been digging the ip_vti.c and ip_tunnel.c sources a bit — and
please excuse my kernel-illiteracy, I’m a complete kernel-newbie. I’m
creating a 2nd VTI through the IOCTL (as »iproute2« does), with the same
src/dst as an existing VTI, but with a different ikey and okey. The
condition that seems to break and throw -EEXIST is ip_tunnel_key_match.
This checks whether TUNNEL_KEY (0x04) is set, however, from what I’ve
seen only GRE_KEY (0x2000) is set — by vti_tunnel_ioctl. Also, in
iproute2, I’ve not found that TUNNEL_KEY gets set.
So from what I *think* I’ve read it’s deliberate that the check doesn’t
actually compare the keys — and thus forbids creating tunnel devices
with same src/same dst/different key.
Now, my final questions on this is: What is the design decision behind
this? Is there a finer point that I’m missing? And … is it actually
sufficient to modify ip_tunnel_key_match to actually compare the keys,
should they be set?
Thanks for all your great work, and thanks for reading this far :-).
Best Regards,
-Dario Ernst
^ permalink raw reply
* Re: [PATCH v2 5/5] posix-timers: make it configurable
From: Nicolas Pitre @ 2016-10-26 13:56 UTC (permalink / raw)
To: Richard Cochran
Cc: John Stultz, Yann E. MORIN, Michal Marek, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <20161026085102.GC11974@localhost.localdomain>
On Wed, 26 Oct 2016, Richard Cochran wrote:
> On Tue, Oct 25, 2016 at 10:28:51PM -0400, Nicolas Pitre wrote:
> > +config POSIX_TIMERS
> > + bool "Posix Clocks & timers" if EXPERT
> > + default y
> > + help
> > + This includes native support for POSIX timers to the kernel.
> > + Most embedded systems may have no use for them and therefore they
> > + can be configured out to reduce the size of the kernel image.
>
> Can you please fix this sentence? It doesn't make any sense. "Most"
> is making a definite statement of fact, while "may have no use" is
> not.
I'm not a native speaker. I'm afraid I just don't appreciate such
nuances.
> Either you mean:
>
> 1. Most embedded systems have no use for them.
>
> 2. Embedded systems may have no use for them.
>
> or expressing #2 in other words:
>
> 3. Many embedded systems have no use for them.
>
> 4. Some embedded systems have no use for them.
>
> Take your pick. (But I doubt #1 is really true, and so I would like
> to see some numbers to back up that claim.)
I used 4 to match the commit message, which incidentally is the result
of a prior suggestion from you. Sorry for not being consistent then.
As for numbers... I don't have any, but I probably mentioned already
that I can run a copy of Fedora on top of a kernel with POSIX timers
disabled and none of the warnings about those disabled syscalls are
triggered. So if my Fedora usage doesn't need them, we can infer that
the number of embedded systems also not needing them might tend towards
a high percentage. But let's be conservative and say "some".
Thanks for your review.
Nicolas
^ permalink raw reply
* Re: Re: [RFC v4 02/18] bpf: Move u64_to_ptr() to BPF headers and inline it
From: David Sterba @ 2016-10-26 13:52 UTC (permalink / raw)
To: kernel-hardening
Cc: Mickaël Salaün, linux-kernel, Alexei Starovoitov,
Andy Lutomirski, Daniel Borkmann, Daniel Mack, David Drysdale,
David S . Miller, Eric W . Biederman, James Morris, Jann Horn,
Kees Cook, Paul Moore, Sargun Dhillon, Serge E . Hallyn,
Tejun Heo, Thomas Graf, Will Drewry, linux-api,
linux-security-module, netdev, cgroups
In-Reply-To: <4045933.vGduYR3PCp@wuerfel>
On Wed, Oct 26, 2016 at 09:19:08AM +0200, Arnd Bergmann wrote:
> On Wednesday, October 26, 2016 8:56:38 AM CEST Mickaël Salaün wrote:
> > include/linux/bpf.h | 6 ++++++
> > kernel/bpf/syscall.c | 6 ------
> > 2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index c201017b5730..cf87db6daf27 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -283,6 +283,12 @@ static inline void bpf_long_memcpy(void *dst, const void *src, u32 size)
> >
> > /* verify correctness of eBPF program */
> > int bpf_check(struct bpf_prog **fp, union bpf_attr *attr);
> > +
> > +/* helper to convert user pointers passed inside __aligned_u64 fields */
> > +static inline void __user *u64_to_ptr(__u64 val)
> > +{
> > + return (void __user *) (unsigned long) val;
> > +}
> > #else
> >
>
>
> We already have at least six copies of this helper:
>
> fs/btrfs/qgroup.c:#define u64_to_ptr(x) ((struct btrfs_qgroup *)(uintptr_t)x)
This one does not take __user pointers, unlike the rest. Anyway, the name is
misleading, I'll send a cleanup. Thanks.
> kernel/bpf/syscall.c:static void __user *u64_to_ptr(__u64 val)
> drivers/staging/android/ion/ion_test.c:#define u64_to_uptr(x) ((void __user *)(unsigned long)(x))
> drivers/firewire/core-cdev.c:static void __user *u64_to_uptr(u64 value)
> drivers/staging/android/ion/ion_test.c:#define u64_to_uptr(x) ((void __user *)(unsigned long)(x))
> include/linux/kernel.h:#define u64_to_user_ptr(x) ( \
>
> Just use the one in linux/kernel.h
>
> Arnd
^ permalink raw reply
* Re: [PATCH net-next RFC WIP] Patch for XDP support for virtio_net
From: Jesper Dangaard Brouer @ 2016-10-26 13:52 UTC (permalink / raw)
To: Shrijeet Mukherjee; +Cc: brouer, mst, tom, netdev, shm, roopa, nikolay
In-Reply-To: <1477109243-29520-1-git-send-email-shrijeet@gmail.com>
On Sat, 22 Oct 2016 04:07:23 +0000
Shrijeet Mukherjee <shrijeet@gmail.com> wrote:
> This patch adds support for xdp ndo and also inserts the xdp program
> call into the merged RX buffers and big buffers paths
I really appreciate you are doing this for virtio_net.
My first question is: Is the (packet) page data writable?
(MST might be able to answer?)
As this is currently an XDP requirement[1].
> * The small packet skb receive is skipped for now
> * No TX for now
I do see more and more valid use-cases for only implementing XDP_DROP
and not necessarily also implementing XDP_TX. This does requires that
we implement some kind of feature/capabilities negotiation mechanism[2].
[1] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/requirements.html#write-access-to-packet-data
[2] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/design.html#capabilities-negotiation
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] sctp: validate chunk len before actually using it
From: Neil Horman @ 2016-10-26 13:23 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: netdev, linux-sctp, Vlad Yasevich, syzkaller, kcc, glider,
edumazet, dvyukov, andreyknvl
In-Reply-To: <06d1d4f21f959784823d7c7e31c3ea7e7360cb99.1477410525.git.marcelo.leitner@gmail.com>
On Tue, Oct 25, 2016 at 02:27:39PM -0200, Marcelo Ricardo Leitner wrote:
> Andrey Konovalov reported that KASAN detected that SCTP was using a slab
> beyond the boundaries. It was caused because when handling out of the
> blue packets in function sctp_sf_ootb() it was checking the chunk len
> only after already processing the first chunk, validating only for the
> 2nd and subsequent ones.
>
> The fix is to just move the check upwards so it's also validated for the
> 1st chunk.
>
> Reported-by: Andrey Konovalov <andreyknvl@google.com>
> Tested-by: Andrey Konovalov <andreyknvl@google.com>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
>
> Hi. Please consider this to -stable too. Thanks
>
> net/sctp/sm_statefuns.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index 026e3bca4a94bd34b418d5e6947f7182c1512358..8ec20a64a3f8055a0c3576627c5ec5dad7e99ca8 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -3422,6 +3422,12 @@ sctp_disposition_t sctp_sf_ootb(struct net *net,
> return sctp_sf_violation_chunklen(net, ep, asoc, type, arg,
> commands);
>
> + /* Report violation if chunk len overflows */
> + ch_end = ((__u8 *)ch) + SCTP_PAD4(ntohs(ch->length));
> + if (ch_end > skb_tail_pointer(skb))
> + return sctp_sf_violation_chunklen(net, ep, asoc, type, arg,
> + commands);
> +
> /* Now that we know we at least have a chunk header,
> * do things that are type appropriate.
> */
> @@ -3453,12 +3459,6 @@ sctp_disposition_t sctp_sf_ootb(struct net *net,
> }
> }
>
> - /* Report violation if chunk len overflows */
> - ch_end = ((__u8 *)ch) + SCTP_PAD4(ntohs(ch->length));
> - if (ch_end > skb_tail_pointer(skb))
> - return sctp_sf_violation_chunklen(net, ep, asoc, type, arg,
> - commands);
> -
> ch = (sctp_chunkhdr_t *) ch_end;
> } while (ch_end < skb_tail_pointer(skb));
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* [PATCH] net_sched actions: use nla_parse_nested()
From: Johannes Berg @ 2016-10-26 12:44 UTC (permalink / raw)
To: netdev; +Cc: Jamal Hadi Salim, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Use nla_parse_nested instead of open-coding the call to
nla_parse() with the attribute data/len.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/sched/act_api.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index c9102172ce3b..ef89ec1d51fb 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -1025,8 +1025,7 @@ static struct nlattr *find_dump_kind(const struct nlmsghdr *n)
if (tb[1] == NULL)
return NULL;
- if (nla_parse(tb2, TCA_ACT_MAX, nla_data(tb[1]),
- nla_len(tb[1]), NULL) < 0)
+ if (nla_parse_nested(tb2, TCA_ACT_MAX, tb[1], NULL) < 0)
return NULL;
kind = tb2[TCA_ACT_KIND];
--
2.8.1
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: mark symbol static where possible
From: Jakub Sitnicki @ 2016-10-26 12:37 UTC (permalink / raw)
To: Baoyou Xie
Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel, arnd,
xie.baoyou, han.fei, tang.qiang007
In-Reply-To: <1477474370-31383-1-git-send-email-baoyou.xie@linaro.org>
On Wed, Oct 26, 2016 at 09:32 AM GMT, Baoyou Xie wrote:
> We get 1 warning when building kernel with W=1:
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c:1557:6: warning: no previous prototype for 'rtl8192eu_power_off' [-Wmissing-prototypes]
>
> In fact, this function is only used in the file in which it is
> declared and don't need a declaration, but can be made static.
> So this patch marks this function with 'static'.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
> index 883fd98..4d975f0 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -2701,7 +2701,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
> return mv88e6xxx_port_write(chip, port, PORT_DEFAULT_VLAN, 0x0000);
> }
>
> -int mv88e6xxx_g1_set_switch_mac(struct mv88e6xxx_chip *chip, u8 *addr)
> +static int mv88e6xxx_g1_set_switch_mac(struct mv88e6xxx_chip *chip, u8 *addr)
> {
> int err;
Probably a mix-up - your patch doesn't match the description.
Thanks,
Jakub
^ permalink raw reply
* Re: [bnx2] [Regression 4.8] Driver loading fails without firmware
From: Baoquan He @ 2016-10-26 12:00 UTC (permalink / raw)
To: Paul Menzel; +Cc: Sony Chacko, Dept-HSGLinuxNICDev, netdev, David S. Miller
In-Reply-To: <b0675854-41f9-e7b6-4ad0-85ff59b98977@molgen.mpg.de>
Hi Paul,
Sorry for this.
On 10/26/16 at 12:31pm, Paul Menzel wrote:
> > > dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
> > > @@ -8607,6 +8608,7 @@ bnx2_init_one(struct pci_dev *pdev, const struct
> > > pci_device_id *ent)
> > > return 0;
> > >
> > > error:
> > > + bnx2_release_firmware(bp);
> > > pci_iounmap(pdev, bp->regview);
> > > pci_release_regions(pdev);
> > > pci_disable_device(pdev);
>
> Baoquan, could you please fix this regression. My suggestion is, that you
> add the old code back, but check if the firmware has been loaded. If it
> hasn’t, load it again.
>
> That way, people can update their Linux kernel, and it continues working
> without changing the initramfs, or anything else.
I saw your mail but I am also not familiar with bnx2 driver. As the
commit log says I just tried to make bnx2 driver reset itself earlier.
So you did a git bisect and found this commit caused the regression,
right? If yes, and network developers have no action, I will look into
the code and see if I have idea to fix it.
Thanks
Baoquan
^ permalink raw reply
* Re: concurrent rhashtable test failure
From: Geert Uytterhoeven @ 2016-10-26 11:45 UTC (permalink / raw)
To: Thomas Graf; +Cc: Phil Sutter, Herbert Xu, netdev@vger.kernel.org, linux-m68k
In-Reply-To: <20161026095139.GA16590@pox.localdomain>
Hi Thomas,
On Wed, Oct 26, 2016 at 11:51 AM, Thomas Graf <tgraf@suug.ch> wrote:
> On 10/24/16 at 02:11pm, Geert Uytterhoeven wrote:
>> On m68k/ARAnyM, test_rhashtable fails with:
>>
>> Test failed: thread 0 returned: -4
>>
>> (-4 = -EINTR)
>
> The error is returned by kthread_stop(), I suspect we are running into
> this:
>
> static int kthread(void *_create)
> {
> [...]
> complete(done);
> schedule();
>
> ret = -EINTR;
>
> if (!test_bit(KTHREAD_SHOULD_STOP, &self.flags)) {
> __kthread_parkme(&self);
> ret = threadfn(data);
> }
> /* we can't just return, we must preserve "self" on stack */
> do_exit(ret);
> }
Looks reasonable. Adding a small delay like in the (whitespace-damaged)
patch below fixes the issue for me.
However, shouldn't the prestart_sem take care of making sure that
all threads have been started?
--- a/lib/test_rhashtable.c
+++ b/lib/test_rhashtable.c
@@ -13,6 +13,7 @@
* Self Test
**************************************************************************/
+#include <linux/delay.h>
#include <linux/init.h>
#include <linux/jhash.h>
#include <linux/kernel.h>
@@ -403,6 +404,7 @@ static int __init test_rht_init(void)
pr_err(" down interruptible failed\n");
for (i = 0; i < tcount; i++)
up(&startup_sem);
+ msleep(1000);
for (i = 0; i < tcount; i++) {
if (IS_ERR(tdata[i].task))
continue;
Gr{oetje,eeting}s,
Geert
^ permalink raw reply
* RE: [PATCH net-next 1/1] driver: tun: Use new macro SOCK_IOC_MAGIC instead of literal number 0x89
From: David Laight @ 2016-10-26 11:12 UTC (permalink / raw)
To: 'fgao@ikuai8.com', davem@davemloft.net,
jasowang@redhat.com, edumazet@google.com, pabeni@redhat.com,
netdev@vger.kernel.org
Cc: gfree.wind@gmail.com
In-Reply-To: <1477400179-32200-1-git-send-email-fgao@ikuai8.com>
From: fgao@ikuai8.com
> Sent: 25 October 2016 13:56
> The current codes use _IOC_TYPE(cmd) == 0x89 to check if the cmd is one
> socket ioctl command like SIOCGIFHWADDR. But the literal number 0x89 may
> confuse readers. So create one macro SOCK_IOC_MAGIC like SPI_IOC_MAGIC to
> enhance the readability.
>
> Signed-off-by: Gao Feng <fgao@ikuai8.com>
> ---
> drivers/net/tun.c | 2 +-
> include/uapi/linux/sockios.h | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 9328568..9efd185 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1985,7 +1985,7 @@ static long __tun_chr_ioctl(struct file *file, unsigned int cmd,
> int le;
> int ret;
>
> - if (cmd == TUNSETIFF || cmd == TUNSETQUEUE || _IOC_TYPE(cmd) == 0x89) {
> + if (cmd == TUNSETIFF || cmd == TUNSETQUEUE || _IOC_TYPE(cmd) == SOCK_IOC_MAGIC) {
> if (copy_from_user(&ifr, argp, ifreq_len))
> return -EFAULT;
> } else {
> diff --git a/include/uapi/linux/sockios.h b/include/uapi/linux/sockios.h
> index 8e7890b..b8f42f2 100644
> --- a/include/uapi/linux/sockios.h
> +++ b/include/uapi/linux/sockios.h
> @@ -24,6 +24,8 @@
> #define SIOCINQ FIONREAD
> #define SIOCOUTQ TIOCOUTQ /* output queue size (not sent + not acked) */
>
> +#define SOCK_IOC_MAGIC 0x89
> +
> /* Routing table calls. */
> #define SIOCADDRT 0x890B /* add routing table entry */
> #define SIOCDELRT 0x890C /* delete routing table entry */
Shouldn't these constants be defined in terms of SOCK_IOC_MAGIC?
And there must be a better name!
David
^ permalink raw reply
* Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Kalle Valo @ 2016-10-26 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arend van Spriel, Linus Torvalds,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Hante Meuleman, Franky Lin,
Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Rafał Miłecki, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list.pdl-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <3406231.8mt2808XDi@wuerfel>
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
> On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
>> Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> writes:
>>
>> > A bugfix added a sanity check around the assignment and use of the
>> > 'is_11d' variable, which looks correct to me, but as the function is
>> > rather complex already, this confuses the compiler to the point where
>> > it can no longer figure out if the variable is always initialized
>> > correctly:
>> >
>> > brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
>> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
>> >
>> > This adds an initialization for the newly introduced case in which
>> > the variable should not really be used, in order to make the warning
>> > go away.
>> >
>> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
>> > Cc: Hante Meuleman <hante.meuleman-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> > Cc: Arend van Spriel <arend.vanspriel-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>> > Cc: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> > Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
>>
>> Via which tree are you planning to submit this? Should I take it?
>
> I'd prefer if you can take it and forward it along with your other
> bugfixes. I'll try to take care of the ones that nobody else
> picked up.
Ok, I'll take it. I'm planning to push this to 4.9.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH net] packet: on direct_xmit, limit tso and csum to supported devices
From: Daniel Borkmann @ 2016-10-26 10:47 UTC (permalink / raw)
To: Willem de Bruijn, netdev; +Cc: davem, Willem de Bruijn
In-Reply-To: <1477441683-68242-1-git-send-email-willemdebruijn.kernel@gmail.com>
On 10/26/2016 02:28 AM, Willem de Bruijn wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> When transmitting on a packet socket with PACKET_VNET_HDR and
> PACKET_QDISC_BYPASS, validate device support for features requested
> in vnet_hdr.
>
> Drop TSO packets sent to devices that do not support TSO or have the
> feature disabled. Note that the latter currently do process those
> packets correctly, regardless of not advertising the feature.
>
> Because of SKB_GSO_DODGY, it is not sufficient to test device features
> with netif_needs_gso. Full validate_xmit_skb is needed.
>
> Switch to software checksum for non-TSO packets that request checksum
> offload if that device feature is unsupported or disabled. Note that
> similar to the TSO case, device drivers may perform checksum offload
> correctly even when not advertising it.
>
> When switching to software checksum, packets hit skb_checksum_help,
> which has two BUG_ON checksum not in linear segment. Packet sockets
> always allocate at least up to csum_start + csum_off + 2 as linear.
Ok, for the tpacket_fill_skb() case with SOCK_RAW, it's guaranteed,
because if we have a vnet header, then copylen would cover that here
(as opposed to just dev->hard_header_len). With Eric's suggestion,
looks good to me. Thanks, Willem!
^ permalink raw reply
* Re: [bnx2] [Regression 4.8] Driver loading fails without firmware
From: Paul Menzel @ 2016-10-26 10:31 UTC (permalink / raw)
To: Sony Chacko, Dept-HSGLinuxNICDev, Baoquan He; +Cc: netdev, David S. Miller
In-Reply-To: <244cb42b-0fce-fe41-7b7c-babb51411e8c@molgen.mpg.de>
Dear Baoquan, Linux folks,
I am sorry for Thunderbird’s autowrapping messing up the message formatting.
On 10/25/16 16:33, Paul Menzel wrote:
> A server with the Broadcom devices below, fails to load the drivers
> because of missing firmware.
>
>> $ lspci -nn
>> […]
>> 01:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)
>> 01:00.1 Ethernet controller [0200]: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)
>> 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)
>> 02:00.1 Ethernet controller [0200]: Broadcom Corporation NetXtreme II
>> BCM5709 Gigabit Ethernet [14e4:1639] (rev 20)
>> […]
>
> Here are the error messages from Linux 4.8.4.
>
>> [ 10.365839] bnx2: QLogic bnx2 Gigabit Ethernet Driver v2.2.6
>> (January 29, 2014)
>> [ 10.366989] bnx2 0000:01:00.0: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.367384] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.367719] bnx2: probe of 0000:01:00.0 failed with error -2
>> [ 10.368616] bnx2 0000:01:00.1: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.369015] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.369292] bnx2: probe of 0000:01:00.1 failed with error -2
>> [ 10.370194] bnx2 0000:02:00.0: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.374460] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.374743] bnx2: probe of 0000:02:00.0 failed with error -2
>> [ 10.375619] bnx2 0000:02:00.1: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.376024] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.376303] bnx2: probe of 0000:02:00.1 failed with error -2
>> [ 10.376589] bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver
>> bnx2x 1.712.30-0 (2014/02/10)
>> [ 10.509323] bnx2: QLogic bnx2 Gigabit Ethernet Driver v2.2.6
>> (January 29, 2014)
>> [ 10.510467] bnx2 0000:01:00.0: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.510855] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.511188] bnx2: probe of 0000:01:00.0 failed with error -2
>> [ 10.512087] bnx2 0000:01:00.1: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.512492] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.512773] bnx2: probe of 0000:01:00.1 failed with error -2
>> [ 10.513648] bnx2 0000:02:00.0: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.517861] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.518182] bnx2: probe of 0000:02:00.0 failed with error -2
>> [ 10.519071] bnx2 0000:02:00.1: Direct firmware load for
>> bnx2/bnx2-mips-09-6.2.1b.fw failed with error -2
>> [ 10.519466] bnx2: Can't load firmware file
>> "bnx2/bnx2-mips-09-6.2.1b.fw"
>> [ 10.519740] bnx2: probe of 0000:02:00.1 failed with error -2
>> [ 10.520039] bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver
>> bnx2x 1.712.30-0 (2014/02/10)
>
> The system boots fine with the *same* initramfs and Linux 4.4.27, and
> Linux 4.7.10.
>
>> $ dmesg | grep bnx # Linux 4.7.10
>> [ 9.875426] bnx2: QLogic bnx2 Gigabit Ethernet Driver v2.2.6
>> (January 29, 2014)
>> [ 9.876766] bnx2 0000:01:00.0 eth0: Broadcom NetXtreme II BCM5709
>> 1000Base-T (C0) PCI Express found at mem e6000000, IRQ 43, node addr
>> 14:fe:b5:c6:81:01
>> [ 9.878065] bnx2 0000:01:00.1 eth1: Broadcom NetXtreme II BCM5709
>> 1000Base-T (C0) PCI Express found at mem e8000000, IRQ 44, node addr
>> 14:fe:b5:c6:81:03
>> [ 9.879357] bnx2 0000:02:00.0 eth2: Broadcom NetXtreme II BCM5709
>> 1000Base-T (C0) PCI Express found at mem ea000000, IRQ 45, node addr
>> 14:fe:b5:c6:81:05
>> [ 9.880630] bnx2 0000:02:00.1 eth3: Broadcom NetXtreme II BCM5709
>> 1000Base-T (C0) PCI Express found at mem ec000000, IRQ 46, node addr
>> 14:fe:b5:c6:81:07
>> [ 9.881129] bnx2x: QLogic 5771x/578xx 10/20-Gigabit Ethernet Driver
>> bnx2x 1.712.30-0 (2014/02/10)
>> [ 27.692521] bnx2 0000:01:00.0 net00: renamed from eth0
>> [ 27.702703] bnx2 0000:01:00.1 net01: renamed from eth1
>> [ 27.719779] bnx2 0000:02:00.0 net02: renamed from eth2
>> [ 27.768563] bnx2 0000:02:00.1 net03: renamed from eth3
>> [ 28.146396] bnx2 0000:01:00.0 net00: using MSIX
>> [ 31.294206] bnx2 0000:01:00.0 net00: NIC Copper Link is Up, 1000
>> Mbps full duplex
>
> There were not many commits between Linux 4.7 and Linux 4.8.
>
> Could the commit below cause this regression?
>
>> $ git log --oneline v4.7...v4.8 -- drivers/net/ethernet/broadcom/bnx2.c
>> 3e1be7a bnx2: Reset device during driver initialization
>> commit 3e1be7ad2d38c6bd6aeef96df9bd0a7822f4e51c
>> Author: Baoquan He <bhe@redhat.com>
>> Date: Fri Sep 9 22:43:12 2016 +0800
>>
>> bnx2: Reset device during driver initialization
>>
>> When system enters into kdump kernel because of kernel panic, it
>> won't
>> shutdown devices. On-flight DMA will continue transferring data until
>> device driver initializes. All devices are supposed to reset during
>> driver initialization. And this property is used to fix the kdump
>> failure in system with intel iommu. Other systems with hardware iommu
>> should be similar. Please check commit 091d42e ("iommu/vt-d: Copy
>> translation tables from old kernel") and those commits around.
>>
>> But bnx2 driver doesn't reset device during driver initialization.
>> The
>> device resetting is deferred to net device up stage. This will cause
>> hardware iommu handling failure on bnx2 device. And its resetting
>> relies
>> on firmware. So in this patch move the firmware requesting code to
>> earlier
>> bnx2_init_one(), then next call bnx2_reset_chip to reset device.
>>
>> Signed-off-by: Baoquan He <bhe@redhat.com>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnx2.c
>> b/drivers/net/ethernet/broadcom/bnx2.c
>> index 8fc3f3c..505ceaf 100644
>> --- a/drivers/net/ethernet/broadcom/bnx2.c
>> +++ b/drivers/net/ethernet/broadcom/bnx2.c
>> @@ -6356,10 +6356,6 @@ bnx2_open(struct net_device *dev)
>> struct bnx2 *bp = netdev_priv(dev);
>> int rc;
>>
>> - rc = bnx2_request_firmware(bp);
>> - if (rc < 0)
>> - goto out;
>> -
>> netif_carrier_off(dev);
>>
>> bnx2_disable_int(bp);
>> @@ -6428,7 +6424,6 @@ bnx2_open(struct net_device *dev)
>> bnx2_free_irq(bp);
>> bnx2_free_mem(bp);
>> bnx2_del_napi(bp);
>> - bnx2_release_firmware(bp);
>> goto out;
>> }
>>
>> @@ -8575,6 +8570,12 @@ bnx2_init_one(struct pci_dev *pdev, const
>> struct pci_device_id *ent)
>>
>> pci_set_drvdata(pdev, dev);
>>
>> + rc = bnx2_request_firmware(bp);
>> + if (rc < 0)
>> + goto error;
>> +
>> +
>> + bnx2_reset_chip(bp, BNX2_DRV_MSG_CODE_RESET);
>> memcpy(dev->dev_addr, bp->mac_addr, ETH_ALEN);
>>
>> dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_SG |
>> @@ -8607,6 +8608,7 @@ bnx2_init_one(struct pci_dev *pdev, const struct
>> pci_device_id *ent)
>> return 0;
>>
>> error:
>> + bnx2_release_firmware(bp);
>> pci_iounmap(pdev, bp->regview);
>> pci_release_regions(pdev);
>> pci_disable_device(pdev);
Baoquan, could you please fix this regression. My suggestion is, that
you add the old code back, but check if the firmware has been loaded. If
it hasn’t, load it again.
That way, people can update their Linux kernel, and it continues working
without changing the initramfs, or anything else.
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Johannes Berg @ 2016-10-26 10:18 UTC (permalink / raw)
To: Thomas Graf
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, daniel-FeC+5ew28dpmcu3hnIyYJQ,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161026095238.GB16590-4EA/1caXOu0mYvmMESoHnA@public.gmane.org>
On Wed, 2016-10-26 at 11:52 +0200, Thomas Graf wrote:
> On 10/26/16 at 10:59am, Johannes Berg wrote:
> >
> >
> > >
> > > /**
> > > + * nla_memdup - duplicate attribute memory (kmemdup)
> > > + * @src: netlink attribute to duplicate from
> > > + * @gfp: GFP mask
> >
> > Actually, is there any point in passing a GFP mask? None of the
> > current
> > users need it, and it seems fairly unlikely to be needed since this
> > is
> > typically used on the netlink input path, where you surely
> > shouldn't
> > need GFP_ATOMIC or so?
>
> I'm fine either way. I didn't want to make assumptions which need
> later changes. It's not hurting either and the function prototype
> is very small.
Yeah, I don't really care much - just wondered.
johannes
^ permalink raw reply
* Re: [PATCH 19/28] brcmfmac: avoid maybe-uninitialized warning in brcmf_cfg80211_start_ap
From: Arnd Bergmann @ 2016-10-26 9:57 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Linus Torvalds, linux-kernel, Hante Meuleman,
Franky Lin, Pieter-Paul Giesberts, Franky (Zhenhui) Lin,
Rafał Miłecki, linux-wireless, brcm80211-dev-list.pdl,
netdev
In-Reply-To: <87zilr61ux.fsf@kamboji.qca.qualcomm.com>
On Wednesday, October 26, 2016 9:49:58 AM CEST Kalle Valo wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > A bugfix added a sanity check around the assignment and use of the
> > 'is_11d' variable, which looks correct to me, but as the function is
> > rather complex already, this confuses the compiler to the point where
> > it can no longer figure out if the variable is always initialized
> > correctly:
> >
> > brcm80211/brcmfmac/cfg80211.c: In function ‘brcmf_cfg80211_start_ap’:
> > brcm80211/brcmfmac/cfg80211.c:4586:10: error: ‘is_11d’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> > This adds an initialization for the newly introduced case in which
> > the variable should not really be used, in order to make the warning
> > go away.
> >
> > Fixes: b3589dfe0212 ("brcmfmac: ignore 11d configuration errors")
> > Cc: Hante Meuleman <hante.meuleman@broadcom.com>
> > Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
> > Cc: Kalle Valo <kvalo@codeaurora.org>
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Via which tree are you planning to submit this? Should I take it?
I'd prefer if you can take it and forward it along with your other
bugfixes. I'll try to take care of the ones that nobody else
picked up.
Arnd
^ permalink raw reply
* Re: [PATCH] net: hns: mark symbols static where possible
From: Arnd Bergmann @ 2016-10-26 9:53 UTC (permalink / raw)
To: Baoyou Xie
Cc: yisen.zhuang, salil.mehta, davem, yankejian, huangdaode,
lisheng011, fabf, xieqianqian, lipeng321, Colin King, weiyongjun1,
oulijun, vinod.koul, andrew, Philippe Reynes, xypron.glpk,
Network Development, Linux Kernel Mailing List, xie.baoyou,
han.fei, tang.qiang007
In-Reply-To: <CA+DQWkw5HkraYgMNtCJ+-VQKcxoVV+AzfnkjQEbRcNLnBcGkaQ@mail.gmail.com>
On Wednesday, October 26, 2016 5:48:32 PM CEST Baoyou Xie wrote:
> In fact, last month I sent a similar patch to fix the warnings, but this
> older patch is based on linux-next, not net git tree, so the patch didn't
> apply.
>
> now, I rework the patch base on git://
> git.kernel.org/pub/scm/linux/kernel/git/davem/net.git.
I think I see the mistake that led to the confusion before: you should
base cleanups for network drivers on net-next.git, not net.git.
The correct URL is
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
and it is usually very close to linux-next, except for patches that
just got applied and have not made it into the latest linux-next.
Only if you find a serious bug, use net.git instead so the fix can
go into the mainline kernel.
Arnd
^ permalink raw reply
* Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr
From: Thomas Graf @ 2016-10-26 9:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: davem, daniel, netdev, linux-wireless
In-Reply-To: <1477472376.4059.23.camel@sipsolutions.net>
On 10/26/16 at 10:59am, Johannes Berg wrote:
>
> > /**
> > + * nla_memdup - duplicate attribute memory (kmemdup)
> > + * @src: netlink attribute to duplicate from
> > + * @gfp: GFP mask
>
> Actually, is there any point in passing a GFP mask? None of the current
> users need it, and it seems fairly unlikely to be needed since this is
> typically used on the netlink input path, where you surely shouldn't
> need GFP_ATOMIC or so?
I'm fine either way. I didn't want to make assumptions which need
later changes. It's not hurting either and the function prototype
is very small.
^ permalink raw reply
* Re: concurrent rhashtable test failure
From: Thomas Graf @ 2016-10-26 9:51 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Phil Sutter, Herbert Xu, netdev@vger.kernel.org, linux-m68k
In-Reply-To: <CAMuHMdWTqXaJAM-O+mmha=JbuyvvNxYyHuV6e4YK7oUkh9rCkA@mail.gmail.com>
On 10/24/16 at 02:11pm, Geert Uytterhoeven wrote:
> Hi Phil,
>
> On m68k/ARAnyM, test_rhashtable fails with:
>
> Test failed: thread 0 returned: -4
>
> (-4 = -EINTR)
The error is returned by kthread_stop(), I suspect we are running into
this:
static int kthread(void *_create)
{
[...]
complete(done);
schedule();
ret = -EINTR;
if (!test_bit(KTHREAD_SHOULD_STOP, &self.flags)) {
__kthread_parkme(&self);
ret = threadfn(data);
}
/* we can't just return, we must preserve "self" on stack */
do_exit(ret);
}
^ permalink raw reply
* [PATCH] net: hns: mark symbols static where possible
From: Baoyou Xie @ 2016-10-26 9:42 UTC (permalink / raw)
To: yisen.zhuang, salil.mehta, davem, yankejian, huangdaode,
lisheng011, fabf, xieqianqian, lipeng321, colin.king, weiyongjun1,
oulijun, vinod.koul, arnd, andrew, tremyfr, xypron.glpk
Cc: netdev, linux-kernel, baoyou.xie, xie.baoyou, han.fei,
tang.qiang007
We get a few warnings when building kernel with W=1:
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:76:21: warning: no previous prototype for 'hns_ae_get_handle' [-Wmissing-prototypes]
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c:274:6: warning: no previous prototype for 'hns_ae_stop' [-Wmissing-prototypes]
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c:330:6: warning: no previous prototype for 'hns_gmac_update_stats' [-Wmissing-prototypes]
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c:885:13: warning: no previous prototype for 'hns_mac_get_vaddr' [-Wmissing-prototypes]
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c:679:6: warning: no previous prototype for 'hns_get_ringparam' [-Wmissing-prototypes]
....
In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c | 30 +++++++++++-----------
drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 8 +++---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c | 7 ++---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 11 ++++----
drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c | 7 ++---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 4 +--
.../net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c | 2 +-
drivers/net/ethernet/hisilicon/hns/hns_enet.c | 13 +++++-----
drivers/net/ethernet/hisilicon/hns/hns_ethtool.c | 24 +++++++++--------
10 files changed, 58 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
index e28d960..a1150e9 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ae_adapt.c
@@ -73,8 +73,8 @@ static struct ring_pair_cb *hns_ae_get_ring_pair(struct hnae_queue *q)
return container_of(q, struct ring_pair_cb, q);
}
-struct hnae_handle *hns_ae_get_handle(struct hnae_ae_dev *dev,
- u32 port_id)
+static struct hnae_handle *hns_ae_get_handle(struct hnae_ae_dev *dev,
+ u32 port_id)
{
int vfnum_per_port;
int qnum_per_vf;
@@ -271,7 +271,7 @@ static int hns_ae_start(struct hnae_handle *handle)
return 0;
}
-void hns_ae_stop(struct hnae_handle *handle)
+static void hns_ae_stop(struct hnae_handle *handle)
{
struct hns_mac_cb *mac_cb = hns_get_mac_cb(handle);
@@ -299,7 +299,7 @@ static void hns_ae_reset(struct hnae_handle *handle)
}
}
-void hns_ae_toggle_ring_irq(struct hnae_ring *ring, u32 mask)
+static void hns_ae_toggle_ring_irq(struct hnae_ring *ring, u32 mask)
{
u32 flag;
@@ -487,8 +487,8 @@ static void hns_ae_get_coalesce_range(struct hnae_handle *handle,
*rx_usecs_high = HNS_RCB_MAX_COALESCED_USECS;
}
-void hns_ae_update_stats(struct hnae_handle *handle,
- struct net_device_stats *net_stats)
+static void hns_ae_update_stats(struct hnae_handle *handle,
+ struct net_device_stats *net_stats)
{
int port;
int idx;
@@ -570,7 +570,7 @@ void hns_ae_update_stats(struct hnae_handle *handle,
net_stats->multicast = mac_cb->hw_stats.rx_mc_pkts;
}
-void hns_ae_get_stats(struct hnae_handle *handle, u64 *data)
+static void hns_ae_get_stats(struct hnae_handle *handle, u64 *data)
{
int idx;
struct hns_mac_cb *mac_cb;
@@ -602,8 +602,8 @@ void hns_ae_get_stats(struct hnae_handle *handle, u64 *data)
hns_dsaf_get_stats(vf_cb->dsaf_dev, p, vf_cb->port_index);
}
-void hns_ae_get_strings(struct hnae_handle *handle,
- u32 stringset, u8 *data)
+static void hns_ae_get_strings(struct hnae_handle *handle,
+ u32 stringset, u8 *data)
{
int port;
int idx;
@@ -635,7 +635,7 @@ void hns_ae_get_strings(struct hnae_handle *handle,
hns_dsaf_get_strings(stringset, p, port, dsaf_dev);
}
-int hns_ae_get_sset_count(struct hnae_handle *handle, int stringset)
+static int hns_ae_get_sset_count(struct hnae_handle *handle, int stringset)
{
u32 sset_count = 0;
struct hns_mac_cb *mac_cb;
@@ -684,7 +684,7 @@ static int hns_ae_config_loopback(struct hnae_handle *handle,
return ret;
}
-void hns_ae_update_led_status(struct hnae_handle *handle)
+static void hns_ae_update_led_status(struct hnae_handle *handle)
{
struct hns_mac_cb *mac_cb;
@@ -695,8 +695,8 @@ void hns_ae_update_led_status(struct hnae_handle *handle)
hns_set_led_opt(mac_cb);
}
-int hns_ae_cpld_set_led_id(struct hnae_handle *handle,
- enum hnae_led_state status)
+static int hns_ae_cpld_set_led_id(struct hnae_handle *handle,
+ enum hnae_led_state status)
{
struct hns_mac_cb *mac_cb;
@@ -707,7 +707,7 @@ int hns_ae_cpld_set_led_id(struct hnae_handle *handle,
return hns_cpld_led_set_id(mac_cb, status);
}
-void hns_ae_get_regs(struct hnae_handle *handle, void *data)
+static void hns_ae_get_regs(struct hnae_handle *handle, void *data)
{
u32 *p = data;
int i;
@@ -732,7 +732,7 @@ void hns_ae_get_regs(struct hnae_handle *handle, void *data)
hns_dsaf_get_regs(vf_cb->dsaf_dev, vf_cb->port_index, p);
}
-int hns_ae_get_regs_len(struct hnae_handle *handle)
+static int hns_ae_get_regs_len(struct hnae_handle *handle)
{
u32 total_num;
struct hnae_vf_cb *vf_cb = hns_ae_get_vf_cb(handle);
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
index 1e1eb92..f0c63c8 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_gmac.c
@@ -327,7 +327,7 @@ static void hns_gmac_init(void *mac_drv)
hns_gmac_set_uc_match(mac_drv, 0);
}
-void hns_gmac_update_stats(void *mac_drv)
+static void hns_gmac_update_stats(void *mac_drv)
{
struct mac_hw_stats *hw_stats = NULL;
struct mac_driver *drv = (struct mac_driver *)mac_drv;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index 22e1410..657b975 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -882,8 +882,9 @@ static int hns_mac_get_mode(phy_interface_t phy_if)
}
}
-u8 __iomem *hns_mac_get_vaddr(struct dsaf_device *dsaf_dev,
- struct hns_mac_cb *mac_cb, u32 mac_mode_idx)
+static u8 __iomem *
+hns_mac_get_vaddr(struct dsaf_device *dsaf_dev,
+ struct hns_mac_cb *mac_cb, u32 mac_mode_idx)
{
u8 __iomem *base = dsaf_dev->io_base;
int mac_id = mac_cb->mac_id;
@@ -901,7 +902,8 @@ u8 __iomem *hns_mac_get_vaddr(struct dsaf_device *dsaf_dev,
* @mac_cb: mac control block
* return 0 - success , negative --fail
*/
-int hns_mac_get_cfg(struct dsaf_device *dsaf_dev, struct hns_mac_cb *mac_cb)
+static int
+hns_mac_get_cfg(struct dsaf_device *dsaf_dev, struct hns_mac_cb *mac_cb)
{
int ret;
u32 mac_mode_idx;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
index 66b99d2..fb0eb6b 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_main.c
@@ -42,7 +42,7 @@ static const struct acpi_device_id hns_dsaf_acpi_match[] = {
};
MODULE_DEVICE_TABLE(acpi, hns_dsaf_acpi_match);
-int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
+static int hns_dsaf_get_cfg(struct dsaf_device *dsaf_dev)
{
int ret, i;
u32 desc_num;
@@ -2085,8 +2085,9 @@ static void hns_dsaf_pfc_unit_cnt(struct dsaf_device *dsaf_dev, int mac_id,
* @dsaf_id: dsa fabric id
* @xge_ge_work_mode
*/
-void hns_dsaf_port_work_rate_cfg(struct dsaf_device *dsaf_dev, int mac_id,
- enum dsaf_port_rate_mode rate_mode)
+static void
+hns_dsaf_port_work_rate_cfg(struct dsaf_device *dsaf_dev, int mac_id,
+ enum dsaf_port_rate_mode rate_mode)
{
u32 port_work_mode;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index 67accce..9dbba66 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -243,7 +243,8 @@ static void hns_dsaf_xge_core_srst_by_port(struct dsaf_device *dsaf_dev,
* bit18-19 for com/dfx
* @enable: false - request reset , true - drop reset
*/
-void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
+static void
+hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
{
u32 reg_addr;
@@ -265,7 +266,7 @@ void hns_dsaf_srst_chns(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
* bit18-19 for com/dfx
* @enable: false - request reset , true - drop reset
*/
-void
+static void
hns_dsaf_srst_chns_acpi(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
{
hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
@@ -273,7 +274,7 @@ hns_dsaf_srst_chns_acpi(struct dsaf_device *dsaf_dev, u32 msk, bool dereset)
msk, dereset);
}
-void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool dereset)
+static void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool dereset)
{
if (!dereset) {
dsaf_write_sub(dsaf_dev, DSAF_SUB_SC_ROCEE_RESET_REQ_REG, 1);
@@ -287,7 +288,7 @@ void hns_dsaf_roce_srst(struct dsaf_device *dsaf_dev, bool dereset)
}
}
-void hns_dsaf_roce_srst_acpi(struct dsaf_device *dsaf_dev, bool dereset)
+static void hns_dsaf_roce_srst_acpi(struct dsaf_device *dsaf_dev, bool dereset)
{
hns_dsaf_acpi_srst_by_port(dsaf_dev, HNS_OP_RESET_FUNC,
HNS_ROCE_RESET_FUNC, 0, dereset);
@@ -479,7 +480,7 @@ static phy_interface_t hns_mac_get_phy_if_acpi(struct hns_mac_cb *mac_cb)
return phy_if;
}
-int hns_mac_get_sfp_prsnt(struct hns_mac_cb *mac_cb, int *sfp_prsnt)
+static int hns_mac_get_sfp_prsnt(struct hns_mac_cb *mac_cb, int *sfp_prsnt)
{
if (!mac_cb->cpld_ctrl)
return -ENODEV;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
index 6ea8722..04e674c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_ppe.c
@@ -73,7 +73,7 @@ hns_ppe_common_get_ioaddr(struct ppe_common_cb *ppe_common)
* comm_index: common index
* retuen 0 - success , negative --fail
*/
-int hns_ppe_common_get_cfg(struct dsaf_device *dsaf_dev, int comm_index)
+static int hns_ppe_common_get_cfg(struct dsaf_device *dsaf_dev, int comm_index)
{
struct ppe_common_cb *ppe_common;
int ppe_num;
@@ -104,7 +104,8 @@ int hns_ppe_common_get_cfg(struct dsaf_device *dsaf_dev, int comm_index)
return 0;
}
-void hns_ppe_common_free_cfg(struct dsaf_device *dsaf_dev, u32 comm_index)
+static void
+hns_ppe_common_free_cfg(struct dsaf_device *dsaf_dev, u32 comm_index)
{
dsaf_dev->ppe_common[comm_index] = NULL;
}
@@ -337,7 +338,7 @@ static void hns_ppe_uninit_hw(struct hns_ppe_cb *ppe_cb)
}
}
-void hns_ppe_uninit_ex(struct ppe_common_cb *ppe_common)
+static void hns_ppe_uninit_ex(struct ppe_common_cb *ppe_common)
{
u32 i;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index ef11077..ded4506 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -612,7 +612,7 @@ void hns_rcb_get_queue_mode(enum dsaf_mode dsaf_mode, u16 *max_vfn,
}
}
-int hns_rcb_get_ring_num(struct dsaf_device *dsaf_dev)
+static int hns_rcb_get_ring_num(struct dsaf_device *dsaf_dev)
{
switch (dsaf_dev->dsaf_mode) {
case DSAF_MODE_ENABLE_FIX:
@@ -648,7 +648,7 @@ int hns_rcb_get_ring_num(struct dsaf_device *dsaf_dev)
}
}
-void __iomem *hns_rcb_common_get_vaddr(struct rcb_common_cb *rcb_common)
+static void __iomem *hns_rcb_common_get_vaddr(struct rcb_common_cb *rcb_common)
{
struct dsaf_device *dsaf_dev = rcb_common->dsaf_dev;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
index 8f4f0e8..3198890 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_xgmac.c
@@ -306,7 +306,7 @@ static void hns_xgmac_config_max_frame_length(void *mac_drv, u16 newval)
dsaf_write_dev(drv, XGMAC_MAC_MAX_PKT_SIZE_REG, newval);
}
-void hns_xgmac_update_stats(void *mac_drv)
+static void hns_xgmac_update_stats(void *mac_drv)
{
struct mac_driver *drv = (struct mac_driver *)mac_drv;
struct mac_hw_stats *hw_stats = &drv->mac_cb->hw_stats;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_enet.c b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
index 059aaed..e5f956c 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
@@ -1082,7 +1082,7 @@ static int hns_nic_net_set_mac_address(struct net_device *ndev, void *p)
return 0;
}
-void hns_nic_update_stats(struct net_device *netdev)
+static void hns_nic_update_stats(struct net_device *netdev)
{
struct hns_nic_priv *priv = netdev_priv(netdev);
struct hnae_handle *h = priv->ae_handle;
@@ -1369,7 +1369,7 @@ static int hns_nic_do_ioctl(struct net_device *netdev, struct ifreq *ifr,
/* use only for netconsole to poll with the device without interrupt */
#ifdef CONFIG_NET_POLL_CONTROLLER
-void hns_nic_poll_controller(struct net_device *ndev)
+static void hns_nic_poll_controller(struct net_device *ndev)
{
struct hns_nic_priv *priv = netdev_priv(ndev);
unsigned long flags;
@@ -1482,7 +1482,7 @@ static netdev_features_t hns_nic_fix_features(
*
* return void
*/
-void hns_set_multicast_list(struct net_device *ndev)
+static void hns_set_multicast_list(struct net_device *ndev)
{
struct hns_nic_priv *priv = netdev_priv(ndev);
struct hnae_handle *h = priv->ae_handle;
@@ -1500,7 +1500,7 @@ void hns_set_multicast_list(struct net_device *ndev)
}
}
-void hns_nic_set_rx_mode(struct net_device *ndev)
+static void hns_nic_set_rx_mode(struct net_device *ndev)
{
struct hns_nic_priv *priv = netdev_priv(ndev);
struct hnae_handle *h = priv->ae_handle;
@@ -1515,8 +1515,9 @@ void hns_nic_set_rx_mode(struct net_device *ndev)
hns_set_multicast_list(ndev);
}
-struct rtnl_link_stats64 *hns_nic_get_stats64(struct net_device *ndev,
- struct rtnl_link_stats64 *stats)
+static struct rtnl_link_stats64 *
+hns_nic_get_stats64(struct net_device *ndev,
+ struct rtnl_link_stats64 *stats)
{
int idx = 0;
u64 tx_bytes = 0;
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
index 47e59bb..7c06436 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_ethtool.c
@@ -676,8 +676,8 @@ static void hns_nic_get_drvinfo(struct net_device *net_dev,
* @dev: net device
* @param: ethtool parameter
*/
-void hns_get_ringparam(struct net_device *net_dev,
- struct ethtool_ringparam *param)
+static void hns_get_ringparam(struct net_device *net_dev,
+ struct ethtool_ringparam *param)
{
struct hns_nic_priv *priv = netdev_priv(net_dev);
struct hnae_ae_ops *ops;
@@ -825,7 +825,8 @@ static int hns_set_coalesce(struct net_device *net_dev,
* @dev: net device
* @ch: channel info.
*/
-void hns_get_channels(struct net_device *net_dev, struct ethtool_channels *ch)
+static void
+hns_get_channels(struct net_device *net_dev, struct ethtool_channels *ch)
{
struct hns_nic_priv *priv = netdev_priv(net_dev);
@@ -842,8 +843,8 @@ void hns_get_channels(struct net_device *net_dev, struct ethtool_channels *ch)
* @stats: statistics info.
* @data: statistics data.
*/
-void hns_get_ethtool_stats(struct net_device *netdev,
- struct ethtool_stats *stats, u64 *data)
+static void hns_get_ethtool_stats(struct net_device *netdev,
+ struct ethtool_stats *stats, u64 *data)
{
u64 *p = data;
struct hns_nic_priv *priv = netdev_priv(netdev);
@@ -900,7 +901,7 @@ void hns_get_ethtool_stats(struct net_device *netdev,
* @stats: string set ID.
* @data: objects data.
*/
-void hns_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
+static void hns_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
{
struct hns_nic_priv *priv = netdev_priv(netdev);
struct hnae_handle *h = priv->ae_handle;
@@ -990,7 +991,7 @@ void hns_get_strings(struct net_device *netdev, u32 stringset, u8 *data)
*
* Return string set count.
*/
-int hns_get_sset_count(struct net_device *netdev, int stringset)
+static int hns_get_sset_count(struct net_device *netdev, int stringset)
{
struct hns_nic_priv *priv = netdev_priv(netdev);
struct hnae_handle *h = priv->ae_handle;
@@ -1022,7 +1023,7 @@ int hns_get_sset_count(struct net_device *netdev, int stringset)
*
* Return 0 on success, negative on failure.
*/
-int hns_phy_led_set(struct net_device *netdev, int value)
+static int hns_phy_led_set(struct net_device *netdev, int value)
{
int retval;
struct phy_device *phy_dev = netdev->phydev;
@@ -1044,7 +1045,8 @@ int hns_phy_led_set(struct net_device *netdev, int value)
*
* Return 0 on success, negative on failure.
*/
-int hns_set_phys_id(struct net_device *netdev, enum ethtool_phys_id_state state)
+static int
+hns_set_phys_id(struct net_device *netdev, enum ethtool_phys_id_state state)
{
struct hns_nic_priv *priv = netdev_priv(netdev);
struct hnae_handle *h = priv->ae_handle;
@@ -1118,8 +1120,8 @@ int hns_set_phys_id(struct net_device *netdev, enum ethtool_phys_id_state state)
* @cmd: ethtool cmd
* @date: register data
*/
-void hns_get_regs(struct net_device *net_dev, struct ethtool_regs *cmd,
- void *data)
+static void hns_get_regs(struct net_device *net_dev, struct ethtool_regs *cmd,
+ void *data)
{
struct hns_nic_priv *priv = netdev_priv(net_dev);
struct hnae_ae_ops *ops;
--
2.7.4
^ permalink raw reply related
* [PATCH] rtl8xxxu: mark symbol static where possible
From: Baoyou Xie @ 2016-10-26 9:32 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli
Cc: netdev, linux-kernel, arnd, baoyou.xie, xie.baoyou, han.fei,
tang.qiang007
We get 1 warning when building kernel with W=1:
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c:1557:6: warning: no previous prototype for 'rtl8192eu_power_off' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks this function with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/net/dsa/mv88e6xxx/chip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index 883fd98..4d975f0 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -2701,7 +2701,7 @@ static int mv88e6xxx_setup_port(struct mv88e6xxx_chip *chip, int port)
return mv88e6xxx_port_write(chip, port, PORT_DEFAULT_VLAN, 0x0000);
}
-int mv88e6xxx_g1_set_switch_mac(struct mv88e6xxx_chip *chip, u8 *addr)
+static int mv88e6xxx_g1_set_switch_mac(struct mv88e6xxx_chip *chip, u8 *addr)
{
int err;
--
2.7.4
^ permalink raw reply related
* [PATCH net] ipv6: Don't use ufo handling on later transformed packets
From: Jakub Sitnicki @ 2016-10-26 9:21 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Hannes Frederic Sowa, Florian Westphal
Similar to commit c146066ab802 ("ipv4: Don't use ufo handling on later
transformed packets"), don't perform UFO on packets that will be IPsec
transformed. To detect it we rely on the fact that headerlen in
dst_entry is non-zero only for transformation bundles (xfrm_dst
objects).
Unwanted segmentation can be observed with a NETIF_F_UFO capable device,
such as a dummy device:
DEV=dum0 LEN=1493
ip li add $DEV type dummy
ip addr add fc00::1/64 dev $DEV nodad
ip link set $DEV up
ip xfrm policy add dir out src fc00::1 dst fc00::2 \
tmpl src fc00::1 dst fc00::2 proto esp spi 1
ip xfrm state add src fc00::1 dst fc00::2 \
proto esp spi 1 enc 'aes' 0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
tcpdump -n -nn -i $DEV -t &
socat /dev/zero,readbytes=$LEN udp6:[fc00::2]:$LEN
tcpdump output before:
IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
IP6 fc00::1 > fc00::2: frag (1448|48)
IP6 fc00::1 > fc00::2: ESP(spi=0x00000001,seq=0x2), length 88
... and after:
IP6 fc00::1 > fc00::2: frag (0|1448) ESP(spi=0x00000001,seq=0x1), length 1448
IP6 fc00::1 > fc00::2: frag (1448|80)
Fixes: e89e9cf539a2 ("[IPv4/IPv6]: UFO Scatter-gather approach")
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv6/ip6_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 6001e78..59eb4ed 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1366,7 +1366,7 @@ static int __ip6_append_data(struct sock *sk,
if (((length > mtu) ||
(skb && skb_is_gso(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
- (rt->dst.dev->features & NETIF_F_UFO) &&
+ (rt->dst.dev->features & NETIF_F_UFO) && !rt->dst.header_len &&
(sk->sk_type == SOCK_DGRAM) && !udp_get_no_check6_tx(sk)) {
err = ip6_ufo_append_data(sk, queue, getfrag, from, length,
hh_len, fragheaderlen, exthdrlen,
--
2.7.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox