- 27 May, 2020 40 commits
-
-
Russell Currey authored
[ Upstream commit c55d7b5e ] I have tested this with the Radix MMU and everything seems to work, and the previous patch for Hash seems to fix everything too. STRICT_KERNEL_RWX should still be disabled by default for now. Please test STRICT_KERNEL_RWX + RELOCATABLE! Signed-off-by:
Russell Currey <ruscur@russell.cc> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20191224064126.183670-2-ruscur@russell.ccSigned-off-by:
Sasha Levin <sashal@kernel.org>
-
Colin Xu authored
commit f965b681 upstream. Init value of some display vregs rea inherited from host pregs. When host display in different status, i.e. all monitors unpluged, different display configurations, etc., GVT virtual display setup don't consistent thus may lead to guest driver consider display goes malfunctional. The added init vreg values are based on PRMs and fixed by calcuation from current configuration (only PIPE_A) and the virtual EDID. Fixes: 04d348ae ("drm/i915/gvt: vGPU display virtualization") Acked-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Colin Xu <colin.xu@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Cristian Ciocaltea authored
commit f8f482de upstream. When the kernel is built with lockdep support and the owl-dma driver is used, the following message is shown: [ 2.496939] INFO: trying to register non-static key. [ 2.501889] the code is fine but needs lockdep annotation. [ 2.507357] turning off the locking correctness validator. [ 2.512834] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.3+ #15 [ 2.519084] Hardware name: Generic DT based system [ 2.523878] Workqueue: events_freezable mmc_rescan [ 2.528681] [<801127f0>] (unwind_backtrace) from [<8010da58>] (show_stack+0x10/0x14) [ 2.536420] [<8010da58>] (show_stack) from [<8080fbe8>] (dump_stack+0xb4/0xe0) [ 2.543645] [<8080fbe8>] (dump_stack) from [<8017efa4>] (register_lock_class+0x6f0/0x718) [ 2.551816] [<8017efa4>] (register_lock_class) from [<8017b7d0>] (__lock_acquire+0x78/0x25f0) [ 2.560330] [<8017b7d0>] (__lock_acquire) from [<8017e5e4>] (lock_acquire+0xd8/0x1f4) [ 2.568159] [<8017e5e4>] (lock_acquire) from [<80831fb0>] (_raw_spin_lock_irqsave+0x3c/0x50) [ 2.576589] [<80831fb0>] (_raw_spin_lock_irqsave) from [<8051b5fc>] (owl_dma_issue_pending+0xbc/0x120) [ 2.585884] [<8051b5fc>] (owl_dma_issue_pending) from [<80668cbc>] (owl_mmc_request+0x1b0/0x390) [ 2.594655] [<80668cbc>] (owl_mmc_request) from [<80650ce0>] (mmc_start_request+0x94/0xbc) [ 2.602906] [<80650ce0>] (mmc_start_request) from [<80650ec0>] (mmc_wait_for_req+0x64/0xd0) [ 2.611245] [<80650ec0>] (mmc_wait_for_req) from [<8065aa10>] (mmc_app_send_scr+0x10c/0x144) [ 2.619669] [<8065aa10>] (mmc_app_send_scr) from [<80659b3c>] (mmc_sd_setup_card+0x4c/0x318) [ 2.628092] [<80659b3c>] (mmc_sd_setup_card) from [<80659f0c>] (mmc_sd_init_card+0x104/0x430) [ 2.636601] [<80659f0c>] (mmc_sd_init_card) from [<8065a3e0>] (mmc_attach_sd+0xcc/0x16c) [ 2.644678] [<8065a3e0>] (mmc_attach_sd) from [<8065301c>] (mmc_rescan+0x3ac/0x40c) [ 2.652332] [<8065301c>] (mmc_rescan) from [<80143244>] (process_one_work+0x2d8/0x780) [ 2.660239] [<80143244>] (process_one_work) from [<80143730>] (worker_thread+0x44/0x598) [ 2.668323] [<80143730>] (worker_thread) from [<8014b5f8>] (kthread+0x148/0x150) [ 2.675708] [<8014b5f8>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20) [ 2.682912] Exception stack(0xee8fdfb0 to 0xee8fdff8) [ 2.687954] dfa0: 00000000 00000000 00000000 00000000 [ 2.696118] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.704277] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 The obvious fix would be to use 'spin_lock_init()' on 'pchan->lock' before attempting to call 'spin_lock_irqsave()' in 'owl_dma_get_pchan()'. However, according to Manivannan Sadhasivam, 'pchan->lock' was supposed to only protect 'pchan->vchan' while 'od->lock' does a similar job in 'owl_dma_terminate_pchan()'. Therefore, this patch substitutes 'pchan->lock' with 'od->lock' and removes the 'lock' attribute in 'owl_dma_pchan' struct. Fixes: 47e20577 ("dmaengine: Add Actions Semi Owl family S900 DMA driver") Signed-off-by:
Cristian Ciocaltea <cristian.ciocaltea@gmail.com> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Acked-by:
Andreas Färber <afaerber@suse.de> Link: https://lore.kernel.org/r/c6e6cdaca252b5364bd294093673951036488cf0.1588439073.git.cristian.ciocaltea@gmail.comSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Christophe JAILLET authored
commit 3a5fd0db upstream. Commit b53611fb ("dmaengine: tegra210-adma: Fix crash during probe") has moved some code in the probe function and reordered the error handling path accordingly. However, a goto has been missed. Fix it and goto the right label if 'dma_async_device_register()' fails, so that all resources are released. Fixes: b53611fb ("dmaengine: tegra210-adma: Fix crash during probe") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Jon Hunter <jonathanh@nvidia.com> Acked-by:
Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20200516214205.276266-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
Xiyu Yang authored
commit c6b39f07 upstream. policy_update() invokes begin_current_label_crit_section(), which returns a reference of the updated aa_label object to "label" with increased refcount. When policy_update() returns, "label" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of policy_update(). When aa_may_manage_policy() returns not NULL, the refcnt increased by begin_current_label_crit_section() is not decreased, causing a refcnt leak. Fix this issue by jumping to "end_section" label when aa_may_manage_policy() returns not NULL. Fixes: 5ac8c355 ("apparmor: allow introspecting the loaded policy pre internal transform") Signed-off-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by:
Xin Tan <tanxin.ctf@gmail.com> Signed-off-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Xiyu Yang authored
commit a0b845ff upstream. aa_change_profile() invokes aa_get_current_label(), which returns a reference of the current task's label. According to the comment of aa_get_current_label(), the returned reference must be put with aa_put_label(). However, when the original object pointed by "label" becomes unreachable because aa_change_profile() returns or a new object is assigned to "label", reference count increased by aa_get_current_label() is not decreased, causing a refcnt leak. Fix this by calling aa_put_label() before aa_change_profile() return and dropping unnecessary aa_get_current_label(). Fixes: 9fcf78cc ("apparmor: update domain transitions that are subsets of confinement at nnp") Signed-off-by:
-
Navid Emamdoost authored
commit c54d481d upstream. In the implementation of aa_audit_rule_init(), when aa_label_parse() fails the allocated memory for rule is released using aa_audit_rule_free(). But after this release, the return statement tries to access the label field of the rule which results in use-after-free. Before releasing the rule, copy errNo and return it after release. Fixes: 52e8c380 ("apparmor: Fix memory leak of rule on error exit path") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
-
Christian Gmeiner authored
commit 40b697e2 upstream. The GC860 has one GPU device which has a 2d and 3d core. In this case we want to expose perfmon information for both cores. The driver has one array which contains all possible perfmon domains with some meta data - doms_meta. Here we can see that for the GC860 two elements of that array are relevant: doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain The userspace driver wants to get a list of all perfmon domains and their perfmon signals. This is done by iterating over all domains and their signals. If the userspace driver wants to access the domain with id 8 the kernel driver fails and returns invalid data from doms_3d with and invalid offset. This results in: Unable to handle kernel paging request at virtual address 00000000 On such a device it is not possible to use the userspace driver at all. The fix for this off-by-one error is quite simple. Reported-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
PeiSen Hou authored
commit 259eb824 upstream. A few known Clevo machines (PC50, PC70, X170) with ALC1220 codec need the existing quirk for pins for PB51 and co. Signed-off-by:
PeiSen Hou <pshou@realtek.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200519065012.13119-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Christian Lachner authored
commit d9e8fe0c upstream. The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. Set up a quirk entry for that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275Signed-off-by:
Christian Lachner <gladiac@gmail.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200518053844.42743-2-gladiac@gmail.comSigned-off-by:
-
Brent Lu authored
commit e7513c57 upstream. There is a corner case that ALSA keeps increasing the hw_ptr but DMA already stop working/updating the position for a long time. In following log we can see the position returned from DMA driver does not move at all but the hw_ptr got increased at some point of time so snd_pcm_avail() will return a large number which seems to be a buffer underrun event from user space program point of view. The program thinks there is space in the buffer and fill more data. [ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 [ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554 ... [ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362 [ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 [ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368 This is because the hw_base will be increased by runtime->buffer_size frames unconditionally if the hw_ptr is not updated for over half of buffer time. As the hw_base increases, so does the hw_ptr increased by the same number. The avail value returned from snd_pcm_avail() could exceed the limit (buffer_size) easily becase the hw_ptr itself got increased by same buffer_size samples when the corner case happens. In following log, the buffer_size is 16368 samples but the avail is 21810 samples so CRAS server complains about it. [ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442 [ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810 cras_server[1907]: pcm_avail returned frames larger than buf_size: sof-glkda7219max: :0,5: 21810 > 16368 By updating runtime->hw_ptr_jiffies each time the HWSYNC is called, the hw_base will keep the same when buffer stall happens at long as the interval between each HWSYNC call is shorter than half of buffer time. Following is a log captured by a patched kernel. The hw_base/hw_ptr value is fixed in this corner case and user space program should be aware of the buffer stall and handle it. [ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 [ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584 [ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488 [ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392 [ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 ... [ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 Signed-off-by:
Brent Lu <brent.lu@intel.com> Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.comSigned-off-by:
-
Scott Bahling authored
commit b0cb0990 upstream. The ST Audio ADCIII is an STDSP24 card plus extension box. With commit e8a91ae1 ("ALSA: ice1712: Add support for STAudio ADCIII") we enabled the ADCIII ports using the model=staudio option but forgot this part to ensure the STDSP24 card is initialized properly. Fixes: e8a91ae1 ("ALSA: ice1712: Add support for STAudio ADCIII") Signed-off-by:
Scott Bahling <sbahling@suse.com> Cc: <stable@vger.kernel.org> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1048934 Link: https://lore.kernel.org/r/20200518175728.28766-1-tiwai@suse.deSigned-off-by:
-
Daniel Jordan authored
[ Upstream commit 065cf577 ] With the removal of the padata timer, padata_do_serial no longer needs special CPU handling, so remove it. Signed-off-by:
Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Daniel Jordan authored
[ Upstream commit ec9c7d19 ] Exercising CPU hotplug on a 5.2 kernel with recent padata fixes from cryptodev-2.6.git in an 8-CPU kvm guest... # modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3 # echo 0 > /sys/devices/system/cpu/cpu1/online # echo c > /sys/kernel/pcrypt/pencrypt/parallel_cpumask # modprobe tcrypt mode=215 ...caused the following crash: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 2 PID: 134 Comm: kworker/2:2 Not tainted 5.2.0-padata-base+ #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-<snip> Workqueue: pencrypt padata_parallel_worker RIP: 0010:padata_reorder+0xcb/0x180 ... Call Trace: padata_do_serial+0x57/0x60 pcrypt_aead_enc+0x3a/0x50 [pcrypt] padata_parallel_worker+0x9b/0xe0 process_one_work+0x1b5/0x3f0 worker_thread+0x4a/0x3c0 ... In padata_alloc_pd, pd->cpu is set using the user-supplied cpumask instead of the effective cpumask, and in this case cpumask_first picked an offline CPU. The offline CPU's reorder->list.next is NULL in padata_reorder because the list wasn't initialized in padata_init_pqueues, which only operates on CPUs in the effective mask. Fix by using the effective mask in padata_alloc_pd. Fixes: 6fc4dbcf ("padata: Replace delayed timer with immediate workqueue in padata_reorder") Signed-off-by:
-
Herbert Xu authored
[ Upstream commit 6fc4dbcf ] The function padata_reorder will use a timer when it cannot progress while completed jobs are outstanding (pd->reorder_objects > 0). This is suboptimal as if we do end up using the timer then it would have introduced a gratuitous delay of one second. In fact we can easily distinguish between whether completed jobs are outstanding and whether we can make progress. All we have to do is look at the next pqueue list. This patch does that by replacing pd->processed with pd->cpu so that the next pqueue is more accessible. A work queue is used instead of the original try_again to avoid hogging the CPU. Note that we don't bother removing the work queue in padata_flush_queues because the whole premise is broken. You cannot flush async crypto requests so it makes no sense to even try. A subsequent patch will fix it by replacing it with a ref counting scheme. Signed-off-by:
-
Thomas Gleixner authored
[ Upstream commit 8101b5a1 ] Stephen reported the following build warning on a ARM multi_v7_defconfig build with GCC 9.2.1: kernel/futex.c: In function 'do_futex': kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized] 1676 | return oldval == cmparg; | ~~~~~~~^~~~~~~~~ kernel/futex.c:1652:6: note: 'oldval' was declared here 1652 | int oldval, ret; | ^~~~~~ introduced by commit a08971e9 ("futex: arch_futex_atomic_op_inuser() calling conventions change"). While that change should not make any difference it confuses GCC which fails to work out that oldval is not referenced when the return value is not zero. GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the early return, the issue is with the assembly macros. GCC fails to detect that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT which makes oldval uninteresting. The store to the callsite supplied oldval pointer is conditional on ret == 0. The straight forward way to solve this is to make the store unconditional. Aside of addressing the build warning this makes sense anyway because it removes the conditional from the fastpath. In the error case the stored value is uninteresting and the extra store does not matter at all. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.deSigned-off-by:
-
Hans de Goede authored
[ Upstream commit 3bd12da7 ] asus-nb-wmi does not add any extra functionality on these Asus Transformer books. They have detachable keyboards, so the hotkeys are send through a HID device (and handled by the hid-asus driver) and also the rfkill functionality is not used on these devices. Besides not adding any extra functionality, initializing the WMI interface on these devices actually has a negative side-effect. For some reason the \_SB.ATKD.INIT() function which asus_wmi_platform_init() calls drives GPO2 (INT33FC:02) pin 8, which is connected to the front facing webcam LED, high and there is no (WMI or other) interface to drive this low again causing the LED to be permanently on, even during suspend. This commit adds a blacklist of DMI system_ids on which not to load the asus-nb-wmi and adds these Transformer books to this list. This fixes the webcam LED being permanently on under Linux. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Alan Stern authored
[ Upstream commit ac854131 ] The syzbot fuzzer found a race between URB submission to endpoint 0 and device reset. Namely, during the reset we call usb_ep0_reinit() because the characteristics of ep0 may have changed (if the reset follows a firmware update, for example). While usb_ep0_reinit() is running there is a brief period during which the pointers stored in udev->ep_in[0] and udev->ep_out[0] are set to NULL, and if an URB is submitted to ep0 during that period, usb_urb_ep_type_check() will report it as a driver bug. In the absence of those pointers, the routine thinks that the endpoint doesn't exist. The log message looks like this: ------------[ cut here ]------------ usb 2-1: BOGUS urb xfer, pipe 2 != type 2 WARNING: CPU: 0 PID: 9241 at drivers/usb/core/urb.c:478 usb_submit_urb+0x1188/0x1460 drivers/usb/core/urb.c:478 Now, although submitting an URB while the device is being reset is a questionable thing to do, it shouldn't count as a driver bug as severe as submitting an URB for an endpoint that doesn't exist. Indeed, endpoint 0 always exists, even while the device is in its unconfigured state. To prevent these misleading driver bug reports, this patch updates usb_disable_endpoint() to avoid clearing the ep_in[] and ep_out[] pointers when the endpoint being disabled is ep0. There's no danger of leaving a stale pointer in place, because the usb_host_endpoint structure being pointed to is stored permanently in udev->ep0; it doesn't get deallocated until the entire usb_device structure does. Reported-and-tested-by: syzbot+db339689b2101f6f6071@syzkaller.appspotmail.com Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2005011558590.903-100000@netrider.rowland.orgSigned-off-by:
-
Maxim Petrov authored
[ Upstream commit f42234ff ] The paranoidal pointer check in IRQ handler looks very strange - it really protects us only against bogus drivers which request IRQ line with null pointer dev_id. However, the code fragment is incorrect because the dev pointer is used before the actual check which leads to undefined behavior. Remove the check to avoid confusing people with incorrect code. Signed-off-by:
Maxim Petrov <mmrmaximuzz@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Wu Bo authored
[ Upstream commit 4d8e28ff ] If the ceph_mdsc_open_export_target_session() return fails, it will do a "goto retry", but the session mutex has already been unlocked. Re-lock the mutex in that case to ensure that we don't unlock it twice. Signed-off-by:
Wu Bo <wubo40@huawei.com> Reviewed-by:
"Yan, Zheng" <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 1e189f26 ] Add a HID_QUIRK_NO_INIT_REPORTS quirk for the Dell K12A keyboard-dock, which can be used with various Dell Venue 11 models. Without this quirk the keyboard/touchpad combo works fine when connected at boot, but when hotplugged 9 out of 10 times it will not work properly. Adding the quirk fixes this. Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Yoshiyuki Kurauchi authored
[ Upstream commit 846c68f7 ] In drivers/net/gtp.c, gtp_genl_dump_pdp() should set NLM_F_MULTI flag since it returns multipart message. This patch adds a new arg "flags" in gtp_genl_fill_info() so that flags can be set by the callers. Signed-off-by:
Yoshiyuki Kurauchi <ahochauwaaaaa@gmail.com> Signed-off-by:
-
Thomas Gleixner authored
[ Upstream commit c84cb373 ] Leon reported that the printk_once() in __setup_APIC_LVTT() triggers a lockdep splat due to a lock order violation between hrtimer_base::lock and console_sem, when the 'once' condition is reset via /sys/kernel/debug/clear_warn_once after boot. The initial printk cannot trigger this because that happens during boot when the local APIC timer is set up on the boot CPU. Prevent it by moving the printk to a place which is guaranteed to be only called once during boot. Mark the deadline timer check related functions and data __init while at it. Reported-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
-
Daniel Playfair Cal authored
[ Upstream commit 538f6740 ] On the Dell XPS 9570, the Synaptics SYNA2393 touchpad generates spurious interrupts after resuming from suspend until it receives some input or is reset. Add it to the quirk I2C_HID_QUIRK_RESET_ON_RESUME so that it is reset when resuming from suspend. More information about the bug can be found in this mailing list discussion: https://www.spinics.net/lists/linux-input/msg59530.htmlSigned-off-by:
Daniel Playfair Cal <daniel.playfair.cal@gmail.com> Signed-off-by:
-
Tyrel Datwyler authored
[ Upstream commit b3652215 ] While removing an ibmvscsi client adapter a WARN_ON like the following is seen in the kernel log: drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1 WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping.c:311 dma_free_attrs+0x78/0x110 Supported: No, Unreleased kernel CPU: 9 PID: 24062 Comm: drmgr Kdump: loaded Tainted: G X 5.3.18-12-default NIP: c0000000001fa758 LR: c0000000001fa744 CTR: c0000000001fa6e0 REGS: c0000002173375d0 TRAP: 0700 Tainted: G X (5.3.18-12-default) MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28088282 XER: 20000000 CFAR: c0000000001fbf0c IRQMASK: 1 GPR00: c0000000001fa744 c000000217337860 c00000000161ab00 0000000000000000 GPR04: 0000000000000000 c000011e12250000 0000000018010000 0000000000000000 GPR08: 0000000000000000 0000000000000001 0000000000000001 c0080000190f4fa8 GPR12: c0000000001fa6e0 c000000007fc2a00 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 000000011420e310 0000000000000000 0000000000000000 0000000018010000 GPR28: c00000000159de50 c000011e12250000 0000000000006600 c000011e5c994848 NIP [c0000000001fa758] dma_free_attrs+0x78/0x110 LR [c0000000001fa744] dma_free_attrs+0x64/0x110 Call Trace: [c000000217337860] [000000011420e310] 0x11420e310 (unreliable) [c0000002173378b0] [c0080000190f0280] release_event_pool+0xd8/0x120 [ibmvscsi] [c000000217337930] [c0080000190f3f74] ibmvscsi_remove+0x6c/0x160 [ibmvscsi] [c000000217337960] [c0000000000f3cac] vio_bus_remove+0x5c/0x100 [c0000002173379a0] [c00000000087a0a4] device_release_driver_internal+0x154/0x280 [c0000002173379e0] [c0000000008777cc] bus_remove_device+0x11c/0x220 [c000000217337a60] [c000000000870fc4] device_del+0x1c4/0x470 [c000000217337b10] [c0000000008712a0] device_unregister+0x30/0xa0 [c000000217337b80] [c0000000000f39ec] vio_unregister_device+0x2c/0x60 [c000000217337bb0] [c00800001a1d0964] dlpar_remove_slot+0x14c/0x250 [rpadlpar_io] [c000000217337c50] [c00800001a1d0bcc] remove_slot_store+0xa4/0x110 [rpadlpar_io] [c000000217337cd0] [c000000000c091a0] kobj_attr_store+0x30/0x50 [c000000217337cf0] [c00000000057c934] sysfs_kf_write+0x64/0x90 [c000000217337d10] [c00000000057be10] kernfs_fop_write+0x1b0/0x290 [c000000217337d60] [c000000000488c4c] __vfs_write+0x3c/0x70 [c000000217337d80] [c00000000048c648] vfs_write+0xd8/0x260 [c000000217337dd0] [c00000000048ca8c] ksys_write+0xdc/0x130 [c000000217337e20] [c00000000000b488] system_call+0x5c/0x70 Instruction dump: 7c840074 f8010010 f821ffb1 20840040 eb830218 7c8407b4 48002019 60000000 2fa30000 409e003c 892d0988 792907e0 <0b090000> 2fbd0000 419e0028 2fbc0000 ---[ end trace 5955b3c0cc079942 ]--- rpadlpar_io: slot U9080.M9S.783AEC8-V11-C11 removed This is tripped as a result of irqs being disabled during the call to dma_free_coherent() by release_event_pool(). At this point in the code path we have quiesced the adapter and it is overly paranoid to be holding the host lock. [mkp: fixed build warning reported by sfr] Link: https://lore.kernel.org/r/1588027793-17952-1-git-send-email-tyreld@linux.ibm.comSigned-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
James Hilliard authored
[ Upstream commit 7706b0a7 ] If a component fails to bind due to -EPROBE_DEFER we should not log an error as this is not a real failure. Fixes messages like: vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517 vc4-drm soc:gpu: master bind failed: -517 Signed-off-by:
James Hilliard <james.hilliard1@gmail.com> Link: https://lore.kernel.org/r/20200411190241.89404-1-james.hilliard1@gmail.comSigned-off-by:
-
Richard Clark authored
[ Upstream commit 6de556c3 ] The Aquantia AQC100 controller enables a SFP+ port, so the driver should configure the media type as '_TYPE_FIBRE' instead of '_TYPE_TP'. Signed-off-by:
Richard Clark <richard.xnu.clark@gmail.com> Cc: Igor Russkikh <irusskikh@marvell.com> Cc: "David S. Miller" <davem@davemloft.net> Acked-by:
Igor Russkikh <irusskikh@marvell.com> Signed-off-by:
-
Stefano Garzarella authored
[ Upstream commit 107bc076 ] We want to deliver packets to monitoring devices before it is put in the virtqueue, to avoid that replies can appear in the packet capture before the transmitted packet. Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Xiyu Yang authored
[ Upstream commit 8aebfffa ] configfs_rmdir() invokes configfs_get_config_item(), which returns a reference of the specified config_item object to "parent_item" with increased refcnt. When configfs_rmdir() returns, local variable "parent_item" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of configfs_rmdir(). When down_write_killable() fails, the function forgets to decrease the refcnt increased by configfs_get_config_item(), causing a refcnt leak. Fix this issue by calling config_item_put() when down_write_killable() fails. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Quinn Tran authored
[ Upstream commit c48f849d ] Delete all sessions before unregistering local nvme port. This allows nvme layer to decrement all active rport count down to zero. Once the count is down to zero, nvme would call qla to continue with the npiv port deletion. PID: 27448 TASK: ffff9e34b777c1c0 CPU: 0 COMMAND: "qaucli" 0 [ffff9e25e84abbd8] __schedule at ffffffff977858ca 1 [ffff9e25e84abc68] schedule at ffffffff97785d79 2 [ffff9e25e84abc78] schedule_timeout at ffffffff97783881 3 [ffff9e25e84abd28] wait_for_completion at ffffffff9778612d 4 [ffff9e25e84abd88] qla_nvme_delete at ffffffffc0e3024e [qla2xxx] 5 [ffff9e25e84abda8] qla24xx_vport_delete at ffffffffc0e024b9 [qla2xxx] 6 [ffff9e25e84abdf0] fc_vport_terminate at ffffffffc011c247 [scsi_transport_fc] 7 [ffff9e25e84abe28] store_fc_host_vport_delete at ffffffffc011cd94 [scsi_transport_fc] 8 [ffff9e25e84abe70] dev_attr_store at ffffffff974b376b 9 [ffff9e25e84abe80] sysfs_kf_write at ffffffff972d9a92 10 [ffff9e25e84abe90] kernfs_fop_write at ffffffff972d907b 11 [ffff9e25e84abec8] vfs_write at ffffffff9724c790 12 [ffff9e25e84abf08] sys_write at ffffffff9724d55f 13 [ffff9e25e84abf50] system_call_fastpath at ffffffff97792ed2 RIP: 00007fc0bd81a6fd RSP: 00007ffff78d9648 RFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000022 RCX: 00007ffff78d96e0 RDX: 0000000000000022 RSI: 00007ffff78d94e0 RDI: 0000000000000008 RBP: 00007ffff78d9440 R8: 0000000000000000 R9: 00007fc0bd48b2cd R10: 0000000000000017 R11: 0000000000000293 R12: 0000000000000000 R13: 00005624e4dac840 R14: 00005624e4da9a10 R15: 0000000000000000 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b Link: https://lore.kernel.org/r/20200331104015.24868-4-njavali@marvell.comReviewed-by:
Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by:
Quinn Tran <qutran@marvell.com> Signed-off-by:
Nilesh Javali <njavali@marvell.com> Signed-off-by:
-
Arun Easi authored
[ Upstream commit 45a76264 ] In NPIV environment, a NPIV host may use a queue pair created by base host or other NPIVs, so the check for a queue pair created by this NPIV is not correct, and can cause an abort to fail, which in turn means the NVME command not returned. This leads to hang in nvme_fc layer in nvme_fc_delete_association() which waits for all I/Os to be returned, which is seen as hang in the application. Link: https://lore.kernel.org/r/20200331104015.24868-3-njavali@marvell.comReviewed-by:
Arun Easi <aeasi@marvell.com> Signed-off-by:
-
Jiri Kosina authored
[ Upstream commit 185af3e7 ] HID_DEVICE_ID_ALPS_1657 PID is too specific, as there are many other ALPS hardware IDs using this particular touchpad. Rename the identifier to HID_DEVICE_ID_ALPS_U1_UNICORN_LEGACY in order to describe reality better. Fixes: 640e403b ("HID: alps: Add AUI1657 device ID") Reported-by:
Xiaojian Cao <xiaojian.cao@cn.alps.com> Signed-off-by:
-
Artem Borisov authored
[ Upstream commit 640e403b ] This device is used on Lenovo V130-15IKB variants and uses the same registers as U1. Signed-off-by:
Artem Borisov <dedsa2002@gmail.com> Signed-off-by:
-
Sebastian Reichel authored
[ Upstream commit f9e82295 ] Add support for P80H84 touchscreen from eGalaxy: idVendor 0x0eef D-WAV Scientific Co., Ltd idProduct 0xc002 iManufacturer 1 eGalax Inc. iProduct 2 eGalaxTouch P80H84 2019 vDIVA_1204_T01 k4.02.146 Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Frédéric Pierret (fepitre) authored
[ Upstream commit c7527373 ] Remove "params.h" include, which has been dropped in GCC 10. Remove is_a_helper() macro, which is now defined in gimple.h, as seen when running './scripts/gcc-plugin.sh g++ g++ gcc': In file included from <stdin>:1: ./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ 852 | inline bool is_a_helper<const ggoto *>::test(const_gimple gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./gcc-plugins/gcc-common.h:125, from <stdin>:1: /usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper<T>::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here 1037 | is_a_helper <const ggoto *>::test (const gimple *gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid meaningless warnings from error() formats used by plugins: scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag] 253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by:
Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org> Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org [kees: include -Wno-format-diag for plugin builds] Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Richard Weinberger authored
[ Upstream commit 0e7572cf ] 3bfa7e14 ("fs/seq_file.c: seq_read(): add info message about buggy .next functions") showed that we don't use seq_file correctly. So make sure that our ->next function always updates the position. Fixes: 7bccd12d ("ubi: Add debugfs file for tracking PEB state") Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit e9d1a0a4 ] A call to 'i2c_demux_deactivate_master()' is missing in the error handling path, as already done in the remove function. Fixes: 50a5ba87 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Alexander Monakov authored
[ Upstream commit e461b8c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is likely to be shorter than 255 bytes, and zero-termination is not guaranteed. With Acer SF314-42 firmware these issues manifest visibly in dmesg: AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR0\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR1\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR2\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR3>\x83e\x8d\x9a\xd1... The first three lines show how the code over-reads adjacent table entries into the UID, and in the last line it even reads garbage data beyond the end of the IVRS table itself. Since each entry has the length of the UID (uidl member of ivhd_entry struct), use that for memcpy, and manually add a zero terminator. Avoid zero-filling hid and uid arrays up front, and instead ensure the uid array is always zero-terminated. No change needed for the hid array, as it was already properly zero-terminated. Fixes: 2a0cb4e2 ("iommu/amd: Add new map for storing IVHD dev entry type HID") Signed-off-by:
Alexander Monakov <amonakov@ispras.ru> Cc: Joerg Roedel <joro@8bytes.org> Cc: iommu@lists.linux-foundation.org Link: https://lore.kernel.org/r/20200511102352.1831-1-amonakov@ispras.ruSigned-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Christoph Hellwig authored
[ Upstream commit ecf84096 ] When "ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs" introduced atime support to ubifs, it also added lazytime support. As far as I can tell the lazytime support is terminally broken, as it causes mark_inode_dirty_sync to be called from __writeback_single_inode, which will then trigger the locking assert in ubifs_dirty_inode. Just remove the broken lazytime support for now, it can be added back later, especially as some infrastructure changes should make that easier soon. Fixes: 8c1c5f26 ("ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs") Signed-off-by:
-
Al Viro authored
[ Upstream commit 4e89b721 ] cpy and set really should be size_t; we won't get an overflow on that, since sysctl_nr_open can't be set above ~(size_t)0 / sizeof(void *), so nr that would've managed to overflow size_t on that multiplication won't get anywhere near copy_fdtable() - we'll fail with EMFILE before that. Cc: stable@kernel.org # v2.6.25+ Fixes: 9cfe015a (get rid of NR_OPEN and introduce a sysctl_nr_open) Reported-by:
Thiago Macieira <thiago.macieira@intel.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
