- 21 Jul, 2019 21 commits
-
-
Petr Oros authored
[ Upstream commit 2e5db6eb ] Certain cards in conjunction with certain switches need a little more time for link setup that results in ethtool link test failure after offline test. Patch adds a loop that waits for a link setup finish. Changes in v2: - added fixes header Fixes: 4276e47e ("be2net: Add link test to list of ethtool self tests.") Signed-off-by:
Petr Oros <poros@redhat.com> Reviewed-by:
Ivan Vecera <ivecera@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Colin Ian King authored
[ Upstream commit ea136a11 ] The left shift of unsigned int cpu_khz will overflow for large values of cpu_khz, so cast it to a long long before shifting it to avoid overvlow. For example, this can happen when cpu_khz is 4194305, i.e. ~4.2 GHz. Addresses-Coverity: ("Unintentional integer overflow") Fixes: 8c3ba8d0 ("x86, apic: ack all pending irqs when crashed/on kexec") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Borislav Petkov <bp@alien8.de> Cc: "H . Peter Anvin" <hpa@zytor.com> Cc: kernel-janitors@vger.kernel.org Link: https://lkml.kernel.org/r/20190619181446.13635-1-colin.king@canonical.comSigned-off-by:
-
Qian Cai authored
[ Upstream commit 919aef44 ] Compiling a kernel with W=1 generates this warning, arch/x86/platform/efi/quirks.c:731:16: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits] Fixes: 3425d934 ("efi/x86: Handle page faults occurring while running ...") Signed-off-by:
Qian Cai <cai@lca.pw> Acked-by:
"Prakhya, Sai Praneeth" <sai.praneeth.prakhya@intel.com> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
David Howells authored
[ Upstream commit 90fa9b64 ] Fix the cb_break_lock spinlock in afs_volume struct by initialising it when the volume record is allocated. Also rename the lock to cb_v_break_lock to distinguish it from the lock of the same name in the afs_server struct. Without this, the following trace may be observed when a volume-break callback is received: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID: 50 Comm: kworker/2:1 Not tainted 5.2.0-rc1-fscache+ #3045 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Workqueue: afs SRXAFSCB_CallBack Call Trace: dump_stack+0x67/0x8e register_lock_class+0x23b/0x421 ? check_usage_forwards+0x13c/0x13c __lock_acquire+0x89/0xf73 lock_acquire+0x13b/0x166 ? afs_break_callbacks+0x1b2/0x3dd _raw_write_lock+0x2c/0x36 ? afs_break_callbacks+0x1b2/0x3dd afs_break_callbacks+0x1b2/0x3dd ? trace_event_raw_event_afs_server+0x61/0xac SRXAFSCB_CallBack+0x11f/0x16c process_one_work+0x2c5/0x4ee ? worker_thread+0x234/0x2ac worker_thread+0x1d8/0x2ac ? cancel_delayed_work_sync+0xf/0xf kthread+0x11f/0x127 ? kthread_park+0x76/0x76 ret_from_fork+0x24/0x30 Fixes: 68251f0a ("afs: Fix whole-volume callback handling") Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 27e23d89 ] omap3xxx_prm_enable_io_wakeup() is marked __init, but its caller is not, so we get a warning with clang-8: WARNING: vmlinux.o(.text+0x343c8): Section mismatch in reference from the function omap3xxx_prm_late_init() to the function .init.text:omap3xxx_prm_enable_io_wakeup() The function omap3xxx_prm_late_init() references the function __init omap3xxx_prm_enable_io_wakeup(). This is often because omap3xxx_prm_late_init lacks a __init annotation or the annotation of omap3xxx_prm_enable_io_wakeup is wrong. When building with gcc, omap3xxx_prm_enable_io_wakeup() is always inlined, so we never noticed in the past. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Tony Lindgren <tony@atomide.com> Reviewed-by:
Andrew Murray <andrew.murray@arm.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit 36558020 ] It's a simple typo in the DNS file, which was pretty serious. No scripts were working properly. Fix it up. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 085ebfe9 ] perf_sample_regs_user() uses 'current->mm' to test for the presence of userspace, but this is insufficient, consider use_mm(). A better test is: '!(current->flags & PF_KTHREAD)', exec() clears PF_KTHREAD after it sets the new ->mm but before it drops to userspace for the first time. Possibly obsoletes: bf05fc25 ("powerpc/perf: Fix oops when kthread execs user process") Reported-by:
Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Reported-by:
Young Xiao <92siuyang@gmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Will Deacon <will.deacon@arm.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 4018994f ("perf: Add ability to attach user level registers dump to sample") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Michael Ellerman authored
[ Upstream commit 16391bfc ] This tests that when a process with a mapping above 512TB forks we correctly separate the parent and child address spaces. This exercises the bug in the context id handling fixed in the previous commit. Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Ran Wang authored
[ Upstream commit 53f2ac9d ] PSCI spec define 1st parameter's bit 16 of function CPU_SUSPEND to indicate CPU State Type: 0 for standby, 1 for power down. In this case, we want to select standby for CPU idle feature. But current setting wrongly select power down and cause CPU SUSPEND fail every time. Need this fix. Fixes: 8897f325 ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by:
Ran Wang <ran.wang_1@nxp.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit a483fcab ] Starting with ACPI 6.2 bits 1 and 2 of the BGRT status field are no longer reserved. These bits are now used to indicate if the image needs to be rotated before being displayed. The first device using these bits has now shown up (the GPD MicroPC) and the reserved bits check causes us to reject the valid BGRT table on this device. Rather then changing the reserved bits check, allowing only the 2 new bits, instead just completely remove it so that we do not end up with a similar problem when more bits are added in the future. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 41b3588d ] If we do a clk_get() for a clock that does not exists, we have _ti_omap4_clkctrl_xlate() return uninitialized data if no match is found. This can be seen in some cases with SLAB_DEBUG enabled: Unable to handle kernel paging request at virtual address 5a5a5a5a ... clk_hw_create_clk.part.33 sysc_notifier_call notifier_call_chain blocking_notifier_call_chain device_add Let's fix this by setting a found flag only when we find a match. Reported-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Fixes: 88a17252 ("clk: ti: add support for clkctrl clocks") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Heyi Guo authored
[ Upstream commit a050fa54 ] When we run several VMs with PCI passthrough and GICv4 enabled, not pinning vCPUs, we will occasionally see below warnings in dmesg: ITS queue timeout (65440 65504 480) ITS cmd its_build_vmovp_cmd failed The reason for the above issue is that in BUILD_SINGLE_CMD_FUNC: 1. Post the write command. 2. Release the lock. 3. Start to read GITS_CREADR to get the reader pointer. 4. Compare the reader pointer to the target pointer. 5. If reader pointer does not reach the target, sleep 1us and continue to try. If we have several processors running the above concurrently, other CPUs will post write commands while the 1st CPU is waiting the completion. So we may have below issue: phase 1: ---rd_idx-----from_idx-----to_idx--0--------- wait 1us: phase 2: --------------from_idx-----to_idx--0-rd_idx-- That is the rd_idx may fly ahead of to_idx, and if in case to_idx is near the wrap point, rd_idx will wrap around. So the below condition will not be met even after 1s: if (from_idx < to_idx && rd_idx >= to_idx) There is another theoretical issue. For a slow and busy ITS, the initial rd_idx may fall behind from_idx a lot, just as below: ---rd_idx---0--from_idx-----to_idx----------- This will cause the wait function exit too early. Actually, it does not make much sense to use from_idx to judge if to_idx is wrapped, but we need a initial rd_idx when lock is still acquired, and it can be used to judge whether to_idx is wrapped and the current rd_idx is wrapped. We switch to a method of calculating the delta of two adjacent reads and accumulating it to get the sum, so that we can get the real rd_idx from the wrapped value even when the queue is almost full. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jason Cooper <jason@lakedaemon.net> Signed-off-by:
Heyi Guo <guoheyi@huawei.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Guo Ren authored
[ Upstream commit db56c512 ] The csky,mpintc could deliver a external irq to one cpu or all cpus, but it couldn't deliver a external irq to a group of cpus with cpu_mask. So we only use auto deliver mode when affinity mask_val is equal to cpu_present_mask. There is no limitation for only two cpus in SMP system. Signed-off-by:
Guo Ren <ren_guo@c-sky.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit 26d65140 ] Amlogic's vendor kernel defines an OPP for the GPU on Meson8b boards with a voltage of 1.15V. It turns out that the vendor kernel relies on the bootloader to set up the voltage. The bootloader however sets a fixed voltage of 1.10V. Amlogic's patched u-boot sources (uboot-2015-01-15-23a3562521) confirm this: $ grep -oiE "VDD(EE|AO)_VOLTAGE[ ]+[0-9]+" board/amlogic/configs/m8b_* board/amlogic/configs/m8b_m100_v1.h:VDDAO_VOLTAGE 1100 board/amlogic/configs/m8b_m101_v1.h:VDDAO_VOLTAGE 1100 board/amlogic/configs/m8b_m102_v1.h:VDDAO_VOLTAGE 1100 board/amlogic/configs/m8b_m200_v1.h:VDDAO_VOLTAGE 1100 board/amlogic/configs/m8b_m201_v1.h:VDDEE_VOLTAGE 1100 board/amlogic/configs/m8b_m201_v1.h:VDDEE_VOLTAGE 1100 board/amlogic/configs/m8b_m202_v1.h:VDDEE_VOLTAGE 1100 Another hint at this is the VDDEE voltage on the EC-100 and Odroid-C1 boards. The VDDEE regulator supplies the Mali GPU. It's basically a copy of the VCCK (CPU supply) which means it's limited to 0.86V to 1.14V. Update the operating voltage of the Mali GPU on Meson8b to 1.10V so it matches with what the vendor u-boot sets. Fixes: c3ea80b6 ("ARM: dts: meson8b: add the Mali-450 MP2 GPU") Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Kevin Hilman <khilman@baylibre.com> Signed-off-by:
-
Martin Blumenstingl authored
[ Upstream commit 01dfdd7b ] The interrupts in Amlogic's vendor kernel sources are all contiguous. There are two typos leading to pp2 and pp4 as well as ppmmu2 and ppmmu4 incorrectly sharing the same interrupt line. Fix this by using interrupt 170 for pp2 and 171 for ppmmu2. Also drop the undocumented "switch-delay" which is a left-over from my experiments with an early lima kernel driver when it was still out-of-tree and required this property on Amlogic SoCs. Fixes: 7d3f6b53 ("ARM: dts: meson8: add the Mali-450 MP6 GPU") Signed-off-by:
-
Sven Van Asbroeck authored
commit 2472d64a upstream. The firmware loader queries if LSM/IMA permits it to load firmware via the sysfs fallback. Unfortunately, the code does the opposite: it expressly permits sysfs fw loading if security_kernel_load_data( LOADING_FIRMWARE) returns -EACCES. This happens because a zero-on-success return value is cast to a bool that's true on success. Fix the return value handling so we get the correct behaviour. Fixes: 6e852651 ("firmware: add call to LSM hook before firmware sysfs fallback") Cc: Stable <stable@vger.kernel.org> Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: Kees Cook <keescook@chromium.org> To: Luis Chamberlain <mcgrof@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: linux-kernel@vger.kernel.org Signed-off-by:
Sven Van Asbroeck <TheSven73@gmail.com> Reviewed-by:
Mimi Zohar <zohar@linux.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
James Morse authored
commit 83b44fe3 upstream. The cacheinfo structures are alloced/freed by cpu online/offline callbacks. Originally these were only used by sysfs to expose the cache topology to user space. Without any in-kernel dependencies CPUHP_AP_ONLINE_DYN was an appropriate choice. resctrl has started using these structures to identify CPUs that share a cache. It updates its 'domain' structures from cpu online/offline callbacks. These depend on the cacheinfo structures (resctrl_online_cpu()->domain_add_cpu()->get_cache_id()-> get_cpu_cacheinfo()). These also run as CPUHP_AP_ONLINE_DYN. Now that there is an in-kernel dependency, move the cacheinfo work earlier so we know its done before resctrl's CPUHP_AP_ONLINE_DYN work runs. Fixes: 2264d9c7 ("x86/intel_rdt: Build structures for each resource based on cache topology") Cc: <stable@vger.kernel.org> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20190624173656.202407-1-james.morse@arm.comSigned-off-by:
-
Masahiro Yamada authored
commit c32cc30c upstream. cpu_to_le32/le32_to_cpu is defined in include/linux/byteorder/generic.h, which is not exported to user-space. UAPI headers must use the ones prefixed with double-underscore. Detected by compile-testing exported headers: include/linux/nilfs2_ondisk.h: In function `nilfs_checkpoint_set_snapshot': include/linux/nilfs2_ondisk.h:536:17: error: implicit declaration of function `cpu_to_le32' [-Werror=implicit-function-declaration] cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) | \ ^ include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS' NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot) ^~~~~~~~~~~~~~~~~~~~ include/linux/nilfs2_ondisk.h:536:29: error: implicit declaration of function `le32_to_cpu' [-Werror=implicit-function-declaration] cp->cp_flags = cpu_to_le32(le32_to_cpu(cp->cp_flags) | \ ^ include/linux/nilfs2_ondisk.h:552:1: note: in expansion of macro `NILFS_CHECKPOINT_FNS' NILFS_CHECKPOINT_FNS(SNAPSHOT, snapshot) ^~~~~~~~~~~~~~~~~~~~ include/linux/nilfs2_ondisk.h: In function `nilfs_segment_usage_set_clean': include/linux/nilfs2_ondisk.h:622:19: error: implicit declaration of function `cpu_to_le64' [-Werror=implicit-function-declaration] su->su_lastmod = cpu_to_le64(0); ^~~~~~~~~~~ Link: http://lkml.kernel.org/r/20190605053006.14332-1-yamada.masahiro@socionext.com Fixes: e63e88bc ("nilfs2: move ioctl interface and disk layout to uapi separately") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Ryusuke Konishi <konishi.ryusuke@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg KH <gregkh@linuxfoundation.org> Cc: Joe Perches <joe@perches.com> Cc: <stable@vger.kernel.org> [4.9+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Cole Rogers authored
commit abbe3acd upstream. Thinkpad t480 laptops had some touchpad features disabled, resulting in the loss of pinch to activities in GNOME, on wayland, and other touch gestures being slower. This patch adds the touchpad of the t480 to the smbus_pnp_ids whitelist to enable the extra features. In my testing this does not break suspend (on fedora, with wayland, and GNOME, using the rc-6 kernel), while also fixing the feature on a T480. Signed-off-by:
Cole Rogers <colerogers@disroot.org> Acked-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Konstantin Khlebnikov authored
commit d17ba0f6 upstream. Driver does not want to keep packets in Tx queue when link is lost. But present code only reset NIC to flush them, but does not prevent queuing new packets. Moreover reset sequence itself could generate new packets via netconsole and NIC falls into endless reset loop. This patch wakes Tx queue only when NIC is ready to send packets. This is proper fix for problem addressed by commit 0f9e980b ("e1000e: fix cyclic resets at link up with active tx"). Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Suggested-by:
Alexander Duyck <alexander.duyck@gmail.com> Tested-by:
Joseph Yasi <joe.yasi@gmail.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Tested-by:
Oleksandr Natalenko <oleksandr@redhat.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Konstantin Khlebnikov authored
commit caff422e upstream. This reverts commit 0f9e980b. That change cased false-positive warning about hardware hang: e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang: TDH <0> TDT <1> next_to_use <1> next_to_clean <0> buffer_info[next_to_clean]: time_stamp <fffba7a7> next_to_watch <0> jiffies <fffbb140> next_to_watch.status <0> MAC Status <40080080> PHY Status <7949> PHY 1000BASE-T Status <0> PHY Extended Status <3000> PCI Status <10> e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx Besides warning everything works fine. Original issue will be fixed property in following patch. Signed-off-by:
-
- 14 Jul, 2019 19 commits
-
-
Greg Kroah-Hartman authored
-
Arnd Bergmann authored
commit fbd6b250 upstream. An earlier patch I sent reduced the stack usage enough to get below the warning limit, and I could show this was safe, but with GCC_PLUGIN_STRUCTLEAK_BYREF_ALL, it gets worse again because large stack variables in the same function no longer overlap: drivers/staging/rtl8712/rtl871x_ioctl_linux.c: In function 'translate_scan.isra.2': drivers/staging/rtl8712/rtl871x_ioctl_linux.c:322:1: error: the frame size of 1200 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Split out the largest two blocks in the affected function into two separate functions and mark those noinline_for_stack. Fixes: 8c5af16f ("staging: rtl8712: reduce stack usage") Fixes: 81a56f6d ("gcc-plugins: structleak: Generalize to all variable types") Signed-off-by:
-
Dave Stevenson authored
commit a26be06d upstream. The change to mapping V4L2 to MMAL buffers 1:1 didn't handle the condition we get with raw pixel buffers (eg YUV and RGB) direct from the camera's stills port. That sends the pixel buffer and then an empty buffer with the EOS flag set. The EOS buffer wasn't handled and returned an error up the stack. Handle the condition correctly by returning it to the component if streaming, or returning with an error if stopping streaming. Fixes: 93841670 ("staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org> Signed-off-by:
Stefan Wahren <wahrenst@gmx.net> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Dave Stevenson authored
commit bb8e9700 upstream. Before commit "staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping" there was a need to ensure that there were sufficient buffers supplied from the user to cover those being sent to the VPU (always 1). Now the buffers are linked 1:1 between MMAL and V4L2, therefore there is no need for that check, and indeed it is wrong as there is no need to submit all the buffers before starting streaming. Fixes: 93841670 ("staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping") Signed-off-by:
-
Dave Stevenson authored
commit 70ec64cc upstream. With the recent change to match MMAL and V4L2 buffers there is a need to wait for all MMAL buffers to be returned during stop_streaming. Fixes: 93841670 ("staging: bcm2835-camera: Remove V4L2/MMAL buffer remapping") Signed-off-by:
-
Dave Stevenson authored
commit 8dedab29 upstream. The commit "staging: bcm2835-camera: Replace open-coded idr with a struct idr." replaced an internal implementation of an idr with the standard functions and a spinlock. idr_alloc(GFP_KERNEL) can sleep whilst calling kmem_cache_alloc to allocate the new node, but this is not valid whilst in an atomic context due to the spinlock. There is no need for this to be a spinlock as a standard mutex is sufficient. Fixes: 950fd867 ("staging: bcm2835-camera: Replace open-coded idr with a struct idr.") Signed-off-by:
-
Colin Ian King authored
commit 5555ebbb upstream. In the default event case switchdev_work is being leaked because nothing is queued for work. Fix this by kfree'ing switchdev_work before returning NOTIFY_DONE. Addresses-Coverity: ("Resource leak") Fixes: 44baaa43 ("staging: fsl-dpaa2/ethsw: Add Freescale DPAA2 Ethernet Switch driver") Signed-off-by:
-
Nicolas Saenz Julienne authored
commit 77cf3f5d upstream. The killable version of wait_event() is meant to be used on situations where it should not fail at all costs, but still have the convenience of being able to kill it if really necessary. Wait events in VCHIQ doesn't fit this criteria, as it's mainly used as an interface to V4L2 and ALSA devices. Fixes: 852b2876 ("staging: vchiq: rework remove_event handling") Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Acked-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
-
Nicolas Saenz Julienne authored
commit 086efbab upstream. The killable version of wait_for_completion() is meant to be used on situations where it should not fail at all costs, but still have the convenience of being able to kill it if really necessary. VCHIQ doesn't fit this criteria, as it's mainly used as an interface to V4L2 and ALSA devices. Fixes: a772f116 ("staging: vchiq: switch to wait_for_completion_killable") Signed-off-by:
-
Nicolas Saenz Julienne authored
commit 061ca140 upstream. The killable version of down() is meant to be used on situations where it should not fail at all costs, but still have the convenience of being able to kill it if really necessary. VCHIQ doesn't fit this criteria, as it's mainly used as an interface to V4L2 and ALSA devices. Fixes: ff5979ad ("staging: vchiq_2835_arm: quit using custom down_interruptible()") Signed-off-by:
-
Vishnu DASA authored
commit 1c2eb5b2 upstream. The VMCI handle array has an integer overflow in vmci_handle_arr_append_entry when it tries to expand the array. This can be triggered from a guest, since the doorbell link hypercall doesn't impose a limit on the number of doorbell handles that a VM can create in the hypervisor, and these handles are stored in a handle array. In this change, we introduce a mandatory max capacity for handle arrays/lists to avoid excessive memory usage. Signed-off-by:
Vishnu Dasa <vdasa@vmware.com> Reviewed-by:
Adit Ranadive <aditr@vmware.com> Reviewed-by:
Jorgen Hansen <jhansen@vmware.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Christian Lamparter authored
commit feb09b29 upstream. This patch follows Alan Stern's recent patch: "p54: Fix race between disconnect and firmware loading" that overhauled carl9170 buggy firmware loading and driver unbinding procedures. Since the carl9170 code was adapted from p54 it uses the same functions and is likely to have the same problem, but it's just that the syzbot hasn't reproduce them (yet). a summary from the changes (copied from the p54 patch): * Call usb_driver_release_interface() rather than device_release_driver(). * Lock udev (the interface's parent) before unbinding the driver instead of locking udev->parent. * During the firmware loading process, take a reference to the USB interface instead of the USB device. * Don't take an unnecessary reference to the device during probe (and then don't drop it during disconnect). and * Make sure to prevent use-after-free bugs by explicitly setting the driver context to NULL after signaling the completion. Cc: <stable@vger.kernel.org> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Fabrice Gasnier authored
commit 7685010f upstream. Add missing vdda-supply, analog power supply, to STM32 ADC. When vdda is an independent supply, it needs to be properly turned on or off to supply the ADC. Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Fixes: 1add6988 ("iio: adc: Add support for STM32 ADC core"). Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Todd Kjos authored
commit bb4a2e48 upstream. The buffer copy functions assumed the caller would ensure correct alignment and that the memory to be copied was completely within the binder buffer. There have been a few cases discovered by syzkallar where a malformed transaction created by a user could violated the assumptions and resulted in a BUG_ON. The fix is to remove the BUG_ON and always return the error to be handled appropriately by the caller. Acked-by:
Martijn Coenen <maco@android.com> Reported-by: syzbot+3ae18325f96190606754@syzkaller.appspotmail.com Fixes: bde4a19f ("binder: use userspace pointer as base of buffer space") Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Todd Kjos <tkjos@google.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Todd Kjos authored
commit 1909a671 upstream. syzkallar found a 32-byte memory leak in a rarely executed error case. The transaction complete work item was not freed if put_user() failed when writing the BR_TRANSACTION_COMPLETE to the user command buffer. Fixed by freeing it before put_user() is called. Reported-by: syzbot+182ce46596c3f2e1eb24@syzkaller.appspotmail.com Signed-off-by:
-
Nick Desaulniers authored
commit e9e08a07 upstream. With CONFIG_LKDTM=y and make OBJCOPY=llvm-objcopy, llvm-objcopy errors: llvm-objcopy: error: --set-section-flags=.text conflicts with --rename-section=.text=.rodata Rather than support setting flags then renaming sections vs renaming then setting flags, it's simpler to just change both at the same time via --rename-section. Adding the load flag is required for GNU objcopy to mark .rodata Type as PROGBITS after the rename. This can be verified with: $ readelf -S drivers/misc/lkdtm/rodata_objcopy.o ... Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align ... [ 1] .rodata PROGBITS 0000000000000000 00000040 0000000000000004 0000000000000000 A 0 0 4 ... Which shows that .text is now renamed .rodata, the alloc flag A is set, the type is PROGBITS, and the section is not flagged as writeable W. Cc: stable@vger.kernel.org Link: https://sourceware.org/bugzilla/show_bug.cgi?id=24554 Link: https://github.com/ClangBuiltLinux/linux/issues/448Reported-by:
Alan Modra <amodra@gmail.com> Suggested-by:
Jordan Rupprect <rupprecht@google.com> Suggested-by:
Kees Cook <keescook@chromium.org> Acked-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
Sebastian Parschauer authored
commit 4c129549 upstream. The PixArt OEM mice are known for disconnecting every minute in runlevel 1 or 3 if they are not always polled. So add quirk ALWAYS_POLL for this Alienware branded Primax mouse as well. Daniel Schepler (@dschepler) reported and tested the quirk. Reference: https://github.com/sriemer/fix-linux-mouse/issues/15Signed-off-by:
Sebastian Parschauer <s.parschauer@gmx.de> CC: stable@vger.kernel.org Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Sergio Paracuellos authored
commit 0ae0cf50 upstream. Add missing parenthesis to PCIE_FTS_NUM_LO macro to do the same it was being done in original code. Fixes: a4b2eb91 ("staging: mt7621-pci: rewrite RC FTS configuration") Signed-off-by:
Sergio Paracuellos <sergio.paracuellos@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Ian Abbott authored
commit 7379e6ba upstream. The interrupt handler `pci230_interrupt()` causes a null pointer dereference for a PCI260 card. There is no analog output subdevice for a PCI260. The `dev->write_subdev` subdevice pointer and therefore the `s_ao` subdevice pointer variable will be `NULL` for a PCI260. The following call near the end of the interrupt handler results in the null pointer dereference for a PCI260: comedi_handle_events(dev, s_ao); Fix it by only calling the above function if `s_ao` is valid. Note that the other uses of `s_ao` in the calls `pci230_handle_ao_nofifo(dev, s_ao);` and `pci230_handle_ao_fifo(dev, s_ao);` will never be reached for a PCI260, so they are safe. Fixes: 39064f23 ("staging: comedi: amplc_pci230: use comedi_handle_events()") Cc: <stable@vger.kernel.org> # v3.19+ Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
