Leo Yan [Tue, 5 Feb 2019 23:24:53 +0000 (16:24 -0700)]
coresight: cpu-debug: Support for CA73 CPUs
[ Upstream commit
a0f890aba2be33377f4eb24e13633c4a76a68f38 ]
This patch is to add the AMBA device ID for CA73 CPU, so that CPU debug
module can be initialized successfully when a SoC contain CA73 CPUs.
This patch has been verified on 96boards Hikey960.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Rui [Fri, 1 Feb 2019 06:13:41 +0000 (14:13 +0800)]
Revert "ACPI / EC: Remove old CLEAR_ON_RESUME quirk"
[ Upstream commit
b6a3e1475b0220378ad32bdf4d8692f058b1fc03 ]
On some Samsung hardware, it is necessary to clear events accumulated by
the EC during sleep. These ECs stop reporting GPEs until they are manually
polled, if too many events are accumulated.
Thus the CLEAR_ON_RESUME quirk is introduced to send EC query commands
unconditionally after resume to clear all the EC query events on those
platforms.
Later, commit
4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME quirk")
removes the CLEAR_ON_RESUME quirk because we thought the new EC IRQ
polling logic should handle this case.
Now it has been proved that the EC IRQ Polling logic does not fix the
issue actually because we got regression report on these Samsung
platforms after removing the quirk.
Thus revert commit
4c237371f290 ("ACPI / EC: Remove old CLEAR_ON_RESUME
quirk") to introduce back the Samsung quirk in this patch.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Tested-by: Ortwin Glück <odi@odi.ch>
Tested-by: Francisco Cribari <cribari@gmail.com>
Tested-by: Balazs Varga <balazs4web@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lars Persson [Wed, 23 Jan 2019 11:59:42 +0000 (12:59 +0100)]
crypto: axis - fix for recursive locking from bottom half
[ Upstream commit
c34a83820f59bb275e5f2d55cd5ea99c64f6ef23 ]
Clients may submit a new requests from the completion callback
context. The driver was not prepared to receive a request in this
state because it already held the request queue lock and a recursive
lock error is triggered.
Now all completions are queued up until we are ready to drop the queue
lock and then delivered.
The fault was triggered by TCP over an IPsec connection in the LTP
test suite:
LTP: starting tcp4_ipsec02 (tcp_ipsec.sh -p ah -m transport -s "100 1000 65535")
BUG: spinlock recursion on CPU#1, genload/943
lock: 0xbf3c3094, .magic:
dead4ead, .owner: genload/943, .owner_cpu: 1
CPU: 1 PID: 943 Comm: genload Tainted: G O 4.9.62-axis5-devel #6
Hardware name: Axis ARTPEC-6 Platform
(unwind_backtrace) from [<
8010d134>] (show_stack+0x18/0x1c)
(show_stack) from [<
803a289c>] (dump_stack+0x84/0x98)
(dump_stack) from [<
8016e164>] (do_raw_spin_lock+0x124/0x128)
(do_raw_spin_lock) from [<
804de1a4>] (artpec6_crypto_submit+0x2c/0xa0)
(artpec6_crypto_submit) from [<
804def38>] (artpec6_crypto_prepare_submit_hash+0xd0/0x54c)
(artpec6_crypto_prepare_submit_hash) from [<
7f3165f0>] (ah_output+0x2a4/0x3dc [ah4])
(ah_output [ah4]) from [<
805df9bc>] (xfrm_output_resume+0x178/0x4a4)
(xfrm_output_resume) from [<
805d283c>] (xfrm4_output+0xac/0xbc)
(xfrm4_output) from [<
80587928>] (ip_queue_xmit+0x140/0x3b4)
(ip_queue_xmit) from [<
805a13b4>] (tcp_transmit_skb+0x4c4/0x95c)
(tcp_transmit_skb) from [<
8059f218>] (tcp_rcv_state_process+0xdf4/0xdfc)
(tcp_rcv_state_process) from [<
805a7530>] (tcp_v4_do_rcv+0x64/0x1ac)
(tcp_v4_do_rcv) from [<
805a9724>] (tcp_v4_rcv+0xa34/0xb74)
(tcp_v4_rcv) from [<
80581d34>] (ip_local_deliver_finish+0x78/0x2b0)
(ip_local_deliver_finish) from [<
8058259c>] (ip_local_deliver+0xe4/0x104)
(ip_local_deliver) from [<
805d23ec>] (xfrm4_transport_finish+0xf4/0x144)
(xfrm4_transport_finish) from [<
805df564>] (xfrm_input+0x4f4/0x74c)
(xfrm_input) from [<
804de420>] (artpec6_crypto_task+0x208/0x38c)
(artpec6_crypto_task) from [<
801271b0>] (tasklet_action+0x60/0xec)
(tasklet_action) from [<
801266d4>] (__do_softirq+0xcc/0x3a4)
(__do_softirq) from [<
80126d20>] (irq_exit+0xf4/0x15c)
(irq_exit) from [<
801741e8>] (__handle_domain_irq+0x68/0xbc)
(__handle_domain_irq) from [<
801014f0>] (gic_handle_irq+0x50/0x94)
(gic_handle_irq) from [<
80657370>] (__irq_usr+0x50/0x80)
Signed-off-by: Lars Persson <larper@axis.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hsin-Yi, Wang [Wed, 9 Jan 2019 06:59:22 +0000 (14:59 +0800)]
drm/panel: panel-innolux: set display off in innolux_panel_unprepare
[ Upstream commit
46f3ceaffa81e846677bca8668e0ad40e643cffd ]
Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
to innolux_panel_unprepare(), so they are consistent with
innolux_panel_enable() and innolux_panel_prepare().
This also fixes some mode check and irq timeout issue in MTK dsi code.
Since some dsi code (e.g. mtk_dsi) have following call trace:
1. drm_panel_disable(), which calls innolux_panel_disable()
2. switch to cmd mode
3. drm_panel_unprepare(), which calls innolux_panel_unprepare()
However, mtk_dsi needs to be in cmd mode to be able to send commands
(e.g. mipi_dsi_dcs_set_display_off() and mipi_dsi_dcs_enter_sleep_mode()),
so we need these functions to be called after the switch to cmd mode happens,
i.e. in innolux_panel_unprepare.
Signed-off-by: Hsin-Yi, Wang <hsinyi@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190109065922.231753-1-hsinyi@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Fri, 14 Dec 2018 15:26:20 +0000 (15:26 +0000)]
lkdtm: Add tests for NULL pointer dereference
[ Upstream commit
59a12205d3c32aee4c13ca36889fdf7cfed31126 ]
Introduce lkdtm tests for NULL pointer dereference: check access or exec
at NULL address, since these errors tend to be reported differently from
the general fault error text. For example from x86:
pr_alert("BUG: unable to handle kernel %s at %px\n",
address < PAGE_SIZE ? "NULL pointer dereference" : "paging request",
(void *)address);
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Wed, 7 Nov 2018 20:14:10 +0000 (20:14 +0000)]
lkdtm: Print real addresses
[ Upstream commit
4c411157a42f122051ae3469bee0b5cabe89e139 ]
Today, when doing a lkdtm test before the readiness of the
random generator, (ptrval) is printed instead of the address
at which it perform the fault:
[ 1597.337030] lkdtm: Performing direct entry EXEC_USERSPACE
[ 1597.337142] lkdtm: attempting ok execution at (ptrval)
[ 1597.337398] lkdtm: attempting bad execution at (ptrval)
[ 1597.337460] kernel tried to execute user page (
77858000) -exploit attempt? (uid: 0)
[ 1597.344769] Unable to handle kernel paging request for instruction fetch
[ 1597.351392] Faulting instruction address: 0x77858000
[ 1597.356312] Oops: Kernel access of bad area, sig: 11 [#1]
If the lkdtm test is done later on, it prints an hashed address.
In both cases this is pointless. The purpose of the test is to
ensure the kernel generates an Oops at the expected address,
so real addresses needs to be printed. This patch fixes that.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Osipenko [Sun, 21 Oct 2018 18:36:14 +0000 (21:36 +0300)]
soc/tegra: pmc: Drop locking from tegra_powergate_is_powered()
[ Upstream commit
b6e1fd17a38bd1d97c11d69fd3207b3ef9bfa4b3 ]
This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
and machine (Tegra30) booted with SMP=n or all secondary CPU's are put
offline. Locking isn't needed because it protects atomic operation.
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:254
in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/0
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C 4.18.0-next-
20180821-00180-gc3ebb6544e44-dirty #823
Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[<
c01134f4>] (unwind_backtrace) from [<
c010db2c>] (show_stack+0x20/0x24)
[<
c010db2c>] (show_stack) from [<
c0bd0f3c>] (dump_stack+0x94/0xa8)
[<
c0bd0f3c>] (dump_stack) from [<
c0151df8>] (___might_sleep+0x13c/0x174)
[<
c0151df8>] (___might_sleep) from [<
c0151ea0>] (__might_sleep+0x70/0xa8)
[<
c0151ea0>] (__might_sleep) from [<
c0bec2b8>] (mutex_lock+0x2c/0x70)
[<
c0bec2b8>] (mutex_lock) from [<
c0589844>] (tegra_powergate_is_powered+0x44/0xa8)
[<
c0589844>] (tegra_powergate_is_powered) from [<
c0581a60>] (tegra30_cpu_rail_off_ready+0x30/0x74)
[<
c0581a60>] (tegra30_cpu_rail_off_ready) from [<
c0122244>] (tegra30_idle_lp2+0xa0/0x108)
[<
c0122244>] (tegra30_idle_lp2) from [<
c0853438>] (cpuidle_enter_state+0x140/0x540)
[<
c0853438>] (cpuidle_enter_state) from [<
c08538a4>] (cpuidle_enter+0x40/0x4c)
[<
c08538a4>] (cpuidle_enter) from [<
c01595e0>] (call_cpuidle+0x30/0x48)
[<
c01595e0>] (call_cpuidle) from [<
c01599f8>] (do_idle+0x238/0x28c)
[<
c01599f8>] (do_idle) from [<
c0159d28>] (cpu_startup_entry+0x28/0x2c)
[<
c0159d28>] (cpu_startup_entry) from [<
c0be76c8>] (rest_init+0xd8/0xdc)
[<
c0be76c8>] (rest_init) from [<
c1200f50>] (start_kernel+0x41c/0x430)
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bart Van Assche [Wed, 27 Feb 2019 00:35:26 +0000 (16:35 -0800)]
scsi: core: Avoid that system resume triggers a kernel warning
[ Upstream commit
388b4e6a00bb3097278ed1648ac5a1cb48c894e6 ]
scsi_device_quiesce() and scsi_device_resume() are called during
system-wide suspend and resume. scsi_device_quiesce() only succeeds for
SCSI devices that are in one of the RUNNING, OFFLINE or TRANSPORT_OFFLINE
states (see also scsi_set_device_state()). This patch avoids that the
following warning is triggered when resuming a system for which quiescing a
SCSI device failed:
WARNING: CPU: 2 PID: 11303 at drivers/scsi/scsi_lib.c:2600 scsi_device_resume+0x4f/0x58
CPU: 2 PID: 11303 Comm: kworker/u8:70 Not tainted 5.0.0-rc1+ #50
Hardware name: LENOVO 80E3/Lancer 5B2, BIOS A2CN45WW(V2.13) 08/04/2016
Workqueue: events_unbound async_run_entry_fn
Call Trace:
scsi_dev_type_resume+0x2e/0x60
async_run_entry_fn+0x32/0xd8
process_one_work+0x1f4/0x420
worker_thread+0x28/0x3c0
kthread+0x118/0x130
ret_from_fork+0x22/0x40
Cc: Przemek Socha <soprwa@gmail.com>
Reported-by: Przemek Socha <soprwa@gmail.com>
Fixes:
3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julia Cartwright [Wed, 20 Feb 2019 16:46:31 +0000 (16:46 +0000)]
iommu/dmar: Fix buffer overflow during PCI bus notification
[ Upstream commit
cffaaf0c816238c45cd2d06913476c83eb50f682 ]
Commit
57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI
device path") changed the type of the path data, however, the change in
path type was not reflected in size calculations. Update to use the
correct type and prevent a buffer overflow.
This bug manifests in systems with deep PCI hierarchies, and can lead to
an overflow of the static allocated buffer (dmar_pci_notify_info_buf),
or can lead to overflow of slab-allocated data.
BUG: KASAN: global-out-of-bounds in dmar_alloc_pci_notify_info+0x1d5/0x2e0
Write of size 1 at addr
ffffffff90445d80 by task swapper/0/1
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.14.87-rt49-02406-gd0a0e96 #1
Call Trace:
? dump_stack+0x46/0x59
? print_address_description+0x1df/0x290
? dmar_alloc_pci_notify_info+0x1d5/0x2e0
? kasan_report+0x256/0x340
? dmar_alloc_pci_notify_info+0x1d5/0x2e0
? e820__memblock_setup+0xb0/0xb0
? dmar_dev_scope_init+0x424/0x48f
? __down_write_common+0x1ec/0x230
? dmar_dev_scope_init+0x48f/0x48f
? dmar_free_unused_resources+0x109/0x109
? cpumask_next+0x16/0x20
? __kmem_cache_create+0x392/0x430
? kmem_cache_create+0x135/0x2f0
? e820__memblock_setup+0xb0/0xb0
? intel_iommu_init+0x170/0x1848
? _raw_spin_unlock_irqrestore+0x32/0x60
? migrate_enable+0x27a/0x5b0
? sched_setattr+0x20/0x20
? migrate_disable+0x1fc/0x380
? task_rq_lock+0x170/0x170
? try_to_run_init_process+0x40/0x40
? locks_remove_file+0x85/0x2f0
? dev_prepare_static_identity_mapping+0x78/0x78
? rt_spin_unlock+0x39/0x50
? lockref_put_or_lock+0x2a/0x40
? dput+0x128/0x2f0
? __rcu_read_unlock+0x66/0x80
? __fput+0x250/0x300
? __rcu_read_lock+0x1b/0x30
? mntput_no_expire+0x38/0x290
? e820__memblock_setup+0xb0/0xb0
? pci_iommu_init+0x25/0x63
? pci_iommu_init+0x25/0x63
? do_one_initcall+0x7e/0x1c0
? initcall_blacklisted+0x120/0x120
? kernel_init_freeable+0x27b/0x307
? rest_init+0xd0/0xd0
? kernel_init+0xf/0x120
? rest_init+0xd0/0xd0
? ret_from_fork+0x1f/0x40
The buggy address belongs to the variable:
dmar_pci_notify_info_buf+0x40/0x60
Fixes:
57384592c433 ("iommu/vt-d: Store bus information in RMRR PCI device path")
Signed-off-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Wed, 20 Feb 2019 08:23:03 +0000 (09:23 +0100)]
net: ip6_gre: fix possible NULL pointer dereference in ip6erspan_set_version
[ Upstream commit
efcc9bcaf77c07df01371a7c34e50424c291f3ac ]
Fix a possible NULL pointer dereference in ip6erspan_set_version checking
nlattr data pointer
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 7549 Comm: syz-executor432 Not tainted 5.0.0-rc6-next-
20190218
#37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
RSP: 0018:
ffff888089ed7168 EFLAGS:
00010202
RAX:
dffffc0000000000 RBX:
ffff8880869d6e58 RCX:
0000000000000000
RDX:
0000000000000016 RSI:
ffffffff862736b4 RDI:
00000000000000b0
RBP:
ffff888089ed7180 R08:
1ffff11010d3adcb R09:
ffff8880869d6e58
R10:
ffffed1010d3add5 R11:
ffff8880869d6eaf R12:
0000000000000000
R13:
ffffffff8931f8c0 R14:
ffffffff862825d0 R15:
ffff8880869d6e58
FS:
0000000000b3d880(0000) GS:
ffff8880ae900000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000020000184 CR3:
0000000092cc5000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
ip6erspan_newlink+0x66/0x7b0 net/ipv6/ip6_gre.c:2210
__rtnl_newlink+0x107b/0x16c0 net/core/rtnetlink.c:3176
rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3234
rtnetlink_rcv_msg+0x465/0xb00 net/core/rtnetlink.c:5192
netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2485
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5210
netlink_unicast_kernel net/netlink/af_netlink.c:1310 [inline]
netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1336
netlink_sendmsg+0x8ae/0xd70 net/netlink/af_netlink.c:1925
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440159
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007fffa69156e8 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
00000000004002c8 RCX:
0000000000440159
RDX:
0000000000000000 RSI:
0000000020001340 RDI:
0000000000000003
RBP:
00000000006ca018 R08:
0000000000000001 R09:
00000000004002c8
R10:
0000000000000011 R11:
0000000000000246 R12:
00000000004019e0
R13:
0000000000401a70 R14:
0000000000000000 R15:
0000000000000000
Modules linked in:
---[ end trace
09f8a7d13b4faaa1 ]---
RIP: 0010:ip6erspan_set_version+0x5c/0x350 net/ipv6/ip6_gre.c:1726
Code: 07 38 d0 7f 08 84 c0 0f 85 9f 02 00 00 49 8d bc 24 b0 00 00 00 c6 43
54 01 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 9a 02 00 00 4d 8b ac 24 b0 00 00 00 4d 85 ed 0f
RSP: 0018:
ffff888089ed7168 EFLAGS:
00010202
RAX:
dffffc0000000000 RBX:
ffff8880869d6e58 RCX:
0000000000000000
RDX:
0000000000000016 RSI:
ffffffff862736b4 RDI:
00000000000000b0
RBP:
ffff888089ed7180 R08:
1ffff11010d3adcb R09:
ffff8880869d6e58
R10:
ffffed1010d3add5 R11:
ffff8880869d6eaf R12:
0000000000000000
R13:
ffffffff8931f8c0 R14:
ffffffff862825d0 R15:
ffff8880869d6e58
FS:
0000000000b3d880(0000) GS:
ffff8880ae900000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000020000184 CR3:
0000000092cc5000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Fixes:
4974d5f678ab ("net: ip6_gre: initialize erspan_ver just for erspan tunnels")
Reported-and-tested-by: syzbot+30191cf1057abd3064af@syzkaller.appspotmail.com
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Sat, 16 Feb 2019 13:51:26 +0000 (14:51 +0100)]
crypto: sha512/arm - fix crash bug in Thumb2 build
[ Upstream commit
c64316502008064c158fa40cc250665e461b0f2a ]
The SHA512 code we adopted from the OpenSSL project uses a rather
peculiar way to take the address of the round constant table: it
takes the address of the sha256_block_data_order() routine, and
substracts a constant known quantity to arrive at the base of the
table, which is emitted by the same assembler code right before
the routine's entry point.
However, recent versions of binutils have helpfully changed the
behavior of references emitted via an ADR instruction when running
in Thumb2 mode: it now takes the Thumb execution mode bit into
account, which is bit 0 af the address. This means the produced
table address also has bit 0 set, and so we end up with an address
value pointing 1 byte past the start of the table, which results
in crashes such as
Unable to handle kernel paging request at virtual address
bf825000
pgd =
42f44b11
[
bf825000] *pgd=
80000040206003, *pmd=
5f1bd003, *pte=
00000000
Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
pc : [<
bf820bca>] lr : [<
bf824ffd>] psr:
800b0033
sp :
ebc8bbe8 ip :
faaabe1c fp :
2fdd3433
r10:
4c5f1692 r9 :
e43037df r8 :
b04b0a5a
r7 :
c369d722 r6 :
39c3693e r5 :
7a013189 r4 :
1580d26b
r3 :
8762a9b0 r2 :
eea9c2cd r1 :
3e9ab536 r0 :
1dea4ae7
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
Control:
70c5383d Table:
6b8467c0 DAC:
dbadc0de
Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
Stack: (0xebc8bbe8 to 0xebc8c000)
...
unwind: Unknown symbol address
bf820bca
unwind: Index not found
bf820bca
Code: 441a ea80 40f9 440a (f85e) 3b04
---[ end trace
e560cce92700ef8a ]---
Given that this affects older kernels as well, in case they are built
with a recent toolchain, apply a minimal backportable fix, which is
to emit another non-code label at the start of the routine, and
reference that instead. (This is similar to the current upstream state
of this file in OpenSSL)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Sat, 16 Feb 2019 13:51:25 +0000 (14:51 +0100)]
crypto: sha256/arm - fix crash bug in Thumb2 build
[ Upstream commit
69216a545cf81b2b32d01948f7039315abaf75a0 ]
The SHA256 code we adopted from the OpenSSL project uses a rather
peculiar way to take the address of the round constant table: it
takes the address of the sha256_block_data_order() routine, and
substracts a constant known quantity to arrive at the base of the
table, which is emitted by the same assembler code right before
the routine's entry point.
However, recent versions of binutils have helpfully changed the
behavior of references emitted via an ADR instruction when running
in Thumb2 mode: it now takes the Thumb execution mode bit into
account, which is bit 0 af the address. This means the produced
table address also has bit 0 set, and so we end up with an address
value pointing 1 byte past the start of the table, which results
in crashes such as
Unable to handle kernel paging request at virtual address
bf825000
pgd =
42f44b11
[
bf825000] *pgd=
80000040206003, *pmd=
5f1bd003, *pte=
00000000
Internal error: Oops: 207 [#1] PREEMPT SMP THUMB2
Modules linked in: sha256_arm(+) sha1_arm_ce sha1_arm ...
CPU: 7 PID: 396 Comm: cryptomgr_test Not tainted 5.0.0-rc6+ #144
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
PC is at sha256_block_data_order+0xaaa/0xb30 [sha256_arm]
LR is at __this_module+0x17fd/0xffffe800 [sha256_arm]
pc : [<
bf820bca>] lr : [<
bf824ffd>] psr:
800b0033
sp :
ebc8bbe8 ip :
faaabe1c fp :
2fdd3433
r10:
4c5f1692 r9 :
e43037df r8 :
b04b0a5a
r7 :
c369d722 r6 :
39c3693e r5 :
7a013189 r4 :
1580d26b
r3 :
8762a9b0 r2 :
eea9c2cd r1 :
3e9ab536 r0 :
1dea4ae7
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment user
Control:
70c5383d Table:
6b8467c0 DAC:
dbadc0de
Process cryptomgr_test (pid: 396, stack limit = 0x69e1fe23)
Stack: (0xebc8bbe8 to 0xebc8c000)
...
unwind: Unknown symbol address
bf820bca
unwind: Index not found
bf820bca
Code: 441a ea80 40f9 440a (f85e) 3b04
---[ end trace
e560cce92700ef8a ]---
Given that this affects older kernels as well, in case they are built
with a recent toolchain, apply a minimal backportable fix, which is
to emit another non-code label at the start of the routine, and
reference that instead. (This is similar to the current upstream state
of this file in OpenSSL)
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Cong Wang [Thu, 31 Jan 2019 21:05:49 +0000 (13:05 -0800)]
xfrm: destroy xfrm_state synchronously on net exit path
[ Upstream commit
f75a2804da391571563c4b6b29e7797787332673 ]
xfrm_state_put() moves struct xfrm_state to the GC list
and schedules the GC work to clean it up. On net exit call
path, xfrm_state_flush() is called to clean up and
xfrm_flush_gc() is called to wait for the GC work to complete
before exit.
However, this doesn't work because one of the ->destructor(),
ipcomp_destroy(), schedules the same GC work again inside
the GC work. It is hard to wait for such a nested async
callback. This is also why syzbot still reports the following
warning:
WARNING: CPU: 1 PID: 33 at net/ipv6/xfrm6_tunnel.c:351 xfrm6_tunnel_net_exit+0x2cb/0x500 net/ipv6/xfrm6_tunnel.c:351
...
ops_exit_list.isra.0+0xb0/0x160 net/core/net_namespace.c:153
cleanup_net+0x51d/0xb10 net/core/net_namespace.c:551
process_one_work+0xd0c/0x1ce0 kernel/workqueue.c:2153
worker_thread+0x143/0x14a0 kernel/workqueue.c:2296
kthread+0x357/0x430 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
In fact, it is perfectly fine to bypass GC and destroy xfrm_state
synchronously on net exit call path, because it is in process context
and doesn't need a work struct to do any blocking work.
This patch introduces xfrm_state_put_sync() which simply bypasses
GC, and lets its callers to decide whether to use this synchronous
version. On net exit path, xfrm_state_fini() and
xfrm6_tunnel_net_exit() use it. And, as ipcomp_destroy() itself is
blocking, it can use xfrm_state_put_sync() directly too.
Also rename xfrm_state_gc_destroy() to ___xfrm_state_destroy() to
reflect this change.
Fixes:
b48c05ab5d32 ("xfrm: Fix warning in xfrm6_tunnel_net_exit.")
Reported-and-tested-by: syzbot+e9aebef558e3ed673934@syzkaller.appspotmail.com
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
shamir rabinovitch [Sun, 16 Dec 2018 07:01:08 +0000 (09:01 +0200)]
net/rds: fix warn in rds_message_alloc_sgs
[ Upstream commit
ea010070d0a7497253d5a6f919f6dd107450b31a ]
redundant copy_from_user in rds_sendmsg system call expose rds
to issue where rds_rdma_extra_size walk the rds iovec and and
calculate the number pf pages (sgs) it need to add to the tail of
rds message and later rds_cmsg_rdma_args copy the rds iovec again
and re calculate the same number and get different result causing
WARN_ON in rds_message_alloc_sgs.
fix this by doing the copy_from_user only once per rds_sendmsg
system call.
When issue occur the below dump is seen:
WARNING: CPU: 0 PID: 19789 at net/rds/message.c:316 rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 19789 Comm: syz-executor827 Not tainted 4.19.0-next-
20181030+ #101
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x244/0x39d lib/dump_stack.c:113
panic+0x2ad/0x55c kernel/panic.c:188
__warn.cold.8+0x20/0x45 kernel/panic.c:540
report_bug+0x254/0x2d0 lib/bug.c:186
fixup_bug arch/x86/kernel/traps.c:178 [inline]
do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969
RIP: 0010:rds_message_alloc_sgs+0x10c/0x160 net/rds/message.c:316
Code: c0 74 04 3c 03 7e 6c 44 01 ab 78 01 00 00 e8 2b 9e 35 fa 4c 89 e0 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 14 9e 35 fa <0f> 0b 31 ff 44 89 ee e8 18 9f 35 fa 45 85 ed 75 1b e8 fe 9d 35 fa
RSP: 0018:
ffff8801c51b7460 EFLAGS:
00010293
RAX:
ffff8801bc412080 RBX:
ffff8801d7bf4040 RCX:
ffffffff8749c9e6
RDX:
0000000000000000 RSI:
ffffffff8749ca5c RDI:
0000000000000004
RBP:
ffff8801c51b7490 R08:
ffff8801bc412080 R09:
ffffed003b5c5b67
R10:
ffffed003b5c5b67 R11:
ffff8801dae2db3b R12:
0000000000000000
R13:
000000000007165c R14:
000000000007165c R15:
0000000000000005
rds_cmsg_rdma_args+0x82d/0x1510 net/rds/rdma.c:623
rds_cmsg_send net/rds/send.c:971 [inline]
rds_sendmsg+0x19a2/0x3180 net/rds/send.c:1273
sock_sendmsg_nosec net/socket.c:622 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:632
___sys_sendmsg+0x7fd/0x930 net/socket.c:2117
__sys_sendmsg+0x11d/0x280 net/socket.c:2155
__do_sys_sendmsg net/socket.c:2164 [inline]
__se_sys_sendmsg net/socket.c:2162 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2162
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x44a859
Code: e8 dc e6 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 6b cb fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:
00007f1d4710ada8 EFLAGS:
00000297 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
00000000006dcc28 RCX:
000000000044a859
RDX:
0000000000000000 RSI:
0000000020001600 RDI:
0000000000000003
RBP:
00000000006dcc20 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000297 R12:
00000000006dcc2c
R13:
646e732f7665642f R14:
00007f1d4710b9c0 R15:
00000000006dcd2c
Kernel Offset: disabled
Rebooting in 86400 seconds..
Reported-by: syzbot+26de17458aeda9d305d8@syzkaller.appspotmail.com
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: shamir rabinovitch <shamir.rabinovitch@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafael J. Wysocki [Mon, 17 Dec 2018 11:21:55 +0000 (12:21 +0100)]
ACPI: EC / PM: Disable non-wakeup GPEs for suspend-to-idle
[ Upstream commit
f941d3e41da7f86bdb9dcc1977c2bcc6b89bfe47 ]
There are systems in which non-wakeup GPEs fire during the "noirq"
suspend stage of suspending devices and that effectively prevents the
system that tries to suspend to idle from entering any low-power
state at all. If the offending GPE fires regularly and often enough,
the system appears to be suspended, but in fact it is in a tight loop
over "noirq" suspend and "noirq" resume of devices all the time.
To prevent that from happening, disable all non-wakeup GPEs except
for the EC GPE for suspend-to-idle (the EC GPE is special, because
on some systems it has to be enabled for power button wakeup events
to be generated as expected).
Fixes:
147a7d9d25ca (ACPI / PM: Do not reconfigure GPEs for suspend-to-idle)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201987
Reported-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ayman Bagabas [Wed, 12 Dec 2018 23:07:57 +0000 (18:07 -0500)]
ALSA: hda: fix front speakers on Huawei MBXP
[ Upstream commit
8ac51bbc4cfec4ef08b03bef24b31e2d50ef8b37 ]
This patch solves bug 200501 'Only 2 of 4 speakers playing sound.'
It enables the front speakers on Huawei Matebook X Pro laptops.
These laptops come with Dolby Atmos sound system and these pins
configuration enables the front speakers.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200501
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ayman Bagabas <ayman.bagabas@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trigger Huang [Tue, 6 Nov 2018 11:37:58 +0000 (19:37 +0800)]
drm/ttm: Fix bo_global and mem_global kfree error
[ Upstream commit
30f33126feca0fe16df9e9302ffc28a953e2eb37 ]
ttm_bo_glob and ttm_mem_glob are defined as structure instance, while
not allocated by kzalloc, so kfree should not be invoked to release
them anymore. Otherwise, it will cause the following kernel BUG when
unloading amdgpu module
[ 48.419294] kernel BUG at /build/linux-5s7Xkn/linux-4.15.0/mm/slub.c:3894!
[ 48.419352] invalid opcode: 0000 [#1] SMP PTI
[ 48.419387] Modules linked in: amdgpu(OE-) amdchash(OE) amdttm(OE) amd_sched(OE) amdkcl(OE) amd_iommu_v2 drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi pcbc snd_seq snd_seq_device snd_timer aesni_intel snd soundcore joydev aes_x86_64 crypto_simd glue_helper cryptd input_leds mac_hid serio_raw binfmt_misc nfsd auth_rpcgss nfs_acl lockd grace sunrpc sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 8139too psmouse i2c_piix4 8139cp mii floppy pata_acpi
[ 48.419782] CPU: 1 PID: 1281 Comm: modprobe Tainted: G OE 4.15.0-20-generic #21-Ubuntu
[ 48.419838] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014
[ 48.419901] RIP: 0010:kfree+0x137/0x180
[ 48.419934] RSP: 0018:
ffffb02101273bf8 EFLAGS:
00010246
[ 48.419974] RAX:
ffffeee1418ad7e0 RBX:
ffffffffc075f100 RCX:
ffff8fed7fca7ed0
[ 48.420025] RDX:
0000000000000000 RSI:
000000000003440e RDI:
0000000022400000
[ 48.420073] RBP:
ffffb02101273c10 R08:
0000000000000010 R09:
ffff8fed7ffd3680
[ 48.420121] R10:
ffffeee1418ad7c0 R11:
ffff8fed7ffd3000 R12:
ffffffffc075e2c0
[ 48.420169] R13:
ffffffffc074ec10 R14:
ffff8fed73063900 R15:
ffff8fed737428e8
[ 48.420216] FS:
00007fdc912ec540(0000) GS:
ffff8fed7fc80000(0000) knlGS:
0000000000000000
[ 48.420267] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 48.420308] CR2:
000055fa40c30060 CR3:
000000023470a006 CR4:
00000000003606e0
[ 48.420358] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 48.420405] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 48.420452] Call Trace:
[ 48.420485] ttm_bo_global_kobj_release+0x20/0x30 [amdttm]
[ 48.420528] kobject_release+0x6a/0x180
[ 48.420562] kobject_put+0x28/0x50
[ 48.420595] ttm_bo_global_release+0x36/0x50 [amdttm]
[ 48.420636] amdttm_bo_device_release+0x119/0x180 [amdttm]
[ 48.420678] ? amdttm_bo_clean_mm+0xa6/0xf0 [amdttm]
[ 48.420760] amdgpu_ttm_fini+0xc9/0x180 [amdgpu]
[ 48.420821] amdgpu_bo_fini+0x12/0x40 [amdgpu]
[ 48.420889] gmc_v9_0_sw_fini+0x40/0x50 [amdgpu]
[ 48.420947] amdgpu_device_fini+0x36f/0x4c0 [amdgpu]
[ 48.421007] amdgpu_driver_unload_kms+0xb4/0x150 [amdgpu]
[ 48.421058] drm_dev_unregister+0x46/0xf0 [drm]
[ 48.421102] drm_dev_unplug+0x12/0x70 [drm]
Signed-off-by: Trigger Huang <Trigger.Huang@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sun, 14 Oct 2018 17:54:27 +0000 (19:54 +0200)]
platform/x86: Add Intel AtomISP2 dummy / power-management driver
[ Upstream commit
49ad712afa88c502831d37f7089d98eac441fb80 ]
The Image Signal Processor found on Cherry Trail devices is brought up in
D0 state on devices which have camera sensors attached to it. The ISP will
not enter D3 state again without some massaging of its registers beforehand
and the ISP not being in D3 state blocks the SoC from entering S0ix modes.
There was a driver for the ISP in drivers/staging but that got removed
again because it never worked. It does not seem likely that a real
driver for the ISP will be added to the mainline kernel anytime soon.
This commit adds a dummy driver which contains the necessary magic from
the staging driver to powerdown the ISP, so that Cherry Trail devices where
the ISP is used will properly use S0ix modes when suspended.
Together with other recent S0ix related fixes this allows S0ix modes to
be entered on e.g. a Chuwi Hi8 Pro and a HP x2 210.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=196915
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vitaly Kuznetsov [Wed, 17 Oct 2018 11:23:55 +0000 (13:23 +0200)]
kernel: hung_task.c: disable on suspend
[ Upstream commit
a1c6ca3c6de763459a6e93b644ec6518c890ba1c ]
It is possible to observe hung_task complaints when system goes to
suspend-to-idle state:
# echo freeze > /sys/power/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done.
sd 0:0:0:0: [sda] Synchronizing SCSI cache
INFO: task bash:1569 blocked for more than 120 seconds.
Not tainted 4.19.0-rc3_+ #687
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
bash D 0 1569 604 0x00000000
Call Trace:
? __schedule+0x1fe/0x7e0
schedule+0x28/0x80
suspend_devices_and_enter+0x4ac/0x750
pm_suspend+0x2c0/0x310
Register a PM notifier to disable the detector on suspend and re-enable
back on wakeup.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steve French [Fri, 19 Oct 2018 06:58:22 +0000 (01:58 -0500)]
cifs: fallback to older infolevels on findfirst queryinfo retry
[ Upstream commit
3b7960caceafdfc2cdfe2850487f8d091eb41144 ]
In cases where queryinfo fails, we have cases in cifs (vers=1.0)
where with backupuid mounts we retry the query info with findfirst.
This doesn't work to some NetApp servers which don't support
WindowsXP (and later) infolevel 261 (SMB_FIND_FILE_ID_FULL_DIR_INFO)
so in this case use other info levels (in this case it will usually
be level 257, SMB_FIND_FILE_DIRECTORY_INFO).
(Also fixes some indentation)
See kernel bugzilla 201435
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thor Thayer [Mon, 22 Oct 2018 22:22:26 +0000 (17:22 -0500)]
net: stmmac: Set OWN bit for jumbo frames
[ Upstream commit
487e2e22ab7968f2c0c82f37b5ca5883efd1a354 ]
Ping with Jumbo packet does not reply and get a watchdog timeout
[ 46.059616] ------------[ cut here ]------------
[ 46.064268] NETDEV WATCHDOG: eth0 (socfpga-dwmac): transmit queue 0 timed out
[ 46.071471] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x2cc/0x2d8
[ 46.079708] Modules linked in:
[ 46.082761] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.18.0-00115-gc262be665854-dirty #264
[ 46.091082] Hardware name: SoCFPGA Stratix 10 SoCDK (DT)
[ 46.096377] pstate:
20000005 (nzCv daif -PAN -UAO)
[ 46.101152] pc : dev_watchdog+0x2cc/0x2d8
[ 46.105149] lr : dev_watchdog+0x2cc/0x2d8
[ 46.109144] sp :
ffff00000800bd80
[ 46.112447] x29:
ffff00000800bd80 x28:
ffff80007a9b4940
[ 46.117744] x27:
00000000ffffffff x26:
ffff80007aa183b0
[ 46.123040] x25:
0000000000000001 x24:
0000000000000140
[ 46.128336] x23:
ffff80007aa1839c x22:
ffff80007aa17fb0
[ 46.133632] x21:
ffff80007aa18000 x20:
ffff0000091a7000
[ 46.138927] x19:
0000000000000000 x18:
ffffffffffffffff
[ 46.144223] x17:
0000000000000000 x16:
0000000000000000
[ 46.149519] x15:
ffff0000091a96c8 x14:
07740775076f0720
[ 46.154814] x13:
07640765076d0769 x12:
0774072007300720
[ 46.160110] x11:
0765077507650775 x10:
0771072007740769
[ 46.165406] x9 :
076d0773076e0761 x8 :
077207740720073a
[ 46.170702] x7 :
072907630761076d x6 :
ffff80007ff9a0c0
[ 46.175997] x5 :
ffff80007ff9a0c0 x4 :
0000000000000002
[ 46.181293] x3 :
0000000000000000 x2 :
ffff0000091ac180
[ 46.186589] x1 :
e6a742ebe628e800 x0 :
0000000000000000
[ 46.191885] Call trace:
[ 46.194326] dev_watchdog+0x2cc/0x2d8
[ 46.197980] call_timer_fn+0x20/0x78
[ 46.201544] expire_timers+0xa4/0xb0
[ 46.205108] run_timer_softirq+0xe4/0x198
[ 46.209107] __do_softirq+0x114/0x210
[ 46.212760] irq_exit+0xd0/0xd8
[ 46.215895] __handle_domain_irq+0x60/0xb0
[ 46.219977] gic_handle_irq+0x58/0xa8
[ 46.223628] el1_irq+0xb0/0x128
[ 46.226761] arch_cpu_idle+0x10/0x18
[ 46.230326] do_idle+0x1d4/0x288
[ 46.233544] cpu_startup_entry+0x24/0x28
[ 46.237457] secondary_start_kernel+0x17c/0x1c0
[ 46.241971] ---[ end trace
57048cd1372cd828 ]---
Inspection of queue showed Jumbo packets were not sent out.
The ring Jumbo packet function needs to set the OWN bit so
the packet is sent.
Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sheng Yong [Fri, 12 Oct 2018 10:49:26 +0000 (18:49 +0800)]
f2fs: cleanup dirty pages if recover failed
[ Upstream commit
26b5a079197c8cb6725565968b7fd3299bd1877b ]
During recover, we will try to create new dentries for inodes with
dentry_mark. But if the parent is missing (e.g. killed by fsck),
recover will break. But those recovered dirty pages are not cleanup.
This will hit f2fs_bug_on:
[ 53.519566] F2FS-fs (loop0): Found nat_bits in checkpoint
[ 53.539354] F2FS-fs (loop0): recover_inode: ino = 5, name = file, inline = 3
[ 53.539402] F2FS-fs (loop0): recover_dentry: ino = 5, name = file, dir = 0, err = -2
[ 53.545760] F2FS-fs (loop0): Cannot recover all fsync data errno=-2
[ 53.546105] F2FS-fs (loop0): access invalid blkaddr:
4294967295
[ 53.546171] WARNING: CPU: 1 PID: 1798 at fs/f2fs/checkpoint.c:163 f2fs_is_valid_blkaddr+0x26c/0x320
[ 53.546174] Modules linked in:
[ 53.546183] CPU: 1 PID: 1798 Comm: mount Not tainted 4.19.0-rc2+ #1
[ 53.546186] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 53.546191] RIP: 0010:f2fs_is_valid_blkaddr+0x26c/0x320
[ 53.546195] Code: 85 bb 00 00 00 48 89 df 88 44 24 07 e8 ad a8 db ff 48 8b 3b 44 89 e1 48 c7 c2 40 03 72 a9 48 c7 c6 e0 01 72 a9 e8 84 3c ff ff <0f> 0b 0f b6 44 24 07 e9 8a 00 00 00 48 8d bf 38 01 00 00 e8 7c a8
[ 53.546201] RSP: 0018:
ffff88006c067768 EFLAGS:
00010282
[ 53.546208] RAX:
0000000000000000 RBX:
ffff880068844200 RCX:
ffffffffa83e1a33
[ 53.546211] RDX:
0000000000000000 RSI:
0000000000000008 RDI:
ffff88006d51e590
[ 53.546215] RBP:
0000000000000005 R08:
ffffed000daa3cb3 R09:
ffffed000daa3cb3
[ 53.546218] R10:
0000000000000001 R11:
ffffed000daa3cb2 R12:
00000000ffffffff
[ 53.546221] R13:
ffff88006a1f8000 R14:
0000000000000200 R15:
0000000000000009
[ 53.546226] FS:
00007fb2f3646840(0000) GS:
ffff88006d500000(0000) knlGS:
0000000000000000
[ 53.546229] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 53.546234] CR2:
00007f0fd77f0008 CR3:
00000000687e6002 CR4:
00000000000206e0
[ 53.546237] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 53.546240] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 53.546242] Call Trace:
[ 53.546248] f2fs_submit_page_bio+0x95/0x740
[ 53.546253] read_node_page+0x161/0x1e0
[ 53.546271] ? truncate_node+0x650/0x650
[ 53.546283] ? add_to_page_cache_lru+0x12c/0x170
[ 53.546288] ? pagecache_get_page+0x262/0x2d0
[ 53.546292] __get_node_page+0x200/0x660
[ 53.546302] f2fs_update_inode_page+0x4a/0x160
[ 53.546306] f2fs_write_inode+0x86/0xb0
[ 53.546317] __writeback_single_inode+0x49c/0x620
[ 53.546322] writeback_single_inode+0xe4/0x1e0
[ 53.546326] sync_inode_metadata+0x93/0xd0
[ 53.546330] ? sync_inode+0x10/0x10
[ 53.546342] ? do_raw_spin_unlock+0xed/0x100
[ 53.546347] f2fs_sync_inode_meta+0xe0/0x130
[ 53.546351] f2fs_fill_super+0x287d/0x2d10
[ 53.546367] ? vsnprintf+0x742/0x7a0
[ 53.546372] ? f2fs_commit_super+0x180/0x180
[ 53.546379] ? up_write+0x20/0x40
[ 53.546385] ? set_blocksize+0x5f/0x140
[ 53.546391] ? f2fs_commit_super+0x180/0x180
[ 53.546402] mount_bdev+0x181/0x200
[ 53.546406] mount_fs+0x94/0x180
[ 53.546411] vfs_kern_mount+0x6c/0x1e0
[ 53.546415] do_mount+0xe5e/0x1510
[ 53.546420] ? fs_reclaim_release+0x9/0x30
[ 53.546424] ? copy_mount_string+0x20/0x20
[ 53.546428] ? fs_reclaim_acquire+0xd/0x30
[ 53.546435] ? __might_sleep+0x2c/0xc0
[ 53.546440] ? ___might_sleep+0x53/0x170
[ 53.546453] ? __might_fault+0x4c/0x60
[ 53.546468] ? _copy_from_user+0x95/0xa0
[ 53.546474] ? memdup_user+0x39/0x60
[ 53.546478] ksys_mount+0x88/0xb0
[ 53.546482] __x64_sys_mount+0x5d/0x70
[ 53.546495] do_syscall_64+0x65/0x130
[ 53.546503] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 53.547639] ---[ end trace
b804d1ea2fec893e ]---
So if recover fails, we need to drop all recovered data.
Signed-off-by: Sheng Yong <shengyong1@huawei.com>
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Taehee Yoo [Mon, 1 Oct 2018 17:17:14 +0000 (02:17 +0900)]
netfilter: nf_flow_table: remove flowtable hook flush routine in netns exit routine
[ Upstream commit
b7f1a16d29b2e28d3dcbb070511bd703e306281b ]
When device is unregistered, flowtable flush routine is called
by notifier_call(nf_tables_flowtable_event). and exit callback of
nftables pernet_operation(nf_tables_exit_net) also has flowtable flush
routine. but when network namespace is destroyed, both notifier_call
and pernet_operation are called. hence flowtable flush routine in
pernet_operation is unnecessary.
test commands:
%ip netns add vm1
%ip netns exec vm1 nft add table ip filter
%ip netns exec vm1 nft add flowtable ip filter w \
{ hook ingress priority 0\; devices = { lo }\; }
%ip netns del vm1
splat looks like:
[ 265.187019] WARNING: CPU: 0 PID: 87 at net/netfilter/core.c:309 nf_hook_entry_head+0xc7/0xf0
[ 265.187112] Modules linked in: nf_flow_table_ipv4 nf_flow_table nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink ip_tables x_tables
[ 265.187390] CPU: 0 PID: 87 Comm: kworker/u4:2 Not tainted 4.19.0-rc3+ #5
[ 265.187453] Workqueue: netns cleanup_net
[ 265.187514] RIP: 0010:nf_hook_entry_head+0xc7/0xf0
[ 265.187546] Code: 8d 81 68 03 00 00 5b c3 89 d0 83 fa 04 48 8d 84 c7 e8 11 00 00 76 81 0f 0b 31 c0 e9 78 ff ff ff 0f 0b 48 83 c4 08 31 c0 5b c3 <0f> 0b 31 c0 e9 65 ff ff ff 0f 0b 31 c0 e9 5c ff ff ff 48 89 0c 24
[ 265.187573] RSP: 0018:
ffff88011546f098 EFLAGS:
00010246
[ 265.187624] RAX:
ffffffff8d90e135 RBX:
1ffff10022a8de1c RCX:
0000000000000000
[ 265.187645] RDX:
0000000000000000 RSI:
0000000000000005 RDI:
ffff880116298040
[ 265.187645] RBP:
ffff88010ea4c1a8 R08:
0000000000000000 R09:
0000000000000000
[ 265.187645] R10:
ffff88011546f1d8 R11:
ffffed0022c532c1 R12:
ffff88010ea4c1d0
[ 265.187645] R13:
0000000000000005 R14:
dffffc0000000000 R15:
ffff88010ea4c1c4
[ 265.187645] FS:
0000000000000000(0000) GS:
ffff88011b200000(0000) knlGS:
0000000000000000
[ 265.187645] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 265.187645] CR2:
00007fdfb8d00000 CR3:
0000000057a16000 CR4:
00000000001006f0
[ 265.187645] Call Trace:
[ 265.187645] __nf_unregister_net_hook+0xca/0x5d0
[ 265.187645] ? nf_hook_entries_free.part.3+0x80/0x80
[ 265.187645] ? save_trace+0x300/0x300
[ 265.187645] nf_unregister_net_hooks+0x2e/0x40
[ 265.187645] nf_tables_exit_net+0x479/0x1340 [nf_tables]
[ 265.187645] ? find_held_lock+0x39/0x1c0
[ 265.187645] ? nf_tables_abort+0x30/0x30 [nf_tables]
[ 265.187645] ? inet_frag_destroy_rcu+0xd0/0xd0
[ 265.187645] ? trace_hardirqs_on+0x93/0x210
[ 265.187645] ? __bpf_trace_preemptirq_template+0x10/0x10
[ 265.187645] ? inet_frag_destroy_rcu+0xd0/0xd0
[ 265.187645] ? inet_frag_destroy_rcu+0xd0/0xd0
[ 265.187645] ? __mutex_unlock_slowpath+0x17f/0x740
[ 265.187645] ? wait_for_completion+0x710/0x710
[ 265.187645] ? bucket_table_free+0xb2/0x1f0
[ 265.187645] ? nested_table_free+0x130/0x130
[ 265.187645] ? __lock_is_held+0xb4/0x140
[ 265.187645] ops_exit_list.isra.10+0x94/0x140
[ 265.187645] cleanup_net+0x45b/0x900
[ ... ]
This WARNING means that hook unregisteration is failed because
all flowtables hooks are already unregistered by notifier_call.
Network namespace exit routine guarantees that all devices will be
unregistered first. then, other exit callbacks of pernet_operations
are called. so that removing flowtable flush routine in exit callback of
pernet_operation(nf_tables_exit_net) doesn't make flowtable leak.
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ndesaulniers@google.com [Mon, 15 Oct 2018 17:22:21 +0000 (10:22 -0700)]
compiler.h: update definition of unreachable()
[ Upstream commit
fe0640eb30b7da261ae84d252ed9ed3c7e68dfd8 ]
Fixes the objtool warning seen with Clang:
arch/x86/mm/fault.o: warning: objtool: no_context()+0x220: unreachable
instruction
Fixes commit
815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h
mutually exclusive")
Josh noted that the fallback definition was meant to work around a
pre-gcc-4.6 bug. GCC still needs to work around
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82365, so compiler-gcc.h
defines its own version of unreachable(). Clang and ICC can use this
shared definition.
Link: https://github.com/ClangBuiltLinux/linux/issues/204
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Suggested-by: Josh Poimboeuf <jpoimboe@redhat.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Christopherson [Wed, 22 Aug 2018 21:57:07 +0000 (14:57 -0700)]
KVM: nVMX: restore host state in nested_vmx_vmexit for VMFail
[ Upstream commit
bd18bffca35397214ae68d85cf7203aca25c3c1d ]
A VMEnter that VMFails (as opposed to VMExits) does not touch host
state beyond registers that are explicitly noted in the VMFail path,
e.g. EFLAGS. Host state does not need to be loaded because VMFail
is only signaled for consistency checks that occur before the CPU
starts to load guest state, i.e. there is no need to restore any
state as nothing has been modified. But in the case where a VMFail
is detected by hardware and not by KVM (due to deferring consistency
checks to hardware), KVM has already loaded some amount of guest
state. Luckily, "loaded" only means loaded to KVM's software model,
i.e. vmcs01 has not been modified. So, unwind our software model to
the pre-VMEntry host state.
Not restoring host state in this VMFail path leads to a variety of
failures because we end up with stale data in vcpu->arch, e.g. CR0,
CR4, EFER, etc... will all be out of sync relative to vmcs01. Any
significant delta in the stale data is all but guaranteed to crash
L1, e.g. emulation of SMEP, SMAP, UMIP, WP, etc... will be wrong.
An alternative to this "soft" reload would be to load host state from
vmcs12 as if we triggered a VMExit (as opposed to VMFail), but that is
wildly inconsistent with respect to the VMX architecture, e.g. an L1
VMM with separate VMExit and VMFail paths would explode.
Note that this approach does not mean KVM is 100% accurate with
respect to VMX hardware behavior, even at an architectural level
(the exact order of consistency checks is microarchitecture specific).
But 100% emulation accuracy isn't the goal (with this patch), rather
the goal is to be consistent in the information delivered to L1, e.g.
a VMExit should not fall-through VMENTER, and a VMFail should not jump
to HOST_RIP.
This technically reverts commit "
5af4157388ad (KVM: nVMX: Fix mmu
context after VMLAUNCH/VMRESUME failure)", but retains the core
aspects of that patch, just in an open coded form due to the need to
pull state from vmcs01 instead of vmcs12. Restoring host state
resolves a variety of issues introduced by commit "
4f350c6dbcb9
(kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure properly)",
which remedied the incorrect behavior of treating VMFail like VMExit
but in doing so neglected to restore arch state that had been modified
prior to attempting nested VMEnter.
A sample failure that occurs due to stale vcpu.arch state is a fault
of some form while emulating an LGDT (due to emulated UMIP) from L1
after a failed VMEntry to L3, in this case when running the KVM unit
test test_tpr_threshold_values in L1. L0 also hits a WARN in this
case due to a stale arch.cr4.UMIP.
L1:
BUG: unable to handle kernel paging request at
ffffc90000663b9e
PGD
276512067 P4D
276512067 PUD
276513067 PMD
274efa067 PTE
8000000271de2163
Oops: 0009 [#1] SMP
CPU: 5 PID: 12495 Comm: qemu-system-x86 Tainted: G W 4.18.0-rc2+ #2
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
RIP: 0010:native_load_gdt+0x0/0x10
...
Call Trace:
load_fixmap_gdt+0x22/0x30
__vmx_load_host_state+0x10e/0x1c0 [kvm_intel]
vmx_switch_vmcs+0x2d/0x50 [kvm_intel]
nested_vmx_vmexit+0x222/0x9c0 [kvm_intel]
vmx_handle_exit+0x246/0x15a0 [kvm_intel]
kvm_arch_vcpu_ioctl_run+0x850/0x1830 [kvm]
kvm_vcpu_ioctl+0x3a1/0x5c0 [kvm]
do_vfs_ioctl+0x9f/0x600
ksys_ioctl+0x66/0x70
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x4f/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
L0:
WARNING: CPU: 2 PID: 3529 at arch/x86/kvm/vmx.c:6618 handle_desc+0x28/0x30 [kvm_intel]
...
CPU: 2 PID: 3529 Comm: qemu-system-x86 Not tainted 4.17.2-coffee+ #76
Hardware name: Intel Corporation Kabylake Client platform/KBL S
RIP: 0010:handle_desc+0x28/0x30 [kvm_intel]
...
Call Trace:
kvm_arch_vcpu_ioctl_run+0x863/0x1840 [kvm]
kvm_vcpu_ioctl+0x3a1/0x5c0 [kvm]
do_vfs_ioctl+0x9f/0x5e0
ksys_ioctl+0x66/0x70
__x64_sys_ioctl+0x16/0x20
do_syscall_64+0x49/0xf0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
5af4157388ad (KVM: nVMX: Fix mmu context after VMLAUNCH/VMRESUME failure)
Fixes:
4f350c6dbcb9 (kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure properly)
Cc: Jim Mattson <jmattson@google.com>
Cc: Krish Sadhukhan <krish.sadhukhan@oracle.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim KrÄmář <rkrcmar@redhat.com>
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kai-Heng Feng [Thu, 11 Oct 2018 07:56:33 +0000 (15:56 +0800)]
HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2
[ Upstream commit
ce9d58d3eafcb2d452a69bdcc1c5f8b8ff640de5 ]
Redragon Seymur 2 stops working since commit
190d7f02ce8e ("HID: input:
do not increment usages when a duplicate is found").
Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
can solve the issue.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
BugLink: https://bugs.launchpad.net/bugs/1793846
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ronald Tschalär [Mon, 1 Oct 2018 02:52:51 +0000 (19:52 -0700)]
ACPI / SBS: Fix GPE storm on recent MacBookPro's
[ Upstream commit
ca1721c5bee77105829cbd7baab8ee0eab85b06d ]
On Apple machines, plugging-in or unplugging the power triggers a GPE
for the EC. Since these machines expose an SBS device, this GPE ends
up triggering the acpi_sbs_callback(). This in turn tries to get the
status of the SBS charger. However, on MBP13,* and MBP14,* machines,
performing the smbus-read operation to get the charger's status triggers
the EC's GPE again. The result is an endless re-triggering and handling
of that GPE, consuming significant CPU resources (> 50% in irq).
In the end this is quite similar to commit
3031cddea633 (ACPI / SBS:
Don't assume the existence of an SBS charger), except that on the above
machines a status of all 1's is returned. And like there, we just want
ignore the charger here.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=198169
Signed-off-by: Ronald Tschalär <ronald@innovation.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maciej Żenczykowski [Thu, 20 Sep 2018 20:29:42 +0000 (13:29 -0700)]
usbip: fix vhci_hcd controller counting
[ Upstream commit
e0a2e73e501c77037c8756137e87b12c7c3c9793 ]
Without this usbip fails on a machine with devices
that lexicographically come after vhci_hcd.
ie.
$ ls -l /sys/devices/platform
...
drwxr-xr-x. 4 root root 0 Sep 19 16:21 serial8250
-rw-r--r--. 1 root root 4096 Sep 19 23:50 uevent
drwxr-xr-x. 6 root root 0 Sep 20 13:15 vhci_hcd.0
drwxr-xr-x. 4 root root 0 Sep 19 16:22 w83627hf.656
Because it detects 'w83627hf.656' as another vhci_hcd controller,
and then fails to be able to talk to it.
Note: this doesn't actually fix usbip's support for multiple
controllers... that's still broken for other reasons
("vhci_hcd.0" is hardcoded in a string macro), but is enough to
actually make it work on the above machine.
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1631148
Cc: Jonathan Dieter <jdieter@gmail.com>
Cc: Valentina Manea <valentina.manea.m@gmail.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Maciej Żenczykowski <zenczykowski@gmail.com>
Acked-by: Shuah Khan (Samsung OSG) <shuah@kernel.org>
Tested-by: Jonathan Dieter <jdieter@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bartlomiej Zolnierkiewicz [Fri, 28 Sep 2018 13:32:46 +0000 (15:32 +0200)]
ARM: samsung: Limit SAMSUNG_PM_CHECK config option to non-Exynos platforms
[ Upstream commit
6862fdf2201ab67cd962dbf0643d37db909f4860 ]
"S3C2410 PM Suspend Memory CRC" feature (controlled by
SAMSUNG_PM_CHECK config option) is incompatible with highmem
(uses phys_to_virt() instead of proper mapping) which is used by
the majority of Exynos boards. The issue manifests itself in OOPS
on affected boards, i.e. on Odroid-U3 I got the following one:
Unable to handle kernel paging request at virtual address
f0000000
pgd =
1c0f9bb4
[
f0000000] *pgd=
00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[<
c0458034>] (crc32_le) from [<
c0121f8c>] (s3c_pm_makecheck+0x34/0x54)
[<
c0121f8c>] (s3c_pm_makecheck) from [<
c0121efc>] (s3c_pm_run_res+0x74/0x8c)
[<
c0121efc>] (s3c_pm_run_res) from [<
c0121ecc>] (s3c_pm_run_res+0x44/0x8c)
[<
c0121ecc>] (s3c_pm_run_res) from [<
c01210b8>] (exynos_suspend_enter+0x64/0x148)
[<
c01210b8>] (exynos_suspend_enter) from [<
c018893c>] (suspend_devices_and_enter+0x9ec/0xe74)
[<
c018893c>] (suspend_devices_and_enter) from [<
c0189534>] (pm_suspend+0x770/0xc04)
[<
c0189534>] (pm_suspend) from [<
c0186ce8>] (state_store+0x6c/0xcc)
[<
c0186ce8>] (state_store) from [<
c09db434>] (kobj_attr_store+0x14/0x20)
[<
c09db434>] (kobj_attr_store) from [<
c02fa63c>] (sysfs_kf_write+0x4c/0x50)
[<
c02fa63c>] (sysfs_kf_write) from [<
c02f97a4>] (kernfs_fop_write+0xfc/0x1e4)
[<
c02f97a4>] (kernfs_fop_write) from [<
c027b198>] (__vfs_write+0x2c/0x140)
[<
c027b198>] (__vfs_write) from [<
c027b418>] (vfs_write+0xa4/0x160)
[<
c027b418>] (vfs_write) from [<
c027b5d8>] (ksys_write+0x40/0x8c)
[<
c027b5d8>] (ksys_write) from [<
c0101000>] (ret_fast_syscall+0x0/0x28)
Add PLAT_S3C24XX, ARCH_S3C64XX and ARCH_S5PV210 dependencies to
SAMSUNG_PM_CHECK config option to hide it on Exynos platforms.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yanjiang Jin [Sat, 29 Sep 2018 09:06:55 +0000 (17:06 +0800)]
pinctrl: core: make sure strcmp() doesn't get a null parameter
[ Upstream commit
54a58185bfafb5af5045fb8388c45daa373f90f3 ]
Some drivers, for example, QCOM's qdf2xxx, set groups[gpio].name only
when gpio is valid, and leave invalid gpio names as null.
If we want to access the sys node "pinconf-groups",
pinctrl_get_group_selector() -> get_group_name() may return a null
pointer if group_selector is invalid, then the below Kernel panic
would happen since strcmp() uses this null pointer to do comparison.
Unable to handle kernel NULL pointer dereference at ss
00000000
el:Internal error: Oops: 9600000[ 143.080279]
SMP
CPU: 19 PID: 2493 Comm: read_all Tainted: G O
.aarch64 #1
Hardware name: HXT Semiconductor HXT REP-2 System
PC is at strcmp+0x18/0x154
LR is at pinctrl_get_group_selector+0x6c/0xe8
Process read_all (pid: 2493, stack limit =
Call trace:
Exception stack
strcmp+0x18/0x154
pin_config_group_get+0x64/0xd8
pinconf_generic_dump_one+0xd8/0x1c0
pinconf_generic_dump_pins+0x94/0xc8
pinconf_groups_show+0xb4/0x104
seq_read+0x178/0x464
full_proxy_read+0x6c/0xac
__vfs_read+0x58/0x178
vfs_read+0x94/0x164
SyS_read+0x60/0xc0
__sys_trace_return+0x0/0x4
--[ end trace]--
Kernel panic - not syncing: Fatal exception
Signed-off-by: Yanjiang Jin <yanjiang.jin@hxt-semitech.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julian Sax [Wed, 19 Sep 2018 09:46:23 +0000 (11:46 +0200)]
HID: i2c-hid: override HID descriptors for certain devices
[ Upstream commit
9ee3e06610fdb8a601cde59c92089fb6c1deb4aa ]
A particular touchpad (SIPODEV SP1064) refuses to supply the HID
descriptors. This patch provides the framework for overriding these
descriptors based on DMI data. It also includes the descriptors for
said touchpad, which were extracted by listening to the traffic of the
windows filter driver, as well as the DMI data for the laptops known
to use this device.
Relevant Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1526312
Cc: Hans de Goede <hdegoede@redhat.com>
Reported-and-tested-by: ahormann@gmx.net
Reported-and-tested-by: Bruno Jesus <bruno.fl.jesus@gmail.com>
Reported-and-tested-by: Dietrich <enaut.w@googlemail.com>
Reported-and-tested-by: kloxdami@yahoo.com
Signed-off-by: Julian Sax <jsbc@gmx.de>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matias Karhumaa [Fri, 28 Sep 2018 18:54:30 +0000 (21:54 +0300)]
Bluetooth: Fix debugfs NULL pointer dereference
[ Upstream commit
30d65e0804d58a03d1a8ea4e12c6fc07ed08218b ]
Fix crash caused by NULL pointer dereference when debugfs functions
le_max_key_read, le_max_key_size_write, le_min_key_size_read or
le_min_key_size_write and Bluetooth adapter was powered off.
Fix is to move max_key_size and min_key_size from smp_dev to hci_dev.
At the same time they were renamed to le_max_key_size and
le_min_key_size.
BUG: unable to handle kernel NULL pointer dereference at
00000000000002e8
PGD 0 P4D 0
Oops: 0000 [#24] SMP PTI
CPU: 2 PID: 6255 Comm: cat Tainted: G D OE 4.18.9-200.fc28.x86_64 #1
Hardware name: LENOVO 4286CTO/4286CTO, BIOS 8DET76WW (1.46 ) 06/21/2018
RIP: 0010:le_max_key_size_read+0x45/0xb0 [bluetooth]
Code: 00 00 00 48 83 ec 10 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 48 8b 87 c8 00 00 00 48 8d 7c 24 04 48 8b 80 48 0a 00 00 <48> 8b 80 e8 02 00 00 0f b6 48 52 e8 fb b6 b3 ed be 04 00 00 00 48
RSP: 0018:
ffffab23c3ff3df0 EFLAGS:
00010246
RAX:
0000000000000000 RBX:
00007f0b4ca2e000 RCX:
ffffab23c3ff3f08
RDX:
ffffffffc0ddb033 RSI:
0000000000000004 RDI:
ffffab23c3ff3df4
RBP:
0000000000020000 R08:
0000000000000000 R09:
0000000000000000
R10:
ffffab23c3ff3ed8 R11:
0000000000000000 R12:
ffffab23c3ff3f08
R13:
00007f0b4ca2e000 R14:
0000000000020000 R15:
ffffab23c3ff3f08
FS:
00007f0b4ca0f540(0000) GS:
ffff91bd5e280000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00000000000002e8 CR3:
00000000629fa006 CR4:
00000000000606e0
Call Trace:
full_proxy_read+0x53/0x80
__vfs_read+0x36/0x180
vfs_read+0x8a/0x140
ksys_read+0x4f/0xb0
do_syscall_64+0x5b/0x160
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Signed-off-by: Matias Karhumaa <matias.karhumaa@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brad Love [Thu, 6 Sep 2018 21:07:48 +0000 (17:07 -0400)]
media: au0828: cannot kfree dev before usb disconnect
[ Upstream commit
4add7104919f9e94e0db03e234caeadbfcc02ea9 ]
If au0828_analog_register fails, the dev is kfree'd and then flow
jumps to done, which can call au0828_usb_disconnect. Since all USB
error codes are negative, au0828_usb_disconnect will be called. The
problem is au0828_usb_disconnect uses dev, if dev is NULL then there
is immediate oops encountered.
[ 7.454307] au0828: au0828_usb_probe() au0282_dev_register failed to register on V4L2
[ 7.454323] BUG: unable to handle kernel NULL pointer dereference at
0000000000000050
[ 7.454421] PGD 0 P4D 0
[ 7.454457] Oops: 0002 [#1] SMP PTI
[ 7.454500] CPU: 1 PID: 262 Comm: systemd-udevd Tainted: P O 4.18.3 #1
[ 7.454584] Hardware name: Google Panther/Panther, BIOS MattDevo 04/27/2015
[ 7.454670] RIP: 0010:_raw_spin_lock_irqsave+0x2c/0x50
[ 7.454725] Code: 44 00 00 55 48 89 e5 41 54 53 48 89 fb 9c 58 0f 1f 44 00 00 49 89 c4 fa 66 0f 1f 44 00 00 e8 db 23 1b ff 31 c0 ba 01 00 00 00 <f0> 0f b1 13 85 c0 75 08 4c 89 e0 5b 41 5c 5d c3 89 c6 48 89 df e8
[ 7.455004] RSP: 0018:
ffff9130f53ef988 EFLAGS:
00010046
[ 7.455063] RAX:
0000000000000000 RBX:
0000000000000050 RCX:
0000000000000000
[ 7.455139] RDX:
0000000000000001 RSI:
0000000000000003 RDI:
0000000000000050
[ 7.455216] RBP:
ffff9130f53ef998 R08:
0000000000000018 R09:
0000000000000090
[ 7.455292] R10:
ffffed4cc53cb000 R11:
ffffed4cc53cb108 R12:
0000000000000082
[ 7.455369] R13:
ffff9130cf2c6188 R14:
0000000000000000 R15:
0000000000000018
[ 7.455447] FS:
00007f2ff8514cc0(0000) GS:
ffff9130fcb00000(0000) knlGS:
0000000000000000
[ 7.455535] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 7.455597] CR2:
0000000000000050 CR3:
00000001753f0002 CR4:
00000000000606a0
[ 7.455675] Call Trace:
[ 7.455713] __wake_up_common_lock+0x65/0xc0
[ 7.455764] __wake_up+0x13/0x20
[ 7.455808] ir_lirc_unregister+0x57/0xe0 [rc_core]
[ 7.455865] rc_unregister_device+0xa0/0xc0 [rc_core]
[ 7.455935] au0828_rc_unregister+0x25/0x40 [au0828]
[ 7.455999] au0828_usb_disconnect+0x33/0x80 [au0828]
[ 7.456064] au0828_usb_probe.cold.16+0x8d/0x2aa [au0828]
[ 7.456130] usb_probe_interface+0xf1/0x300
[ 7.456184] driver_probe_device+0x2e3/0x460
[ 7.456235] __driver_attach+0xe4/0x110
[ 7.456282] ? driver_probe_device+0x460/0x460
[ 7.456335] bus_for_each_dev+0x74/0xb0
[ 7.456385] ? kmem_cache_alloc_trace+0x15d/0x1d0
[ 7.456441] driver_attach+0x1e/0x20
[ 7.456485] bus_add_driver+0x159/0x230
[ 7.456532] driver_register+0x70/0xc0
[ 7.456578] usb_register_driver+0x7f/0x140
[ 7.456626] ? 0xffffffffc0474000
[ 7.456674] au0828_init+0xbc/0x1000 [au0828]
[ 7.456725] do_one_initcall+0x4a/0x1c9
[ 7.456771] ? _cond_resched+0x19/0x30
[ 7.456817] ? kmem_cache_alloc_trace+0x15d/0x1d0
[ 7.456873] do_init_module+0x60/0x210
[ 7.456918] load_module+0x221b/0x2710
[ 7.456966] ? vfs_read+0xf5/0x120
[ 7.457010] __do_sys_finit_module+0xbd/0x120
[ 7.457061] ? __do_sys_finit_module+0xbd/0x120
[ 7.457115] __x64_sys_finit_module+0x1a/0x20
[ 7.457166] do_syscall_64+0x5b/0x110
[ 7.457210] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Brad Love <brad@nextdimension.cc>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Fontenot [Mon, 10 Sep 2018 14:57:00 +0000 (09:57 -0500)]
powerpc/pseries: Remove prrn_work workqueue
[ Upstream commit
cd24e457fd8b2d087d9236700c8d2957054598bf ]
When a PRRN event is received we are already running in a worker
thread. Instead of spawning off another worker thread on the prrn_work
workqueue to handle the PRRN event we can just call the PRRN handler
routine directly.
With this update we can also pass the scope variable for the PRRN
event directly to the handler instead of it being a global variable.
This patch fixes the following oops mnessage we are seeing in PRRN testing:
Oops: Bad kernel stack pointer, sig: 6 [#1]
SMP NR_CPUS=2048 NUMA pSeries
Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache binfmt_misc reiserfs vfat fat rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag af_packet xfs libcrc32c dm_service_time ibmveth(X) ses enclosure scsi_transport_sas rtc_generic btrfs xor raid6_pq sd_mod ibmvscsi(X) scsi_transport_srp ipr(X) libata sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
Supported: Yes, External 54
CPU: 7 PID: 18967 Comm: kworker/u96:0 Tainted: G X 4.4.126-94.22-default #1
Workqueue: pseries hotplug workque pseries_hp_work_fn
task:
c000000775367790 ti:
c00000001ebd4000 task.ti:
c00000070d140000
NIP:
0000000000000000 LR:
000000001fb3d050 CTR:
0000000000000000
REGS:
c00000001ebd7d40 TRAP: 0700 Tainted: G X (4.4.126-94.22-default)
MSR:
8000000102081000 <41,VEC,ME5 CR:
28000002 XER:
20040018 4
CFAR:
000000001fb3d084 40 419 1 3
GPR00:
000000000000000040000000000010007 000000001ffff400 000000041fffe200
GPR04:
000000000000008050000000000000000 000000001fb15fa8 0000000500000500
GPR08:
000000000001f40040000000000000001 0000000000000000 000005:
5200040002
GPR12:
00000000000000005c000000007a05400 c0000000000e89f8 000000001ed9f668
GPR16:
000000001fbeff944000000001fbeff94 000000001fb545e4 0000006000000060
GPR20:
ffffffffffffffff4ffffffffffffffff 0000000000000000 0000000000000000
GPR24:
00000000000000005400000001fb3c000 0000000000000000 000000001fb1b040
GPR28:
000000001fb240004000000001fb440d8 0000000000000008 0000000000000000
NIP [
0000000000000000] 5 (null)
LR [
000000001fb3d050]
031fb3d050
Call Trace: 4
Instruction dump: 4 5:47 12 2
XXXXXXXX XXXXXXXX XXXXX4XX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXX5XX XXXXXXXX
60000000 60000000 60000000 60000000
---[ end trace
aa5627b04a7d9d6b ]--- 3NMI watchdog: BUG: soft lockup - CPU#27 stuck for 23s! [kworker/27:0:13903]
Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache binfmt_misc reiserfs vfat fat rpadlpar_io(X) rpaphp(X) tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag af_packet xfs libcrc32c dm_service_time ibmveth(X) ses enclosure scsi_transport_sas rtc_generic btrfs xor raid6_pq sd_mod ibmvscsi(X) scsi_transport_srp ipr(X) libata sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4
Supported: Yes, External
CPU: 27 PID: 13903 Comm: kworker/27:0 Tainted: G D X 4.4.126-94.22-default #1
Workqueue: events prrn_work_fn
task:
c000000747cfa390 ti:
c00000074712c000 task.ti:
c00000074712c000
NIP:
c0000000008002a8 LR:
c000000000090770 CTR:
000000000032e088
REGS:
c00000074712f7b0 TRAP: 0901 Tainted: G D X (4.4.126-94.22-default)
MSR:
8000000100009033 <SF,EE,ME,IR,DR,RI,LE> CR:
22482044 XER:
20040000
CFAR:
c0000000008002c4 SOFTE: 1
GPR00:
c000000000090770 c00000074712fa30 c000000000f09800 c000000000fa1928 6:02
GPR04:
c000000775f5e000 fffffffffffffffe 0000000000000001 c000000000f42db8
GPR08:
0000000000000001 0000000080000007 0000000000000000 0000000000000000
GPR12:
8006210083180000 c000000007a14400
NIP [
c0000000008002a8] _raw_spin_lock+0x68/0xd0
LR [
c000000000090770] mobility_rtas_call+0x50/0x100
Call Trace: 59 5
[
c00000074712fa60] [
c000000000090770] mobility_rtas_call+0x50/0x100
[
c00000074712faf0] [
c000000000090b08] pseries_devicetree_update+0xf8/0x530
[
c00000074712fc20] [
c000000000031ba4] prrn_work_fn+0x34/0x50
[
c00000074712fc40] [
c0000000000e0390] process_one_work+0x1a0/0x4e0
[
c00000074712fcd0] [
c0000000000e0870] worker_thread+0x1a0/0x6105:57 2
[
c00000074712fd80] [
c0000000000e8b18] kthread+0x128/0x150
[
c00000074712fe30] [
c0000000000096f8] ret_from_kernel_thread+0x5c/0x64
Instruction dump:
2c090000 40c20010 7d40192d 40c2fff0 7c2004ac 2fa90000 40de0018 5:540030 3
e8010010 ebe1fff8 7c0803a6 4e800020 <
7c210b78>
e92d0000 89290009 792affe3
Signed-off-by: John Allen <jallen@linux.ibm.com>
Signed-off-by: Haren Myneni <haren@us.ibm.com>
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michal Simek [Mon, 3 Sep 2018 13:10:49 +0000 (15:10 +0200)]
serial: uartps: console_setup() can't be placed to init section
[ Upstream commit
4bb1ce2350a598502b23088b169e16b43d4bc639 ]
When console device is rebinded, console_setup() is called again.
But marking it as __init means that function will be clear after boot is
complete. If console device is binded again console_setup() is not found
and error "Unable to handle kernel paging request at virtual address"
is reported.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pablo Neira Ayuso [Tue, 4 Sep 2018 10:07:55 +0000 (12:07 +0200)]
netfilter: xt_cgroup: shrink size of v2 path
[ Upstream commit
0d704967f4a49cc2212350b3e4a8231f8b4283ed ]
cgroup v2 path field is PATH_MAX which is too large, this is placing too
much pressure on memory allocation for people with many rules doing
cgroup v1 classid matching, side effects of this are bug reports like:
https://bugzilla.kernel.org/show_bug.cgi?id=200639
This patch registers a new revision that shrinks the cgroup path to 512
bytes, which is the same approach we follow in similar extensions that
have a path field.
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chao Yu [Thu, 6 Sep 2018 12:34:12 +0000 (20:34 +0800)]
f2fs: fix to do sanity check with current segment number
[ Upstream commit
042be0f849e5fc24116d0afecfaf926eed5cac63 ]
https://bugzilla.kernel.org/show_bug.cgi?id=200219
Reproduction way:
- mount image
- run poc code
- umount image
F2FS-fs (loop1): Bitmap was wrongly set, blk:15364
------------[ cut here ]------------
kernel BUG at /home/yuchao/git/devf2fs/segment.c:2061!
invalid opcode: 0000 [#1] PREEMPT SMP
CPU: 2 PID: 17686 Comm: umount Tainted: G W O 4.18.0-rc2+ #39
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
EIP: update_sit_entry+0x459/0x4e0 [f2fs]
Code: e8 1c b5 fd ff 0f 0b 0f 0b 8b 45 e4 c7 44 24 08 9c 7a 6c f8 c7 44 24 04 bc 4a 6c f8 89 44 24 0c 8b 06 89 04 24 e8 f7 b4 fd ff <0f> 0b 8b 45 e4 0f b6 d2 89 54 24 10 c7 44 24 08 60 7a 6c f8 c7 44
EAX:
00000032 EBX:
000000f8 ECX:
00000002 EDX:
00000001
ESI:
d7177000 EDI:
f520fe68 EBP:
d6477c6c ESP:
d6477c34
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS:
00010282
CR0:
80050033 CR2:
b7fbe000 CR3:
2a99b3c0 CR4:
000406f0
Call Trace:
f2fs_allocate_data_block+0x124/0x580 [f2fs]
do_write_page+0x78/0x150 [f2fs]
f2fs_do_write_node_page+0x25/0xa0 [f2fs]
__write_node_page+0x2bf/0x550 [f2fs]
f2fs_sync_node_pages+0x60e/0x6d0 [f2fs]
? sync_inode_metadata+0x2f/0x40
? f2fs_write_checkpoint+0x28f/0x7d0 [f2fs]
? up_write+0x1e/0x80
f2fs_write_checkpoint+0x2a9/0x7d0 [f2fs]
? mark_held_locks+0x5d/0x80
? _raw_spin_unlock_irq+0x27/0x50
kill_f2fs_super+0x68/0x90 [f2fs]
deactivate_locked_super+0x3d/0x70
deactivate_super+0x40/0x60
cleanup_mnt+0x39/0x70
__cleanup_mnt+0x10/0x20
task_work_run+0x81/0xa0
exit_to_usermode_loop+0x59/0xa7
do_fast_syscall_32+0x1f5/0x22c
entry_SYSENTER_32+0x53/0x86
EIP: 0xb7f95c51
Code: c1 1e f7 ff ff 89 e5 8b 55 08 85 d2 8b 81 64 cd ff ff 74 02 89 02 5d c3 8b 0c 24 c3 8b 1c 24 c3 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76
EAX:
00000000 EBX:
0871ab90 ECX:
bfb2cd00 EDX:
00000000
ESI:
00000000 EDI:
0871ab90 EBP:
0871ab90 ESP:
bfb2cd7c
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS:
00000246
Modules linked in: f2fs(O) crc32_generic bnep rfcomm bluetooth ecdh_generic snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq pcbc joydev aesni_intel snd_seq_device aes_i586 snd_timer crypto_simd snd cryptd soundcore mac_hid serio_raw video i2c_piix4 parport_pc ppdev lp parport hid_generic psmouse usbhid hid e1000 [last unloaded: f2fs]
---[ end trace
d423f83982cfcdc5 ]---
The reason is, different log headers using the same segment, once
one log's next block address is used by another log, it will cause
panic as above.
Main area: 24 segs, 24 secs 24 zones
- COLD data: 0, 0, 0
- WARM data: 1, 1, 1
- HOT data: 20, 20, 20
- Dir dnode: 22, 22, 22
- File dnode: 22, 22, 22
- Indir nodes: 21, 21, 21
So this patch adds sanity check to detect such condition to avoid
this issue.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rohit kumar [Tue, 11 Sep 2018 09:29:21 +0000 (14:59 +0530)]
ASoC: Fix UBSAN warning at snd_soc_get/put_volsw_sx()
[ Upstream commit
ae7d1247d8673ebfd686b17e759d4be391165368 ]
In functions snd_soc_get_volsw_sx() or snd_soc_put_volsw_sx(),
if the result of (min + max) is negative, then fls() returns
signed integer with value as 32. This leads to signed integer
overflow as complete operation is considered as signed integer.
UBSAN: Undefined behaviour in sound/soc/soc-ops.c:382:50
signed integer overflow:
-
2147483648 - 1 cannot be represented in type 'int'
Call trace:
[<
ffffff852f746fe4>] __dump_stack lib/dump_stack.c:15 [inline]
[<
ffffff852f746fe4>] dump_stack+0xec/0x158 lib/dump_stack.c:51
[<
ffffff852f7b5f3c>] ubsan_epilogue+0x18/0x50 lib/ubsan.c:164
[<
ffffff852f7b6840>] handle_overflow+0xf8/0x130 lib/ubsan.c:195
[<
ffffff852f7b68f0>] __ubsan_handle_sub_overflow+0x34/0x44 lib/ubsan.c:211
[<
ffffff85307971a0>] snd_soc_get_volsw_sx+0x1a8/0x1f8 sound/soc/soc-ops.c:382
Typecast the operation to unsigned int to fix the issue.
Signed-off-by: Rohit kumar <rohitkr@codeaurora.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dinu-Razvan Chis-Serban [Wed, 5 Sep 2018 07:44:12 +0000 (16:44 +0900)]
9p locks: add mount option for lock retry interval
[ Upstream commit
5e172f75e51e3de1b4274146d9b990f803cb5c2a ]
The default P9_LOCK_TIMEOUT can be too long for some users exporting
a local file system to a guest VM (30s), make this configurable at
mount time.
Link: http://lkml.kernel.org/r/1536295827-3181-1-git-send-email-asmadeus@codewreck.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195727
Signed-off-by: Dinu-Razvan Chis-Serban <justcsdr@gmail.com>
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gertjan Halkes [Wed, 5 Sep 2018 06:41:29 +0000 (15:41 +0900)]
9p: do not trust pdu content for stat item size
[ Upstream commit
2803cf4379ed252894f046cb8812a48db35294e3 ]
v9fs_dir_readdir() could deadloop if a struct was sent with a size set
to -2
Link: http://lkml.kernel.org/r/1536134432-11997-1-git-send-email-asmadeus@codewreck.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88021
Signed-off-by: Gertjan Halkes <gertjan@google.com>
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chao Yu [Mon, 3 Sep 2018 19:52:17 +0000 (03:52 +0800)]
f2fs: fix to avoid NULL pointer dereference on se->discard_map
[ Upstream commit
7d20c8abb2edcf962ca857d51f4d0f9cd4b19053 ]
https://bugzilla.kernel.org/show_bug.cgi?id=200951
These is a NULL pointer dereference issue reported in bugzilla:
Hi,
in the setup there is a SATA SSD connected to a SATA-to-USB bridge.
The disc is "Samsung SSD 850 PRO 256G" which supports TRIM.
There are four partitions:
sda1: FAT /boot
sda2: F2FS /
sda3: F2FS /home
sda4: F2FS
The bridge is ASMT1153e which uses the "uas" driver.
There is no TRIM pass-through, so, when mounting it reports:
mounting with "discard" option, but the device does not support discard
The USB host is USB3.0 and UASP capable. It is the one on RK3399.
Given this everything works fine, except there is no TRIM support.
In order to enable TRIM a new UDEV rule is added [1]:
/etc/udev/rules.d/10-sata-bridge-trim.rules:
ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
After reboot any F2FS write hangs forever and dmesg reports:
Unable to handle kernel NULL pointer dereference
Also tested on a x86_64 system: works fine even with TRIM enabled.
same disc
same bridge
different usb host controller
different cpu architecture
not root filesystem
Regards,
Vicenç.
[1] Post #5 in https://bbs.archlinux.org/viewtopic.php?id=236280
Unable to handle kernel NULL pointer dereference at virtual address
000000000000003e
Mem abort info:
ESR = 0x96000004
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp =
00000000626e3122
[
000000000000003e] pgd=
0000000000000000
Internal error: Oops:
96000004 [#1] SMP
Modules linked in: overlay snd_soc_hdmi_codec rc_cec dw_hdmi_i2s_audio dw_hdmi_cec snd_soc_simple_card snd_soc_simple_card_utils snd_soc_rockchip_i2s rockchip_rga snd_soc_rockchip_pcm rockchipdrm videobuf2_dma_sg v4l2_mem2mem rtc_rk808 videobuf2_memops analogix_dp videobuf2_v4l2 videobuf2_common dw_hdmi dw_wdt cec rc_core videodev drm_kms_helper media drm rockchip_thermal rockchip_saradc realtek drm_panel_orientation_quirks syscopyarea sysfillrect sysimgblt fb_sys_fops dwmac_rk stmmac_platform stmmac pwm_bl squashfs loop crypto_user gpio_keys hid_kensington
CPU: 5 PID: 957 Comm: nvim Not tainted 4.19.0-rc1-1-ARCH #1
Hardware name: Sapphire-RK3399 Board (DT)
pstate:
00000005 (nzcv daif -PAN -UAO)
pc : update_sit_entry+0x304/0x4b0
lr : update_sit_entry+0x108/0x4b0
sp :
ffff00000ca13bd0
x29:
ffff00000ca13bd0 x28:
000000000000003e
x27:
0000000000000020 x26:
0000000000080000
x25:
0000000000000048 x24:
ffff8000ebb85cf8
x23:
0000000000000253 x22:
00000000ffffffff
x21:
00000000000535f2 x20:
00000000ffffffdf
x19:
ffff8000eb9e6800 x18:
ffff8000eb9e6be8
x17:
0000000007ce6926 x16:
000000001c83ffa8
x15:
0000000000000000 x14:
ffff8000f602df90
x13:
0000000000000006 x12:
0000000000000040
x11:
0000000000000228 x10:
0000000000000000
x9 :
0000000000000000 x8 :
0000000000000000
x7 :
00000000000535f2 x6 :
ffff8000ebff3440
x5 :
ffff8000ebff3440 x4 :
ffff8000ebe3a6c8
x3 :
00000000ffffffff x2 :
0000000000000020
x1 :
0000000000000000 x0 :
ffff8000eb9e5800
Process nvim (pid: 957, stack limit = 0x0000000063a78320)
Call trace:
update_sit_entry+0x304/0x4b0
f2fs_invalidate_blocks+0x98/0x140
truncate_node+0x90/0x400
f2fs_remove_inode_page+0xe8/0x340
f2fs_evict_inode+0x2b0/0x408
evict+0xe0/0x1e0
iput+0x160/0x260
do_unlinkat+0x214/0x298
__arm64_sys_unlinkat+0x3c/0x68
el0_svc_handler+0x94/0x118
el0_svc+0x8/0xc
Code:
f9400800 b9488400 36080140 f9400f01 (
387c4820)
---[ end trace
a0f21a307118c477 ]---
The reason is it is possible to enable discard flag on block queue via
UDEV, but during mount, f2fs will initialize se->discard_map only if
this flag is set, once the flag is set after mount, f2fs may dereference
NULL pointer on se->discard_map.
So this patch does below changes to fix this issue:
- initialize and update se->discard_map all the time.
- don't clear DISCARD option if device has no QUEUE_FLAG_DISCARD flag
during mount.
- don't issue small discard on zoned block device.
- introduce some functions to enhance the readability.
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Tested-by: Vicente Bergas <vicencb@gmail.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Siva Rebbagondla [Mon, 27 Aug 2018 11:35:15 +0000 (17:05 +0530)]
rsi: improve kernel thread handling to fix kernel panic
[ Upstream commit
4c62764d0fc21a34ffc44eec1210038c3a2e4473 ]
While running regressions, observed below kernel panic when sdio disconnect
called. This is because of, kthread_stop() is taking care of
wait_for_completion() by default. When wait_for_completion triggered
in kthread_stop and as it was done already, giving kernel panic.
Hence, removing redundant wait_for_completion() from rsi_kill_thread().
... skipping ...
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<
ffffffff810a63df>] exit_creds+0x1f/0x50
PGD 0
Oops: 0002 [#1] SMP
CPU: 0 PID: 6502 Comm: rmmod Tainted: G OE 4.15.9-Generic #154-Ubuntu
Hardware name: Dell Inc. Edge Gateway 3003/ , BIOS 01.00.00 04/17/2017
Stack:
ffff88007392e600 ffff880075847dc0 ffffffff8108160a 0000000000000000
ffff88007392e600 ffff880075847de8 ffffffff810a484b ffff880076127000
ffff88003cd3a800 ffff880074f12a00 ffff880075847e28 ffffffffc09bed15
Call Trace:
[<
ffffffff8108160a>] __put_task_struct+0x5a/0x140
[<
ffffffff810a484b>] kthread_stop+0x10b/0x110
[<
ffffffffc09bed15>] rsi_disconnect+0x2f5/0x300 [ven_rsi_sdio]
[<
ffffffff81578bcb>] ? __pm_runtime_resume+0x5b/0x80
[<
ffffffff816f0918>] sdio_bus_remove+0x38/0x100
[<
ffffffff8156cc64>] __device_release_driver+0xa4/0x150
[<
ffffffff8156d7a5>] driver_detach+0xb5/0xc0
[<
ffffffff8156c6c5>] bus_remove_driver+0x55/0xd0
[<
ffffffff8156dfbc>] driver_unregister+0x2c/0x50
[<
ffffffff816f0b8a>] sdio_unregister_driver+0x1a/0x20
[<
ffffffffc09bf0f5>] rsi_module_exit+0x15/0x30 [ven_rsi_sdio]
[<
ffffffff8110cad8>] SyS_delete_module+0x1b8/0x210
[<
ffffffff81851dc8>] entry_SYSCALL_64_fastpath+0x1c/0xbb
Signed-off-by: Siva Rebbagondla <siva.rebbagondla@redpinesignals.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Jarzmik [Sat, 25 Aug 2018 08:44:17 +0000 (10:44 +0200)]
gpio: pxa: handle corner case of unprobed device
[ Upstream commit
9ce3ebe973bf4073426f35f282c6b955ed802765 ]
In the corner case where the gpio driver probe fails, for whatever
reason, the suspend and resume handlers will still be called as they
have to be registered as syscore operations. This applies as well when
no probe was called while the driver has been built in the kernel.
Nicolas tracked this in :
https://bugzilla.kernel.org/show_bug.cgi?id=200905
Therefore, add a failsafe in these function, and test if a proper probe
succeeded and the driver is functional.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Reported-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thomas Zimmermann [Fri, 20 Jul 2018 11:27:43 +0000 (13:27 +0200)]
drm/cirrus: Use drm_framebuffer_put to avoid kernel oops in clean-up
[ Upstream commit
abf7b30d7f61d981bfcca65d1e8331b27021b475 ]
In the Cirrus driver, the regular clean-up code also performs the clean-up
of a failed initialization. If the fbdev's framebuffer was not initialized,
the clean-up will fail within drm_framebuffer_unregister_private. Booting
with cirrus.bpp=16 triggers this bug.
The framebuffer is currently stored directly within struct cirrus_fbdev. To
fix the bug, we turn it into a pointer that is only set for initialized
framebuffers. The fbdev's clean-up code skips uninitialized framebuffers.
The memory for struct drm_framebuffer is allocated dynamically. This requires
additional error handling within cirrusfb_create. The framebuffer clean-up is
now performed by drm_framebuffer_put, which also frees the data strcuture's
memory.
Link: https://bugzilla.suse.com/show_bug.cgi?id=1101822
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20180720112743.27159-1-tzimmermann@suse.de
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Darrick J. Wong [Sat, 23 Mar 2019 16:10:29 +0000 (12:10 -0400)]
ext4: prohibit fstrim in norecovery mode
[ Upstream commit
18915b5873f07e5030e6fb108a050fa7c71c59fb ]
The ext4 fstrim implementation uses the block bitmaps to find free space
that can be discarded. If we haven't replayed the journal, the bitmaps
will be stale and we absolutely *cannot* use stale metadata to zap the
underlying storage.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kairui Song [Fri, 8 Mar 2019 03:05:08 +0000 (11:05 +0800)]
x86/gart: Exclude GART aperture from kcore
[ Upstream commit
ffc8599aa9763f39f6736a79da4d1575e7006f9a ]
On machines where the GART aperture is mapped over physical RAM,
/proc/kcore contains the GART aperture range. Accessing the GART range via
/proc/kcore results in a kernel crash.
vmcore used to have the same issue, until it was fixed with commit
2a3e83c6f96c ("x86/gart: Exclude GART aperture from vmcore")', leveraging
existing hook infrastructure in vmcore to let /proc/vmcore return zeroes
when attempting to read the aperture region, and so it won't read from the
actual memory.
Apply the same workaround for kcore. First implement the same hook
infrastructure for kcore, then reuse the hook functions introduced in the
previous vmcore fix. Just with some minor adjustment, rename some functions
for more general usage, and simplify the hook infrastructure a bit as there
is no module usage yet.
Suggested-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Kairui Song <kasong@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Jiri Bohac <jbohac@suse.cz>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Omar Sandoval <osandov@fb.com>
Cc: Dave Young <dyoung@redhat.com>
Link: https://lkml.kernel.org/r/20190308030508.13548-1-kasong@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steve French [Sun, 17 Mar 2019 20:58:38 +0000 (15:58 -0500)]
fix incorrect error code mapping for OBJECTID_NOT_FOUND
[ Upstream commit
85f9987b236cf46e06ffdb5c225cf1f3c0acb789 ]
It was mapped to EIO which can be confusing when user space
queries for an object GUID for an object for which the server
file system doesn't support (or hasn't saved one).
As Amir Goldstein suggested this is similar to ENOATTR
(equivalently ENODATA in Linux errno definitions) so
changing NT STATUS code mapping for OBJECTID_NOT_FOUND
to ENODATA.
Signed-off-by: Steve French <stfrench@microsoft.com>
CC: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Thu, 7 Mar 2019 21:27:56 +0000 (14:27 -0700)]
x86/hw_breakpoints: Make default case in hw_breakpoint_arch_parse() return an error
[ Upstream commit
e898e69d6b9475bf123f99b3c5d1a67bb7cb2361 ]
When building with -Wsometimes-uninitialized, Clang warns:
arch/x86/kernel/hw_breakpoint.c:355:2: warning: variable 'align' is used
uninitialized whenever switch default is taken
[-Wsometimes-uninitialized]
The default cannot be reached because arch_build_bp_info() initializes
hw->len to one of the specified cases. Nevertheless the warning is valid
and returning -EINVAL makes sure that this cannot be broken by future
modifications.
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: clang-built-linux@googlegroups.com
Link: https://github.com/ClangBuiltLinux/linux/issues/392
Link: https://lkml.kernel.org/r/20190307212756.4648-1-natechancellor@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lu Baolu [Wed, 20 Mar 2019 01:58:33 +0000 (09:58 +0800)]
iommu/vt-d: Check capability before disabling protected memory
[ Upstream commit
5bb71fc790a88d063507dc5d445ab8b14e845591 ]
The spec states in 10.4.16 that the Protected Memory Enable
Register should be treated as read-only for implementations
not supporting protected memory regions (PLMR and PHMR fields
reported as Clear in the Capability register).
Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: mark gross <mgross@intel.com>
Suggested-by: Ashok Raj <ashok.raj@intel.com>
Fixes:
f8bab73515ca5 ("intel-iommu: PMEN support")
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YueHaibing [Thu, 28 Feb 2019 12:24:59 +0000 (20:24 +0800)]
drm/nouveau/debugfs: Fix check of pm_runtime_get_sync failure
[ Upstream commit
909e9c9c428376e2a43d178ed4b0a2d5ba9cb7d3 ]
pm_runtime_get_sync returns negative on failure.
Fixes:
eaeb9010bb4b ("drm/nouveau/debugfs: Wake up GPU before doing any reclocking")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthew Whitehead [Thu, 14 Mar 2019 20:46:00 +0000 (16:46 -0400)]
x86/cpu/cyrix: Use correct macros for Cyrix calls on Geode processors
[ Upstream commit
18fb053f9b827bd98cfc64f2a35df8ab19745a1d ]
There are comments in processor-cyrix.h advising you to _not_ make calls
using the deprecated macros in this style:
setCx86_old(CX86_CCR4, getCx86_old(CX86_CCR4) | 0x80);
This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:
outb(CX86_CCR2, 0x22);
inb(0x23);
From the comments:
* When using the old macros a line like
* setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
* gets expanded to:
* do {
* outb((CX86_CCR2), 0x22);
* outb((({
* outb((CX86_CCR2), 0x22);
* inb(0x23);
* }) | 0x88), 0x23);
* } while (0);
The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.
Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: luto@kernel.org
Link: https://lkml.kernel.org/r/1552596361-8967-2-git-send-email-tedheadster@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kangjie Lu [Thu, 14 Mar 2019 05:46:51 +0000 (00:46 -0500)]
x86/hyperv: Prevent potential NULL pointer dereference
[ Upstream commit
534c89c22e26b183d838294f0937ee092c82ad3a ]
The page allocation in hv_cpu_init() can fail, but the code does not
have a check for that.
Add a check and return -ENOMEM when the allocation fails.
[ tglx: Massaged changelog ]
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Acked-by: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: pakki001@umn.edu
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: linux-hyperv@vger.kernel.org
Link: https://lkml.kernel.org/r/20190314054651.1315-1-kjlu@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aditya Pakki [Tue, 19 Mar 2019 02:19:56 +0000 (21:19 -0500)]
x86/hpet: Prevent potential NULL pointer dereference
[ Upstream commit
2e84f116afca3719c9d0a1a78b47b48f75fd5724 ]
hpet_virt_address may be NULL when ioremap_nocache fail, but the code lacks
a check.
Add a check to prevent NULL pointer dereference.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: kjlu@umn.edu
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Joe Perches <joe@perches.com>
Cc: Nicolai Stange <nstange@suse.de>
Cc: Roland Dreier <roland@purestorage.com>
Link: https://lkml.kernel.org/r/20190319021958.17275-1-pakki001@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jianguo Chen [Wed, 20 Mar 2019 18:54:21 +0000 (18:54 +0000)]
irqchip/mbigen: Don't clear eventid when freeing an MSI
[ Upstream commit
fca269f201a8d9985c0a31fb60b15d4eb57cef80 ]
mbigen_write_msg clears eventid bits of a mbigen register
when free a interrupt, because msi_domain_deactivate memset
struct msg to zero. Then multiple mbigen pins with zero eventid
will report the same interrupt number.
The eventid clear call trace:
free_irq
__free_irq
irq_shutdown
irq_domain_deactivate_irq
__irq_domain_deactivate_irq
__irq_domain_deactivate_irq
msi_domain_deactivate
platform_msi_write_msg
mbigen_write_msg
Signed-off-by: Jianguo Chen <chenjianguo3@huawei.com>
[maz: massaged subject]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fabien Dessenne [Thu, 7 Mar 2019 18:40:35 +0000 (19:40 +0100)]
irqchip/stm32: Don't clear rising/falling config registers at init
[ Upstream commit
0dda09666f50eae9c5b794dd89b1fd8a8d89d714 ]
Falling and rising configuration and status registers are not banked.
As they are shared with M4 co-processor, they should not be cleared
at probe time, else M4 co-processor configuration will be lost.
Fixes:
f9fc1745501e ("irqchip/stm32: Add host and driver data structures")
Signed-off-by: Loic Pallardy <loic.pallardy@st.com>
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrzej Hajda [Tue, 19 Mar 2019 13:05:11 +0000 (14:05 +0100)]
drm/exynos/mixer: fix MIXER shadow registry synchronisation code
[ Upstream commit
6a3b45ada960ac475ec2b4103d43e57943b2b8d3 ]
MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
to update internal state (shadow registers).
Apparently the driver implements it incorrectly. The rule should be
as follows:
- do not request updating registers until previous request was finished,
ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
- before setting registers synchronisation on VSYNC should be turned off,
ie. MXR_STATUS_SYNC_ENABLE should be reset,
- after finishing MXR_STATUS_SYNC_ENABLE should be set again.
The patch hopefully implements it correctly.
Below sample kernel log from page fault caused by the bug:
[ 25.670038] exynos-sysmmu
14650000.sysmmu:
14450000.mixer: PAGE FAULT occurred at 0x2247b800
[ 25.677888] ------------[ cut here ]------------
[ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
[ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 25.693778] Modules linked in:
[ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 5.0.0-rc7-01157-g5f86b1566bdd #136
[ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
[ 25.716470] LR is at lock_is_held_type+0x44/0x64
v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync
Reported-by: Marian Mihailescu <mihailescu2m@gmail.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bart Van Assche [Wed, 20 Mar 2019 20:15:01 +0000 (13:15 -0700)]
blk-iolatency: #include "blk.h"
[ Upstream commit
373e915cd8e84544609eced57a44fbc084f8d60f ]
This patch avoids that the following warning is reported when building
with W=1:
block/blk-iolatency.c:734:5: warning: no previous prototype for 'blk_iolatency_init' [-Wmissing-prototypes]
Cc: Josef Bacik <jbacik@fb.com>
Fixes:
d70675121546 ("block: introduce blk-iolatency io controller") # v4.19
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiada Wang [Tue, 12 Mar 2019 06:51:28 +0000 (15:51 +0900)]
PM / Domains: Avoid a potential deadlock
[ Upstream commit
2071ac985d37efe496782c34318dbead93beb02f ]
Lockdep warns that prepare_lock and genpd->mlock can cause a deadlock
the deadlock scenario is like following:
First thread is probing cs2000
cs2000_probe()
clk_register()
__clk_core_init()
clk_prepare_lock() ----> acquires prepare_lock
cs2000_recalc_rate()
i2c_smbus_read_byte_data()
rcar_i2c_master_xfer()
dma_request_chan()
rcar_dmac_of_xlate()
rcar_dmac_alloc_chan_resources()
pm_runtime_get_sync()
__pm_runtime_resume()
rpm_resume()
rpm_callback()
genpd_runtime_resume() ----> acquires genpd->mlock
Second thread is attaching any device to the same PM domain
genpd_add_device()
genpd_lock() ----> acquires genpd->mlock
cpg_mssr_attach_dev()
of_clk_get_from_provider()
__of_clk_get_from_provider()
__clk_create_clk()
clk_prepare_lock() ----> acquires prepare_lock
Since currently no PM provider access genpd's critical section
in .attach_dev, and .detach_dev callbacks, so there is no need to protect
these two callbacks with genpd->mlock.
This patch avoids a potential deadlock by moving out .attach_dev and .detach_dev
from genpd->mlock, so that genpd->mlock won't be held when prepare_lock is acquired
in .attach_dev and .detach_dev
Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Mon, 18 Mar 2019 18:47:09 +0000 (21:47 +0300)]
ACPI / utils: Drop reference in test for device presence
[ Upstream commit
54e3aca84e571559915998aa6cc05e5ac37c043b ]
When commit
8661423eea1a ("ACPI / utils: Add new acpi_dev_present
helper") introduced acpi_dev_present(), it missed the fact that
bus_find_device() took a reference on the device found by it and
the callers of acpi_dev_present() don't drop that reference.
Drop the reference on the device in acpi_dev_present().
Fixes:
8661423eea1a ("ACPI / utils: Add new acpi_dev_present helper")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:56 +0000 (16:05 +0800)]
perf tests: Fix a memory leak in test__perf_evsel__tp_sched_test()
[ Upstream commit
d982b33133284fa7efa0e52ae06b88f9be3ea764 ]
=================================================================
==20875==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 1160 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc84138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x55bd50005599 in zalloc util/util.h:23
#2 0x55bd500068f5 in perf_evsel__newtp_idx util/evsel.c:327
#3 0x55bd4ff810fc in perf_evsel__newtp /home/work/linux/tools/perf/util/evsel.h:216
#4 0x55bd4ff81608 in test__perf_evsel__tp_sched_test tests/evsel-tp-sched.c:69
#5 0x55bd4ff528e6 in run_test tests/builtin-test.c:358
#6 0x55bd4ff52baf in test_and_print tests/builtin-test.c:388
#7 0x55bd4ff543fe in __cmd_test tests/builtin-test.c:583
#8 0x55bd4ff5572f in cmd_test tests/builtin-test.c:722
#9 0x55bd4ffc4087 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#10 0x55bd4ffc45c6 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#11 0x55bd4ffc49ca in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#12 0x55bd4ffc5138 in main /home/changbin/work/linux/tools/perf/perf.c:520
#13 0x7f1b6e34809a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 19 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc83f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x7f1b6e3ac30f in vasprintf (/lib/x86_64-linux-gnu/libc.so.6+0x8830f)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes:
6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields")
Link: http://lkml.kernel.org/r/20190316080556.3075-17-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:55 +0000 (16:05 +0800)]
perf tests: Fix memory leak by expr__find_other() in test__expr()
[ Upstream commit
f97a8991d3b998e518f56794d879f645964de649 ]
=================================================================
==7506==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 13 byte(s) in 3 object(s) allocated from:
#0 0x7f03339d6070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x5625e53aaef0 in expr__find_other util/expr.y:221
#2 0x5625e51bcd3f in test__expr tests/expr.c:52
#3 0x5625e51528e6 in run_test tests/builtin-test.c:358
#4 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#5 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#6 0x5625e515572f in cmd_test tests/builtin-test.c:722
#7 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#8 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#9 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#10 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#11 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes:
075167363f8b ("perf tools: Add a simple expression parser for JSON")
Link: http://lkml.kernel.org/r/20190316080556.3075-16-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:54 +0000 (16:05 +0800)]
perf tests: Fix a memory leak of cpu_map object in the openat_syscall_event_on_all_cpus test
[ Upstream commit
93faa52e8371f0291ee1ff4994edae2b336b6233 ]
=================================================================
==7497==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a88f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x5625e5326213 in cpu_map__trim_new util/cpumap.c:45
#2 0x5625e5326703 in cpu_map__read util/cpumap.c:103
#3 0x5625e53267ef in cpu_map__read_all_cpu_map util/cpumap.c:120
#4 0x5625e5326915 in cpu_map__new util/cpumap.c:135
#5 0x5625e517b355 in test__openat_syscall_event_on_all_cpus tests/openat-syscall-all-cpus.c:36
#6 0x5625e51528e6 in run_test tests/builtin-test.c:358
#7 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#8 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#9 0x5625e515572f in cmd_test tests/builtin-test.c:722
#10 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#11 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#12 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#13 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#14 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes:
f30a79b012e5 ("perf tools: Add reference counting for cpu_map object")
Link: http://lkml.kernel.org/r/20190316080556.3075-15-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnaldo Carvalho de Melo [Mon, 18 Mar 2019 19:41:28 +0000 (16:41 -0300)]
perf evsel: Free evsel->counts in perf_evsel__exit()
[ Upstream commit
42dfa451d825a2ad15793c476f73e7bbc0f9d312 ]
Using gcc's ASan, Changbin reports:
=================================================================
==7494==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x5625e5330a5e in zalloc util/util.h:23
#2 0x5625e5330a9b in perf_counts__new util/counts.c:10
#3 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
#4 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
#5 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
#6 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
#7 0x5625e51528e6 in run_test tests/builtin-test.c:358
#8 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#9 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#10 0x5625e515572f in cmd_test tests/builtin-test.c:722
#11 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#12 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#13 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#14 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#15 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x5625e532560d in zalloc util/util.h:23
#2 0x5625e532566b in xyarray__new util/xyarray.c:10
#3 0x5625e5330aba in perf_counts__new util/counts.c:15
#4 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
#5 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
#6 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
#7 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
#8 0x5625e51528e6 in run_test tests/builtin-test.c:358
#9 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#10 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#11 0x5625e515572f in cmd_test tests/builtin-test.c:722
#12 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#13 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#14 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#15 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#16 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
His patch took care of evsel->prev_raw_counts, but the above backtraces
are about evsel->counts, so fix that instead.
Reported-by: Changbin Du <changbin.du@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lkml.kernel.org/n/tip-hd1x13g59f0nuhe4anxhsmfp@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:49 +0000 (16:05 +0800)]
perf hist: Add missing map__put() in error case
[ Upstream commit
cb6186aeffda4d27e56066c79e9579e7831541d3 ]
We need to map__put() before returning from failure of
sample__resolve_callchain().
Detected with gcc's ASan.
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Krister Johansen <kjlx@templeofstupid.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes:
9c68ae98c6f7 ("perf callchain: Reference count maps")
Link: http://lkml.kernel.org/r/20190316080556.3075-10-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:48 +0000 (16:05 +0800)]
perf top: Fix error handling in cmd_top()
[ Upstream commit
70c819e4bf1c5f492768b399d898d458ccdad2b6 ]
We should go to the cleanup path, to avoid leaks, detected using gcc's
ASan.
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20190316080556.3075-9-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:46 +0000 (16:05 +0800)]
perf build-id: Fix memory leak in print_sdt_events()
[ Upstream commit
8bde8516893da5a5fdf06121f74d11b52ab92df5 ]
Detected with gcc's ASan:
Direct leak of 4356 byte(s) in 120 object(s) allocated from:
#0 0x7ff1a2b5a070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x55719aef4814 in build_id_cache__origname util/build-id.c:215
#2 0x55719af649b6 in print_sdt_events util/parse-events.c:2339
#3 0x55719af66272 in print_events util/parse-events.c:2542
#4 0x55719ad1ecaa in cmd_list /home/changbin/work/linux/tools/perf/builtin-list.c:58
#5 0x55719aec745d in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#6 0x55719aec7d1a in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#7 0x55719aec8184 in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#8 0x55719aeca41a in main /home/changbin/work/linux/tools/perf/perf.c:520
#9 0x7ff1a07ae09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes:
40218daea1db ("perf list: Show SDT and pre-cached events")
Link: http://lkml.kernel.org/r/20190316080556.3075-7-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:45 +0000 (16:05 +0800)]
perf config: Fix a memory leak in collect_config()
[ Upstream commit
54569ba4b06d5baedae4614bde33a25a191473ba ]
Detected with gcc's ASan:
Direct leak of 66 byte(s) in 5 object(s) allocated from:
#0 0x7ff3b1f32070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x560c8761034d in collect_config util/config.c:597
#2 0x560c8760d9cb in get_value util/config.c:169
#3 0x560c8760dfd7 in perf_parse_file util/config.c:285
#4 0x560c8760e0d2 in perf_config_from_file util/config.c:476
#5 0x560c876108fd in perf_config_set__init util/config.c:661
#6 0x560c87610c72 in perf_config_set__new util/config.c:709
#7 0x560c87610d2f in perf_config__init util/config.c:718
#8 0x560c87610e5d in perf_config util/config.c:730
#9 0x560c875ddea0 in main /home/changbin/work/linux/tools/perf/perf.c:442
#10 0x7ff3afb8609a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Taeung Song <treeze.taeung@gmail.com>
Fixes:
20105ca1240c ("perf config: Introduce perf_config_set class")
Link: http://lkml.kernel.org/r/20190316080556.3075-6-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:44 +0000 (16:05 +0800)]
perf config: Fix an error in the config template documentation
[ Upstream commit
9b40dff7ba3caaf0d1919f98e136fa3400bd34aa ]
The option 'sort-order' should be 'sort_order'.
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Milian Wolff <milian.wolff@kdab.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes:
893c5c798be9 ("perf config: Show default report configuration in example and docs")
Link: http://lkml.kernel.org/r/20190316080556.3075-5-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changbin Du [Sat, 16 Mar 2019 08:05:42 +0000 (16:05 +0800)]
perf list: Don't forget to drop the reference to the allocated thread_map
[ Upstream commit
39df730b09774bd860e39ea208a48d15078236cb ]
Detected via gcc's ASan:
Direct leak of 2048 byte(s) in 64 object(s) allocated from:
6 #0 0x7f606512e370 in __interceptor_realloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee370)
7 #1 0x556b0f1d7ddd in thread_map__realloc util/thread_map.c:43
8 #2 0x556b0f1d84c7 in thread_map__new_by_tid util/thread_map.c:85
9 #3 0x556b0f0e045e in is_event_supported util/parse-events.c:2250
10 #4 0x556b0f0e1aa1 in print_hwcache_events util/parse-events.c:2382
11 #5 0x556b0f0e3231 in print_events util/parse-events.c:2514
12 #6 0x556b0ee0a66e in cmd_list /home/changbin/work/linux/tools/perf/builtin-list.c:58
13 #7 0x556b0f01e0ae in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
14 #8 0x556b0f01e859 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
15 #9 0x556b0f01edc8 in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
16 #10 0x556b0f01f71f in main /home/changbin/work/linux/tools/perf/perf.c:520
17 #11 0x7f6062ccf09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Signed-off-by: Changbin Du <changbin.du@gmail.com>
Reviewed-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Fixes:
89896051f8da ("perf tools: Do not put a variable sized type not at the end of a struct")
Link: http://lkml.kernel.org/r/20190316080556.3075-3-changbin.du@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Arcari [Tue, 12 Feb 2019 14:34:39 +0000 (09:34 -0500)]
tools/power turbostat: return the exit status of a command
[ Upstream commit
2a95496634a017c19641f26f00907af75b962f01 ]
turbostat failed to return a non-zero exit status even though the
supplied command (turbostat <command>) failed. Currently when turbostat
forks a command it returns zero instead of the actual exit status of the
command. Modify the code to return the exit status.
Signed-off-by: David Arcari <darcari@redhat.com>
Acked-by: Len Brown <len.brown@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matteo Croce [Mon, 18 Mar 2019 21:24:03 +0000 (22:24 +0100)]
x86/mm: Don't leak kernel addresses
[ Upstream commit
a3151724437f54076cc10bc02b1c4f0003ae36cd ]
Since commit:
ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
at boot "____ptrval____" is printed instead of actual addresses:
found SMP MP-table at [mem 0x000f5cc0-0x000f5ccf] mapped at [(____ptrval____)]
Instead of changing the print to "%px", and leaking a kernel addresses,
just remove the print completely, like in:
071929dbdd865f77 ("arm64: Stop printing the virtual memory layout").
Signed-off-by: Matteo Croce <mcroce@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Konstantin Khlebnikov [Wed, 6 Mar 2019 17:11:42 +0000 (20:11 +0300)]
sched/core: Fix buffer overflow in cgroup2 property cpu.max
[ Upstream commit
4c47acd824aaaa8fc6dc519fb4e08d1522105b7a ]
Add limit into sscanf format string for on-stack buffer.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Li Zefan <lizefan@huawei.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes:
0d5936344f30 ("sched: Implement interface for cgroup unified hierarchy")
Link: https://lkml.kernel.org/r/155189230232.2620.13120481613524200065.stgit@buzz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Zijlstra [Tue, 5 Mar 2019 08:32:02 +0000 (09:32 +0100)]
sched/cpufreq: Fix 32-bit math overflow
[ Upstream commit
a23314e9d88d89d49e69db08f60b7caa470f04e1 ]
Vincent Wang reported that get_next_freq() has a mult overflow bug on
32-bit platforms in the IOWAIT boost case, since in that case {util,max}
are in freq units instead of capacity units.
Solve this by moving the IOWAIT boost to capacity units. And since this
means @max is constant; simplify the code.
Reported-by: Vincent Wang <vincent.wang@unisoc.com>
Tested-by: Vincent Wang <vincent.wang@unisoc.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Chunyan Zhang <zhang.lyra@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Quentin Perret <quentin.perret@arm.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Rik van Riel <riel@surriel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20190305083202.GU32494@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maurizio Lombardi [Mon, 28 Jan 2019 14:24:42 +0000 (15:24 +0100)]
scsi: iscsi: flush running unbind operations when removing a session
[ Upstream commit
165aa2bfb42904b1bec4bf2fa257c8c603c14a06 ]
In some cases, the iscsi_remove_session() function is called while an
unbind_work operation is still running. This may cause a situation where
sysfs objects are removed in an incorrect order, triggering a kernel
warning.
[ 605.249442] ------------[ cut here ]------------
[ 605.259180] sysfs group 'power' not found for kobject 'target2:0:0'
[ 605.321371] WARNING: CPU: 1 PID: 26794 at fs/sysfs/group.c:235 sysfs_remove_group+0x76/0x80
[ 605.341266] Modules linked in: dm_service_time target_core_user target_core_pscsi target_core_file target_core_iblock iscsi_target_mod target_core_mod nls_utf8 isofs ppdev bochs_drm nfit ttm libnvdimm drm_kms_helper syscopyarea sysfillrect sysimgblt joydev pcspkr fb_sys_fops drm i2c_piix4 sg parport_pc parport xfs libcrc32c dm_multipath sr_mod sd_mod cdrom ata_generic 8021q garp mrp ata_piix stp crct10dif_pclmul crc32_pclmul llc libata crc32c_intel virtio_net net_failover ghash_clmulni_intel serio_raw failover sunrpc dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
[ 605.627479] CPU: 1 PID: 26794 Comm: kworker/u32:2 Not tainted 4.18.0-60.el8.x86_64 #1
[ 605.721401] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20180724_192412-buildhw-07.phx2.fedoraproject.org-1.fc29 04/01/2014
[ 605.823651] Workqueue: scsi_wq_2 __iscsi_unbind_session [scsi_transport_iscsi]
[ 605.830940] RIP: 0010:sysfs_remove_group+0x76/0x80
[ 605.922907] Code: 48 89 df 5b 5d 41 5c e9 38 c4 ff ff 48 89 df e8 e0 bf ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 38 73 cb a7 e8 24 77 d7 ff <0f> 0b 5b 5d 41 5c c3 0f 1f 00 0f 1f 44 00 00 41 56 41 55 41 54 55
[ 606.122304] RSP: 0018:
ffffbadcc8d1bda8 EFLAGS:
00010286
[ 606.218492] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
0000000000000000
[ 606.326381] RDX:
ffff98bdfe85eb40 RSI:
ffff98bdfe856818 RDI:
ffff98bdfe856818
[ 606.514498] RBP:
ffffffffa7ab73e0 R08:
0000000000000268 R09:
0000000000000007
[ 606.529469] R10:
0000000000000000 R11:
ffffffffa860d9ad R12:
ffff98bdf978e838
[ 606.630535] R13:
ffff98bdc2cd4010 R14:
ffff98bdc2cd3ff0 R15:
ffff98bdc2cd4000
[ 606.824707] FS:
0000000000000000(0000) GS:
ffff98bdfe840000(0000) knlGS:
0000000000000000
[ 607.018333] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 607.117844] CR2:
00007f84b78ac024 CR3:
000000002c00a003 CR4:
00000000003606e0
[ 607.117844] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 607.420926] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 607.524236] Call Trace:
[ 607.530591] device_del+0x56/0x350
[ 607.624393] ? ata_tlink_match+0x30/0x30 [libata]
[ 607.727805] ? attribute_container_device_trigger+0xb4/0xf0
[ 607.829911] scsi_target_reap_ref_release+0x39/0x50
[ 607.928572] scsi_remove_target+0x1a2/0x1d0
[ 608.017350] __iscsi_unbind_session+0xb3/0x160 [scsi_transport_iscsi]
[ 608.117435] process_one_work+0x1a7/0x360
[ 608.132917] worker_thread+0x30/0x390
[ 608.222900] ? pwq_unbound_release_workfn+0xd0/0xd0
[ 608.323989] kthread+0x112/0x130
[ 608.418318] ? kthread_bind+0x30/0x30
[ 608.513821] ret_from_fork+0x35/0x40
[ 608.613909] ---[ end trace
0b98c310c8a6138c ]---
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Acked-by: Chris Leech <cleech@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Rui [Mon, 18 Mar 2019 14:26:33 +0000 (22:26 +0800)]
thermal/intel_powerclamp: fix truncated kthread name
[ Upstream commit
e925b5be5751f6a7286bbd9a4cbbc4ac90cc5fa6 ]
kthread name only allows 15 characters (TASK_COMMON_LEN is 16).
Thus rename the kthreads created by intel_powerclamp driver from
"kidle_inject/ + decimal cpuid" to "kidle_inj/ + decimal cpuid"
to avoid truncated kthead name for cpu 100 and later.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthew Garrett [Wed, 10 Oct 2018 08:30:07 +0000 (01:30 -0700)]
thermal/int340x_thermal: fix mode setting
[ Upstream commit
396ee4d0cd52c13b3f6421b8d324d65da5e7e409 ]
int3400 only pushes the UUID into the firmware when the mode is flipped
to "enable". The current code only exposes the mode flag if the firmware
supports the PASSIVE_1 UUID, which not all machines do. Remove the
restriction.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Matthew Garrett [Wed, 10 Oct 2018 08:30:06 +0000 (01:30 -0700)]
thermal/int340x_thermal: Add additional UUIDs
[ Upstream commit
16fc8eca1975358111dbd7ce65e4ce42d1a848fb ]
Add more supported DPTF policies than the driver currently exposes.
Signed-off-by: Matthew Garrett <mjg59@google.com>
Cc: Nisha Aram <nisha.aram@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Phil Elwell [Tue, 29 Jan 2019 09:55:57 +0000 (09:55 +0000)]
thermal: bcm2835: Fix crash in bcm2835_thermal_debugfs
[ Upstream commit
35122495a8c6683e863acf7b05a7036b2be64c7a ]
"cat /sys/kernel/debug/bcm2835_thermal/regset" causes a NULL pointer
dereference in bcm2835_thermal_debugfs. The driver makes use of the
implementation details of the thermal framework to retrieve a pointer
to its private data from a struct thermal_zone_device, and gets it
wrong - leading to the crash. Instead, store its private data as the
drvdata and retrieve the thermal_zone_device pointer from it.
Fixes:
bcb7dd9ef206 ("thermal: bcm2835: add thermal driver for bcm2835 SoC")
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Szyprowski [Tue, 22 Jan 2019 15:47:41 +0000 (16:47 +0100)]
thermal: samsung: Fix incorrect check after code merge
[ Upstream commit
3b5236cc5d086dd3ddd01113ee9255421aab9fab ]
Merge commit
19785cf93b6c ("Merge branch 'linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal")
broke the code introduced by commit
ffe6e16f14fa ("thermal: exynos: Reduce
severity of too early temperature read"). Restore the original code from
the mentioned commit to finally fix the warning message during boot:
thermal thermal_zone0: failed to read out thermal zone (-22)
Reported-by: Marian Mihailescu <mihailescu2m@gmail.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes:
19785cf93b6c ("Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal")
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luc Van Oostenryck [Sat, 19 Jan 2019 16:15:23 +0000 (17:15 +0100)]
thermal/intel_powerclamp: fix __percpu declaration of worker_data
[ Upstream commit
aa36e3616532f82a920b5ebf4e059fbafae63d88 ]
This variable is declared as:
static struct powerclamp_worker_data * __percpu worker_data;
In other words, a percpu pointer to struct ...
But this variable not used like so but as a pointer to a percpu
struct powerclamp_worker_data.
So fix the declaration as:
static struct powerclamp_worker_data __percpu *worker_data;
This also quiets Sparse's warnings from __verify_pcpu_ptr(), like:
494:49: warning: incorrect type in initializer (different address spaces)
494:49: expected void const [noderef] <asn:3> *__vpp_verify
494:49: got struct powerclamp_worker_data *
Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Sun, 17 Mar 2019 23:21:24 +0000 (23:21 +0000)]
ALSA: opl3: fix mismatch between snd_opl3_drum_switch definition and declaration
[ Upstream commit
b4748e7ab731e436cf5db4786358ada5dd2db6dd ]
The function snd_opl3_drum_switch declaration in the header file
has the order of the two arguments on_off and vel swapped when
compared to the definition arguments of vel and on_off. Fix this
by swapping them around to match the definition.
This error predates the git history, so no idea when this error
was introduced.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Thu, 7 Mar 2019 10:10:11 +0000 (11:10 +0100)]
mmc: davinci: remove extraneous __init annotation
[ Upstream commit
9ce58dd7d9da3ca0d7cb8c9568f1c6f4746da65a ]
Building with clang finds a mistaken __init tag:
WARNING: vmlinux.o(.text+0x5e4250): Section mismatch in reference from the function davinci_mmcsd_probe() to the function .init.text:init_mmcsd_host()
The function davinci_mmcsd_probe() references
the function __init init_mmcsd_host().
This is often because davinci_mmcsd_probe lacks a __init
annotation or the annotation of init_mmcsd_host is wrong.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Feng Tang [Thu, 14 Mar 2019 10:37:29 +0000 (18:37 +0800)]
i40iw: Avoid panic when handling the inetdev event
[ Upstream commit
ec4fe4bcc584b55e24e8d1768f5510a62c0fd619 ]
There is a panic reported that on a system with x722 ethernet, when doing
the operations like:
# ip link add br0 type bridge
# ip link set eno1 master br0
# systemctl restart systemd-networkd
The system will panic "BUG: unable to handle kernel null pointer
dereference at
0000000000000034", with call chain:
i40iw_inetaddr_event
notifier_call_chain
blocking_notifier_call_chain
notifier_call_chain
__inet_del_ifa
inet_rtm_deladdr
rtnetlink_rcv_msg
netlink_rcv_skb
rtnetlink_rcv
netlink_unicast
netlink_sendmsg
sock_sendmsg
__sys_sendto
It is caused by "local_ipaddr = ntohl(in->ifa_list->ifa_address)", while
the in->ifa_list is NULL.
So add a check for the "in->ifa_list == NULL" case, and skip the ARP
operation accordingly.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jack Morgenstein [Wed, 6 Mar 2019 17:17:56 +0000 (19:17 +0200)]
IB/mlx4: Fix race condition between catas error reset and aliasguid flows
[ Upstream commit
587443e7773e150ae29e643ee8f41a1eed226565 ]
Code review revealed a race condition which could allow the catas error
flow to interrupt the alias guid query post mechanism at random points.
Thiis is fixed by doing cancel_delayed_work_sync() instead of
cancel_delayed_work() during the alias guid mechanism destroy flow.
Fixes:
a0c64a17aba8 ("mlx4: Add alias_guid mechanism")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dave Airlie [Fri, 15 Mar 2019 01:37:20 +0000 (11:37 +1000)]
drm/udl: use drm_gem_object_put_unlocked.
[ Upstream commit
8f3b487685b2acf71b42bb30d68fd9271bec8695 ]
When Daniel removed struct_mutex he didn't fix this call to the unlocked
variant which is required since we no longer use struct mutex.
This fixes a bunch of:
WARNING: CPU: 4 PID: 1370 at drivers/gpu/drm/drm_gem.c:931 drm_gem_object_put+0x2b/0x30 [drm]
Modules linked in: udl xt_CHECKSUM ipt_MASQUERADE tun bridge stp llc nf_conntrack_netbios_ns nf_conntrack_broadcast xt_CT ip6t>
CPU: 4 PID: 1370 Comm: Xorg Not tainted 5.0.0+ #2
backtraces when you plug in a udl device.
Fixes:
ae358dacd217 (drm/udl: Get rid of dev->struct_mutex usage)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Tue, 12 Mar 2019 14:44:28 +0000 (16:44 +0200)]
auxdisplay: hd44780: Fix memory leak on ->remove()
[ Upstream commit
41c8d0adf3c4df1867d98cee4a2c4531352a33ad ]
We have to free on ->remove() the allocated resources on ->probe().
Fixes:
d47d88361fee ("auxdisplay: Add HD44780 Character LCD support")
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kangjie Lu [Fri, 15 Mar 2019 04:04:14 +0000 (23:04 -0500)]
ALSA: sb8: add a check for request_region
[ Upstream commit
dcd0feac9bab901d5739de51b3f69840851f8919 ]
In case request_region fails, the fix returns an error code to
avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kangjie Lu [Fri, 15 Mar 2019 03:58:29 +0000 (22:58 -0500)]
ALSA: echoaudio: add a check for ioremap_nocache
[ Upstream commit
6ade657d6125ec3ec07f95fa51e28138aef6208f ]
In case ioremap_nocache fails, the fix releases chip and returns
an error code upstream to avoid NULL pointer dereference.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lukas Czerner [Fri, 15 Mar 2019 04:22:28 +0000 (00:22 -0400)]
ext4: report real fs size after failed resize
[ Upstream commit
6c7328400e0488f7d49e19e02290ba343b6811b2 ]
Currently when the file system resize using ext4_resize_fs() fails it
will report into log that "resized filesystem to <requested block
count>". However this may not be true in the case of failure. Use the
current block count as returned by ext4_blocks_count() to report the
block count.
Additionally, report a warning that "error occurred during file system
resize"
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lukas Czerner [Fri, 15 Mar 2019 04:15:32 +0000 (00:15 -0400)]
ext4: add missing brelse() in add_new_gdb_meta_bg()
[ Upstream commit
d64264d6218e6892edd832dc3a5a5857c2856c53 ]
Currently in add_new_gdb_meta_bg() there is a missing brelse of gdb_bh
in case ext4_journal_get_write_access() fails.
Additionally kvfree() is missing in the same error path. Fix it by
moving the ext4_journal_get_write_access() before the ext4 sb update as
Ted suggested and release n_group_desc and gdb_bh in case it fails.
Fixes:
61a9c11e5e7a ("ext4: add missing brelse() add_new_gdb_meta_bg()'s error path")
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jan Kara [Fri, 15 Mar 2019 03:46:05 +0000 (23:46 -0400)]
ext4: avoid panic during forced reboot
[ Upstream commit
1dc1097ff60e4105216da7cd0aa99032b039a994 ]
When admin calls "reboot -f" - i.e., does a hard system reboot by
directly calling reboot(2) - ext4 filesystem mounted with errors=panic
can panic the system. This happens because the underlying device gets
disabled without unmounting the filesystem and thus some syscall running
in parallel to reboot(2) can result in the filesystem getting IO errors.
This is somewhat surprising to the users so try improve the behavior by
switching to errors=remount-ro behavior when the system is running
reboot(2).
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephane Eranian [Thu, 7 Mar 2019 18:52:33 +0000 (10:52 -0800)]
perf/core: Restore mmap record type correctly
[ Upstream commit
d9c1bb2f6a2157b38e8eb63af437cb22701d31ee ]
On mmap(), perf_events generates a RECORD_MMAP record and then checks
which events are interested in this record. There are currently 2
versions of mmap records: RECORD_MMAP and RECORD_MMAP2. MMAP2 is larger.
The event configuration controls which version the user level tool
accepts.
If the event->attr.mmap2=1 field then MMAP2 record is returned. The
perf_event_mmap_output() takes care of this. It checks attr->mmap2 and
corrects the record fields before putting it in the sampling buffer of
the event. At the end the function restores the modified MMAP record
fields.
The problem is that the function restores the size but not the type.
Thus, if a subsequent event only accepts MMAP type, then it would
instead receive an MMAP2 record with a size of MMAP record.
This patch fixes the problem by restoring the record type on exit.
Signed-off-by: Stephane Eranian <eranian@google.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Fixes:
13d7a2410fa6 ("perf: Add attr->mmap2 attribute to an event")
Link: http://lkml.kernel.org/r/20190307185233.225521-1-eranian@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ZhangXiaoxu [Sat, 2 Mar 2019 01:17:32 +0000 (09:17 +0800)]
inotify: Fix fsnotify_mark refcount leak in inotify_update_existing_watch()
[ Upstream commit
62c9d2674b31d4c8a674bee86b7edc6da2803aea ]
Commit
4d97f7d53da7dc83 ("inotify: Add flag IN_MASK_CREATE for
inotify_add_watch()") forgot to call fsnotify_put_mark() with
IN_MASK_CREATE after fsnotify_find_mark()
Fixes:
4d97f7d53da7dc83 ("inotify: Add flag IN_MASK_CREATE for inotify_add_watch()")
Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Mon, 25 Feb 2019 09:45:38 +0000 (09:45 +0000)]
arc: hsdk_defconfig: Enable CONFIG_BLK_DEV_RAM
[ Upstream commit
0728aeb7ead99a9b0dac2f3c92b3752b4e02ff97 ]
We have now a HSDK device in our kernelci lab, but kernel builded via
the hsdk_defconfig lacks ramfs supports, so it cannot boot kernelci jobs
yet.
So this patch enable CONFIG_BLK_DEV_RAM in hsdk_defconfig.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eugeniy Paltsev [Mon, 25 Feb 2019 17:16:01 +0000 (20:16 +0300)]
ARC: u-boot args: check that magic number is correct
[ Upstream commit
edb64bca50cd736c6894cc6081d5263c007ce005 ]
In case of devboards we really often disable bootloader and load
Linux image in memory via JTAG. Even if kernel tries to verify
uboot_tag and uboot_arg there is sill a chance that we treat some
garbage in registers as valid u-boot arguments in JTAG case.
E.g. it is enough to have '1' in r0 to treat any value in r2 as
a boot command line.
So check that magic number passed from u-boot is correct and drop
u-boot arguments otherwise. That helps to reduce the possibility
of using garbage as u-boot arguments in JTAG case.
We can safely check U-boot magic value (0x0) in linux passed via
r1 register as U-boot pass it from the beginning. So there is no
backward-compatibility issues.
Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Greg Kroah-Hartman [Wed, 17 Apr 2019 06:38:55 +0000 (08:38 +0200)]
Linux 4.19.35
Marc Orr [Tue, 2 Apr 2019 06:56:00 +0000 (23:56 -0700)]
KVM: x86: nVMX: fix x2APIC VTPR read intercept
commit
c73f4c998e1fd4249b9edfa39e23f4fda2b9b041 upstream.
Referring to the "VIRTUALIZING MSR-BASED APIC ACCESSES" chapter of the
SDM, when "virtualize x2APIC mode" is 1 and "APIC-register
virtualization" is 0, a RDMSR of 808H should return the VTPR from the
virtual APIC page.
However, for nested, KVM currently fails to disable the read intercept
for this MSR. This means that a RDMSR exit takes precedence over
"virtualize x2APIC mode", and KVM passes through L1's TPR to L2,
instead of sourcing the value from L2's virtual APIC page.
This patch fixes the issue by disabling the read intercept, in VMCS02,
for the VTPR when "APIC-register virtualization" is 0.
The issue described above and fix prescribed here, were verified with
a related patch in kvm-unit-tests titled "Test VMX's virtualize x2APIC
mode w/ nested".
Signed-off-by: Marc Orr <marcorr@google.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Fixes:
c992384bde84f ("KVM: vmx: speed up MSR bitmap merge")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Orr [Tue, 2 Apr 2019 06:55:59 +0000 (23:55 -0700)]
KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887)
commit
acff78477b9b4f26ecdf65733a4ed77fe837e9dc upstream.
The nested_vmx_prepare_msr_bitmap() function doesn't directly guard the
x2APIC MSR intercepts with the "virtualize x2APIC mode" MSR. As a
result, we discovered the potential for a buggy or malicious L1 to get
access to L0's x2APIC MSRs, via an L2, as follows.
1. L1 executes WRMSR(IA32_SPEC_CTRL, 1). This causes the spec_ctrl
variable, in nested_vmx_prepare_msr_bitmap() to become true.
2. L1 disables "virtualize x2APIC mode" in VMCS12.
3. L1 enables "APIC-register virtualization" in VMCS12.
Now, KVM will set VMCS02's x2APIC MSR intercepts from VMCS12, and then
set "virtualize x2APIC mode" to 0 in VMCS02. Oops.
This patch closes the leak by explicitly guarding VMCS02's x2APIC MSR
intercepts with VMCS12's "virtualize x2APIC mode" control.
The scenario outlined above and fix prescribed here, were verified with
a related patch in kvm-unit-tests titled "Add leak scenario to
virt_x2apic_mode_test".
Note, it looks like this issue may have been introduced inadvertently
during a merge---see
15303ba5d1cd.
Signed-off-by: Marc Orr <marcorr@google.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Erik Schmauss [Wed, 17 Oct 2018 21:09:35 +0000 (14:09 -0700)]
ACPICA: AML interpreter: add region addresses in global list during initialization
commit
4abb951b73ff0a8a979113ef185651aa3c8da19b upstream.
The table load process omitted adding the operation region address
range to the global list. This omission is problematic because the OS
queries the global list to check for address range conflicts before
deciding which drivers to load. This commit may result in warning
messages that look like the following:
[ 7.871761] ACPI Warning: system_IO range 0x00000428-0x0000042F conflicts with op_region 0x00000400-0x0000047F (\PMIO) (
20180531/utaddress-213)
[ 7.871769] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
However, these messages do not signify regressions. It is a result of
properly adding address ranges within the global address list.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200011
Tested-by: Jean-Marc Lenoir <archlinux@jihemel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomohiro Mayama [Sat, 9 Mar 2019 16:10:12 +0000 (01:10 +0900)]
arm64: dts: rockchip: Fix vcc_host1_5v GPIO polarity on rk3328-rock64
commit
a8772e5d826d0f61f8aa9c284b3ab49035d5273d upstream.
This patch makes USB ports functioning again.
Fixes:
955bebde057e ("arm64: dts: rockchip: add rk3328-rock64 board")
Cc: stable@vger.kernel.org
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Tomohiro Mayama <parly-gh@iris.mystia.org>
Tested-by: Katsuhiro Suzuki <katsuhiro@katsuster.net>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / platform / kernel / linux-rpi.git / log