| Age | Commit message (Collapse) | Author |
|---|
|
Not every device has dev->tstats set. So when OVS tries to calculate
vport stats it causes kernel panic. Following patch fixes it by
using standard API to get net-device stats.
---8<---
Unable to handle kernel paging request at virtual address 766b4008
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in: vport_vxlan vxlan ip6_udp_tunnel udp_tunnel tun bridge stp llc openvswitch ipv6
CPU: 7 PID: 1108 Comm: ovs-vswitchd Not tainted 4.3.0-rc3+ #82
PC is at ovs_vport_get_stats+0x150/0x1f8 [openvswitch]
<snip>
Call trace:
[<ffffffbffc0859f8>] ovs_vport_get_stats+0x150/0x1f8 [openvswitch]
[<ffffffbffc07cdb0>] ovs_vport_cmd_fill_info+0x140/0x1e0 [openvswitch]
[<ffffffbffc07cf0c>] ovs_vport_cmd_dump+0xbc/0x138 [openvswitch]
[<ffffffc00045a5ac>] netlink_dump+0xb8/0x258
[<ffffffc00045ace0>] __netlink_dump_start+0x120/0x178
[<ffffffc00045dd9c>] genl_family_rcv_msg+0x2d4/0x308
[<ffffffc00045de58>] genl_rcv_msg+0x88/0xc4
[<ffffffc00045cf24>] netlink_rcv_skb+0xd4/0x100
[<ffffffc00045dab0>] genl_rcv+0x30/0x48
[<ffffffc00045c830>] netlink_unicast+0x154/0x200
[<ffffffc00045cc9c>] netlink_sendmsg+0x308/0x364
[<ffffffc00041e10c>] sock_sendmsg+0x14/0x2c
[<ffffffc000420d58>] SyS_sendto+0xbc/0xf0
Code: aa1603e1 f94037a4 aa1303e2 aa1703e0 (f9400465)
Reported-by: Tomasz Sawicki <tomasz.sawicki@objectiveintegration.uk>
Fixes: 8c876639c98 ("openvswitch: Remove vport stats.")
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Without this patch, if the only instructions using r_X are of the
BPF_LD | BPF_IND type, r_X would not be reset to 0, using whatever
value was there when entering the jited code. With this patch, r_X
will be correctly marked as used so it will be reset to 0 in the
prologue code.
This fix also makes the test "LD_IND byte default X" pass in the
test_bpf module when the ARM JIT is enabled.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
restore the fbdev state if a drm app like X is killed.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
restore the fbdev state if a drm app like X is killed.
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When openvswitch tries allocate memory from offline numa node 0:
stats = kmem_cache_alloc_node(flow_stats_cache, GFP_KERNEL | __GFP_ZERO, 0)
It catches VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid))
[ replaced with VM_WARN_ON(!node_online(nid)) recently ] in linux/gfp.h
This patch disables numa affinity in this case.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When sockets have a native eBPF program attached through
setsockopt(sk, SOL_SOCKET, SO_ATTACH_BPF, ...), and then try to
dump these over getsockopt(sk, SOL_SOCKET, SO_GET_FILTER, ...),
the following panic appears:
[49904.178642] BUG: unable to handle kernel NULL pointer dereference at (null)
[49904.178762] IP: [<ffffffff81610fd9>] sk_get_filter+0x39/0x90
[49904.182000] PGD 86fc9067 PUD 531a1067 PMD 0
[49904.185196] Oops: 0000 [#1] SMP
[...]
[49904.224677] Call Trace:
[49904.226090] [<ffffffff815e3d49>] sock_getsockopt+0x319/0x740
[49904.227535] [<ffffffff812f59e3>] ? sock_has_perm+0x63/0x70
[49904.228953] [<ffffffff815e2fc8>] ? release_sock+0x108/0x150
[49904.230380] [<ffffffff812f5a43>] ? selinux_socket_getsockopt+0x23/0x30
[49904.231788] [<ffffffff815dff36>] SyS_getsockopt+0xa6/0xc0
[49904.233267] [<ffffffff8171b9ae>] entry_SYSCALL_64_fastpath+0x12/0x71
The underlying issue is the very same as in commit b382c0865600
("sock, diag: fix panic in sock_diag_put_filterinfo"), that is,
native eBPF programs don't store an original program since this
is only needed in cBPF ones.
However, sk_get_filter() wasn't updated to test for this at the
time when eBPF could be attached. Just throw an error to the user
to indicate that eBPF cannot be dumped over this interface.
That way, it can also be known that a program _is_ attached (as
opposed to just return 0), and a different (future) method needs
to be consulted for a dump.
Fixes: 89aa075832b0 ("net: sock: allow eBPF programs to be attached to sockets")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@plumgrid.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Conntrack LABELS (plural) are exposed by conntrack; rename the OVS name
for these to be consistent with conntrack.
Fixes: c2ac667 "openvswitch: Allow matching on conntrack label"
Signed-off-by: Joe Stringer <joestringer@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Now send with MSG_PEEK can return data from multiple SKBs.
Unfortunately we take into account the peek offset for each skb,
that is wrong. We need to apply the peek offset only once.
In addition, the peek offset should be used only if MSG_PEEK is set.
Cc: "David S. Miller" <davem@davemloft.net> (maintainer:NETWORKING
Cc: Eric Dumazet <edumazet@google.com> (commit_signer:1/14=7%)
Cc: Aaron Conole <aconole@bytheb.org>
Fixes: 9f389e35674f ("af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag")
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Tested-by: Aaron Conole <aconole@bytheb.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Align with other tc actions.
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
After commit 1ce87720d456 ("net: sched: make cls_u32 lockless")
we began to release tc actions in a RCU callback. However,
mirred action relies on RTNL lock to protect the global
mirred_list, therefore we could have a race condition
between RCU callback and netdevice event, which caused
a list corruption as reported by Vinson.
Instead of relying on RTNL lock, introduce a spinlock to
protect this list.
Note, in non-bind case, it is still called with RTNL lock,
therefore should disable BH too.
Reported-by: Vinson Lee <vlee@twopensource.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Cong Wang <cwang@twopensource.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The driver still was not offloading TSO on GRE tunnels because
it forgot to set the GSO_GRE flag, causing lots of retransmits.
This fixes generic GRE traffic (like a tunnel added like below)
whereas before it would get 1Gb/s or less, now on a 10G adapter
it gets 8.7Gb/s.
ip ad ad 11.1.0.2/24 dev ens2f0
ip l set ens2f0 up
ip link add gre2 type gretap remote 11.1.0.1 local 11.1.0.2 dev ens2f0
ip l set gre2 up
ip ad ad 192.168.124.2/24 dev gre2
ping 192.168.124.1
netperf -H 192.168.124.1
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
Kalle Valo says:
====================
pull-request: wireless-drivers 2015-10-01
ath9k:
* declare required extra tx headroom
ath10k:
* fix DMA related firmware crashes on multiple devices
rt2800usb:
* add usb ID 1b75:3070 for Airlive WT-2000USB
b43:
* probe bcma core (device) rev 0x15
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
There are cases when the created metadata reply is not used. Ensure the
allocated memory is freed also in such cases.
Fixes: 63d008a4e9ee ("ipv4: send arp replies to the correct tunnel")
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
FW dump may be triggered when running init ucode, for example due to a
sysassert. In this case fw_dump_wk may run after mvm is freed, resulting
in a kernel panic.
Fix it by flushing the work.
Fixes: 01b988a708af ("iwlwifi: mvm: allow to collect debug data when restart is disabled")
Cc: <stable@vger.kernel.org> [3.18+]
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
reqsk_timer_handler() tests if icsk_accept_queue.listen_opt
is NULL at its beginning.
By the time it calls inet_csk_reqsk_queue_drop() and
reqsk_queue_unlink(), listener might have been closed and
inet_csk_listen_stop() had called reqsk_queue_yank_acceptq()
which sets icsk_accept_queue.listen_opt to NULL
We therefore need to correctly check listen_opt being NULL
after holding syn_wait_lock for proper synchronization.
Fixes: fa76ce7328b2 ("inet: get rid of central tcp/dccp listener timer")
Fixes: b357a364c57c ("inet: fix possible panic in reqsk_queue_unlink()")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
I’m using the compilation flag -Werror=old-style-declaration, which
requires that the “inline” word would come at the beginning of the code
line.
$ make drivers/net/ethernet/intel/e1000e/e1000e.ko
...
include/net/inet_timewait_sock.h:116:1: error: ‘inline’ is not at
beginning of declaration [-Werror=old-style-declaration]
static void inline inet_twsk_schedule(struct inet_timewait_sock *tw, int
timeo)
include/net/inet_timewait_sock.h:121:1: error: ‘inline’ is not at
beginning of declaration [-Werror=old-style-declaration]
static void inline inet_twsk_reschedule(struct inet_timewait_sock *tw,
int timeo)
Fixes: ed2e92394589 ("tcp/dccp: fix timewait races in timer handling")
Signed-off-by: Raanan Avargil <raanan.avargil@intel.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
During the CT-kill exit flow, the card is powered up and partially
initialized to check if the temperature is already low enough.
Unfortunately the init bails early because the CT-kill flag is set.
Make the code bail early only for HW RF-kill, as was intended by the
author. CT-kill is self-imposed and is not really RF-kill.
Fixes: 31b8b343e019 ("iwlwifi: fix RFkill while calibrating")
Cc: <stable@vger.kernel.org> [3.18+]
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B
device ID.
Cc: <stable@vger.kernerl.org> [3.13+]
Reported-by: Jeremy <jeremy.bomkamp@gmail.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The MODULE_FIRMWARE() for 3160 should be using the 7260 version as
it's done in the device configuration struct instead of referencing
IWL3160_UCODE_API_OK which doesn't even exist.
Cc: <stable@vger.kernel.org> [3.8+]
Reported-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The csa_countdown flag was not cleared when the AP is stopped.
As a result, if the AP was stopped after csa_countdown had started,
all the folowing channel switch commands would fail.
Fix that by clearing the csa_countdown flag when the AP is stopped.
Cc: <stable@vger.kernel.org> [3.17+]
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.
Cc: <stable@vger.kernel.org> [3.1+]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.
Cc: <stable@vger.kernel.org> [3.1+]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
When going into/coming out of D3, the TX PN must be programmed into
and restored from the firmware respectively. The restore was broken
due to my previous commit to move PN assignment into the driver.
Sending the PN to the firmware still worked since we now use the
counter that's shared with mac80211, but accessing it through the
mac80211 API makes no sense now.
Fix this by reading/writing the counter directly. This actually
simplifies the code since we don't need to round-trip through the
key_seq structure.
Fixes: ca8c0f4bede6 ("iwlwifi: mvm: move TX PN assignment for CCMP to the driver")
Cc: <stable@vger.kernel.org> [4.1+]
Reported-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
|
|
If common clock framework is configured, the driver generates warnings,
which are fixed by this change:
WARNING: CPU: 0 PID: 1 at linux/drivers/clk/clk.c:727 clk_core_enable+0x2c/0xa4()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.3.0-rc2+ #141
Hardware name: LPC32XX SoC (Flattened Device Tree)
Backtrace:
[<>] (dump_backtrace) from [<>] (show_stack+0x18/0x1c)
[<>] (show_stack) from [<>] (dump_stack+0x20/0x28)
[<>] (dump_stack) from [<>] (warn_slowpath_common+0x90/0xb8)
[<>] (warn_slowpath_common) from [<>] (warn_slowpath_null+0x24/0x2c)
[<>] (warn_slowpath_null) from [<>] (clk_core_enable+0x2c/0xa4)
[<>] (clk_core_enable) from [<>] (clk_enable+0x24/0x38)
[<>] (clk_enable) from [<>] (lpc_eth_drv_probe+0xfc/0x99c)
[<>] (lpc_eth_drv_probe) from [<>] (platform_drv_probe+0x50/0xa0)
[<>] (platform_drv_probe) from [<>] (driver_probe_device+0x18c/0x408)
[<>] (driver_probe_device) from [<>] (__driver_attach+0x70/0x94)
[<>] (__driver_attach) from [<>] (bus_for_each_dev+0x74/0x98)
[<>] (bus_for_each_dev) from [<>] (driver_attach+0x20/0x28)
[<>] (driver_attach) from [<>] (bus_add_driver+0x11c/0x248)
[<>] (bus_add_driver) from [<>] (driver_register+0xa4/0xe8)
[<>] (driver_register) from [<>] (__platform_driver_register+0x50/0x64)
[<>] (__platform_driver_register) from [<>] (lpc_eth_driver_init+0x18/0x20)
[<>] (lpc_eth_driver_init) from [<>] (do_one_initcall+0x11c/0x1dc)
[<>] (do_one_initcall) from [<>] (kernel_init_freeable+0x10c/0x1d4)
[<>] (kernel_init_freeable) from [<>] (kernel_init+0x10/0xec)
[<>] (kernel_init) from [<>] (ret_from_fork+0x14/0x24)
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If asix_rx_fixup_internal() fails to allocate rx->ax_skb, it will return
but not clear rx->size. rx points to driver private data. A later call
assumes that nonzero size means ax_skb was allocated and passes a null
ax_skb to skb_put. Changed allocation failure return to clear size first.
Found testing board with AX88772B devices.
Signed-off-by: David B. Robins <linux@davidrobins.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2015-09-30
this is a pull request of a single patch for 4.3.
The patch is by Stephane Grosjean and add support for the peak OEM PCI card to
the peak_pci driver by adding its device ID.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Added kfree() to avoid the memory leak when debugfs_create_dir() fails.
Signed-off-by: Geliang Tang <geliangtang@163.com>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Since commit 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release"),
pppoe_release() calls dev_put(po->pppoe_dev) if sk is in the
PPPOX_ZOMBIE state. But pppoe_flush_dev() can set sk->sk_state to
PPPOX_ZOMBIE _and_ reset po->pppoe_dev to NULL. This leads to the
following oops:
[ 570.140800] BUG: unable to handle kernel NULL pointer dereference at 00000000000004e0
[ 570.142931] IP: [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[ 570.144601] PGD 3d119067 PUD 3dbc1067 PMD 0
[ 570.144601] Oops: 0000 [#1] SMP
[ 570.144601] Modules linked in: l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoe pppox ppp_generic slhc loop crc32c_intel ghash_clmulni_intel jitterentropy_rng sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 ablk_helper cryptd lrw gf128mul glue_helper acpi_cpufreq evdev serio_raw processor button ext4 crc16 mbcache jbd2 virtio_net virtio_blk virtio_pci virtio_ring virtio
[ 570.144601] CPU: 1 PID: 15738 Comm: ppp-apitest Not tainted 4.2.0 #1
[ 570.144601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
[ 570.144601] task: ffff88003d30d600 ti: ffff880036b60000 task.ti: ffff880036b60000
[ 570.144601] RIP: 0010:[<ffffffffa018c701>] [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[ 570.144601] RSP: 0018:ffff880036b63e08 EFLAGS: 00010202
[ 570.144601] RAX: 0000000000000000 RBX: ffff880034340000 RCX: 0000000000000206
[ 570.144601] RDX: 0000000000000006 RSI: ffff88003d30dd20 RDI: ffff88003d30dd20
[ 570.144601] RBP: ffff880036b63e28 R08: 0000000000000001 R09: 0000000000000000
[ 570.144601] R10: 00007ffee9b50420 R11: ffff880034340078 R12: ffff8800387ec780
[ 570.144601] R13: ffff8800387ec7b0 R14: ffff88003e222aa0 R15: ffff8800387ec7b0
[ 570.144601] FS: 00007f5672f48700(0000) GS:ffff88003fc80000(0000) knlGS:0000000000000000
[ 570.144601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 570.144601] CR2: 00000000000004e0 CR3: 0000000037f7e000 CR4: 00000000000406a0
[ 570.144601] Stack:
[ 570.144601] ffffffffa018f240 ffff8800387ec780 ffffffffa018f240 ffff8800387ec7b0
[ 570.144601] ffff880036b63e48 ffffffff812caabe ffff880039e4e000 0000000000000008
[ 570.144601] ffff880036b63e58 ffffffff812cabad ffff880036b63ea8 ffffffff811347f5
[ 570.144601] Call Trace:
[ 570.144601] [<ffffffff812caabe>] sock_release+0x1a/0x75
[ 570.144601] [<ffffffff812cabad>] sock_close+0xd/0x11
[ 570.144601] [<ffffffff811347f5>] __fput+0xff/0x1a5
[ 570.144601] [<ffffffff811348cb>] ____fput+0x9/0xb
[ 570.144601] [<ffffffff81056682>] task_work_run+0x66/0x90
[ 570.144601] [<ffffffff8100189e>] prepare_exit_to_usermode+0x8c/0xa7
[ 570.144601] [<ffffffff81001a26>] syscall_return_slowpath+0x16d/0x19b
[ 570.144601] [<ffffffff813babb1>] int_ret_from_sys_call+0x25/0x9f
[ 570.144601] Code: 48 8b 83 c8 01 00 00 a8 01 74 12 48 89 df e8 8b 27 14 e1 b8 f7 ff ff ff e9 b7 00 00 00 8a 43 12 a8 0b 74 1c 48 8b 83 a8 04 00 00 <48> 8b 80 e0 04 00 00 65 ff 08 48 c7 83 a8 04 00 00 00 00 00 00
[ 570.144601] RIP [<ffffffffa018c701>] pppoe_release+0x50/0x101 [pppoe]
[ 570.144601] RSP <ffff880036b63e08>
[ 570.144601] CR2: 00000000000004e0
[ 570.200518] ---[ end trace 46956baf17349563 ]---
pppoe_flush_dev() has no reason to override sk->sk_state with
PPPOX_ZOMBIE. pppox_unbind_sock() already sets sk->sk_state to
PPPOX_DEAD, which is the correct state given that sk is unbound and
po->pppoe_dev is NULL.
Fixes: 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
Tested-by: Oleksii Berezhniak <core@irc.lg.ua>
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Some GCC versions (e.g. 4.8.3) can incorrectly inline a function with
MIPS32 instructions into another function with MIPS16 code [1], causing
the assembler to genereate incorrect binary code or fail right away
complaining about unrecognized opcode.
In the case of __arch_swab{16,32}, when inlined by the compiler with
flags `-mips32r2 -mips16 -Os', the assembler can fail with the following
error.
{standard input}:79: Error: unrecognized opcode `wsbh $2,$2'
For performance concerns and to workaround the issue already existing in
older compilers, just ignore these 2 functions when compiling with
mips16 enabled.
[1] Inlining nomips16 function into mips16 function can result in
undefined builtins, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55777
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11241/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
This reverts commit e0d8b2ec532852d4b5aabcec3e7611848c32237d.
For at least GCC 4.8.3, adding nomips16 function attribute still cannot
prevent it from being inlined in mips16 context. So revert it first in
preparation for a better workaround.
[1] Inlining nomips16 function into mips16 function can result in
undefined builtins, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55777
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Cc: Maciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11240/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
|
|
If a MCB PCI Carrier device is IO mapped insted of memory-mapped,
the memory of the PCI device is still not unmapped.
Also the patch adds deallocation of the bus
if chameleon_parse_cells() fails.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The recent widget power saving introduced some unavoidable click
noises on old IDT 92HD73xx chips while it still seems working on the
compatible new chips. In the bugzilla, we tried lots of tests and
workarounds, but they didn't help much. So, let's disable the feature
for these specific chips as the least (but safest) fix.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104981
Cc: <stable@vger.kernel.org> # v4.1+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Here is a patch to make speakup-r work again.
It broke in 3.6 due to commit 4369c64c79a22b98d3b7eff9d089196cd878a10a
"Input: Send events one packet at a time)
The problem was that the fakekey.c routine to fake a down arrow no
longer functioned properly and putting the input_sync fixed it.
Fixes: 4369c64c79a22b98d3b7eff9d089196cd878a10a
Cc: stable <stable@vger.kernel.org>
Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: John Covici <covici@ccs.covici.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
My device broke a long time ago, so I do not have any
chance of testing things or any reason to continue
maintaining it.
Signed-off-by: Julian Andres Klode <jak@jak-linux.org>
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is mostly a hardening fix, given that write-only access to other
users' ttys is usually only given through setgid tty executables.
Signed-off-by: Jann Horn <jann@thejh.net>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This adds an entry to the uart_config table for PORT_RT2880
enabling rx/tx FIFOs. The UART is actually a Palmchip BK-3103
which is found in several devices from Alchemy/RMI, Ralink, and
Sigma Designs.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Race on buffer data happens when newly committed data is
picked up by an old flush work in the following scenario:
__tty_buffer_request_room does a plain write of tail->commit,
no barriers were executed before that.
At this point flush_to_ldisc reads this new value of commit,
and reads buffer data, no barriers in between.
The committed buffer data is not necessary visible to flush_to_ldisc.
Similar bug happens when tty_schedule_flip commits data.
Update commit with smp_store_release and read commit with
smp_load_acquire, as it is commit that signals data readiness.
This is orthogonal to the existing synchronization on tty_buffer.next,
which is required to not dismiss a buffer with unconsumed data.
The data race was found with KernelThreadSanitizer (KTSAN).
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
tty_buffer_flush frees not acquired buffers.
As the result, for example, read of b->size in tty_buffer_free
can return garbage value which will lead to a huge buffer
hanging in the freelist. This is just the benignest
manifestation of freeing of a not acquired object.
If the object is passed to kfree, heap can be corrupted.
Acquire visibility over the buffer before freeing it.
The data race was found with KernelThreadSanitizer (KTSAN).
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
flush_to_ldisc reads port->itty and checks that it is not NULL,
concurrently release_tty sets port->itty to NULL. It is possible
that flush_to_ldisc loads port->itty once, ensures that it is
not NULL, but then reloads it again and uses. The second load
can already return NULL, which will cause a crash.
Use READ_ONCE to read port->itty.
The data race was found with KernelThreadSanitizer (KTSAN).
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
My colleague ran into a program stall on a x86_64 server, where
n_tty_read() was waiting for data even if there was data in the buffer
in the pty. kernel stack for the stuck process looks like below.
#0 [ffff88303d107b58] __schedule at ffffffff815c4b20
#1 [ffff88303d107bd0] schedule at ffffffff815c513e
#2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818
#3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2
#4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23
#5 [ffff88303d107dd0] tty_read at ffffffff81368013
#6 [ffff88303d107e20] __vfs_read at ffffffff811a3704
#7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57
#8 [ffff88303d107f00] sys_read at ffffffff811a4306
#9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7
There seems to be two problems causing this issue.
First, in drivers/tty/n_tty.c, __receive_buf() stores the data and
updates ldata->commit_head using smp_store_release() and then checks
the wait queue using waitqueue_active(). However, since there is no
memory barrier, __receive_buf() could return without calling
wake_up_interactive_poll(), and at the same time, n_tty_read() could
start to wait in wait_woken() as in the following chart.
__receive_buf() n_tty_read()
------------------------------------------------------------------------
if (waitqueue_active(&tty->read_wait))
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
add_wait_queue(&tty->read_wait, &wait);
...
if (!input_available_p(tty, 0)) {
smp_store_release(&ldata->commit_head,
ldata->read_head);
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------
The second problem is that n_tty_read() also lacks a memory barrier
call and could also cause __receive_buf() to return without calling
wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken()
as in the chart below.
__receive_buf() n_tty_read()
------------------------------------------------------------------------
spin_lock_irqsave(&q->lock, flags);
/* from add_wait_queue() */
...
if (!input_available_p(tty, 0)) {
/* Memory operations issued after the
RELEASE may be completed before the
RELEASE operation has completed */
smp_store_release(&ldata->commit_head,
ldata->read_head);
if (waitqueue_active(&tty->read_wait))
__add_wait_queue(q, wait);
spin_unlock_irqrestore(&q->lock,flags);
/* from add_wait_queue() */
...
timeout = wait_woken(&wait,
TASK_INTERRUPTIBLE, timeout);
------------------------------------------------------------------------
There are also other places in drivers/tty/n_tty.c which have similar
calls to waitqueue_active(), so instead of adding many memory barrier
calls, this patch simply removes the call to waitqueue_active(),
leaving just wake_up*() behind.
This fixes both problems because, even though the memory access before
or after the spinlocks in both wake_up*() and add_wait_queue() can
sneak into the critical section, it cannot go past it and the critical
section assures that they will be serialized (please see "INTER-CPU
ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a
better explanation). Moreover, the resulting code is much simpler.
Latency measurement using a ping-pong test over a pty doesn't show any
visible performance drop.
Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If atmel_init_gpios fails the port has already been marked as busy (in
line 2629), so this must be undone in the error path.
This bug was introduced because I created the patch that finally
became 722ccf416ac2 ("serial: atmel: fix error handling when
mctrl_gpio_init fails") on top of 3.19 which didn't have commit
6fbb9bdf0f3f ("tty/serial: at91: fix error handling in
atmel_serial_probe()") yet.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails")
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit a3a10ce3429e ("Avoid usb reset crashes by making tty_io cdevs truly
dynamic") which mixes using cdev_alloc() and cdev_init() is problematic.
Subsequent call to cdev_init() after cdev_alloc() sets kobj release method
from cdev_dynamic_release() to cdev_default_release() and thus makes it
impossible to free allocated cdev.
This patch also consolidates error path of cdev_add() as cdev can also leak
here if things went wrong.
Signed-off-by: Leon Yu <chianglungyu@gmail.com>
Fixes: a3a10ce3429e ("Avoid usb reset crashes by making tty_io cdevs truly dynamic")
Acked-by: Richard Watts <rrw@kynesim.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d.
Commit ("9e7b399d6528ea") causes the following warning and sometimes
also hangs the system:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:868 mutex_trylock+0x20c/0x22c()
DEBUG_LOCKS_WARN_ON(in_interrupt())
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-next-20150818-00001-g14418a6 #4
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[<80012f08>] (dump_backtrace) from [<800130a4>] (show_stack+0x18/0x1c)
r6:00000364 r5:00000000 r4:00000000 r3:00000000
[<8001308c>] (show_stack) from [<807902b8>] (dump_stack+0x88/0xa4)
[<80790230>] (dump_stack) from [<8002a604>] (warn_slowpath_common+0x80/0xbc)
r5:807945c4 r4:80ab3b50
[<8002a584>] (warn_slowpath_common) from [<8002a6e4>] (warn_slowpath_fmt+0x38/0x40)
r8:00000000 r7:8131100c r6:8054c3cc r5:8131300c r4:80b0a570
[<8002a6b0>] (warn_slowpath_fmt) from [<807945c4>] (mutex_trylock+0x20c/0x22c)
r3:8095d0d8 r2:8095ab28
[<807943b8>] (mutex_trylock) from [<8054c3cc>] (clk_prepare_lock+0x14/0xf4)
r7:8131100c r6:be3f0c80 r5:00000037 r4:be3f0c80
[<8054c3b8>] (clk_prepare_lock) from [<8054dbfc>] (clk_prepare+0x18/0x30)
r5:00000037 r4:be3f0c80
[<8054dbe4>] (clk_prepare) from [<8036a600>] (imx_console_write+0x30/0x244)
r4:812d0bc8 r3:8132b9a4
To reproduce the problem we only need to let the board idle for something
like 30 seconds.
Tested on a imx6q-sabresd.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile
Pull strscpy string copy function implementation from Chris Metcalf.
Chris sent this during the merge window, but I waffled back and forth on
the pull request, which is why it's going in only now.
The new "strscpy()" function is definitely easier to use and more secure
than either strncpy() or strlcpy(), both of which are horrible nasty
interfaces that have serious and irredeemable problems.
strncpy() has a useless return value, and doesn't NUL-terminate an
overlong result. To make matters worse, it pads a short result with
zeroes, which is a performance disaster if you have big buffers.
strlcpy(), by contrast, is a mis-designed "fix" for strlcpy(), lacking
the insane NUL padding, but having a differently broken return value
which returns the original length of the source string. Which means
that it will read characters past the count from the source buffer, and
you have to trust the source to be properly terminated. It also makes
error handling fragile, since the test for overflow is unnecessarily
subtle.
strscpy() avoids both these problems, guaranteeing the NUL termination
(but not excessive padding) if the destination size wasn't zero, and
making the overflow condition very obvious by returning -E2BIG. It also
doesn't read past the size of the source, and can thus be used for
untrusted source data too.
So why did I waffle about this for so long?
Every time we introduce a new-and-improved interface, people start doing
these interminable series of trivial conversion patches.
And every time that happens, somebody does some silly mistake, and the
conversion patch to the improved interface actually makes things worse.
Because the patch is mindnumbing and trivial, nobody has the attention
span to look at it carefully, and it's usually done over large swatches
of source code which means that not every conversion gets tested.
So I'm pulling the strscpy() support because it *is* a better interface.
But I will refuse to pull mindless conversion patches. Use this in
places where it makes sense, but don't do trivial patches to fix things
that aren't actually known to be broken.
* 'strscpy' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
tile: use global strscpy() rather than private copy
string: provide strscpy()
Make asm/word-at-a-time.h available on all architectures
|
|
Use || instead && in state check.
The latter is bogus and leads to following warning:
drivers/misc/mei/hbm.c:1212:46: warning: logical ‘and’ of mutually exclusive tests is always false [-Wlogical-op]
Fixes: 70ef835c84b3 ("mei: support for dynamic clients")
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The sunxi_sid driver doesn't check for kmalloc return status before
derefencing the returned pointer, which could lead to a NULL pointer
dereference if kmalloc failed. Check for its return code to make sure it
deosn't happen.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
A tmp buffer is allocated if cell->bit_offset || cell->nbits.
So the tmp buffer needs to be freed at the same condition to avoid leak.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
It's pointless to test (cell->bit_offset || cell->bit_offset).
nvmem_shift_read_buffer_in_place() should be called when
(cell->bit_offset || cell->nbits).
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The position to read/write must be less than max
register size.
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
