- 05 Apr, 2019 40 commits
-
-
Michal Kazior authored
[ Upstream commit 5ddb0869 ] I've stumbled upon a kernel crash and the logs pointed me towards the lp5562 driver: > <4>[306013.841294] lp5562 0-0030: Direct firmware load for lp5562 failed with error -2 > <4>[306013.894990] lp5562 0-0030: Falling back to user helper > ... > <3>[306073.924886] lp5562 0-0030: firmware request failed > <1>[306073.939456] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > <4>[306074.251011] PC is at _raw_spin_lock+0x1c/0x58 > <4>[306074.255539] LR is at release_firmware+0x6c/0x138 > ... After taking a look I noticed firmware_release() could be called with either NULL or a dangling pointer. Fixes: 10c06d17 ("leds-lp55xx: support firmware interface") Signed-off-by:
Michal Kazior <michal@plume.com> Signed-off-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Theodore Ts'o authored
[ Upstream commit 538bcaa6 ] The jbd2 superblock is lockless now, so there is probably a race condition between writing it so disk and modifing contents of it, which may lead to checksum error. The following race is the one case that we have captured. jbd2 fsstress jbd2_journal_commit_transaction jbd2_journal_update_sb_log_tail jbd2_write_superblock jbd2_superblock_csum_set jbd2_journal_revoke jbd2_journal_set_features(revork) modify superblock submit_bh(checksum incorrect) Fix this by locking the buffer head before modifing it. We always write the jbd2 superblock after we modify it, so this just means calling the lock_buffer() a little earlier. This checksum corruption problem can be reproduced by xfstests generic/475. Reported-by:
zhangyi (F) <yi.zhang@huawei.com> Suggested-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Tejun Heo authored
[ Upstream commit b4ff1b44 ] cgroup_rstat_cpu_pop_updated() is used to traverse the updated cgroups on flush. While it was only visiting updated ones in the subtree, it was visiting @root unconditionally. We can easily check whether @root is updated or not by looking at its ->updated_next just as with the cgroups in the subtree. * Remove the unnecessary cgroup_parent() test. The system root cgroup is never updated and thus its ->updated_next is always NULL. No need to test whether cgroup_parent() exists in addition to ->updated_next. * Terminate traverse if ->updated_next is NULL. This can only happen for subtree @root and there's no reason to visit it if it's not marked updated. This reduces cpu consumption when reading a lot of rstat backed files. In a micro benchmark reading stat from ~1600 cgroups, the sys time was lowered by >40%. Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Hong Liu authored
[ Upstream commit 0d28f494 ] When performing a warm reset in ishtp bus driver, the ishtp_cl_device will not be removed, its fw_client still points to the already freed ishtp_device.fw_clients array. Later after driver finishing ishtp client enumeration, this dangling pointer may cause driver to bind the wrong ishtp_cl_device to the new client, causing wrong callback to be called for messages intended for the new client. This helps in development of firmware where frequent switching of firmwares is required without Linux reboot. Signed-off-by:
Hong Liu <hong.liu@intel.com> Tested-by:
Hongyan Song <hongyan.song@intel.com> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Aurelien Jarno authored
[ Upstream commit cc4b1242 ] The preadv2 and pwritev2 syscalls are supposed to emulate the readv and writev syscalls when offset == -1. Therefore the compat code should check for offset before calling do_compat_preadv64 and do_compat_pwritev64. This is the case for the preadv2 and pwritev2 syscalls, but handling of offset == -1 is missing in their 64-bit equivalent. This patch fixes that, calling do_compat_readv and do_compat_writev when offset == -1. This fixes the following glibc tests on x32: - misc/tst-preadvwritev2 - misc/tst-preadvwritev64v2 Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: H.J. Lu <hjl.tools@gmail.com> Signed-off-by:
Aurelien Jarno <aurelien@aurel32.net> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Oleksandr Andrushchenko authored
[ Upstream commit fa13e665 ] If there are exported DMA buffers which are still in use and grant device is closed by either normal user-space close or by a signal this leads to the grant device context to be destroyed, thus making it not possible to correctly destroy those exported buffers when they are returned back to gntdev and makes the module crash: [ 339.617540] [<ffff00000854c0d8>] dmabuf_exp_ops_release+0x40/0xa8 [ 339.617560] [<ffff00000867a6e8>] dma_buf_release+0x60/0x190 [ 339.617577] [<ffff0000082211f0>] __fput+0x88/0x1d0 [ 339.617589] [<ffff000008221394>] ____fput+0xc/0x18 [ 339.617607] [<ffff0000080ed4e4>] task_work_run+0x9c/0xc0 [ 339.617622] [<ffff000008089714>] do_notify_resume+0xfc/0x108 Fix this by referencing gntdev on each DMA buffer export and unreferencing on buffer release. Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by: Boris Ostrovsky@oracle.com> Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Lorenzo Bianconi authored
[ Upstream commit b3098121 ] Do not call mt76u_queues_deinit routine in mt76u_alloc_queues error path since it will be run in mt76x0u_register_device or mt76x2u_register_device error path. Current implementation triggers the following kernel warning: [ 67.005516] WARNING: CPU: 2 PID: 761 at lib/refcount.c:187 refcount_sub_and_test_checked+0xa4/0xb8 [ 67.019513] refcount_t: underflow; use-after-free. [ 67.099872] Hardware name: BCM2835 [ 67.106268] Backtrace: [ 67.111584] [<8010c91c>] (dump_backtrace) from [<8010cc00>] (show_stack+0x20/0x24) [ 67.124974] r6:60000013 r5:ffffffff r4:00000000 r3:a50bade6 [ 67.132226] [<8010cbe0>] (show_stack) from [<807ca5f4>] (dump_stack+0xc8/0x114) [ 67.141225] [<807ca52c>] (dump_stack) from [<8011e65c>] (__warn+0xf4/0x120) [ 67.149849] r9:000000bb r8:804d0138 r7:00000009 r6:8099dc84 r5:00000000 r4:b66c7b58 [ 67.160767] [<8011e568>] (__warn) from [<8011e6d0>] (warn_slowpath_fmt+0x48/0x50) [ 67.171436] r9:7f65e128 r8:80d1419c r7:80c0bac4 r6:b97b3044 r5:b7368e00 r4:00000000 [ 67.182433] [<8011e68c>] (warn_slowpath_fmt) from [<804d0138>] (refcount_sub_and_test_checked+0xa4/0xb8) [ 67.195221] r3:80c91c25 r2:8099dc94 [ 67.200370] r4:00000000 [ 67.204397] [<804d0094>] (refcount_sub_and_test_checked) from [<804d0164>] (refcount_dec_and_test_checked+0x18/0x1c) [ 67.218046] r4:b7368e00 r3:00000001 [ 67.223125] [<804d014c>] (refcount_dec_and_test_checked) from [<805db49c>] (usb_free_urb+0x20/0x4c) [ 67.235358] [<805db47c>] (usb_free_urb) from [<7f639804>] (mt76u_buf_free+0x98/0xac [mt76_usb]) [ 67.247302] r4:00000001 r3:00000001 [ 67.252468] [<7f63976c>] (mt76u_buf_free [mt76_usb]) from [<7f639ef8>] (mt76u_queues_deinit+0x44/0x100 [mt76_usb]) [ 67.266102] r8:b8fe8600 r7:b5dac480 r6:b5dace20 r5:00000001 r4:00000000 r3:00000080 [ 67.277132] [<7f639eb4>] (mt76u_queues_deinit [mt76_usb]) from [<7f65c040>] (mt76x0u_cleanup+0x40/0x4c [mt76x0u]) [ 67.290737] r7:b5dac480 r6:b8fe8600 r5:ffffffea r4:b5dace20 [ 67.298069] [<7f65c000>] (mt76x0u_cleanup [mt76x0u]) from [<7f65c564>] (mt76x0u_probe+0x1f0/0x354 [mt76x0u]) [ 67.311174] r4:b5dace20 r3:00000000 [ 67.316312] [<7f65c374>] (mt76x0u_probe [mt76x0u]) from [<805e0b6c>] (usb_probe_interface+0x104/0x240) [ 67.328915] r7:00000000 r6:7f65e034 r5:b6634800 r4:b8fe8620 [ 67.336276] [<805e0a68>] (usb_probe_interface) from [<8056a8bc>] (really_probe+0x224/0x2f8) [ 67.347965] r10:b65f0a00 r9:00000019 r8:7f65e034 r7:80d3e124 r6:00000000 r5:80d3e120 [ 67.359175] r4:b8fe8620 r3:805e0a68 [ 67.364384] [<8056a698>] (really_probe) from [<8056ab60>] (driver_probe_device+0x6c/0x180) [ 67.375974] r10:b65f0a00 r9:7f65e2c0 r8:b8fe8620 r7:00000000 r6:7f65e034 r5:7f65e034 [ 67.387170] r4:b8fe8620 r3:00000000 [ 67.392378] [<8056aaf4>] (driver_probe_device) from [<8056ad54>] (__driver_attach+0xe0/0xe4) [ 67.404097] r9:7f65e2c0 r8:7f65d22c r7:00000000 r6:b8fe8654 r5:7f65e034 r4:b8fe8620 [ 67.415122] [<8056ac74>] (__driver_attach) from [<8056880c>] (bus_for_each_dev+0x68/0xa0) [ 67.426628] r6:8056ac74 r5:7f65e034 r4:00000000 r3:00000027 [ 67.434017] [<805687a4>] (bus_for_each_dev) from [<8056a1cc>] (driver_attach+0x28/0x30) [ 67.445394] r6:80c6ddc8 r5:b7368f80 r4:7f65e034 [ 67.451703] [<8056a1a4>] (driver_attach) from [<80569c24>] (bus_add_driver+0x194/0x21c) [ 67.463081] [<80569a90>] (bus_add_driver) from [<8056b504>] (driver_register+0x8c/0x124) [ 67.474560] r7:80c6ddc8 r6:7f65e034 r5:00000000 r4:7f65e034 [ 67.481964] [<8056b478>] (driver_register) from [<805df510>] (usb_register_driver+0x74/0x140) [ 67.493901] r5:00000000 r4:7f65e000 [ 67.499131] [<805df49c>] (usb_register_driver) from [<7f661024>] (mt76x0_driver_init+0x24/0x1000 [mt76x0u]) [ 67.512258] r9:00000001 r8:7f65e308 r7:00000000 r6:80c08d48 r5:7f661000 r4:7f65e2c0 [ 67.523404] [<7f661000>] (mt76x0_driver_init [mt76x0u]) from [<80102f6c>] (do_one_initcall+0x4c/0x210) [ 67.536142] [<80102f20>] (do_one_initcall) from [<801ae63c>] (do_init_module+0x6c/0x21c) [ 67.547639] r8:7f65e308 r7:80c08d48 r6:b65f0ac0 r5:7f65e2c0 r4:7f65e2c0 [ 67.556129] [<801ae5d0>] (do_init_module) from [<801ad68c>] (load_module+0x1d10/0x2304) Fixes: b40b15e1 ("mt76: add usb support to mt76 layer") Signed-off-by:
Lorenzo Bianconi <lorenzo.bianconi@redhat.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit 1b275e4e ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit 8d20dcef ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit 30fa627b ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit da2d3a4e ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit 4a88f898 ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by:
-
Ezequiel Garcia authored
[ Upstream commit 43c14519 ] Fix the assigned type of mem2mem buffer handling API. Namely, these functions: v4l2_m2m_next_buf v4l2_m2m_last_buf v4l2_m2m_buf_remove v4l2_m2m_next_src_buf v4l2_m2m_next_dst_buf v4l2_m2m_last_src_buf v4l2_m2m_last_dst_buf v4l2_m2m_src_buf_remove v4l2_m2m_dst_buf_remove return a struct vb2_v4l2_buffer, and not a struct vb2_buffer. Fixing this is necessary to fix the mem2mem buffer handling API, changing the return to the correct struct vb2_v4l2_buffer instead of a void pointer. Signed-off-by:
-
Akinobu Mita authored
[ Upstream commit 12aceee1 ] The runtime PM of this device is enabled after v4l2_ctrl_handler_setup(), and this makes this device's runtime PM usage count a negative value. The ov7740_set_ctrl() tries to do something only if the device's runtime PM usage counter is nonzero. ov7740_set_ctrl() { if (!pm_runtime_get_if_in_use(&client->dev)) return 0; <do something>; pm_runtime_put(&client->dev); return ret; } However, the ov7740_set_ctrl() is called by v4l2_ctrl_handler_setup() while the runtime PM of this device is not yet enabled. In this case, the pm_runtime_get_if_in_use() returns -EINVAL (!= 0). Therefore we can't bail out of this function and the usage count is decreased by pm_runtime_put() without increment. This fixes this problem by enabling the runtime PM of this device before v4l2_ctrl_handler_setup() so that the ov7740_set_ctrl() is always called when the runtime PM is enabled. Cc: Wenyou Yang <wenyou.yang@microchip.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Tested-by:
Eugen Hristev <eugen.hristev@microchip.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Wen Yang authored
[ Upstream commit 8fa857da ] The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Detected by coccinelle with the following warnings: ./sound/soc/fsl/imx-sgtl5000.c:169:1-7: ERROR: missing put_device; call of_find_device_by_node on line 105, but without a corresponding object release within this function. ./sound/soc/fsl/imx-sgtl5000.c:177:1-7: ERROR: missing put_device; call of_find_device_by_node on line 105, but without a corresponding object release within this function. Signed-off-by:
Wen Yang <yellowriver2010@hotmail.com> Cc: Timur Tabi <timur@kernel.org> Cc: Nicolin Chen <nicoleotsuka@gmail.com> Cc: Xiubo Li <Xiubo.Lee@gmail.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Jaroslav Kysela <perex@perex.cz> Cc: Takashi Iwai <tiwai@suse.com> Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: alsa-devel@alsa-project.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
He Kuang authored
[ Upstream commit 7346195e ] We can't assume inlined symbols with the same name are equal, because their address range may be different. This will cause the symbols with different addresses be shadowed when adding to the hist entry, and lead to ERANGE error when checking the symbol address during sample parse, the addr should be within the range of [sym.start, sym.end]. The error message is like: "0x36aea60f [0x8]: failed to process type: 68". The second parameter of symbol__new() is the length of the fake symbol for the inline frame, which is the subtraction of the end and start address of base_sym. Signed-off-by:
He Kuang <hekuang@huawei.com> Acked-by:
Jiri Olsa <jolsa@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Milian Wolff <milian.wolff@kdab.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: aa441895 ("perf report: Compare symbol name for inlined frames when sorting") Link: http://lkml.kernel.org/r/20190219130531.15692-1-hekuang@huawei.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Brian Norris authored
[ Upstream commit 6f21ab30 ] As it is, doing something like # iw phy phy0 interface add foobar type ibss on a firmware that doesn't have ad-hoc support just yields failures of HostCmd_CMD_SET_BSS_MODE, which happened to return a '-1' error code (-EPERM? not really right...) and sometimes may even crash the firmware along the way. Let's parse the firmware capability flag while registering the wiphy, so we don't allow attempting IBSS at all, and we get a proper -EOPNOTSUPP from nl80211 instead. Fixes: e267e71e ("mwifiex: Disable adhoc feature based on firmware capability") Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Thomas Richter authored
[ Upstream commit 03d30971 ] Commit 489338a7 ("perf tests evsel-tp-sched: Fix bitwise operator") causes test case 14 "Parse sched tracepoints fields" to fail on s390. This test succeeds on x86. In fact this test now fails on all architectures with type char treated as type unsigned char. The root cause is the signed-ness of character arrays in the tracepoints sched_switch for structure members prev_comm and next_comm. On s390 the output of: [root@m35lp76 perf]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format name: sched_switch ID: 287 format: field:unsigned short common_type; offset:0; size:2; signed:0; ... field:char prev_comm[16]; offset:8; size:16; signed:0; ... field:char next_comm[16]; offset:40; size:16; signed:0; reveals the character arrays prev_comm and next_comm are per default unsigned char and have values in the range of 0..255. On x86 both fields are signed as this output shows: [root@f29]# cat /sys/kernel/debug/tracing/events/sched/sched_switch/format name: sched_switch ID: 287 format: field:unsigned short common_type; offset:0; size:2; signed:0; ... field:char prev_comm[16]; offset:8; size:16; signed:1; ... field:char next_comm[16]; offset:40; size:16; signed:1; and the character arrays prev_comm and next_comm are per default signed char and have values in the range of -1..127. The implementation of type char is architecture specific. Since the character arrays in both tracepoints sched_switch and sched_wakeup should contain ascii characters, simply omit the check for signedness in the test case. Output before: [root@m35lp76 perf]# ./perf test -F 14 14: Parse sched tracepoints fields : --- start --- sched:sched_switch: "prev_comm" signedness(0) is wrong, should be 1 sched:sched_switch: "next_comm" signedness(0) is wrong, should be 1 sched:sched_wakeup: "comm" signedness(0) is wrong, should be 1 ---- end ---- 14: Parse sched tracepoints fields : FAILED! [root@m35lp76 perf]# Output after: [root@m35lp76 perf]# ./perf test -Fv 14 14: Parse sched tracepoints fields : --- start --- ---- end ---- Parse sched tracepoints fields: Ok [root@m35lp76 perf]# Fixes: 489338a7 ("perf tests evsel-tp-sched: Fix bitwise operator") Signed-off-by:
Thomas Richter <tmricht@linux.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Link: http://lkml.kernel.org/r/20190219153639.31267-1-tmricht@linux.ibm.comSigned-off-by:
-
Nicholas Kazlauskas authored
[ Upstream commit d8d2f174 ] [Why] The stream->mode_changed flag can persist in the following sequence of atomic commits: Commit 1: Enable CRTC0 (mode_changed = true), Enable CRTC1 (mode_changed = true) Commit 2: Disable CRTC1 (mode_changed = false) In this sequence we want to keep the exiting CRTC0 but it's not in the atomic state for the commit since it hasn't been modified. In this case the stream->mode_changed flag persists as true and we don't re-program the planes for the existing stream. [How] The flag needs to be cleared and it makes the most sense to do it within DC after the state has been committed. Nothing following dc_commit_state should think that the stream's mode has changed. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Leo Li <sunpeng.li@amd.com> Acked-by:
Tony Cheng <Tony.Cheng@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Sedat Dilek authored
[ Upstream commit 8beb90aa ] commit 1917d42d ("fcoe: use enum for fip_mode") introduces a separate enum for the fip_mode that shall be used during initialisation handling until it is passed to fcoe_ctrl_link_up to set the initial fip_state. That change was incomplete and gcc quietly converted in various places between the fip_mode and the fip_state enum values with implicit enum conversions, which fortunately cannot cause any issues in the actual code's execution. clang however warns about these implicit enum conversions in the scsi drivers. This commit consolidates the use of the two enums, guided by clang's enum-conversion warnings. This commit now completes the use of the fip_mode: It expects and uses fip_mode in {bnx2fc,fcoe}_interface_create and fcoe_ctlr_init, and it calls fcoe_ctrl_set_set() with the correct values in fcoe_ctlr_link_up(). It also breaks the association between FIP_MODE_AUTO and FIP_ST_AUTO to indicate these two enums are distinct. Link: https://github.com/ClangBuiltLinux/linux/issues/151 Fixes: 1917d42d ("fcoe: use enum for fip_mode") Reported-by:
Dmitry Golovin <dima@golovin.in> Original-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> CC: Lukas Bulwahn <lukas.bulwahn@gmail.com> CC: Nick Desaulniers <ndesaulniers@google.com> CC: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Tested-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Jason Yan authored
[ Upstream commit bcf3b67d ] when create DMA pool for cmd frames failed, we should return -ENOMEM, instead of 0. In some case in: megasas_init_adapter_fusion() -->megasas_alloc_cmds() -->megasas_create_frame_pool create DMA pool failed, --> megasas_free_cmds() [1] -->megasas_alloc_cmds_fusion() failed, then goto fail_alloc_cmds. -->megasas_free_cmds() [2] we will call megasas_free_cmds twice, [1] will kfree cmd_list, [2] will use cmd_list.it will cause a problem: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ffffffc000f70000 [00000000] *pgd=0000001fbf893003, *pud=0000001fbf893003, *pmd=0000001fbf894003, *pte=006000006d000707 Internal error: Oops: 96000005 [#1] SMP Modules linked in: CPU: 18 PID: 1 Comm: swapper/0 Not tainted task: ffffffdfb9290000 ti: ffffffdfb923c000 task.ti: ffffffdfb923c000 PC is at megasas_free_cmds+0x30/0x70 LR is at megasas_free_cmds+0x24/0x70 ... Call trace: [<ffffffc0005b779c>] megasas_free_cmds+0x30/0x70 [<ffffffc0005bca74>] megasas_init_adapter_fusion+0x2f4/0x4d8 [<ffffffc0005b926c>] megasas_init_fw+0x2dc/0x760 [<ffffffc0005b9ab0>] megasas_probe_one+0x3c0/0xcd8 [<ffffffc0004a5abc>] local_pci_probe+0x4c/0xb4 [<ffffffc0004a5c40>] pci_device_probe+0x11c/0x14c [<ffffffc00053a5e4>] driver_probe_device+0x1ec/0x430 [<ffffffc00053a92c>] __driver_attach+0xa8/0xb0 [<ffffffc000538178>] bus_for_each_dev+0x74/0xc8 [<ffffffc000539e88>] driver_attach+0x28/0x34 [<ffffffc000539a18>] bus_add_driver+0x16c/0x248 [<ffffffc00053b234>] driver_register+0x6c/0x138 [<ffffffc0004a5350>] __pci_register_driver+0x5c/0x6c [<ffffffc000ce3868>] megasas_init+0xc0/0x1a8 [<ffffffc000082a58>] do_one_initcall+0xe8/0x1ec [<ffffffc000ca7be8>] kernel_init_freeable+0x1c8/0x284 [<ffffffc0008d90b8>] kernel_init+0x1c/0xe4 Signed-off-by:
Jason Yan <yanaijie@huawei.com> Acked-by:
Sumit Saxena <sumit.saxena@broadcom.com> Signed-off-by:
-
Sebastian Ott authored
[ Upstream commit 0ff06c44 ] Prior to dma unmap/free operations the ism driver tries to ensure that the memory is no longer accessed by the HW. When errors during deregistration of memory regions from the HW occur the ism driver will not unmap/free this memory. When we receive notification from the hypervisor that a PCI function has been detached we can no longer access the device and would never unmap/free these memory regions which led to complaints by the DMA debug API. Treat this kind of errors during the deregistration of memory regions from the HW as success since it is already ensured that the memory is no longer accessed by HW. Reported-by:
Karsten Graul <kgraul@linux.ibm.com> Reported-by:
Hans Wippel <hwippel@linux.ibm.com> Signed-off-by:
Sebastian Ott <sebott@linux.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Ross Lagerwall authored
[ Upstream commit 45b14a4f ] When checking a generic status block, we iterate over all the generic data blocks. The loop condition only checks that the start of the generic data block is valid (within estatus->data_length) but not the whole block. Because the size of data blocks (excluding error data) may vary depending on the revision and the revision is contained within the data block, ensure that enough of the current data block is valid before dereferencing any members otherwise an out-of-bounds access may occur if estatus->data_length is invalid. This relies on the fact that struct acpi_hest_generic_data_v300 is a superset of the earlier version. Also rework the other checks to avoid potential underflow. Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by:
Borislav Petkov <bp@suse.de> Tested-by:
Tyler Baicar <baicar.tyler@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Erwan Velu authored
[ Upstream commit 1222d527 ] There is some rare cases where CPB (and possibly IDA) are missing on processors. This is the case fixed by commit f7f3dc00 ("x86/cpu/AMD: Fix erratum 1076 (CPB bit)") and following. In such context, the boost status isn't reported by /sys/devices/system/cpu/cpufreq/boost. This commit is about printing a message to report that the CPU doesn't expose the boost capabilities. This message could help debugging platforms hit by this phenomena. Signed-off-by:
Erwan Velu <e.velu@criteo.com> [ rjw: Change the message text somewhat ] Signed-off-by:
-
Takashi Iwai authored
[ Upstream commit 70b77321 ] Although qcom_snd_parse_of() tries to manage the of-node refcount, there are still a few places that lead to the unblanced refcount in the error code path. Namely, - for_each_child_of_node() needs to unreference the iterator node if aborting the loop in the middle, - cpu, codec and platform node objects have to be unreferenced at each iteration, - platform and codec node objects have to be referred before jumping to the error handling code that unreference them unconditionally. This patch tries to address these by moving the assignment of platform and codec node objects to the beginning of the loop and adding the of_node_put() calls adequately. Fixes: c25e295c ("ASoC: qcom: Add support to parse common audio device nodes") Cc: Patrick Lai <plai@codeaurora.org> Cc: Banajit Goswami <bgoswami@codeaurora.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Wei Li authored
[ Upstream commit 11db1ad4 ] The output of "perf annotate -l --stdio xxx" changed since commit 425859ff ("perf annotate: No need to calculate notes->start twice") removed notes->start assignment in symbol__calc_lines(). It will get failed in find_address_in_section() from symbol__tty_annotate() subroutine as the a2l->addr is wrong. So the annotate summary doesn't report the line number of source code correctly. Before fix: liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ cat common_while_1.c void hotspot_1(void) { volatile int i; for (i = 0; i < 0x10000000; i++); for (i = 0; i < 0x10000000; i++); for (i = 0; i < 0x10000000; i++); } int main(void) { hotspot_1(); return 0; } liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ gcc common_while_1.c -g -o common_while_1 liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf record ./common_while_1 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.488 MB perf.data (12498 samples) ] liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf annotate -l -s hotspot_1 --stdio Sorted summary for file /home/liwei/main_code/hulk_work/hulk/tools/perf/common_while_1 ---------------------------------------------- 19.30 common_while_1[32] 19.03 common_while_1[4e] 19.01 common_while_1[16] 5.04 common_while_1[13] 4.99 common_while_1[4b] 4.78 common_while_1[2c] 4.77 common_while_1[10] 4.66 common_while_1[2f] 4.59 common_while_1[51] 4.59 common_while_1[35] 4.52 common_while_1[19] 4.20 common_while_1[56] 0.51 common_while_1[48] Percent | Source code & Disassembly of common_while_1 for cycles:ppp (12480 samples, percent: local period) ----------------------------------------------------------------------------------------------------------------- : : : : Disassembly of section .text: : : 00000000000005fa <hotspot_1>: : hotspot_1(): : void hotspot_1(void) : { 0.00 : 5fa: push %rbp 0.00 : 5fb: mov %rsp,%rbp : volatile int i; : : for (i = 0; i < 0x10000000; i++); 0.00 : 5fe: movl $0x0,-0x4(%rbp) 0.00 : 605: jmp 610 <hotspot_1+0x16> 0.00 : 607: mov -0x4(%rbp),%eax common_while_1[10] 4.77 : 60a: add $0x1,%eax common_while_1[13] 5.04 : 60d: mov %eax,-0x4(%rbp) common_while_1[16] 19.01 : 610: mov -0x4(%rbp),%eax common_while_1[19] 4.52 : 613: cmp $0xfffffff,%eax 0.00 : 618: jle 607 <hotspot_1+0xd> : for (i = 0; i < 0x10000000; i++); ... After fix: liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf record ./common_while_1 [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.488 MB perf.data (12500 samples) ] liwei@euler:~/main_code/hulk_work/hulk/tools/perf$ sudo ./perf annotate -l -s hotspot_1 --stdio Sorted summary for file /home/liwei/main_code/hulk_work/hulk/tools/perf/common_while_1 ---------------------------------------------- 33.34 common_while_1.c:5 33.34 common_while_1.c:6 33.32 common_while_1.c:7 Percent | Source code & Disassembly of common_while_1 for cycles:ppp (12482 samples, percent: local period) ----------------------------------------------------------------------------------------------------------------- : : : : Disassembly of section .text: : : 00000000000005fa <hotspot_1>: : hotspot_1(): : void hotspot_1(void) : { 0.00 : 5fa: push %rbp 0.00 : 5fb: mov %rsp,%rbp : volatile int i; : : for (i = 0; i < 0x10000000; i++); 0.00 : 5fe: movl $0x0,-0x4(%rbp) 0.00 : 605: jmp 610 <hotspot_1+0x16> 0.00 : 607: mov -0x4(%rbp),%eax common_while_1.c:5 4.70 : 60a: add $0x1,%eax 4.89 : 60d: mov %eax,-0x4(%rbp) common_while_1.c:5 19.03 : 610: mov -0x4(%rbp),%eax common_while_1.c:5 4.72 : 613: cmp $0xfffffff,%eax 0.00 : 618: jle 607 <hotspot_1+0xd> : for (i = 0; i < 0x10000000; i++); 0.00 : 61a: movl $0x0,-0x4(%rbp) 0.00 : 621: jmp 62c <hotspot_1+0x32> 0.00 : 623: mov -0x4(%rbp),%eax common_while_1.c:6 4.54 : 626: add $0x1,%eax 4.73 : 629: mov %eax,-0x4(%rbp) common_while_1.c:6 19.54 : 62c: mov -0x4(%rbp),%eax common_while_1.c:6 4.54 : 62f: cmp $0xfffffff,%eax ... Signed-off-by:
Wei Li <liwei391@huawei.com> Acked-by:
-
Katsuhiro Suzuki authored
[ Upstream commit d13501a2 ] Custom approximation of fractional-divider may not need parent clock rate checking. For example Rockchip SoCs work fine using grand parent clock rate even if target rate is greater than parent. This patch checks parent clock rate only if CLK_SET_RATE_PARENT flag is set. For detailed example, clock tree of Rockchip I2S audio hardware. - Clock rate of CPLL is 1.2GHz, GPLL is 491.52MHz. - i2s1_div is integer divider can divide N (N is 1~128). Input clock is CPLL or GPLL. Initial divider value is N = 1. Ex) PLL = CPLL, N = 10, i2s1_div output rate is CPLL / 10 = 1.2GHz / 10 = 120MHz - i2s1_frac is fractional divider can divide input to x/y, x and y are 16bit integer. CPLL --> | selector | ---> i2s1_div -+--> | selector | --> I2S1 MCLK GPLL --> | | ,--------------' | | `--> i2s1_frac ---> | | Clock mux system try to choose suitable one from i2s1_div and i2s1_frac for master clock (MCLK) of I2S1. Bad scenario as follows: - Try to set MCLK to 8.192MHz (32kHz audio replay) Candidate setting is - i2s1_div: GPLL / 60 = 8.192MHz i2s1_div candidate is exactly same as target clock rate, so mux choose this clock source. i2s1_div output rate is changed 491.52MHz -> 8.192MHz - After that try to set to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div = 8.192MHz This is because clk_fd_round_rate() thinks target rate (11.2896MHz) is higher than parent rate (i2s1_div = 8.192MHz) and returns parent clock rate. Above is current upstreamed behavior. Clock mux system choose i2s1_div, but this clock rate is not acceptable for I2S driver, so users cannot replay audio. Expected behavior is: - Try to set master clock to 11.2896MHz (44.1kHz audio replay) Candidate settings are - i2s1_div : CPLL / 107 = 11.214945MHz - i2s1_frac: i2s1_div * 147/6400 = 11.2896MHz Change i2s1_div to GPLL / 1 = 491.52MHz at same time. If apply this commit, clk_fd_round_rate() calls custom approximate function of Rockchip even if target rate is higher than parent. Custom function changes both grand parent (i2s1_div) and parent (i2s_frac) settings at same time. Clock mux system can choose i2s1_frac and audio works fine. Signed-off-by:
Katsuhiro Suzuki <katsuhiro@katsuster.net> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> [sboyd@kernel.org: Make function into a macro instead] Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Håkon Bugge authored
[ Upstream commit 2612d723 ] Using CX-3 virtual functions, either from a bare-metal machine or pass-through from a VM, MAD packets are proxied through the PF driver. Since the VF drivers have separate name spaces for MAD Transaction Ids (TIDs), the PF driver has to re-map the TIDs and keep the book keeping in a cache. Following the RDMA Connection Manager (CM) protocol, it is clear when an entry has to evicted form the cache. But life is not perfect, remote peers may die or be rebooted. Hence, it's a timeout to wipe out a cache entry, when the PF driver assumes the remote peer has gone. During workloads where a high number of QPs are destroyed concurrently, excessive amount of CM DREQ retries has been observed The problem can be demonstrated in a bare-metal environment, where two nodes have instantiated 8 VFs each. This using dual ported HCAs, so we have 16 vPorts per physical server. 64 processes are associated with each vPort and creates and destroys one QP for each of the remote 64 processes. That is, 1024 QPs per vPort, all in all 16K QPs. The QPs are created/destroyed using the CM. When tearing down these 16K QPs, excessive CM DREQ retries (and duplicates) are observed. With some cat/paste/awk wizardry on the infiniband_cm sysfs, we observe as sum of the 16 vPorts on one of the nodes: cm_rx_duplicates: dreq 2102 cm_rx_msgs: drep 1989 dreq 6195 rep 3968 req 4224 rtu 4224 cm_tx_msgs: drep 4093 dreq 27568 rep 4224 req 3968 rtu 3968 cm_tx_retries: dreq 23469 Note that the active/passive side is equally distributed between the two nodes. Enabling pr_debug in cm.c gives tons of: [171778.814239] <mlx4_ib> mlx4_ib_multiplex_cm_handler: id{slave: 1,sl_cm_id: 0xd393089f} is NULL! By increasing the CM_CLEANUP_CACHE_TIMEOUT from 5 to 30 seconds, the tear-down phase of the application is reduced from approximately 90 to 50 seconds. Retries/duplicates are also significantly reduced: cm_rx_duplicates: dreq 2460 [] cm_tx_retries: dreq 3010 req 47 Increasing the timeout further didn't help, as these duplicates and retries stems from a too short CMA timeout, which was 20 (~4 seconds) on the systems. By increasing the CMA timeout to 22 (~17 seconds), the numbers fell down to about 10 for both of them. Adjustment of the CMA timeout is not part of this commit. Signed-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Acked-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Dongli Zhang authored
[ Upstream commit 758a58d0 ] Commit 0da03cab ("loop: Fix deadlock when calling blkdev_reread_part()") moves blkdev_reread_part() out of the loop_ctl_mutex. However, GENHD_FL_NO_PART_SCAN is set before __blkdev_reread_part(). As a result, __blkdev_reread_part() will fail the check of GENHD_FL_NO_PART_SCAN and will not rescan the loop device to delete all partitions. Below are steps to reproduce the issue: step1 # dd if=/dev/zero of=tmp.raw bs=1M count=100 step2 # losetup -P /dev/loop0 tmp.raw step3 # parted /dev/loop0 mklabel gpt step4 # parted -a none -s /dev/loop0 mkpart primary 64s 1 step5 # losetup -d /dev/loop0 Step5 will not be able to delete /dev/loop0p1 (introduced by step4) and there is below kernel warning message: [ 464.414043] __loop_clr_fd: partition scan of loop0 failed (rc=-22) This patch sets GENHD_FL_NO_PART_SCAN after blkdev_reread_part(). Fixes: 0da03cab ("loop: Fix deadlock when calling blkdev_reread_part()") Signed-off-by:
Dongli Zhang <dongli.zhang@oracle.com> Reviewed-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Vadim Pasternak authored
[ Upstream commit e4c275f7 ] Fix the following KASAN warning produced when booting a 64-bit kernel: [ 13.334750] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x19/0x70 [ 13.342166] Read of size 8 at addr ffff880235067178 by task kworker/2:1/42 [ 13.342176] CPU: 2 PID: 42 Comm: kworker/2:1 Not tainted 4.20.0-rc1+ #106 [ 13.342179] Hardware name: Mellanox Technologies Ltd. MSN2740/Mellanox x86 SFF board, BIOS 5.6.5 06/07/2016 [ 13.342190] Workqueue: events deferred_probe_work_func [ 13.342194] Call Trace: [ 13.342206] dump_stack+0xc7/0x15b [ 13.342214] ? show_regs_print_info+0x5/0x5 [ 13.342220] ? kmsg_dump_rewind_nolock+0x59/0x59 [ 13.342234] ? _raw_write_lock_irqsave+0x100/0x100 [ 13.351593] print_address_description+0x73/0x260 [ 13.351603] kasan_report+0x260/0x380 [ 13.351611] ? find_first_bit+0x19/0x70 [ 13.351619] find_first_bit+0x19/0x70 [ 13.351630] mlxreg_hotplug_work_handler+0x73c/0x920 [mlxreg_hotplug] [ 13.351639] ? __lock_text_start+0x8/0x8 [ 13.351646] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.351656] ? mlxreg_hotplug_remove+0x1e0/0x1e0 [mlxreg_hotplug] [ 13.351663] ? regmap_volatile+0x40/0xb0 [ 13.351668] ? regcache_write+0x4c/0x90 [ 13.351676] ? mlxplat_mlxcpld_reg_write+0x24/0x30 [mlx_platform] [ 13.351681] ? _regmap_write+0xea/0x220 [ 13.351688] ? __mutex_lock_slowpath+0x10/0x10 [ 13.351696] ? devm_add_action+0x70/0x70 [ 13.351701] ? mutex_unlock+0x1d/0x40 [ 13.351710] mlxreg_hotplug_probe+0x82e/0x989 [mlxreg_hotplug] [ 13.351723] ? mlxreg_hotplug_work_handler+0x920/0x920 [mlxreg_hotplug] [ 13.351731] ? sysfs_do_create_link_sd.isra.2+0xf4/0x190 [ 13.351737] ? sysfs_rename_link_ns+0xf0/0xf0 [ 13.351743] ? devres_close_group+0x2b0/0x2b0 [ 13.351749] ? pinctrl_put+0x20/0x20 [ 13.351755] ? acpi_dev_pm_attach+0x2c/0xd0 [ 13.351763] platform_drv_probe+0x70/0xd0 [ 13.351771] really_probe+0x480/0x6e0 [ 13.351778] ? device_attach+0x10/0x10 [ 13.351784] ? __lock_text_start+0x8/0x8 [ 13.351790] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.351797] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.351806] ? __driver_attach+0x190/0x190 [ 13.351812] driver_probe_device+0x17d/0x1a0 [ 13.351819] ? __driver_attach+0x190/0x190 [ 13.351825] bus_for_each_drv+0xd6/0x130 [ 13.351831] ? bus_rescan_devices+0x20/0x20 [ 13.351837] ? __mutex_lock_slowpath+0x10/0x10 [ 13.351845] __device_attach+0x18c/0x230 [ 13.351852] ? device_bind_driver+0x70/0x70 [ 13.351859] ? __mutex_lock_slowpath+0x10/0x10 [ 13.351866] bus_probe_device+0xea/0x110 [ 13.351874] deferred_probe_work_func+0x1c9/0x290 [ 13.351882] ? driver_deferred_probe_add+0x1d0/0x1d0 [ 13.351889] ? preempt_notifier_dec+0x20/0x20 [ 13.351897] ? read_word_at_a_time+0xe/0x20 [ 13.351904] ? strscpy+0x151/0x290 [ 13.351912] ? set_work_pool_and_clear_pending+0x9c/0xf0 [ 13.351918] ? __switch_to_asm+0x34/0x70 [ 13.351924] ? __switch_to_asm+0x40/0x70 [ 13.351929] ? __switch_to_asm+0x34/0x70 [ 13.351935] ? __switch_to_asm+0x40/0x70 [ 13.351942] process_one_work+0x5cc/0xa00 [ 13.351952] ? pwq_dec_nr_in_flight+0x1e0/0x1e0 [ 13.351960] ? pci_mmcfg_check_reserved+0x80/0xb8 [ 13.351967] ? run_rebalance_domains+0x250/0x250 [ 13.351980] ? stack_access_ok+0x35/0x80 [ 13.351986] ? deref_stack_reg+0xa1/0xe0 [ 13.351994] ? schedule+0xcd/0x250 [ 13.352000] ? worker_enter_idle+0x2d6/0x330 [ 13.352006] ? __schedule+0xeb0/0xeb0 [ 13.352014] ? fork_usermode_blob+0x130/0x130 [ 13.352019] ? mutex_lock+0xa7/0x100 [ 13.352026] ? _raw_spin_lock_irq+0x98/0xf0 [ 13.352032] ? _raw_read_unlock_irqrestore+0x30/0x30 [ 13.352037] i2c i2c-2: Added multiplexed i2c bus 11 [ 13.352043] worker_thread+0x181/0xa80 [ 13.352052] ? __switch_to_asm+0x34/0x70 [ 13.352058] ? __switch_to_asm+0x40/0x70 [ 13.352064] ? process_one_work+0xa00/0xa00 [ 13.352070] ? __switch_to_asm+0x34/0x70 [ 13.352076] ? __switch_to_asm+0x40/0x70 [ 13.352081] ? __switch_to_asm+0x34/0x70 [ 13.352086] ? __switch_to_asm+0x40/0x70 [ 13.352092] ? __switch_to_asm+0x34/0x70 [ 13.352097] ? __switch_to_asm+0x40/0x70 [ 13.352105] ? __schedule+0x3d6/0xeb0 [ 13.352112] ? migrate_swap_stop+0x470/0x470 [ 13.352119] ? save_stack+0x89/0xb0 [ 13.352127] ? kmem_cache_alloc_trace+0xe5/0x570 [ 13.352132] ? kthread+0x59/0x1d0 [ 13.352138] ? ret_from_fork+0x35/0x40 [ 13.352154] ? __schedule+0xeb0/0xeb0 [ 13.352161] ? remove_wait_queue+0x150/0x150 [ 13.352169] ? _raw_write_lock_irqsave+0x80/0x100 [ 13.352175] ? __lock_text_start+0x8/0x8 [ 13.352183] ? process_one_work+0xa00/0xa00 [ 13.352188] kthread+0x1a4/0x1d0 [ 13.352195] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 13.352202] ret_from_fork+0x35/0x40 [ 13.353879] The buggy address belongs to the page: [ 13.353885] page:ffffea0008d419c0 count:0 mapcount:0 mapping:0000000000000000 index:0x0 [ 13.353890] flags: 0x2ffff8000000000() [ 13.353897] raw: 02ffff8000000000 ffffea0008d419c8 ffffea0008d419c8 0000000000000000 [ 13.353903] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 13.353905] page dumped because: kasan: bad access detected [ 13.353908] Memory state around the buggy address: [ 13.353912] ffff880235067000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 13.353917] ffff880235067080: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 [ 13.353921] >ffff880235067100: f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 04 [ 13.353923] ^ [ 13.353927] ffff880235067180: f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 00 00 00 00 00 [ 13.353931] ffff880235067200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 13.353933] ================================================================== The warning is caused by the below loop: for_each_set_bit(bit, (unsigned long *)&asserted, 8) { while "asserted" is declared as 'unsigned'. The casting of 32-bit unsigned integer pointer to a 64-bit unsigned long pointer. There are two problems here. It causes the access of four extra byte, which can corrupt memory The 32-bit pointer address may not be 64-bit aligned. The fix changes variable "asserted" to "unsigned long". Fixes: 1f976f69 ("platform/x86: Move Mellanox platform hotplug driver to platform/mellanox") Signed-off-by:
Vadim Pasternak <vadimp@mellanox.com> Signed-off-by:
Darren Hart (VMware) <dvhart@infradead.org> Signed-off-by:
-
Yang Fan authored
[ Upstream commit 4d9b2864 ] Commit ae7c8cba ("platform/x86: ideapad-laptop: add lenovo RESCUER R720-15IKBN to no_hw_rfkill_list") added DMI_MATCH(DMI_BOARD_NAME, "80WW") for Lenovo RESCUER R720-15IKBN. But DMI_BOARD_NAME does not match 80WW on Lenovo RESCUER R720-15IKBN, thus cause Wireless LAN still be hard blocked. On Lenovo RESCUER R720-15IKBN: ~$ cat /sys/class/dmi/id/sys_vendor LENOVO ~$ cat /sys/class/dmi/id/board_name Provence-5R3 ~$ cat /sys/class/dmi/id/product_name 80WW ~$ cat /sys/class/dmi/id/product_version Lenovo R720-15IKBN So on Lenovo RESCUER R720-15IKBN: DMI_SYS_VENDOR should match "LENOVO", DMI_BOARD_NAME should match "Provence-5R3", DMI_PRODUCT_NAME should match "80WW", DMI_PRODUCT_VERSION should match "Lenovo R720-15IKBN". Fix it, and in according with other entries in no_hw_rfkill_list, use DMI_PRODUCT_VERSION instead of DMI_BOARD_NAME. Fixes: ae7c8cba ("platform/x86: ideapad-laptop: add lenovo RESCUER R720-15IKBN to no_hw_rfkill_list") Signed-off-by:
Yang Fan <nullptr.cpp@gmail.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit ab2c4e25 ] Give precision identifiers to the two snprintf() formatting the priority and TC strings to avoid producing these two warnings: drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function 'mlxsw_sp_port_get_prio_strings': drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:37: warning: '%d' directive output may be truncated writing between 1 and 3 bytes into a region of size between 0 and 31 [-Wformat-truncation=] snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~ drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2132:3: note: 'snprintf' output between 3 and 36 bytes into a destination of size 32 snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlxsw_sp_port_hw_prio_stats[i].str, prio); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlxsw/spectrum.c: In function 'mlxsw_sp_port_get_tc_strings': drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:37: warning: '%d' directive output may be truncated writing between 1 and 11 bytes into a region of size between 0 and 31 [-Wformat-truncation=] snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~ drivers/net/ethernet/mellanox/mlxsw/spectrum.c:2143:3: note: 'snprintf' output between 3 and 44 bytes into a destination of size 32 snprintf(*p, ETH_GSTRING_LEN, "%s_%d", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlxsw_sp_port_hw_tc_stats[i].str, tc); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 135e7245 ] Provide precision hints to snprintf() since we know the destination buffer size of the RX/TX ring names are IFNAMSIZ + 5 - 1. This fixes the following warnings: drivers/net/ethernet/intel/e1000e/netdev.c: In function 'e1000_request_msix': drivers/net/ethernet/intel/e1000e/netdev.c:2109:13: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] "%s-rx-0", netdev->name); ^ drivers/net/ethernet/intel/e1000e/netdev.c:2107:3: note: 'snprintf' output between 6 and 21 bytes into a destination of size 20 snprintf(adapter->rx_ring->name, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(adapter->rx_ring->name) - 1, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%s-rx-0", netdev->name); ~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/intel/e1000e/netdev.c:2125:13: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=] "%s-tx-0", netdev->name); ^ drivers/net/ethernet/intel/e1000e/netdev.c:2123:3: note: 'snprintf' output between 6 and 21 bytes into a destination of size 20 snprintf(adapter->tx_ring->name, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ sizeof(adapter->tx_ring->name) - 1, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "%s-tx-0", netdev->name); ~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by:
-
Andrew Lunn authored
[ Upstream commit f6d9758b ] The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ #302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Aaro Koskinen authored
[ Upstream commit a6327b5e ] When running OMAP1 kernel on QEMU, MMC access is annoyingly noisy: MMC: CTO of 0xff and 0xfe cannot be used! MMC: CTO of 0xff and 0xfe cannot be used! MMC: CTO of 0xff and 0xfe cannot be used! [ad inf.] Emulator warnings appear to be valid. The TI document SPRU680 [1] ("OMAP5910 Dual-Core Processor MultiMedia Card/Secure Data Memory Card (MMC/SD) Reference Guide") page 36 states that the maximum timeout is 253 cycles and "0xff and 0xfe cannot be used". Fix by using 0xfd as the maximum timeout. Tested using QEMU 2.5 (Siemens SX1 machine, OMAP310), and also checked on real hardware using Palm TE (OMAP310), Nokia 770 (OMAP1710) and Nokia N810 (OMAP2420) that MMC works as before. [1] http://www.ti.com/lit/ug/spru680/spru680.pdf Fixes: 730c9b7e ("[MMC] Add OMAP MMC host driver") Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Qu Wenruo authored
[ Upstream commit f5fef459 ] [BUG] Btrfs qgroup will still hit EDQUOT under the following case: $ dev=/dev/test/test $ mnt=/mnt/btrfs $ umount $mnt &> /dev/null $ umount $dev &> /dev/null $ mkfs.btrfs -f $dev $ mount $dev $mnt -o nospace_cache $ btrfs subv create $mnt/subv $ btrfs quota enable $mnt $ btrfs quota rescan -w $mnt $ btrfs qgroup limit -e 1G $mnt/subv $ fallocate -l 900M $mnt/subv/padding $ sync $ rm $mnt/subv/padding # Hit EDQUOT $ xfs_io -f -c "pwrite 0 512M" $mnt/subv/real_file [CAUSE] Since commit a514d638 ("btrfs: qgroup: Commit transaction in advance to reduce early EDQUOT"), btrfs is not forced to commit transaction to reclaim more quota space. Instead, we just check pertrans metadata reservation against some threshold and try to do asynchronously transaction commit. However in above case, the pertrans metadata reservation is pretty small thus it will never trigger asynchronous transaction commit. [FIX] Instead of only accounting pertrans metadata reservation, we calculate how much free space we have, and if there isn't much free space left, commit transaction asynchronously to try to free some space. This may slow down the fs when we have less than 32M free qgroup space, but should reduce a lot of false EDQUOT, so the cost should be acceptable. Signed-off-by:
Qu Wenruo <wqu@suse.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Aneesh Kumar K.V authored
[ Upstream commit 5330367f ] After we ALIGN up the address we need to make sure we didn't overflow and resulted in zero address. In that case, we need to make sure that the returned address is greater than mmap_min_addr. This fixes selftest va_128TBswitch --run-hugetlb reporting failures when run as non root user for mmap(-1, MAP_HUGETLB) The bug is that a non-root user requesting address -1 will be given address 0 which will then fail, whereas they should have been given something else that would have succeeded. We also avoid the first mmap(-1, MAP_HUGETLB) returning NULL address as mmap address with this change. So we think this is not a security issue, because it only affects whether we choose an address below mmap_min_addr, not whether we actually allow that address to be mapped. ie. there are existing capability checks to prevent a user mapping below mmap_min_addr and those will still be honoured even without this fix. Fixes: 48483760 ("powerpc/mm: Add radix support for hugetlb") Reviewed-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nicolas Boichat authored
[ Upstream commit 032ebd85 ] L1 tables are allocated with __get_dma_pages, and therefore already ignored by kmemleak. Without this, the kernel would print this error message on boot, when the first L1 table is allocated: [ 2.810533] kmemleak: Trying to color unknown object at 0xffffffd652388000 as Black [ 2.818190] CPU: 5 PID: 39 Comm: kworker/5:0 Tainted: G S 4.19.16 #8 [ 2.831227] Workqueue: events deferred_probe_work_func [ 2.836353] Call trace: ... [ 2.852532] paint_ptr+0xa0/0xa8 [ 2.855750] kmemleak_ignore+0x38/0x6c [ 2.859490] __arm_v7s_alloc_table+0x168/0x1f4 [ 2.863922] arm_v7s_alloc_pgtable+0x114/0x17c [ 2.868354] alloc_io_pgtable_ops+0x3c/0x78 ... Fixes: e5fc9753 ("iommu/io-pgtable: Add ARMv7 short descriptor support") Signed-off-by:
Nicolas Boichat <drinkcat@chromium.org> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
[ Upstream commit 74ffe79a ] Mostly unwind is done with irqs enabled however SLUB may call it with irqs disabled while creating a new SLUB cache. I had system freeze while loading a module which called kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled interrupts and then ->new_slab_objects() ->new_slab() ->setup_object() ->setup_object_debug() ->init_tracking() ->set_track() ->save_stack_trace() ->save_stack_trace_tsk() ->walk_stackframe() ->unwind_frame() ->unwind_find_idx() =>spin_lock_irqsave(&unwind_lock); Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit fe9ed6d2 ] Like the other OF-enabled drivers, use the port number from the firmware if the devicetree specifies an alias: aliases { ... serial2 = &uart2; /* Should be ttyS2 */ } This is how the deprecated pxa.c driver behaved, switching to 8250_pxa messes up the numbering. Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
