user/sven/linux.git, branch v4.19.176

Linux 4.19.176

2021-02-13T12:51:16Z

Tested-by: Jason Self Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Pavel Machek (CIP) Tested-by: Ross Schmidt Link: https://lore.kernel.org/r/20210212074240.963766197@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

regulator: Fix lockdep warning resolving supplies

2021-02-13T12:51:16Z

[ Upstream commit 14a71d509ac809dcf56d7e3ca376b15d17bd0ddd ] With commit eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) we started holding the rdev lock while resolving supplies, an operation that requires holding the regulator_list_mutex. This results in lockdep warnings since in other places we take the list mutex then the mutex on an individual rdev. Since the goal is to make sure that we don't call set_supply() twice rather than a concern about the cost of resolution pull the rdev lock and check for duplicate resolution down to immediately before we do the set_supply() and drop it again once the allocation is done. Fixes: eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race condition) Reported-by: Marek Szyprowski Tested-by: Marek Szyprowski Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210122132042.10306-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: Clean enabling always-on regulators + their supplies

2021-02-13T12:51:15Z

[ Upstream commit 05f224ca669398b567d09feb6e2ceefcb7d7f945 ] At the end of regulator_resolve_supply() we have historically turned on our supply in some cases. This could be for one of two reasons: 1. If resolving supplies was happening before the call to set_machine_constraints() we needed to predict if set_machine_constraints() was going to turn the regulator on and we needed to preemptively turn the supply on. 2. Maybe set_machine_constraints() happened before we could resolve supplies (because we failed the first time to resolve) and thus we might need to propagate an enable that already happened up to our supply. Historically regulator_resolve_supply() used _regulator_is_enabled() to decide whether to turn on the supply. Let's change things a little bit. Specifically: 1. Let's try to enable the supply and the regulator in the same place, both in set_machine_constraints(). This means that we have exactly the same logic for enabling the supply and the regulator. 2. Let's properly set use_count when we enable always-on or boot-on regulators even for those that don't have supplies. The previous commit 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible") only did this right for regulators with supplies. 3. Let's make it clear that the only time we need to enable the supply in regulator_resolve_supply() is if the main regulator is currently in use. By using use_count (like the rest of the code) to decide if we're going to enable our supply we keep everything consistent. Overall the new scheme should be cleaner and easier to reason about. In addition to fixing regulator_summary to be more correct (because of the more correct use_count), this change also has the effect of no longer using _regulator_is_enabled() in this code path. _regulator_is_enabled() could return an error code for some regulators at bootup (like RPMh) that can't read their initial state. While one can argue that the design of those regulators is sub-optimal, the new logic sidesteps this brokenness. This fix in particular fixes observed problems on Qualcomm sdm845 boards which use the above-mentioned RPMh regulator. Those problems were made worse by commit 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible") because now we'd think at bootup that the SD regulators were already enabled and we'd never try them again. Fixes: 1fc12b05895e ("regulator: core: Avoid propagating to supplies when possible") Reported-by: Evan Green Signed-off-by: Douglas Anderson Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: core: enable power when setting up constraints

2021-02-13T12:51:15Z

[ Upstream commit 2bb1666369339f69f227ad060c250afde94d5c69 ] When a regulator is marked as always on, it is enabled early on, when checking and setting up constraints. It makes the assumption that the bootloader properly initialized the regulator, and just in case enables the regulator anyway. Some constraints however currently get missed, such as the soft-start and ramp-delay. This causes the regulator to be enabled, without the soft-start and ramp-delay being applied, which in turn can cause high-currents or other start-up problems. By moving the always-enabled constraints later in the constraints check, we can at least ensure all constraints for the regulator are followed. Signed-off-by: Olliver Schinagl Signed-off-by: Priit Laes Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

squashfs: add more sanity checks in xattr id lookup

2021-02-13T12:51:15Z

commit 506220d2ba21791314af569211ffd8870b8208fa upstream. Sysbot has reported a warning where a kmalloc() attempt exceeds the maximum limit. This has been identified as corruption of the xattr_ids count when reading the xattr id lookup table. This patch adds a number of additional sanity checks to detect this corruption and others. 1. It checks for a corrupted xattr index read from the inode. This could be because the metadata block is uncompressed, or because the "compression" bit has been corrupted (turning a compressed block into an uncompressed block). This would cause an out of bounds read. 2. It checks against corruption of the xattr_ids count. This can either lead to the above kmalloc failure, or a smaller than expected table to be read. 3. It checks the contents of the index table for corruption. [phillip@squashfs.org.uk: fix checkpatch issue] Link: https://lkml.kernel.org/r/270245655.754655.1612770082682@webmail.123-reg.co.uk Link: https://lkml.kernel.org/r/20210204130249.4495-5-phillip@squashfs.org.uk Signed-off-by: Phillip Lougher Reported-by: syzbot+2ccea6339d368360800d@syzkaller.appspotmail.com Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

squashfs: add more sanity checks in inode lookup

2021-02-13T12:51:15Z

