Omar Sandoval [Mon, 16 Sep 2019 18:30:54 +0000 (11:30 -0700)]
btrfs: don't prematurely free work in end_workqueue_fn()
[ Upstream commit
9be490f1e15c34193b1aae17da58e14dd9f55a95 ]
Currently, end_workqueue_fn() frees the end_io_wq entry (which embeds
the work item) and then calls bio_endio(). This is another potential
instance of the bug in "btrfs: don't prematurely free work in
run_ordered_work()".
In particular, the endio call may depend on other work items. For
example, btrfs_end_dio_bio() can call btrfs_subio_endio_read() ->
__btrfs_correct_data_nocsum() -> dio_read_error() ->
submit_dio_repair_bio(), which submits a bio that is also completed
through a end_workqueue_fn() work item. However,
__btrfs_correct_data_nocsum() waits for the newly submitted bio to
complete, thus it depends on another work item.
This example currently usually works because we use different workqueue
helper functions for BTRFS_WQ_ENDIO_DATA and BTRFS_WQ_ENDIO_DIO_REPAIR.
However, it may deadlock with stacked filesystems and is fragile
overall. The proper fix is to free the work item at the very end of the
work function, so let's do that.
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eugeniu Rosca [Fri, 15 Nov 2019 13:44:30 +0000 (14:44 +0100)]
mmc: tmio: Add MMC_CAP_ERASE to allow erase/discard/trim requests
[ Upstream commit
c91843463e9e821dc3b48fe37e3155fa38299f6e ]
Isolated initially to renesas_sdhi_internal_dmac [1], Ulf suggested
adding MMC_CAP_ERASE to the TMIO mmc core:
On Fri, Nov 15, 2019 at 10:27:25AM +0100, Ulf Hansson wrote:
-- snip --
This test and due to the discussions with Wolfram and you in this
thread, I would actually suggest that you enable MMC_CAP_ERASE for all
tmio variants, rather than just for this particular one.
In other words, set the cap in tmio_mmc_host_probe() should be fine,
as it seems none of the tmio variants supports HW busy detection at
this point.
-- snip --
Testing on R-Car H3ULCB-KF doesn't reveal any issues (v5.4-rc7):
root@rcar-gen3:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk0 179:0 0 59.2G 0 disk <--- eMMC
mmcblk0boot0 179:8 0 4M 1 disk
mmcblk0boot1 179:16 0 4M 1 disk
mmcblk1 179:24 0 30G 0 disk <--- SD card
root@rcar-gen3:~# time blkdiscard /dev/mmcblk0
real 0m8.659s
user 0m0.001s
sys 0m1.920s
root@rcar-gen3:~# time blkdiscard /dev/mmcblk1
real 0m1.176s
user 0m0.001s
sys 0m0.124s
[1] https://lore.kernel.org/linux-renesas-soc/
20191112134808.23546-1-erosca@de.adit-jv.com/
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Originally-by: Harish Jenny K N <harish_kandiga@mentor.com>
Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Sat, 9 Nov 2019 17:09:27 +0000 (18:09 +0100)]
crypto: virtio - deal with unsupported input sizes
[ Upstream commit
19c5da7d4a2662e85ea67d2d81df57e038fde3ab ]
Return -EINVAL for input sizes that are not a multiple of the AES
block size, since they are not supported by our CBC chaining mode.
While at it, remove the pr_err() that reports unsupported key sizes
being used: we shouldn't spam the kernel log with that.
Fixes:
dbaf0624ffa5 ("crypto: add virtio-crypto driver")
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Gonglei <arei.gonglei@huawei.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Petar Penkov [Thu, 14 Nov 2019 17:52:09 +0000 (09:52 -0800)]
tun: fix data-race in gro_normal_list()
[ Upstream commit
c39e342a050a4425348e6fe7f75827c0a1a7ebc5 ]
There is a race in the TUN driver between napi_busy_loop and
napi_gro_frags. This commit resolves the race by adding the NAPI struct
via netif_tx_napi_add, instead of netif_napi_add, which disables polling
for the NAPI struct.
KCSAN reported:
BUG: KCSAN: data-race in gro_normal_list.part.0 / napi_busy_loop
write to 0xffff8880b5d474b0 of 4 bytes by task 11205 on cpu 0:
gro_normal_list.part.0+0x77/0xb0 net/core/dev.c:5682
gro_normal_list net/core/dev.c:5678 [inline]
gro_normal_one net/core/dev.c:5692 [inline]
napi_frags_finish net/core/dev.c:5705 [inline]
napi_gro_frags+0x625/0x770 net/core/dev.c:5778
tun_get_user+0x2150/0x26a0 drivers/net/tun.c:1976
tun_chr_write_iter+0x79/0xd0 drivers/net/tun.c:2022
call_write_iter include/linux/fs.h:1895 [inline]
do_iter_readv_writev+0x487/0x5b0 fs/read_write.c:693
do_iter_write fs/read_write.c:970 [inline]
do_iter_write+0x13b/0x3c0 fs/read_write.c:951
vfs_writev+0x118/0x1c0 fs/read_write.c:1015
do_writev+0xe3/0x250 fs/read_write.c:1058
__do_sys_writev fs/read_write.c:1131 [inline]
__se_sys_writev fs/read_write.c:1128 [inline]
__x64_sys_writev+0x4e/0x60 fs/read_write.c:1128
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
read to 0xffff8880b5d474b0 of 4 bytes by task 11168 on cpu 1:
gro_normal_list net/core/dev.c:5678 [inline]
napi_busy_loop+0xda/0x4f0 net/core/dev.c:6126
sk_busy_loop include/net/busy_poll.h:108 [inline]
__skb_recv_udp+0x4ad/0x560 net/ipv4/udp.c:1689
udpv6_recvmsg+0x29e/0xe90 net/ipv6/udp.c:288
inet6_recvmsg+0xbb/0x240 net/ipv6/af_inet6.c:592
sock_recvmsg_nosec net/socket.c:871 [inline]
sock_recvmsg net/socket.c:889 [inline]
sock_recvmsg+0x92/0xb0 net/socket.c:885
sock_read_iter+0x15f/0x1e0 net/socket.c:967
call_read_iter include/linux/fs.h:1889 [inline]
new_sync_read+0x389/0x4f0 fs/read_write.c:414
__vfs_read+0xb1/0xc0 fs/read_write.c:427
vfs_read fs/read_write.c:461 [inline]
vfs_read+0x143/0x2c0 fs/read_write.c:446
ksys_read+0xd5/0x1b0 fs/read_write.c:587
__do_sys_read fs/read_write.c:597 [inline]
__se_sys_read fs/read_write.c:595 [inline]
__x64_sys_read+0x4c/0x60 fs/read_write.c:595
do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 11168 Comm: syz-executor.0 Not tainted 5.4.0-rc6+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Fixes:
943170998b20 ("tun: enable NAPI for TUN/TAP driver")
Signed-off-by: Petar Penkov <ppenkov@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Fri, 15 Nov 2019 08:31:22 +0000 (16:31 +0800)]
spi: tegra20-slink: add missed clk_unprepare
[ Upstream commit
04358e40ba96d687c0811c21d9dede73f5244a98 ]
The driver misses calling clk_unprepare in probe failure and remove.
Add the calls to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191115083122.12278-1-hslester96@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Walle [Tue, 12 Nov 2019 22:36:29 +0000 (23:36 +0100)]
ASoC: wm8904: fix regcache handling
[ Upstream commit
e9149b8c00d25dbaef1aa174fc604bed207e576d ]
The current code assumes that the power is turned off in
SND_SOC_BIAS_OFF. If there are no actual regulator the codec isn't
turned off and the registers are not reset to their default values but
the regcache is still marked as dirty. Thus a value might not be written
to the hardware if it is set to the default value. Do a software reset
before turning off the power to make sure the registers are always reset
to their default states.
Signed-off-by: Michael Walle <michael@walle.cc>
Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20191112223629.21867-1-michael@walle.cc
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Xuerui [Fri, 15 Nov 2019 07:28:02 +0000 (09:28 +0200)]
iwlwifi: mvm: fix unaligned read of rx_pkt_status
[ Upstream commit
c5aaa8be29b25dfe1731e9a8b19fd91b7b789ee3 ]
This is present since the introduction of iwlmvm.
Example stack trace on MIPS:
[<
ffffffffc0789328>] iwl_mvm_rx_rx_mpdu+0xa8/0xb88 [iwlmvm]
[<
ffffffffc0632b40>] iwl_pcie_rx_handle+0x420/0xc48 [iwlwifi]
Tested with a Wireless AC 7265 for ~6 months, confirmed to fix the
problem. No other unaligned accesses are spotted yet.
Signed-off-by: Wang Xuerui <wangxuerui@qiniu.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrea Righi [Wed, 13 Nov 2019 08:03:21 +0000 (16:03 +0800)]
bcache: fix deadlock in bcache_allocator
[ Upstream commit
84c529aea182939e68f618ed9813740c9165c7eb ]
bcache_allocator can call the following:
bch_allocator_thread()
-> bch_prio_write()
-> bch_bucket_alloc()
-> wait on &ca->set->bucket_wait
But the wake up event on bucket_wait is supposed to come from
bch_allocator_thread() itself => deadlock:
[ 1158.490744] INFO: task bcache_allocato:15861 blocked for more than 10 seconds.
[ 1158.495929] Not tainted 5.3.0-050300rc3-generic #
201908042232
[ 1158.500653] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1158.504413] bcache_allocato D 0 15861 2 0x80004000
[ 1158.504419] Call Trace:
[ 1158.504429] __schedule+0x2a8/0x670
[ 1158.504432] schedule+0x2d/0x90
[ 1158.504448] bch_bucket_alloc+0xe5/0x370 [bcache]
[ 1158.504453] ? wait_woken+0x80/0x80
[ 1158.504466] bch_prio_write+0x1dc/0x390 [bcache]
[ 1158.504476] bch_allocator_thread+0x233/0x490 [bcache]
[ 1158.504491] kthread+0x121/0x140
[ 1158.504503] ? invalidate_buckets+0x890/0x890 [bcache]
[ 1158.504506] ? kthread_park+0xb0/0xb0
[ 1158.504510] ret_from_fork+0x35/0x40
Fix by making the call to bch_prio_write() non-blocking, so that
bch_allocator_thread() never waits on itself.
Moreover, make sure to wake up the garbage collector thread when
bch_prio_write() is failing to allocate buckets.
BugLink: https://bugs.launchpad.net/bugs/1784665
BugLink: https://bugs.launchpad.net/bugs/1796292
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Tue, 29 Oct 2019 08:31:44 +0000 (17:31 +0900)]
tracing/kprobe: Check whether the non-suffixed symbol is notrace
[ Upstream commit
c7411a1a126f649be71526a36d4afac9e5aefa13 ]
Check whether the non-suffixed symbol is notrace, since suffixed
symbols are generated by the compilers for optimization. Based on
these suffixed symbols, notrace check might not work because
some of them are just a partial code of the original function.
(e.g. cold-cache (unlikely) code is separated from original
function as FUNCTION.cold.XX)
For example, without this fix,
# echo p device_add.cold.67 > /sys/kernel/debug/tracing/kprobe_events
sh: write error: Invalid argument
# cat /sys/kernel/debug/tracing/error_log
[ 135.491035] trace_kprobe: error: Failed to register probe event
Command: p device_add.cold.67
^
# dmesg | tail -n 1
[ 135.488599] trace_kprobe: Could not probe notrace function device_add.cold.67
With this,
# echo p device_add.cold.66 > /sys/kernel/debug/tracing/kprobe_events
# cat /sys/kernel/debug/kprobes/list
ffffffff81599de9 k device_add.cold.66+0x0 [DISABLED]
Actually, kprobe blacklist already did similar thing,
see within_kprobe_blacklist().
Link: http://lkml.kernel.org/r/157233790394.6706.18243942030937189679.stgit@devnote2
Fixes:
45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace function")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yuming Han [Thu, 24 Oct 2019 03:34:30 +0000 (11:34 +0800)]
tracing: use kvcalloc for tgid_map array allocation
[ Upstream commit
6ee40511cb838f9ced002dff7131bca87e3ccbdd ]
Fail to allocate memory for tgid_map, because it requires order-6 page.
detail as:
c3 sh: page allocation failure: order:6,
mode:0x140c0c0(GFP_KERNEL), nodemask=(null)
c3 sh cpuset=/ mems_allowed=0
c3 CPU: 3 PID: 5632 Comm: sh Tainted: G W O 4.14.133+ #10
c3 Hardware name: Generic DT based system
c3 Backtrace:
c3 [<
c010bdbc>] (dump_backtrace) from [<
c010c08c>](show_stack+0x18/0x1c)
c3 [<
c010c074>] (show_stack) from [<
c0993c54>](dump_stack+0x84/0xa4)
c3 [<
c0993bd0>] (dump_stack) from [<
c0229858>](warn_alloc+0xc4/0x19c)
c3 [<
c0229798>] (warn_alloc) from [<
c022a6e4>](__alloc_pages_nodemask+0xd18/0xf28)
c3 [<
c02299cc>] (__alloc_pages_nodemask) from [<
c0248344>](kmalloc_order+0x20/0x38)
c3 [<
c0248324>] (kmalloc_order) from [<
c0248380>](kmalloc_order_trace+0x24/0x108)
c3 [<
c024835c>] (kmalloc_order_trace) from [<
c01e6078>](set_tracer_flag+0xb0/0x158)
c3 [<
c01e5fc8>] (set_tracer_flag) from [<
c01e6404>](trace_options_core_write+0x7c/0xcc)
c3 [<
c01e6388>] (trace_options_core_write) from [<
c0278b1c>](__vfs_write+0x40/0x14c)
c3 [<
c0278adc>] (__vfs_write) from [<
c0278e10>](vfs_write+0xc4/0x198)
c3 [<
c0278d4c>] (vfs_write) from [<
c027906c>](SyS_write+0x6c/0xd0)
c3 [<
c0279000>] (SyS_write) from [<
c01079a0>](ret_fast_syscall+0x0/0x54)
Switch to use kvcalloc to avoid unexpected allocation failures.
Link: http://lkml.kernel.org/r/1571888070-24425-1-git-send-email-chunyan.zhang@unisoc.com
Signed-off-by: Yuming Han <yuming.han@unisoc.com>
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lianbo Jiang [Fri, 8 Nov 2019 09:00:27 +0000 (17:00 +0800)]
x86/crash: Add a forward declaration of struct kimage
[ Upstream commit
112eee5d06007dae561f14458bde7f2a4879ef4e ]
Add a forward declaration of struct kimage to the crash.h header because
future changes will invoke a crash-specific function from the realmode
init path and the compiler will complain otherwise like this:
In file included from arch/x86/realmode/init.c:11:
./arch/x86/include/asm/crash.h:5:32: warning: ‘struct kimage’ declared inside\
parameter list will not be visible outside of this definition or declaration
5 | int crash_load_segments(struct kimage *image);
| ^~~~~~
./arch/x86/include/asm/crash.h:6:37: warning: ‘struct kimage’ declared inside\
parameter list will not be visible outside of this definition or declaration
6 | int crash_copy_backup_region(struct kimage *image);
| ^~~~~~
./arch/x86/include/asm/crash.h:7:39: warning: ‘struct kimage’ declared inside\
parameter list will not be visible outside of this definition or declaration
7 | int crash_setup_memmap_entries(struct kimage *image,
|
[ bp: Rewrite the commit message. ]
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: bhe@redhat.com
Cc: d.hatayama@fujitsu.com
Cc: dhowells@redhat.com
Cc: dyoung@redhat.com
Cc: ebiederm@xmission.com
Cc: horms@verge.net.au
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jürgen Gross <jgross@suse.com>
Cc: kexec@lists.infradead.org
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: vgoyal@redhat.com
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191108090027.11082-4-lijiang@redhat.com
Link: https://lkml.kernel.org/r/201910310233.EJRtTMWP%25lkp@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Viresh Kumar [Thu, 14 Nov 2019 03:36:17 +0000 (09:06 +0530)]
cpufreq: Register drivers only after CPU devices have been registered
[ Upstream commit
46770be0cf94149ca48be87719bda1d951066644 ]
The cpufreq core heavily depends on the availability of the struct
device for CPUs and if they aren't available at the time cpufreq driver
is registered, we will never succeed in making cpufreq work.
This happens due to following sequence of events:
- cpufreq_register_driver()
- subsys_interface_register()
- return 0; //successful registration of driver
... at a later point of time
- register_cpu();
- device_register();
- bus_probe_device();
- sif->add_dev();
- cpufreq_add_dev();
- get_cpu_device(); //FAILS
- per_cpu(cpu_sys_devices, num) = &cpu->dev; //used by get_cpu_device()
- return 0; //CPU registered successfully
Because the per-cpu variable cpu_sys_devices is set only after the CPU
device is regsitered, cpufreq will never be able to get it when
cpufreq_add_dev() is called.
This patch avoids this failure by making sure device structure of at
least CPU0 is available when the cpufreq driver is registered, else
return -EPROBE_DEFER.
Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Co-developed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Coly Li [Wed, 13 Nov 2019 08:03:17 +0000 (16:03 +0800)]
bcache: fix static checker warning in bcache_device_free()
[ Upstream commit
2d8869518a525c9bce5f5268419df9dfbe3dfdeb ]
Commit
cafe56359144 ("bcache: A block layer cache") leads to the
following static checker warning:
./drivers/md/bcache/super.c:770 bcache_device_free()
warn: variable dereferenced before check 'd->disk' (see line 766)
drivers/md/bcache/super.c
762 static void bcache_device_free(struct bcache_device *d)
763 {
764 lockdep_assert_held(&bch_register_lock);
765
766 pr_info("%s stopped", d->disk->disk_name);
^^^^^^^^^
Unchecked dereference.
767
768 if (d->c)
769 bcache_device_detach(d);
770 if (d->disk && d->disk->flags & GENHD_FL_UP)
^^^^^^^
Check too late.
771 del_gendisk(d->disk);
772 if (d->disk && d->disk->queue)
773 blk_cleanup_queue(d->disk->queue);
774 if (d->disk) {
775 ida_simple_remove(&bcache_device_idx,
776 first_minor_to_idx(d->disk->first_minor));
777 put_disk(d->disk);
778 }
779
It is not 100% sure that the gendisk struct of bcache device will always
be there, the warning makes sense when there is problem in block core.
This patch tries to remove the static checking warning by checking
d->disk to avoid NULL pointer deferences.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Coly Li <colyli@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sudip Mukherjee [Wed, 16 Oct 2019 14:45:39 +0000 (15:45 +0100)]
parport: load lowlevel driver if ports not found
[ Upstream commit
231ec2f24dad18d021b361045bbd618ba62a274e ]
Usually all the distro will load the parport low level driver as part
of their initialization. But we can get into a situation where all the
parallel port drivers are built as module and we unload all the modules
at a later time. Then if we just do "modprobe parport" it will only
load the parport module and will not load the low level driver which
will actually register the ports. So, check the bus if there is any
parport registered, if not, load the low level driver.
We can get into the above situation with all distro but only Suse has
setup the alias for "parport_lowlevel" and so it only works in Suse.
Users of Debian based distro will need to load the lowlevel module
manually.
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Link: https://lore.kernel.org/r/20191016144540.18810-3-sudipm.mukherjee@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eduard Hasenleithner [Tue, 12 Nov 2019 20:55:01 +0000 (21:55 +0100)]
nvme: Discard workaround for non-conformant devices
[ Upstream commit
530436c45ef2e446c12538a400e465929a0b3ade ]
Users observe IOMMU related errors when performing discard on nvme from
non-compliant nvme devices reading beyond the end of the DMA mapped
ranges to discard.
Two different variants of this behavior have been observed: SM22XX
controllers round up the read size to a multiple of 512 bytes, and Phison
E12 unconditionally reads the maximum discard size allowed by the spec
(256 segments or 4kB).
Make nvme_setup_discard unconditionally allocate the maximum DSM buffer
so the driver DMA maps a memory range that will always succeed.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=202665
Signed-off-by: Eduard Hasenleithner <eduard@hasenleithner.at>
[changelog, use existing define, kernel coding style]
Signed-off-by: Keith Busch <kbusch@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ilya Leoshkevich [Thu, 31 Oct 2019 17:25:16 +0000 (18:25 +0100)]
s390/disassembler: don't hide instruction addresses
[ Upstream commit
544f1d62e3e6c6e6d17a5e56f6139208acb5ff46 ]
Due to kptr_restrict, JITted BPF code is now displayed like this:
000000000b6ed1b2:
ebdff0800024 stmg %r13,%r15,128(%r15)
000000004cde2ba0:
41d0f040 la %r13,64(%r15)
00000000fbad41b0:
a7fbffa0 aghi %r15,-96
Leaking kernel addresses to dmesg is not a concern in this case, because
this happens only when JIT debugging is explicitly activated, which only
root can do.
Use %px in this particular instance, and also to print an instruction
address in show_code and PCREL (e.g. brasl) arguments in print_insn.
While at present functionally equivalent to %016lx, %px is recommended
by Documentation/core-api/printk-formats.rst for such cases.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yu-Hsuan Hsu [Mon, 23 Sep 2019 16:29:40 +0000 (00:29 +0800)]
ASoC: Intel: kbl_rt5663_rt5514_max98927: Add dmic format constraint
[ Upstream commit
e2db787bdcb4f2722ecf410168f0583764634e45 ]
On KBL platform, the microphone is attached to external codec(rt5514)
instead of PCH. However, TDM slot between PCH and codec is 16 bits only.
In order to avoid setting wrong format, we should add a constraint to
force to use 16 bits format forever.
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190923162940.199580-1-yuhsuan@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Popa [Wed, 6 Nov 2019 09:47:21 +0000 (11:47 +0200)]
iio: dac: ad5446: Add support for new AD5600 DAC
[ Upstream commit
6376cbe549fffb378403cee78efd26b8a2c8e450 ]
The AD5600 is a single channel, 16-bit resolution, voltage output digital
to analog converter (DAC). The AD5600 uses a 3-wire SPI interface. It is
part of the AD5541 family of DACs.
The ad5446 IIO driver implements support for some of these DACs (in the
AD5441 family), so the change is a simple entry in this driver.
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5600.pdf
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Zhang [Wed, 6 Nov 2019 01:13:30 +0000 (17:13 -0800)]
ASoC: rt5677: Mark reg RT5677_PWR_ANLG2 as volatile
[ Upstream commit
eabf424f7b60246c76dcb0ea6f1e83ef9abbeaa6 ]
The codec dies when RT5677_PWR_ANLG2(MX-64h) is set to 0xACE1
while it's streaming audio over SPI. The DSP firmware turns
on PLL2 (MX-64 bit 8) when SPI streaming starts. However regmap
does not believe that register can change by itself. When
BST1 (bit 15) is turned on with regmap_update_bits(), it doesn't
read the register first before write, so PLL2 power bit is
cleared by accident.
Marking MX-64h as volatile in regmap solved the issue.
Signed-off-by: Ben Zhang <benzh@chromium.org>
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Link: https://lore.kernel.org/r/20191106011335.223061-6-cujomalainey@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Sat, 9 Nov 2019 08:09:43 +0000 (16:09 +0800)]
spi: pxa2xx: Add missed security checks
[ Upstream commit
5eb263ef08b5014cfc2539a838f39d2fd3531423 ]
pxa2xx_spi_init_pdata misses checks for devm_clk_get and
platform_get_irq.
Add checks for them to fix the bugs.
Since ssp->clk and ssp->irq are used in probe, they are mandatory here.
So we cannot use _optional() for devm_clk_get and platform_get_irq.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Link: https://lore.kernel.org/r/20191109080943.30428-1-hslester96@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Richter [Wed, 6 Nov 2019 09:33:23 +0000 (09:33 +0000)]
EDAC/ghes: Fix grain calculation
[ Upstream commit
7088e29e0423d3195e09079b4f849ec4837e5a75 ]
The current code to convert a physical address mask to a grain
(defined as granularity in bytes) is:
e->grain = ~(mem_err->physical_addr_mask & ~PAGE_MASK);
This is broken in several ways:
1) It calculates to wrong grain values. E.g., a physical address mask
of ~0xfff should give a grain of 0x1000. Without considering
PAGE_MASK, there is an off-by-one. Things are worse when also
filtering it with ~PAGE_MASK. This will calculate to a grain with the
upper bits set. In the example it even calculates to ~0.
2) The grain does not depend on and is unrelated to the kernel's
page-size. The page-size only matters when unmapping memory in
memory_failure(). Smaller grains are wrongly rounded up to the
page-size, on architectures with a configurable page-size (e.g. arm64)
this could round up to the even bigger page-size of the hypervisor.
Fix this with:
e->grain = ~mem_err->physical_addr_mask + 1;
The grain_bits are defined as:
grain = 1 << grain_bits;
Change also the grain_bits calculation accordingly, it is the same
formula as in edac_mc.c now and the code can be unified.
The value in ->physical_addr_mask coming from firmware is assumed to
be contiguous, but this is not sanity-checked. However, in case the
mask is non-contiguous, a conversion to grain_bits effectively
converts the grain bit mask to a power of 2 by rounding it up.
Suggested-by: James Morse <james.morse@arm.com>
Signed-off-by: Robert Richter <rrichter@marvell.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20191106093239.25517-11-rrichter@marvell.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Sun, 10 Nov 2019 06:28:15 +0000 (07:28 +0100)]
media: si470x-i2c: add missed operations in remove
[ Upstream commit
2df200ab234a86836a8879a05a8007d6b884eb14 ]
The driver misses calling v4l2_ctrl_handler_free and
v4l2_device_unregister in remove like what is done in probe failure.
Add the calls to fix it.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mitch Williams [Wed, 6 Nov 2019 10:05:36 +0000 (02:05 -0800)]
ice: delay less
[ Upstream commit
88bb432a55de8ae62106305083a8bfbb23b01ad2 ]
Shorten the delay for SQ responses, but increase the number of loops.
Max delay time is unchanged, but some operations complete much more
quickly.
In the process, add a new define to make the delay count and delay time
more explicit. Add comments to make things more explicit.
This fixes a problem with VF resets failing on with many VFs.
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Herbert Xu [Mon, 28 Oct 2019 07:39:07 +0000 (15:39 +0800)]
crypto: atmel - Fix authenc support when it is set to m
[ Upstream commit
1520c72596dde7f22b8bd6bed3ef7df2b8b7ef39 ]
As it is if CONFIG_CRYPTO_DEV_ATMEL_AUTHENC is set to m it is in
effect disabled. This patch fixes it by using IS_ENABLED instead
of ifdef.
Fixes:
89a82ef87e01 ("crypto: atmel-authenc - add support to...")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pierre-Louis Bossart [Tue, 22 Oct 2019 23:29:48 +0000 (18:29 -0500)]
soundwire: intel: fix PDI/stream mapping for Bulk
[ Upstream commit
c134f914e9f55b7817e2bae625ec0e5f1379f7cd ]
The previous formula is incorrect for PDI0/1, the mapping is not
linear but has a discontinuity between PDI1 and PDI2.
This change has no effect on PCM PDIs (same mapping).
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191022232948.17156-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mike Isely [Wed, 6 Nov 2019 11:11:14 +0000 (12:11 +0100)]
media: pvrusb2: Fix oops on tear-down when radio support is not present
[ Upstream commit
7f404ae9cf2a285f73b3c18ab9303d54b7a3d8e1 ]
In some device configurations there's no radio or radio support in the
driver. That's OK, as the driver sets itself up accordingly. However
on tear-down in these caes it's still trying to tear down radio
related context when there isn't anything there, leading to
dereferences through a null pointer and chaos follows.
How this bug survived unfixed for 11 years in the pvrusb2 driver is a
mystery to me.
[hverkuil: fix two checkpatch warnings]
Signed-off-by: Mike Isely <isely@pobox.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrew Jeffery [Fri, 8 Nov 2019 05:19:39 +0000 (15:49 +1030)]
fsi: core: Fix small accesses and unaligned offsets via sysfs
[ Upstream commit
9f4c2b516b4f031e3cd0e45957f4150b3c1a083d ]
Subtracting the offset delta from four-byte alignment lead to wrapping
of the requested length where `count` is less than `off`. Generalise the
length handling to enable and optimise aligned access sizes for all
offset and size combinations. The new formula produces the following
results for given offset and count values:
offset count | length
--------------+-------
0 1 | 1
0 2 | 2
0 3 | 2
0 4 | 4
0 5 | 4
1 1 | 1
1 2 | 1
1 3 | 1
1 4 | 1
1 5 | 1
2 1 | 1
2 2 | 2
2 3 | 2
2 4 | 2
2 5 | 2
3 1 | 1
3 2 | 1
3 3 | 1
3 4 | 1
3 5 | 1
We might need something like this for the cfam chardevs as well, for
example we don't currently implement any alignment restrictions /
handling in the hardware master driver.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20191108051945.7109-6-joel@jms.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miaoqing Pan [Wed, 6 Nov 2019 18:04:37 +0000 (20:04 +0200)]
ath10k: fix get invalid tx rate for Mesh metric
[ Upstream commit
05a11003a56507023f18d3249a4d4d119c0a3e9c ]
ath10k does not provide transmit rate info per MSDU
in tx completion, mark that as -1 so mac80211
will ignore the rates. This fixes mac80211 update Mesh
link metric with invalid transmit rate info.
Tested HW: QCA9984
Tested FW: 10.4-3.9.0.2-00035
Signed-off-by: Hou Bao Hou <houbao@codeaurora.org>
Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Wed, 30 Oct 2019 07:09:30 +0000 (16:09 +0900)]
perf probe: Filter out instances except for inlined subroutine and subprogram
[ Upstream commit
da6cb952a89efe24bb76c4971370d485737a2d85 ]
Filter out instances except for inlined_subroutine and subprogram DIE in
die_walk_instances() and die_is_func_instance().
This fixes an issue that perf probe sets some probes on calling address
instead of a target function itself.
When perf probe walks on instances of an abstruct origin (a kind of
function prototype of inlined function), die_walk_instances() can also
pass a GNU_call_site (a GNU extension for call site) to callback. Since
it is not an inlined instance of target function, we have to filter out
when searching a probe point.
Without this patch, perf probe sets probes on call site address too.This
can happen on some function which is marked "inlined", but has actual
symbol. (I'm not sure why GCC mark it "inlined"):
# perf probe -D vfs_read
p:probe/vfs_read _text+2500017
p:probe/vfs_read_1 _text+2499468
p:probe/vfs_read_2 _text+2499563
p:probe/vfs_read_3 _text+2498876
p:probe/vfs_read_4 _text+2498512
p:probe/vfs_read_5 _text+2498627
With this patch:
Slightly different results, similar tho:
# perf probe -D vfs_read
p:probe/vfs_read _text+2498512
Committer testing:
# uname -a
Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Before:
# perf probe -D vfs_read
p:probe/vfs_read _text+3131557
p:probe/vfs_read_1 _text+3130975
p:probe/vfs_read_2 _text+3131047
p:probe/vfs_read_3 _text+3130380
p:probe/vfs_read_4 _text+3130000
# uname -a
Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
#
After:
# perf probe -D vfs_read
p:probe/vfs_read _text+3130000
#
Fixes:
db0d2c6420ee ("perf probe: Search concrete out-of-line instances")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157241937063.32002.11024544873990816590.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Wed, 30 Oct 2019 07:09:21 +0000 (16:09 +0900)]
perf probe: Skip end-of-sequence and non statement lines
[ Upstream commit
f4d99bdfd124823a81878b44b5e8750b97f73902 ]
Skip end-of-sequence and non-statement lines while walking through lines
list.
The "end-of-sequence" line information means:
"the current address is that of the first byte after the
end of a sequence of target machine instructions."
(DWARF version 4 spec 6.2.2)
This actually means out of scope and we can not probe on it.
On the other hand, the statement lines (is_stmt) means:
"the current instruction is a recommended breakpoint location.
A recommended breakpoint location is intended to “represent”
a line, a statement and/or a semantically distinct subpart
of a statement."
(DWARF version 4 spec 6.2.2)
So, non-statement line info also should be skipped.
These can reduce unneeded probe points and also avoid an error.
E.g. without this patch:
# perf probe -a "clear_tasks_mm_cpumask:1"
Added new events:
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:1)
probe:clear_tasks_mm_cpumask_2 (on clear_tasks_mm_cpumask:1)
probe:clear_tasks_mm_cpumask_3 (on clear_tasks_mm_cpumask:1)
probe:clear_tasks_mm_cpumask_4 (on clear_tasks_mm_cpumask:1)
You can now use it in all perf tools, such as:
perf record -e probe:clear_tasks_mm_cpumask_4 -aR sleep 1
#
This puts 5 probes on one line, but acutally it's not inlined function.
This is because there are many non statement instructions at the
function prologue.
With this patch:
# perf probe -a "clear_tasks_mm_cpumask:1"
Added new event:
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
You can now use it in all perf tools, such as:
perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1
#
Now perf-probe skips unneeded addresses.
Committer testing:
Slightly different results, but similar:
Before:
# uname -a
Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
#
# perf probe -a "clear_tasks_mm_cpumask:1"
Added new events:
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:1)
probe:clear_tasks_mm_cpumask_2 (on clear_tasks_mm_cpumask:1)
You can now use it in all perf tools, such as:
perf record -e probe:clear_tasks_mm_cpumask_2 -aR sleep 1
#
After:
# perf probe -a "clear_tasks_mm_cpumask:1"
Added new event:
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1)
You can now use it in all perf tools, such as:
perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1
# perf probe -l
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c)
#
Fixes:
4cc9cec636e7 ("perf probe: Introduce lines walker interface")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157241936090.32002.12156347518596111660.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Wed, 30 Oct 2019 07:09:40 +0000 (16:09 +0900)]
perf probe: Fix to show calling lines of inlined functions
[ Upstream commit
86c0bf8539e7f46d91bd105e55eda96e0064caef ]
Fix to show calling lines of inlined functions (where an inline function
is called).
die_walk_lines() filtered out the lines inside inlined functions based
on the address. However this also filtered out the lines which call
those inlined functions from the target function.
To solve this issue, check the call_file and call_line attributes and do
not filter out if it matches to the line information.
Without this fix, perf probe -L doesn't show some lines correctly.
(don't see the lines after 17)
# perf probe -L vfs_read
<vfs_read@/home/mhiramat/ksrc/linux/fs/read_write.c:0>
0 ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
1 {
2 ssize_t ret;
4 if (!(file->f_mode & FMODE_READ))
return -EBADF;
6 if (!(file->f_mode & FMODE_CAN_READ))
return -EINVAL;
8 if (unlikely(!access_ok(buf, count)))
return -EFAULT;
11 ret = rw_verify_area(READ, file, pos, count);
12 if (!ret) {
13 if (count > MAX_RW_COUNT)
count = MAX_RW_COUNT;
15 ret = __vfs_read(file, buf, count, pos);
16 if (ret > 0) {
fsnotify_access(file);
add_rchar(current, ret);
}
With this fix:
# perf probe -L vfs_read
<vfs_read@/home/mhiramat/ksrc/linux/fs/read_write.c:0>
0 ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
1 {
2 ssize_t ret;
4 if (!(file->f_mode & FMODE_READ))
return -EBADF;
6 if (!(file->f_mode & FMODE_CAN_READ))
return -EINVAL;
8 if (unlikely(!access_ok(buf, count)))
return -EFAULT;
11 ret = rw_verify_area(READ, file, pos, count);
12 if (!ret) {
13 if (count > MAX_RW_COUNT)
count = MAX_RW_COUNT;
15 ret = __vfs_read(file, buf, count, pos);
16 if (ret > 0) {
17 fsnotify_access(file);
18 add_rchar(current, ret);
}
20 inc_syscr(current);
}
Fixes:
4cc9cec636e7 ("perf probe: Introduce lines walker interface")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157241937995.32002.17899884017011512577.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Tue, 5 Nov 2019 00:16:49 +0000 (09:16 +0900)]
perf probe: Return a better scope DIE if there is no best scope
[ Upstream commit
c701636aeec4c173208697d68da6e4271125564b ]
Make find_best_scope() returns innermost DIE at given address if there
is no best matched scope DIE. Since Gcc sometimes generates intuitively
strange line info which is out of inlined function address range, we
need this fixup.
Without this, sometimes perf probe failed to probe on a line inside an
inlined function:
# perf probe -D ksys_open:3
Failed to find scope of probe point.
Error: Failed to add events.
With this fix, 'perf probe' can probe it:
# perf probe -D ksys_open:3
p:probe/ksys_open _text+
25707308
p:probe/ksys_open_1 _text+
25710596
p:probe/ksys_open_2 _text+
25711114
p:probe/ksys_open_3 _text+
25711343
p:probe/ksys_open_4 _text+
25714058
p:probe/ksys_open_5 _text+2819653
p:probe/ksys_open_6 _text+2819701
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
Link: http://lore.kernel.org/lkml/157291300887.19771.14936015360963292236.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Wed, 30 Oct 2019 07:09:49 +0000 (16:09 +0900)]
perf probe: Skip overlapped location on searching variables
[ Upstream commit
dee36a2abb67c175265d49b9a8c7dfa564463d9a ]
Since debuginfo__find_probes() callback function can be called with the
location which already passed, the callback function must filter out
such overlapped locations.
add_probe_trace_event() has already done it by commit
1a375ae7659a
("perf probe: Skip same probe address for a given line"), but
add_available_vars() doesn't. Thus perf probe -v shows same address
repeatedly as below:
# perf probe -V vfs_read:18
Available variables at vfs_read:18
@<vfs_read+217>
char* buf
loff_t* pos
ssize_t ret
struct file* file
@<vfs_read+217>
char* buf
loff_t* pos
ssize_t ret
struct file* file
@<vfs_read+226>
char* buf
loff_t* pos
ssize_t ret
struct file* file
With this fix, perf probe -V shows it correctly:
# perf probe -V vfs_read:18
Available variables at vfs_read:18
@<vfs_read+217>
char* buf
loff_t* pos
ssize_t ret
struct file* file
@<vfs_read+226>
char* buf
loff_t* pos
ssize_t ret
struct file* file
Fixes:
cf6eb489e5c0 ("perf probe: Show accessible local variables")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157241938927.32002.4026859017790562751.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ian Rogers [Wed, 30 Oct 2019 22:34:46 +0000 (15:34 -0700)]
perf parse: If pmu configuration fails free terms
[ Upstream commit
38f2c4226e6bc3e8c41c318242821ba5dc825aba ]
Avoid a memory leak when the configuration fails.
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Cc: clang-built-linux@googlegroups.com
Cc: netdev@vger.kernel.org
Link: http://lore.kernel.org/lkml/20191030223448.12930-9-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jason Gunthorpe [Mon, 28 Oct 2019 20:10:25 +0000 (17:10 -0300)]
xen/gntdev: Use select for DMA_SHARED_BUFFER
[ Upstream commit
fa6614d8ef13c63aac52ad7c07c5e69ce4aba3dd ]
DMA_SHARED_BUFFER can not be enabled by the user (it represents a library
set in the kernel). The kconfig convention is to use select for such
symbols so they are turned on implicitly when the user enables a kconfig
that needs them.
Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable.
Fixes:
932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI")
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xenproject.org
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pan Bian [Wed, 6 Nov 2019 09:14:45 +0000 (17:14 +0800)]
drm/amdgpu: fix potential double drop fence reference
[ Upstream commit
946ab8db6953535a3a88c957db8328beacdfed9d ]
The object fence is not set to NULL after its reference is dropped. As a
result, its reference may be dropped again if error occurs after that,
which may lead to a use after free bug. To avoid the issue, fence is
explicitly set to NULL after dropping its reference.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hawking Zhang [Mon, 4 Nov 2019 08:20:06 +0000 (16:20 +0800)]
drm/amdgpu: disallow direct upload save restore list from gfx driver
[ Upstream commit
58f46d4b65021083ef4b4d49c6e2c58e5783f626 ]
Direct uploading save/restore list via mmio register writes breaks the security
policy. Instead, the driver should pass s&r list to psp.
For all the ASICs that use rlc v2_1 headers, the driver actually upload s&r list
twice, in non-psp ucode front door loading phase and gfx pg initialization phase.
The latter is not allowed.
VG12 is the only exception where the driver still keeps legacy approach for S&R
list uploading. In theory, this can be elimnated if we have valid srcntl ucode
for VG12.
Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com>
Reviewed-by: Candice Li <Candice.Li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ian Rogers [Fri, 25 Oct 2019 18:08:22 +0000 (11:08 -0700)]
perf tools: Splice events onto evlist even on error
[ Upstream commit
8e8714c3d157568b7a769917a5e05573bbaf5af0 ]
If event parsing fails the event list is leaked, instead splice the list
onto the out result and let the caller cleanup.
An example input for parse_events found by libFuzzer that reproduces
this memory leak is 'm{'.
Signed-off-by: Ian Rogers <irogers@google.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Jin Yao <yao.jin@linux.intel.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: bpf@vger.kernel.org
Cc: clang-built-linux@googlegroups.com
Cc: netdev@vger.kernel.org
Link: http://lore.kernel.org/lkml/20191025180827.191916-5-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Fri, 25 Oct 2019 08:46:34 +0000 (17:46 +0900)]
perf probe: Fix to probe a function which has no entry pc
[ Upstream commit
5d16dbcc311d91267ddb45c6da4f187be320ecee ]
Fix 'perf probe' to probe a function which has no entry pc or low pc but
only has ranges attribute.
probe_point_search_cb() uses dwarf_entrypc() to get the probe address,
but that doesn't work for the function DIE which has only ranges
attribute. Use die_entrypc() instead.
Without this fix:
# perf probe -k ../build-x86_64/vmlinux -D clear_tasks_mm_cpumask:0
Probe point 'clear_tasks_mm_cpumask' not found.
Error: Failed to add events.
With this:
# perf probe -k ../build-x86_64/vmlinux -D clear_tasks_mm_cpumask:0
p:probe/clear_tasks_mm_cpumask clear_tasks_mm_cpumask+0
Committer testing:
Before:
[root@quaco ~]# perf probe clear_tasks_mm_cpumask:0
Probe point 'clear_tasks_mm_cpumask' not found.
Error: Failed to add events.
[root@quaco ~]#
After:
[root@quaco ~]# perf probe clear_tasks_mm_cpumask:0
Added new event:
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask)
You can now use it in all perf tools, such as:
perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1
[root@quaco ~]#
Using it with 'perf trace':
[root@quaco ~]# perf trace -e probe:clear_tasks_mm_cpumask
Doesn't seem to be used in x86_64:
$ find . -name "*.c" | xargs grep clear_tasks_mm_cpumask
./kernel/cpu.c: * clear_tasks_mm_cpumask - Safely clear tasks' mm_cpumask for a CPU
./kernel/cpu.c:void clear_tasks_mm_cpumask(int cpu)
./arch/xtensa/kernel/smp.c: clear_tasks_mm_cpumask(cpu);
./arch/csky/kernel/smp.c: clear_tasks_mm_cpumask(cpu);
./arch/sh/kernel/smp.c: clear_tasks_mm_cpumask(cpu);
./arch/arm/kernel/smp.c: clear_tasks_mm_cpumask(cpu);
./arch/powerpc/mm/nohash/mmu_context.c: clear_tasks_mm_cpumask(cpu);
$ find . -name "*.h" | xargs grep clear_tasks_mm_cpumask
./include/linux/cpu.h:void clear_tasks_mm_cpumask(int cpu);
$ find . -name "*.S" | xargs grep clear_tasks_mm_cpumask
$
Fixes:
e1ecbbc3fa83 ("perf probe: Fix to handle optimized not-inlined functions")
Reported-by: Arnaldo Carvalho de Melo <acme@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157199319438.8075.4695576954550638618.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Clark [Mon, 28 Oct 2019 11:34:01 +0000 (11:34 +0000)]
libsubcmd: Use -O0 with DEBUG=1
[ Upstream commit
22bd8f1b5a1dd168ba4eba27cb17643a11012f5d ]
When a 'make DEBUG=1' build is done, the command parser is still built
with -O6 and is hard to step through, fix it making it use -O0 in that
case.
Signed-off-by: James Clark <james.clark@arm.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: nd <nd@arm.com>
Link: http://lore.kernel.org/lkml/20191028113340.4282-1-james.clark@arm.com
[ split from a larger patch ]
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Fri, 25 Oct 2019 08:47:01 +0000 (17:47 +0900)]
perf probe: Fix to show inlined function callsite without entry_pc
[ Upstream commit
18e21eb671dc87a4f0546ba505a89ea93598a634 ]
Fix 'perf probe --line' option to show inlined function callsite lines
even if the function DIE has only ranges.
Without this:
# perf probe -L amd_put_event_constraints
...
2 {
3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
__amd_put_nb_event_constraints(cpuc, event);
5 }
With this patch:
# perf probe -L amd_put_event_constraints
...
2 {
3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
4 __amd_put_nb_event_constraints(cpuc, event);
5 }
Committer testing:
Before:
[root@quaco ~]# perf probe -L amd_put_event_constraints
<amd_put_event_constraints@/usr/src/debug/kernel-5.2.fc30/linux-5.2.18-200.fc30.x86_64/arch/x86/events/amd/core.c:0>
0 static void amd_put_event_constraints(struct cpu_hw_events *cpuc,
struct perf_event *event)
2 {
3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
__amd_put_nb_event_constraints(cpuc, event);
5 }
PMU_FORMAT_ATTR(event, "config:0-7,32-35");
PMU_FORMAT_ATTR(umask, "config:8-15" );
[root@quaco ~]#
After:
[root@quaco ~]# perf probe -L amd_put_event_constraints
<amd_put_event_constraints@/usr/src/debug/kernel-5.2.fc30/linux-5.2.18-200.fc30.x86_64/arch/x86/events/amd/core.c:0>
0 static void amd_put_event_constraints(struct cpu_hw_events *cpuc,
struct perf_event *event)
2 {
3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw))
4 __amd_put_nb_event_constraints(cpuc, event);
5 }
PMU_FORMAT_ATTR(event, "config:0-7,32-35");
PMU_FORMAT_ATTR(umask, "config:8-15" );
[root@quaco ~]# perf probe amd_put_event_constraints:4
Added new event:
probe:amd_put_event_constraints (on amd_put_event_constraints:4)
You can now use it in all perf tools, such as:
perf record -e probe:amd_put_event_constraints -aR sleep 1
[root@quaco ~]#
[root@quaco ~]# perf probe -l
probe:amd_put_event_constraints (on amd_put_event_constraints:4@arch/x86/events/amd/core.c)
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c)
[root@quaco ~]#
Using it:
[root@quaco ~]# perf trace -e probe:*
^C[root@quaco ~]#
Ok, Intel system here... :-)
Fixes:
4cc9cec636e7 ("perf probe: Introduce lines walker interface")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157199322107.8075.12659099000567865708.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Fri, 25 Oct 2019 08:47:10 +0000 (17:47 +0900)]
perf probe: Fix to show ranges of variables in functions without entry_pc
[ Upstream commit
af04dd2f8ebaa8fbd46f698714acbf43da14da45 ]
Fix to show ranges of variables (--range and --vars option) in functions
which DIE has only ranges but no entry_pc attribute.
Without this fix:
# perf probe --range -V clear_tasks_mm_cpumask
Available variables at clear_tasks_mm_cpumask
@<clear_tasks_mm_cpumask+0>
(No matched variables)
With this fix:
# perf probe --range -V clear_tasks_mm_cpumask
Available variables at clear_tasks_mm_cpumask
@<clear_tasks_mm_cpumask+0>
[VAL] int cpu @<clear_tasks_mm_cpumask+[0-35,317-317,2052-2059]>
Committer testing:
Before:
[root@quaco ~]# perf probe --range -V clear_tasks_mm_cpumask
Available variables at clear_tasks_mm_cpumask
@<clear_tasks_mm_cpumask+0>
(No matched variables)
[root@quaco ~]#
After:
[root@quaco ~]# perf probe --range -V clear_tasks_mm_cpumask
Available variables at clear_tasks_mm_cpumask
@<clear_tasks_mm_cpumask+0>
[VAL] int cpu @<clear_tasks_mm_cpumask+[0-23,23-105,105-106,106-106,1843-1850,1850-1862]>
[root@quaco ~]#
Using it:
[root@quaco ~]# perf probe clear_tasks_mm_cpumask cpu
Added new event:
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask with cpu)
You can now use it in all perf tools, such as:
perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1
[root@quaco ~]# perf probe -l
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c with cpu)
[root@quaco ~]#
[root@quaco ~]# perf trace -e probe:*cpumask
^C[root@quaco ~]#
Fixes:
349e8d261131 ("perf probe: Add --range option to show a variable's location range")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157199323018.8075.8179744380479673672.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Fri, 25 Oct 2019 08:46:43 +0000 (17:46 +0900)]
perf probe: Fix to probe an inline function which has no entry pc
[ Upstream commit
eb6933b29d20bf2c3053883d409a53f462c1a3ac ]
Fix perf probe to probe an inlne function which has no entry pc
or low pc but only has ranges attribute.
This seems very rare case, but I could find a few examples, as
same as probe_point_search_cb(), use die_entrypc() to get the
entry address in probe_point_inline_cb() too.
Without this patch:
# perf probe -D __amd_put_nb_event_constraints
Failed to get entry address of __amd_put_nb_event_constraints.
Probe point '__amd_put_nb_event_constraints' not found.
Error: Failed to add events.
With this patch:
# perf probe -D __amd_put_nb_event_constraints
p:probe/__amd_put_nb_event_constraints amd_put_event_constraints+43
Committer testing:
Before:
[root@quaco ~]# perf probe -D __amd_put_nb_event_constraints
Failed to get entry address of __amd_put_nb_event_constraints.
Probe point '__amd_put_nb_event_constraints' not found.
Error: Failed to add events.
[root@quaco ~]#
After:
[root@quaco ~]# perf probe -D __amd_put_nb_event_constraints
p:probe/__amd_put_nb_event_constraints _text+33789
[root@quaco ~]#
Fixes:
4ea42b181434 ("perf: Add perf probe subcommand, a kprobe-event setup helper")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157199320336.8075.16189530425277588587.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Thu, 24 Oct 2019 09:12:45 +0000 (18:12 +0900)]
perf probe: Walk function lines in lexical blocks
[ Upstream commit
acb6a7047ac2146b723fef69ee1ab6b7143546bf ]
Since some inlined functions are in lexical blocks of given function, we
have to recursively walk through the DIE tree. Without this fix,
perf-probe -L can miss the inlined functions which is in a lexical block
(like if (..) { func() } case.)
However, even though, to walk the lines in a given function, we don't
need to follow the children DIE of inlined functions because those do
not have any lines in the specified function.
We need to walk though whole trees only if we walk all lines in a given
file, because an inlined function can include another inlined function
in the same file.
Fixes:
b0e9cb2802d4 ("perf probe: Fix to search nested inlined functions in CU")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157190836514.1859.15996864849678136353.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunfeng Ye [Wed, 16 Oct 2019 13:50:17 +0000 (21:50 +0800)]
perf jevents: Fix resource leak in process_mapfile() and main()
[ Upstream commit
1785fbb73896dbd9d27a406f0d73047df42db710 ]
There are memory leaks and file descriptor resource leaks in
process_mapfile() and main().
Fix this by adding free(), fclose() and free_arch_std_events() on the
error paths.
Fixes:
80eeb67fe577 ("perf jevents: Program to convert JSON file")
Fixes:
3f056b66647b ("perf jevents: Make build fail on JSON parse error")
Fixes:
e9d32c1bf0cd ("perf vendor events: Add support for arch standard events")
Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Feilong Lin <linfeilong@huawei.com>
Cc: Hu Shiyuan <hushiyuan@huawei.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Luke Mujica <lukemujica@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Link: http://lore.kernel.org/lkml/d7907042-ec9c-2bef-25b4-810e14602f89@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Fri, 25 Oct 2019 08:46:52 +0000 (17:46 +0900)]
perf probe: Fix to list probe event with correct line number
[ Upstream commit
3895534dd78f0fd4d3f9e05ee52b9cdd444a743e ]
Since debuginfo__find_probe_point() uses dwarf_entrypc() for finding the
entry address of the function on which a probe is, it will fail when the
function DIE has only ranges attribute.
To fix this issue, use die_entrypc() instead of dwarf_entrypc().
Without this fix, perf probe -l shows incorrect offset:
# perf probe -l
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask+
18446744071579263632@work/linux/linux/kernel/cpu.c)
probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask+
18446744071579263752@work/linux/linux/kernel/cpu.c)
With this:
# perf probe -l
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@work/linux/linux/kernel/cpu.c)
probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:21@work/linux/linux/kernel/cpu.c)
Committer testing:
Before:
[root@quaco ~]# perf probe -l
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask+
18446744071579765152@kernel/cpu.c)
[root@quaco ~]#
After:
[root@quaco ~]# perf probe -l
probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c)
[root@quaco ~]#
Fixes:
1d46ea2a6a40 ("perf probe: Fix listing incorrect line number with inline function")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157199321227.8075.14655572419136993015.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Masami Hiramatsu [Thu, 24 Oct 2019 09:12:36 +0000 (18:12 +0900)]
perf probe: Fix to find range-only function instance
[ Upstream commit
b77afa1f810f37bd8a36cb1318178dfe2d7af6b6 ]
Fix die_is_func_instance() to find range-only function instance.
In some case, a function instance can be made without any low PC or
entry PC, but only with address ranges by optimization. (e.g. cold text
partially in "text.unlikely" section) To find such function instance, we
have to check the range attribute too.
Fixes:
e1ecbbc3fa83 ("perf probe: Fix to handle optimized not-inlined functions")
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/157190835669.1859.8368628035930950596.stgit@devnote2
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ping-Ke Shih [Tue, 5 Nov 2019 02:18:38 +0000 (10:18 +0800)]
rtlwifi: fix memory leak in rtl92c_set_fw_rsvdpagepkt()
[ Upstream commit
5174f1e41074b5186608badc2e89441d021e8c08 ]
This leak was found by testing the EDIMAX EW-7612 on Raspberry Pi 3B+ with
Linux 5.4-rc5 (multi_v7_defconfig + rtlwifi + kmemleak) and noticed a
single memory leak during probe:
unreferenced object 0xec13ee40 (size 176):
comm "kworker/u8:1", pid 36, jiffies
4294939321 (age 5580.790s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
fc1bbb3e>] __netdev_alloc_skb+0x9c/0x164
[<
863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common]
[<
9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu]
[<
116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi]
[<
8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211]
[<
d4061e86>] ieee80211_assoc_success+0x934/0x1798 [mac80211]
[<
e55adb56>] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211]
[<
5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211]
[<
d91091c6>] ieee80211_iface_work+0x208/0x318 [mac80211]
[<
ac5fcae4>] process_one_work+0x22c/0x564
[<
f5e6d3b6>] worker_thread+0x44/0x5d8
[<
82c7b073>] kthread+0x150/0x154
[<
b43e1b7d>] ret_from_fork+0x14/0x2c
[<
794dff30>] 0x0
It is because 8192cu doesn't implement usb_cmd_send_packet(), and this
patch just frees the skb within the function to resolve memleak problem
by now. Since 8192cu doesn't turn on fwctrl_lps that needs to download
command packet for firmware via the function, applying this patch doesn't
affect driver behavior.
Reported-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Wed, 6 Nov 2019 15:42:57 +0000 (16:42 +0100)]
ALSA: timer: Limit max amount of slave instances
[ Upstream commit
fdea53fe5de532969a332d6e5e727f2ad8bf084d ]
The fuzzer tries to open the timer instances as much as possible, and
this may cause a system hiccup easily. We've already introduced the
cap for the max number of available instances for the h/w timers, and
we should put such a limit also to the slave timers, too.
This patch introduces the limit to the multiple opened slave timers.
The upper limit is hard-coded to 1000 for now, which should suffice
for any practical usages up to now.
Link: https://lore.kernel.org/r/20191106154257.5853-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pan Bian [Wed, 6 Nov 2019 02:36:09 +0000 (10:36 +0800)]
spi: img-spfi: fix potential double release
[ Upstream commit
e9a8ba9769a0e354341bc6cc01b98aadcea1dfe9 ]
The channels spfi->tx_ch and spfi->rx_ch are not set to NULL after they
are released. As a result, they will be released again, either on the
error handling branch in the same function or in the corresponding
remove function, i.e. img_spfi_remove(). This patch fixes the bug by
setting the two members to NULL.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Link: https://lore.kernel.org/r/1573007769-20131-1-git-send-email-bianpan2016@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Manish Chopra [Tue, 5 Nov 2019 05:51:11 +0000 (21:51 -0800)]
bnx2x: Fix PF-VF communication over multi-cos queues.
[ Upstream commit
dc5a3d79c345871439ffe72550b604fcde9770e1 ]
PF driver doesn't enable tx-switching for all cos queues/clients,
which causes packets drop from PF to VF. Fix this by enabling
tx-switching on all cos queues/clients.
Signed-off-by: Manish Chopra <manishc@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marcel Holtmann [Thu, 24 Oct 2019 17:40:42 +0000 (19:40 +0200)]
rfkill: allocate static minor
[ Upstream commit
8670b2b8b029a6650d133486be9d2ace146fd29a ]
udev has a feature of creating /dev/<node> device-nodes if it finds
a devnode:<node> modalias. This allows for auto-loading of modules that
provide the node. This requires to use a statically allocated minor
number for misc character devices.
However, rfkill uses dynamic minor numbers and prevents auto-loading
of the module. So allocate the next static misc minor number and use
it for rfkill.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Link: https://lore.kernel.org/r/20191024174042.19851-1-marcel@holtmann.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lucas Stach [Tue, 29 Oct 2019 11:42:35 +0000 (11:42 +0000)]
nvmem: imx-ocotp: reset error status on probe
[ Upstream commit
c33c585f1b3a99d53920bdac614aca461d8db06f ]
If software running before the OCOTP driver is loaded left the
controller with the error status pending, the driver will never
be able to complete the read timing setup. Reset the error status
on probe to make sure the controller is in usable state.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20191029114240.14905-6-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vandana BN [Tue, 22 Oct 2019 07:51:40 +0000 (04:51 -0300)]
media: v4l2-core: fix touch support in v4l_g_fmt
[ Upstream commit
545b618cfb5cadacd00c25066b9a36540e5ca9e9 ]
v4l_s_fmt, for VFL_TYPE_TOUCH, sets unneeded members of
the v4l2_pix_format structure to default values.This was
missing in v4l_g_fmt, which would lead to failures in
v4l2-compliance tests.
Signed-off-by: Vandana BN <bnvandana@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kangjie Lu [Fri, 18 Oct 2019 04:47:00 +0000 (01:47 -0300)]
media: rcar_drif: fix a memory disclosure
[ Upstream commit
d39083234c60519724c6ed59509a2129fd2aed41 ]
"f->fmt.sdr.reserved" is uninitialized. As other peer drivers
like msi2500 and airspy do, the fix initializes it to avoid
memory disclosures.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Manjunath Patil [Sat, 5 Oct 2019 15:20:03 +0000 (08:20 -0700)]
ixgbe: protect TX timestamping from API misuse
[ Upstream commit
07066d9dc3d2326fbad8f7b0cb0120cff7b7dedb ]
HW timestamping can only be requested for a packet if the NIC is first
setup via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the ixgbe
driver still allowed TX packets to request HW timestamping. In this
situation, we see 'clearing Tx Timestamp hang' noise in the log.
Fix this by checking that the NIC is configured for HW TX timestamping
before accepting a HW TX timestamping request.
Similar-to:
commit
26bd4e2db06b ("igb: protect TX timestamping from API misuse")
commit
0a6f2f05a2f5 ("igb: Fix a test with HWTSTAMP_TX_ON")
Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Dooks (Codethink) [Tue, 22 Oct 2019 15:11:54 +0000 (16:11 +0100)]
pinctrl: amd: fix __iomem annotation in amd_gpio_irq_handler()
[ Upstream commit
10ff58aa3c2e2a093b6ad615a7e3d8bb0dc613e5 ]
The regs pointer in amd_gpio_irq_handler() should have __iomem
on it, so add that to fix the following sparse warnings:
drivers/pinctrl/pinctrl-amd.c:555:14: warning: incorrect type in assignment (different address spaces)
drivers/pinctrl/pinctrl-amd.c:555:14: expected unsigned int [usertype] *regs
drivers/pinctrl/pinctrl-amd.c:555:14: got void [noderef] <asn:2> *base
drivers/pinctrl/pinctrl-amd.c:563:34: warning: incorrect type in argument 1 (different address spaces)
drivers/pinctrl/pinctrl-amd.c:563:34: expected void const volatile [noderef] <asn:2> *addr
drivers/pinctrl/pinctrl-amd.c:563:34: got unsigned int [usertype] *
drivers/pinctrl/pinctrl-amd.c:580:34: warning: incorrect type in argument 1 (different address spaces)
drivers/pinctrl/pinctrl-amd.c:580:34: expected void const volatile [noderef] <asn:2> *addr
drivers/pinctrl/pinctrl-amd.c:580:34: got unsigned int [usertype] *
drivers/pinctrl/pinctrl-amd.c:587:25: warning: incorrect type in argument 2 (different address spaces)
drivers/pinctrl/pinctrl-amd.c:587:25: expected void volatile [noderef] <asn:2> *addr
drivers/pinctrl/pinctrl-amd.c:587:25: got unsigned int [usertype] *
Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Link: https://lore.kernel.org/r/20191022151154.5986-1-ben.dooks@codethink.co.uk
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luiz Augusto von Dentz [Sun, 3 Nov 2019 21:58:15 +0000 (23:58 +0200)]
Bluetooth: Fix advertising duplicated flags
[ Upstream commit
6012b9346d8959194c239fd60a62dfec98d43048 ]
Instances may have flags set as part of its data in which case the code
should not attempt to add it again otherwise it can cause duplication:
< HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 35
Handle: 0x00
Operation: Complete extended advertising data (0x03)
Fragment preference: Minimize fragmentation (0x01)
Data length: 0x06
Flags: 0x04
BR/EDR Not Supported
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Toke Høiland-Jørgensen [Sat, 2 Nov 2019 11:09:37 +0000 (12:09 +0100)]
libbpf: Fix error handling in bpf_map__reuse_fd()
[ Upstream commit
d1b4574a4b86565325ef2e545eda8dfc9aa07c60 ]
bpf_map__reuse_fd() was calling close() in the error path before returning
an error value based on errno. However, close can change errno, so that can
lead to potentially misleading error messages. Instead, explicitly store
errno in the err variable before each goto.
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Link: https://lore.kernel.org/bpf/157269297769.394725.12634985106772698611.stgit@toke.dk
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexandru Ardelean [Wed, 23 Oct 2019 08:26:34 +0000 (11:26 +0300)]
iio: dln2-adc: fix iio_triggered_buffer_postenable() position
[ Upstream commit
a7bddfe2dfce1d8859422124abe1964e0ecd386e ]
The iio_triggered_buffer_postenable() hook should be called first to
attach the poll function. The iio_triggered_buffer_predisable() hook is
called last (as is it should).
This change moves iio_triggered_buffer_postenable() to be called first. It
adds iio_triggered_buffer_predisable() on the error paths of the postenable
hook.
For the predisable hook, some code-paths have been changed to make sure
that the iio_triggered_buffer_predisable() hook gets called in case there
is an error before it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Thu, 24 Oct 2019 13:13:08 +0000 (15:13 +0200)]
pinctrl: sh-pfc: sh7734: Fix duplicate TCLK1_B
[ Upstream commit
884caadad128efad8e00c1cdc3177bc8912ee8ec ]
The definitions for bit field [19:18] of the Peripheral Function Select
Register 3 were accidentally copied from bit field [20], leading to
duplicates for the TCLK1_B function, and missing TCLK0, CAN_CLK_B, and
ET0_ETXD4 functions.
Fix this by adding the missing GPIO_FN_CAN_CLK_B and GPIO_FN_ET0_ETXD4
enum values, and correcting the functions.
Reported-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191024131308.16659-1-geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
Darrick J. Wong [Thu, 31 Oct 2019 03:29:48 +0000 (20:29 -0700)]
loop: fix no-unmap write-zeroes request behavior
[ Upstream commit
efcfec579f6139528c9e6925eca2bc4a36da65c6 ]
Currently, if the loop device receives a WRITE_ZEROES request, it asks
the underlying filesystem to punch out the range. This behavior is
correct if unmapping is allowed. However, a NOUNMAP request means that
the caller doesn't want us to free the storage backing the range, so
punching out the range is incorrect behavior.
To satisfy a NOUNMAP | WRITE_ZEROES request, loop should ask the
underlying filesystem to FALLOC_FL_ZERO_RANGE, which is (according to
the fallocate documentation) required to ensure that the entire range is
backed by real storage, which suffices for our purposes.
Fixes:
19372e2769179dd ("loop: implement REQ_OP_WRITE_ZEROES")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Garry [Wed, 16 Oct 2019 10:19:52 +0000 (18:19 +0800)]
libata: Ensure ata_port probe has completed before detach
[ Upstream commit
130f4caf145c3562108b245a576db30b916199d2 ]
With CONFIG_DEBUG_TEST_DRIVER_REMOVE set, we may find the following WARN:
[ 23.452574] ------------[ cut here ]------------
[ 23.457190] WARNING: CPU: 59 PID: 1 at drivers/ata/libata-core.c:6676 ata_host_detach+0x15c/0x168
[ 23.466047] Modules linked in:
[ 23.469092] CPU: 59 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00010-g5b83fd27752b-dirty #296
[ 23.477776] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
[ 23.486286] pstate:
a0c00009 (NzCv daif +PAN +UAO)
[ 23.491065] pc : ata_host_detach+0x15c/0x168
[ 23.495322] lr : ata_host_detach+0x88/0x168
[ 23.499491] sp :
ffff800011cabb50
[ 23.502792] x29:
ffff800011cabb50 x28:
0000000000000007
[ 23.508091] x27:
ffff80001137f068 x26:
ffff8000112c0c28
[ 23.513390] x25:
0000000000003848 x24:
ffff0023ea185300
[ 23.518689] x23:
0000000000000001 x22:
00000000000014c0
[ 23.523987] x21:
0000000000013740 x20:
ffff0023bdc20000
[ 23.529286] x19:
0000000000000000 x18:
0000000000000004
[ 23.534584] x17:
0000000000000001 x16:
00000000000000f0
[ 23.539883] x15:
ffff0023eac13790 x14:
ffff0023eb76c408
[ 23.545181] x13:
0000000000000000 x12:
ffff0023eac13790
[ 23.550480] x11:
ffff0023eb76c228 x10:
0000000000000000
[ 23.555779] x9 :
ffff0023eac13798 x8 :
0000000040000000
[ 23.561077] x7 :
0000000000000002 x6 :
0000000000000001
[ 23.566376] x5 :
0000000000000002 x4 :
0000000000000000
[ 23.571674] x3 :
ffff0023bf08a0bc x2 :
0000000000000000
[ 23.576972] x1 :
3099674201f72700 x0 :
0000000000400284
[ 23.582272] Call trace:
[ 23.584706] ata_host_detach+0x15c/0x168
[ 23.588616] ata_pci_remove_one+0x10/0x18
[ 23.592615] ahci_remove_one+0x20/0x40
[ 23.596356] pci_device_remove+0x3c/0xe0
[ 23.600267] really_probe+0xdc/0x3e0
[ 23.603830] driver_probe_device+0x58/0x100
[ 23.608000] device_driver_attach+0x6c/0x90
[ 23.612169] __driver_attach+0x84/0xc8
[ 23.615908] bus_for_each_dev+0x74/0xc8
[ 23.619730] driver_attach+0x20/0x28
[ 23.623292] bus_add_driver+0x148/0x1f0
[ 23.627115] driver_register+0x60/0x110
[ 23.630938] __pci_register_driver+0x40/0x48
[ 23.635199] ahci_pci_driver_init+0x20/0x28
[ 23.639372] do_one_initcall+0x5c/0x1b0
[ 23.643199] kernel_init_freeable+0x1a4/0x24c
[ 23.647546] kernel_init+0x10/0x108
[ 23.651023] ret_from_fork+0x10/0x18
[ 23.654590] ---[ end trace
634a14b675b71c13 ]---
With KASAN also enabled, we may also get many use-after-free reports.
The issue is that when CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, we may
attempt to detach the ata_port before it has been probed.
This is because the ata_ports are async probed, meaning that there is no
guarantee that the ata_port has probed prior to detach. When the ata_port
does probe in this scenario, we get all sorts of issues as the detach may
have already happened.
Fix by ensuring synchronisation with async_synchronize_full(). We could
alternatively use the cookie returned from the ata_port probe
async_schedule() call, but that means managing the cookie, so more
complicated.
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunsheng Lin [Thu, 31 Oct 2019 11:23:17 +0000 (19:23 +0800)]
net: hns3: add struct netdev_queue debug info for TX timeout
[ Upstream commit
647522a5ef6401dcdb8ec417421e43fb21910167 ]
When there is a TX timeout, we can tell if the driver or stack
has stopped the queue by looking at state field, and when has
the last packet transmited by looking at trans_start field.
So this patch prints these two field in the
hns3_get_tx_timeo_queue_info().
Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gerald Schaefer [Tue, 22 Oct 2019 12:38:08 +0000 (14:38 +0200)]
s390/mm: add mm_pxd_folded() checks to pxd_free()
[ Upstream commit
2416cefc504ba8ae9b17e3e6b40afc72708f96be ]
Unlike pxd_free_tlb(), the pxd_free() functions do not check for folded
page tables. This is not an issue so far, as those functions will actually
never be called, since no code will reach them when page tables are folded.
In order to avoid future issues, and to make the s390 code more similar to
other architectures, add mm_pxd_folded() checks, similar to how it is done
in pxd_free_tlb().
This was found by testing a patch from from Anshuman Khandual, which is
currently discussed on LKML ("mm/debug: Add tests validating architecture
page table helpers").
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Heiko Carstens [Tue, 29 Oct 2019 13:09:47 +0000 (14:09 +0100)]
s390/time: ensure get_clock_monotonic() returns monotonic values
[ Upstream commit
011620688a71f2f1fe9901dbc2479a7c01053196 ]
The current implementation of get_clock_monotonic() leaves it up to
the caller to call the function with preemption disabled. The only
core kernel caller (sched_clock) however does not disable preemption.
In order to make sure that all callers of this function see monotonic
values handle disabling preemption within the function itself.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephan Gerhold [Tue, 8 Oct 2019 11:52:08 +0000 (13:52 +0200)]
phy: qcom-usb-hs: Fix extcon double register after power cycle
[ Upstream commit
64f86b9978449ff05bfa6c64b4c5439e21e9c80b ]
Commit
f0b5c2c96370 ("phy: qcom-usb-hs: Replace the extcon API")
switched from extcon_register_notifier() to the resource-managed
API, i.e. devm_extcon_register_notifier().
This is problematic in this case, because the extcon notifier
is dynamically registered/unregistered whenever the PHY is powered
on/off. The resource-managed API does not unregister the notifier
until the driver is removed, so as soon as the PHY is power cycled,
attempting to register the notifier again results in:
double register detected
WARNING: CPU: 1 PID: 182 at kernel/notifier.c:26 notifier_chain_register+0x74/0xa0
Call trace:
...
extcon_register_notifier+0x74/0xb8
devm_extcon_register_notifier+0x54/0xb8
qcom_usb_hs_phy_power_on+0x1fc/0x208
...
... and USB stops working after plugging the cable out and in
another time.
The easiest way to fix this is to make a partial revert of
commit
f0b5c2c96370 ("phy: qcom-usb-hs: Replace the extcon API")
and avoid using the resource-managed API in this case.
Fixes:
f0b5c2c96370 ("phy: qcom-usb-hs: Replace the extcon API")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mao Wenan [Sat, 26 Oct 2019 02:21:39 +0000 (10:21 +0800)]
net: dsa: LAN9303: select REGMAP when LAN9303 enable
[ Upstream commit
b6989d248a2d13f02895bae1a9321b3bbccc0283 ]
When NET_DSA_SMSC_LAN9303=y and NET_DSA_SMSC_LAN9303_MDIO=y,
below errors can be seen:
drivers/net/dsa/lan9303_mdio.c:87:23: error: REGMAP_ENDIAN_LITTLE
undeclared here (not in a function)
.reg_format_endian = REGMAP_ENDIAN_LITTLE,
drivers/net/dsa/lan9303_mdio.c:93:3: error: const struct regmap_config
has no member named reg_read
.reg_read = lan9303_mdio_read,
It should select REGMAP in config NET_DSA_SMSC_LAN9303.
Fixes:
dc7005831523 ("net: dsa: LAN9303: add MDIO managed mode support")
Signed-off-by: Mao Wenan <maowenan@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thierry Reding [Mon, 28 Oct 2019 12:37:12 +0000 (13:37 +0100)]
gpu: host1x: Allocate gather copy for host1x
[ Upstream commit
b78e70c04c149299bd210759d7c7af7c86b89ca8 ]
Currently when the gather buffers are copied, they are copied to a
buffer that is allocated for the host1x client that wants to execute the
command streams in the buffers. However, the gather buffers will be read
by the host1x device, which causes SMMU faults if the DMA API is backed
by an IOMMU.
Fix this by allocating the gather buffer copy for the host1x device,
which makes sure that it will be mapped into the host1x's IOVA space if
the DMA API is backed by an IOMMU.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michal Kalderon [Sun, 27 Oct 2019 20:04:51 +0000 (22:04 +0200)]
RDMA/qedr: Fix memory leak in user qp and mr
[ Upstream commit
24e412c1e00ebfe73619e6b88cbc26c2c7d41b85 ]
User QPs pbl's weren't freed properly.
MR pbls weren't freed properly.
Fixes:
e0290cce6ac0 ("qedr: Add support for memory registeration verbs")
Link: https://lore.kernel.org/r/20191027200451.28187-5-michal.kalderon@marvell.com
Signed-off-by: Ariel Elior <ariel.elior@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Sat, 26 Oct 2019 20:24:34 +0000 (22:24 +0200)]
ACPI: button: Add DMI quirk for Medion Akoya E2215T
[ Upstream commit
932e1ba486117de2fcea3df27ad8218ad6c11470 ]
The Medion Akoya E2215T's ACPI _LID implementation is quite broken:
1. For notifications it uses an ActiveLow Edge GpioInt, rather then
an ActiveBoth one, meaning that the device is only notified when the
lid is closed, not when it is opened.
2. Matching with this its _LID method simply always returns 0 (closed)
In order for the Linux LID code to work properly with this implementation,
the lid_init_state selection needs to be set to ACPI_BUTTON_LID_INIT_OPEN.
This commit adds a DMI quirk for this.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-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>
Lingling Xu [Mon, 28 Oct 2019 10:10:30 +0000 (18:10 +0800)]
spi: sprd: adi: Add missing lock protection when rebooting
[ Upstream commit
91ea1d70607e374b014b4b9bea771ce661f9f64b ]
When rebooting the system, we should lock the watchdog after
configuration to make sure the watchdog can reboot the system
successfully.
Signed-off-by: Lingling Xu <ling_ling.xu@unisoc.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Link: https://lore.kernel.org/r/7b04711127434555e3a1a86bc6be99860cd86668.1572257085.git.baolin.wang@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thierry Reding [Wed, 24 Jul 2019 15:06:17 +0000 (17:06 +0200)]
drm/tegra: sor: Use correct SOR index on Tegra210
[ Upstream commit
24e64f86da40e68c5f58af08796110f147b12193 ]
The device tree bindings for the Tegra210 SOR don't require the
controller instance to be defined, since the instance can be derived
from the compatible string. The index is never used on Tegra210, so we
got away with it not getting set. However, subsequent patches will
change that, so make sure the proper index is used.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Grygorii Strashko [Wed, 23 Oct 2019 14:48:45 +0000 (17:48 +0300)]
net: phy: dp83867: enable robust auto-mdix
[ Upstream commit
5a7f08c2abb0efc9d17aff2fc75d6d3b85e622e4 ]
The link detection timeouts can be observed (or link might not be detected
at all) when dp83867 PHY is configured in manual mode (speed/duplex).
CFG3[9] Robust Auto-MDIX option allows to significantly improve link detection
in case dp83867 is configured in manual mode and reduce link detection
time.
As per DM: "If link partners are configured to operational modes that are
not supported by normal Auto MDI/MDIX mode (like Auto-Neg versus Force
100Base-TX or Force 100Base-TX versus Force 100Base-TX), this Robust Auto
MDI/MDIX mode allows MDI/MDIX resolution and prevents deadlock."
Hence, enable this option by default as there are no known reasons
not to do so.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicholas Nunley [Fri, 20 Sep 2019 09:17:21 +0000 (02:17 -0700)]
i40e: initialize ITRN registers with correct values
[ Upstream commit
998e5166e604fd37afe94352f7b8c2d816b11049 ]
Since commit
92418fb14750 ("i40e/i40evf: Use usec value instead of reg
value for ITR defines") the driver tracks the interrupt throttling
intervals in single usec units, although the actual ITRN/ITR0 registers are
programmed in 2 usec units. Most register programming flows in the driver
correctly handle the conversion, although it is currently not applied when
the registers are initialized to their default values. Most of the time
this doesn't present a problem since the default values are usually
immediately overwritten through the standard adaptive throttling mechanism,
or updated manually by the user, but if adaptive throttling is disabled and
the interval values are left alone then the incorrect value will persist.
Since the intended default interval of 50 usecs (vs. 100 usecs as
programmed) performs better for most traffic workloads, this can lead to
performance regressions.
This patch adds the correct conversion when writing the initial values to
the ITRN registers.
Signed-off-by: Nicholas Nunley <nicholas.d.nunley@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunfeng Ye [Mon, 21 Oct 2019 11:31:21 +0000 (19:31 +0800)]
arm64: psci: Reduce the waiting time for cpu_psci_cpu_kill()
[ Upstream commit
bfcef4ab1d7ee8921bc322109b1692036cc6cbe0 ]
In cases like suspend-to-disk and suspend-to-ram, a large number of CPU
cores need to be shut down. At present, the CPU hotplug operation is
serialised, and the CPU cores can only be shut down one by one. In this
process, if PSCI affinity_info() does not return LEVEL_OFF quickly,
cpu_psci_cpu_kill() needs to wait for 10ms. If hundreds of CPU cores
need to be shut down, it will take a long time.
Normally, there is no need to wait 10ms in cpu_psci_cpu_kill(). So
change the wait interval from 10 ms to max 1 ms and use usleep_range()
instead of msleep() for more accurate timer.
In addition, reducing the time interval will increase the messages
output, so remove the "Retry ..." message, instead, track time and
output to the the sucessful message.
Signed-off-by: Yunfeng Ye <yeyunfeng@huawei.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guoqing Jiang [Thu, 26 Sep 2019 11:53:50 +0000 (13:53 +0200)]
md/bitmap: avoid race window between md_bitmap_resize and bitmap_file_clear_bit
[ Upstream commit
fadcbd2901a0f7c8721f3bdb69eac95c272dc8ed ]
We need to move "spin_lock_irq(&bitmap->counts.lock)" before unmap previous
storage, otherwise panic like belows could happen as follows.
[ 902.353802] sdl: detected capacity change from
1077936128 to
3221225472
[ 902.616948] general protection fault: 0000 [#1] SMP
[snip]
[ 902.618588] CPU: 12 PID: 33698 Comm: md0_raid1 Tainted: G O 4.14.144-1-pserver #4.14.144-1.1~deb10
[ 902.618870] Hardware name: Supermicro SBA-7142G-T4/BHQGE, BIOS 3.00 10/24/2012
[ 902.619120] task:
ffff9ae1860fc600 task.stack:
ffffb52e4c704000
[ 902.619301] RIP: 0010:bitmap_file_clear_bit+0x90/0xd0 [md_mod]
[ 902.619464] RSP: 0018:
ffffb52e4c707d28 EFLAGS:
00010087
[ 902.619626] RAX:
ffe8008b0d061000 RBX:
ffff9ad078c87300 RCX:
0000000000000000
[ 902.619792] RDX:
ffff9ad986341868 RSI:
0000000000000803 RDI:
ffff9ad078c87300
[ 902.619986] RBP:
ffff9ad0ed7a8000 R08:
0000000000000000 R09:
0000000000000000
[ 902.620154] R10:
ffffb52e4c707ec0 R11:
ffff9ad987d1ed44 R12:
ffff9ad0ed7a8360
[ 902.620320] R13:
0000000000000003 R14:
0000000000060000 R15:
0000000000000800
[ 902.620487] FS:
0000000000000000(0000) GS:
ffff9ad987d00000(0000) knlGS:
0000000000000000
[ 902.620738] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 902.620901] CR2:
000055ff12aecec0 CR3:
0000001005207000 CR4:
00000000000406e0
[ 902.621068] Call Trace:
[ 902.621256] bitmap_daemon_work+0x2dd/0x360 [md_mod]
[ 902.621429] ? find_pers+0x70/0x70 [md_mod]
[ 902.621597] md_check_recovery+0x51/0x540 [md_mod]
[ 902.621762] raid1d+0x5c/0xeb0 [raid1]
[ 902.621939] ? try_to_del_timer_sync+0x4d/0x80
[ 902.622102] ? del_timer_sync+0x35/0x40
[ 902.622265] ? schedule_timeout+0x177/0x360
[ 902.622453] ? call_timer_fn+0x130/0x130
[ 902.622623] ? find_pers+0x70/0x70 [md_mod]
[ 902.622794] ? md_thread+0x94/0x150 [md_mod]
[ 902.622959] md_thread+0x94/0x150 [md_mod]
[ 902.623121] ? wait_woken+0x80/0x80
[ 902.623280] kthread+0x119/0x130
[ 902.623437] ? kthread_create_on_node+0x60/0x60
[ 902.623600] ret_from_fork+0x22/0x40
[ 902.624225] RIP: bitmap_file_clear_bit+0x90/0xd0 [md_mod] RSP:
ffffb52e4c707d28
Because mdadm was running on another cpu to do resize, so bitmap_resize was
called to replace bitmap as below shows.
PID: 38801 TASK:
ffff9ad074a90e00 CPU: 0 COMMAND: "mdadm"
[exception RIP: queued_spin_lock_slowpath+56]
[snip]
-- <NMI exception stack> --
#5 [
ffffb52e60f17c58] queued_spin_lock_slowpath at
ffffffff9c0b27b8
#6 [
ffffb52e60f17c58] bitmap_resize at
ffffffffc0399877 [md_mod]
#7 [
ffffb52e60f17d30] raid1_resize at
ffffffffc0285bf9 [raid1]
#8 [
ffffb52e60f17d50] update_size at
ffffffffc038a31a [md_mod]
#9 [
ffffb52e60f17d70] md_ioctl at
ffffffffc0395ca4 [md_mod]
And the procedure to keep resize bitmap safe is allocate new storage
space, then quiesce, copy bits, replace bitmap, and re-start.
However the daemon (bitmap_daemon_work) could happen even the array is
quiesced, which means when bitmap_file_clear_bit is triggered by raid1d,
then it thinks it should be fine to access store->filemap since
counts->lock is held, but resize could change the storage without the
protection of the lock.
Cc: Jack Wang <jinpu.wang@cloud.ionos.com>
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Guoqing Jiang <guoqing.jiang@cloud.ionos.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sakari Ailus [Fri, 11 Oct 2019 11:16:02 +0000 (08:16 -0300)]
media: smiapp: Register sensor after enabling runtime PM on the device
[ Upstream commit
90c9e4a4dba9f4de331372e745fb1991c1faa598 ]
Earlier it was possible that the parts of the driver that assumed runtime
PM was enabled were being called before runtime PM was enabled in the
driver's probe function. So enable runtime PM before registering the
sub-device.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Thomas Gleixner [Thu, 17 Oct 2019 10:19:01 +0000 (12:19 +0200)]
x86/ioapic: Prevent inconsistent state when moving an interrupt
[ Upstream commit
df4393424af3fbdcd5c404077176082a8ce459c4 ]
There is an issue with threaded interrupts which are marked ONESHOT
and using the fasteoi handler:
if (IS_ONESHOT())
mask_irq();
....
cond_unmask_eoi_irq()
chip->irq_eoi();
if (setaffinity_pending) {
mask_ioapic();
...
move_affinity();
unmask_ioapic();
}
So if setaffinity is pending the interrupt will be moved and then
unconditionally unmasked at the ioapic level, which is wrong in two
aspects:
1) It should be kept masked up to the point where the threaded handler
finished.
2) The physical chip state and the software masked state are inconsistent
Guard both the mask and the unmask with a check for the software masked
state. If the line is marked masked then the ioapic line is also masked, so
both mask_ioapic() and unmask_ioapic() can be skipped safely.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Fixes:
3aa551c9b4c4 ("genirq: add threaded interrupt handler support")
Link: https://lkml.kernel.org/r/20191017101938.321393687@linutronix.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corey Minyard [Mon, 14 Oct 2019 15:35:56 +0000 (10:35 -0500)]
ipmi: Don't allow device module unload when in use
[ Upstream commit
cbb79863fc3175ed5ac506465948b02a893a8235 ]
If something has the IPMI driver open, don't allow the device
module to be unloaded. Before it would unload and the user would
get errors on use.
This change is made on user request, and it makes it consistent
with the I2C driver, which has the same behavior.
It does change things a little bit with respect to kernel users.
If the ACPI or IPMI watchdog (or any other kernel user) has
created a user, then the device module cannot be unloaded. Before
it could be unloaded,
This does not affect hot-plug. If the device goes away (it's on
something removable that is removed or is hot-removed via sysfs)
then it still behaves as it did before.
Reported-by: tony camuso <tcamuso@redhat.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: tony camuso <tcamuso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chris Chiu [Wed, 16 Oct 2019 01:54:08 +0000 (09:54 +0800)]
rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot
[ Upstream commit
0eeb91ade90ce06d2fa1e2fcb55e3316b64c203c ]
The RTL8723BU has problems connecting to AP after each warm reboot.
Sometimes it returns no scan result, and in most cases, it fails
the authentication for unknown reason. However, it works totally
fine after cold reboot.
Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE
for cold reboot and warm reboot, the registers imply that the MAC
is already powered and thus some procedures are skipped during
driver initialization. Double checked the vendor driver, it reads
the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any
during initialization based on them. This commit only tells the
RTL8723BU to do full initialization without checking MAC status.
Signed-off-by: Chris Chiu <chiu@endlessm.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kangjie Lu [Fri, 18 Oct 2019 04:41:50 +0000 (23:41 -0500)]
drm/gma500: fix memory disclosures due to uninitialized bytes
[ Upstream commit
ec3b7b6eb8c90b52f61adff11b6db7a8db34de19 ]
"clock" may be copied to "best_clock". Initializing best_clock
is not sufficient. The fix initializes clock as well to avoid
memory disclosures and informaiton leaks.
Signed-off-by: Kangjie Lu <kjlu@umn.edu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20191018044150.1899-1-kjlu@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leo Yan [Fri, 18 Oct 2019 08:55:31 +0000 (16:55 +0800)]
perf tests: Disable bp_signal testing for arm64
[ Upstream commit
6a5f3d94cb69a185b921cb92c39888dc31009acb ]
As there are several discussions for enabling perf breakpoint signal
testing on arm64 platform: arm64 needs to rely on single-step to execute
the breakpointed instruction and then reinstall the breakpoint exception
handler. But if we hook the breakpoint with a signal, the signal
handler will do the stepping rather than the breakpointed instruction,
this causes infinite loops as below:
Kernel space | Userspace
---------------------------------|--------------------------------
| __test_function() -> hit
| breakpoint
breakpoint_handler() |
`-> user_enable_single_step() |
do_signal() |
| sig_handler() -> Step one
| instruction and
| trap to kernel
single_step_handler() |
`-> reinstall_suspended_bps() |
| __test_function() -> hit
| breakpoint again and
| repeat up flow infinitely
As Will Deacon mentioned [1]: "that we require the overflow handler to
do the stepping on arm/arm64, which is relied upon by GDB/ptrace. The
hw_breakpoint code is a complete disaster so my preference would be to
rip out the perf part and just implement something directly in ptrace,
but it's a pretty horrible job". Though Will commented this on arm
architecture, but the comment also can apply on arm64 architecture.
For complete information, I searched online and found a few years back,
Wang Nan sent one patch 'arm64: Store breakpoint single step state into
pstate' [2]; the patch tried to resolve this issue by avoiding single
stepping in signal handler and defer to enable the signal stepping when
return to __test_function(). The fixing was not merged due to the
concern for missing to handle different usage cases.
Based on the info, the most feasible way is to skip Perf breakpoint
signal testing for arm64 and this could avoid the duplicate
investigation efforts when people see the failure. This patch skips
this case on arm64 platform, which is same with arm architecture.
[1] https://lkml.org/lkml/2018/11/15/205
[2] https://lkml.org/lkml/2015/12/23/477
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Brajeswar Ghosh <brajeswar.linux@gmail.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Song Liu <songliubraving@fb.com>
Cc: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Will Deacon <will@kernel.org>
Link: http://lore.kernel.org/lkml/20191018085531.6348-3-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Benjamin Berg [Wed, 9 Oct 2019 15:54:24 +0000 (17:54 +0200)]
x86/mce: Lower throttling MCE messages' priority to warning
[ Upstream commit
9c3bafaa1fd88e4dd2dba3735a1f1abb0f2c7bb7 ]
On modern CPUs it is quite normal that the temperature limits are
reached and the CPU is throttled. In fact, often the thermal design is
not sufficient to cool the CPU at full load and limits can quickly be
reached when a burst in load happens. This will even happen with
technologies like RAPL limitting the long term power consumption of
the package.
Also, these limits are "softer", as Srinivas explains:
"CPU temperature doesn't have to hit max(TjMax) to get these warnings.
OEMs ha[ve] an ability to program a threshold where a thermal interrupt
can be generated. In some systems the offset is 20C+ (Read only value).
In recent systems, there is another offset on top of it which can be
programmed by OS, once some agent can adjust power limits dynamically.
By default this is set to low by the firmware, which I guess the
prime motivation of Benjamin to submit the patch."
So these messages do not usually indicate a hardware issue (e.g.
insufficient cooling). Log them as warnings to avoid confusion about
their severity.
[ bp: Massage commit mesage. ]
Signed-off-by: Benjamin Berg <bberg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Christian Kellner <ckellner@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: linux-edac <linux-edac@vger.kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: x86-ml <x86@kernel.org>
Link: https://lkml.kernel.org/r/20191009155424.249277-1-bberg@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Song Liu [Mon, 14 Oct 2019 17:12:23 +0000 (10:12 -0700)]
bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack()
[ Upstream commit
eac9153f2b584c702cea02c1f1a57d85aa9aea42 ]
bpf stackmap with build-id lookup (BPF_F_STACK_BUILD_ID) can trigger A-A
deadlock on rq_lock():
rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[...]
Call Trace:
try_to_wake_up+0x1ad/0x590
wake_up_q+0x54/0x80
rwsem_wake+0x8a/0xb0
bpf_get_stack+0x13c/0x150
bpf_prog_fbdaf42eded9fe46_on_event+0x5e3/0x1000
bpf_overflow_handler+0x60/0x100
__perf_event_overflow+0x4f/0xf0
perf_swevent_overflow+0x99/0xc0
___perf_sw_event+0xe7/0x120
__schedule+0x47d/0x620
schedule+0x29/0x90
futex_wait_queue_me+0xb9/0x110
futex_wait+0x139/0x230
do_futex+0x2ac/0xa50
__x64_sys_futex+0x13c/0x180
do_syscall_64+0x42/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
This can be reproduced by:
1. Start a multi-thread program that does parallel mmap() and malloc();
2. taskset the program to 2 CPUs;
3. Attach bpf program to trace_sched_switch and gather stackmap with
build-id, e.g. with trace.py from bcc tools:
trace.py -U -p <pid> -s <some-bin,some-lib> t:sched:sched_switch
A sample reproducer is attached at the end.
This could also trigger deadlock with other locks that are nested with
rq_lock.
Fix this by checking whether irqs are disabled. Since rq_lock and all
other nested locks are irq safe, it is safe to do up_read() when irqs are
not disable. If the irqs are disabled, postpone up_read() in irq_work.
Fixes:
615755a77b24 ("bpf: extend stackmap to save binary_build_id+offset instead of address")
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20191014171223.357174-1-songliubraving@fb.com
Reproducer:
============================ 8< ============================
char *filename;
void *worker(void *p)
{
void *ptr;
int fd;
char *pptr;
fd = open(filename, O_RDONLY);
if (fd < 0)
return NULL;
while (1) {
struct timespec ts = {0, 1000 + rand() % 2000};
ptr = mmap(NULL, 4096 * 64, PROT_READ, MAP_PRIVATE, fd, 0);
usleep(1);
if (ptr == MAP_FAILED) {
printf("failed to mmap\n");
break;
}
munmap(ptr, 4096 * 64);
usleep(1);
pptr = malloc(1);
usleep(1);
pptr[0] = 1;
usleep(1);
free(pptr);
usleep(1);
nanosleep(&ts, NULL);
}
close(fd);
return NULL;
}
int main(int argc, char *argv[])
{
void *ptr;
int i;
pthread_t threads[THREAD_COUNT];
if (argc < 2)
return 0;
filename = argv[1];
for (i = 0; i < THREAD_COUNT; i++) {
if (pthread_create(threads + i, NULL, worker, NULL)) {
fprintf(stderr, "Error creating thread\n");
return 0;
}
}
for (i = 0; i < THREAD_COUNT; i++)
pthread_join(threads[i], NULL);
return 0;
}
============================ 8< ============================
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mattijs Korpershoek [Thu, 17 Oct 2019 03:20:39 +0000 (20:20 -0700)]
Bluetooth: hci_core: fix init for HCI_USER_CHANNEL
[ Upstream commit
eb8c101e28496888a0dcfe16ab86a1bee369e820 ]
During the setup() stage, HCI device drivers expect the chip to
acknowledge its setup() completion via vendor specific frames.
If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode,
the vendor specific frames are never tranmitted to the driver, as
they are filtered in hci_rx_work().
Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive
frames if the HCI device is is HCI_INIT state.
[1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html
Fixes:
23500189d7e0 ("Bluetooth: Introduce new HCI socket channel for user operation")
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Szymon Janc [Wed, 2 Oct 2019 12:22:43 +0000 (14:22 +0200)]
Bluetooth: Workaround directed advertising bug in Broadcom controllers
[ Upstream commit
4c371bb95cf06ded80df0e6139fdd77cee1d9a94 ]
It appears that some Broadcom controllers (eg BCM20702A0) reject LE Set
Advertising Parameters command if advertising intervals provided are not
within range for undirected and low duty directed advertising.
Workaround this bug by populating min and max intervals with 'valid'
values.
< HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15
Min advertising interval: 0.000 msec (0x0000)
Max advertising interval: 0.000 msec (0x0000)
Type: Connectable directed - ADV_DIRECT_IND (high duty cycle) (0x01)
Own address type: Public (0x00)
Direct address type: Random (0x01)
Direct address: E2:F0:7B:9F:DC:F4 (Static)
Channel map: 37, 38, 39 (0x07)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertising Parameters (0x08|0x0006) ncmd 1
Status: Invalid HCI Command Parameters (0x12)
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Tested-by: Sören Beye <linux@hypfer.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Dooks (Codethink) [Wed, 16 Oct 2019 11:39:43 +0000 (12:39 +0100)]
Bluetooth: missed cpu_to_le16 conversion in hci_init4_req
[ Upstream commit
727ea61a5028f8ac96f75ab34cb1b56e63fd9227 ]
It looks like in hci_init4_req() the request is being
initialised from cpu-endian data but the packet is specified
to be little-endian. This causes an warning from sparse due
to __le16 to u16 conversion.
Fix this by using cpu_to_le16() on the two fields in the packet.
net/bluetooth/hci_core.c:845:27: warning: incorrect type in assignment (different base types)
net/bluetooth/hci_core.c:845:27: expected restricted __le16 [usertype] tx_len
net/bluetooth/hci_core.c:845:27: got unsigned short [usertype] le_max_tx_len
net/bluetooth/hci_core.c:846:28: warning: incorrect type in assignment (different base types)
net/bluetooth/hci_core.c:846:28: expected restricted __le16 [usertype] tx_time
net/bluetooth/hci_core.c:846:28: got unsigned short [usertype] le_max_tx_time
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miquel Raynal [Fri, 11 Oct 2019 14:43:42 +0000 (16:43 +0200)]
iio: adc: max1027: Reset the device at probe time
[ Upstream commit
db033831b4f5589f9fcbadb837614a7c4eac0308 ]
All the registers are configured by the driver, let's reset the chip
at probe time, avoiding any conflict with a possible earlier
configuration.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ingo Rohloff [Fri, 11 Oct 2019 11:55:18 +0000 (13:55 +0200)]
usb: usbfs: Suppress problematic bind and unbind uevents.
[ Upstream commit
abb0b3d96a1f9407dd66831ae33985a386d4200d ]
commit
1455cf8dbfd0 ("driver core: emit uevents when device is bound
to a driver") added bind and unbind uevents when a driver is bound or
unbound to a physical device.
For USB devices which are handled via the generic usbfs layer (via
libusb for example), this is problematic:
Each time a user space program calls
ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
and then later
ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
The kernel will now produce a bind or unbind event, which does not
really contain any useful information.
This allows a user space program to run a DoS attack against programs
which listen to uevents (in particular systemd/eudev/upowerd):
A malicious user space program just has to call in a tight loop
ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr);
ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr);
With this loop the malicious user space program floods the kernel and
all programs listening to uevents with tons of bind and unbind
events.
This patch suppresses uevents for ioctls USBDEVFS_CLAIMINTERFACE and
USBDEVFS_RELEASEINTERFACE.
Signed-off-by: Ingo Rohloff <ingo.rohloff@lauterbach.com>
Link: https://lore.kernel.org/r/20191011115518.2801-1-ingo.rohloff@lauterbach.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jin Yao [Fri, 11 Oct 2019 02:21:22 +0000 (10:21 +0800)]
perf report: Add warning when libunwind not compiled in
[ Upstream commit
800d3f561659b5436f8c57e7c26dd1f6928b5615 ]
We received a user report that call-graph DWARF mode was enabled in
'perf record' but 'perf report' didn't unwind the callstack correctly.
The reason was, libunwind was not compiled in.
We can use 'perf -vv' to check the compiled libraries but it would be
valuable to report a warning to user directly (especially valuable for
a perf newbie).
The warning is:
Warning:
Please install libunwind development packages during the perf build.
Both TUI and stdio are supported.
Signed-off-by: Jin Yao <yao.jin@linux.intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lore.kernel.org/lkml/20191011022122.26369-1-yao.jin@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leo Yan [Fri, 11 Oct 2019 09:19:41 +0000 (17:19 +0800)]
perf test: Report failure for mmap events
[ Upstream commit
6add129c5d9210ada25217abc130df0b7096ee02 ]
When fail to mmap events in task exit case, it misses to set 'err' to
-1; thus the testing will not report failure for it.
This patch sets 'err' to -1 when fails to mmap events, thus Perf tool
can report correct result.
Fixes:
d723a55096b8 ("perf test: Add test case for checking number of EXIT events")
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: http://lore.kernel.org/lkml/20191011091942.29841-1-leo.yan@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Kurtz [Tue, 8 Oct 2019 10:21:45 +0000 (18:21 +0800)]
drm/bridge: dw-hdmi: Restore audio when setting a mode
[ Upstream commit
fadfee3f9d8f114435a8a3e9f83a227600d89de7 ]
When setting a new display mode, dw_hdmi_setup() calls
dw_hdmi_enable_video_path(), which disables all hdmi clocks, including
the audio clock.
We should only (re-)enable the audio clock if audio was already enabled
when setting the new mode.
Without this patch, on RK3288, there will be HDMI audio on some monitors
if i2s was played to headphone when the monitor was plugged.
ACER H277HU and ASUS PB278 are two of the monitors showing this issue.
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191008102145.55134-1-cychiang@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bjorn Andersson [Fri, 11 Oct 2019 18:28:17 +0000 (11:28 -0700)]
ath10k: Correct error handling of dma_map_single()
[ Upstream commit
d43810b2c1808ac865aa1a2a2c291644bf95345c ]
The return value of dma_map_single() should be checked for errors using
dma_mapping_error() and the skb has been dequeued so it needs to be
freed.
This was found when enabling CONFIG_DMA_API_DEBUG and it warned about the
missing dma_mapping_error() call.
Fixes:
1807da49733e ("ath10k: wmi: add management tx by reference support over wmi")
Reported-by: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sami Tolvanen [Fri, 13 Sep 2019 21:14:02 +0000 (14:14 -0700)]
x86/mm: Use the correct function type for native_set_fixmap()
[ Upstream commit
f53e2cd0b8ab7d9e390414470bdbd830f660133f ]
We call native_set_fixmap indirectly through the function pointer
struct pv_mmu_ops::set_fixmap, which expects the first parameter to be
'unsigned' instead of 'enum fixed_addresses'. This patch changes the
function type for native_set_fixmap to match the pointer, which fixes
indirect call mismatches with Control-Flow Integrity (CFI) checking.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.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: H. Peter Anvin <hpa@zytor.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>
Link: https://lkml.kernel.org/r/20190913211402.193018-1-samitolvanen@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephan Gerhold [Thu, 10 Oct 2019 15:47:20 +0000 (17:47 +0200)]
extcon: sm5502: Reset registers during initialization
[ Upstream commit
6942635032cfd3e003e980d2dfa4e6323a3ce145 ]
On some devices (e.g. Samsung Galaxy A5 (2015)), the bootloader
seems to keep interrupts enabled for SM5502 when booting Linux.
Changing the cable state (i.e. plugging in a cable) - until the driver
is loaded - will therefore produce an interrupt that is never read.
In this situation, the cable state will be stuck forever on the
initial state because SM5502 stops sending interrupts.
This can be avoided by clearing those pending interrupts after
the driver has been loaded.
One way to do this is to reset all registers to default state
by writing to SM5502_REG_RESET. This ensures that we start from
a clean state, with all interrupts disabled.
Suggested-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Galiffi [Sat, 21 Sep 2019 00:20:23 +0000 (20:20 -0400)]
drm/amd/display: Fix dongle_caps containing stale information.
[ Upstream commit
dd998291dbe92106d8c4a7581c409b356928d711 ]
[WHY]
During detection:
function: get_active_converter_info populates link->dpcd_caps.dongle_caps
only when dpcd_rev >= DPCD_REV_11 and DWN_STRM_PORTX_TYPE is
DOWN_STREAM_DETAILED_HDMI or DOWN_STREAM_DETAILED_DP_PLUS_PLUS.
Otherwise, it is not cleared, and stale information remains.
During mode validation:
function: dp_active_dongle_validate_timing reads
link->dpcd_caps.dongle_caps->dongle_type to determine the maximum
pixel clock to support. This information is now stale and no longer
valid.
[HOW]
dp_active_dongle_validate_timing should be using
link->dpcd_caps->dongle_type instead.
Signed-off-by: David Galiffi <david.galiffi@amd.com>
Reviewed-by: Jun Lei <Jun.Lei@amd.com>
Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sami Tolvanen [Tue, 8 Oct 2019 22:40:45 +0000 (15:40 -0700)]
syscalls/x86: Use the correct function type in SYSCALL_DEFINE0
[ Upstream commit
8661d769ab77c675b5eb6c3351a372b9fbc1bf40 ]
Although a syscall defined using SYSCALL_DEFINE0 doesn't accept
parameters, use the correct function type to avoid type mismatches
with Control-Flow Integrity (CFI) checking.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H . Peter Anvin <hpa@zytor.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20191008224049.115427-2-samitolvanen@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Benoit Parrot [Mon, 7 Oct 2019 15:09:59 +0000 (12:09 -0300)]
media: ti-vpe: vpe: fix a v4l2-compliance failure about invalid sizeimage
[ Upstream commit
0bac73adea4df8d34048b38f6ff24dc3e73e90b6 ]
v4l2-compliance fails with this message:
fail: v4l2-test-formats.cpp(463): !pfmt.sizeimage
fail: v4l2-test-formats.cpp(736): \
Video Capture Multiplanar is valid, \
but TRY_FMT failed to return a format
test VIDIOC_TRY_FMT: FAIL
This failure is causd by the driver failing to handle out range
'bytesperline' values from user space applications.
VPDMA hardware is limited to 64k line stride (16 bytes aligned, so 65520
bytes). So make sure the provided or calculated 'bytesperline' is
smaller than the maximum value.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Benoit Parrot [Mon, 7 Oct 2019 15:10:01 +0000 (12:10 -0300)]
media: ti-vpe: vpe: ensure buffers are cleaned up properly in abort cases
[ Upstream commit
cf6acb73b050e98b5cc435fae0e8ae0157520410 ]
v4l2-compliance fails with this message:
fail: v4l2-test-buffers.cpp(691): ret == 0
fail: v4l2-test-buffers.cpp(974): captureBufs(node, q, m2m_q,
frame_count, true)
test MMAP: FAIL
This caused the following Kernel Warning:
WARNING: CPU: 0 PID: 961 at
drivers/media/v4l2-core/videobuf2-core.c:1658
__vb2_queue_cancel+0x174/0x1d8
...
CPU: 0 PID: 961 Comm: v4l2-compliance Not tainted
4.14.62-01720-g20ecd717e87a #6
Hardware name: Generic DRA72X (Flattened Device Tree)
Backtrace:
[<
c020b5bc>] (dump_backtrace) from [<
c020b8a0>] (show_stack+0x18/0x1c)
r7:
00000009 r6:
60070013 r5:
00000000 r4:
c1053824
[<
c020b888>] (show_stack) from [<
c09232e8>] (dump_stack+0x90/0xa4)
[<
c0923258>] (dump_stack) from [<
c022b740>] (__warn+0xec/0x104)
r7:
00000009 r6:
c0c0ad50 r5:
00000000 r4:
00000000
[<
c022b654>] (__warn) from [<
c022b810>] (warn_slowpath_null+0x28/0x30)
r9:
00000008 r8:
00000000 r7:
eced4808 r6:
edbc9bac r5:
eced4844
r4:
eced4808
[<
c022b7e8>] (warn_slowpath_null) from [<
c0726f48>]
(__vb2_queue_cancel+0x174/0x1d8)
[<
c0726dd4>] (__vb2_queue_cancel) from [<
c0727648>]
(vb2_core_queue_release+0x20/0x40)
r10:
ecc7bd70 r9:
00000008 r8:
00000000 r7:
edb73010 r6:
edbc9bac
r5:
eced4844
r4:
eced4808 r3:
00000004
[<
c0727628>] (vb2_core_queue_release) from [<
c0729528>]
(vb2_queue_release+0x10/0x14)
r5:
edbc9810 r4:
eced4800
[<
c0729518>] (vb2_queue_release) from [<
c0724d08>]
(v4l2_m2m_ctx_release+0x1c/0x30)
[<
c0724cec>] (v4l2_m2m_ctx_release) from [<
bf0e8f28>]
(vpe_release+0x74/0xb0 [ti_vpe])
r5:
edbc9810 r4:
ed67a400
[<
bf0e8eb4>] (vpe_release [ti_vpe]) from [<
c070fccc>]
(v4l2_release+0x3c/0x80)
r7:
edb73010 r6:
ed176aa0 r5:
edbc9868 r4:
ed5119c0
[<
c070fc90>] (v4l2_release) from [<
c033cf1c>] (__fput+0x8c/0x1dc)
r5:
ecc7bd70 r4:
ed5119c0
[<
c033ce90>] (__fput) from [<
c033d0cc>] (____fput+0x10/0x14)
r10:
00000000 r9:
ed5119c0 r8:
ece392d0 r7:
c1059544 r6:
ece38d80
r5:
ece392b4
r4:
00000000
[<
c033d0bc>] (____fput) from [<
c0246e00>] (task_work_run+0x98/0xb8)
[<
c0246d68>] (task_work_run) from [<
c022f1d8>] (do_exit+0x170/0xa80)
r9:
ece351fc r8:
00000000 r7:
ecde3f58 r6:
ffffe000 r5:
ece351c0
r4:
ece38d80
[<
c022f068>] (do_exit) from [<
c022fb6c>] (do_group_exit+0x48/0xc4)
r7:
000000f8
[<
c022fb24>] (do_group_exit) from [<
c022fc00>]
(__wake_up_parent+0x0/0x28)
r7:
000000f8 r6:
b6c6a798 r5:
00000001 r4:
00000001
[<
c022fbe8>] (SyS_exit_group) from [<
c0207c80>]
(ret_fast_syscall+0x0/0x4c)
These warnings are caused by buffers which not properly cleaned
up/release during an abort use case.
In the abort cases the VPDMA desc buffers would still be mapped and the
in-flight VB2 buffers would not be released properly causing a kernel
warning from being generated by the videobuf2-core level.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
projects / platform / kernel / linux-rpi.git / log