* Re: [PATCH] net: davicom: dm9000: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-12-18 2:32 UTC (permalink / raw)
To: tremyfr
Cc: robert.jarzmik, mugunthanvnm, marcel, jarod, s.nawrocki, fw,
harvey.hunt, netdev
In-Reply-To: <1481706118-13076-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Wed, 14 Dec 2016 10:01:58 +0100
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: sfc: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-12-18 2:32 UTC (permalink / raw)
To: tremyfr; +Cc: linux-net-drivers, ecree, bkenward, netdev, linux-kernel
In-Reply-To: <1481757173-16000-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Thu, 15 Dec 2016 00:12:53 +0100
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch net-next] irda: w83977af_ir: cleanup an indent issue
From: David Miller @ 2016-12-18 2:33 UTC (permalink / raw)
To: dan.carpenter; +Cc: samuel, joe, netdev, kernel-janitors
In-Reply-To: <20161212112134.GA10035@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 12 Dec 2016 14:21:34 +0300
> In commit 99d8d2159d7c ("irda: w83977af_ir: Neaten logging"), we
> accidentally added an extra tab to these lines.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 net] r6040: move spinlock in r6040_close as SOFTIRQ-unsafe lock order detected
From: David Miller @ 2016-12-18 2:36 UTC (permalink / raw)
To: manuel.bessler; +Cc: netdev, f.fainelli
In-Reply-To: <1481860500-25117-1-git-send-email-manuel.bessler@sensus.com>
From: Manuel Bessler <manuel.bessler@sensus.com>
Date: Thu, 15 Dec 2016 22:55:00 -0500
> 'ifconfig eth0 down' makes r6040_close() trigger:
> INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
>
> Fixed by moving calls to phy_stop(), napi_disable(), netif_stop_queue()
> to outside of the module's private spin_lock_irq block.
>
> Found on a Versalogic Tomcat SBC with a Vortex86 SoC
...
> Signed-off-by: Manuel Bessler <manuel.bessler@sensus.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ipv6: check route protocol when deleting routes
From: David Miller @ 2016-12-18 2:37 UTC (permalink / raw)
To: grawity; +Cc: netdev, linux-kernel
In-Reply-To: <20161216083059.251368-1-grawity@gmail.com>
From: Mantas Mikulėnas <grawity@gmail.com>
Date: Fri, 16 Dec 2016 10:30:59 +0200
> The protocol field is checked when deleting IPv4 routes, but ignored for
> IPv6, which causes problems with routing daemons accidentally deleting
> externally set routes (observed by multiple bird6 users).
>
> This can be verified using `ip -6 route del <prefix> proto something`.
>
> Signed-off-by: Mantas Mikulėnas <grawity@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] qed: fix old-style function definition
From: David Miller @ 2016-12-18 2:39 UTC (permalink / raw)
To: arnd
Cc: Yuval.Mintz, Ariel.Elior, everest-linux-l2, arun.easi, hare,
jthumshirn, netdev, linux-kernel
In-Reply-To: <20161216084808.1815139-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 16 Dec 2016 09:47:41 +0100
> The newly added file causes a harmless warning, with "make W=1":
>
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c: In function 'qed_get_iscsi_ops':
> drivers/net/ethernet/qlogic/qed/qed_iscsi.c:1268:29: warning: old-style function definition [-Wold-style-definition]
>
> This makes it a proper prototype.
>
> Fixes: fc831825f99e ("qed: Add support for hardware offloaded iSCSI.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
APplied.
^ permalink raw reply
* Re: pull-request: mac80211 2016-12-16
From: David Miller @ 2016-12-18 2:42 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20161216123957.16744-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 16 Dec 2016 13:39:56 +0100
> Since you seem to be updating net, I thought I'd send you a few fixes.
> These aren't really all that important though, so if you want to let
> them wait for a bit I can live with that.
>
> Please pull and let me know if there's any problem.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] cgroup: Fix CGROUP_BPF config
From: David Miller @ 2016-12-18 2:43 UTC (permalink / raw)
To: luto; +Cc: alexei.starovoitov, daniel, netdev
In-Reply-To: <8d48c3940f8d0275da6398ea5bcef14e20233db5.1481905995.git.luto@kernel.org>
From: Andy Lutomirski <luto@kernel.org>
Date: Fri, 16 Dec 2016 08:33:45 -0800
> CGROUP_BPF depended on SOCK_CGROUP_DATA which can't be manually
> enabled, making it rather challenging to turn CGROUP_BPF on.
>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
Applied, thanks.
^ permalink raw reply
* Re: [patch net] mlxsw: spectrum: Mark split ports as such
From: David Miller @ 2016-12-18 2:45 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, arkadis, tamirw
In-Reply-To: <1481912943-2864-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 16 Dec 2016 19:29:03 +0100
> From: Ido Schimmel <idosch@mellanox.com>
>
> When a port is split we should mark it as such, as otherwise the split
> ports aren't renamed correctly (e.g. sw1p3 -> sw1p3s1) and the unsplit
> operation fails:
>
> $ devlink port split sw1p3 count 4
> $ devlink port unsplit eth0
> devlink answers: Invalid argument
> [ 598.565307] mlxsw_spectrum 0000:03:00.0 eth0: Port wasn't split
>
> Fixes: 67963a33b4fd ("mlxsw: Make devlink port instances independent of spectrum/switchx2 port instances")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Reported-by: Tamir Winetroub <tamirw@mellanox.com>
> Reviewed-by: Elad Raz <eladr@mellanox.com>
> Tested-by: Tamir Winetroub <tamirw@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH] isdn: Constify some function parameters
From: David Miller @ 2016-12-18 2:46 UTC (permalink / raw)
To: keescook; +Cc: isdn, linux-kernel, re.emese, netdev
In-Reply-To: <20161216214047.GA90306@beast>
From: Kees Cook <keescook@chromium.org>
Date: Fri, 16 Dec 2016 13:40:47 -0800
> From: Emese Revfy <re.emese@gmail.com>
>
> The coming initify gcc plugin expects const pointer types, and caught
> some __printf arguments that weren't const yet. This fixes those.
>
> Signed-off-by: Emese Revfy <re.emese@gmail.com>
> [kees: expanded commit message]
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: mv643xx_eth: fix build failure
From: David Miller @ 2016-12-18 2:47 UTC (permalink / raw)
To: sudipm.mukherjee; +Cc: sebastian.hesselbarth, linux-kernel, netdev
In-Reply-To: <1481935505-24475-1-git-send-email-sudipm.mukherjee@gmail.com>
From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Date: Sat, 17 Dec 2016 00:45:05 +0000
> The build of sparc allmodconfig fails with the error:
> "of_irq_to_resource" [drivers/net/ethernet/marvell/mv643xx_eth.ko]
> undefined!
>
> of_irq_to_resource() is defined when CONFIG_OF_IRQ is defined. And also
> CONFIG_OF_IRQ can only be defined if CONFIG_IRQ is defined. So we can
> safely use #if defined(CONFIG_OF_IRQ) in the code.
>
> Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Applied, thanks.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2016-12-18 2:55 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Revert bogus nla_ok() change, from Alexey Dobriyan.
2) Various bpf validator fixes from Daniel Borkmann.
3) Add some necessary SET_NETDEV_DEV() calls to hsis_femac and hip04
drivers, from Dongpo Li.
4) Several ethtool ksettings conversions from Philippe Reynes.
5) Fix bugs in inet port management wrt. soreuseport, from Tom
Herbert.
6) XDP support for virtio_net, from John Fastabend.
7) Fix NAT handling within a vrf, from David Ahern.
8) Endianness fixes in dpaa_eth driver, from Claudiu Manoil.
Please pull, thanks a lot!
The following changes since commit 8fa3b6f9392bf6d90cb7b908e07bd90166639f0a:
Merge tag 'cris-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris (2016-12-12 09:06:38 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
for you to fetch changes up to 3e3397e7b11ce1b9526975ddfbe8dd569fc1f316:
net: mv643xx_eth: fix build failure (2016-12-17 21:47:26 -0500)
----------------------------------------------------------------
Alexey Dobriyan (1):
netlink: revert broken, broken "2-clause nla_ok()"
Andrew Lunn (1):
net: dsa: mv88e6xxx: Fix opps when adding vlan bridge
Andy Lutomirski (1):
cgroup: Fix CGROUP_BPF config
Arnd Bergmann (1):
qed: fix old-style function definition
Bartosz Folta (1):
net: macb: Added PCI wrapper for Platform Driver.
Ben Greear (1):
mac80211: fix legacy and invalid rx-rate report
Cedric Izoard (1):
mac80211: Ensure enough headroom when forwarding mesh pkt
Claudiu Manoil (1):
dpaa_eth: use big endian accessors
Dan Carpenter (1):
irda: w83977af_ir: cleanup an indent issue
Daniel Borkmann (5):
bpf: fix regression on verifier pruning wrt map lookups
bpf, test_verifier: fix a test case error result on unprivileged
bpf: dynamically allocate digest scratch buffer
bpf: fix overflow in prog accounting
bpf: fix mark_reg_unknown_value for spilled regs on map value marking
Daniel Mack (1):
bpf: cgroup: annotate pointers in struct cgroup_bpf with __rcu
David Ahern (2):
net: vrf: Fix NAT within a VRF
net: vrf: Drop conntrack data after pass through VRF device on Tx
David S. Miller (8):
Merge branch 'hisilicon-netdev-dev'
Merge branch 'cls_flower-mask'
Merge branch 'inet_csk_get_port-and-soreusport-fixes'
Merge branch 'dpaa_eth-fixes'
Merge branch 'virtio_net-XDP'
Merge branch 'gtp-fixes'
Merge branch 'bpf-fixes'
Merge tag 'mac80211-for-davem-2016-12-16' of git://git.kernel.org/.../jberg/mac80211
Dongpo Li (2):
net: ethernet: hisi_femac: Call SET_NETDEV_DEV()
net: ethernet: hip04: Call SET_NETDEV_DEV()
Emese Revfy (1):
isdn: Constify some function parameters
Harald Welte (1):
gtp: Fix initialization of Flags octet in GTPv1 header
Ido Schimmel (1):
mlxsw: spectrum: Mark split ports as such
Jason Wang (1):
virtio-net: correctly enable multiqueue
Jeroen De Wachter (2):
encx24j600: bugfix - always move ERXTAIL to next packet in encx24j600_rx_packets
encx24j600: Fix some checkstyle warnings
Johannes Berg (1):
mac80211: don't call drv_set_default_unicast_key() for VLANs
John Fastabend (5):
net: xdp: add invalid buffer warning
virtio_net: Add XDP support
virtio_net: add dedicated XDP transmit queues
virtio_net: add XDP_TX support
virtio_net: xdp, add slowpath case for non contiguous buffers
Kees Cook (7):
isdn/gigaset: use designated initializers
ATM: use designated initializers
net: use designated initializers
WAN: use designated initializers
bna: use designated initializers
isdn: use designated initializers
net/x25: use designated initializers
LABBE Corentin (5):
irda: irproc.c: Remove unneeded linux/miscdevice.h include
irda: irnet: Move linux/miscdevice.h include
irnet: ppp: move IRNET_MINOR to include/linux/miscdevice.h
irda: irnet: Remove unused IRNET_MAJOR define
irda: irnet: add member name to the miscdevice declaration
Lionel Gauthier (1):
gtp: gtp_check_src_ms_ipv4() always return success
Madalin Bucur (2):
dpaa_eth: remove redundant dependency on FSL_SOC
MAINTAINERS: net: add entry for Freescale QorIQ DPAA Ethernet driver
Mantas M (1):
net: ipv6: check route protocol when deleting routes
Manuel Bessler (1):
r6040: move spinlock in r6040_close as SOFTIRQ-unsafe lock order detected
Paul Blakey (2):
net/sched: cls_flower: Use mask for addr_type
net/sched: cls_flower: Use masked key when calling HW offloads
Philippe Reynes (5):
net: chelsio: cxgb2: use new api ethtool_{get|set}_link_ksettings
net: chelsio: cxgb3: use new api ethtool_{get|set}_link_ksettings
net: cirrus: ep93xx: use new api ethtool_{get|set}_link_ksettings
net: davicom: dm9000: use new api ethtool_{get|set}_link_ksettings
net: sfc: use new api ethtool_{get|set}_link_ksettings
Sudip Mukherjee (1):
net: mv643xx_eth: fix build failure
Thomas Falcon (1):
ibmveth: calculate gso_segs for large packets
Thomas Gleixner (1):
net/3com/3c515: Fix timer handling, prevent leaks and crashes
Timur Tabi (1):
net: qcom/emac: don't try to claim clocks on ACPI systems
Tom Herbert (2):
inet: Don't go into port scan when looking for specific bind port
inet: Fix get port to handle zero port number with soreuseport set
Xin Long (2):
sctp: sctp_epaddr_lookup_transport should be protected by rcu_read_lock
sctp: sctp_transport_lookup_process should rcu_read_unlock when transport is null
MAINTAINERS | 6 ++
drivers/isdn/gigaset/bas-gigaset.c | 32 +++---
drivers/isdn/gigaset/ser-gigaset.c | 32 +++---
drivers/isdn/gigaset/usb-gigaset.c | 32 +++---
drivers/isdn/hisax/config.c | 16 +--
drivers/isdn/hisax/hisax.h | 4 +-
drivers/isdn/i4l/isdn_concap.c | 6 +-
drivers/isdn/i4l/isdn_x25iface.c | 16 +--
drivers/net/dsa/mv88e6xxx/chip.c | 6 ++
drivers/net/ethernet/3com/3c515.c | 15 +--
drivers/net/ethernet/brocade/bna/bna_enet.c | 8 +-
drivers/net/ethernet/cadence/Kconfig | 9 ++
drivers/net/ethernet/cadence/Makefile | 1 +
drivers/net/ethernet/cadence/macb.c | 31 +++++-
drivers/net/ethernet/cadence/macb_pci.c | 153 ++++++++++++++++++++++++++++
drivers/net/ethernet/chelsio/cxgb/cxgb2.c | 64 +++++++-----
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 65 ++++++------
drivers/net/ethernet/cirrus/ep93xx_eth.c | 14 +--
drivers/net/ethernet/davicom/dm9000.c | 14 +--
drivers/net/ethernet/freescale/dpaa/Kconfig | 2 +-
drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 71 ++++++-------
drivers/net/ethernet/hisilicon/hip04_eth.c | 2 +-
drivers/net/ethernet/hisilicon/hisi_femac.c | 2 +-
drivers/net/ethernet/ibm/ibmveth.c | 12 ++-
drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 2 +-
drivers/net/ethernet/microchip/encx24j600-regmap.c | 17 ++--
drivers/net/ethernet/microchip/encx24j600.c | 19 +++-
drivers/net/ethernet/qlogic/qed/qed_iscsi.c | 2 +-
drivers/net/ethernet/qualcomm/emac/emac.c | 9 ++
drivers/net/ethernet/rdc/r6040.c | 10 +-
drivers/net/ethernet/sfc/ethtool.c | 35 ++++---
drivers/net/ethernet/sfc/mcdi_port.c | 60 ++++++-----
drivers/net/ethernet/sfc/net_driver.h | 12 +--
drivers/net/gtp.c | 8 +-
drivers/net/irda/w83977af_ir.c | 6 +-
drivers/net/virtio_net.c | 369 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
drivers/net/vrf.c | 6 +-
drivers/net/wan/lmc/lmc_media.c | 97 +++++++++---------
include/linux/bpf-cgroup.h | 2 +-
include/linux/bpf.h | 13 ++-
include/linux/filter.h | 15 ++-
include/linux/miscdevice.h | 1 +
include/linux/platform_data/macb.h | 6 ++
include/net/inet6_connection_sock.h | 3 +-
include/net/inet_connection_sock.h | 6 +-
include/net/netlink.h | 3 +-
init/Kconfig | 3 +-
kernel/bpf/core.c | 43 +++++---
kernel/bpf/syscall.c | 38 +++++--
kernel/bpf/verifier.c | 28 ++++--
net/atm/lec.c | 6 +-
net/atm/mpoa_caches.c | 43 ++++----
net/core/filter.c | 6 ++
net/decnet/dn_dev.c | 2 +-
net/ipv4/inet_connection_sock.c | 16 +--
net/ipv6/inet6_connection_sock.c | 7 +-
net/ipv6/route.c | 2 +
net/irda/irnet/irnet.h | 1 -
net/irda/irnet/irnet_ppp.h | 11 +-
net/irda/irproc.c | 1 -
net/mac80211/key.c | 3 +-
net/mac80211/rx.c | 2 +-
net/mac80211/sta_info.c | 14 +--
net/sched/cls_flower.c | 6 +-
net/sctp/endpointola.c | 5 +-
net/sctp/socket.c | 7 +-
net/vmw_vsock/vmci_transport_notify.c | 30 +++---
net/vmw_vsock/vmci_transport_notify_qstate.c | 30 +++---
net/x25/sysctl_net_x25.c | 2 +-
tools/testing/selftests/bpf/test_verifier.c | 30 +++++-
71 files changed, 1206 insertions(+), 446 deletions(-)
create mode 100644 drivers/net/ethernet/cadence/macb_pci.c
^ permalink raw reply
* (unknown),
From: netdev @ 2016-12-18 2:58 UTC (permalink / raw)
To: netdev; +Cc: xhgn, 561383013161808, sjuud, 1197, skqi, vqjs, 2752446077
[-- Attachment #1: EMAIL-6394134655.zip --]
[-- Type: application/zip, Size: 16284 bytes --]
^ permalink raw reply
* (unknown),
From: netdev @ 2016-12-18 4:04 UTC (permalink / raw)
To: netdev; +Cc: iqhm, 651366975, uqhzj, 139563427260, cvhv, pinz, 96948314
[-- Attachment #1: ONLINE-311698597317131.zip --]
[-- Type: application/zip, Size: 16286 bytes --]
^ permalink raw reply
* Re: [PATCH net] ipvlan: fix crash
From: David Miller @ 2016-12-18 4:54 UTC (permalink / raw)
To: mahesh; +Cc: netdev, edumazet, maheshb
In-Reply-To: <1482027379-30785-1-git-send-email-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Sat, 17 Dec 2016 18:16:19 -0800
> diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
> index b4e990743e1d..4294fc1f5564 100644
> --- a/drivers/net/ipvlan/ipvlan_core.c
> +++ b/drivers/net/ipvlan/ipvlan_core.c
> @@ -660,6 +660,9 @@ rx_handler_result_t ipvlan_handle_frame(struct sk_buff **pskb)
> if (!port)
> return RX_HANDLER_PASS;
>
> + if (unlikely(!pskb_may_pull(skb, sizeof(struct ethhdr))))
> + goto out;
> +
> switch (port->mode) {
ipvlan only allows non-loopback ethernet devices to register
this RX handler.
Such situations being tested here should therefore be completely
impossible.
Every such device must send the SKB through eth_type_trans(), which
unconditionally accesses the ethernet header, therefore it must
be pulled into the linear SKB area already, long before this RX
handler is invoked.
If this really can legitimately happen, you must explain how so.
Just showing the crash that later happens in some (completely
unrelated BTW) ipvlan multicast workqueue handling function, is
really an insufficient commit log message for a bug like this.
^ permalink raw reply
* RE: [PATCH] qed: fix memory leak of a qed_spq_entry on error failure paths
From: Mintz, Yuval @ 2016-12-18 6:33 UTC (permalink / raw)
To: Colin King, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Elior, Ariel, Tayar, Tomer
In-Reply-To: <20161216125039.20969-1-colin.king@canonical.com>
> From: Colin Ian King <colin.king@canonical.com>
>
> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd
> if an error occurs, causing a memory leak. Fix this by kfree'ing it and also
> setting *pp_ent to NULL to be safe.
>
> Found with static analysis by CoverityScan, CIDs 1389468-1389470
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
...
> +err:
> + kfree(*pp_ent);
> + *pp_ent = NULL;
> +
> + return rc;
> }
Hi Colin - thanks for this.
It would have been preferable to return the previously allocated spq entry.
I.e., do:
+err:
+ qed_spq_return_entry(p_hwfn, *pp_ent);
+ *pp_ent = NULL;
+ return rc;
Thanks,
Yuval
^ permalink raw reply
* Re: mlx4: Bug in XDP_TX + 16 rx-queues
From: Tariq Toukan @ 2016-12-18 10:31 UTC (permalink / raw)
To: Martin KaFai Lau, Saeed Mahameed, Tariq Toukan
Cc: netdev@vger.kernel.org, Alexei Starovoitov
In-Reply-To: <20161217101803.GB8732@kafai-mba.local>
Hi Martin,
On 17/12/2016 12:18 PM, Martin KaFai Lau wrote:
> Hi All,
>
> I have been debugging with XDP_TX and 16 rx-queues.
>
> 1) When 16 rx-queues is used and an XDP prog is doing XDP_TX,
> it seems that the packet cannot be XDP_TX out if the pkt
> is received from some particular CPUs (/rx-queues).
Does the rx_xdp_tx_full counter increase?
Does the problem repro if you turn off PFC?
ethtool -A <intf> rx off tx off
>
> 2) If 8 rx-queues is used, it does not have problem.
>
> 3) The 16 rx-queues problem also went away after reverting these
> two patches:
> 15fca2c8eb41 net/mlx4_en: Add ethtool statistics for XDP cases
> 67f8b1dcb9ee net/mlx4_en: Refactor the XDP forwarding rings scheme
>
> 4) I can reproduce the problem by running samples/bof/xdp_ip_tunnel at
> the receiver side. The sender side sends out TCP packets with
> source port ranging from 1 to 1024. At the sender side also, do
> a tcpdump to capture the ip-tunnel packet reflected by xdp_ip_tunnel.
> With 8 rx-queues, I can get all 1024 packets back. With 16 rx-queues,
> I can only get 512 packets back. It is a 40 CPUs machine.
> I also checked the rx*_xdp_tx counters (from ethtool -S eth0) to ensure
> the xdp prog has XDP_TX-ed it out.
So all packets were transmitted (according to rx*_xdp_tx), and only half
the of them received on the other side?
>
> Not saying that 67f8b1dcb9ee is 100% the cause because there are other
> changes since then. It is merely a brain dump on what I have already
> tried.
>
> Tariq/Saeed, any thoughts? I can easily test some patches in
> my setup.
>
> Thanks,
> --Martin
Thanks,
Tariq
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Arend Van Spriel @ 2016-12-18 10:49 UTC (permalink / raw)
To: Pali Rohár, Daniel Wagner
Cc: Luis R. Rodriguez, Tom Gundersen, Johannes Berg, Ming Lei,
Mimi Zohar, Bjorn Andersson, Rafał Miłecki, Kalle Valo,
Sebastian Reichel, Pavel Machek, Michal Kazior, Ivaylo Dimitrov,
Aaro Koskinen, Tony Lindgren, linux-wireless, Network Development,
linux-kernel@vger.kernel.org, David Woodhouse
In-Reply-To: <201612161140.27241@pali>
On 16-12-2016 11:40, Pali Rohár wrote:
> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>> For the new API a solution for "fallback mechanisms" should be
>>> clean though and I am looking to stay as far as possible from the
>>> existing mess. A solution to help both the old API and new API is
>>> possible for the "fallback mechanism" though -- but for that I can
>>> only refer you at this point to some of Daniel Wagner and Tom
>>> Gunderson's firmwared deamon prospect. It should help pave the way
>>> for a clean solution and help address other stupid issues.
>>
>> The firmwared project is hosted here
>>
>> https://github.com/teg/firmwared
>>
>> As Luis pointed out, firmwared relies on
>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
>
> I know. But it does not mean that I cannot enable this option at kernel
> compile time.
>
> Bigger problem is that currently request_firmware() first try to load
> firmware directly from VFS and after that (if fails) fallback to user
> helper.
>
> So I would need to extend kernel firmware code with new function (or
> flag) to not use VFS and try only user mode helper.
Why do you need the user-mode helper anyway. This is all static data,
right? So why not cook up a firmware file in user-space once and put it
in /lib/firmware for the driver to request directly. Seems a bit
overkill to have a {e,}udev or whatever daemon running if the result is
always the same. Just my 2 cents.
Regards,
Arend
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-12-18 11:04 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Daniel Wagner, Luis R. Rodriguez, Tom Gundersen, Johannes Berg,
Ming Lei, Mimi Zohar, Bjorn Andersson, Rafał Miłecki,
Kalle Valo, Sebastian Reichel, Pavel Machek, Michal Kazior,
Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren, linux-wireless,
Network Development, linux-kernel@vger.kernel.org
In-Reply-To: <68166247-bcd3-f598-7f9e-2139e732233e@broadcom.com>
[-- Attachment #1: Type: Text/Plain, Size: 2610 bytes --]
On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> On 16-12-2016 11:40, Pali Rohár wrote:
> > On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> >> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> >>> For the new API a solution for "fallback mechanisms" should be
> >>> clean though and I am looking to stay as far as possible from the
> >>> existing mess. A solution to help both the old API and new API is
> >>> possible for the "fallback mechanism" though -- but for that I
> >>> can only refer you at this point to some of Daniel Wagner and
> >>> Tom Gunderson's firmwared deamon prospect. It should help pave
> >>> the way for a clean solution and help address other stupid
> >>> issues.
> >>
> >> The firmwared project is hosted here
> >>
> >> https://github.com/teg/firmwared
> >>
> >> As Luis pointed out, firmwared relies on
> >> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
> >
> > I know. But it does not mean that I cannot enable this option at
> > kernel compile time.
> >
> > Bigger problem is that currently request_firmware() first try to
> > load firmware directly from VFS and after that (if fails) fallback
> > to user helper.
> >
> > So I would need to extend kernel firmware code with new function
> > (or flag) to not use VFS and try only user mode helper.
>
> Why do you need the user-mode helper anyway. This is all static data,
> right?
Those are static data, but device specific!
> So why not cook up a firmware file in user-space once and put
> it in /lib/firmware for the driver to request directly.
1. Violates FHS
2. Does not work for readonly /, readonly /lib, readonly /lib/firmware
3. Backup & restore of rootfs between same devices does not work (as
rootfs now contains device specific data).
4. Sharing one rootfs (either via nfs or other technology) does not work
for more devices (even in state when rootfs is used only by one device
at one time).
And it is common that N900 developers have rootfs in laptop and via usb
(cdc_ether) exports it over nfs to N900 device and boot system. It
basically break booting from one nfs-exported rootfs, as that export
become model specific...
> Seems a bit
> overkill to have a {e,}udev or whatever daemon running if the result
> is always the same. Just my 2 cents.
No it is not. It will break couple of other things in Linux and device
and model specific calibration data should not be in /lib/firmware! That
directory is used for firmware files, not calibration.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Arend Van Spriel @ 2016-12-18 11:54 UTC (permalink / raw)
To: Pali Rohár
Cc: Daniel Wagner, Luis R. Rodriguez, Tom Gundersen, Johannes Berg,
Ming Lei, Mimi Zohar, Bjorn Andersson, Rafał Miłecki,
Kalle Valo, Sebastian Reichel, Pavel Machek, Michal Kazior,
Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren, linux-wireless,
Network Development, linux-kernel@vger.kernel.org
In-Reply-To: <201612181204.52928@pali>
On 18-12-2016 12:04, Pali Rohár wrote:
> On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
>> On 16-12-2016 11:40, Pali Rohár wrote:
>>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
>>>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
>>>>> For the new API a solution for "fallback mechanisms" should be
>>>>> clean though and I am looking to stay as far as possible from the
>>>>> existing mess. A solution to help both the old API and new API is
>>>>> possible for the "fallback mechanism" though -- but for that I
>>>>> can only refer you at this point to some of Daniel Wagner and
>>>>> Tom Gunderson's firmwared deamon prospect. It should help pave
>>>>> the way for a clean solution and help address other stupid
>>>>> issues.
>>>>
>>>> The firmwared project is hosted here
>>>>
>>>> https://github.com/teg/firmwared
>>>>
>>>> As Luis pointed out, firmwared relies on
>>>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
>>>
>>> I know. But it does not mean that I cannot enable this option at
>>> kernel compile time.
>>>
>>> Bigger problem is that currently request_firmware() first try to
>>> load firmware directly from VFS and after that (if fails) fallback
>>> to user helper.
>>>
>>> So I would need to extend kernel firmware code with new function
>>> (or flag) to not use VFS and try only user mode helper.
>>
>> Why do you need the user-mode helper anyway. This is all static data,
>> right?
>
> Those are static data, but device specific!
So what?
>> So why not cook up a firmware file in user-space once and put
>> it in /lib/firmware for the driver to request directly.
>
> 1. Violates FHS
How?
> 2. Does not work for readonly /, readonly /lib, readonly /lib/firmware
Que?
> 3. Backup & restore of rootfs between same devices does not work (as
> rootfs now contains device specific data).
True.
> 4. Sharing one rootfs (either via nfs or other technology) does not work
> for more devices (even in state when rootfs is used only by one device
> at one time).
Indeed.
> And it is common that N900 developers have rootfs in laptop and via usb
> (cdc_ether) exports it over nfs to N900 device and boot system. It
> basically break booting from one nfs-exported rootfs, as that export
> become model specific...
These are all you choices and more a logistic issue. If your take is
that udev is the way to solve those, fine by me.
>> Seems a bit
>> overkill to have a {e,}udev or whatever daemon running if the result
>> is always the same. Just my 2 cents.
>
> No it is not. It will break couple of other things in Linux and device
Now I am curious. What "couple of other things" will be broken.
> and model specific calibration data should not be in /lib/firmware! That
> directory is used for firmware files, not calibration.
What is "firmware"? Really. These are binary blobs required to make the
device work. And guess what, your device needs calibration data. Why
make the distinction.
Regards,
Arend
^ permalink raw reply
* Re: wl1251 & mac address & calibration data
From: Pali Rohár @ 2016-12-18 12:09 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Daniel Wagner, Luis R. Rodriguez, Tom Gundersen, Johannes Berg,
Ming Lei, Mimi Zohar, Bjorn Andersson, Rafał Miłecki,
Kalle Valo, Sebastian Reichel, Pavel Machek, Michal Kazior,
Ivaylo Dimitrov, Aaro Koskinen, Tony Lindgren, linux-wireless,
Network Development, linux-kernel@vger.kernel.org
In-Reply-To: <83b2e9a4-f990-68a8-241e-375e46448d47@broadcom.com>
[-- Attachment #1: Type: Text/Plain, Size: 4450 bytes --]
On Sunday 18 December 2016 12:54:00 Arend Van Spriel wrote:
> On 18-12-2016 12:04, Pali Rohár wrote:
> > On Sunday 18 December 2016 11:49:53 Arend Van Spriel wrote:
> >> On 16-12-2016 11:40, Pali Rohár wrote:
> >>> On Friday 16 December 2016 08:25:44 Daniel Wagner wrote:
> >>>> On 12/16/2016 03:03 AM, Luis R. Rodriguez wrote:
> >>>>> For the new API a solution for "fallback mechanisms" should be
> >>>>> clean though and I am looking to stay as far as possible from
> >>>>> the existing mess. A solution to help both the old API and new
> >>>>> API is possible for the "fallback mechanism" though -- but for
> >>>>> that I can only refer you at this point to some of Daniel
> >>>>> Wagner and Tom Gunderson's firmwared deamon prospect. It
> >>>>> should help pave the way for a clean solution and help address
> >>>>> other stupid issues.
> >>>>
> >>>> The firmwared project is hosted here
> >>>>
> >>>> https://github.com/teg/firmwared
> >>>>
> >>>> As Luis pointed out, firmwared relies on
> >>>> FW_LOADER_USER_HELPER_FALLBACK, which is not enabled by default.
> >>>
> >>> I know. But it does not mean that I cannot enable this option at
> >>> kernel compile time.
> >>>
> >>> Bigger problem is that currently request_firmware() first try to
> >>> load firmware directly from VFS and after that (if fails)
> >>> fallback to user helper.
> >>>
> >>> So I would need to extend kernel firmware code with new function
> >>> (or flag) to not use VFS and try only user mode helper.
> >>
> >> Why do you need the user-mode helper anyway. This is all static
> >> data, right?
> >
> > Those are static data, but device specific!
>
> So what?
>
> >> So why not cook up a firmware file in user-space once and put
> >> it in /lib/firmware for the driver to request directly.
> >
> > 1. Violates FHS
>
> How?
>
> > 2. Does not work for readonly /, readonly /lib, readonly
> > /lib/firmware
>
> Que?
>
> > 3. Backup & restore of rootfs between same devices does not work
> > (as rootfs now contains device specific data).
>
> True.
>
> > 4. Sharing one rootfs (either via nfs or other technology) does not
> > work for more devices (even in state when rootfs is used only by
> > one device at one time).
>
> Indeed.
>
> > And it is common that N900 developers have rootfs in laptop and via
> > usb (cdc_ether) exports it over nfs to N900 device and boot
> > system. It basically break booting from one nfs-exported rootfs,
> > as that export become model specific...
>
> These are all you choices and more a logistic issue. If your take is
> that udev is the way to solve those, fine by me.
>
> >> Seems a bit
> >> overkill to have a {e,}udev or whatever daemon running if the
> >> result is always the same. Just my 2 cents.
> >
> > No it is not. It will break couple of other things in Linux and
> > device
>
> Now I am curious. What "couple of other things" will be broken.
>
> > and model specific calibration data should not be in /lib/firmware!
> > That directory is used for firmware files, not calibration.
>
> What is "firmware"? Really. These are binary blobs required to make
> the device work. And guess what, your device needs calibration data.
> Why make the distinction.
>
> Regards,
> Arend
File wl1251-nvs.bin is provided by linux-firmware package and contains
default data which should be overriden by model specific calibrated
data.
But overwriting that one file is not possible as it next update of
linux-firmware package will overwrite it back. It break any normal usage
of package management.
Also it is ridiculously broken by design if some "boot" files needs to
be overwritten to initialize hardware properly. To not break booting you
need to overwrite that file before first boot. But without booting
device you cannot read calibration data. So some hack with autoreboot
after boot is needed. And how to detect that we have real overwritten
calibration data and not default one from linux-firmware? Any heuristic
or checks will be broken here. And no, nothing like you need to reboot
your device now (and similar concept) from windows world is not
accepted.
"firmware" is one for chip. Any N900 device with wl1251 chip needs
exactly same firmware "wl1251-fw.bin". But every N900 needs different
calibration data which is not firmware.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2 2/2] tc/m_tunnel_key: Add dest UDP port to tunnel key action
From: Hadar Hen Zion @ 2016-12-18 7:41 UTC (permalink / raw)
To: Simon Horman; +Cc: Stephen Hemminger, netdev, Or Gerlitz, Roi Dayan, Amir Vadai
In-Reply-To: <20161215135312.GB7104@penelope.horms.nl>
On 12/15/2016 3:53 PM, Simon Horman wrote:
> On Thu, Dec 15, 2016 at 02:03:36PM +0100, Simon Horman wrote:
>> On Tue, Dec 13, 2016 at 10:07:47AM +0200, Hadar Hen Zion wrote:
>>> Enhance tunnel key action parameters by adding destination UDP port.
>>>
>>> Signed-off-by: Hadar Hen Zion <hadarh@mellanox.com>
>>> Reviewed-by: Roi Dayan <roid@mellanox.com>
>> Hi,
>>
>> this looks good to me but could you also update tc/m_tunnel_key.c:usage(); ?
> It seems that I was a bit hasty here as I now see that Stephen has
> indicated that he has applied this series. I also notice that
> patch 1/2 of this series also misses updating usage(). Let me know
> if sending some follow-up patches is the best way forwards.
Yes, I you are right, I'll send a follow-up patches.
Thanks,
Hadar
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Martin Blumenstingl @ 2016-12-18 13:37 UTC (permalink / raw)
To: Florian Fainelli, jbrunet
Cc: David Miller, netdev, devicetree, carlo, khilman, peppe.cavallaro,
alexandre.torgue, neolynx, andrew, narmstrong, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <162595c2-d403-0070-3399-de03c1653065@gmail.com>
Hi Florian, Hi Jerome,
On Wed, Nov 30, 2016 at 2:15 AM, Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 11/29/2016 05:13 PM, David Miller wrote:
>> From: Florian Fainelli <f.fainelli@gmail.com>
>> Date: Tue, 29 Nov 2016 16:43:20 -0800
>>
>>> On 11/29/2016 04:38 PM, David Miller wrote:
>>>> From: Jerome Brunet <jbrunet@baylibre.com>
>>>> Date: Mon, 28 Nov 2016 10:46:45 +0100
>>>>
>>>>> This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
>>>>> The platform seems to enter LPI on the Rx path too often while performing
>>>>> relatively high TX transfer. This eventually break the link (both Tx and
>>>>> Rx), and require to bring the interface down and up again to get the Rx
>>>>> path working again.
>>>>>
>>>>> The root cause of this issue is not fully understood yet but disabling EEE
>>>>> advertisement on the PHY prevent this feature to be negotiated.
>>>>> With this change, the link is stable and reliable, with the expected
>>>>> throughput performance.
>>>>>
>>>>> The patchset adds options in the generic phy driver to disable EEE
>>>>> advertisement, through device tree. The way it is done is very similar
>>>>> to the handling of the max-speed property.
>>>>
>>>> Patches 1-3 applied to net-next, thanks.
>>>
>>> Meh, there was a v4 submitted shortly after, and I objected to the whole
>>> idea of using that kind of Device Tree properties to disable EEE, we can
>>> send reverts though..
>>
>> Sorry, I lost this in all the discussion, I can revert.
>
> Yeah, I can understand why, these freaking PHYs tend to generate a lot
> of noise and discussion...
>
>>
>> Just send me a revert of the entire merge commit
>> a152c91889556df17ca6d8ea134fb2cb4ac9f893 with a short
>> description of why and I'll apply it.
>
> OK, I will talk with Jerome first to make sure that we are in agreement
> with the solution to deploy to fix the OdroidC2 problem first.
simply because I'm curious: what was the outcome of your discussion?
can we stay with the current solution or are any changes required?
Regards,
Martin
^ permalink raw reply
* regression: ath_tx_edma_tasklet() Illegal idle entry in RCU read-side critical section
From: Gabriel C @ 2016-12-18 13:52 UTC (permalink / raw)
To: lkml; +Cc: ath9k-devel, linux-wireless, ath9k-devel, Paul E. McKenney,
netdev
Hello,
while testing kernel 4.9 I run into a weird issue with the ath9k driver.
I can boot the box in console mode and it stay up sometime but is not usable.
from dmesg :
===============================
[ INFO: suspicious RCU usage. ]
4.9-fw1 #1 Tainted: G I
-------------------------------
kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
#0: (rcu_read_lock){......}, at: [<ffffffffa0ee0240>] ath_tx_edma_tasklet+0x0/0x460 [ath9k]
stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G I 4.9-fw1 #1
Hardware name: FUJITSU PRIMERGY TX200 S5 /D2709, BIOS 6.00 Rev. 1.14.2709 02/04/2013
ffff88043ee03f38 ffffffff812cf0f3 ffffffff81a11540 0000000000000001
ffff88043ee03f68 ffffffff810b7865 ffffffff81a55d58 ffff88043efcedc0
ffff88083cb1ca00 00000000000000d1 ffff88043ee03f88 ffffffff810dbfe8
Call Trace:
<IRQ>
[<ffffffff812cf0f3>] dump_stack+0x86/0xc3
[<ffffffff810b7865>] lockdep_rcu_suspicious+0xc5/0x100
[<ffffffff810dbfe8>] rcu_eqs_enter_common.constprop.62+0x128/0x130
[<ffffffff810ddc78>] rcu_irq_exit+0x38/0x70
[<ffffffff81067ec4>] irq_exit+0x74/0xd0
[<ffffffff8101e561>] do_IRQ+0x71/0x130
[<ffffffff8158700c>] common_interrupt+0x8c/0x8c
<EOI>
[<ffffffff81472836>] ? cpuidle_enter_state+0x156/0x220
[<ffffffff81472922>] cpuidle_enter+0x12/0x20
[<ffffffff810ad23e>] call_cpuidle+0x1e/0x40
[<ffffffff810ad46d>] cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] rest_init+0x12c/0x140
[<ffffffff81d02ec3>] start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] x86_64_start_kernel+0xeb/0xf8
...
perf: interrupt took too long (2766 > 2500), lowering kernel.perf_event_max_sample_rate to 72000
perf: interrupt took too long (3510 > 3457), lowering kernel.perf_event_max_sample_rate to 56000
perf: interrupt took too long (4689 > 4387), lowering kernel.perf_event_max_sample_rate to 42000
perf: interrupt took too long (5980 > 5861), lowering kernel.perf_event_max_sample_rate to 33000
INFO: rcu_preempt detected stalls on CPUs/tasks:
Tasks blocked on level-0 rcu_node (CPUs 0-15): P0
(detected by 5, t=65002 jiffies, g=3241, c=3240, q=8520)
swapper/0 R running task 0 0 0 0x00000000
ffffffff81a03e90 ffffffff8139bf30 ffffffff81ae30b8 00000000810253a9
ffff88083cb1e600 ffffffff81ae30a0 0000000000000002 ffffffff81ae30b8
ffffffff81ae2fe0 ffffffff81a03ed0 ffffffff81472814 0000001823671b47
Call Trace:
[<ffffffff8139bf30>] ? acpi_idle_enter+0x116/0x1fb
[<ffffffff81472814>] ? cpuidle_enter_state+0x134/0x220
[<ffffffff81472922>] ? cpuidle_enter+0x12/0x20
[<ffffffff810ad23e>] ? call_cpuidle+0x1e/0x40
[<ffffffff810ad46d>] ? cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
swapper/0 R running task 0 0 0 0x00000000
ffffffff81a03e90 ffffffff8139bf30 ffffffff81ae30b8 00000000810253a9
ffff88083cb1e600 ffffffff81ae30a0 0000000000000002 ffffffff81ae30b8
ffffffff81ae2fe0 ffffffff81a03ed0 ffffffff81472814 0000001823671b47
Call Trace:
[<ffffffff8139bf30>] ? acpi_idle_enter+0x116/0x1fb
[<ffffffff81472814>] ? cpuidle_enter_state+0x134/0x220
[<ffffffff81472922>] ? cpuidle_enter+0x12/0x20
[<ffffffff810ad23e>] ? call_cpuidle+0x1e/0x40
[<ffffffff810ad46d>] ? cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
perf: interrupt took too long (7746 > 7475), lowering kernel.perf_event_max_sample_rate to 25000
systemd-hostnamed.service: State 'stop-sigterm' timed out. Killing.
systemd-hostnamed.service: Killing process 1507 (systemd-hostnam) with signal SIGKILL.
perf: interrupt took too long (10065 > 9682), lowering kernel.perf_event_max_sample_rate to 19000
perf: interrupt took too long (12596 > 12581), lowering kernel.perf_event_max_sample_rate to 15000
INFO: task systemd-hostnam:1507 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-hostnam D 0 1507 1 0x00000002
ffff88043a29f200 000000000000c460 ffff88043ab0a1c0 ffff88043cdc0000
ffff88043f9d6718 ffffc9000b67fb88 ffffffff8157ff6e ffffc9000b67fbf8
ffff88043ab0abc0 ffff88043f9d6718 0000000000000000 ffff88043ab0a1c0
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81584e82>] schedule_timeout+0x222/0x3a0
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff810b5de9>] ? get_lock_stats+0x19/0x50
[<ffffffff81585d17>] ? _raw_spin_unlock_irq+0x27/0x50
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81580ffa>] wait_for_common+0xca/0x180
[<ffffffff8108e150>] ? wake_up_q+0x80/0x80
[<ffffffff815810c8>] wait_for_completion+0x18/0x20
[<ffffffff810d82e5>] __wait_rcu_gp+0xc5/0x100
[<ffffffff810dbccd>] synchronize_rcu.part.53+0x2d/0x50
[<ffffffff810dc7e0>] ? __call_rcu.constprop.59+0x270/0x270
[<ffffffff810d8210>] ? rcu_panic+0x20/0x20
[<ffffffff81580f69>] ? wait_for_common+0x39/0x180
[<ffffffff810dbd17>] synchronize_rcu+0x27/0x90
[<ffffffff811fd887>] namespace_unlock+0x47/0x60
[<ffffffff81200639>] drop_collected_mounts+0x89/0x90
[<ffffffff8120246b>] ? put_mnt_ns+0x1b/0x30
[<ffffffff8120246b>] put_mnt_ns+0x1b/0x30
[<ffffffff81085798>] free_nsproxy+0x18/0xb0
[<ffffffff8108593e>] switch_task_namespaces+0x5e/0x70
[<ffffffff8108595b>] exit_task_namespaces+0xb/0x10
[<ffffffff8106652e>] do_exit+0x2de/0xb30
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81066e00>] do_group_exit+0x40/0xc0
[<ffffffff81066e8f>] SyS_exit_group+0xf/0x10
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
=============================================
systemd-hostnamed.service: Processes still around after SIGKILL. Ignoring.
INFO: rcu_preempt detected stalls on CPUs/tasks:
Tasks blocked on level-0 rcu_node (CPUs 0-15): P0
(detected by 9, t=260007 jiffies, g=3241, c=3240, q=12143)
swapper/0 R running task 0 0 0 0x00000000
ffffffff81a11540 000000000000001f 0000000000000007 ffffffff817d2a6f
ffffffff817a0867 ffffffffffffffcf ffffffff81472836 0000000000000010
0000000000000212 ffffffff81a03ea0 ffffffff81085cb8 ffffffff81085c70
Call Trace:
[<ffffffff8139bf30>] ? acpi_idle_enter+0x116/0x1fb
[<ffffffff81472814>] ? cpuidle_enter_state+0x134/0x220
[<ffffffff81472922>] ? cpuidle_enter+0x12/0x20
[<ffffffff810ad23e>] ? call_cpuidle+0x1e/0x40
[<ffffffff810ad46d>] ? cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
swapper/0 R running task 0 0 0 0x00000000
ffffffff81a03e90 ffffffff8139bf30 ffffffff81ae30b8 00000000810253a9
ffff88083cb1e600 ffffffff81ae30a0 0000000000000002 ffffffff81ae30b8
ffffffff81ae2fe0 ffffffff81a03ed0 ffffffff81472814 000000458b315be4
Call Trace:
[<ffffffff8139bf30>] ? acpi_idle_enter+0x116/0x1fb
[<ffffffff81472814>] ? cpuidle_enter_state+0x134/0x220
[<ffffffff81472922>] ? cpuidle_enter+0x12/0x20
[<ffffffff810ad23e>] ? call_cpuidle+0x1e/0x40
[<ffffffff810ad46d>] ? cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
systemd-hostnamed.service: State 'stop-final-sigterm' timed out. Killing.
systemd-hostnamed.service: Killing process 1507 (systemd-hostnam) with signal SIGKILL.
INFO: task systemd-hostnam:1507 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-hostnam D 0 1507 1 0x00000002
ffff88043a29f200 000000000000c460 ffff88043ab0a1c0 ffff88043cdc0000
ffff88043f9d6718 ffffc9000b67fb88 ffffffff8157ff6e ffffc9000b67fbf8
ffff88043ab0abc0 ffff88043f9d6718 0000000000000000 ffff88043ab0a1c0
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81584e82>] schedule_timeout+0x222/0x3a0
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff810b5de9>] ? get_lock_stats+0x19/0x50
[<ffffffff81585d17>] ? _raw_spin_unlock_irq+0x27/0x50
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81580ffa>] wait_for_common+0xca/0x180
[<ffffffff8108e150>] ? wake_up_q+0x80/0x80
[<ffffffff815810c8>] wait_for_completion+0x18/0x20
[<ffffffff810d82e5>] __wait_rcu_gp+0xc5/0x100
[<ffffffff810dbccd>] synchronize_rcu.part.53+0x2d/0x50
[<ffffffff810dc7e0>] ? __call_rcu.constprop.59+0x270/0x270
[<ffffffff810d8210>] ? rcu_panic+0x20/0x20
[<ffffffff81580f69>] ? wait_for_common+0x39/0x180
[<ffffffff810dbd17>] synchronize_rcu+0x27/0x90
[<ffffffff811fd887>] namespace_unlock+0x47/0x60
[<ffffffff81200639>] drop_collected_mounts+0x89/0x90
[<ffffffff8120246b>] ? put_mnt_ns+0x1b/0x30
[<ffffffff8120246b>] put_mnt_ns+0x1b/0x30
[<ffffffff81085798>] free_nsproxy+0x18/0xb0
[<ffffffff8108593e>] switch_task_namespaces+0x5e/0x70
[<ffffffff8108595b>] exit_task_namespaces+0xb/0x10
[<ffffffff8106652e>] do_exit+0x2de/0xb30
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81066e00>] do_group_exit+0x40/0xc0
[<ffffffff81066e8f>] SyS_exit_group+0xf/0x10
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
=============================================
perf: interrupt took too long (15815 > 15745), lowering kernel.perf_event_max_sample_rate to 12000
INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P0 } 67953 jiffies s: 1039 root: 0x0/T
blocking rcu_node structures:
systemd-hostnamed.service: Processes still around after final SIGKILL. Entering failed mode.
systemd-hostnamed.service: Unit entered failed state.
systemd-hostnamed.service: Failed with result 'timeout'.
Starting system activity accounting tool...
INFO: task NetworkManager:1475 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
NetworkManager D 0 1475 1 0x00000000
ffff88083a8eaf80 000000000000d4d0 ffff88083955c380 ffff8804371d4380
ffff88043f3d6718 ffffc90007f57640 ffffffff8157ff6e ffffc90007f57608
ffff88083955cd80 ffff88043f3d6718 0000000000000000 ffff88083955c380
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff810da9d4>] _synchronize_rcu_expedited+0x344/0x350
[<ffffffff810da5c0>] ? rcu_momentary_dyntick_idle+0xa0/0xa0
[<ffffffff810acd10>] ? wake_atomic_t_function+0x50/0x50
[<ffffffff810da5c0>] ? rcu_momentary_dyntick_idle+0xa0/0xa0
[<ffffffff810dacf0>] ? rcu_seq_end+0x40/0x40
[<ffffffff810daca7>] synchronize_rcu_expedited+0x17/0x20
[<ffffffff814aaf6c>] synchronize_net+0x2c/0x30
[<ffffffff814daf8c>] dev_deactivate_many+0x2cc/0x2e0
[<ffffffff814a6971>] __dev_close_many+0x71/0xe0
[<ffffffff814a6b21>] __dev_close+0x31/0x50
[<ffffffff814b16a8>] __dev_change_flags+0x98/0x160
[<ffffffff814b1794>] dev_change_flags+0x24/0x60
[<ffffffff810253a9>] ? sched_clock+0x9/0x10
[<ffffffff814c3c96>] do_setlink+0x2e6/0xcc0
[<ffffffff810b9b64>] ? __lock_acquire+0x454/0x1b00
[<ffffffff813081c1>] ? nla_parse+0x31/0x120
[<ffffffff814c6750>] rtnl_newlink+0x5c0/0x860
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff810b5de9>] ? get_lock_stats+0x19/0x50
[<ffffffff814c6a6f>] rtnetlink_rcv_msg+0x7f/0x1e0
[<ffffffff8158178a>] ? mutex_lock_nested+0x2fa/0x430
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814c69f0>] ? rtnl_newlink+0x860/0x860
[<ffffffff814e7eef>] netlink_rcv_skb+0x9f/0xc0
[<ffffffff814c3295>] rtnetlink_rcv+0x25/0x30
[<ffffffff814e7865>] netlink_unicast+0x155/0x1f0
[<ffffffff814e7cad>] netlink_sendmsg+0x2dd/0x360
[<ffffffff8148d682>] sock_sendmsg+0x12/0x20
[<ffffffff8148ddfc>] ___sys_sendmsg+0x2ac/0x2c0
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff811fb60b>] ? __fget+0x10b/0x1f0
[<ffffffff811fb500>] ? expand_files+0x2a0/0x2a0
[<ffffffff811fb730>] ? __fget_light+0x20/0x60
[<ffffffff8148ed60>] __sys_sendmsg+0x40/0x70
[<ffffffff8148ed9d>] SyS_sendmsg+0xd/0x20
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
2 locks held by nano/2071:
#0: (&tty->ldisc_sem){++++.+}, at: [<ffffffff8158549d>] ldsem_down_read+0x2d/0x40
#1: (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff813c4363>] n_tty_read+0xb3/0x8e0
=============================================
INFO: task systemd-hostnam:1507 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-hostnam D 0 1507 1 0x00000002
ffff88043a29f200 000000000000c460 ffff88043ab0a1c0 ffff88043cdc0000
ffff88043f9d6718 ffffc9000b67fb88 ffffffff8157ff6e ffffc9000b67fbf8
ffff88043ab0abc0 ffff88043f9d6718 0000000000000000 ffff88043ab0a1c0
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81584e82>] schedule_timeout+0x222/0x3a0
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff810b5de9>] ? get_lock_stats+0x19/0x50
[<ffffffff81585d17>] ? _raw_spin_unlock_irq+0x27/0x50
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81580ffa>] wait_for_common+0xca/0x180
[<ffffffff8108e150>] ? wake_up_q+0x80/0x80
[<ffffffff815810c8>] wait_for_completion+0x18/0x20
[<ffffffff810d82e5>] __wait_rcu_gp+0xc5/0x100
[<ffffffff810dbccd>] synchronize_rcu.part.53+0x2d/0x50
[<ffffffff810dc7e0>] ? __call_rcu.constprop.59+0x270/0x270
[<ffffffff810d8210>] ? rcu_panic+0x20/0x20
[<ffffffff81580f69>] ? wait_for_common+0x39/0x180
[<ffffffff810dbd17>] synchronize_rcu+0x27/0x90
[<ffffffff811fd887>] namespace_unlock+0x47/0x60
[<ffffffff81200639>] drop_collected_mounts+0x89/0x90
[<ffffffff8120246b>] ? put_mnt_ns+0x1b/0x30
[<ffffffff8120246b>] put_mnt_ns+0x1b/0x30
[<ffffffff81085798>] free_nsproxy+0x18/0xb0
[<ffffffff8108593e>] switch_task_namespaces+0x5e/0x70
[<ffffffff8108595b>] exit_task_namespaces+0xb/0x10
[<ffffffff8106652e>] do_exit+0x2de/0xb30
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81066e00>] do_group_exit+0x40/0xc0
[<ffffffff81066e8f>] SyS_exit_group+0xf/0x10
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
2 locks held by nano/2071:
#0: (&tty->ldisc_sem){++++.+}, at: [<ffffffff8158549d>] ldsem_down_read+0x2d/0x40
#1: (&ldata->atomic_read_lock){+.+...}, at: [<ffffffff813c4363>] n_tty_read+0xb3/0x8e0
=============================================
INFO: rcu_preempt detected stalls on CPUs/tasks:
Tasks blocked on level-0 rcu_node (CPUs 0-15): P0
(detected by 5, t=455012 jiffies, g=3241, c=3240, q=17768)
swapper/0 R running task 0 0 0 0x00000000
ffffffff81a11540 000000000000001f 0000000000000007 ffffffff817d2a6f
ffffffff817a0867 ffffffffffffffcf ffffffff81472836 0000000000000010
0000000000000216 ffffffff81a03ea0 0000000000000018 00000072f2ea5c0d
Call Trace:
[<ffffffff81472836>] ? cpuidle_enter_state+0x156/0x220
[<ffffffff815804eb>] ? schedule+0x3b/0x90
[<ffffffff81580943>] ? schedule_preempt_disabled+0x13/0x20
[<ffffffff810ad4c9>] ? cpu_startup_entry+0x179/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
swapper/0 R running task 0 0 0 0x00000000
ffff880439c31c80 0000000000003392 ffffffff81a11540 ffff88043cd40000
ffff88043efd6718 ffffffff81a03ec8 ffffffff8157ff6e 00000000001d6700
ffffffff81a11f48 ffff88043efd6718 0000000000000000 ffffffff81a11540
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff811736c7>] ? quiet_vmstat+0x47/0x50
[<ffffffff81026654>] ? arch_cpu_idle_enter+0x24/0x30
[<ffffffff810ad46d>] ? cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
perf: interrupt took too long (19983 > 19768), lowering kernel.perf_event_max_sample_rate to 10000
......
INFO: task sd-resolve:1445 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sd-resolve D 0 1445 1 0x00000000
ffff88043a299300 00000000000078cb ffff88043c56c380 ffff88043cdc4380
ffff88043fdd6718 ffffc90008093c90 ffffffff8157ff6e ffff88043c56cff0
ffff88043c56cd80 ffff88043fdd6718 0000000000000000 ffff88043c56c380
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815815ef>] ? mutex_lock_nested+0x15f/0x430
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81580943>] schedule_preempt_disabled+0x13/0x20
[<ffffffff81581630>] mutex_lock_nested+0x1a0/0x430
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814e4870>] ? netlink_deliver_tap+0x90/0x2b0
[<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
[<ffffffff814e7865>] netlink_unicast+0x155/0x1f0
[<ffffffff814e7cad>] netlink_sendmsg+0x2dd/0x360
[<ffffffff8148d682>] sock_sendmsg+0x12/0x20
[<ffffffff8148e952>] SyS_sendto+0xf2/0x170
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff8100201a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
1 lock held by sudo/2214:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
=============================================
INFO: task NetworkManager:1475 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
NetworkManager D 0 1475 1 0x00000000
ffff88083a8eaf80 000000000000d4d0 ffff88083955c380 ffff8804371d4380
ffff88043f3d6718 ffffc90007f57640 ffffffff8157ff6e ffffc90007f57608
ffff88083955cd80 ffff88043f3d6718 0000000000000000 ffff88083955c380
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff810da9d4>] _synchronize_rcu_expedited+0x344/0x350
[<ffffffff810da5c0>] ? rcu_momentary_dyntick_idle+0xa0/0xa0
[<ffffffff810acd10>] ? wake_atomic_t_function+0x50/0x50
[<ffffffff810da5c0>] ? rcu_momentary_dyntick_idle+0xa0/0xa0
[<ffffffff810dacf0>] ? rcu_seq_end+0x40/0x40
[<ffffffff810daca7>] synchronize_rcu_expedited+0x17/0x20
[<ffffffff814aaf6c>] synchronize_net+0x2c/0x30
[<ffffffff814daf8c>] dev_deactivate_many+0x2cc/0x2e0
[<ffffffff814a6971>] __dev_close_many+0x71/0xe0
[<ffffffff814a6b21>] __dev_close+0x31/0x50
[<ffffffff814b16a8>] __dev_change_flags+0x98/0x160
[<ffffffff814b1794>] dev_change_flags+0x24/0x60
[<ffffffff810253a9>] ? sched_clock+0x9/0x10
[<ffffffff814c3c96>] do_setlink+0x2e6/0xcc0
[<ffffffff810b9b64>] ? __lock_acquire+0x454/0x1b00
[<ffffffff813081c1>] ? nla_parse+0x31/0x120
[<ffffffff814c6750>] rtnl_newlink+0x5c0/0x860
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff810b5de9>] ? get_lock_stats+0x19/0x50
[<ffffffff814c6a6f>] rtnetlink_rcv_msg+0x7f/0x1e0
[<ffffffff8158178a>] ? mutex_lock_nested+0x2fa/0x430
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814c69f0>] ? rtnl_newlink+0x860/0x860
[<ffffffff814e7eef>] netlink_rcv_skb+0x9f/0xc0
[<ffffffff814c3295>] rtnetlink_rcv+0x25/0x30
[<ffffffff814e7865>] netlink_unicast+0x155/0x1f0
[<ffffffff814e7cad>] netlink_sendmsg+0x2dd/0x360
[<ffffffff8148d682>] sock_sendmsg+0x12/0x20
[<ffffffff8148ddfc>] ___sys_sendmsg+0x2ac/0x2c0
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff811fb60b>] ? __fget+0x10b/0x1f0
[<ffffffff811fb500>] ? expand_files+0x2a0/0x2a0
[<ffffffff811fb730>] ? __fget_light+0x20/0x60
[<ffffffff8148ed60>] __sys_sendmsg+0x40/0x70
[<ffffffff8148ed9d>] SyS_sendmsg+0xd/0x20
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
1 lock held by sudo/2214:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
=============================================
INFO: task systemd-hostnam:1507 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
systemd-hostnam D 0 1507 1 0x00000002
ffff88043a29f200 000000000000c460 ffff88043ab0a1c0 ffff88043cdc0000
ffff88043f9d6718 ffffc9000b67fb88 ffffffff8157ff6e ffffc9000b67fbf8
ffff88043ab0abc0 ffff88043f9d6718 0000000000000000 ffff88043ab0a1c0
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81584e82>] schedule_timeout+0x222/0x3a0
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff810b5de9>] ? get_lock_stats+0x19/0x50
[<ffffffff81585d17>] ? _raw_spin_unlock_irq+0x27/0x50
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81580ffa>] wait_for_common+0xca/0x180
[<ffffffff8108e150>] ? wake_up_q+0x80/0x80
[<ffffffff815810c8>] wait_for_completion+0x18/0x20
[<ffffffff810d82e5>] __wait_rcu_gp+0xc5/0x100
[<ffffffff810dbccd>] synchronize_rcu.part.53+0x2d/0x50
[<ffffffff810dc7e0>] ? __call_rcu.constprop.59+0x270/0x270
[<ffffffff810d8210>] ? rcu_panic+0x20/0x20
[<ffffffff81580f69>] ? wait_for_common+0x39/0x180
[<ffffffff810dbd17>] synchronize_rcu+0x27/0x90
[<ffffffff811fd887>] namespace_unlock+0x47/0x60
[<ffffffff81200639>] drop_collected_mounts+0x89/0x90
[<ffffffff8120246b>] ? put_mnt_ns+0x1b/0x30
[<ffffffff8120246b>] put_mnt_ns+0x1b/0x30
[<ffffffff81085798>] free_nsproxy+0x18/0xb0
[<ffffffff8108593e>] switch_task_namespaces+0x5e/0x70
[<ffffffff8108595b>] exit_task_namespaces+0xb/0x10
[<ffffffff8106652e>] do_exit+0x2de/0xb30
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81066e00>] do_group_exit+0x40/0xc0
[<ffffffff81066e8f>] SyS_exit_group+0xf/0x10
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
1 lock held by sudo/2214:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
=============================================
INFO: task kworker/2:7:1630 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
kworker/2:7 D 0 1630 2 0x00000000
Workqueue: events wait_rcu_exp_gp
ffff880439c31c80 000000000000affb ffff8804371d4380 ffff88043bddc380
ffff88043f3d6718 ffffc9000c157be8 ffffffff8157ff6e ffffc9000c157bb0
ffff8804371d4d80 ffff88043f3d6718 0000000000000000 ffff8804371d4380
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81584e4b>] schedule_timeout+0x1eb/0x3a0
[<ffffffff810e1410>] ? del_timer_sync+0xd0/0xd0
[<ffffffff810acdf7>] ? prepare_to_swait+0x67/0x90
[<ffffffff810daff5>] wait_rcu_exp_gp+0x305/0xa10
[<ffffffff8107d62c>] process_one_work+0x24c/0x4d0
[<ffffffff8107d5c6>] ? process_one_work+0x1e6/0x4d0
[<ffffffff8107d8f6>] worker_thread+0x46/0x4f0
[<ffffffff8107d8b0>] ? process_one_work+0x4d0/0x4d0
[<ffffffff810840fe>] kthread+0xee/0x110
[<ffffffff81084010>] ? kthread_park+0x60/0x60
[<ffffffff815868ea>] ret_from_fork+0x2a/0x40
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
1 lock held by sudo/2214:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
=============================================
INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { P0 } 264561 jiffies s: 1039 root: 0x0/T
blocking rcu_node structures:
session-c1.scope: Stopping timed out. Killing.
session-c1.scope: Killing process 2214 (sudo) with signal SIGKILL.
gpm.service: State 'stop-sigterm' timed out. Killing.
gpm.service: Killing process 1461 (gpm) with signal SIGKILL.
perf: interrupt took too long (25099 > 24978), lowering kernel.perf_event_max_sample_rate to 7000
INFO: rcu_preempt detected stalls on CPUs/tasks:
Tasks blocked on level-0 rcu_node (CPUs 0-15): P0
(detected by 1, t=650017 jiffies, g=3241, c=3240, q=28138)
swapper/0 R running task 0 0 0 0x00000000
ffffffff81a03e90 ffffffff8139bf30 ffffffff81ae30b8 00000000810253a9
ffff88083cb1e600 ffffffff81ae30a0 0000000000000002 ffffffff81ae30b8
ffffffff81ae2fe0 ffffffff81a03ed0 ffffffff81472814 000000a05ac4422f
Call Trace:
[<ffffffff8139bf30>] ? acpi_idle_enter+0x116/0x1fb
[<ffffffff81472814>] ? cpuidle_enter_state+0x134/0x220
[<ffffffff81472922>] ? cpuidle_enter+0x12/0x20
[<ffffffff810ad23e>] ? call_cpuidle+0x1e/0x40
[<ffffffff810ad46d>] ? cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
swapper/0 R running task 0 0 0 0x00000000
ffffffff81a03e90 ffffffff8139bf30 ffffffff81ae30b8 00000000810253a9
ffff88083cb1e600 ffffffff81ae30a0 0000000000000002 ffffffff81ae30b8
ffffffff81ae2fe0 ffffffff81a03ed0 ffffffff81472814 000000a05ac4422f
Call Trace:
[<ffffffff8139bf30>] ? acpi_idle_enter+0x116/0x1fb
[<ffffffff81472814>] ? cpuidle_enter_state+0x134/0x220
[<ffffffff81472922>] ? cpuidle_enter+0x12/0x20
[<ffffffff810ad23e>] ? call_cpuidle+0x1e/0x40
[<ffffffff810ad46d>] ? cpu_startup_entry+0x11d/0x210
[<ffffffff8157892c>] ? rest_init+0x12c/0x140
[<ffffffff81d02ec3>] ? start_kernel+0x40f/0x41c
[<ffffffff81d02120>] ? early_idt_handler_array+0x120/0x120
[<ffffffff81d02299>] ? x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d02386>] ? x86_64_start_kernel+0xeb/0xf8
session-c1.scope: Still around after SIGKILL. Ignoring.
Stopped Session c1 of user root.
session-c1.scope: Unit entered failed state.
gpm.service: Processes still around after SIGKILL. Ignoring.
Removed slice User Slice of root.
Stopping Login Service...
Stopping Permit User Sessions...
Stopped Permit User Sessions.
Stopped target Remote File Systems.
Stopped target Network.
Stopping Network Manager...
Stopping WPA supplicant...
INFO: task sd-resolve:1445 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
sd-resolve D 0 1445 1 0x00000000
ffff88043a299300 00000000000078cb ffff88043c56c380 ffff88043cdc4380
ffff88043fdd6718 ffffc90008093c90 ffffffff8157ff6e ffff88043c56cff0
ffff88043c56cd80 ffff88043fdd6718 0000000000000000 ffff88043c56c380
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815815ef>] ? mutex_lock_nested+0x15f/0x430
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81580943>] schedule_preempt_disabled+0x13/0x20
[<ffffffff81581630>] mutex_lock_nested+0x1a0/0x430
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814c3286>] ? rtnetlink_rcv+0x16/0x30
[<ffffffff814e4870>] ? netlink_deliver_tap+0x90/0x2b0
[<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
[<ffffffff814e7865>] netlink_unicast+0x155/0x1f0
[<ffffffff814e7cad>] netlink_sendmsg+0x2dd/0x360
[<ffffffff8148d682>] sock_sendmsg+0x12/0x20
[<ffffffff8148e952>] SyS_sendto+0xf2/0x170
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff8100201a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
1 lock held by wpa_supplicant/1512:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
1 lock held by sudo/2214:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
=============================================
INFO: task gpm:1461 blocked for more than 120 seconds.
Tainted: G I 4.9-fw1 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
gpm D 0 1461 1 0x00000002
ffff880439d59300 0000000000001482 ffff8804371bc380 ffff88083c8e8000
ffff88083efd6718 ffffc9000b523b78 ffffffff8157ff6e ffffc9000b523be8
ffff8804371bcd80 ffff88083efd6718 0000000000000000 ffff8804371bc380
Call Trace:
[<ffffffff8157ff6e>] ? __schedule+0x2ce/0x810
[<ffffffff815804eb>] schedule+0x3b/0x90
[<ffffffff81584e82>] schedule_timeout+0x222/0x3a0
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff812fe1f7>] ? debug_smp_processor_id+0x17/0x20
[<ffffffff810b5de9>] ? get_lock_stats+0x19/0x50
[<ffffffff81585d17>] ? _raw_spin_unlock_irq+0x27/0x50
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81580ffa>] wait_for_common+0xca/0x180
[<ffffffff8108e150>] ? wake_up_q+0x80/0x80
[<ffffffff815810c8>] wait_for_completion+0x18/0x20
[<ffffffff810d82e5>] __wait_rcu_gp+0xc5/0x100
[<ffffffff810dbccd>] synchronize_rcu.part.53+0x2d/0x50
[<ffffffff810dc7e0>] ? __call_rcu.constprop.59+0x270/0x270
[<ffffffff810d8210>] ? rcu_panic+0x20/0x20
[<ffffffff81580f69>] ? wait_for_common+0x39/0x180
[<ffffffff810dbd17>] synchronize_rcu+0x27/0x90
[<ffffffff81459c5e>] mousedev_release+0x4e/0x70
[<ffffffff811dc51a>] __fput+0xba/0x200
[<ffffffff811dc699>] ____fput+0x9/0x10
[<ffffffff81082680>] task_work_run+0x80/0xb0
[<ffffffff81066533>] do_exit+0x2e3/0xb30
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
[<ffffffff810b92cf>] ? trace_hardirqs_on_caller+0xef/0x200
[<ffffffff81066e00>] do_group_exit+0x40/0xc0
[<ffffffff81066e8f>] SyS_exit_group+0xf/0x10
[<ffffffff81586681>] entry_SYSCALL_64_fastpath+0x1f/0xc2
[<ffffffff812fe213>] ? __this_cpu_preempt_check+0x13/0x20
Showing all locks held in the system:
2 locks held by khungtaskd/108:
#0: (rcu_read_lock){......}, at: [<ffffffff811269af>] watchdog+0x9f/0x490
#1: (tasklist_lock){.+.+..}, at: [<ffffffff810b760d>] debug_show_all_locks+0x3d/0x1a0
1 lock held by sd-resolve/1445:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by NetworkManager/1475:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
#1: (rcu_preempt_state.exp_mutex){+.+...}, at: [<ffffffff810da7d9>] _synchronize_rcu_expedited+0x149/0x350
1 lock held by wpa_supplicant/1512:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
2 locks held by kworker/2:7/1630:
#0: ("events"){.+.+.+}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
#1: ((&rew.rew_work)){+.+...}, at: [<ffffffff8107d5c6>] process_one_work+0x1e6/0x4d0
1 lock held by sudo/2214:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff814c3286>] rtnetlink_rcv+0x16/0x30
=============================================
Full log can be found there :
http://ftp.frugalware.org/pub/other/people/crazy/journalctl-4.9-log
lspci -vv for the card :
02:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01)
Subsystem: Qualcomm Atheros AR93xx Wireless Network Adapter
Physical Slot: 6
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 25
Region 0: Memory at b0220000 (64-bit, non-prefetchable) [size=128K]
[virtual] Expansion ROM at b0200000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 25.000W
DevCtl: Report errors: Correctable- Non-Fatal+ Fatal+ Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <2us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
Status: NegoPending- InProgress-
Capabilities: [300 v1] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: ath9k
Kernel modules: ath9k
Also when disabling the ath9k driver or blacklisting it everything seems normal.
Please let me know when you need more infos.
Best Regards,
Gabrile C
^ permalink raw reply
* Re: [PATCH] qed: fix memory leak of a qed_spq_entry on error failure paths
From: David Miller @ 2016-12-18 15:37 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: colin.king, netdev, linux-kernel, Ariel.Elior, Tomer.Tayar
In-Reply-To: <BL2PR07MB2306151726E6A6E95702776B8D9E0@BL2PR07MB2306.namprd07.prod.outlook.com>
From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Date: Sun, 18 Dec 2016 06:33:50 +0000
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> A qed_spq_entry entry is allocated by qed_sp_init_request but is not kfree'd
>> if an error occurs, causing a memory leak. Fix this by kfree'ing it and also
>> setting *pp_ent to NULL to be safe.
>>
>> Found with static analysis by CoverityScan, CIDs 1389468-1389470
>>
>> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ...
>> +err:
>> + kfree(*pp_ent);
>> + *pp_ent = NULL;
>> +
>> + return rc;
>> }
>
> Hi Colin - thanks for this.
> It would have been preferable to return the previously allocated spq entry.
> I.e., do:
>
> +err:
> + qed_spq_return_entry(p_hwfn, *pp_ent);
> + *pp_ent = NULL;
> + return rc;
Looking at this last night, I came to the same conclusion.
^ permalink raw reply
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