commit eabac19e40c095543def79cb6ffeb3a8588aaff4 upstream. Sysbot has reported an "slab-out-of-bounds read" error which has been identified as being caused by a corrupted "ino_num" value read from the inode. This could be because the metadata block is uncompressed, or because the "compression" bit has been corrupted (turning a compressed block into an uncompressed block). This patch adds additional sanity checks to detect this, and the following corruption. 1. It checks against corruption of the inodes count. This can either lead to a larger table to be read, or a smaller than expected table to be read. In the case of a too large inodes count, this would often have been trapped by the existing sanity checks, but this patch introduces a more exact check, which can identify too small values. 2. It checks the contents of the index table for corruption. [phillip@squashfs.org.uk: fix checkpatch issue] Link: https://lkml.kernel.org/r/527909353.754618.1612769948607@webmail.123-reg.co.uk Link: https://lkml.kernel.org/r/20210204130249.4495-4-phillip@squashfs.org.uk Signed-off-by: Phillip Lougher Reported-by: syzbot+04419e3ff19d2970ea28@syzkaller.appspotmail.com Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

squashfs: add more sanity checks in id lookup

2021-02-13T12:51:15Z

commit f37aa4c7366e23f91b81d00bafd6a7ab54e4a381 upstream. Sysbot has reported a number of "slab-out-of-bounds reads" and "use-after-free read" errors which has been identified as being caused by a corrupted index value read from the inode. This could be because the metadata block is uncompressed, or because the "compression" bit has been corrupted (turning a compressed block into an uncompressed block). This patch adds additional sanity checks to detect this, and the following corruption. 1. It checks against corruption of the ids count. This can either lead to a larger table to be read, or a smaller than expected table to be read. In the case of a too large ids count, this would often have been trapped by the existing sanity checks, but this patch introduces a more exact check, which can identify too small values. 2. It checks the contents of the index table for corruption. Link: https://lkml.kernel.org/r/20210204130249.4495-3-phillip@squashfs.org.uk Signed-off-by: Phillip Lougher Reported-by: syzbot+b06d57ba83f604522af2@syzkaller.appspotmail.com Reported-by: syzbot+c021ba012da41ee9807c@syzkaller.appspotmail.com Reported-by: syzbot+5024636e8b5fd19f0f19@syzkaller.appspotmail.com Reported-by: syzbot+bcbc661df46657d0fa4f@syzkaller.appspotmail.com Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

blk-mq: don't hold q->sysfs_lock in blk_mq_map_swqueue

2021-02-13T12:51:15Z

commit c6ba933358f0d7a6a042b894dba20cc70396a6d3 upstream. blk_mq_map_swqueue() is called from blk_mq_init_allocated_queue() and blk_mq_update_nr_hw_queues(). For the former caller, the kobject isn't exposed to userspace yet. For the latter caller, hctx sysfs entries and debugfs are un-registered before updating nr_hw_queues. On the other hand, commit 2f8f1336a48b ("blk-mq: always free hctx after request queue is freed") moves freeing hctx into queue's release handler, so there won't be race with queue release path too. So don't hold q->sysfs_lock in blk_mq_map_swqueue(). Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Greg KH Cc: Mike Snitzer Cc: Bart Van Assche Reviewed-by: Bart Van Assche Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Jack Wang Signed-off-by: Greg Kroah-Hartman

block: don't hold q->sysfs_lock in elevator_init_mq

2021-02-13T12:51:15Z

commit c48dac137a62a5d6fa1ef3fa445cbd9c43655a76 upstream. The original comment says: q->sysfs_lock must be held to provide mutual exclusion between elevator_switch() and here. Which is simply wrong. elevator_init_mq() is only called from blk_mq_init_allocated_queue, which is always called before the request queue is registered via blk_register_queue(), for dm-rq or normal rq based driver. However, queue's kobject is only exposed and added to sysfs in blk_register_queue(). So there isn't such race between elevator_switch() and elevator_init_mq(). So avoid to hold q->sysfs_lock in elevator_init_mq(). Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Greg KH Cc: Mike Snitzer Cc: Bart Van Assche Cc: Damien Le Moal Reviewed-by: Bart Van Assche Signed-off-by: Ming Lei Signed-off-by: Jens Axboe Signed-off-by: Jack Wang Signed-off-by: Greg Kroah-Hartman

Fix unsynchronized access to sev members through svm_register_enc_region

2021-02-13T12:51:15Z

commit 19a23da53932bc8011220bd8c410cb76012de004 upstream. Grab kvm->lock before pinning memory when registering an encrypted region; sev_pin_memory() relies on kvm->lock being held to ensure correctness when checking and updating the number of pinned pages. Add a lockdep assertion to help prevent future regressions. Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Paolo Bonzini Cc: Joerg Roedel Cc: Tom Lendacky Cc: Brijesh Singh Cc: Sean Christopherson Cc: x86@kernel.org Cc: kvm@vger.kernel.org Cc: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org Fixes: 1e80fdc09d12 ("KVM: SVM: Pin guest memory when SEV is active") Signed-off-by: Peter Gonda V2 - Fix up patch description - Correct file paths svm.c -> sev.c - Add unlock of kvm->lock on sev_pin_memory error V1 - https://lore.kernel.org/kvm/20210126185431.1824530-1-pgonda@google.com/ Message-Id: <20210127161524.2832400-1-pgonda@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman