Jesper Dangaard Brouer [Thu, 23 Apr 2020 14:57:50 +0000 (16:57 +0200)]
dpaa2-eth: fix return codes used in ndo_setup_tc
[ Upstream commit
b89c1e6bdc73f5775e118eb2ab778e75b262b30c ]
Drivers ndo_setup_tc call should return -EOPNOTSUPP, when it cannot
support the qdisc type. Other return values will result in failing the
qdisc setup. This lead to qdisc noop getting assigned, which will
drop all TX packets on the interface.
Fixes:
ab1e6de2bd49 ("dpaa2-eth: Add mqprio support")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrea Parri (Microsoft) [Mon, 6 Apr 2020 00:15:04 +0000 (02:15 +0200)]
Drivers: hv: vmbus: Always handle the VMBus messages on CPU0
[ Upstream commit
8a857c55420f29da4fc131adc22b12d474c48f4c ]
A Linux guest have to pick a "connect CPU" to communicate with the
Hyper-V host. This CPU can not be taken offline because Hyper-V does
not provide a way to change that CPU assignment.
Current code sets the connect CPU to whatever CPU ends up running the
function vmbus_negotiate_version(), and this will generate problems if
that CPU is taken offine.
Establish CPU0 as the connect CPU, and add logics to prevents the
connect CPU from being taken offline. We could pick some other CPU,
and we could pick that "other CPU" dynamically if there was a reason to
do so at some point in the future. But for now, #defining the connect
CPU to 0 is the most straightforward and least complex solution.
While on this, add inline comments explaining "why" offer and rescind
messages should not be handled by a same serialized work queue.
Suggested-by: Dexuan Cui <decui@microsoft.com>
Signed-off-by: Andrea Parri (Microsoft) <parri.andrea@gmail.com>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Link: https://lore.kernel.org/r/20200406001514.19876-2-parri.andrea@gmail.com
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Moore [Tue, 21 Apr 2020 13:10:56 +0000 (09:10 -0400)]
audit: fix a net reference leak in audit_list_rules_send()
[ Upstream commit
3054d06719079388a543de6adb812638675ad8f5 ]
If audit_list_rules_send() fails when trying to create a new thread
to send the rules it also fails to cleanup properly, leaking a
reference to a net structure. This patch fixes the error patch and
renames audit_send_list() to audit_send_list_thread() to better
match its cousin, audit_send_reply_thread().
Reported-by: teroincn@gmail.com
Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hans de Goede [Fri, 17 Apr 2020 17:15:32 +0000 (19:15 +0200)]
Bluetooth: btbcm: Add 2 missing models to subver tables
[ Upstream commit
c03ee9af4e07112bd3fc688daca9e654f41eca93 ]
Currently the bcm_uart_subver_ and bcm_usb_subver_table-s lack entries
for the BCM4324B5 and BCM20703A1 chipsets. This makes the code use just
"BCM" as prefix for the filename to pass to request-firmware, making it
harder for users to figure out which firmware they need. This especially
is problematic with the UART attached BCM4324B5 where this leads to the
filename being just "BCM.hcd".
Add the 2 missing devices to subver tables. This has been tested on:
1. A Dell XPS15 9550 where this makes btbcm.c try to load
"BCM20703A1-0a5c-6410.hcd" before it tries to load "BCM-0a5c-6410.hcd".
2. A Thinkpad 8 where this makes btbcm.c try to load
"BCM4324B5.hcd" before it tries to load "BCM.hcd"
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wen Gong [Tue, 21 Apr 2020 12:09:35 +0000 (15:09 +0300)]
ath10k: add flush tx packets for SDIO chip
[ Upstream commit
dd7fc5545bbafdbd6c1efdc996b61883b285bdc5 ]
When station connected to AP, and run TX traffic such as TCP/UDP, and
system enter suspend state, then mac80211 call ath10k_flush with set
drop flag, recently it only send wmi peer flush to firmware and
firmware will flush all pending TX packets, for PCIe, firmware will
indicate the TX packets status to ath10k, and then ath10k indicate to
mac80211 TX complete with the status, then all the packets has been
flushed at this moment. For SDIO chip, it is different, its TX
complete indication is disabled by default, and it has a tx queue in
ath10k, and its tx credit control is enabled, total tx credit is 96,
when its credit is not sufficient, then the packets will buffered in
the tx queue of ath10k, max packets is TARGET_TLV_NUM_MSDU_DESC_HL
which is 1024, for SDIO, when mac80211 call ath10k_flush with set drop
flag, maybe it have pending packets in tx queue of ath10k, and if it
does not have sufficient tx credit, the packets will stay in queue
untill tx credit report from firmware, if it is a noisy environment,
tx speed is low and the tx credit report from firmware will delay more
time, then the num_pending_tx will remain > 0 untill all packets send
to firmware. After the 1st ath10k_flush, mac80211 will call the 2nd
ath10k_flush without set drop flag immediately, then it will call to
ath10k_mac_wait_tx_complete, and it wait untill num_pending_tx become
to 0, in noisy environment, it is esay to wait about near 5 seconds,
then it cause the suspend take long time.
1st and 2nd callstack of ath10k_flush
[ 303.740427] ath10k_sdio mmc1:0001:1: ath10k_flush drop:1, pending:0-0
[ 303.740495] ------------[ cut here ]------------
[ 303.740739] WARNING: CPU: 1 PID: 3921 at /mnt/host/source/src/third_party/kernel/v4.19/drivers/net/wireless/ath/ath10k/mac.c:7025 ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.740757] Modules linked in: bridge stp llc ath10k_sdio ath10k_core rfcomm uinput cros_ec_rpmsg mtk_seninf mtk_cam_isp mtk_vcodec_enc mtk_fd mtk_vcodec_dec mtk_vcodec_common mtk_dip mtk_mdp3 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 videobuf2_common hid_google_hammer hci_uart btqca bluetooth dw9768 ov8856 ecdh_generic ov02a10 v4l2_fwnode mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi ipt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring cros_ec_sensors_sync cros_ec_light_prox cros_ec_sensors industrialio_triggered_buffer
[ 303.740914] kfifo_buf cros_ec_activity cros_ec_sensors_core lzo_rle lzo_compress ath mac80211 zram cfg80211 joydev [last unloaded: ath10k_core]
[ 303.741009] CPU: 1 PID: 3921 Comm: kworker/u16:10 Tainted: G W 4.19.95 #2
[ 303.741027] Hardware name: MediaTek krane sku176 board (DT)
[ 303.741061] Workqueue: events_unbound async_run_entry_fn
[ 303.741086] pstate:
60000005 (nZCv daif -PAN -UAO)
[ 303.741166] pc : ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.741244] lr : ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.741260] sp :
ffffffdf080e77a0
[ 303.741276] x29:
ffffffdf080e77a0 x28:
ffffffdef3730040
[ 303.741300] x27:
ffffff907c2240a0 x26:
ffffffde6ff39afc
[ 303.741321] x25:
ffffffdef3730040 x24:
ffffff907bf61018
[ 303.741343] x23:
ffffff907c2240a0 x22:
ffffffde6ff39a50
[ 303.741364] x21:
0000000000000001 x20:
ffffffde6ff39a50
[ 303.741385] x19:
ffffffde6bac2420 x18:
0000000000017200
[ 303.741407] x17:
ffffff907c24a000 x16:
0000000000000037
[ 303.741428] x15:
ffffff907b49a568 x14:
ffffff907cf332c1
[ 303.741476] x13:
00000000000922e4 x12:
0000000000000000
[ 303.741497] x11:
0000000000000001 x10:
0000000000000007
[ 303.741518] x9 :
f2256b8c1de4bc00 x8 :
f2256b8c1de4bc00
[ 303.741539] x7 :
ffffff907ab5e764 x6 :
0000000000000000
[ 303.741560] x5 :
0000000000000080 x4 :
0000000000000001
[ 303.741582] x3 :
ffffffdf080e74a8 x2 :
ffffff907aa91244
[ 303.741603] x1 :
ffffffdf080e74a8 x0 :
0000000000000024
[ 303.741624] Call trace:
[ 303.741701] ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.741941] __ieee80211_flush_queues+0x1dc/0x358 [mac80211]
[ 303.742098] ieee80211_flush_queues+0x34/0x44 [mac80211]
[ 303.742253] ieee80211_set_disassoc+0xc0/0x5ec [mac80211]
[ 303.742399] ieee80211_mgd_deauth+0x720/0x7d4 [mac80211]
[ 303.742535] ieee80211_deauth+0x24/0x30 [mac80211]
[ 303.742720] cfg80211_mlme_deauth+0x250/0x3bc [cfg80211]
[ 303.742849] cfg80211_mlme_down+0x90/0xd0 [cfg80211]
[ 303.742971] cfg80211_disconnect+0x340/0x3a0 [cfg80211]
[ 303.743087] __cfg80211_leave+0xe4/0x17c [cfg80211]
[ 303.743203] cfg80211_leave+0x38/0x50 [cfg80211]
[ 303.743319] wiphy_suspend+0x84/0x5bc [cfg80211]
[ 303.743335] dpm_run_callback+0x170/0x304
[ 303.743346] __device_suspend+0x2dc/0x3e8
[ 303.743356] async_suspend+0x2c/0xb0
[ 303.743370] async_run_entry_fn+0x48/0xf8
[ 303.743383] process_one_work+0x304/0x604
[ 303.743394] worker_thread+0x248/0x3f4
[ 303.743403] kthread+0x120/0x130
[ 303.743416] ret_from_fork+0x10/0x18
[ 303.743812] ath10k_sdio mmc1:0001:1: ath10k_flush drop:0, pending:0-0
[ 303.743858] ------------[ cut here ]------------
[ 303.744057] WARNING: CPU: 1 PID: 3921 at /mnt/host/source/src/third_party/kernel/v4.19/drivers/net/wireless/ath/ath10k/mac.c:7025 ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.744075] Modules linked in: bridge stp llc ath10k_sdio ath10k_core rfcomm uinput cros_ec_rpmsg mtk_seninf mtk_cam_isp mtk_vcodec_enc mtk_fd mtk_vcodec_dec mtk_vcodec_common mtk_dip mtk_mdp3 videobuf2_dma_contig videobuf2_memops v4l2_mem2mem videobuf2_v4l2 videobuf2_common hid_google_hammer hci_uart btqca bluetooth dw9768 ov8856 ecdh_generic ov02a10 v4l2_fwnode mtk_scp mtk_rpmsg rpmsg_core mtk_scp_ipi ipt_MASQUERADE fuse iio_trig_sysfs cros_ec_sensors_ring cros_ec_sensors_sync cros_ec_light_prox cros_ec_sensors industrialio_triggered_buffer kfifo_buf cros_ec_activity cros_ec_sensors_core lzo_rle lzo_compress ath mac80211 zram cfg80211 joydev [last unloaded: ath10k_core]
[ 303.744256] CPU: 1 PID: 3921 Comm: kworker/u16:10 Tainted: G W 4.19.95 #2
[ 303.744273] Hardware name: MediaTek krane sku176 board (DT)
[ 303.744301] Workqueue: events_unbound async_run_entry_fn
[ 303.744325] pstate:
60000005 (nZCv daif -PAN -UAO)
[ 303.744403] pc : ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.744480] lr : ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.744496] sp :
ffffffdf080e77a0
[ 303.744512] x29:
ffffffdf080e77a0 x28:
ffffffdef3730040
[ 303.744534] x27:
ffffff907c2240a0 x26:
ffffffde6ff39afc
[ 303.744556] x25:
ffffffdef3730040 x24:
ffffff907bf61018
[ 303.744577] x23:
ffffff907c2240a0 x22:
ffffffde6ff39a50
[ 303.744598] x21:
0000000000000000 x20:
ffffffde6ff39a50
[ 303.744620] x19:
ffffffde6bac2420 x18:
000000000001831c
[ 303.744641] x17:
ffffff907c24a000 x16:
0000000000000037
[ 303.744662] x15:
ffffff907b49a568 x14:
ffffff907cf332c1
[ 303.744683] x13:
00000000000922ea x12:
0000000000000000
[ 303.744704] x11:
0000000000000001 x10:
0000000000000007
[ 303.744747] x9 :
f2256b8c1de4bc00 x8 :
f2256b8c1de4bc00
[ 303.744768] x7 :
ffffff907ab5e764 x6 :
0000000000000000
[ 303.744789] x5 :
0000000000000080 x4 :
0000000000000001
[ 303.744810] x3 :
ffffffdf080e74a8 x2 :
ffffff907aa91244
[ 303.744831] x1 :
ffffffdf080e74a8 x0 :
0000000000000024
[ 303.744853] Call trace:
[ 303.744929] ath10k_flush+0x54/0x104 [ath10k_core]
[ 303.745098] __ieee80211_flush_queues+0x1dc/0x358 [mac80211]
[ 303.745277] ieee80211_flush_queues+0x34/0x44 [mac80211]
[ 303.745424] ieee80211_set_disassoc+0x108/0x5ec [mac80211]
[ 303.745569] ieee80211_mgd_deauth+0x720/0x7d4 [mac80211]
[ 303.745706] ieee80211_deauth+0x24/0x30 [mac80211]
[ 303.745853] cfg80211_mlme_deauth+0x250/0x3bc [cfg80211]
[ 303.745979] cfg80211_mlme_down+0x90/0xd0 [cfg80211]
[ 303.746103] cfg80211_disconnect+0x340/0x3a0 [cfg80211]
[ 303.746219] __cfg80211_leave+0xe4/0x17c [cfg80211]
[ 303.746335] cfg80211_leave+0x38/0x50 [cfg80211]
[ 303.746452] wiphy_suspend+0x84/0x5bc [cfg80211]
[ 303.746467] dpm_run_callback+0x170/0x304
[ 303.746477] __device_suspend+0x2dc/0x3e8
[ 303.746487] async_suspend+0x2c/0xb0
[ 303.746498] async_run_entry_fn+0x48/0xf8
[ 303.746510] process_one_work+0x304/0x604
[ 303.746521] worker_thread+0x248/0x3f4
[ 303.746530] kthread+0x120/0x130
[ 303.746542] ret_from_fork+0x10/0x18
one sample's debugging log: it wait 3190 ms(5000 - 1810).
1st ath10k_flush, it has 120 packets in tx queue of ath10k:
<...>-1513 [000] .... 25374.786005: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_flush drop:1, pending:120-0
<...>-1513 [000] ...1 25374.788375: ath10k_log_warn: ath10k_sdio mmc1:0001:1 ath10k_htt_tx_mgmt_inc_pending htt->num_pending_mgmt_tx:0
<...>-1500 [001] .... 25374.790143: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:121
2st ath10k_flush, it has 121 packets in tx queue of ath10k:
<...>-1513 [000] .... 25374.790571: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_flush drop:0, pending:121-0
<...>-1513 [000] .... 25374.791990: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_mac_wait_tx_complete state:1 pending:121-0
<...>-1508 [001] .... 25374.792696: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:46
<...>-1508 [001] .... 25374.792700: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:46
<...>-1508 [001] .... 25374.792729: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:121
<...>-1508 [001] .... 25374.792937: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:88, count:32, len:49792
<...>-1508 [001] .... 25374.793031: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:75, count:14, len:21784
kworker/u16:0-25773 [003] .... 25374.793701: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:46
<...>-1881 [000] .... 25375.073178: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:24
<...>-1881 [000] .... 25375.073182: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:24
<...>-1881 [000] .... 25375.073429: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:75
<...>-1879 [001] .... 25375.074090: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:24
<...>-1881 [000] .... 25375.074123: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:51, count:24, len:37344
<...>-1879 [001] .... 25375.270126: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:26
<...>-1879 [001] .... 25375.270130: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:26
<...>-1488 [000] .... 25375.270174: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:51
<...>-1488 [000] .... 25375.270529: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:25, count:26, len:40456
<...>-1879 [001] .... 25375.270693: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:26
<...>-1488 [001] .... 25377.775885: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:12
<...>-1488 [001] .... 25377.775890: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:12
<...>-1488 [001] .... 25377.775933: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:25
<...>-1488 [001] .... 25377.776059: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:13, count:12, len:18672
<...>-1879 [001] .... 25377.776100: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:12
<...>-1488 [001] .... 25377.878079: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:15
<...>-1488 [001] .... 25377.878087: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:15
<...>-1879 [000] .... 25377.878323: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:13
<...>-1879 [000] .... 25377.878487: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx status:0, eid:1, req count:0, count:13, len:20228
<...>-1879 [000] .... 25377.878497: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx complete, eid:1, pending complete count:13
<...>-1488 [001] .... 25377.919927: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit update: delta:11
<...>-1488 [001] .... 25377.919932: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 credit total:13
<...>-1488 [001] .... 25377.919976: ath10k_log_dbg: ath10k_sdio mmc1:0001:1 bundle tx work, eid:1, count:0
<...>-1881 [000] .... 25377.982645: ath10k_log_warn: ath10k_sdio mmc1:0001:1 HTT_T2H_MSG_TYPE_MGMT_TX_COMPLETION status:0
<...>-1513 [001] .... 25377.982973: ath10k_log_err: ath10k_sdio mmc1:0001:1 ath10k_mac_wait_tx_complete time_left:1810, pending:0-0
Flush all pending TX packets for the 1st ath10k_flush reduced the wait
time of the 2nd ath10k_flush and then suspend take short time.
This Patch only effect SDIO chips.
Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
Signed-off-by: Wen Gong <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200415233730.10581-1-wgong@codeaurora.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tiezhu Yang [Tue, 21 Apr 2020 11:59:46 +0000 (19:59 +0800)]
MIPS: Make sparse_init() using top-down allocation
[ Upstream commit
269b3a9ac538c4ae87f84be640b9fa89914a2489 ]
In the current code, if CONFIG_SWIOTLB is set, when failed to get IO TLB
memory from the low pages by plat_swiotlb_setup(), it may lead to the boot
process failed with kernel panic.
(1) On the Loongson and SiByte platform
arch/mips/loongson64/dma.c
arch/mips/sibyte/common/dma.c
void __init plat_swiotlb_setup(void)
{
swiotlb_init(1);
}
kernel/dma/swiotlb.c
void __init
swiotlb_init(int verbose)
{
...
vstart = memblock_alloc_low(PAGE_ALIGN(bytes), PAGE_SIZE);
if (vstart && !swiotlb_init_with_tbl(vstart, io_tlb_nslabs, verbose))
return;
...
pr_warn("Cannot allocate buffer");
no_iotlb_memory = true;
}
phys_addr_t swiotlb_tbl_map_single()
{
...
if (no_iotlb_memory)
panic("Can not allocate SWIOTLB buffer earlier ...");
...
}
(2) On the Cavium OCTEON platform
arch/mips/cavium-octeon/dma-octeon.c
void __init plat_swiotlb_setup(void)
{
...
octeon_swiotlb = memblock_alloc_low(swiotlbsize, PAGE_SIZE);
if (!octeon_swiotlb)
panic("%s: Failed to allocate %zu bytes align=%lx\n",
__func__, swiotlbsize, PAGE_SIZE);
...
}
Because IO_TLB_DEFAULT_SIZE is 64M, if the rest size of low memory is less
than 64M when call plat_swiotlb_setup(), we can easily reproduce the panic
case.
In order to reduce the possibility of kernel panic when failed to get IO
TLB memory under CONFIG_SWIOTLB, it is better to allocate low memory as
small as possible before plat_swiotlb_setup(), so make sparse_init() using
top-down allocation.
Reported-by: Juxin Gao <gaojuxin@loongson.cn>
Co-developed-by: Juxin Gao <gaojuxin@loongson.cn>
Signed-off-by: Juxin Gao <gaojuxin@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kieran Bingham [Tue, 7 Apr 2020 15:44:17 +0000 (17:44 +0200)]
media: platform: fcp: Set appropriate DMA parameters
[ Upstream commit
dd844fb8e50b12e65bbdc5746c9876c6735500df ]
Enabling CONFIG_DMA_API_DEBUG=y and CONFIG_DMA_API_DEBUG_SG=y will
enable extra validation on DMA operations ensuring that the size
restraints are met.
When using the FCP in conjunction with the VSP1/DU, and display frames,
the size of the DMA operations is larger than the default maximum
segment size reported by the DMA core (64K). With the DMA debug enabled,
this produces a warning such as the following:
"DMA-API: rcar-fcp
fea27000.fcp: mapping sg segment longer than device
claims to support [len=3145728] [max=65536]"
We have no specific limitation on the segment size which isn't already
handled by the VSP1/DU which actually handles the DMA allcoations and
buffer management, so define a maximum segment size of up to 4GB (a 32
bit mask).
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes:
7b49235e83b2 ("[media] v4l: Add Renesas R-Car FCP driver")
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Mon, 10 Feb 2020 17:51:33 +0000 (18:51 +0100)]
media: dvb: return -EREMOTEIO on i2c transfer failure.
[ Upstream commit
96f3a9392799dd0f6472648a7366622ffd0989f3 ]
Currently when i2c transfers fail the error return -EREMOTEIO
is assigned to err but then later overwritten when the tuner
attach call is made. Fix this by returning early with the
error return code -EREMOTEIO on i2c transfer failure errors.
If the transfer fails, an uninitialized value will be read from b2.
Addresses-Coverity: ("Unused value")
Fixes:
fbfee8684ff2 ("V4L/DVB (5651): Dibusb-mb: convert pll handling to properly use dvb-pll")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Moore [Mon, 20 Apr 2020 14:09:29 +0000 (10:09 -0400)]
audit: fix a net reference leak in audit_send_reply()
[ Upstream commit
a48b284b403a4a073d8beb72d2bb33e54df67fb6 ]
If audit_send_reply() fails when trying to create a new thread to
send the reply it also fails to cleanup properly, leaking a reference
to a net structure. This patch fixes the error path and makes a
handful of other cleanups that came up while fixing the code.
Reported-by: teroincn@gmail.com
Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jitao Shi [Wed, 15 Apr 2020 01:13:19 +0000 (09:13 +0800)]
drm/mediatek: set dpi pin mode to gpio low to avoid leakage current
[ Upstream commit
6bd4763fd532cff43f9b15704f324c45a9806f53 ]
Config dpi pins mode to output and pull low when dpi is disabled.
Aovid leakage current from some dpi pins (Hsync Vsync DE ... ).
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jitao Shi [Wed, 15 Apr 2020 01:13:17 +0000 (09:13 +0800)]
dt-bindings: display: mediatek: control dpi pins mode to avoid leakage
[ Upstream commit
b0ff9b590733079f7f9453e5976a9dd2630949e3 ]
Add property "pinctrl-names" to swap pin mode between gpio and dpi mode.
Set the dpi pins to gpio mode and output-low to avoid leakage current
when dpi disabled.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Thu, 20 Feb 2020 06:23:02 +0000 (22:23 -0800)]
e1000: Distribute switch variables for initialization
[ Upstream commit
a34c7f5156654ebaf7eaace102938be7ff7036cb ]
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.
To avoid these problems, move such variables into the "case" where
they're used or lift them up into the main function body.
drivers/net/ethernet/intel/e1000/e1000_main.c: In function ‘e1000_xmit_frame’:
drivers/net/ethernet/intel/e1000/e1000_main.c:3143:18: warning: statement will never be executed [-Wswitch-unreachable]
3143 | unsigned int pull_size;
| ^~~~~~~~~
[1] https://bugs.llvm.org/show_bug.cgi?id=44916
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephane Eranian [Thu, 2 Apr 2020 15:43:54 +0000 (08:43 -0700)]
tools api fs: Make xxx__mountpoint() more scalable
[ Upstream commit
c6fddb28bad26e5472cb7acf7b04cd5126f1a4ab ]
The xxx_mountpoint() interface provided by fs.c finds mount points for
common pseudo filesystems. The first time xxx_mountpoint() is invoked,
it scans the mount table (/proc/mounts) looking for a match. If found,
it is cached. The price to scan /proc/mounts is paid once if the mount
is found.
When the mount point is not found, subsequent calls to xxx_mountpoint()
scan /proc/mounts over and over again. There is no caching.
This causes a scaling issue in perf record with hugeltbfs__mountpoint().
The function is called for each process found in
synthesize__mmap_events(). If the machine has thousands of processes
and if the /proc/mounts has many entries this could cause major overhead
in perf record. We have observed multi-second slowdowns on some
configurations.
As an example on a laptop:
Before:
$ sudo umount /dev/hugepages
$ strace -e trace=openat -o /tmp/tt perf record -a ls
$ fgrep mounts /tmp/tt
285
After:
$ sudo umount /dev/hugepages
$ strace -e trace=openat -o /tmp/tt perf record -a ls
$ fgrep mounts /tmp/tt
1
One could argue that the non-caching in case the moint point is not
found is intentional. That way subsequent calls may discover a moint
point if the sysadmin mounts the filesystem. But the same argument could
be made against caching the mount point. It could be unmounted causing
errors. It all depends on the intent of the interface. This patch
assumes it is expected to scan /proc/mounts once. The patch documents
the caching behavior in the fs.h header file.
An alternative would be to just fix perf record. But it would solve the
problem with hugetlbs__mountpoint() but there could be similar issues
(possibly down the line) with other xxx_mountpoint() calls in perf or
other tools.
Signed-off-by: Stephane Eranian <eranian@google.com>
Reviewed-by: Ian Rogers <irogers@google.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andrey Zhizhikin <andrey.z@gmail.com>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lore.kernel.org/lkml/20200402154357.107873-3-irogers@google.com
Signed-off-by: Ian Rogers <irogers@google.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bjorn Andersson [Wed, 15 Apr 2020 05:37:08 +0000 (22:37 -0700)]
regulator: qcom-rpmh: Fix typos in pm8150 and pm8150l
[ Upstream commit
906746ba26d0b45688f4c3b730c35f765dc958ba ]
Fix typos in pm8150 l13/l16/l17 and pm8150l ldo8 supplies.
Fixes:
06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200415053708.717623-1-bjorn.andersson@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jaehoon Chung [Mon, 30 Mar 2020 05:25:28 +0000 (14:25 +0900)]
brcmfmac: fix wrong location to get firmware feature
[ Upstream commit
c57673852062428cdeabdd6501ac8b8e4c302067 ]
sup_wpa feature is getting after setting feature_disable flag.
If firmware is supported sup_wpa feature, it's always enabled
regardless of feature_disable flag.
Fixes:
b8a64f0e96c2 ("brcmfmac: support 4-way handshake offloading for WPA/WPA2-PSK")
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200330052528.10503-1-jh80.chung@samsung.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Mon, 13 Apr 2020 18:04:06 +0000 (21:04 +0300)]
spi: Respect DataBitLength field of SpiSerialBusV2() ACPI resource
[ Upstream commit
0dadde344d965566589cd82797893d5aa06557a3 ]
By unknown reason the commit
64bee4d28c9e
("spi / ACPI: add ACPI enumeration support")
missed the DataBitLength property to encounter when parse SPI slave
device data from ACPI.
Fill the gap here.
Fixes:
64bee4d28c9e ("spi / ACPI: add ACPI enumeration support")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200413180406.1826-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bingbu Cao [Thu, 26 Mar 2020 14:54:37 +0000 (15:54 +0100)]
media: staging/intel-ipu3: Implement lock for stream on/off operations
[ Upstream commit
33e3c349b2bf1235be458df09fb8d237141486c4 ]
Currently concurrent stream off operations on ImgU nodes are not
synchronized, leading to use-after-free bugs (as reported by KASAN).
[ 250.090724] BUG: KASAN: use-after-free in
ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu]
[ 250.090726] Read of size 8 at addr
ffff888127b29bc0 by task
yavta/18836
[ 250.090731] Hardware name: HP Soraka/Soraka, BIOS
Google_Soraka.10431.17.0 03/22/2018
[ 250.090732] Call Trace:
[ 250.090735] dump_stack+0x6a/0xb1
[ 250.090739] print_address_description+0x8e/0x279
[ 250.090743] ? ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu]
[ 250.090746] kasan_report+0x260/0x28a
[ 250.090750] ipu3_dmamap_free+0xc5/0x116 [ipu3_imgu]
[ 250.090754] ipu3_css_pool_cleanup+0x24/0x37 [ipu3_imgu]
[ 250.090759] ipu3_css_pipeline_cleanup+0x61/0xb9 [ipu3_imgu]
[ 250.090763] ipu3_css_stop_streaming+0x1f2/0x321 [ipu3_imgu]
[ 250.090768] imgu_s_stream+0x94/0x443 [ipu3_imgu]
[ 250.090772] ? ipu3_vb2_buf_queue+0x280/0x280 [ipu3_imgu]
[ 250.090775] ? vb2_dma_sg_unmap_dmabuf+0x16/0x6f [videobuf2_dma_sg]
[ 250.090778] ? vb2_buffer_in_use+0x36/0x58 [videobuf2_common]
[ 250.090782] ipu3_vb2_stop_streaming+0xf9/0x135 [ipu3_imgu]
Implemented a lock to synchronize imgu stream on / off operations and
the modification of streaming flag (in struct imgu_device), to prevent
these issues.
Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Signed-off-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Venkateswara Naralasetty [Wed, 1 Apr 2020 10:18:10 +0000 (15:48 +0530)]
ath10k: fix kernel null pointer dereference
[ Upstream commit
acb31476adc9ff271140cdd4d3c707ff0c97f5a4 ]
Currently sta airtime is updated without any lock in case of
host based airtime calculation. Which may result in accessing the
invalid sta pointer in case of continuous station connect/disconnect.
This patch fix the kernel null pointer dereference by updating the
station airtime with proper RCU lock in case of host based airtime
calculation.
Proceeding with the analysis of "ARM Kernel Panic".
The APSS crash happened due to OOPS on CPU 0.
Crash Signature : Unable to handle kernel NULL pointer dereference
at virtual address
00000300
During the crash,
PC points to "ieee80211_sta_register_airtime+0x1c/0x448 [mac80211]"
LR points to "ath10k_txrx_tx_unref+0x17c/0x364 [ath10k_core]".
The Backtrace obtained is as follows:
[<
bf880238>] (ieee80211_sta_register_airtime [mac80211]) from
[<
bf945a38>] (ath10k_txrx_tx_unref+0x17c/0x364 [ath10k_core])
[<
bf945a38>] (ath10k_txrx_tx_unref [ath10k_core]) from
[<
bf9428e4>] (ath10k_htt_txrx_compl_task+0xa50/0xfc0 [ath10k_core])
[<
bf9428e4>] (ath10k_htt_txrx_compl_task [ath10k_core]) from
[<
bf9b9bc8>] (ath10k_pci_napi_poll+0x50/0xf8 [ath10k_pci])
[<
bf9b9bc8>] (ath10k_pci_napi_poll [ath10k_pci]) from
[<
c059e3b0>] (net_rx_action+0xac/0x160)
[<
c059e3b0>] (net_rx_action) from [<
c02329a4>] (__do_softirq+0x104/0x294)
[<
c02329a4>] (__do_softirq) from [<
c0232b64>] (run_ksoftirqd+0x30/0x90)
[<
c0232b64>] (run_ksoftirqd) from [<
c024e358>] (smpboot_thread_fn+0x25c/0x274)
[<
c024e358>] (smpboot_thread_fn) from [<
c02482fc>] (kthread+0xd8/0xec)
Tested HW: QCA9888
Tested FW: 10.4-3.10-00047
Signed-off-by: Venkateswara Naralasetty <vnaralas@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585736290-17661-1-git-send-email-vnaralas@codeaurora.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christoph Hellwig [Tue, 2 Jun 2020 04:50:23 +0000 (21:50 -0700)]
staging: android: ion: use vmap instead of vm_map_ram
[ Upstream commit
5bf9917452112694b2c774465ee4dbe441c84b77 ]
vm_map_ram can keep mappings around after the vm_unmap_ram. Using that
with non-PAGE_KERNEL mappings can lead to all kinds of aliasing issues.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Gao Xiang <xiang@kernel.org>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Will Deacon <will@kernel.org>
Link: http://lkml.kernel.org/r/20200414131348.444715-4-hch@lst.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christoph Hellwig [Tue, 2 Jun 2020 04:50:19 +0000 (21:50 -0700)]
x86: fix vmap arguments in map_irq_stack
[ Upstream commit
0348801151b5aefbcf9d6e9b9e30aceb3a2a7b13 ]
vmap does not take a gfp_t, the flags argument is for VM_* flags.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Gao Xiang <xiang@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Michael Kelley <mikelley@microsoft.com>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Will Deacon <will@kernel.org>
Link: http://lkml.kernel.org/r/20200414131348.444715-3-hch@lst.de
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jia-Ju Bai [Sat, 30 May 2020 02:41:50 +0000 (10:41 +0800)]
net: vmxnet3: fix possible buffer overflow caused by bad DMA value in vmxnet3_get_rss()
[ Upstream commit
3e1c6846b9e108740ef8a37be80314053f5dd52a ]
The value adapter->rss_conf is stored in DMA memory, and it is assigned
to rssConf, so rssConf->indTableSize can be modified at anytime by
malicious hardware. Because rssConf->indTableSize is assigned to n,
buffer overflow may occur when the code "rssConf->indTable[n]" is
executed.
To fix this possible bug, n is checked after being used.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jon Doron [Fri, 24 Apr 2020 11:37:40 +0000 (14:37 +0300)]
x86/kvm/hyper-v: Explicitly align hcall param for kvm_hyperv_exit
[ Upstream commit
f7d31e65368aeef973fab788aa22c4f1d5a6af66 ]
The problem the patch is trying to address is the fact that 'struct
kvm_hyperv_exit' has different layout on when compiling in 32 and 64 bit
modes.
In 64-bit mode the default alignment boundary is 64 bits thus
forcing extra gaps after 'type' and 'msr' but in 32-bit mode the
boundary is at 32 bits thus no extra gaps.
This is an issue as even when the kernel is 64 bit, the userspace using
the interface can be both 32 and 64 bit but the same 32 bit userspace has
to work with 32 bit kernel.
The issue is fixed by forcing the 64 bit layout, this leads to ABI
change for 32 bit builds and while we are obviously breaking '32 bit
userspace with 32 bit kernel' case, we're fixing the '32 bit userspace
with 64 bit kernel' one.
As the interface has no (known) users and 32 bit KVM is rather baroque
nowadays, this seems like a reasonable decision.
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Jon Doron <arilou@gmail.com>
Message-Id: <
20200424113746.3473563-2-arilou@gmail.com>
Reviewed-by: Roman Kagan <rvkagan@yandex-team.ru>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Serge Semin [Fri, 29 May 2020 13:11:57 +0000 (16:11 +0300)]
spi: dw: Fix Rx-only DMA transfers
[ Upstream commit
46164fde6b7890e7a3982d54549947c8394c0192 ]
Tx-only DMA transfers are working perfectly fine since in this case
the code just ignores the Rx FIFO overflow interrupts. But it turns
out the SPI Rx-only transfers are broken since nothing pushing any
data to the shift registers, so the Rx FIFO is left empty and the
SPI core subsystems just returns a timeout error. Since DW DMAC
driver doesn't support something like cyclic write operations of
a single byte to a device register, the only way to support the
Rx-only SPI transfers is to fake it by using a dummy Tx-buffer.
This is what we intend to fix in this commit by setting the
SPI_CONTROLLER_MUST_TX flag for DMA-capable platform.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
Link: https://lore.kernel.org/r/20200529131205.31838-9-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Fri, 29 May 2020 02:27:26 +0000 (10:27 +0800)]
Bluetooth: btmtkuart: Improve exception handling in btmtuart_probe()
[ Upstream commit
4803c54ca24923a30664bea2a7772db6e7303c51 ]
Calls of the functions clk_disable_unprepare() and hci_free_dev()
were missing for the exception handling.
Thus add the missed function calls together with corresponding
jump targets.
Fixes:
055825614c6b ("Bluetooth: btmtkuart: add an implementation for clock osc property")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Sun, 3 May 2020 22:28:05 +0000 (00:28 +0200)]
mmc: meson-mx-sdio: trigger a soft reset after a timeout or CRC error
[ Upstream commit
91995b904ec2e44b5c159ac6a5d3f154345a4de7 ]
The vendor driver (from the 3.10 kernel) triggers a soft reset every
time before starting a new command. While this fixes a problem where
SDIO cards are not detected at all (because all commands simply
timed out) this hurts SD card read performance a bit (in my tests
between 10% to 20%).
Trigger a soft reset after we got a CRC error or if the previous command
timed out (just like the vendor driver from the same 3.10 kernel for the
newer SDHC controller IP does). This fixes detection of SDIO cards and
doesn't hurt SD card read performance at the same time.
With this patch the initialization of an RTL8723BS SDIO card looks like
this:
req done (CMD52): -110:
00000000 00000000 00000000 00000000
clock 400000Hz busmode 2 powermode 2 cs 1 Vdd 21 width 1 timing 0
starting CMD0 arg
00000000 flags
000000c0
req done (CMD0): 0:
00000000 00000000 00000000 00000000
clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 0
starting CMD8 arg
000001aa flags
000002f5
req done (CMD8): -110:
00000000 00000000 00000000 00000000
starting CMD5 arg
00000000 flags
000002e1
req done (CMD5): 0:
90ff0000 00000000 00000000 00000000
starting CMD5 arg
00200000 flags
000002e1
req done (CMD5): 0:
90ff0000 00000000 00000000 00000000
starting CMD3 arg
00000000 flags
00000075
req done (CMD3): 0:
00010000 00000000 00000000 00000000
starting CMD7 arg
00010000 flags
00000015
req done (CMD7): 0:
00001e00 00000000 00000000 00000000
starting CMD52 arg
00000000 flags
00000195
req done (CMD52): 0:
00001032 00000000 00000000 00000000
[... more CMD52 omitted ...]
clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2
clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 1 timing 2
starting CMD52 arg
00000e00 flags
00000195
req done (CMD52): 0:
00001000 00000000 00000000 00000000
starting CMD52 arg
80000e02 flags
00000195
req done (CMD52): 0:
00001002 00000000 00000000 00000000
clock 50000000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 4 timing 2
starting CMD52 arg
00020000 flags
00000195
req done (CMD52): 0:
00001007 00000000 00000000 00000000
[... more CMD52 omitted ...]
new high speed SDIO card at address 0001
Fixes:
ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20200503222805.2668941-1-martin.blumenstingl@googlemail.com
Tested-by: Tobias Baumann <017623705678@o2online.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Surabhi Boob [Sat, 16 May 2020 00:36:43 +0000 (17:36 -0700)]
ice: Fix for memory leaks and modify ICE_FREE_CQ_BUFS
[ Upstream commit
68d270783742783f96e89ef92ac24ab3c7fb1d31 ]
Handle memory leaks during control queue initialization and
buffer allocation failures. The macro ICE_FREE_CQ_BUFS is modified to
re-use for this fix.
Signed-off-by: Surabhi Boob <surabhi.boob@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>
Surabhi Boob [Sat, 16 May 2020 00:36:42 +0000 (17:36 -0700)]
ice: Fix memory leak
[ Upstream commit
1aaef2bc4e0a5ce9e4dd86359e6a0bf52c6aa64f ]
Handle memory leak on filter management initialization failure.
Signed-off-by: Surabhi Boob <surabhi.boob@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>
Sven Eckelmann [Mon, 25 Nov 2019 09:46:50 +0000 (10:46 +0100)]
batman-adv: Revert "disable ethtool link speed detection when auto negotiation off"
[ Upstream commit
9ad346c90509ebd983f60da7d082f261ad329507 ]
The commit
8c46fcd78308 ("batman-adv: disable ethtool link speed detection
when auto negotiation off") disabled the usage of ethtool's link_ksetting
when auto negotation was enabled due to invalid values when used with
tun/tap virtual net_devices. According to the patch, automatic measurements
should be used for these kind of interfaces.
But there are major flaws with this argumentation:
* automatic measurements are not implemented
* auto negotiation has nothing to do with the validity of the retrieved
values
The first point has to be fixed by a longer patch series. The "validity"
part of the second point must be addressed in the same patch series by
dropping the usage of ethtool's link_ksetting (thus always doing automatic
measurements over ethernet).
Drop the patch again to have more default values for various net_device
types/configurations. The user can still overwrite them using the
batadv_hardif's BATADV_ATTR_THROUGHPUT_OVERRIDE.
Reported-by: Matthias Schiffer <mschiffer@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Walleij [Tue, 19 May 2020 11:59:12 +0000 (12:59 +0100)]
ARM: 8978/1: mm: make act_mm() respect THREAD_SIZE
[ Upstream commit
e1de94380af588bdf6ad6f0cc1f75004c35bc096 ]
Recent work with KASan exposed the folling hard-coded bitmask
in arch/arm/mm/proc-macros.S:
bic rd, sp, #8128
bic rd, rd, #63
This forms the bitmask 0x1FFF that is coinciding with
(PAGE_SIZE << THREAD_SIZE_ORDER) - 1, this code was assuming
that THREAD_SIZE is always 8K (8192).
As KASan was increasing THREAD_SIZE_ORDER to 2, I ran into
this bug.
Fix it by this little oneline suggested by Ard:
bic rd, sp, #(THREAD_SIZE - 1) & ~63
Where THREAD_SIZE is defined using THREAD_SIZE_ORDER.
We have to also include <linux/const.h> since the THREAD_SIZE
expands to use the _AC() macro.
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Filipe Manana [Mon, 18 May 2020 11:15:09 +0000 (12:15 +0100)]
btrfs: do not ignore error from btrfs_next_leaf() when inserting checksums
[ Upstream commit
7e4a3f7ed5d54926ec671bbb13e171cfe179cc50 ]
We are currently treating any non-zero return value from btrfs_next_leaf()
the same way, by going to the code that inserts a new checksum item in the
tree. However if btrfs_next_leaf() returns an error (a value < 0), we
should just stop and return the error, and not behave as if nothing has
happened, since in that case we do not have a way to know if there is a
next leaf or we are currently at the last leaf already.
So fix that by returning the error from btrfs_next_leaf().
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Josef Bacik [Fri, 13 Mar 2020 19:58:07 +0000 (15:58 -0400)]
btrfs: account for trans_block_rsv in may_commit_transaction
[ Upstream commit
bb4f58a747f0421b10645fbf75a6acc88da0de50 ]
On ppc64le with 64k page size (respectively 64k block size) generic/320
was failing and debug output showed we were getting a premature ENOSPC
with a bunch of space in btrfs_fs_info::trans_block_rsv.
This meant there were still open transaction handles holding space, yet
the flusher didn't commit the transaction because it deemed the freed
space won't be enough to satisfy the current reserve ticket. Fix this
by accounting for space in trans_block_rsv when deciding whether the
current transaction should be committed or not.
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brad Love [Thu, 14 May 2020 16:40:43 +0000 (18:40 +0200)]
media: dvbdev: Fix tuner->demod media controller link
[ Upstream commit
9f984cacf4f4d53fd8a3f44d7f13528b81c1f6a8 ]
Fixes bug exposed by:
[
a3fbc2e6bb0: media: mc-entity.c: use WARN_ON, validate link pads]
The dvbdev incorrectly requests a tuner sink pad to connect to a demux
sink pad. The media controller failure percolates back and the dvb device
creation fails. Fix this by requesting a tuner source pad. Instead of
forcing that pad to be index zero, check if a negative integer error
is returned. A note is added that first source pad found is chosen.
Affected bridges cx231xx and em28xx printed the below warning[s]
when a variety of media controller dvb enabled devices were connected.
The warning returns an error causing all affected devices to fail DVB
device creation.
[ 253.138332] ------------[ cut here ]------------
[ 253.138339] WARNING: CPU: 0 PID: 1550 at drivers/media/mc/mc-entity.c:669 media_create_pad_link+0x1e0/0x200 [mc]
[ 253.138339] Modules linked in: si2168 em28xx_dvb(+) em28xx si2157 lgdt3306a cx231xx_dvb dvb_core cx231xx_alsa cx25840 cx231xx tveeprom cx2341x i2c_mux videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ir_rc5_decoder rc_hauppauge mceusb rc_core eda
c_mce_amd kvm nls_iso8859_1 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper efi_pstore wmi_bmof k10temp asix usbnet mii nouveau snd_hda_codec_realtek snd_hda_codec_generic input_leds ledtrig_audio snd_hda_codec_hdmi mxm_wmi snd_hda_in
tel video snd_intel_dspcfg ttm snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_seq_midi snd_seq_midi_event i2c_algo_bit snd_pcm snd_rawmidi fb_sys_fops snd_seq syscopyarea sysfillrect snd_seq_device sysimgblt snd_timer snd soundcore ccp mac_hid sch_fq_codel parport_p
c ppdev lp parport ip_tables x_tables autofs4 vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio hid_generic usbhid hid i2c_piix4 ahci libahci wmi gpio_amdpt
[ 253.138370] gpio_generic
[ 253.138372] CPU: 0 PID: 1550 Comm: modprobe Tainted: G W 5.7.0-rc2+ #181
[ 253.138373] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 04/27/2018
[ 253.138376] RIP: 0010:media_create_pad_link+0x1e0/0x200 [mc]
[ 253.138378] Code: 26 fd ff ff 44 8b 4d d0 eb d9 0f 0b 41 b9 ea ff ff ff 44 89 c8 c3 0f 0b 41 b9 ea ff ff ff eb f2 0f 0b 41 b9 ea ff ff ff eb e8 <0f> 0b 41 b9 ea ff ff ff eb af 0f 0b 41 b9 ea ff ff ff eb a5 66 90
[ 253.138379] RSP: 0018:
ffffb9ecc0ee7a78 EFLAGS:
00010246
[ 253.138380] RAX:
ffff943f706c99d8 RBX:
0000000000000000 RCX:
0000000000000000
[ 253.138381] RDX:
ffff943f613e0180 RSI:
0000000000000000 RDI:
ffff943f706c9958
[ 253.138381] RBP:
ffffb9ecc0ee7ab0 R08:
0000000000000001 R09:
ffff943f613e0180
[ 253.138382] R10:
ffff943f613e0180 R11:
ffff943f706c9400 R12:
0000000000000000
[ 253.138383] R13:
0000000000000001 R14:
ffff943f706c9958 R15:
0000000000000001
[ 253.138384] FS:
00007f3cd29ba540(0000) GS:
ffff943f8ec00000(0000) knlGS:
0000000000000000
[ 253.138385] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 253.138385] CR2:
000055f7de0ca830 CR3:
00000003dd208000 CR4:
00000000003406f0
[ 253.138386] Call Trace:
[ 253.138392] media_create_pad_links+0x104/0x1b0 [mc]
[ 253.138397] dvb_create_media_graph+0x350/0x5f0 [dvb_core]
[ 253.138402] em28xx_dvb_init+0x5ea/0x2600 [em28xx_dvb]
[ 253.138408] em28xx_register_extension+0x63/0xc0 [em28xx]
[ 253.138410] ? 0xffffffffc039c000
[ 253.138412] em28xx_dvb_register+0x15/0x1000 [em28xx_dvb]
[ 253.138416] do_one_initcall+0x71/0x250
[ 253.138418] ? do_init_module+0x27/0x22e
[ 253.138421] ? _cond_resched+0x1a/0x50
[ 253.138423] ? kmem_cache_alloc_trace+0x1ec/0x270
[ 253.138425] ? __vunmap+0x1e3/0x240
[ 253.138427] do_init_module+0x5f/0x22e
[ 253.138430] load_module+0x2525/0x2d40
[ 253.138436] __do_sys_finit_module+0xe5/0x120
[ 253.138438] ? __do_sys_finit_module+0xe5/0x120
[ 253.138442] __x64_sys_finit_module+0x1a/0x20
[ 253.138443] do_syscall_64+0x57/0x1b0
[ 253.138445] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 253.138446] RIP: 0033:0x7f3cd24dc839
[ 253.138448] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
[ 253.138449] RSP: 002b:
00007ffe4fc514d8 EFLAGS:
00000246 ORIG_RAX:
0000000000000139
[ 253.138450] RAX:
ffffffffffffffda RBX:
000055a9237f63f0 RCX:
00007f3cd24dc839
[ 253.138451] RDX:
0000000000000000 RSI:
000055a922c3ad2e RDI:
0000000000000000
[ 253.138451] RBP:
000055a922c3ad2e R08:
0000000000000000 R09:
0000000000000000
[ 253.138452] R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000000
[ 253.138453] R13:
000055a9237f5550 R14:
0000000000040000 R15:
000055a9237f63f0
[ 253.138456] ---[ end trace
a60f19c54aa96ec4 ]---
[ 234.915628] ------------[ cut here ]------------
[ 234.915640] WARNING: CPU: 0 PID: 1502 at drivers/media/mc/mc-entity.c:669 media_create_pad_link+0x1e0/0x200 [mc]
[ 234.915641] Modules linked in: si2157 lgdt3306a cx231xx_dvb(+) dvb_core cx231xx_alsa cx25840 cx231xx tveeprom cx2341x i2c_mux videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc ir_rc5_decoder rc_hauppauge mceusb rc_core edac_mce_amd kvm nls_iso8859
_1 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel crypto_simd cryptd glue_helper efi_pstore wmi_bmof k10temp asix usbnet mii nouveau snd_hda_codec_realtek snd_hda_codec_generic input_leds ledtrig_audio snd_hda_codec_hdmi mxm_wmi snd_hda_intel video snd_intel_dspcf
g ttm snd_hda_codec drm_kms_helper snd_hda_core drm snd_hwdep snd_seq_midi snd_seq_midi_event i2c_algo_bit snd_pcm snd_rawmidi fb_sys_fops snd_seq syscopyarea sysfillrect snd_seq_device sysimgblt snd_timer snd soundcore ccp mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tab
les x_tables autofs4 vfio_pci irqbypass vfio_virqfd vfio_iommu_type1 vfio hid_generic usbhid hid i2c_piix4 ahci libahci wmi gpio_amdpt gpio_generic
[ 234.915700] CPU: 0 PID: 1502 Comm: modprobe Not tainted 5.7.0-rc2+ #181
[ 234.915702] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 04/27/2018
[ 234.915709] RIP: 0010:media_create_pad_link+0x1e0/0x200 [mc]
[ 234.915712] Code: 26 fd ff ff 44 8b 4d d0 eb d9 0f 0b 41 b9 ea ff ff ff 44 89 c8 c3 0f 0b 41 b9 ea ff ff ff eb f2 0f 0b 41 b9 ea ff ff ff eb e8 <0f> 0b 41 b9 ea ff ff ff eb af 0f 0b 41 b9 ea ff ff ff eb a5 66 90
[ 234.915714] RSP: 0018:
ffffb9ecc1b6fa50 EFLAGS:
00010246
[ 234.915717] RAX:
ffff943f8c94a9d8 RBX:
0000000000000000 RCX:
0000000000000000
[ 234.915719] RDX:
ffff943f613e0900 RSI:
0000000000000000 RDI:
ffff943f8c94a958
[ 234.915721] RBP:
ffffb9ecc1b6fa88 R08:
0000000000000001 R09:
ffff943f613e0900
[ 234.915723] R10:
ffff943f613e0900 R11:
ffff943f6b590c00 R12:
0000000000000000
[ 234.915724] R13:
0000000000000001 R14:
ffff943f8c94a958 R15:
0000000000000001
[ 234.915727] FS:
00007f4ca3646540(0000) GS:
ffff943f8ec00000(0000) knlGS:
0000000000000000
[ 234.915729] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 234.915731] CR2:
00007fff7a53ba18 CR3:
00000003da614000 CR4:
00000000003406f0
[ 234.915733] Call Trace:
[ 234.915745] media_create_pad_links+0x104/0x1b0 [mc]
[ 234.915756] dvb_create_media_graph+0x350/0x5f0 [dvb_core]
[ 234.915766] dvb_init.part.4+0x691/0x1360 [cx231xx_dvb]
[ 234.915780] dvb_init+0x1a/0x20 [cx231xx_dvb]
[ 234.915787] cx231xx_register_extension+0x71/0xa0 [cx231xx]
[ 234.915791] ? 0xffffffffc042f000
[ 234.915796] cx231xx_dvb_register+0x15/0x1000 [cx231xx_dvb]
[ 234.915802] do_one_initcall+0x71/0x250
[ 234.915807] ? do_init_module+0x27/0x22e
[ 234.915811] ? _cond_resched+0x1a/0x50
[ 234.915816] ? kmem_cache_alloc_trace+0x1ec/0x270
[ 234.915820] ? __vunmap+0x1e3/0x240
[ 234.915826] do_init_module+0x5f/0x22e
[ 234.915831] load_module+0x2525/0x2d40
[ 234.915848] __do_sys_finit_module+0xe5/0x120
[ 234.915850] ? __do_sys_finit_module+0xe5/0x120
[ 234.915862] __x64_sys_finit_module+0x1a/0x20
[ 234.915865] do_syscall_64+0x57/0x1b0
[ 234.915870] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 234.915872] RIP: 0033:0x7f4ca3168839
[ 234.915876] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f f6 2c 00 f7 d8 64 89 01 48
[ 234.915878] RSP: 002b:
00007ffcea3db3b8 EFLAGS:
00000246 ORIG_RAX:
0000000000000139
[ 234.915881] RAX:
ffffffffffffffda RBX:
000055af22c29340 RCX:
00007f4ca3168839
[ 234.915882] RDX:
0000000000000000 RSI:
000055af22c38390 RDI:
0000000000000001
[ 234.915884] RBP:
000055af22c38390 R08:
0000000000000000 R09:
0000000000000000
[ 234.915885] R10:
0000000000000001 R11:
0000000000000246 R12:
0000000000000000
[ 234.915887] R13:
000055af22c29060 R14:
0000000000040000 R15:
0000000000000000
[ 234.915896] ---[ end trace
a60f19c54aa96ec3 ]---
Signed-off-by: Brad Love <brad@nextdimension.cc>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Serge Semin [Thu, 21 May 2020 20:48:15 +0000 (23:48 +0300)]
clocksource: dw_apb_timer_of: Fix missing clockevent timers
[ Upstream commit
6d2e16a3181bafb77b535095c39ad1c8b9558c8c ]
Commit
100214889973 ("clocksource: dw_apb_timer_of: use
clocksource_of_init") replaced a publicly available driver
initialization method with one called by the timer_probe() method
available after CLKSRC_OF. In current implementation it traverses
all the timers available in the system and calls their initialization
methods if corresponding devices were either in dtb or in acpi. But
if before the commit any number of available timers would be installed
as clockevent and clocksource devices, after that there would be at most
two. The rest are just ignored since default case branch doesn't do
anything. I don't see a reason of such behaviour, neither the commit
message explains it. Moreover this might be wrong if on some platforms
these timers might be used for different purpose, as virtually CPU-local
clockevent timers and as an independent broadcast timer. So in order
to keep the compatibility with the platforms where the order of the
timers detection has some meaning, lets add the secondly discovered
timer to be of clocksource/sched_clock type, while the very first and
the others would provide the clockevents service.
Fixes:
100214889973 ("clocksource: dw_apb_timer_of: use clocksource_of_init")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200521204818.25436-7-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
Serge Semin [Thu, 21 May 2020 20:48:13 +0000 (23:48 +0300)]
clocksource: dw_apb_timer: Make CPU-affiliation being optional
[ Upstream commit
cee43dbf2ee3f430434e2b66994eff8a1aeda889 ]
Currently the DW APB Timer driver binds each clockevent timers to a
particular CPU. This isn't good for multiple reasons. First of all seeing
the device is placed on APB bus (which makes it accessible from any CPU
core), accessible over MMIO and having the DYNIRQ flag set we can be sure
that manually binding the timer to any CPU just isn't correct. By doing
so we just set an extra limitation on device usage. This also doesn't
reflect the device actual capability, since by setting the IRQ affinity
we can make it virtually local to any CPU. Secondly imagine if you had a
real CPU-local timer with the same rating and the same CPU-affinity.
In this case if DW APB timer was registered first, then due to the
clockevent framework tick-timer selection procedure we'll end up with the
real CPU-local timer being left unselected for clock-events tracking. But
on most of the platforms (MIPS/ARM/etc) such timers are normally embedded
into the CPU core and are accessible with much better performance then
devices placed on APB. For instance in MIPS architectures there is
r4k-timer, which is CPU-local, assigned with the same rating, and normally
its clockevent device is registered after the platform-specific one.
So in order to fix all of these issues let's make the DW APB Timer CPU
affinity being optional and deactivated by passing a negative CPU id,
which will effectively set the DW APB clockevent timer cpumask to
'cpu_possible_mask'.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20200521204818.25436-5-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
Serge Semin [Fri, 22 May 2020 00:07:51 +0000 (03:07 +0300)]
spi: dw: Enable interrupts in accordance with DMA xfer mode
[ Upstream commit
43dba9f3f98c2b184a19f856f06fe22817bfd9e0 ]
It's pointless to track the Tx overrun interrupts if Rx-only SPI
transfer is issued. Similarly there is no need in handling the Rx
overrun/underrun interrupts if Tx-only SPI transfer is executed.
So lets unmask the interrupts only if corresponding SPI
transactions are implied.
Co-developed-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Signed-off-by: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
Link: https://lore.kernel.org/r/20200522000806.7381-3-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Serge Semin [Thu, 21 May 2020 14:07:16 +0000 (17:07 +0300)]
mips: Fix cpu_has_mips64r1/2 activation for MIPS32 CPUs
[ Upstream commit
a2ac81c6ef4018ea49c034ce165bb9ea1cf99f3e ]
Commit
1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA
allows") updated the cpu_has_mips* macro to be replaced with a constant
expression where it's possible. By mistake it wasn't done correctly
for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to
be replaced with conditional expression __isa_range_or_flag(), which
means either ISA revision being within the range or the corresponding
CPU options flag was set at the probe stage or both being true at the
same time. But the ISA level value doesn't indicate whether the ISA is
MIPS32 or MIPS64. Due to this if we select MIPS32r1 - MIPS32r5
architectures the __isa_range() macro will activate the
cpu_has_mips64rX flags, which is incorrect. In order to fix the
problem we make sure the 64bits CPU support is enabled by means of
checking the flag cpu_has_64bits aside with proper ISA range and specific
Revision flag being set.
Fixes:
1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows")
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Paul Burton <paulburton@kernel.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tuan Phan [Wed, 20 May 2020 17:13:07 +0000 (10:13 -0700)]
ACPI/IORT: Fix PMCG node single ID mapping handling
[ Upstream commit
50c8ab8d9fbf5b18d5162a797ca26568afc0af1a ]
An IORT PMCG node can have no ID mapping if its overflow interrupt is
wire based therefore the code that parses the PMCG node can not assume
the node will always have a single mapping present at index 0.
Fix iort_get_id_mapping_index() by checking for an overflow interrupt
and mapping count.
Fixes:
24e516049360 ("ACPI/IORT: Add support for PMCG")
Signed-off-by: Tuan Phan <tuanphan@os.amperecomputing.com>
Reviewed-by: Hanjun Guo <guoahanjun@huawei.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Link: https://lore.kernel.org/r/1589994787-28637-1-git-send-email-tuanphan@os.amperecomputing.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jean-Philippe Brucker [Wed, 22 Apr 2020 08:48:06 +0000 (10:48 +0200)]
pmu/smmuv3: Clear IRQ affinity hint on device removal
[ Upstream commit
10f6cd2af21bb44faab31a50ec3361d7649e5a39 ]
Currently when trying to remove the SMMUv3 PMU module we get a
WARN_ON_ONCE from free_irq(), because the affinity hint set during probe
hasn't been properly cleared.
[ 238.878383] WARNING: CPU: 0 PID: 175 at kernel/irq/manage.c:1744 free_irq+0x324/0x358
...
[ 238.897263] Call trace:
[ 238.897998] free_irq+0x324/0x358
[ 238.898792] devm_irq_release+0x18/0x28
[ 238.899189] release_nodes+0x1b0/0x228
[ 238.899984] devres_release_all+0x38/0x60
[ 238.900779] device_release_driver_internal+0x10c/0x1d0
[ 238.901574] driver_detach+0x50/0xe0
[ 238.902368] bus_remove_driver+0x5c/0xd8
[ 238.903448] driver_unregister+0x30/0x60
[ 238.903958] platform_driver_unregister+0x14/0x20
[ 238.905075] arm_smmu_pmu_exit+0x1c/0xecc [arm_smmuv3_pmu]
[ 238.905547] __arm64_sys_delete_module+0x14c/0x260
[ 238.906342] el0_svc_common.constprop.0+0x74/0x178
[ 238.907355] do_el0_svc+0x24/0x90
[ 238.907932] el0_sync_handler+0x11c/0x198
[ 238.908979] el0_sync+0x158/0x180
Just like the other perf drivers, clear the affinity hint before
releasing the device.
Fixes:
7d839b4b9e00 ("perf/smmuv3: Add arm64 smmuv3 pmu driver")
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20200422084805.237738-1-jean-philippe@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Douglas Anderson [Thu, 7 May 2020 20:08:44 +0000 (13:08 -0700)]
kgdb: Prevent infinite recursive entries to the debugger
[ Upstream commit
3ca676e4ca60d1834bb77535dafe24169cadacef ]
If we detect that we recursively entered the debugger we should hack
our I/O ops to NULL so that the panic() in the next line won't
actually cause another recursion into the debugger. The first line of
kgdb_panic() will check this and return.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20200507130644.v4.6.I89de39f68736c9de610e6f241e68d8dbc44bc266@changeid
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Douglas Anderson [Thu, 7 May 2020 20:08:39 +0000 (13:08 -0700)]
kgdb: Disable WARN_CONSOLE_UNLOCKED for all kgdb
[ Upstream commit
202164fbfa2b2ffa3e66b504e0f126ba9a745006 ]
In commit
81eaadcae81b ("kgdboc: disable the console lock when in
kgdb") we avoided the WARN_CONSOLE_UNLOCKED() yell when we were in
kgdboc. That still works fine, but it turns out that we get a similar
yell when using other I/O drivers. One example is the "I/O driver"
for the kgdb test suite (kgdbts). When I enabled that I again got the
same yells.
Even though "kgdbts" doesn't actually interact with the user over the
console, using it still causes kgdb to print to the consoles. That
trips the same warning:
con_is_visible+0x60/0x68
con_scroll+0x110/0x1b8
lf+0x4c/0xc8
vt_console_print+0x1b8/0x348
vkdb_printf+0x320/0x89c
kdb_printf+0x68/0x90
kdb_main_loop+0x190/0x860
kdb_stub+0x2cc/0x3ec
kgdb_cpu_enter+0x268/0x744
kgdb_handle_exception+0x1a4/0x200
kgdb_compiled_brk_fn+0x34/0x44
brk_handler+0x7c/0xb8
do_debug_exception+0x1b4/0x228
Let's increment/decrement the "ignore_console_lock_warning" variable
all the time when we enter the debugger.
This will allow us to later revert commit
81eaadcae81b ("kgdboc:
disable the console lock when in kgdb").
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>
Link: https://lore.kernel.org/r/20200507130644.v4.1.Ied2b058357152ebcc8bf68edd6f20a11d98d7d4e@changeid
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hsin-Yu Chao [Fri, 15 May 2020 09:27:04 +0000 (17:27 +0800)]
Bluetooth: Add SCO fallback for invalid LMP parameters error
[ Upstream commit
56b5453a86203a44726f523b4133c1feca49ce7c ]
Bluetooth PTS test case HFP/AG/ACC/BI-12-I accepts SCO connection
with invalid parameter at the first SCO request expecting AG to
attempt another SCO request with the use of "safe settings" for
given codec, base on section 5.7.1.2 of HFP 1.7 specification.
This patch addresses it by adding "Invalid LMP Parameters" (0x1e)
to the SCO fallback case. Verified with below log:
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
Handle: 256
Transmit bandwidth: 8000
Receive bandwidth: 8000
Max latency: 13
Setting: 0x0003
Input Coding: Linear
Input Data Format: 1's complement
Input Sample Size: 8-bit
# of bits padding at MSB: 0
Air Coding Format: Transparent Data
Retransmission effort: Optimize for link quality (0x02)
Packet type: 0x0380
3-EV3 may not be used
2-EV5 may not be used
3-EV5 may not be used
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) ncmd 1
Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5
Num handles: 1
Handle: 256
Count: 1
> HCI Event: Max Slots Change (0x1b) plen 3
Handle: 256
Max slots: 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
Status: Invalid LMP Parameters / Invalid LL Parameters (0x1e)
Handle: 0
Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
Link type: eSCO (0x02)
Transmission interval: 0x00
Retransmission window: 0x02
RX packet length: 0
TX packet length: 0
Air mode: Transparent (0x03)
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
Handle: 256
Transmit bandwidth: 8000
Receive bandwidth: 8000
Max latency: 8
Setting: 0x0003
Input Coding: Linear
Input Data Format: 1's complement
Input Sample Size: 8-bit
# of bits padding at MSB: 0
Air Coding Format: Transparent Data
Retransmission effort: Optimize for link quality (0x02)
Packet type: 0x03c8
EV3 may be used
2-EV3 may not be used
3-EV3 may not be used
2-EV5 may not be used
3-EV5 may not be used
> HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) ncmd 1
Status: Success (0x00)
> HCI Event: Max Slots Change (0x1b) plen 3
Handle: 256
Max slots: 5
> HCI Event: Max Slots Change (0x1b) plen 3
Handle: 256
Max slots: 1
> HCI Event: Synchronous Connect Complete (0x2c) plen 17
Status: Success (0x00)
Handle: 257
Address: 00:1B:DC:F2:21:59 (OUI 00-1B-DC)
Link type: eSCO (0x02)
Transmission interval: 0x06
Retransmission window: 0x04
RX packet length: 30
TX packet length: 30
Air mode: Transparent (0x03)
Signed-off-by: Hsin-Yu Chao <hychao@chromium.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tiezhu Yang [Sat, 16 May 2020 02:15:48 +0000 (10:15 +0800)]
MIPS: Loongson: Build ATI Radeon GPU driver as module
[ Upstream commit
a44de7497f91834df0b8b6d459e259788ba66794 ]
When ATI Radeon GPU driver has been compiled directly into the kernel
instead of as a module, we should make sure the firmware for the model
(check available ones in /lib/firmware/radeon) is built-in to the kernel
as well, otherwise there exists the following fatal error during GPU init,
change CONFIG_DRM_RADEON=y to CONFIG_DRM_RADEON=m to fix it.
[ 1.900997] [drm] Loading RS780 Microcode
[ 1.905077] radeon 0000:01:05.0: Direct firmware load for radeon/RS780_pfp.bin failed with error -2
[ 1.914140] r600_cp: Failed to load firmware "radeon/RS780_pfp.bin"
[ 1.920405] [drm:r600_init] *ERROR* Failed to load firmware!
[ 1.926069] radeon 0000:01:05.0: Fatal error during GPU init
[ 1.931729] [drm] radeon: finishing device.
Fixes:
024e6a8b5bb1 ("MIPS: Loongson: Add a Loongson-3 default config file")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Koba Ko [Mon, 11 May 2020 01:44:56 +0000 (09:44 +0800)]
platform/x86: dell-laptop: don't register micmute LED if there is no token
[ Upstream commit
257e03a334ccb96e657bf5f6ab3b5693a22c2aa4 ]
On Dell G3-3590, error message is issued during boot up,
"platform::micmute: Setting an LED's brightness failed (-19)",
but there's no micmute led on the machine.
Get the related tokens of SMBIOS, GLOBAL_MIC_MUTE_DISABLE/ENABLE.
If one of two tokens doesn't exist,
don't call led_classdev_register() for platform::micmute.
After that, you wouldn't see the platform::micmute in /sys/class/leds/,
and the error message wouldn't see in dmesg.
Fixes:
d00fa46e0a2c6 ("platform/x86: dell-laptop: Add micmute LED trigger support")
Signed-off-by: Koba Ko <koba.ko@canonical.com>
Reviewed-by: Mario Limonciello <Mario.limonciello@dell.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jesper Dangaard Brouer [Thu, 14 May 2020 10:50:49 +0000 (12:50 +0200)]
ixgbe: Fix XDP redirect on archs with PAGE_SIZE above 4K
[ Upstream commit
88eb0ee17b2ece64fcf6689a4557a5c2e7a89c4b ]
The ixgbe driver have another memory model when compiled on archs with
PAGE_SIZE above 4096 bytes. In this mode it doesn't split the page in
two halves, but instead increment rx_buffer->page_offset by truesize of
packet (which include headroom and tailroom for skb_shared_info).
This is done correctly in ixgbe_build_skb(), but in ixgbe_rx_buffer_flip
which is currently only called on XDP_TX and XDP_REDIRECT, it forgets
to add the tailroom for skb_shared_info. This breaks XDP_REDIRECT, for
veth and cpumap. Fix by adding size of skb_shared_info tailroom.
Maintainers notice: This fix have been queued to Jeff.
Fixes:
6453073987ba ("ixgbe: add initial support for xdp redirect")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Link: https://lore.kernel.org/bpf/158945344946.97035.17031588499266605743.stgit@firesoul
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jeremy Cline [Thu, 14 May 2020 14:05:46 +0000 (10:05 -0400)]
lockdown: Allow unprivileged users to see lockdown status
[ Upstream commit
60cf7c5ed5f7087c4de87a7676b8c82d96fd166c ]
A number of userspace tools, such as systemtap, need a way to see the
current lockdown state so they can gracefully deal with the kernel being
locked down. The state is already exposed in
/sys/kernel/security/lockdown, but is only readable by root. Adjust the
permissions so unprivileged users can read the state.
Fixes:
000d388ed3bb ("security: Add a static lockdown policy LSM")
Cc: Frank Ch. Eigler <fche@redhat.com>
Signed-off-by: Jeremy Cline <jcline@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tomohito Esaki [Wed, 1 Apr 2020 06:11:00 +0000 (15:11 +0900)]
drm: rcar-du: Set primary plane zpos immutably at initializing
[ Upstream commit
7982471d01aac33994276bf567c8f1f3a137648a ]
According to drm_plane_create_zpos_property() function documentation,
all planes zpos range should be set if zpos property is supported.
However, the rcar-du driver didn't set primary plane zpos range. Since
the primary plane's zpos is fixed, set it immutably.
Reported-by: Yoshihito Ogawa <yoshihito.ogawa.kc@renesas.com>
Reported-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
[Turn continue into if ... else ...]
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Weiping Zhang [Wed, 13 May 2020 00:44:05 +0000 (08:44 +0800)]
block: reset mapping if failed to update hardware queue count
[ 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/8541
CPU: 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/0xb3
Signed-off-by: Weiping Zhang <zhangweiping@didiglobal.com>
Tested-by: Bart van Assche <bvanassche@acm.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luke Nelson [Fri, 8 May 2020 18:15:44 +0000 (11:15 -0700)]
arm64: insn: Fix two bugs in encoding 32-bit logical immediates
[ 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 <will@kernel.org>
Co-developed-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200508181547.24783-2-luke.r.nels@gmail.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ming Lei [Thu, 7 May 2020 13:04:08 +0000 (21:04 +0800)]
block: alloc map and request for new hardware queue
[ 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 system
A 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 <0f> 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 <44> 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/0xa9
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Weiping Zhang <zhangweiping@didiglobal.com>
Tested-by: Weiping Zhang <zhangweiping@didiglobal.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erik Kaneda [Tue, 5 May 2020 00:46:52 +0000 (17:46 -0700)]
ACPICA: Dispatcher: add status checks
[ Upstream commit
6bfe5344b2956d0bee116f1c640aef05e5cddd76 ]
ACPICA commit
3244c1eeba9f9fb9ccedb875f7923a3d85e0c6aa
The status chekcs are used to to avoid NULL pointer dereference on
field objects
Link: https://github.com/acpica/acpica/commit/3244c1ee
Reported-by: Kurt Kennett <kurt_kennett@hotmail.com>
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Wed, 6 May 2020 15:30:18 +0000 (18:30 +0300)]
spi: dw: Zero DMA Tx and Rx configurations on stack
[ 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 <andriy.shevchenko@linux.intel.com>
Acked-by: Feng Tang <feng.tang@intel.com>
Cc: Feng Tang <feng.tang@intel.com>
Link: https://lore.kernel.org/r/20200506153025.21441-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dejin Zheng [Mon, 4 May 2020 08:34:42 +0000 (16:34 +0800)]
rtw88: fix an issue about leak system resources
[ 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 <andy.shevchenko@gmail.com>
Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Acked-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200504083442.3033-1-zhengdejin5@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tomasz Figa [Sat, 11 Apr 2020 17:37:10 +0000 (19:37 +0200)]
media: staging: ipu3: Fix stale list entries on parameter queue failure
[ 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 <0f> 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 <48> 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 <49> 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 <48> 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 ov567
Fix 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 <tfiga@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Thompson [Mon, 4 May 2020 17:05:18 +0000 (18:05 +0100)]
arm64: cacheflush: Fix KGDB trap detection
[ 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 <daniel.thompson@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20200504170518.2959478-1-daniel.thompson@linaro.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wen Gong [Mon, 4 May 2020 09:03:14 +0000 (12:03 +0300)]
ath10k: remove the max_sched_scan_reqs value
[ 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 <wgong@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20191114050001.4658-1-wgong@codeaurora.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Mon, 4 May 2020 08:06:29 +0000 (10:06 +0200)]
efi/libstub/x86: Work around LLVM ELF quirk build regression
[ 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 10
This 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 <ndesaulniers@google.com>
Cc: Peter Collingbourne <pcc@google.com>
Cc: Sami Tolvanen <samitolvanen@google.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: Fangrui Song <maskray@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arthur Kiyanovski [Sun, 3 May 2020 09:52:11 +0000 (09:52 +0000)]
net: ena: fix error returning in ena_com_get_hash_function()
[ 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 <sameehj@amazon.com>
Signed-off-by: Arthur Kiyanovski <akiyano@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mark Starovoytov [Thu, 30 Apr 2020 08:04:34 +0000 (11:04 +0300)]
net: atlantic: make hw_get_regs optional
[ Upstream commit
d0f23741c202c685447050713907f3be39a985ee ]
This patch fixes potential crash in case if hw_get_regs is NULL.
Signed-off-by: Mark Starovoytov <mstarovoitov@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Huaixin Chang [Mon, 20 Apr 2020 02:44:21 +0000 (10:44 +0800)]
sched/fair: Refill bandwidth before scaling
[ 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 <changhuaixin@linux.alibaba.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Ben Segall <bsegall@google.com>
Reviewed-by: Phil Auld <pauld@redhat.com>
Link: https://lkml.kernel.org/r/20200420024421.22442-3-changhuaixin@linux.alibaba.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Zijlstra [Tue, 28 Apr 2020 17:57:59 +0000 (19:57 +0200)]
x86,smap: Fix smap_{save,restore}() alternatives
[ 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 stack
the 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) <peterz@infradead.org>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20200429101802.GI13592@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
Evan Green [Mon, 27 Apr 2020 23:32:48 +0000 (16:32 -0700)]
spi: pxa2xx: Apply CS clk quirk to BXT
[ 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 <evgreen@chromium.org>
Cc: Shobhit Srivastava <shobhit.srivastava@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20200427163238.1.Ib1faaabe236e37ea73be9b8dcc6aa034cb3c8804@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Wed, 29 Apr 2020 01:21:04 +0000 (18:21 -0700)]
libbpf: Fix memory leak and possible double-free in hashmap__clear
[ 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 <alston64@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20200429012111.277390-5-andriin@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gavin Shan [Mon, 27 Apr 2020 23:57:00 +0000 (09:57 +1000)]
arm64/kernel: Fix range on invalidating dcache for boot page tables
[ 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 <gshan@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20200427235700.112220-1-gshan@redhat.com
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
limingyu [Wed, 22 Apr 2020 09:01:19 +0000 (17:01 +0800)]
drm/amdgpu: Init data to avoid oops while reading pp_num_states.
[ 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_states
Message from syslogd@uos-PC at Apr 22 09:26:20 ...
kernel:[ 82.154129] Internal error: Oops:
96000004 [#1] SMP
This patch aims to fix this problem, avoid that reading file
triggers the kernel sementfault.
Signed-off-by: limingyu <limingyu@uniontech.com>
Signed-off-by: zhoubinbin <zhoubinbin@uniontech.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Geert Uytterhoeven [Thu, 16 Apr 2020 10:14:18 +0000 (12:14 +0200)]
spi: spi-mem: Fix Dual/Quad modes on Octal-capable devices
[ 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 <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20200416101418.14379-1-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julien Thierry [Fri, 27 Mar 2020 15:28:41 +0000 (15:28 +0000)]
objtool: Ignore empty alternatives
[ 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 <jthierry@redhat.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Brad Love [Thu, 14 Nov 2019 20:03:57 +0000 (21:03 +0100)]
media: si2157: Better check for running tuner in init
[ 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 <brad@nextdimension.cc>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Tue, 7 Apr 2020 09:32:37 +0000 (11:32 +0200)]
media: vicodec: Fix error codes in probe function
[ 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 <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Wed, 8 Apr 2020 16:26:48 +0000 (18:26 +0200)]
crypto: ccp -- don't "select" CONFIG_DMADEVICES
[ 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_FREESCALE
The 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 <arnd@arndb.de>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Laurent Pinchart [Thu, 12 Mar 2020 23:47:09 +0000 (00:47 +0100)]
media: imx: imx7-mipi-csis: Cleanup and fix subdev pad format handling
[ 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 <laurent.pinchart@ideasonboard.com>
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bingbu Cao [Tue, 24 Mar 2020 04:16:48 +0000 (05:16 +0100)]
media: staging: imgu: do not hold spinlock during freeing mmu page table
[ 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 <bingbu.cao@intel.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bogdan Togorean [Mon, 13 Apr 2020 11:35:08 +0000 (14:35 +0300)]
drm: bridge: adv7511: Extend list of audio sample rates
[ 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 <bogdan.togorean@analog.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200413113513.86091-2-bogdan.togorean@analog.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maharaja Kennadyrajan [Thu, 26 Mar 2020 16:36:36 +0000 (18:36 +0200)]
ath10k: Fix the race condition in firmware dump work queue
[ 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-00044
Co-developed-by: Govindaraj Saminathan <gsamin@codeaurora.org>
Signed-off-by: Govindaraj Saminathan <gsamin@codeaurora.org>
Signed-off-by: Maharaja Kennadyrajan <mkenna@codeaurora.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1585213077-28439-1-git-send-email-mkenna@codeaurora.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian König [Thu, 12 Mar 2020 11:03:34 +0000 (12:03 +0100)]
drm/amdgpu: fix and cleanup amdgpu_gem_object_close v4
[ 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_close
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: xinhui pan <xinhui.pan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ard Biesheuvel [Wed, 27 May 2020 11:37:00 +0000 (13:37 +0200)]
ACPI: GED: use correct trigger type field in _Exx / _Lxx handling
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 nonetheless
Fixes:
ea6f3af4c5e63f69 ("ACPI: GED: add support for _Exx / _Lxx handler methods")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 17 Jun 2020 14:40:38 +0000 (16:40 +0200)]
Linux 5.4.47
Marc Zyngier [Wed, 3 Jun 2020 17:24:01 +0000 (18:24 +0100)]
KVM: arm64: Save the host's PtrAuth keys in non-preemptible context
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 <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Tue, 9 Jun 2020 07:50:29 +0000 (08:50 +0100)]
KVM: arm64: Synchronize sysreg state on injecting an AArch32 exception
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 there
For 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 <james.morse@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Mon, 11 May 2020 07:42:31 +0000 (09:42 +0200)]
xen/pvcalls-back: test for errors when calling backend_connect()
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 <jgross@suse.com>
Link: https://lore.kernel.org/r/20200511074231.19794-1-jgross@suse.com
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Kosina [Tue, 26 May 2020 09:49:18 +0000 (11:49 +0200)]
block/floppy: fix contended case in floppy_queue_rq()
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 is
for 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 <lpechacek@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ulf Hansson [Thu, 30 Apr 2020 09:16:38 +0000 (11:16 +0200)]
mmc: sdio: Fix several potential memory leaks in mmc_sdio_init_card()
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: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200430091640.455-3-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ulf Hansson [Thu, 30 Apr 2020 09:16:37 +0000 (11:16 +0200)]
mmc: sdio: Fix potential NULL pointer error in mmc_sdio_init_card()
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: <stable@vger.kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20200430091640.455-2-ulf.hansson@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ludovic Desroches [Wed, 1 Apr 2020 22:15:00 +0000 (00:15 +0200)]
ARM: dts: at91: sama5d2_ptc_ek: fix sdmmc0 node description
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 <ludovic.desroches@microchip.com>
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 <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masahiro Yamada [Mon, 11 May 2020 06:21:58 +0000 (15:21 +0900)]
mmc: uniphier-sd: call devm_request_irq() after tmio_mmc_host_probe()
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 <yamada.masahiro@socionext.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200511062158.1790924-1-yamada.masahiro@socionext.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ulf Hansson [Tue, 19 May 2020 15:24:34 +0000 (17:24 +0200)]
mmc: tmio: Further fixup runtime PM management at remove
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 <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200519152434.6867-1-ulf.hansson@linaro.org
Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ludovic Barre [Tue, 26 May 2020 15:51:02 +0000 (17:51 +0200)]
mmc: mmci_sdmmc: fix DMA API warning overlapping mappings
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
[<
c03138c0>] (unwind_backtrace) from [<
c030d760>] (show_stack+0x10/0x14)
[<
c030d760>] (show_stack) from [<
c0f2eb28>] (dump_stack+0xc0/0xd4)
[<
c0f2eb28>] (dump_stack) from [<
c034a14c>] (__warn+0xd0/0xf8)
[<
c034a14c>] (__warn) from [<
c034a530>] (warn_slowpath_fmt+0x94/0xb8)
[<
c034a530>] (warn_slowpath_fmt) from [<
c03bca0c>] (add_dma_entry+0x16c/0x17c)
[<
c03bca0c>] (add_dma_entry) from [<
c03bdf54>] (debug_dma_map_sg+0xe4/0x3d4)
[<
c03bdf54>] (debug_dma_map_sg) from [<
c0d09244>] (sdmmc_idma_prep_data+0x94/0xf8)
[<
c0d09244>] (sdmmc_idma_prep_data) from [<
c0d05a2c>] (mmci_prep_data+0x2c/0xb0)
[<
c0d05a2c>] (mmci_prep_data) from [<
c0d073ec>] (mmci_start_data+0x134/0x2f0)
[<
c0d073ec>] (mmci_start_data) from [<
c0d078d0>] (mmci_request+0xe8/0x154)
[<
c0d078d0>] (mmci_request) from [<
c0cecb44>] (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 <ludovic.barre@st.com>
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 <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Veerabhadrarao Badiganti [Thu, 28 May 2020 15:13:52 +0000 (20:43 +0530)]
mmc: sdhci-msm: Clear tuning done flag while hs400 tuning
commit
9253d71011c349d5f5cc0cebdf68b4a80811b92d upstream.
Clear tuning_done flag while executing tuning to ensure vendor
specific HS400 settings are applied properly when the controller
is re-initialized in HS400 mode.
Without this, re-initialization of the qcom SDHC in HS400 mode fails
while resuming the driver from runtime-suspend or system-suspend.
Fixes:
ff06ce417828 ("mmc: sdhci-msm: Add HS400 platform support")
Cc: stable@vger.kernel.org
Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
Link: https://lore.kernel.org/r/1590678838-18099-1-git-send-email-vbadigan@codeaurora.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Wilson [Fri, 10 Apr 2020 08:35:35 +0000 (09:35 +0100)]
agp/intel: Reinforce the barrier after GTT updates
commit
f30d3ced9fafa03e4855508929b5b6334907f45e upstream.
After changing the timing between GTT updates and execution on the GPU,
we started seeing sporadic failures on Ironlake. These were narrowed
down to being an insufficiently strong enough barrier/delay after
updating the GTT and scheduling execution on the GPU. By forcing the
uncached read, and adding the missing barrier for the singular
insert_page (relocation paths), the sporadic failures go away.
Fixes:
983d308cb8f6 ("agp/intel: Serialise after GTT updates")
Fixes:
3497971a71d8 ("agp/intel: Flush chipset writes after updating a single PTE")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Andi Shyti <andi.shyti@intel.com>
Cc: stable@vger.kernel.org # v4.0+
Link: https://patchwork.freedesktop.org/patch/msgid/20200410083535.25464-1-chris@chris-wilson.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Barret Rhoden [Tue, 14 Apr 2020 22:29:20 +0000 (18:29 -0400)]
perf: Add cond_resched() to task_function_call()
commit
2ed6edd33a214bca02bd2b45e3fc3038a059436b upstream.
Under rare circumstances, task_function_call() can repeatedly fail and
cause a soft lockup.
There is a slight race where the process is no longer running on the cpu
we targeted by the time remote_function() runs. The code will simply
try again. If we are very unlucky, this will continue to fail, until a
watchdog fires. This can happen in a heavily loaded, multi-core virtual
machine.
Reported-by: syzbot+bb4935a5c09b5ff79940@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200414222920.121401-1-brho@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
OGAWA Hirofumi [Thu, 4 Jun 2020 23:50:56 +0000 (16:50 -0700)]
fat: don't allow to mount if the FAT length == 0
commit
b1b65750b8db67834482f758fc385bfa7560d228 upstream.
If FAT length == 0, the image doesn't have any data. And it can be the
cause of overlapping the root dir and FAT entries.
Also Windows treats it as invalid format.
Reported-by: syzbot+6f1624f937d9d6911e2d@syzkaller.appspotmail.com
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Marco Elver <elver@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Link: http://lkml.kernel.org/r/87r1wz8mrd.fsf@mail.parknet.co.jp
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang Hai [Wed, 3 Jun 2020 22:56:21 +0000 (15:56 -0700)]
mm/slub: fix a memory leak in sysfs_slab_add()
commit
dde3c6b72a16c2db826f54b2d49bdea26c3534a2 upstream.
syzkaller reports for memory leak when kobject_init_and_add() returns an
error in the function sysfs_slab_add() [1]
When this happened, the function kobject_put() is not called for the
corresponding kobject, which potentially leads to memory leak.
This patch fixes the issue by calling kobject_put() even if
kobject_init_and_add() fails.
[1]
BUG: memory leak
unreferenced object 0xffff8880a6d4be88 (size 8):
comm "syz-executor.3", pid 946, jiffies
4295772514 (age 18.396s)
hex dump (first 8 bytes):
70 69 64 5f 33 00 ff ff pid_3...
backtrace:
kstrdup+0x35/0x70 mm/util.c:60
kstrdup_const+0x3d/0x50 mm/util.c:82
kvasprintf_const+0x112/0x170 lib/kasprintf.c:48
kobject_set_name_vargs+0x55/0x130 lib/kobject.c:289
kobject_add_varg lib/kobject.c:384 [inline]
kobject_init_and_add+0xd8/0x170 lib/kobject.c:473
sysfs_slab_add+0x1d8/0x290 mm/slub.c:5811
__kmem_cache_create+0x50a/0x570 mm/slub.c:4384
create_cache+0x113/0x1e0 mm/slab_common.c:407
kmem_cache_create_usercopy+0x1a1/0x260 mm/slab_common.c:505
kmem_cache_create+0xd/0x10 mm/slab_common.c:564
create_pid_cachep kernel/pid_namespace.c:54 [inline]
create_pid_namespace kernel/pid_namespace.c:96 [inline]
copy_pid_ns+0x77c/0x8f0 kernel/pid_namespace.c:148
create_new_namespaces+0x26b/0xa30 kernel/nsproxy.c:95
unshare_nsproxy_namespaces+0xa7/0x1e0 kernel/nsproxy.c:229
ksys_unshare+0x3d2/0x770 kernel/fork.c:2969
__do_sys_unshare kernel/fork.c:3037 [inline]
__se_sys_unshare kernel/fork.c:3035 [inline]
__x64_sys_unshare+0x2d/0x40 kernel/fork.c:3035
do_syscall_64+0xa1/0x530 arch/x86/entry/common.c:295
Fixes:
80da026a8e5d ("mm/slub: fix slab double-free in case of duplicate sysfs filename")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Link: http://lkml.kernel.org/r/20200602115033.1054-1-wanghai38@huawei.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ezequiel Garcia [Mon, 27 Apr 2020 21:44:05 +0000 (18:44 -0300)]
drm/vkms: Hold gem object while still in-use
commit
0ea2ea42b31abc1141f2fd3911f952a97d401fcb upstream.
We need to keep the reference to the drm_gem_object
until the last access by vkms_dumb_create.
Therefore, the put the object after it is used.
This fixes a use-after-free issue reported by syzbot.
While here, change vkms_gem_create() symbol to static.
Reported-and-tested-by: syzbot+e3372a2afe1e7ef04bc7@syzkaller.appspotmail.com
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200427214405.13069-1-ezequiel@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Casey Schaufler [Thu, 9 Apr 2020 23:35:28 +0000 (16:35 -0700)]
Smack: slab-out-of-bounds in vsscanf
commit
84e99e58e8d1e26f04c097f4266e431a33987f36 upstream.
Add barrier to soob. Return -EOVERFLOW if the buffer
is exceeded.
Suggested-by: Hillf Danton <hdanton@sina.com>
Reported-by: syzbot+bfdd4a2f07be52351350@syzkaller.appspotmail.com
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiujun Huang [Sat, 4 Apr 2020 04:18:38 +0000 (12:18 +0800)]
ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb
commit
2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream.
In ath9k_hif_usb_rx_cb interface number is assumed to be 0.
usb_ifnum_to_if(urb->dev, 0)
But it isn't always true.
The case reported by syzbot:
https://lore.kernel.org/linux-usb/
000000000000666c9c05a1c05d12@google.com
usb 2-1: new high-speed USB device number 2 using dummy_hcd
usb 2-1: config 1 has an invalid interface number: 2 but max is 0
usb 2-1: config 1 has no interface number 0
usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice=
1.08
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
general protection fault, probably for non-canonical address
0xdffffc0000000015: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0
Call Trace
__usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
__do_softirq+0x21e/0x950 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x178/0x1a0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:546 [inline]
smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiujun Huang [Sat, 4 Apr 2020 04:18:37 +0000 (12:18 +0800)]
ath9x: Fix stack-out-of-bounds Write in ath9k_hif_usb_rx_cb
commit
19d6c375d671ce9949a864fb9a03e19f5487b4d3 upstream.
Add barrier to accessing the stack array skb_pool.
The case reported by syzbot:
https://lore.kernel.org/linux-usb/
0000000000003d7c1505a2168418@google.com
BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_stream
drivers/net/wireless/ath/ath9k/hif_usb.c:626 [inline]
BUG: KASAN: stack-out-of-bounds in ath9k_hif_usb_rx_cb+0xdf6/0xf70
drivers/net/wireless/ath/ath9k/hif_usb.c:666
Write of size 8 at addr
ffff8881db309a28 by task swapper/1/0
Call Trace:
ath9k_hif_usb_rx_stream drivers/net/wireless/ath/ath9k/hif_usb.c:626
[inline]
ath9k_hif_usb_rx_cb+0xdf6/0xf70
drivers/net/wireless/ath/ath9k/hif_usb.c:666
__usb_hcd_giveback_urb+0x1f2/0x470 drivers/usb/core/hcd.c:1648
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1713
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
Reported-and-tested-by: syzbot+d403396d4df67ad0bd5f@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200404041838.10426-5-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiujun Huang [Sat, 4 Apr 2020 04:18:36 +0000 (12:18 +0800)]
ath9k: Fix use-after-free Write in ath9k_htc_rx_msg
commit
e4ff08a4d727146bb6717a39a8d399d834654345 upstream.
Write out of slab bounds. We should check epid.
The case reported by syzbot:
https://lore.kernel.org/linux-usb/
0000000000006ac55b05a1c05d72@google.com
BUG: KASAN: use-after-free in htc_process_conn_rsp
drivers/net/wireless/ath/ath9k/htc_hst.c:131 [inline]
BUG: KASAN: use-after-free in ath9k_htc_rx_msg+0xa25/0xaf0
drivers/net/wireless/ath/ath9k/htc_hst.c:443
Write of size 2 at addr
ffff8881cea291f0 by task swapper/1/0
Call Trace:
htc_process_conn_rsp drivers/net/wireless/ath/ath9k/htc_hst.c:131
[inline]
ath9k_htc_rx_msg+0xa25/0xaf0
drivers/net/wireless/ath/ath9k/htc_hst.c:443
ath9k_hif_usb_reg_in_cb+0x1ba/0x630
drivers/net/wireless/ath/ath9k/hif_usb.c:718
__usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
Reported-and-tested-by: syzbot+b1c61e5f11be5782f192@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200404041838.10426-4-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiujun Huang [Sat, 4 Apr 2020 04:18:35 +0000 (12:18 +0800)]
ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
commit
abeaa85054ff8cfe8b99aafc5c70ea067e5d0908 upstream.
Free wmi later after cmd urb has been killed, as urb cb will access wmi.
the case reported by syzbot:
https://lore.kernel.org/linux-usb/
0000000000000002fc05a1d61a68@google.com
BUG: KASAN: use-after-free in ath9k_wmi_ctrl_rx+0x416/0x500
drivers/net/wireless/ath/ath9k/wmi.c:215
Read of size 1 at addr
ffff8881cef1417c by task swapper/1/0
Call Trace:
<IRQ>
ath9k_wmi_ctrl_rx+0x416/0x500 drivers/net/wireless/ath/ath9k/wmi.c:215
ath9k_htc_rx_msg+0x2da/0xaf0
drivers/net/wireless/ath/ath9k/htc_hst.c:459
ath9k_hif_usb_reg_in_cb+0x1ba/0x630
drivers/net/wireless/ath/ath9k/hif_usb.c:718
__usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
Reported-and-tested-by: syzbot+5d338854440137ea0fef@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200404041838.10426-3-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qiujun Huang [Sat, 4 Apr 2020 04:18:34 +0000 (12:18 +0800)]
ath9k: Fix use-after-free Read in htc_connect_service
commit
ced21a4c726bdc60b1680c050a284b08803bc64c upstream.
The skb is consumed by htc_send_epid, so it needn't release again.
The case reported by syzbot:
https://lore.kernel.org/linux-usb/
000000000000590f6b05a1c05d15@google.com
usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size:
51008
usb 1-1: Service connection timeout for: 256
==================================================================
BUG: KASAN: use-after-free in atomic_read
include/asm-generic/atomic-instrumented.h:26 [inline]
BUG: KASAN: use-after-free in refcount_read include/linux/refcount.h:134
[inline]
BUG: KASAN: use-after-free in skb_unref include/linux/skbuff.h:1042
[inline]
BUG: KASAN: use-after-free in kfree_skb+0x32/0x3d0 net/core/skbuff.c:692
Read of size 4 at addr
ffff8881d0957994 by task kworker/1:2/83
Call Trace:
kfree_skb+0x32/0x3d0 net/core/skbuff.c:692
htc_connect_service.cold+0xa9/0x109
drivers/net/wireless/ath/ath9k/htc_hst.c:282
ath9k_wmi_connect+0xd2/0x1a0 drivers/net/wireless/ath/ath9k/wmi.c:265
ath9k_init_htc_services.constprop.0+0xb4/0x650
drivers/net/wireless/ath/ath9k/htc_drv_init.c:146
ath9k_htc_probe_device+0x25a/0x1d80
drivers/net/wireless/ath/ath9k/htc_drv_init.c:959
ath9k_htc_hw_init+0x31/0x60
drivers/net/wireless/ath/ath9k/htc_hst.c:501
ath9k_hif_usb_firmware_cb+0x26b/0x500
drivers/net/wireless/ath/ath9k/hif_usb.c:1187
request_firmware_work_func+0x126/0x242
drivers/base/firmware_loader/main.c:976
process_one_work+0x94b/0x1620 kernel/workqueue.c:2264
worker_thread+0x96/0xe20 kernel/workqueue.c:2410
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Allocated by task 83:
kmem_cache_alloc_node+0xdc/0x330 mm/slub.c:2814
__alloc_skb+0xba/0x5a0 net/core/skbuff.c:198
alloc_skb include/linux/skbuff.h:1081 [inline]
htc_connect_service+0x2cc/0x840
drivers/net/wireless/ath/ath9k/htc_hst.c:257
ath9k_wmi_connect+0xd2/0x1a0 drivers/net/wireless/ath/ath9k/wmi.c:265
ath9k_init_htc_services.constprop.0+0xb4/0x650
drivers/net/wireless/ath/ath9k/htc_drv_init.c:146
ath9k_htc_probe_device+0x25a/0x1d80
drivers/net/wireless/ath/ath9k/htc_drv_init.c:959
ath9k_htc_hw_init+0x31/0x60
drivers/net/wireless/ath/ath9k/htc_hst.c:501
ath9k_hif_usb_firmware_cb+0x26b/0x500
drivers/net/wireless/ath/ath9k/hif_usb.c:1187
request_firmware_work_func+0x126/0x242
drivers/base/firmware_loader/main.c:976
process_one_work+0x94b/0x1620 kernel/workqueue.c:2264
worker_thread+0x96/0xe20 kernel/workqueue.c:2410
kthread+0x318/0x420 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Freed by task 0:
kfree_skb+0x102/0x3d0 net/core/skbuff.c:690
ath9k_htc_txcompletion_cb+0x1f8/0x2b0
drivers/net/wireless/ath/ath9k/htc_hst.c:356
hif_usb_regout_cb+0x10b/0x1b0
drivers/net/wireless/ath/ath9k/hif_usb.c:90
__usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650
usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716
dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966
call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786
__do_softirq+0x21e/0x950 kernel/softirq.c:292
Reported-and-tested-by: syzbot+9505af1ae303dabdc646@syzkaller.appspotmail.com
Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200404041838.10426-2-hqjagain@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Mon, 25 May 2020 10:20:57 +0000 (19:20 +0900)]
selftests/ftrace: Return unsupported if no error_log file
commit
619ee76f5c9f6a1d601d1a056a454d62bf676ae4 upstream.
Check whether error_log file exists in tracing/error_log testcase
and return UNSUPPORTED if no error_log file.
This can happen if we run the ftracetest on the older stable
kernel.
Fixes:
4eab1cc461a6 ("selftests/ftrace: Add tracing/error_log testcase")
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dick Kennedy [Fri, 1 May 2020 21:43:05 +0000 (14:43 -0700)]
scsi: lpfc: Fix negation of else clause in lpfc_prep_node_fc4type
commit
f809da6db68a8be49e317f0ccfbced1af9258839 upstream.
Implementation of a previous patch added a condition to an if check that
always end up with the if test being true. Execution of the else clause was
inadvertently negated. The additional condition check was incorrect and
unnecessary after the other modifications had been done in that patch.
Remove the check from the if series.
Link: https://lore.kernel.org/r/20200501214310.91713-5-jsmart2021@gmail.com
Fixes:
b95b21193c85 ("scsi: lpfc: Fix loss of remote port after devloss due to lack of RPIs")
Cc: <stable@vger.kernel.org> # v5.4+
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>