- Aug 19, 2020
-
-
Helge Deller authored
commit 157e9afc upstream. This reverts commit 86d4d068. Signed-off-by:
Helge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Helge Deller authored
commit 6e9f06ee upstream. This reverts commit 9e5c6021. No need to use the ldcw instruction as SMP spinlock release barrier. Revert it to gain back speed again. Signed-off-by:
-
Helge Deller authored
commit 462fb756 upstream. This reverts commit e6eb5fe9. We need to optimize it differently. A follow up patch will correct it. Signed-off-by:
-
Helge Deller authored
commit 3d05b8ae upstream. This reverts commit 2772f0ef. It turns out that we want to implement the spinlock code differently. Signed-off-by:
-
Baoquan He authored
commit a8a4b7ae upstream. This reverts commit 26e7dead. Sonny reported that one of their tests started failing on the latest kernel on their Chrome OS platform. The root cause is that the above commit removed the protection line of empty zone, while the parser used in the test relies on the protection line to mark the end of each zone. Let's revert it to avoid breaking userspace testing or applications. Fixes: 26e7dead ("mm/vmstat.c: do not show lowmem reserve protection information of empty zone)" Reported-by:
Sonny Rao <sonnyrao@chromium.org> Signed-off-by:
Baoquan He <bhe@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Reviewed-by:
David Hildenbrand <david@redhat.com> Acked-by:
David Rientjes <rientjes@google.com> Cc: <stable@vger.kernel.org> [5.8.x] Link: http://lkml.kernel.org/r/20200811075412.12872-1-bhe@redhat.com Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Gao Xiang authored
commit 0dcd3c94 upstream. Each ondisk inode should be aligned with inode slot boundary (32-byte alignment) because of nid calculation formula, so all compact inodes (32 byte) cannot across page boundary. However, extended inode is now 64-byte form, which can across page boundary in principle if the location is specified on purpose, although it's hard to be generated by mkfs due to the allocation policy and rarely used by Android use case now mainly for > 4GiB files. For now, only two fields `i_ctime_nsec` and `i_nlink' couldn't be read from disk properly and cause out-of-bound memory read with random value. Let's fix now. Fixes: 431339ba ("staging: erofs: add inode operations") Cc: <stable@vger.kernel.org> # 4.19+ Link: https://lore.kernel.org/r/20200729175801.GA23973@xiangao.remote.csb Reviewed-by:
Chao Yu <yuchao0@huawei.com> Signed-off-by:
Gao Xiang <hsiangkao@redhat.com> Signed-off-by:
-
Alexander Sverdlin authored
commit 44a80df4 upstream. After spi_nor_write_disable() return code checks were introduced in the spi-nor front end intel-spi backend stopped to work because WRDI was never supported and always failed. Just pretend it was sucessful and ignore the command itself. HW sequencer shall do the right thing automatically, while with SW sequencer we cannot do it anyway, because the only tool we had was preopcode and it makes no sense for WRDI. Fixes: bce679e5 ("mtd: spi-nor: Check for errors after each Register Operation") Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/282e1305-fd08-e446-1a22-eb4dff78cfb4@nokia.com Signed-off-by:
Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by:
-
Sivaprakash Murugesan authored
commit 443440cc upstream. SFLASHC_BURST_CFG is only available on older ipq NAND platforms, this register has been removed when the NAND controller got implemented in the qpic controller. Avoid writing this register on devices which are based on qpic NAND controller. Fixes: dce84760 ("mtd: nand: qcom: Support for IPQ8074 QPIC NAND controller") Cc: stable@vger.kernel.org Signed-off-by:
Sivaprakash Murugesan <sivaprak@codeaurora.org> Signed-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/1591948696-16015-2-git-send-email-sivaprak@codeaurora.org Signed-off-by:
-
Christian Eggers authored
commit aa9e862d upstream. Simply copying all xfers from userspace into one bounce buffer causes alignment problems if the SPI controller uses DMA. Ensure that all transfer data blocks within the rx and tx bounce buffers are aligned for DMA (according to ARCH_KMALLOC_MINALIGN). Alignment may increase the usage of the bounce buffers. In some cases, the buffers may need to be increased using the "bufsiz" module parameter. Signed-off-by:
Christian Eggers <ceggers@arri.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200728100832.24788-1-ceggers@arri.de Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Chanwoo Choi authored
commit 0aae11bc upstream. The commit 66d0e797 ("Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"") roll back the device name from 'devfreqX' to device name explained in DT. After applied commit 66d0e797, the indentation of devfreq_summary debugfs node was broken. So, fix indentaion of devfreq_summary debugfs node as following: For example on Exynos5422-based Odroid-XU3 board, $ cat /sys/kernel/debug/devfreq/devfreq_summary dev parent_dev governor polling_ms cur_freq_Hz min_freq_Hz max_freq_Hz ------------------------------ ------------------------------ --------------- ---------- ------------ ------------ ------------ 10c20000.memory-controller null simple_ondemand 0 413000000 165000000 825000000 soc:bus_wcore null simple_ondemand 50 88700000 88700000 532000000 soc:bus_noc soc:bus_wcore passive 0 66600000 66600000 111000000 soc:bus_fsys_apb soc:bus_wcore passive 0 111000000 111000000 222000000 soc:bus_fsys soc:bus_wcore passive 0 75000000 75000000 200000000 soc:bus_fsys2 soc:bus_wcore passive 0 75000000 75000000 200000000 soc:bus_mfc soc:bus_wcore passive 0 83250000 83250000 333000000 soc:bus_gen soc:bus_wcore passive 0 88700000 88700000 266000000 soc:bus_peri soc:bus_wcore passive 0 66600000 66600000 66600000 soc:bus_g2d soc:bus_wcore passive 0 83250000 83250000 333000000 soc:bus_g2d_acp soc:bus_wcore passive 0 0 66500000 266000000 soc:bus_jpeg soc:bus_wcore passive 0 0 75000000 300000000 soc:bus_jpeg_apb soc:bus_wcore passive 0 0 83250000 166500000 soc:bus_disp1_fimd soc:bus_wcore passive 0 0 120000000 200000000 soc:bus_disp1 soc:bus_wcore passive 0 0 120000000 300000000 soc:bus_gscl_scaler soc:bus_wcore passive 0 0 150000000 300000000 soc:bus_mscl soc:bus_wcore passive 0 0 84000000 666000000 Cc: stable@vger.kernel.org Fixes: 66d0e797 ("Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"") Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Marc Zyngier authored
commit 63ef91f2 upstream. Booting a recent kernel on a rk3399-based system (nanopc-t4), equipped with a recent u-boot and ATF results in an Oops due to a NULL pointer dereference. This turns out to be due to the rk3399-dmc driver looking for an *undocumented* property (rockchip,pmu), and happily using a NULL pointer when the property isn't there. Instead, make most of what was brought in with 9173c5ce ("PM / devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.") conditioned on finding this property in the device-tree, preventing the driver from exploding. Cc: stable@vger.kernel.org Fixes: 9173c5ce ("PM / devfreq: rk3399_dmc: Pass ODT and auto power down parameters to TF-A.") Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
-
Romain Naour authored
commit 7f897acb upstream. Since the patch [1], building the kernel using a toolchain built with binutils 2.33.1 prevents booting a sh4 system under Qemu. Apply the patch provided by Alan Modra [2] that fix alignment of rodata. [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ebd2263ba9a9124d93bbc0ece63d7e0fae89b40e [2] https://www.sourceware.org/ml/binutils/2019-12/msg00112.html Signed-off-by:
Romain Naour <romain.naour@gmail.com> Signed-off-by:
-
Huacai Chen authored
commit cf99c505 upstream. Only Loongson64 platform has and needs loongson_regs.h, including it unconditionally will cause build errors. Fixes: 7f2a83f1 ("KVM: MIPS: Add CPUCFG emulation for Loongson-3") Cc: stable@vger.kernel.org Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Huacai Chen <chenhc@lemote.com> Message-Id: <1596891052-24052-1-git-send-email-chenhc@lemote.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Ivan Kokshaysky authored
commit 10470dec upstream. Commit 0c868627 (cpufreq: dt: Allow platform specific intermediate callbacks) added two function pointers to the struct cpufreq_dt_platform_data. However, armada37xx_cpufreq_driver_init() has this struct (pdata) located on the stack and uses only "suspend" and "resume" fields. So these newly added "get_intermediate" and "target_intermediate" pointers are uninitialized and contain arbitrary non-null values, causing all kinds of trouble. For instance, here is an oops on espressobin after an attempt to change the cpefreq governor: [ 29.174554] Unable to handle kernel execute from non-executable memory at virtual address ffff00003f87bdc0 ... [ 29.269373] pc : 0xffff00003f87bdc0 [ 29.272957] lr : __cpufreq_driver_target+0x138/0x580 ... Fixed by zeroing out pdata before use. Cc: <stable@vger.kernel.org> # v5.7+ Signed-off-by:
Ivan Kokshaysky <ink@jurassic.park.msu.ru> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Viresh Kumar authored
commit 8cc46ae5 upstream. The locking around governors handling isn't adequate currently. The list of governors should never be traversed without the locking in place. Also governor modules must not be removed while the code in them is still in use. Reported-by:
Quentin Perret <qperret@google.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Trond Myklebust authored
commit d474f961 upstream. If the NFS_LAYOUT_RETURN_REQUESTED flag is set, we want to return the layout as soon as possible, meaning that the affected layout segments should be marked as invalid, and should no longer be in use for I/O. Fixes: f0b42981 ("pNFS: Ignore non-recalled layouts in pnfs_layout_need_return()") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
-
Trond Myklebust authored
commit ff041727 upstream. If the layout segment is still in use for a read or a write, we should not move it to the layout plh_return_segs list. If we do, we can end up returning the layout while I/O is still in progress. Fixes: e0b7d420 ("pNFS: Don't discard layout segments that are marked for return") Cc: stable@vger.kernel.org # v4.19+ Signed-off-by:
-
Jens Axboe authored
commit d4e7cd36 upstream. There's a bit of confusion on the matching pairs of poll vs double poll, depending on if the request is a pure poll (IORING_OP_POLL_ADD) or poll driven retry. Add io_poll_get_double() that returns the double poll waitqueue, if any, and io_poll_get_single() that returns the original poll waitqueue. With that, remove the argument to io_poll_remove_double(). Finally ensure that wait->private is cleared once the double poll handler has run, so that remove knows it's already been seen. Cc: stable@vger.kernel.org # v5.8 Reported-by:
<syzbot+7f617d4a9369028b8a2c@syzkaller.appspotmail.com> Fixes: 18bceab1 ("io_uring: allow POLL_ADD with double poll_wait() users") Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jens Axboe authored
commit a36da65c upstream. Check the ipt.error value, it must have been either cleared to zero or set to another error than the default -EINVAL if we don't go through the waitqueue proc addition. Just give up on poll at that point and return failure, this will fallback to async work. io_poll_add() doesn't suffer from this failure case, as it returns the error value directly. Cc: stable@vger.kernel.org # v5.7+ Reported-by:
<syzbot+a730016dc0bdce4f6ff5@syzkaller.appspotmail.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Jens Axboe authored
commit 0ba9c9ed upstream. An earlier commit: b7db41c9 ("io_uring: fix regression with always ignoring signals in io_cqring_wait()") ensured that we didn't get stuck waiting for eventfd reads when it's registered with the io_uring ring for event notification, but we still have cases where the task can be waiting on other events in the kernel and need a bigger nudge to make forward progress. Or the task could be in the kernel and running, but on its way to blocking. This means that TWA_RESUME cannot reliably be used to ensure we make progress. Use TWA_SIGNAL unconditionally. Cc: stable@vger.kernel.org # v5.7+ Reported-by:
Josef <josef.grieb@gmail.com> Signed-off-by:
-
Jens Axboe authored
commit bd740481 upstream. If we hit an earlier error path in io_uring_create(), then we will have accounted memory, but not set ctx->{sq,cq}_entries yet. Then when the ring is torn down in error, we use those values to unaccount the memory. Ensure we set the ctx entries before we're able to hit a potential error path. Cc: stable@vger.kernel.org Reported-by:
Tomáš Chaloupka <chalucha@gmail.com> Tested-by:
-
Dave Airlie authored
commit 5de5b6ec upstream. This is confusing, and from my reading of all the drivers only nouveau got this right. Just make the API act under driver control of it's own allocation failing, and don't call destroy, if the page table fails to create there is nothing to cleanup here. (I'm willing to believe I've missed something here, so please review deeply). Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200728041736.20689-1-airlied@gmail.com Signed-off-by:
-
Tuomas Tynkkynen authored
commit e30cc79c upstream. Syzbot reports a NULL-ptr deref in the kref_put() call: BUG: KASAN: null-ptr-deref in media_request_put drivers/media/mc/mc-request.c:81 [inline] kref_put include/linux/kref.h:64 [inline] media_request_put drivers/media/mc/mc-request.c:81 [inline] media_request_close+0x4d/0x170 drivers/media/mc/mc-request.c:89 __fput+0x2ed/0x750 fs/file_table.c:281 task_work_run+0x147/0x1d0 kernel/task_work.c:123 tracehook_notify_resume include/linux/tracehook.h:188 [inline] exit_to_usermode_loop arch/x86/entry/common.c:165 [inline] prepare_exit_to_usermode+0x48e/0x600 arch/x86/entry/common.c:196 What led to this crash was an injected memory allocation failure in media_request_alloc(): FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 should_failslab+0x5/0x20 kmem_cache_alloc_trace+0x57/0x300 ? anon_inode_getfile+0xe5/0x170 media_request_alloc+0x339/0x440 media_device_request_alloc+0x94/0xc0 media_device_ioctl+0x1fb/0x330 ? do_vfs_ioctl+0x6ea/0x1a00 ? media_ioctl+0x101/0x120 ? __media_device_usb_init+0x430/0x430 ? media_poll+0x110/0x110 __se_sys_ioctl+0xf9/0x160 do_syscall_64+0xf3/0x1b0 When that allocation fails, filp->private_data is left uninitialized which media_request_close() does not expect and crashes. To avoid this, reorder media_request_alloc() such that allocating the struct file happens as the last step thus media_request_close() will no longer get called for a partially created media request. Reported-by:
<syzbot+6bed2d543cf7e48b822b@syzkaller.appspotmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi> Fixes: 10905d70 ("media: media-request: implement media requests") Reviewed-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Tetsuo Handa authored
commit b292b50b upstream. syzbot is reporting hung task in wait_for_device_probe() [1]. At least, we always need to decrement probe_count if we incremented probe_count in really_probe(). However, since I can't find "Resources present before probing" message in the console log, both "this message simply flowed off" and "syzbot is not hitting this path" will be possible. Therefore, while we are at it, let's also prepare for concurrent wait_for_device_probe() calls by replacing wake_up() with wake_up_all(). [1] https://syzkaller.appspot.com/bug?id=25c833f1983c9c1d512f4ff860dd0d7f5a2e2c0f Reported-by:
syzbot <syzbot+805f5f6ae37411f15b64@syzkaller.appspotmail.com> Fixes: 7c35e699 ("driver core: Print device when resources present in really_probe()") Cc: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20200713021254.3444-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by:
-
Zheng Bin authored
commit cb0aae0e upstream. v9fs_mount v9fs_session_init v9fs_cache_session_get_cookie v9fs_random_cachetag -->alloc cachetag v9ses->fscache = fscache_acquire_cookie -->maybe NULL sb = sget -->fail, goto clunk clunk_fid: v9fs_session_close if (v9ses->fscache) -->NULL kfree(v9ses->cachetag) Thus memleak happens. Link: http://lkml.kernel.org/r/20200615012153.89538-1-zhengbin13@huawei.com Fixes: 60e78d2c ("9p: Add fscache support to 9p") Cc: <stable@vger.kernel.org> # v2.6.32+ Signed-off-by:
Zheng Bin <zhengbin13@huawei.com> Signed-off-by:
Dominique Martinet <asmadeus@codewreck.org> Signed-off-by:
-
Maxim Levitsky authored
commit 841c2be0 upstream. To avoid complex and in some cases incorrect logic in kvm_spec_ctrl_test_value, just try the guest's given value on the host processor instead, and if it doesn't #GP, allow the guest to set it. One such case is when host CPU supports STIBP mitigation but doesn't support IBRS (as is the case with some Zen2 AMD cpus), and in this case we were giving guest #GP when it tried to use STIBP The reason why can can do the host test is that IA32_SPEC_CTRL msr is passed to the guest, after the guest sets it to a non zero value for the first time (due to performance reasons), and as as result of this, it is pointless to emulate #GP condition on this first access, in a different way than what the host CPU does. This is based on a patch from Sean Christopherson, who suggested this idea. Fixes: 6441fa61 ("KVM: x86: avoid incorrect writes to host MSR_IA32_SPEC_CTRL") Cc: stable@vger.kernel.org Suggested-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20200708115731.180097-1-mlevitsk@redhat.com> Signed-off-by:
-
Eric Biggers authored
commit 270ef410 upstream. If the minix filesystem tries to map a very large logical block number to its on-disk location, block_to_path() can return offsets that are too large, causing out-of-bounds memory accesses when accessing indirect index blocks. This should be prevented by the check against the maximum file size, but this doesn't work because the maximum file size is read directly from the on-disk superblock and isn't validated itself. Fix this by validating the maximum file size at mount time. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
<syzbot+c7d9ec7a1a7272dd71b3@syzkaller.appspotmail.com> Reported-by:
<syzbot+3b7b03a0c28948054fb5@syzkaller.appspotmail.com> Reported-by:
<syzbot+6e056ee473568865f3e6@syzkaller.appspotmail.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
-
Eric Biggers authored
commit facb03dd upstream. If an inode has no links, we need to mark it bad rather than allowing it to be accessed. This avoids WARNINGs in inc_nlink() and drop_nlink() when doing directory operations on a fuzzed filesystem. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
<syzbot+a9ac3de1b5de5fb10efc@syzkaller.appspotmail.com> Reported-by:
<syzbot+df958cf5688a96ad3287@syzkaller.appspotmail.com> Signed-off-by:
-
Eric Biggers authored
commit da27e0a0 upstream. Patch series "fs/minix: fix syzbot bugs and set s_maxbytes". This series fixes all syzbot bugs in the minix filesystem: KASAN: null-ptr-deref Write in get_block KASAN: use-after-free Write in get_block KASAN: use-after-free Read in get_block WARNING in inc_nlink KMSAN: uninit-value in get_block WARNING in drop_nlink It also fixes the minix filesystem to set s_maxbytes correctly, so that userspace sees the correct behavior when exceeding the max file size. This patch (of 6): sb_getblk() can fail, so check its return value. This fixes a NULL pointer dereference. Originally from Qiujun Huang. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
<syzbot+4a88b2b9dc280f47baf4@syzkaller.appspotmail.com> Signed-off-by:
-
Jakub Kicinski authored
commit 444da3f5 upstream. When ur_load_imm_any() is inlined into jeq_imm(), it's possible for the compiler to deduce a case where _val can only have the value of -1 at compile time. Specifically, /* struct bpf_insn: _s32 imm */ u64 imm = insn->imm; /* sign extend */ if (imm >> 32) { /* non-zero only if insn->imm is negative */ /* inlined from ur_load_imm_any */ u32 __imm = imm >> 32; /* therefore, always 0xffffffff */ if (__builtin_constant_p(__imm) && __imm > 255) compiletime_assert_XXX() This can result in tripping a BUILD_BUG_ON() in __BF_FIELD_CHECK() that checks that a given value is representable in one byte (interpreted as unsigned). FIELD_FIT() should return true or false at runtime for whether a value can fit for not. Don't break the build over a value that's too large for the mask. We'd prefer to keep the inlining and compiler optimizations though we know this case will always return false. Cc: stable@vger.kernel.org Fixes: 1697599e ("bitfield.h: add FIELD_FIT() helper") Link: https://lore.kernel.org/kernel-hardening/CAK7LNASvb0UDJ0U5wkYYRzTAdnEs64HjXpEUL7d=V0CXiAXcNw@mail.gmail.com/ Reported-by:
Masahiro Yamada <masahiroy@kernel.org> Debugged-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Frederic Weisbecker authored
commit 3c8920e2 upstream. Setting a tick dependency on any task, including the case where a task sets that dependency on itself, triggers an IPI to all CPUs. That is of course suboptimal but it had previously not been an issue because it was only used by POSIX CPU timers on nohz_full, which apparently never occurs in latency-sensitive workloads in production. (Or users of such systems are suffering in silence on the one hand or venting their ire on the wrong people on the other.) But RCU now sets a task tick dependency on the current task in order to fix stall issues that can occur during RCU callback processing. Thus, RCU callback processing triggers frequent system-wide IPIs from nohz_full CPUs. This is quite counter-productive, after all, avoiding IPIs is what nohz_full is supposed to be all about. This commit therefore optimizes tasks' self-setting of a task tick dependency by using tick_nohz_full_kick() to avoid the system-wide IPI. Instead, only the execution of the one task is disturbed, which is acceptable given that this disturbance is well down into the noise compared to the degree to which the RCU callback processing itself disturbs execution. Fixes: 6a949b7a (rcu: Force on tick when invoking lots of callbacks) Reported-by:
Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by:
Frederic Weisbecker <frederic@kernel.org> Cc: stable@kernel.org Cc: Paul E. McKenney <paulmck@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
-
Mikulas Patocka authored
commit 9e27c991 upstream. There is this call chain: cvm_encrypt -> cvm_enc_dec -> cptvf_do_request -> process_request -> kzalloc where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP was not specified. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org # v4.11+ Fixes: c694b233 ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
John Allen authored
commit 8a302808 upstream. Running the crypto manager self tests with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS may result in several types of errors when using the ccp-crypto driver: alg: skcipher: cbc-des3-ccp encryption failed on test vector 0; expected_error=0, actual_error=-5 ... alg: skcipher: ctr-aes-ccp decryption overran dst buffer on test vector 0 ... alg: ahash: sha224-ccp test failed (wrong result) on test vector ... These errors are the result of improper processing of scatterlists mapped for DMA. Given a scatterlist in which entries are merged as part of mapping the scatterlist for DMA, the DMA length of a merged entry will reflect the combined length of the entries that were merged. The subsequent scatterlist entry will contain DMA information for the scatterlist entry after the last merged entry, but the non-DMA information will be that of the first merged entry. The ccp driver does not take this scatterlist merging into account. To address this, add a second scatterlist pointer to track the current position in the DMA mapped representation of the scatterlist. Both the DMA representation and the original representation of the scatterlist must be tracked as while most of the driver can use just the DMA representation, scatterlist_map_and_copy() must use the original representation and expects the scatterlist pointer to be accurate to the original representation. In order to properly walk the original scatterlist, the scatterlist must be walked until the combined lengths of the entries seen is equal to the DMA length of the current entry being processed in the DMA mapped representation. Fixes: 63b94509 ("crypto: ccp - CCP device driver and interface support") Signed-off-by:
John Allen <john.allen@amd.com> Cc: stable@vger.kernel.org Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Tom Rix authored
commit c06c7660 upstream. clang static analysis flags this error qat_uclo.c:297:3: warning: Attempt to free released memory [unix.Malloc] kfree(*init_tab_base); ^~~~~~~~~~~~~~~~~~~~~ When input *init_tab_base is null, the function allocates memory for the head of the list. When there is problem allocating other list elements the list is unwound and freed. Then a check is made if the list head was allocated and is also freed. Keeping track of the what may need to be freed is the variable 'tail_old'. The unwinding/freeing block is while (tail_old) { mem_init = tail_old->next; kfree(tail_old); tail_old = mem_init; } The problem is that the first element of tail_old is also what was allocated for the list head init_header = kzalloc(sizeof(*init_header), GFP_KERNEL); ... *init_tab_base = init_header; flag = 1; } tail_old = init_header; So *init_tab_base/init_header are freed twice. There is another problem. When the input *init_tab_base is non null the tail_old is calculated by traveling down the list to first non null entry. tail_old = init_header; while (tail_old->next) tail_old = tail_old->next; When the unwinding free happens, the last entry of the input list will be freed. So the freeing needs a general changed. If locally allocated the first element of tail_old is freed, else it is skipped. As a bit of cleanup, reset *init_tab_base if it came in as null. Fixes: b4b7e67c ("crypto: qat - Intel(R) QAT ucode part of fw loader") Cc: <stable@vger.kernel.org> Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 5ead0517 upstream. There is this call chain: sec_alg_skcipher_encrypt -> sec_alg_skcipher_crypto -> sec_alg_alloc_and_calc_split_sizes -> kcalloc where we call sleeping allocator function even if CRYPTO_TFM_REQ_MAY_SLEEP was not specified. Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Matteo Croce authored
commit fd49e032 upstream. When building a kernel with CONFIG_PSTORE=y and CONFIG_CRYPTO not set, a build error happens: ld: fs/pstore/platform.o: in function `pstore_dump': platform.c:(.text+0x3f9): undefined reference to `crypto_comp_compress' ld: fs/pstore/platform.o: in function `pstore_get_backend_records': platform.c:(.text+0x784): undefined reference to `crypto_comp_decompress' This because some pstore code uses crypto_comp_(de)compress regardless of the CONFIG_CRYPTO status. Fix it by wrapping the (de)compress usage by IS_ENABLED(CONFIG_PSTORE_COMPRESS) Signed-off-by:
Matteo Croce <mcroce@linux.microsoft.com> Link: https://lore.kernel.org/lkml/20200706234045.9516-1-mcroce@linux.microsoft.com Fixes: cb3bee03 ("pstore: Use crypto compress API") Cc: stable@vger.kernel.org Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Jarkko Sakkinen authored
commit 6c4e79d9 upstream. The size of the buffers for storing context's and sessions can vary from arch to arch as PAGE_SIZE can be anything between 4 kB and 256 kB (the maximum for PPC64). Define a fixed buffer size set to 16 kB. This should be enough for most use with three handles (that is how many we allow at the moment). Parametrize the buffer size while doing this, so that it is easier to revisit this later on if required. Cc: stable@vger.kernel.org Reported-by:
Stefan Berger <stefanb@linux.ibm.com> Fixes: 745b361e ("tpm: infrastructure for TPM spaces") Reviewed-by:
Jerry Snitselaar <jsnitsel@redhat.com> Tested-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Hector Martin authored
commit 6e859617 upstream. This is just another Pioneer device with fixed endpoints. Input is dummy but used as feedback (it always returns silence). Cc: stable@vger.kernel.org Signed-off-by:
Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20200810082502.225979-1-marcan@marcan.st Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hector Martin authored
commit 1b7ecc24 upstream. Further investigation of the L-R swap problem on the MS2109 reveals that the problem isn't that the channels are swapped, but rather that they are swapped and also out of phase by one sample. In other words, the issue is actually that the very first frame that comes from the hardware is a half-frame containing only the right channel, and after that everything becomes offset. So introduce a new quirk field to drop the very first 2 bytes that come in after the format is configured and a capture stream starts. This puts the channels in phase and in the correct order. Cc: stable@vger.kernel.org Signed-off-by:
-
Hector Martin authored
commit 14a720dc upstream. Matching by device matches all interfaces, which breaks the video/HID portions of the device depending on module load order. Fixes: e337bf19 ("ALSA: usb-audio: add quirk for MacroSilicon MS2109") Cc: stable@vger.kernel.org Signed-off-by:
-
