| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[ Upstream commit ab07506b0454bea606095951e19e72c282bfbb42 ]
If firmware load fails after having loaded some parts of the
firmware, e.g. the IML image, then this would leak. For the
host command list we'd end up running into a WARN on the next
attempt to load another firmware image.
Fix this by calling iwl_dealloc_ucode() on failures, and make
that also clear the data so we start fresh on the next round.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211210110539.1f742f0eb58a.I1315f22f6aa632d94ae2069f85e1bca5e734dce0@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 92c550f9ffd2884bb5def52b5c0485a35e452784 ]
do_div() does a 64-by-32 division. Here the divisor is an unsigned long
which on some platforms is 64 bit wide. So use div64_ul instead of do_div
to avoid a possible truncation.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Changcheng Deng <deng.changcheng@zte.com.cn>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211125014311.45942-1-deng.changcheng@zte.com.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit c1afb26727d9e507d3e17a9890e7aaf7fc85cd55 ]
These settings enables mac to detect and recover when rx fifo
circuit deadlock occurs. Previous version missed this, so we fix it.
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211217012708.8623-1-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6ce708f54cc8d73beca213cec66ede5ce100a781 ]
Large pkt_len can lead to out-out-bound memcpy. Current
ath9k_hif_usb_rx_stream allows combining the content of two urb
inputs to one pkt. The first input can indicate the size of the
pkt. Any remaining size is saved in hif_dev->rx_remain_len.
While processing the next input, memcpy is used with rx_remain_len.
4-byte pkt_len can go up to 0xffff, while a single input is 0x4000
maximum in size (MAX_RX_BUF_SIZE). Thus, the patch adds a check for
pkt_len which must not exceed 2 * MAX_RX_BUG_SIZE.
BUG: KASAN: slab-out-of-bounds in ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
Read of size 46393 at addr ffff888018798000 by task kworker/0:1/23
CPU: 0 PID: 23 Comm: kworker/0:1 Not tainted 5.6.0 #63
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
Workqueue: events request_firmware_work_func
Call Trace:
<IRQ>
dump_stack+0x76/0xa0
print_address_description.constprop.0+0x16/0x200
? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
__kasan_report.cold+0x37/0x7c
? ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
kasan_report+0xe/0x20
check_memory_region+0x15a/0x1d0
memcpy+0x20/0x50
ath9k_hif_usb_rx_cb+0x490/0xed7 [ath9k_htc]
? hif_usb_mgmt_cb+0x2d9/0x2d9 [ath9k_htc]
? _raw_spin_lock_irqsave+0x7b/0xd0
? _raw_spin_trylock_bh+0x120/0x120
? __usb_unanchor_urb+0x12f/0x210
__usb_hcd_giveback_urb+0x1e4/0x380
usb_giveback_urb_bh+0x241/0x4f0
? __hrtimer_run_queues+0x316/0x740
? __usb_hcd_giveback_urb+0x380/0x380
tasklet_action_common.isra.0+0x135/0x330
__do_softirq+0x18c/0x634
irq_exit+0x114/0x140
smp_apic_timer_interrupt+0xde/0x380
apic_timer_interrupt+0xf/0x20
I found the bug using a custome USBFuzz port. It's a research work
to fuzz USB stack/drivers. I modified it to fuzz ath9k driver only,
providing hand-crafted usb descriptors to QEMU.
After fixing the value of pkt_tag to ATH_USB_RX_STREAM_MODE_TAG in QEMU
emulation, I found the KASAN report. The bug is triggerable whenever
pkt_len is above two MAX_RX_BUG_SIZE. I used the same input that crashes
to test the driver works when applying the patch.
Signed-off-by: Zekun Shen <bruceshenzk@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/YXsidrRuK6zBJicZ@10-18-43-117.dynapool.wireless.nyu.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 00558586382891540c59c9febc671062425a6e47 ]
When a new USB device gets plugged to nested hubs, the affected hub,
which connects to usb 2-1.4-port2, doesn't report there's any change,
hence the nested hubs go back to runtime suspend like nothing happened:
[ 281.032951] usb usb2: usb wakeup-resume
[ 281.032959] usb usb2: usb auto-resume
[ 281.032974] hub 2-0:1.0: hub_resume
[ 281.033011] usb usb2-port1: status 0263 change 0000
[ 281.033077] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.049797] usb 2-1: usb wakeup-resume
[ 281.069800] usb 2-1: Waited 0ms for CONNECT
[ 281.069810] usb 2-1: finish resume
[ 281.070026] hub 2-1:1.0: hub_resume
[ 281.070250] usb 2-1-port4: status 0203 change 0000
[ 281.070272] usb usb2-port1: resume, status 0
[ 281.070282] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000
[ 281.089813] usb 2-1.4: usb wakeup-resume
[ 281.109792] usb 2-1.4: Waited 0ms for CONNECT
[ 281.109801] usb 2-1.4: finish resume
[ 281.109991] hub 2-1.4:1.0: hub_resume
[ 281.110147] usb 2-1.4-port2: status 0263 change 0000
[ 281.110234] usb 2-1-port4: resume, status 0
[ 281.110239] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s
[ 281.110266] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.110426] hub 2-1.4:1.0: hub_suspend
[ 281.110565] usb 2-1.4: usb auto-suspend, wakeup 1
[ 281.130998] hub 2-1:1.0: hub_suspend
[ 281.137788] usb 2-1: usb auto-suspend, wakeup 1
[ 281.142935] hub 2-0:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.177828] usb 2-1: usb wakeup-resume
[ 281.197839] usb 2-1: Waited 0ms for CONNECT
[ 281.197850] usb 2-1: finish resume
[ 281.197984] hub 2-1:1.0: hub_resume
[ 281.198203] usb 2-1-port4: status 0203 change 0000
[ 281.198228] usb usb2-port1: resume, status 0
[ 281.198237] hub 2-1:1.0: state 7 ports 4 chg 0010 evt 0000
[ 281.217835] usb 2-1.4: usb wakeup-resume
[ 281.237834] usb 2-1.4: Waited 0ms for CONNECT
[ 281.237845] usb 2-1.4: finish resume
[ 281.237990] hub 2-1.4:1.0: hub_resume
[ 281.238067] usb 2-1.4-port2: status 0263 change 0000
[ 281.238148] usb 2-1-port4: resume, status 0
[ 281.238152] usb 2-1-port4: status 0203, change 0000, 10.0 Gb/s
[ 281.238166] hub 2-1.4:1.0: state 7 ports 4 chg 0000 evt 0000
[ 281.238385] hub 2-1.4:1.0: hub_suspend
[ 281.238523] usb 2-1.4: usb auto-suspend, wakeup 1
[ 281.258076] hub 2-1:1.0: hub_suspend
[ 281.265744] usb 2-1: usb auto-suspend, wakeup 1
[ 281.285976] hub 2-0:1.0: hub_suspend
[ 281.285988] usb usb2: bus auto-suspend, wakeup 1
USB 3.2 spec, 9.2.5.4 "Changing Function Suspend State" says that "If
the link is in a non-U0 state, then the device must transition the link
to U0 prior to sending the remote wake message", but the hub only
transits the link to U0 after signaling remote wakeup.
So be more forgiving and use a 20ms delay to let the link transit to U0
for remote wakeup.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20211215120108.336597-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 521223d8b3ec078f670c7c35a1a04b1b2af07966 ]
The min and max frequency QoS requests in the cpufreq core are
initialized to whatever the current min and max frequency values are
at the init time, but if any of these values change later (for
example, cpuinfo.max_freq is updated by the driver), these initial
request values will be limiting the CPU frequency unnecessarily
unless they are changed by user space via sysfs.
To address this, initialize min_freq_req and max_freq_req to
FREQ_QOS_MIN_DEFAULT_VALUE and FREQ_QOS_MAX_DEFAULT_VALUE,
respectively, so they don't really limit anything until user
space updates them.
Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d1579e61192e0e686faa4208500ef4c3b529b16c ]
Because refcount_dec_not_one() returns true if the target refcount
becomes saturated, it is generally unsafe to use its return value as
a loop termination condition, but that is what happens when a device
link's supplier device is released during runtime PM suspend
operations and on device link removal.
To address this, introduce pm_runtime_release_supplier() to be used
in the above cases which will check the supplier device's runtime
PM usage counter in addition to the refcount_dec_not_one() return
value, so the loop can be terminated in case the rpm_active refcount
value becomes invalid, and update the code in question to use it as
appropriate.
This change is not expected to have any visible functional impact.
Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8c3e5b74b9e2146f564905e50ca716591c76d4f1 ]
The mmc core takes a specific path to support initializing of a
non-standard SDIO card. This is triggered by looking for the card-quirk,
MMC_QUIRK_NONSTD_SDIO.
In mmc_sdio_init_card() this gets rather messy, as it causes the code to
bail out earlier, compared to the usual path. This leads to that the OCR
doesn't get saved properly in card->ocr. Fortunately, only omap_hsmmc has
been using the MMC_QUIRK_NONSTD_SDIO and is dealing with the issue, by
assigning a hardcoded value (0x80) to card->ocr from an ->init_card() ops.
To make the behaviour consistent, let's instead rely on the core to save
the OCR in card->ocr during initialization.
Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Link: https://lore.kernel.org/r/e7936cff7fc24d187ef2680d3b4edb0ade58f293.1636564631.git.hns@goldelico.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3af86b046933ba513d08399dba0d4d8b50d607d0 ]
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate
a new memory for dev->vv_data. saa7146_vv_release() will be called on
failure of saa7146_register_device(). There is a dereference of
dev->vv_data in saa7146_vv_release(), which could lead to a NULL
pointer dereference on failure of saa7146_vv_init().
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_VIDEO_HEXIUM_GEMINI=m show no new warnings,
and our static analyzer no longer warns about this code.
Link: https://lore.kernel.org/linux-media/20211203154030.111210-1-zhou1615@umn.edu
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8fede658e7ddb605bbd68ed38067ddb0af033db4 ]
Without this, some IR will be missing mid-stream and we might decode
something which never really occurred.
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>
|
|
[ Upstream commit fd8d135b2c5e88662f2729e034913f183455a667 ]
Add a HID_QUIRK_X_INVERT/HID_QUIRK_Y_INVERT quirk that can be used
to invert the X/Y values.
Signed-off-by: Alistair Francis <alistair@alistair23.me>
[bentiss: silence checkpatch warning]
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Link: https://lore.kernel.org/r/20211208124045.61815-2-alistair@alistair23.me
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit fee32de284ac277ba434a2d59f8ce46528ff3946 ]
Currently "bond_should_notify_peers: slave ..." messages are printed whenever
"bond_should_notify_peers" function is called.
+++
Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Received LACPDU on port 1
Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): Rx Machine: Port=1, Last State=6, Curr State=6
Dec 12 12:33:26 node1 kernel: bond0: (slave enp0s25): partner sync=1
Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:26 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
...
Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Received LACPDU on port 2
Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): Rx Machine: Port=2, Last State=6, Curr State=6
Dec 12 12:33:30 node1 kernel: bond0: (slave enp4s3): partner sync=1
Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
Dec 12 12:33:30 node1 kernel: bond0: bond_should_notify_peers: slave enp0s25
+++
This is confusing and can also clutter up debug logs.
Print logs only when the peer notification happens.
Signed-off-by: Suresh Kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 767c94caf0efad136157110787fe221b74cb5c8a ]
With CONFIG_LOCKDEP=y and CONFIG_DEBUG_SPINLOCK=y, lockdep reports
below warning:
[ 166.059415] ============================================
[ 166.059416] WARNING: possible recursive locking detected
[ 166.059418] 5.15.0-wt-ath+ #10 Tainted: G W O
[ 166.059420] --------------------------------------------
[ 166.059421] kworker/0:2/116 is trying to acquire lock:
[ 166.059423] ffff9905f2083160 (&srng->lock){+.-.}-{2:2}, at: ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k]
[ 166.059440]
but task is already holding lock:
[ 166.059442] ffff9905f2083230 (&srng->lock){+.-.}-{2:2}, at: ath11k_dp_process_reo_status+0x95/0x2d0 [ath11k]
[ 166.059491]
other info that might help us debug this:
[ 166.059492] Possible unsafe locking scenario:
[ 166.059493] CPU0
[ 166.059494] ----
[ 166.059495] lock(&srng->lock);
[ 166.059498] lock(&srng->lock);
[ 166.059500]
*** DEADLOCK ***
[ 166.059501] May be due to missing lock nesting notation
[ 166.059502] 3 locks held by kworker/0:2/116:
[ 166.059504] #0: ffff9905c0081548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f6/0x660
[ 166.059511] #1: ffff9d2400a5fe68 ((debug_obj_work).work){+.+.}-{0:0}, at: process_one_work+0x1f6/0x660
[ 166.059517] #2: ffff9905f2083230 (&srng->lock){+.-.}-{2:2}, at: ath11k_dp_process_reo_status+0x95/0x2d0 [ath11k]
[ 166.059532]
stack backtrace:
[ 166.059534] CPU: 0 PID: 116 Comm: kworker/0:2 Kdump: loaded Tainted: G W O 5.15.0-wt-ath+ #10
[ 166.059537] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0059.2019.1112.1124 11/12/2019
[ 166.059539] Workqueue: events free_obj_work
[ 166.059543] Call Trace:
[ 166.059545] <IRQ>
[ 166.059547] dump_stack_lvl+0x56/0x7b
[ 166.059552] __lock_acquire+0xb9a/0x1a50
[ 166.059556] lock_acquire+0x1e2/0x330
[ 166.059560] ? ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k]
[ 166.059571] _raw_spin_lock_bh+0x33/0x70
[ 166.059574] ? ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k]
[ 166.059584] ath11k_hal_reo_cmd_send+0x20/0x490 [ath11k]
[ 166.059594] ath11k_dp_tx_send_reo_cmd+0x3f/0x130 [ath11k]
[ 166.059605] ath11k_dp_rx_tid_del_func+0x221/0x370 [ath11k]
[ 166.059618] ath11k_dp_process_reo_status+0x22f/0x2d0 [ath11k]
[ 166.059632] ? ath11k_dp_service_srng+0x2ea/0x2f0 [ath11k]
[ 166.059643] ath11k_dp_service_srng+0x2ea/0x2f0 [ath11k]
[ 166.059655] ath11k_pci_ext_grp_napi_poll+0x1c/0x70 [ath11k_pci]
[ 166.059659] __napi_poll+0x28/0x230
[ 166.059664] net_rx_action+0x285/0x310
[ 166.059668] __do_softirq+0xe6/0x4d2
[ 166.059672] irq_exit_rcu+0xd2/0xf0
[ 166.059675] common_interrupt+0xa5/0xc0
[ 166.059678] </IRQ>
[ 166.059679] <TASK>
[ 166.059680] asm_common_interrupt+0x1e/0x40
[ 166.059683] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70
[ 166.059686] Code: 83 c7 18 e8 2a 95 43 ff 48 89 ef e8 22 d2 43 ff 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 63 2e 40 ff 65 8b 05 8c 59 97 5c 85 c0 74 0a 5b 5d c3 e8 00 6a
[ 166.059689] RSP: 0018:ffff9d2400a5fca0 EFLAGS: 00000206
[ 166.059692] RAX: 0000000000000002 RBX: 0000000000000200 RCX: 0000000000000006
[ 166.059694] RDX: 0000000000000000 RSI: ffffffffa404879b RDI: 0000000000000001
[ 166.059696] RBP: ffff9905c0053000 R08: 0000000000000001 R09: 0000000000000001
[ 166.059698] R10: ffff9d2400a5fc50 R11: 0000000000000001 R12: ffffe186c41e2840
[ 166.059700] R13: 0000000000000001 R14: ffff9905c78a1c68 R15: 0000000000000001
[ 166.059704] free_debug_processing+0x257/0x3d0
[ 166.059708] ? free_obj_work+0x1f5/0x250
[ 166.059712] __slab_free+0x374/0x5a0
[ 166.059718] ? kmem_cache_free+0x2e1/0x370
[ 166.059721] ? free_obj_work+0x1f5/0x250
[ 166.059724] kmem_cache_free+0x2e1/0x370
[ 166.059727] free_obj_work+0x1f5/0x250
[ 166.059731] process_one_work+0x28b/0x660
[ 166.059735] ? process_one_work+0x660/0x660
[ 166.059738] worker_thread+0x37/0x390
[ 166.059741] ? process_one_work+0x660/0x660
[ 166.059743] kthread+0x176/0x1a0
[ 166.059746] ? set_kthread_struct+0x40/0x40
[ 166.059749] ret_from_fork+0x22/0x30
[ 166.059754] </TASK>
Since these two lockes are both initialized in ath11k_hal_srng_setup,
they are assigned with the same key. As a result lockdep suspects that
the task is trying to acquire the same lock (due to same key) while
already holding it, and thus reports the DEADLOCK warning. However as
they are different spinlock instances, the warning is false positive.
On the other hand, even no dead lock indeed, this is a major issue for
upstream regression testing as it disables lockdep functionality.
Fix it by assigning separate lock class key for each srng->lock.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211209011949.151472-1-quic_bqiang@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 61a7904b6ace99b1bde0d0e867fa3097f5c8cee2 ]
The gpio-aspeed driver implements an irq_chip which need to be invoked
from hardirq context. Since spin_lock() can sleep with PREEMPT_RT, it is
no longer legal to invoke it while interrupts are disabled.
This also causes lockdep to complain about:
[ 0.649797] [ BUG: Invalid wait context ]
because aspeed_gpio.lock (spin_lock_t) is taken under irq_desc.lock
(raw_spinlock_t).
Let's use of raw_spinlock_t instead of spinlock_t.
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f20f94f7f52c4685c81754f489ffcc72186e8bdb ]
The PHY settings table is supposed to be sorted by descending match
priority - in other words, earlier entries are preferred over later
entries.
The order of 1000baseKX/Full and 1000baseT/Full is such that we
prefer 1000baseKX/Full over 1000baseT/Full, but 1000baseKX/Full is
a lot rarer than 1000baseT/Full, and thus is much less likely to
be preferred.
This causes phylink problems - it means a fixed link specifying a
speed of 1G and full duplex gets an ethtool linkmode of 1000baseKX/Full
rather than 1000baseT/Full as would be expected - and since we offer
userspace a software emulation of a conventional copper PHY, we want
to offer copper modes in preference to anything else. However, we do
still want to allow the rarer modes as well.
Hence, let's reorder these two modes to prefer copper.
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/E1muvFO-00F6jY-1K@rmk-PC.armlinux.org.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e8a91863eba3966a447d2daa1526082d52b5db2a ]
While running stress tests in roaming scenarios (switching ap's every 5
seconds, we discovered a issue which leads to tx hangings of exactly 5
seconds while or after scanning for new accesspoints. We found out that
this hanging is triggered by ath10k_mac_wait_tx_complete since the
empty_tx_wq was not wake when the num_tx_pending counter reaches zero.
To fix this, we simply move the wake_up call to htt_tx_dec_pending,
since this call was missed on several locations within the ath10k code.
Signed-off-by: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20210505085806.11474-1-s.gottschall@dd-wrt.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ed05c7cf1286d7e31e7623bce55ff135723591bf ]
When enable debug config, it print below warning while shut down wlan
interface shuh as run "ifconfig wlan0 down".
The reason is because ar->regd_update_work is ran once, and it is will
call wiphy_lock(ar->hw->wiphy) in function ath11k_regd_update() which
is running in workqueue of ieee80211_local queued by ieee80211_queue_work().
Another thread from "ifconfig wlan0 down" will also accuqire the lock
by wiphy_lock(sdata->local->hw.wiphy) in function ieee80211_stop(), and
then it call ieee80211_stop_device() to flush_workqueue(local->workqueue),
this will wait the workqueue of ieee80211_local finished. Then deadlock
will happen easily if the two thread run meanwhile.
Below warning disappeared after this change.
[ 914.088798] ath11k_pci 0000:05:00.0: mac remove interface (vdev 0)
[ 914.088806] ath11k_pci 0000:05:00.0: mac stop 11d scan
[ 914.088810] ath11k_pci 0000:05:00.0: mac stop 11d vdev id 0
[ 914.088827] ath11k_pci 0000:05:00.0: htc ep 2 consumed 1 credits (total 0)
[ 914.088841] ath11k_pci 0000:05:00.0: send 11d scan stop vdev id 0
[ 914.088849] ath11k_pci 0000:05:00.0: htc insufficient credits ep 2 required 1 available 0
[ 914.088856] ath11k_pci 0000:05:00.0: htc insufficient credits ep 2 required 1 available 0
[ 914.096434] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 16
[ 914.096442] ath11k_pci 0000:05:00.0: htc ep 2 got 1 credits (total 1)
[ 914.096481] ath11k_pci 0000:05:00.0: htc ep 2 consumed 1 credits (total 0)
[ 914.096491] ath11k_pci 0000:05:00.0: WMI vdev delete id 0
[ 914.111598] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 16
[ 914.111628] ath11k_pci 0000:05:00.0: htc ep 2 got 1 credits (total 1)
[ 914.114659] ath11k_pci 0000:05:00.0: rx ce pipe 2 len 20
[ 914.114742] ath11k_pci 0000:05:00.0: htc rx completion ep 2 skb pK-error
[ 914.115977] ath11k_pci 0000:05:00.0: vdev delete resp for vdev id 0
[ 914.116685] ath11k_pci 0000:05:00.0: vdev 00:03:7f:29:61:11 deleted, vdev_id 0
[ 914.117583] ======================================================
[ 914.117592] WARNING: possible circular locking dependency detected
[ 914.117600] 5.16.0-rc1-wt-ath+ #1 Tainted: G OE
[ 914.117611] ------------------------------------------------------
[ 914.117618] ifconfig/2805 is trying to acquire lock:
[ 914.117628] ffff9c00a62bb548 ((wq_completion)phy0){+.+.}-{0:0}, at: flush_workqueue+0x87/0x470
[ 914.117674]
but task is already holding lock:
[ 914.117682] ffff9c00baea07d0 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_stop+0x38/0x180 [mac80211]
[ 914.117872]
which lock already depends on the new lock.
[ 914.117880]
the existing dependency chain (in reverse order) is:
[ 914.117888]
-> #3 (&rdev->wiphy.mtx){+.+.}-{4:4}:
[ 914.117910] __mutex_lock+0xa0/0x9c0
[ 914.117930] mutex_lock_nested+0x1b/0x20
[ 914.117944] reg_process_self_managed_hints+0x3a/0xb0 [cfg80211]
[ 914.118093] wiphy_regulatory_register+0x47/0x80 [cfg80211]
[ 914.118229] wiphy_register+0x84f/0x9c0 [cfg80211]
[ 914.118353] ieee80211_register_hw+0x6b1/0xd90 [mac80211]
[ 914.118486] ath11k_mac_register+0x6af/0xb60 [ath11k]
[ 914.118550] ath11k_core_qmi_firmware_ready+0x383/0x4a0 [ath11k]
[ 914.118598] ath11k_qmi_driver_event_work+0x347/0x4a0 [ath11k]
[ 914.118656] process_one_work+0x228/0x670
[ 914.118669] worker_thread+0x4d/0x440
[ 914.118680] kthread+0x16d/0x1b0
[ 914.118697] ret_from_fork+0x22/0x30
[ 914.118714]
-> #2 (rtnl_mutex){+.+.}-{4:4}:
[ 914.118736] __mutex_lock+0xa0/0x9c0
[ 914.118751] mutex_lock_nested+0x1b/0x20
[ 914.118767] rtnl_lock+0x17/0x20
[ 914.118783] ath11k_regd_update+0x15a/0x260 [ath11k]
[ 914.118841] ath11k_regd_update_work+0x15/0x20 [ath11k]
[ 914.118897] process_one_work+0x228/0x670
[ 914.118909] worker_thread+0x4d/0x440
[ 914.118920] kthread+0x16d/0x1b0
[ 914.118934] ret_from_fork+0x22/0x30
[ 914.118948]
-> #1 ((work_completion)(&ar->regd_update_work)){+.+.}-{0:0}:
[ 914.118972] process_one_work+0x1fa/0x670
[ 914.118984] worker_thread+0x4d/0x440
[ 914.118996] kthread+0x16d/0x1b0
[ 914.119010] ret_from_fork+0x22/0x30
[ 914.119023]
-> #0 ((wq_completion)phy0){+.+.}-{0:0}:
[ 914.119045] __lock_acquire+0x146d/0x1cf0
[ 914.119057] lock_acquire+0x19b/0x360
[ 914.119067] flush_workqueue+0xae/0x470
[ 914.119084] ieee80211_stop_device+0x3b/0x50 [mac80211]
[ 914.119260] ieee80211_do_stop+0x5d7/0x830 [mac80211]
[ 914.119409] ieee80211_stop+0x45/0x180 [mac80211]
[ 914.119557] __dev_close_many+0xb3/0x120
[ 914.119573] __dev_change_flags+0xc3/0x1d0
[ 914.119590] dev_change_flags+0x29/0x70
[ 914.119605] devinet_ioctl+0x653/0x810
[ 914.119620] inet_ioctl+0x193/0x1e0
[ 914.119631] sock_do_ioctl+0x4d/0xf0
[ 914.119649] sock_ioctl+0x262/0x340
[ 914.119665] __x64_sys_ioctl+0x96/0xd0
[ 914.119678] do_syscall_64+0x3d/0xd0
[ 914.119694] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 914.119709]
other info that might help us debug this:
[ 914.119717] Chain exists of:
(wq_completion)phy0 --> rtnl_mutex --> &rdev->wiphy.mtx
[ 914.119745] Possible unsafe locking scenario:
[ 914.119752] CPU0 CPU1
[ 914.119758] ---- ----
[ 914.119765] lock(&rdev->wiphy.mtx);
[ 914.119778] lock(rtnl_mutex);
[ 914.119792] lock(&rdev->wiphy.mtx);
[ 914.119807] lock((wq_completion)phy0);
[ 914.119819]
*** DEADLOCK ***
[ 914.119827] 2 locks held by ifconfig/2805:
[ 914.119837] #0: ffffffffba3dc010 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock+0x17/0x20
[ 914.119872] #1: ffff9c00baea07d0 (&rdev->wiphy.mtx){+.+.}-{4:4}, at: ieee80211_stop+0x38/0x180 [mac80211]
[ 914.120039]
stack backtrace:
[ 914.120048] CPU: 0 PID: 2805 Comm: ifconfig Tainted: G OE 5.16.0-rc1-wt-ath+ #1
[ 914.120064] Hardware name: LENOVO 418065C/418065C, BIOS 83ET63WW (1.33 ) 07/29/2011
[ 914.120074] Call Trace:
[ 914.120084] <TASK>
[ 914.120094] dump_stack_lvl+0x73/0xa4
[ 914.120119] dump_stack+0x10/0x12
[ 914.120135] print_circular_bug.isra.44+0x221/0x2e0
[ 914.120165] check_noncircular+0x106/0x150
[ 914.120203] __lock_acquire+0x146d/0x1cf0
[ 914.120215] ? __lock_acquire+0x146d/0x1cf0
[ 914.120245] lock_acquire+0x19b/0x360
[ 914.120259] ? flush_workqueue+0x87/0x470
[ 914.120286] ? lockdep_init_map_type+0x6b/0x250
[ 914.120310] flush_workqueue+0xae/0x470
[ 914.120327] ? flush_workqueue+0x87/0x470
[ 914.120344] ? lockdep_hardirqs_on+0xd7/0x150
[ 914.120391] ieee80211_stop_device+0x3b/0x50 [mac80211]
[ 914.120565] ? ieee80211_stop_device+0x3b/0x50 [mac80211]
[ 914.120736] ieee80211_do_stop+0x5d7/0x830 [mac80211]
[ 914.120906] ieee80211_stop+0x45/0x180 [mac80211]
[ 914.121060] __dev_close_many+0xb3/0x120
[ 914.121081] __dev_change_flags+0xc3/0x1d0
[ 914.121109] dev_change_flags+0x29/0x70
[ 914.121131] devinet_ioctl+0x653/0x810
[ 914.121149] ? __might_fault+0x77/0x80
[ 914.121179] inet_ioctl+0x193/0x1e0
[ 914.121194] ? inet_ioctl+0x193/0x1e0
[ 914.121218] ? __might_fault+0x77/0x80
[ 914.121238] ? _copy_to_user+0x68/0x80
[ 914.121266] sock_do_ioctl+0x4d/0xf0
[ 914.121283] ? inet_stream_connect+0x60/0x60
[ 914.121297] ? sock_do_ioctl+0x4d/0xf0
[ 914.121329] sock_ioctl+0x262/0x340
[ 914.121347] ? sock_ioctl+0x262/0x340
[ 914.121362] ? exit_to_user_mode_prepare+0x13b/0x280
[ 914.121388] ? syscall_enter_from_user_mode+0x20/0x50
[ 914.121416] __x64_sys_ioctl+0x96/0xd0
[ 914.121430] ? br_ioctl_call+0x90/0x90
[ 914.121445] ? __x64_sys_ioctl+0x96/0xd0
[ 914.121465] do_syscall_64+0x3d/0xd0
[ 914.121482] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 914.121497] RIP: 0033:0x7f0ed051737b
[ 914.121513] Code: 0f 1e fa 48 8b 05 15 3b 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e5 3a 0d 00 f7 d8 64 89 01 48
[ 914.121527] RSP: 002b:00007fff7be38b98 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[ 914.121544] RAX: ffffffffffffffda RBX: 00007fff7be38ba0 RCX: 00007f0ed051737b
[ 914.121555] RDX: 00007fff7be38ba0 RSI: 0000000000008914 RDI: 0000000000000004
[ 914.121566] RBP: 00007fff7be38c60 R08: 000000000000000a R09: 0000000000000001
[ 914.121576] R10: 0000000000000000 R11: 0000000000000202 R12: 00000000fffffffe
[ 914.121586] R13: 0000000000000004 R14: 0000000000000000 R15: 0000000000000000
[ 914.121620] </TASK>
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20211201071745.17746-2-quic_wgong@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8e967c137df3b236d2075f9538cb888129425d1a ]
When scheduling a session protection the id is saved but
then it may be cleared when calling iwl_mvm_te_clear_data
(if a previous session protection is currently active).
Fix it by saving the id after calling iwl_mvm_te_clear_data.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204130722.b0743a588d14.I098fef6677d0dab3ef1b6183ed206a10bab01eb2@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit db66abeea3aefed481391ecc564fb7b7fb31d742 ]
If userspace installs a lot of multicast groups very quickly, then
we may run out of command queue space as we send the updates in an
asynchronous fashion (due to locking concerns), and the CPU can
create them faster than the firmware can process them. This is true
even when mac80211 has a work struct that gets scheduled.
Fix this by synchronizing with the firmware after sending all those
commands - outside of the iteration we can send a synchronous echo
command that just has the effect of the CPU waiting for the prior
asynchronous commands to finish. This also will cause fewer of the
commands to be sent to the firmware overall, because the work will
only run once when rescheduled multiple times while it's running.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=213649
Suggested-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reported-by: Maximilian Ernestus <maximilian@ernestus.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20211204083238.51aea5b79ea4.I88a44798efda16e9fe480fb3e94224931d311b29@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f3380cac0c0b3a6f49ab161e2a057c363962f48d ]
If protocol tunnels are already up when the driver is loaded, for
instance if the boot firmware implements connection manager of its own,
runtime PM reference count of the consumer devices behind the tunnel
might have been increased already before the device link is created but
the supplier device runtime PM reference count is not. This leads to a
situation where the supplier (the Thunderbolt driver) can runtime
suspend even if it should not because the corresponding protocol tunnel
needs to be up causing the devices to be removed from the corresponding
native bus.
Prevent this from happening by making both sides of the link runtime PM
active briefly. The pm_runtime_put() for the consumer (PCIe
root/downstream port, xHCI) then allows it to runtime suspend again but
keeps the supplier runtime resumed the whole time it is runtime active.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a2ab06d7c4d6bfd0b545a768247a70463e977e27 ]
Using stack-allocated pointers for USB message data don't work.
This driver is almost OK with that, except for the I2C read
logic.
Fix it by using a temporary read buffer, just like on all other
calls to m920x_read().
Link: https://lore.kernel.org/all/ccc99e48-de4f-045e-0fe4-61e3118e3f74@mida.se/
Reported-by: rkardell@mida.se
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 348df8035301dd212e3cc2860efe4c86cb0d3303 ]
In hexium_attach(dev, info), saa7146_vv_init() is called to allocate
a new memory for dev->vv_data. In hexium_detach(), saa7146_vv_release()
will be called and there is a dereference of dev->vv_data in
saa7146_vv_release(), which could lead to a NULL pointer dereference
on failure of saa7146_vv_init() according to the following logic.
Both hexium_attach() and hexium_detach() are callback functions of
the variable 'extension', so there exists a possible call chain directly
from hexium_attach() to hexium_detach():
hexium_attach(dev, info) -- fail to alloc memory to dev->vv_data
| in saa7146_vv_init().
|
|
hexium_detach() -- a dereference of dev->vv_data in saa7146_vv_release()
Fix this bug by adding a check of saa7146_vv_init().
This bug was found by a static analyzer. The analysis employs
differential checking to identify inconsistent security operations
(e.g., checks or kfrees) between two code paths and confirms that the
inconsistent operations are not recovered in the current function or
the callers, so they constitute bugs.
Note that, as a bug found by static analysis, it can be a false
positive or hard to trigger. Multiple researchers have cross-reviewed
the bug.
Builds with CONFIG_VIDEO_HEXIUM_ORION=m show no new warnings,
and our static analyzer no longer warns about this code.
Signed-off-by: Zhou Qingyang <zhou1615@umn.edu>
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>
|
|
[ Upstream commit da6911f330d40cfe115a37249e47643eff555e82 ]
This change fixes two issues with the size constraints for buffers.
- There is no width alignment constraint for RGB formats. Prior to this
change they were treated as YUV and as a result were more restricted
than needed. Add a new check to differentiate between the two.
- The minimum width and height supported is 5x2, not 2x4, this is an
artifact from the driver's soc-camera days. Fix this incorrect
assumption.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
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>
|
|
[ Upstream commit c8ed7d2f614cd8b315981d116c7a2fb01829500d ]
Some uvc devices appear to require the maximum allowed USB timeout
for GET_CUR/SET_CUR requests.
So lets just bump the UVC control timeout to 5 seconds which is the
same as the usb ctrl get/set defaults:
USB_CTRL_GET_TIMEOUT 5000
USB_CTRL_SET_TIMEOUT 5000
It fixes the following runtime warnings:
Failed to query (GET_CUR) UVC control 11 on unit 2: -110 (exp. 1).
Failed to query (SET_CUR) UVC control 3 on unit 2: -110 (exp. 2).
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit f0ce591dc9a97067c6e783a2eaccd22c5476144d ]
When the CMM is enabled, an offset of 25 pixels must be subtracted from
the HDS (horizontal display start) and HDE (horizontal display end)
registers. Fix the timings calculation, and take this into account in
the mode validation.
This fixes a visible horizontal offset in the image with VGA monitors.
HDMI monitors seem to be generally more tolerant to incorrect timings,
but may be affected too.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 545a32498c536ee152331cd2e7d2416aa0f20e01 ]
We need to check the max request size that is from user space before
allocating pages. If the request size exceeds the limit, return -EINVAL.
This check can avoid the warning below from page allocator.
WARNING: CPU: 3 PID: 16525 at mm/page_alloc.c:5344 current_gfp_context include/linux/sched/mm.h:195 [inline]
WARNING: CPU: 3 PID: 16525 at mm/page_alloc.c:5344 __alloc_pages+0x45d/0x500 mm/page_alloc.c:5356
Modules linked in:
CPU: 3 PID: 16525 Comm: syz-executor.3 Not tainted 5.15.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
RIP: 0010:__alloc_pages+0x45d/0x500 mm/page_alloc.c:5344
Code: be c9 00 00 00 48 c7 c7 20 4a 97 89 c6 05 62 32 a7 0b 01 e8 74 9a 42 07 e9 6a ff ff ff 0f 0b e9 a0 fd ff ff 40 80 e5 3f eb 88 <0f> 0b e9 18 ff ff ff 4c 89 ef 44 89 e6 45 31 ed e8 1e 76 ff ff e9
RSP: 0018:ffffc90023b87850 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 1ffff92004770f0b RCX: dffffc0000000000
RDX: 0000000000000000 RSI: 0000000000000033 RDI: 0000000000010cc1
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001
R10: ffffffff81bb4686 R11: 0000000000000001 R12: ffffffff902c1960
R13: 0000000000000033 R14: 0000000000000000 R15: ffff88804cf64a30
FS: 0000000000000000(0000) GS:ffff88802cd00000(0063) knlGS:00000000f44b4b40
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 000000002c921000 CR3: 000000004f507000 CR4: 0000000000150ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
alloc_pages+0x1a7/0x300 mm/mempolicy.c:2191
__get_free_pages+0x8/0x40 mm/page_alloc.c:5418
raw_cmd_copyin drivers/block/floppy.c:3113 [inline]
raw_cmd_ioctl drivers/block/floppy.c:3160 [inline]
fd_locked_ioctl+0x12e5/0x2820 drivers/block/floppy.c:3528
fd_ioctl drivers/block/floppy.c:3555 [inline]
fd_compat_ioctl+0x891/0x1b60 drivers/block/floppy.c:3869
compat_blkdev_ioctl+0x3b8/0x810 block/ioctl.c:662
__do_compat_sys_ioctl+0x1c7/0x290 fs/ioctl.c:972
do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
__do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178
do_fast_syscall_32+0x2f/0x70 arch/x86/entry/common.c:203
entry_SYSENTER_compat_after_hwframe+0x4d/0x5c
Reported-by: syzbot+23a02c7df2cf2bc93fa2@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20211116131033.27685-1-sxwjean@me.com
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 554abfe2eadec97d12c71d4a69da1518478f69eb ]
Enable ast2600 uhci quirks.
Signed-off-by: Neal Liu <neal_liu@aspeedtech.com>
Link: https://lore.kernel.org/r/20211126100021.2331024-1-neal_liu@aspeedtech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 57d2dbf710d832841872fb15ebb79429cab90fae ]
The GPD win and its sibling the GPD pocket (99% the same electronics in a
different case) use a PCI wifi card. But the ACPI tables on both variants
contain a bug where the SDIO MMC controller for SDIO wifi cards is enabled
despite this. This SDIO MMC controller has a PCI0.SDHB.BRC1 child-device
which _PS3 method sets a GPIO causing the PCI wifi card to turn off.
At the moment there is a pretty ugly kludge in the sdhci-acpi.c code,
just to work around the bug in the DSDT of this single design. This can
be solved cleaner/simply with a quirk overriding the _STA return of the
broken PCI0.SDHB.BRC1 PCI0.SDHB.BRC1 child with a status value of 0,
so that its power_manageable flag gets cleared, avoiding this problem.
Note that even though it is not used, the _STA method for the MMC
controller is deliberately not overridden. If the status of the MMC
controller were forced to 0 it would never get suspended, which would
cause these mini-laptops to not reach S0i3 level when suspended.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ba46e42e925b5d09b4e441f8de3db119cc7df58f ]
Not all ACPI-devices have a HID + UID, allow specifying quirks for
acpi_device_override_status() by path too.
Note this moves the path/HID+UID check to after the CPU + DMI checks
since the path lookup is somewhat costly.
This way this lookup is only done on devices where the other checks
match.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1a68b346a2c9969c05e80a3b99a9ab160b5655c0 ]
Currently, acpi_bus_get_status() calls acpi_device_always_present() to
allow platform quirks to override the _STA return to report that a
device is present (status = ACPI_STA_DEFAULT) independent of the _STA
return.
In some cases it might also be useful to have the opposite functionality
and have a platform quirk which marks a device as not present (status = 0)
to work around ACPI table bugs.
Change acpi_device_always_present() into a more generic
acpi_device_override_status() function to allow this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit d431dfb764b145369be820fcdfd50f2159b9bbc2 ]
It turns out that there is a WMI object which controls the PWM2 device
used for the keyboard backlight and that WMI object also provides some
other useful functionality.
The upcoming lenovo-yogabook-wmi driver will offer both backlight
control and the other functionality, so there no longer is a need
to have the lpss-pwm driver binding to PWM2 for backlight control;
and this is now actually undesirable because this will cause both
the WMI code and the lpss-pwm driver to poke at the same PWM
controller.
Drop the always-present quirk for the PWM2 ACPI-device, so that the
lpss-pwm controller will no longer bind to it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
concurrent video sessions
[ Upstream commit 91f2b7d269e5c885c38c7ffa261f5276bd42f907 ]
In existing implementation, core_clk_setrate() is getting called
concurrently in concurrent video sessions. Before the previous call to
core_clk_setrate returns, new call to core_clk_setrate is invoked from
another video session running concurrently. This results in latest
calculated frequency being set (higher/lower) instead of actual frequency
required for that video session. It also results in stability crashes
mention below. These resources are specific to video core, hence keeping
under core lock would ensure that they are estimated for all running video
sessions and called once for the video core.
Crash logs:
[ 1.900089] WARNING: CPU: 4 PID: 1 at drivers/opp/debugfs.c:33 opp_debug_remove_one+0x2c/0x48
[ 1.908493] Modules linked in:
[ 1.911524] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 5.10.67 #35 f8edb8c30cf2dd |
