22 Jun, 2020
29 commits
-
[ Upstream commit aa880ad690ab6d4c53934af85fb5a43e69ecb0f5 ]
When we increase hardware queue count, blk_mq_update_queue_map will
reset the mapping between cpu and hardware queue base on the hardware
queue count(set->nr_hw_queues). The mapping cannot be reset if it
encounters error in blk_mq_realloc_hw_ctxs, but the fallback flow will
continue using it, then blk_mq_map_swqueue will touch a invalid memory,
because the mapping points to a wrong hctx.blktest block/030:
null_blk: module loaded
Increasing nr_hw_queues to 8 fails, fallback to 1
==================================================================
BUG: KASAN: null-ptr-deref in blk_mq_map_swqueue+0x2f2/0x830
Read of size 8 at addr 0000000000000128 by task nproc/8541CPU: 5 PID: 8541 Comm: nproc Not tainted 5.7.0-rc4-dbg+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-0-gf21b5a4-rebuilt.opensuse.org 04/01/2014
Call Trace:
dump_stack+0xa5/0xe6
__kasan_report.cold+0x65/0xbb
kasan_report+0x45/0x60
check_memory_region+0x15e/0x1c0
__kasan_check_read+0x15/0x20
blk_mq_map_swqueue+0x2f2/0x830
__blk_mq_update_nr_hw_queues+0x3df/0x690
blk_mq_update_nr_hw_queues+0x32/0x50
nullb_device_submit_queues_store+0xde/0x160 [null_blk]
configfs_write_file+0x1c4/0x250 [configfs]
__vfs_write+0x4c/0x90
vfs_write+0x14b/0x2d0
ksys_write+0xdd/0x180
__x64_sys_write+0x47/0x50
do_syscall_64+0x6f/0x310
entry_SYSCALL_64_after_hwframe+0x49/0xb3Signed-off-by: Weiping Zhang
Tested-by: Bart van Assche
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin -
[ Upstream commit 579d1b3faa3735e781ff74aac0afd598515dbc63 ]
This patch fixes two issues present in the current function for encoding
arm64 logical immediates when using the 32-bit variants of instructions.First, the code does not correctly reject an all-ones 32-bit immediate,
and returns an undefined instruction encoding.Second, the code incorrectly rejects some 32-bit immediates that are
actually encodable as logical immediates. The root cause is that the code
uses a default mask of 64-bit all-ones, even for 32-bit immediates.
This causes an issue later on when the default mask is used to fill the
top bits of the immediate with ones, shown here:/*
* Pattern: 0..01..10..01..1
*
* Fill the unused top bits with ones, and check if
* the result is a valid immediate (all ones with a
* contiguous ranges of zeroes).
*/
imm |= ~mask;
if (!range_of_ones(~imm))
return AARCH64_BREAK_FAULT;To see the problem, consider an immediate of the form 0..01..10..01..1,
where the upper 32 bits are zero, such as 0x80000001. The code checks
if ~(imm | ~mask) contains a range of ones: the incorrect mask yields
1..10..01..10..0, which fails the check; the correct mask yields
0..01..10..0, which succeeds.The fix for both issues is to generate a correct mask based on the
instruction immediate size, and use the mask to check for all-ones,
all-zeroes, and values wider than the mask.Currently, arch/arm64/kvm/va_layout.c is the only user of this function,
which uses 64-bit immediates and therefore won't trigger these bugs.We tested the new code against llvm-mc with all 1,302 encodable 32-bit
logical immediates and all 5,334 encodable 64-bit logical immediates.Fixes: ef3935eeebff ("arm64: insn: Add encoder for bitwise operations using literals")
Suggested-by: Will Deacon
Co-developed-by: Xi Wang
Signed-off-by: Xi Wang
Signed-off-by: Luke Nelson
Reviewed-by: Marc Zyngier
Link: https://lore.kernel.org/r/20200508181547.24783-2-luke.r.nels@gmail.com
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin -
[ Upstream commit fd689871bbfbb41cd77379d3e9e5f4def0f7d6c6 ]
Alloc new map and request for new hardware queue when increse
hardware queue count. Before this patch, it will show a
warning for each new hardware queue, but it's not enough, these
hctx have no maps and reqeust, when a bio was mapped to these
hardware queue, it will trigger kernel panic when get request
from these hctx.Test environment:
* A NVMe disk supports 128 io queues
* 96 cpus in systemA corner case can always trigger this panic, there are 96
io queues allocated for HCTX_TYPE_DEFAULT type, the corresponding kernel
log: nvme nvme0: 96/0/0 default/read/poll queues. Now we set nvme write
queues to 96, then nvme will alloc others(32) queues for read, but
blk_mq_update_nr_hw_queues does not alloc map and request for these new
added io queues. So when process read nvme disk, it will trigger kernel
panic when get request from these hardware context.Reproduce script:
nr=$(expr `cat /sys/block/nvme0n1/device/queue_count` - 1)
echo $nr > /sys/module/nvme/parameters/write_queues
echo 1 > /sys/block/nvme0n1/device/reset_controller
dd if=/dev/nvme0n1 of=/dev/null bs=4K count=1[ 8040.805626] ------------[ cut here ]------------
[ 8040.805627] WARNING: CPU: 82 PID: 12921 at block/blk-mq.c:2578 blk_mq_map_swqueue+0x2b6/0x2c0
[ 8040.805627] Modules linked in: nvme nvme_core nf_conntrack_netlink xt_addrtype br_netfilter overlay xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nft_counter nf_nat_tftp nf_conntrack_tftp nft_masq nf_tables_set nft_fib_inet nft_f
ib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack tun bridge nf_defrag_ipv6 nf_defrag_ipv4 stp llc ip6_tables ip_tables nft_compat rfkill ip_set nf_tables nfne
tlink sunrpc intel_rapl_msr intel_rapl_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass ipmi_ssif crct10dif_pclmul crc32_pclmul iTCO_wdt iTCO_vendor_support ghash_clmulni_intel intel_
cstate intel_uncore raid0 joydev intel_rapl_perf ipmi_si pcspkr mei_me ioatdma sg ipmi_devintf mei i2c_i801 dca lpc_ich ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c sd_mod ast i2c_algo_bit drm_vram_helper drm_ttm_helper ttm d
rm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
[ 8040.805637] ahci drm i40e libahci crc32c_intel libata t10_pi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: nvme_core]
[ 8040.805640] CPU: 82 PID: 12921 Comm: kworker/u194:2 Kdump: loaded Tainted: G W 5.6.0-rc5.78317c+ #2
[ 8040.805640] Hardware name: Inspur SA5212M5/YZMB-00882-104, BIOS 4.0.9 08/27/2019
[ 8040.805641] Workqueue: nvme-reset-wq nvme_reset_work [nvme]
[ 8040.805642] RIP: 0010:blk_mq_map_swqueue+0x2b6/0x2c0
[ 8040.805643] Code: 00 00 00 00 00 41 83 c5 01 44 39 6d 50 77 b8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 48 8b bb 98 00 00 00 89 d6 e8 8c 81 03 00 eb 83 0b e9 52 ff ff ff 0f 1f 00 0f 1f 44 00 00 41 57 48 89 f1 41 56
[ 8040.805643] RSP: 0018:ffffba590d2e7d48 EFLAGS: 00010246
[ 8040.805643] RAX: 0000000000000000 RBX: ffff9f013e1ba800 RCX: 000000000000003d
[ 8040.805644] RDX: ffff9f00ffff6000 RSI: 0000000000000003 RDI: ffff9ed200246d90
[ 8040.805644] RBP: ffff9f00f6a79860 R08: 0000000000000000 R09: 000000000000003d
[ 8040.805645] R10: 0000000000000001 R11: ffff9f0138c3d000 R12: ffff9f00fb3a9008
[ 8040.805645] R13: 000000000000007f R14: ffffffff96822660 R15: 000000000000005f
[ 8040.805645] FS: 0000000000000000(0000) GS:ffff9f013fa80000(0000) knlGS:0000000000000000
[ 8040.805646] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8040.805646] CR2: 00007f7f397fa6f8 CR3: 0000003d8240a002 CR4: 00000000007606e0
[ 8040.805647] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8040.805647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8040.805647] PKRU: 55555554
[ 8040.805647] Call Trace:
[ 8040.805649] blk_mq_update_nr_hw_queues+0x31b/0x390
[ 8040.805650] nvme_reset_work+0xb4b/0xeab [nvme]
[ 8040.805651] process_one_work+0x1a7/0x370
[ 8040.805652] worker_thread+0x1c9/0x380
[ 8040.805653] ? max_active_store+0x80/0x80
[ 8040.805655] kthread+0x112/0x130
[ 8040.805656] ? __kthread_parkme+0x70/0x70
[ 8040.805657] ret_from_fork+0x35/0x40
[ 8040.805658] ---[ end trace b5f13b1e73ccb5d3 ]---
[ 8229.365135] BUG: kernel NULL pointer dereference, address: 0000000000000004
[ 8229.365165] #PF: supervisor read access in kernel mode
[ 8229.365178] #PF: error_code(0x0000) - not-present page
[ 8229.365191] PGD 0 P4D 0
[ 8229.365201] Oops: 0000 [#1] SMP PTI
[ 8229.365212] CPU: 77 PID: 13024 Comm: dd Kdump: loaded Tainted: G W 5.6.0-rc5.78317c+ #2
[ 8229.365232] Hardware name: Inspur SA5212M5/YZMB-00882-104, BIOS 4.0.9 08/27/2019
[ 8229.365253] RIP: 0010:blk_mq_get_tag+0x227/0x250
[ 8229.365265] Code: 44 24 04 44 01 e0 48 8b 74 24 38 65 48 33 34 25 28 00 00 00 75 33 48 83 c4 40 5b 5d 41 5c 41 5d 41 5e c3 48 8d 68 10 4c 89 ef 8b 60 04 48 89 ee e8 dd f9 ff ff 83 f8 ff 75 c8 e9 67 fe ff ff
[ 8229.365304] RSP: 0018:ffffba590e977970 EFLAGS: 00010246
[ 8229.365317] RAX: 0000000000000000 RBX: ffff9f00f6a79860 RCX: ffffba590e977998
[ 8229.365333] RDX: 0000000000000000 RSI: ffff9f012039b140 RDI: ffffba590e977a38
[ 8229.365349] RBP: 0000000000000010 R08: ffffda58ff94e190 R09: ffffda58ff94e198
[ 8229.365365] R10: 0000000000000011 R11: ffff9f00f6a79860 R12: 0000000000000000
[ 8229.365381] R13: ffffba590e977a38 R14: ffff9f012039b140 R15: 0000000000000001
[ 8229.365397] FS: 00007f481c230580(0000) GS:ffff9f013f940000(0000) knlGS:0000000000000000
[ 8229.365415] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 8229.365428] CR2: 0000000000000004 CR3: 0000005f35e26004 CR4: 00000000007606e0
[ 8229.365444] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 8229.365460] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 8229.365476] PKRU: 55555554
[ 8229.365484] Call Trace:
[ 8229.365498] ? finish_wait+0x80/0x80
[ 8229.365512] blk_mq_get_request+0xcb/0x3f0
[ 8229.365525] blk_mq_make_request+0x143/0x5d0
[ 8229.365538] generic_make_request+0xcf/0x310
[ 8229.365553] ? scan_shadow_nodes+0x30/0x30
[ 8229.365564] submit_bio+0x3c/0x150
[ 8229.365576] mpage_readpages+0x163/0x1a0
[ 8229.365588] ? blkdev_direct_IO+0x490/0x490
[ 8229.365601] read_pages+0x6b/0x190
[ 8229.365612] __do_page_cache_readahead+0x1c1/0x1e0
[ 8229.365626] ondemand_readahead+0x182/0x2f0
[ 8229.365639] generic_file_buffered_read+0x590/0xab0
[ 8229.365655] new_sync_read+0x12a/0x1c0
[ 8229.365666] vfs_read+0x8a/0x140
[ 8229.365676] ksys_read+0x59/0xd0
[ 8229.365688] do_syscall_64+0x55/0x1d0
[ 8229.365700] entry_SYSCALL_64_after_hwframe+0x44/0xa9Signed-off-by: Ming Lei
Signed-off-by: Weiping Zhang
Tested-by: Weiping Zhang
Reviewed-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin -
[ Upstream commit 6bfe5344b2956d0bee116f1c640aef05e5cddd76 ]
ACPICA commit 3244c1eeba9f9fb9ccedb875f7923a3d85e0c6aa
The status chekcs are used to to avoid NULL pointer dereference on
field objectsLink: https://github.com/acpica/acpica/commit/3244c1ee
Reported-by: Kurt Kennett
Signed-off-by: Erik Kaneda
Signed-off-by: Bob Moore
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin -
[ Upstream commit 3cb97e223d277f84171cc4ccecab31e08b2ee7b5 ]
Some DMA controller drivers do not tolerate non-zero values in
the DMA configuration structures. Zero them to avoid issues with
such DMA controller drivers. Even despite above this is a good
practice per se.Fixes: 7063c0d942a1 ("spi/dw_spi: add DMA support")
Signed-off-by: Andy Shevchenko
Acked-by: Feng Tang
Cc: Feng Tang
Link: https://lore.kernel.org/r/20200506153025.21441-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 191f6b08bfef24e1a9641eaac96ed030a7be4599 ]
the related system resources were not released when pci_iomap() return
error in the rtw_pci_io_mapping() function. add pci_release_regions() to
fix it.Fixes: e3037485c68ec1a ("rtw88: new Realtek 802.11ac driver")
Cc: Andy Shevchenko
Signed-off-by: Dejin Zheng
Acked-by: Yan-Hsuan Chuang
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/20200504083442.3033-1-zhengdejin5@gmail.com
Signed-off-by: Sasha Levin -
[ Upstream commit 735a02f1bbc2c5e6e9cdbf0222948ff03ff7ab2d ]
When queuing parameters fails, current code bails out without deleting
the corresponding vb2 buffer from the driver buffer list, but the buffer
is returned to vb2. This leads to stale list entries and a crash when
the driver stops streaming:[ 224.935561] ipu3-imgu 0000:00:05.0: set parameters failed.
[ 224.998932] ipu3-imgu 0000:00:05.0: set parameters failed.
[ 225.064430] ipu3-imgu 0000:00:05.0: set parameters failed.
[ 225.128534] ipu3-imgu 0000:00:05.0: set parameters failed.
[ 225.194945] ipu3-imgu 0000:00:05.0: set parameters failed.
[ 225.360363] ------------[ cut here ]------------
[ 225.360372] WARNING: CPU: 0 PID: 6704 at
drivers/media/common/videobuf2/videobuf2-core.c:927
vb2_buffer_done+0x20f/0x21a [videobuf2_common]
[ 225.360374] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
veth bridge stp llc tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
nf_conntrack_ftp esp6 ah6 ip6t_REJECT ip6t_ipv6header cmac rfcomm uinput
ipu3_imgu(C) ipu3_cio2 iova videobuf2_v4l2 videobuf2_common
videobuf2_dma_sg videobuf2_memops ov13858 ov5670 v4l2_fwnode dw9714
acpi_als xt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring
cros_ec_light_prox cros_ec_sensors cros_ec_sensors_core
industrialio_triggered_buffer kfifo_buf industrialio
cros_ec_sensorsupport cdc_ether btusb btrtl btintel btbcm usbnet
bluetooth ecdh_generic ecc hid_google_hammer iwlmvm iwl7000_mac80211
r8152 mii lzo_rle lzo_compress iwlwifi zram cfg80211 joydev
[ 225.360400] CPU: 0 PID: 6704 Comm: CameraDeviceOps Tainted: G
C 5.4.30 #5
[ 225.360402] Hardware name: HP Soraka/Soraka, BIOS
Google_Soraka.10431.106.0 12/03/2019
[ 225.360405] RIP: 0010:vb2_buffer_done+0x20f/0x21a [videobuf2_common]
[ 225.360408] Code: 5e 41 5f 5d e9 e0 16 5a d4 41 8b 55 08 48 c7 c7 8f
8b 5c c0 48 c7 c6 36 9a 5c c0 44 89 f9 31 c0 e8 a5 1c 5b d4 e9 53 fe ff
ff 0b eb a3 e8 12 d7 43 d4 eb 97 0f 1f 44 00 00 55 48 89 e5 41 56
[ 225.360410] RSP: 0018:ffff9468ab32fba8 EFLAGS: 00010297
[ 225.360412] RAX: ffff8aa7a51577a8 RBX: dead000000000122 RCX:
ffff8aa7a51577a8
[ 225.360414] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
ffff8aa7a5157400
[ 225.360416] RBP: ffff9468ab32fbd8 R08: ffff8aa64e47e600 R09:
0000000000000000
[ 225.360418] R10: 0000000000000000 R11: ffffffffc06036e6 R12:
dead000000000100
[ 225.360420] R13: ffff8aa7820f1940 R14: ffff8aa7a51577a8 R15:
0000000000000006
[ 225.360422] FS: 00007c1146ffd700(0000) GS:ffff8aa7baa00000(0000)
knlGS:0000000000000000
[ 225.360424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 225.360426] CR2: 00007aea3473a000 CR3: 00000000537d6004 CR4:
00000000003606f0
[ 225.360427] Call Trace:
[ 225.360434] imgu_return_all_buffers+0x6f/0x8e [ipu3_imgu]
[ 225.360438] imgu_vb2_stop_streaming+0xd6/0xf0 [ipu3_imgu]
[ 225.360441] __vb2_queue_cancel+0x33/0x22d [videobuf2_common]
[ 225.360443] vb2_core_streamoff+0x16/0x78 [videobuf2_common]
[ 225.360448] __video_do_ioctl+0x33d/0x42a
[ 225.360452] video_usercopy+0x34a/0x615
[ 225.360455] ? video_ioctl2+0x16/0x16
[ 225.360458] v4l2_ioctl+0x46/0x53
[ 225.360462] do_vfs_ioctl+0x50a/0x787
[ 225.360465] ksys_ioctl+0x58/0x83
[ 225.360468] __x64_sys_ioctl+0x1a/0x1e
[ 225.360470] do_syscall_64+0x54/0x68
[ 225.360474] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 225.360476] RIP: 0033:0x7c118030f497
[ 225.360479] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48
[ 225.360480] RSP: 002b:00007c1146ffa5a8 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[ 225.360483] RAX: ffffffffffffffda RBX: 00007c1140010018 RCX:
00007c118030f497
[ 225.360484] RDX: 00007c114001019c RSI: 0000000040045613 RDI:
000000000000004c
[ 225.360486] RBP: 00007c1146ffa700 R08: 00007c1140010048 R09:
0000000000000000
[ 225.360488] R10: 0000000000000000 R11: 0000000000000246 R12:
00007c11400101b0
[ 225.360489] R13: 00007c1140010200 R14: 00007c1140010048 R15:
0000000000000001
[ 225.360492] ---[ end trace 73625ecfbd1c930e ]---
[ 225.360498] general protection fault: 0000 [#1] PREEMPT SMP PTI
[ 225.360501] CPU: 0 PID: 6704 Comm: CameraDeviceOps Tainted: G
WC 5.4.30 #5
[ 225.360502] Hardware name: HP Soraka/Soraka, BIOS
Google_Soraka.10431.106.0 12/03/2019
[ 225.360505] RIP: 0010:imgu_return_all_buffers+0x52/0x8e [ipu3_imgu]
[ 225.360507] Code: d4 49 8b 85 70 0a 00 00 49 81 c5 70 0a 00 00 49 39
c5 74 3b 49 bc 00 01 00 00 00 00 ad de 49 8d 5c 24 22 4c 8b 30 48 8b 48
08 89 4e 08 4c 89 31 4c 89 20 48 89 58 08 48 8d b8 58 fc ff ff 44
[ 225.360509] RSP: 0018:ffff9468ab32fbe8 EFLAGS: 00010293
[ 225.360511] RAX: ffff8aa7a51577a8 RBX: dead000000000122 RCX:
dead000000000122
[ 225.360512] RDX: 0000000000000000 RSI: 0000000000000006 RDI:
ffff8aa7a5157400
[ 225.360514] RBP: ffff9468ab32fc18 R08: ffff8aa64e47e600 R09:
0000000000000000
[ 225.360515] R10: 0000000000000000 R11: ffffffffc06036e6 R12:
dead000000000100
[ 225.360517] R13: ffff8aa7820f1940 R14: dead000000000100 R15:
0000000000000006
[ 225.360519] FS: 00007c1146ffd700(0000) GS:ffff8aa7baa00000(0000)
knlGS:0000000000000000
[ 225.360521] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 225.360523] CR2: 00007aea3473a000 CR3: 00000000537d6004 CR4:
00000000003606f0
[ 225.360525] Call Trace:
[ 225.360528] imgu_vb2_stop_streaming+0xd6/0xf0 [ipu3_imgu]
[ 225.360531] __vb2_queue_cancel+0x33/0x22d [videobuf2_common]
[ 225.360534] vb2_core_streamoff+0x16/0x78 [videobuf2_common]
[ 225.360537] __video_do_ioctl+0x33d/0x42a
[ 225.360540] video_usercopy+0x34a/0x615
[ 225.360542] ? video_ioctl2+0x16/0x16
[ 225.360546] v4l2_ioctl+0x46/0x53
[ 225.360548] do_vfs_ioctl+0x50a/0x787
[ 225.360551] ksys_ioctl+0x58/0x83
[ 225.360554] __x64_sys_ioctl+0x1a/0x1e
[ 225.360556] do_syscall_64+0x54/0x68
[ 225.360559] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 225.360561] RIP: 0033:0x7c118030f497
[ 225.360563] Code: 8a 66 90 48 8b 05 d1 d9 2b 00 64 c7 00 26 00 00 00
48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f
05 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 d9 2b 00 f7 d8 64 89 01 48
[ 225.360565] RSP: 002b:00007c1146ffa5a8 EFLAGS: 00000246 ORIG_RAX:
0000000000000010
[ 225.360567] RAX: ffffffffffffffda RBX: 00007c1140010018 RCX:
00007c118030f497
[ 225.360569] RDX: 00007c114001019c RSI: 0000000040045613 RDI:
000000000000004c
[ 225.360570] RBP: 00007c1146ffa700 R08: 00007c1140010048 R09:
0000000000000000
[ 225.360572] R10: 0000000000000000 R11: 0000000000000246 R12:
00007c11400101b0
[ 225.360574] R13: 00007c1140010200 R14: 00007c1140010048 R15:
0000000000000001
[ 225.360576] Modules linked in: snd_seq_dummy snd_seq snd_seq_device
veth bridge stp llc tun nf_nat_tftp nf_conntrack_tftp nf_nat_ftp
nf_conntrack_ftp esp6 ah6 ip6t_REJECT ip6t_ipv6header cmac rfcomm uinput
ipu3_imgu(C) ipu3_cio2 iova videobuf2_v4l2 videobuf2_common
videobuf2_dma_sg videobuf2_memops ov13858 ov567Fix this by moving the list_del() call just below the list_first_entry()
call when the buffer no longer needs to be in the list.Fixes: 8ecc7c9da013 ("media: staging/intel-ipu3: parameter buffer refactoring")
Signed-off-by: Tomasz Figa
Reviewed-by: Laurent Pinchart
Reviewed-by: Bingbu Cao
Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin -
[ Upstream commit ab8ad279ceac4fc78ae4dcf1a26326e05695e537 ]
flush_icache_range() contains a bodge to avoid issuing IPIs when the kgdb
trap handler is running because issuing IPIs is unsafe (and not needed)
in this execution context. However the current test, based on
kgdb_connected is flawed: it both over-matches and under-matches.The over match occurs because kgdb_connected is set when gdb attaches
to the stub and remains set during normal running. This is relatively
harmelss because in almost all cases irq_disabled() will be false.The under match is more serious. When kdb is used instead of kgdb to access
the debugger then kgdb_connected is not set in all the places that the
debug core updates sw breakpoints (and hence flushes the icache). This
can lead to deadlock.Fix by replacing the ad-hoc check with the proper kgdb macro. This also
allows us to drop the #ifdef wrapper.Fixes: 3b8c9f1cdfc5 ("arm64: IPI each CPU after invalidating the I-cache for kernel mappings")
Signed-off-by: Daniel Thompson
Reviewed-by: Douglas Anderson
Link: https://lore.kernel.org/r/20200504170518.2959478-1-daniel.thompson@linaro.org
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin -
[ Upstream commit d431f8939c1419854dfe89dd345387f5397c6edd ]
The struct cfg80211_wowlan of NET_DETECT WoWLAN feature share the same
struct cfg80211_sched_scan_request together with scheduled scan request
feature, and max_sched_scan_reqs of wiphy is only used for sched scan,
and ath10k does not support scheduled scan request feature, so ath10k
does not set flag NL80211_FEATURE_SCHED_SCAN_RANDOM_MAC_ADDR, but ath10k
set max_sched_scan_reqs of wiphy to a non zero value 1, then function
nl80211_add_commands_unsplit of cfg80211 will set it support command
NL80211_CMD_START_SCHED_SCAN because max_sched_scan_reqs is a non zero
value, but actually ath10k not support it, then it leads a mismatch result
for sched scan of cfg80211, then application shill found the mismatch and
stop running case of MAC random address scan and then the case fail.After remove max_sched_scan_reqs value, it keeps match for sched scan and
case of MAC random address scan pass.Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00029.
Tested with QCA6174 PCIe with firmware WLAN.RM.4.4.1-00110-QCARMSWP-1.Fixes: ce834e280f2f875 ("ath10k: support NET_DETECT WoWLAN feature")
Signed-off-by: Wen Gong
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/20191114050001.4658-1-wgong@codeaurora.org
Signed-off-by: Sasha Levin -
[ Upstream commit f77767ed5f4d398b29119563155e4ece2dfeee13 ]
When building the x86 EFI stub with Clang, the libstub Makefile rules
that manipulate the ELF object files may throw an error like:STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o
strip: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10
objcopy: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10This is the result of a LLVM feature [0] where symbol references are
stored in a LLVM specific .llvm_addrsig section in a non-transparent way,
causing generic ELF tools such as strip or objcopy to choke on them.So force the compiler not to emit these sections, by passing the
appropriate command line option.[0] https://sourceware.org/bugzilla/show_bug.cgi?id=23817
Cc: Nick Desaulniers
Cc: Peter Collingbourne
Cc: Sami Tolvanen
Reported-by: Arnd Bergmann
Suggested-by: Fangrui Song
Signed-off-by: Ard Biesheuvel
Signed-off-by: Sasha Levin -
[ Upstream commit e9a1de378dd46375f9abfd8de1e6f59ee114a793 ]
In case the "func" parameter is NULL we now return "-EINVAL".
This shouldn't happen in general, but when it does happen, this is the
proper way to handle it.We also check func for NULL in the beginning of the function, as there
is no reason to do all the work and realize in the end of the function
it was useless.Signed-off-by: Sameeh Jubran
Signed-off-by: Arthur Kiyanovski
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin -
[ Upstream commit d0f23741c202c685447050713907f3be39a985ee ]
This patch fixes potential crash in case if hw_get_regs is NULL.
Signed-off-by: Mark Starovoytov
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin -
[ Upstream commit 5a6d6a6ccb5f48ca8cf7c6d64ff83fd9c7999390 ]
In order to prevent possible hardlockup of sched_cfs_period_timer()
loop, loop count is introduced to denote whether to scale quota and
period or not. However, scale is done between forwarding period timer
and refilling cfs bandwidth runtime, which means that period timer is
forwarded with old "period" while runtime is refilled with scaled
"quota".Move do_sched_cfs_period_timer() before scaling to solve this.
Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup")
Signed-off-by: Huaixin Chang
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Ben Segall
Reviewed-by: Phil Auld
Link: https://lkml.kernel.org/r/20200420024421.22442-3-changhuaixin@linux.alibaba.com
Signed-off-by: Sasha Levin -
[ Upstream commit 1ff865e343c2b59469d7e41d370a980a3f972c71 ]
As reported by objtool:
lib/ubsan.o: warning: objtool: .altinstr_replacement+0x0: alternative modifies stack
lib/ubsan.o: warning: objtool: .altinstr_replacement+0x7: alternative modifies stackthe smap_{save,restore}() alternatives violate (the newly enforced)
rule on stack invariance. That is, due to there only being a single
ORC table it must be valid to any alternative. These alternatives
violate this with the direct result that unwinds will not be correct
when it hits between the PUSH and POP instructions.Rewrite the functions to only have a conditional jump.
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Acked-by: Josh Poimboeuf
Link: https://lkml.kernel.org/r/20200429101802.GI13592@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin -
[ Upstream commit 6eefaee4f2d366a389da0eb95e524ba82bf358c4 ]
With a couple allies at Intel, and much badgering, I got confirmation
from Intel that at least BXT suffers from the same SPI chip-select
issue as Cannonlake (and beyond). The issue being that after going
through runtime suspend/resume, toggling the chip-select line without
also sending data does nothing.Add the quirk to BXT to briefly toggle dynamic clock gating off and
on, forcing the fabric to wake up enough to notice the CS register
change.Signed-off-by: Evan Green
Cc: Shobhit Srivastava
Cc: Andy Shevchenko
Link: https://lore.kernel.org/r/20200427163238.1.Ib1faaabe236e37ea73be9b8dcc6aa034cb3c8804@changeid
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 229bf8bf4d910510bc1a2fd0b89bd467cd71050d ]
Fix memory leak in hashmap_clear() not freeing hashmap_entry structs for each
of the remaining entries. Also NULL-out bucket list to prevent possible
double-free between hashmap__clear() and hashmap__free().Running test_progs-asan flavor clearly showed this problem.
Reported-by: Alston Tang
Signed-off-by: Andrii Nakryiko
Signed-off-by: Alexei Starovoitov
Link: https://lore.kernel.org/bpf/20200429012111.277390-5-andriin@fb.com
Signed-off-by: Sasha Levin -
[ Upstream commit 9d2d75ede59bc1edd8561f2ee9d4702a5ea0ae30 ]
Prior to commit 8eb7e28d4c642c31 ("arm64/mm: move runtime pgds to
rodata"), idmap_pgd_dir, tramp_pg_dir, reserved_ttbr0, swapper_pg_dir,
and init_pg_dir were contiguous at the end of the kernel image. The
maintenance at the end of __create_page_tables assumed these were
contiguous, and affected everything from the start of idmap_pg_dir
to the end of init_pg_dir.That commit moved all but init_pg_dir into the .rodata section, with
other data placed between idmap_pg_dir and init_pg_dir, but did not
update the maintenance. Hence the maintenance is performed on much
more data than necessary (but as the bootloader previously made this
clean to the PoC there is no functional problem).As we only alter idmap_pg_dir, and init_pg_dir, we only need to perform
maintenance for these. As the other dirs are in .rodata, the bootloader
will have initialised them as expected and cleaned them to the PoC. The
kernel will initialize them as necessary after enabling the MMU.This patch reworks the maintenance to only cover the idmap_pg_dir and
init_pg_dir to avoid this unnecessary work.Signed-off-by: Gavin Shan
Reviewed-by: Mark Rutland
Link: https://lore.kernel.org/r/20200427235700.112220-1-gshan@redhat.com
Signed-off-by: Will Deacon
Signed-off-by: Sasha Levin -
[ Upstream commit 6f81b2d047c59eb77cd04795a44245d6a52cdaec ]
For chip like CHIP_OLAND with si enabled(amdgpu.si_support=1),
the amdgpu will expose pp_num_states to the /sys directory.
In this moment, read the pp_num_states file will excute the
amdgpu_get_pp_num_states func. In our case, the data hasn't
been initialized, so the kernel will access some ilegal
address, trigger the segmentfault and system will reboot soon:uos@uos-PC:~$ cat /sys/devices/pci0000\:00/0000\:00\:00.0/0000\:01\:00
.0/pp_num_statesMessage from syslogd@uos-PC at Apr 22 09:26:20 ...
kernel:[ 82.154129] Internal error: Oops: 96000004 [#1] SMPThis patch aims to fix this problem, avoid that reading file
triggers the kernel sementfault.Signed-off-by: limingyu
Signed-off-by: zhoubinbin
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin -
[ Upstream commit 80300a7d5f2d7178335652f41d2e55ba898b4ec1 ]
Currently buswidths 2 and 4 are rejected for a device that advertises
Octal capabilities. Allow these buswidths, just like is done for
buswidth 2 and Quad-capable devices.Fixes: b12a084c8729ef42 ("spi: spi-mem: add support for octal mode I/O data transfer")
Signed-off-by: Geert Uytterhoeven
Link: https://lore.kernel.org/r/20200416101418.14379-1-geert+renesas@glider.be
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin -
[ Upstream commit 7170cf47d16f1ba29eca07fd818870b7af0a93a5 ]
The .alternatives section can contain entries with no original
instructions. Objtool will currently crash when handling such an entry.Just skip that entry, but still give a warning to discourage useless
entries.Signed-off-by: Julien Thierry
Acked-by: Peter Zijlstra (Intel)
Reviewed-by: Miroslav Benes
Signed-off-by: Josh Poimboeuf
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin -
[ Upstream commit e955f959ac52e145f27ff2be9078b646d0352af0 ]
Getting the Xtal trim property to check if running is less error prone.
Reset if_frequency if state is unknown.Replaces the previous "garbage check".
Signed-off-by: Brad Love
Signed-off-by: Sean Young
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin -
[ Upstream commit f36592e7b343d853edf44d3545bb68961c0949a4 ]
If these functions fail then we return success, but we should instead
preserve negative error code and return that.Fixes: fde649b418d1 ("media: vicodec: Register another node for stateless decoder")
Fixes: c022a4a95722 ("media: vicodec: add struct for encoder/decoder instance")
Signed-off-by: Dan Carpenter
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin -
[ Upstream commit eebac678556d6927f09a992872f4464cf3aecc76 ]
DMADEVICES is the top-level option for the slave DMA
subsystem, and should not be selected by device drivers,
as this can cause circular dependencies such as:drivers/net/ethernet/freescale/Kconfig:6:error: recursive dependency detected!
drivers/net/ethernet/freescale/Kconfig:6: symbol NET_VENDOR_FREESCALE depends on PPC_BESTCOMM
drivers/dma/bestcomm/Kconfig:6: symbol PPC_BESTCOMM depends on DMADEVICES
drivers/dma/Kconfig:6: symbol DMADEVICES is selected by CRYPTO_DEV_SP_CCP
drivers/crypto/ccp/Kconfig:10: symbol CRYPTO_DEV_SP_CCP depends on CRYPTO
crypto/Kconfig:16: symbol CRYPTO is selected by LIBCRC32C
lib/Kconfig:222: symbol LIBCRC32C is selected by LIQUIDIO
drivers/net/ethernet/cavium/Kconfig:65: symbol LIQUIDIO depends on PTP_1588_CLOCK
drivers/ptp/Kconfig:8: symbol PTP_1588_CLOCK is implied by FEC
drivers/net/ethernet/freescale/Kconfig:23: symbol FEC depends on NET_VENDOR_FREESCALEThe LIQUIDIO driver causing this problem is addressed in a
separate patch, but this change is needed to prevent it from
happening again.Using "depends on DMADEVICES" is what we do for all other
implementations of slave DMA controllers as well.Fixes: b3c2fee5d66b ("crypto: ccp - Ensure all dependencies are specified")
Signed-off-by: Arnd Bergmann
Acked-by: Tom Lendacky
Signed-off-by: Herbert Xu
Signed-off-by: Sasha Levin -
[ Upstream commit d321dd233b9f2bb407b8e6b4759408f09ec207c3 ]
The subdev set pad format operation currently misbehaves in multiple ways:
- mipi_csis_try_format() unconditionally stores the format in the device
state, even for V4L2_SUBDEV_FORMAT_TRY.- The format is never stored in the pad cfg, but the pad cfg format
always overwrites the format requested by the user.- The sink format is not propagated to the source.
Fix all this by reworking the set format operation as follows:
1. For the source pad, turn set() into get() as the source format is not
modifiable.
2. Validate the requested format and updated the stored format
accordingly.
3. Return the format actually set.
4. Propagate the format from sink to source.Signed-off-by: Laurent Pinchart
Acked-by: Rui Miguel Silva
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin -
[ Upstream commit e1ebe9f9c88e5a78fcc4670a9063c9b3cd87dda4 ]
ImgU need set the mmu page table in memory as uncached, and set back
to write-back when free the page table by set_memory_wb(),
set_memory_wb() can not do flushing without interrupt, so the spinlock
should not be hold during ImgU page alloc and free, the interrupt
should be enabled during memory cache flush.This patch release spinlock before freeing pages table.
Signed-off-by: Bingbu Cao
Reviewed-by: Tomasz Figa
Signed-off-by: Sakari Ailus
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Sasha Levin -
[ Upstream commit b97b6a1f6e14a25d1e1ca2a46c5fa3e2ca374e22 ]
ADV7511 support sample rates up to 192kHz. CTS and N parameters should
be computed accordingly so this commit extend the list up to maximum
supported sample rate.Signed-off-by: Bogdan Togorean
Reviewed-by: Andrzej Hajda
Signed-off-by: Andrzej Hajda
Link: https://patchwork.freedesktop.org/patch/msgid/20200413113513.86091-2-bogdan.togorean@analog.com
Signed-off-by: Sasha Levin -
[ Upstream commit 3d1c60460fb2823a19ead9e6ec8f184dd7271aa7 ]
There is a race condition, when the user writes 'hw-restart' and
'hard' in the simulate_fw_crash debugfs file without any delay.
In the above scenario, the firmware dump work queue(scheduled by
'hard') should be handled gracefully, while the target is in the
'hw-restart'.Tested HW: QCA9984
Tested FW: 10.4-3.9.0.2-00044Co-developed-by: Govindaraj Saminathan
Signed-off-by: Govindaraj Saminathan
Signed-off-by: Maharaja Kennadyrajan
Signed-off-by: Kalle Valo
Link: https://lore.kernel.org/r/1585213077-28439-1-git-send-email-mkenna@codeaurora.org
Signed-off-by: Sasha Levin -
[ Upstream commit 82c416b13cb7d22b96ec0888b296a48dff8a09eb ]
The problem is that we can't add the clear fence to the BO
when there is an exclusive fence on it since we can't
guarantee the the clear fence will complete after the
exclusive one.To fix this refactor the function and also add the exclusive
fence as shared to the resv object.v2: fix warning
v3: add excl fence as shared instead
v4: squash in fix for fence handling in amdgpu_gem_object_closeSigned-off-by: Christian König
Reviewed-by: xinhui pan
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin -
commit e5c399b0bd6490c12c0af2a9eaa9d7cd805d52c9 upstream.
Commit ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler
methods") added a reference to the 'triggering' field of either the
normal or the extended ACPI IRQ resource struct, but inadvertently used
the wrong pointer in the latter case. Note that both pointers refer to the
same union, and the 'triggering' field appears at the same offset in both
struct types, so it currently happens to work by accident. But let's fix
it nonethelessFixes: ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler methods")
Signed-off-by: Ard Biesheuvel
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
17 Jun, 2020
11 commits
-
commit ef3e40a7ea8dbe2abd0a345032cd7d5023b9684f upstream.
When using the PtrAuth feature in a guest, we need to save the host's
keys before allowing the guest to program them. For that, we dump
them in a per-CPU data structure (the so called host context).But both call sites that do this are in preemptible context,
which may end up in disaster should the vcpu thread get preempted
before reentering the guest.Instead, save the keys eagerly on each vcpu_load(). This has an
increased overhead, but is at least safe.Cc: stable@vger.kernel.org
Reviewed-by: Mark Rutland
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman -
commit 0370964dd3ff7d3d406f292cb443a927952cbd05 upstream.
On a VHE system, the EL1 state is left in the CPU most of the time,
and only syncronized back to memory when vcpu_put() is called (most
of the time on preemption).Which means that when injecting an exception, we'd better have a way
to either:
(1) write directly to the EL1 sysregs
(2) synchronize the state back to memory, and do the changes thereFor an AArch64, we already do (1), so we are safe. Unfortunately,
doing the same thing for AArch32 would be pretty invasive. Instead,
we can easily implement (2) by calling the put/load architectural
backends, and keep preemption disabled. We can then reload the
state back into EL1.Cc: stable@vger.kernel.org
Reported-by: James Morse
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman -
commit c8d70a29d6bbc956013f3401f92a4431a9385a3c upstream.
backend_connect() can fail, so switch the device to connected only if
no error occurred.Fixes: 0a9c75c2c7258f2 ("xen/pvcalls: xenbus state handling")
Cc: stable@vger.kernel.org
Signed-off-by: Juergen Gross
Link: https://lore.kernel.org/r/20200511074231.19794-1-jgross@suse.com
Reviewed-by: Stefano Stabellini
Signed-off-by: Boris Ostrovsky
Signed-off-by: Greg Kroah-Hartman -
commit 263c61581a38d0a5ad1f5f4a9143b27d68caeffd upstream.
Since the switch of floppy driver to blk-mq, the contended (fdc_busy) case
in floppy_queue_rq() is not handled correctly.In case we reach floppy_queue_rq() with fdc_busy set (i.e. with the floppy
locked due to another request still being in-flight), we put the request
on the list of requests and return BLK_STS_OK to the block core, without
actually scheduling delayed work / doing further processing of the
request. This means that processing of this request is postponed until
another request comes and passess uncontended.Which in some cases might actually never happen and we keep waiting
indefinitely. The simple testcase isfor i in `seq 1 2000`; do echo -en $i '\r'; blkid --info /dev/fd0 2> /dev/null; done
run in quemu. That reliably causes blkid eventually indefinitely hanging
in __floppy_read_block_0() waiting for completion, as the BIO callback
never happens, and no further IO is ever submitted on the (non-existent)
floppy device. This was observed reliably on qemu-emulated device.Fix that by not queuing the request in the contended case, and return
BLK_STS_RESOURCE instead, so that blk core handles the request
rescheduling and let it pass properly non-contended later.Fixes: a9f38e1dec107a ("floppy: convert to blk-mq")
Cc: stable@vger.kernel.org
Tested-by: Libor Pechacek
Signed-off-by: Jiri Kosina
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit a94a59f43749b4f8cd81b8be87c95f9ef898d19d upstream.
Over the years, the code in mmc_sdio_init_card() has grown to become quite
messy. Unfortunate this has also lead to that several paths are leaking
memory in form of an allocated struct mmc_card, which includes additional
data, such as initialized struct device for example.Unfortunate, it's a too complex task find each offending commit. Therefore,
this change fixes all memory leaks at once.Cc:
Signed-off-by: Ulf Hansson
Link: https://lore.kernel.org/r/20200430091640.455-3-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman -
commit f04086c225da11ad16d7f9a2fbca6483ab16dded upstream.
During some scenarios mmc_sdio_init_card() runs a retry path for the UHS-I
specific initialization, which leads to removal of the previously allocated
card. A new card is then re-allocated while retrying.However, in one of the corresponding error paths we may end up to remove an
already removed card, which likely leads to a NULL pointer exception. So,
let's fix this.Fixes: 5fc3d80ef496 ("mmc: sdio: don't use rocr to check if the card could support UHS mode")
Cc:
Signed-off-by: Ulf Hansson
Link: https://lore.kernel.org/r/20200430091640.455-2-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman -
commit a1af7f36c70369b971ee1cf679dd68368dad23f0 upstream.
Remove non-removable and mmc-ddr-1_8v properties from the sdmmc0
node which come probably from an unchecked copy/paste.Signed-off-by: Ludovic Desroches
Fixes:42ed535595ec "ARM: dts: at91: introduce the sama5d2 ptc ek board"
Cc: stable@vger.kernel.org # 4.19 and later
Link: https://lore.kernel.org/r/20200401221504.41196-1-ludovic.desroches@microchip.com
Signed-off-by: Alexandre Belloni
Signed-off-by: Greg Kroah-Hartman -
commit 5d1f42e14b135773c0cc1d82e904c5b223783a9d upstream.
Currently, tmio_mmc_irq() handler is registered before the host is
fully initialized by tmio_mmc_host_probe(). I did not previously notice
this problem.The boot ROM of a new Socionext SoC unmasks interrupts (CTL_IRQ_MASK)
somehow. The handler is invoked before tmio_mmc_host_probe(), then
emits noisy call trace.Move devm_request_irq() below tmio_mmc_host_probe().
Fixes: 3fd784f745dd ("mmc: uniphier-sd: add UniPhier SD/eMMC controller driver")
Signed-off-by: Masahiro Yamada
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200511062158.1790924-1-yamada.masahiro@socionext.com
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 4bd784411aca022622e484eb262f5a0540ae732c upstream.
Before calling tmio_mmc_host_probe(), the caller is required to enable
clocks for its device, as to make it accessible when reading/writing
registers during probe.Therefore, the responsibility to disable these clocks, in the error path of
->probe() and during ->remove(), is better managed outside
tmio_mmc_host_remove(). As a matter of fact, callers of
tmio_mmc_host_remove() already expects this to be the behaviour.However, there's a problem with tmio_mmc_host_remove() when the Kconfig
option, CONFIG_PM, is set. More precisely, tmio_mmc_host_remove() may then
disable the clock via runtime PM, which leads to clock enable/disable
imbalance problems, when the caller of tmio_mmc_host_remove() also tries to
disable the same clocks.To solve the problem, let's make sure tmio_mmc_host_remove() leaves the
device with clocks enabled, but also make sure to disable the IRQs, as we
normally do at ->runtime_suspend().Reported-by: Geert Uytterhoeven
Reviewed-by: Wolfram Sang
Tested-by: Wolfram Sang
Signed-off-by: Ulf Hansson
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200519152434.6867-1-ulf.hansson@linaro.org
Tested-by: Geert Uytterhoeven
Signed-off-by: Greg Kroah-Hartman -
commit fe8d33bd33d527dee3155d2bccd714a655f37334 upstream.
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
WARNING: CPU: 1 PID: 20 at kernel/dma/debug.c:500 add_dma_entry+0x16c/0x17c
DMA-API: exceeded 7 overlapping mappings of cacheline 0x031d2645
Modules linked in:
CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.5.0-rc2-00021-gdeda30999c2b-dirty #49
Hardware name: STM32 (Device Tree Support)
Workqueue: events_freezable mmc_rescan
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xc0/0xd4)
[] (dump_stack) from [] (__warn+0xd0/0xf8)
[] (__warn) from [] (warn_slowpath_fmt+0x94/0xb8)
[] (warn_slowpath_fmt) from [] (add_dma_entry+0x16c/0x17c)
[] (add_dma_entry) from [] (debug_dma_map_sg+0xe4/0x3d4)
[] (debug_dma_map_sg) from [] (sdmmc_idma_prep_data+0x94/0xf8)
[] (sdmmc_idma_prep_data) from [] (mmci_prep_data+0x2c/0xb0)
[] (mmci_prep_data) from [] (mmci_start_data+0x134/0x2f0)
[] (mmci_start_data) from [] (mmci_request+0xe8/0x154)
[] (mmci_request) from [] (mmc_start_request+0x94/0xbc)DMA api debug brings to light leaking dma-mappings, dma_map_sg and
dma_unmap_sg are not correctly balanced.If a request is prepared, the dma_map/unmap are done in asynchronous call
pre_req (prep_data) and post_req (unprep_data). In this case the
dma-mapping is right balanced.But if the request was not prepared, the data->host_cookie is define to
zero and the dma_map/unmap must be done in the request. The dma_map is
called by mmci_dma_start (prep_data), but there is no dma_unmap in this
case.This patch adds dma_unmap_sg when the dma is finalized and the data cookie
is zero (request not prepared).Signed-off-by: Ludovic Barre
Link: https://lore.kernel.org/r/20200526155103.12514-2-ludovic.barre@st.com
Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant")
Cc: stable@vger.kernel.org
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman
