commit 255b58a2b3af0baa0ee11507390349217b8b73b0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sat Feb 13 13:51:16 2021 +0100

    Linux 4.19.176
    
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Ross Schmidt <ross.schm.dev@gmail.com>
    Link: https://lore.kernel.org/r/20210212074240.963766197@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9dcaae42b61d8106056f027c4a09f443af0a6c7f
Author: Mark Brown <broonie@kernel.org>
Date:   Fri Jan 22 13:20:42 2021 +0000

    regulator: Fix lockdep warning resolving supplies
    
    [ 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 <m.szyprowski@samsung.com>
    Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Link: https://lore.kernel.org/r/20210122132042.10306-1-broonie@kernel.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45f9c1b2e57cb06b732dc21fda6e47477e802233
Author: Douglas Anderson <dianders@chromium.org>
Date:   Thu Dec 6 14:23:18 2018 -0800

    regulator: core: Clean enabling always-on regulators + their supplies
    
    [ 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 <evgreen@chromium.org>
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cb19da4d5ccfa731bf5dd17e6161b6d7d1b32cbe
Author: Olliver Schinagl <oliver@schinagl.nl>
Date:   Mon Nov 26 17:27:44 2018 +0200

    regulator: core: enable power when setting up constraints
    
    [ 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 <oliver@schinagl.nl>
    Signed-off-by: Priit Laes <plaes@plaes.org>
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a8717b34003f4f7353b23826617ad872f85d85d8
Author: Phillip Lougher <phillip@squashfs.org.uk>
Date:   Tue Feb 9 13:42:00 2021 -0800

    squashfs: add more sanity checks in xattr id lookup
    
    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 <phillip@squashfs.org.uk>
    Reported-by: syzbot+2ccea6339d368360800d@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a6f933a3036313a3c4b56c68eccbf84d7546b49e
Author: Phillip Lougher <phillip@squashfs.org.uk>
Date:   Tue Feb 9 13:41:56 2021 -0800

    squashfs: add more sanity checks in inode lookup
    
    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 <phillip@squashfs.org.uk>
    Reported-by: syzbot+04419e3ff19d2970ea28@syzkaller.appspotmail.com
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e5099c0e851a801d04831db64d140bd4f3a014db
Author: Phillip Lougher <phillip@squashfs.org.uk>
Date:   Tue Feb 9 13:41:53 2021 -0800

    squashfs: add more sanity checks in id lookup
    
    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 <phillip@squashfs.org.uk>
    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: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ff18507a7c165b90f1fe51822c65d10265f5714
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Aug 27 19:01:46 2019 +0800

    blk-mq: don't hold q->sysfs_lock in blk_mq_map_swqueue
    
    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 <hch@infradead.org>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 44b07600cec4df051b7ecbd6831febdeca252e54
Author: Ming Lei <ming.lei@redhat.com>
Date:   Tue Aug 27 19:01:45 2019 +0800

    block: don't hold q->sysfs_lock in elevator_init_mq
    
    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 <hch@infradead.org>
    Cc: Hannes Reinecke <hare@suse.com>
    Cc: Greg KH <gregkh@linuxfoundation.org>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Cc: Damien Le Moal <damien.lemoal@wdc.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f1ecde00ce1694597f923f0d25f7a797c5243d99
Author: Peter Gonda <pgonda@google.com>
Date:   Wed Jan 27 08:15:24 2021 -0800

    Fix unsynchronized access to sev members through svm_register_enc_region
    
    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 <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Tom Lendacky <thomas.lendacky@amd.com>
    Cc: Brijesh Singh <brijesh.singh@amd.com>
    Cc: Sean Christopherson <seanjc@google.com>
    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 <pgonda@google.com>
    
    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 <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 050462f040b9cdb92b63f35aca76c6c873b0b5ab
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Thu Jan 30 22:11:04 2020 -0800

    memcg: fix a crash in wb_workfn when a device disappears
    
    [ Upstream commit 68f23b89067fdf187763e75a56087550624fdbee ]
    
    Without memcg, there is a one-to-one mapping between the bdi and
    bdi_writeback structures.  In this world, things are fairly
    straightforward; the first thing bdi_unregister() does is to shutdown
    the bdi_writeback structure (or wb), and part of that writeback ensures
    that no other work queued against the wb, and that the wb is fully
    drained.
    
    With memcg, however, there is a one-to-many relationship between the bdi
    and bdi_writeback structures; that is, there are multiple wb objects
    which can all point to a single bdi.  There is a refcount which prevents
    the bdi object from being released (and hence, unregistered).  So in
    theory, the bdi_unregister() *should* only get called once its refcount
    goes to zero (bdi_put will drop the refcount, and when it is zero,
    release_bdi gets called, which calls bdi_unregister).
    
    Unfortunately, del_gendisk() in block/gen_hd.c never got the memo about
    the Brave New memcg World, and calls bdi_unregister directly.  It does
    this without informing the file system, or the memcg code, or anything
    else.  This causes the root wb associated with the bdi to be
    unregistered, but none of the memcg-specific wb's are shutdown.  So when
    one of these wb's are woken up to do delayed work, they try to
    dereference their wb->bdi->dev to fetch the device name, but
    unfortunately bdi->dev is now NULL, thanks to the bdi_unregister()
    called by del_gendisk().  As a result, *boom*.
    
    Fortunately, it looks like the rest of the writeback path is perfectly
    happy with bdi->dev and bdi->owner being NULL, so the simplest fix is to
    create a bdi_dev_name() function which can handle bdi->dev being NULL.
    This also allows us to bulletproof the writeback tracepoints to prevent
    them from dereferencing a NULL pointer and crashing the kernel if one is
    tracing with memcg's enabled, and an iSCSI device dies or a USB storage
    stick is pulled.
    
    The most common way of triggering this will be hotremoval of a device
    while writeback with memcg enabled is going on.  It was triggering
    several times a day in a heavily loaded production environment.
    
    Google Bug Id: 145475544
    
    Link: https://lore.kernel.org/r/20191227194829.150110-1-tytso@mit.edu
    Link: http://lkml.kernel.org/r/20191228005211.163952-1-tytso@mit.edu
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: Chris Mason <clm@fb.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d3fcb6d76c4fb3d2c335cc78f982f3bd3de9e66f
Author: Qian Cai <cai@lca.pw>
Date:   Wed Sep 25 16:46:16 2019 -0700

    include/trace/events/writeback.h: fix -Wstringop-truncation warnings
    
    [ Upstream commit d1a445d3b86c9341ce7a0954c23be0edb5c9bec5 ]
    
    There are many of those warnings.
    
    In file included from ./arch/powerpc/include/asm/paca.h:15,
                     from ./arch/powerpc/include/asm/current.h:13,
                     from ./include/linux/thread_info.h:21,
                     from ./include/asm-generic/preempt.h:5,
                     from ./arch/powerpc/include/generated/asm/preempt.h:1,
                     from ./include/linux/preempt.h:78,
                     from ./include/linux/spinlock.h:51,
                     from fs/fs-writeback.c:19:
    In function 'strncpy',
        inlined from 'perf_trace_writeback_page_template' at
    ./include/trace/events/writeback.h:56:1:
    ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified
    bound 32 equals destination size [-Wstringop-truncation]
      return __builtin_strncpy(p, q, size);
             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    Fix it by using the new strscpy_pad() which was introduced in "lib/string:
    Add strscpy_pad() function" and will always be NUL-terminated instead of
    strncpy().  Also, change strlcpy() to use strscpy_pad() in this file for
    consistency.
    
    Link: http://lkml.kernel.org/r/1564075099-27750-1-git-send-email-cai@lca.pw
    Fixes: 455b2864686d ("writeback: Initial tracing support")
    Fixes: 028c2dd184c0 ("writeback: Add tracing to balance_dirty_pages")
    Fixes: e84d0a4f8e39 ("writeback: trace event writeback_queue_io")
    Fixes: b48c104d2211 ("writeback: trace event bdi_dirty_ratelimit")
    Fixes: cc1676d917f3 ("writeback: Move requeueing when I_SYNC set to writeback_sb_inodes()")
    Fixes: 9fb0a7da0c52 ("writeback: add more tracepoints")
    Signed-off-by: Qian Cai <cai@lca.pw>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: Tobin C. Harding <tobin@kernel.org>
    Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Dave Chinner <dchinner@redhat.com>
    Cc: Fengguang Wu <fengguang.wu@intel.com>
    Cc: Jens Axboe <axboe@kernel.dk>
    Cc: Joe Perches <joe@perches.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Jann Horn <jannh@google.com>
    Cc: Jonathan Corbet <corbet@lwn.net>
    Cc: Nitin Gote <nitin.r.gote@intel.com>
    Cc: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
    Cc: Stephen Kitt <steve@sk2.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 2a3687034e47c51cd4f01ce82ed16f1964008b9e
Author: Tobin C. Harding <tobin@kernel.org>
Date:   Fri Apr 5 12:58:58 2019 +1100

    lib/string: Add strscpy_pad() function
    
    [ Upstream commit 458a3bf82df4fe1f951d0f52b1e0c1e9d5a88a3b ]
    
    We have a function to copy strings safely and we have a function to copy
    strings and zero the tail of the destination (if source string is
    shorter than destination buffer) but we do not have a function to do
    both at once.  This means developers must write this themselves if they
    desire this functionality.  This is a chore, and also leaves us open to
    off by one errors unnecessarily.
    
    Add a function that calls strscpy() then memset()s the tail to zero if
    the source string is shorter than the destination buffer.
    
    Acked-by: Kees Cook <keescook@chromium.org>
    Signed-off-by: Tobin C. Harding <tobin@kernel.org>
    Signed-off-by: Shuah Khan <shuah@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9848962bfb28515c476bcf34a8ec9655ccee08e4
Author: Dave Wysochanski <dwysocha@redhat.com>
Date:   Thu Jan 21 16:17:24 2021 -0500

    SUNRPC: Handle 0 length opaque XDR object data properly
    
    [ Upstream commit e4a7d1f7707eb44fd953a31dd59eff82009d879c ]
    
    When handling an auth_gss downcall, it's possible to get 0-length
    opaque object for the acceptor.  In the case of a 0-length XDR
    object, make sure simple_get_netobj() fills in dest->data = NULL,
    and does not continue to kmemdup() which will set
    dest->data = ZERO_SIZE_PTR for the acceptor.
    
    The trace event code can handle NULL but not ZERO_SIZE_PTR for a
    string, and so without this patch the rpcgss_context trace event
    will crash the kernel as follows:
    
    [  162.887992] BUG: kernel NULL pointer dereference, address: 0000000000000010
    [  162.898693] #PF: supervisor read access in kernel mode
    [  162.900830] #PF: error_code(0x0000) - not-present page
    [  162.902940] PGD 0 P4D 0
    [  162.904027] Oops: 0000 [#1] SMP PTI
    [  162.905493] CPU: 4 PID: 4321 Comm: rpc.gssd Kdump: loaded Not tainted 5.10.0 #133
    [  162.908548] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    [  162.910978] RIP: 0010:strlen+0x0/0x20
    [  162.912505] Code: 48 89 f9 74 09 48 83 c1 01 80 39 00 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 0f 1f 80 00 00 00 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 31
    [  162.920101] RSP: 0018:ffffaec900c77d90 EFLAGS: 00010202
    [  162.922263] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fffde697
    [  162.925158] RDX: 000000000000002f RSI: 0000000000000080 RDI: 0000000000000010
    [  162.928073] RBP: 0000000000000010 R08: 0000000000000e10 R09: 0000000000000000
    [  162.930976] R10: ffff8e698a590cb8 R11: 0000000000000001 R12: 0000000000000e10
    [  162.933883] R13: 00000000fffde697 R14: 000000010034d517 R15: 0000000000070028
    [  162.936777] FS:  00007f1e1eb93700(0000) GS:ffff8e6ab7d00000(0000) knlGS:0000000000000000
    [  162.940067] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  162.942417] CR2: 0000000000000010 CR3: 0000000104eba000 CR4: 00000000000406e0
    [  162.945300] Call Trace:
    [  162.946428]  trace_event_raw_event_rpcgss_context+0x84/0x140 [auth_rpcgss]
    [  162.949308]  ? __kmalloc_track_caller+0x35/0x5a0
    [  162.951224]  ? gss_pipe_downcall+0x3a3/0x6a0 [auth_rpcgss]
    [  162.953484]  gss_pipe_downcall+0x585/0x6a0 [auth_rpcgss]
    [  162.955953]  rpc_pipe_write+0x58/0x70 [sunrpc]
    [  162.957849]  vfs_write+0xcb/0x2c0
    [  162.959264]  ksys_write+0x68/0xe0
    [  162.960706]  do_syscall_64+0x33/0x40
    [  162.962238]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [  162.964346] RIP: 0033:0x7f1e1f1e57df
    
    Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b5c6efba2b0d35b0f8920d93c5510ea029d17976
Author: Dave Wysochanski <dwysocha@redhat.com>
Date:   Thu Jan 21 16:17:23 2021 -0500

    SUNRPC: Move simple_get_bytes and simple_get_netobj into private header
    
    [ Upstream commit ba6dfce47c4d002d96cd02a304132fca76981172 ]
    
    Remove duplicated helper functions to parse opaque XDR objects
    and place inside new file net/sunrpc/auth_gss/auth_gss_internal.h.
    In the new file carry the license and copyright from the source file
    net/sunrpc/auth_gss/auth_gss.c.  Finally, update the comment inside
    include/linux/sunrpc/xdr.h since lockd is not the only user of
    struct xdr_netobj.
    
    Signed-off-by: Dave Wysochanski <dwysocha@redhat.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45115259782a6b18566f378c8d9b16b25869444c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 22 14:52:41 2021 +0200

    iwlwifi: mvm: guard against device removal in reprobe
    
    [ Upstream commit 7a21b1d4a728a483f07c638ccd8610d4b4f12684 ]
    
    If we get into a problem severe enough to attempt a reprobe,
    we schedule a worker to do that. However, if the problem gets
    more severe and the device is actually destroyed before this
    worker has a chance to run, we use a free device. Bump up the
    reference count of the device until the worker runs to avoid
    this situation.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20210122144849.871f0892e4b2.I94819e11afd68d875f3e242b98bef724b8236f1e@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 182b4310af89bd8980976d60e4d290f4c6635ed9
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 15 13:05:56 2021 +0200

    iwlwifi: pcie: fix context info memory leak
    
    [ Upstream commit 2d6bc752cc2806366d9a4fd577b3f6c1f7a7e04e ]
    
    If the image loader allocation fails, we leak all the previously
    allocated memory. Fix this.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20210115130252.97172cbaa67c.I3473233d0ad01a71aa9400832fb2b9f494d88a11@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 896cf561fc605391eea05c0e5dd8b217c0c40bad
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date:   Fri Jan 15 13:05:55 2021 +0200

    iwlwifi: pcie: add a NULL check in iwl_pcie_txq_unmap
    
    [ Upstream commit 98c7d21f957b10d9c07a3a60a3a5a8f326a197e5 ]
    
    I hit a NULL pointer exception in this function when the
    init flow went really bad.
    
    Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20210115130252.2e8da9f2c132.I0234d4b8ddaf70aaa5028a20c863255e05bc1f84@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit dc64ebad85455ae43fa589687184c547fae1714d
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Jan 15 13:05:48 2021 +0200

    iwlwifi: mvm: take mutex for calling iwl_mvm_get_sync_time()
    
    [ Upstream commit 5c56d862c749669d45c256f581eac4244be00d4d ]
    
    We need to take the mutex to call iwl_mvm_get_sync_time(), do it.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/iwlwifi.20210115130252.4bb5ccf881a6.I62973cbb081e80aa5b0447a5c3b9c3251a65cf6b@changeid
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 682821d905f77005b1b85684608dfc75e75422a9
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Thu Jan 21 17:11:42 2021 -0500

    pNFS/NFSv4: Try to return invalid layout in pnfs_layout_process()
    
    [ Upstream commit 08bd8dbe88825760e953759d7ec212903a026c75 ]
    
    If the server returns a new stateid that does not match the one in our
    cache, then try to return the one we hold instead of just invalidating
    it on the client side. This ensures that both client and server will
    agree that the stateid is invalid.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6259963da5adcbbe4992412ccf8375bd380c5c72
Author: Pan Bian <bianpan2016@163.com>
Date:   Thu Jan 21 06:57:38 2021 -0800

    chtls: Fix potential resource leak
    
    [ Upstream commit b6011966ac6f402847eb5326beee8da3a80405c7 ]
    
    The dst entry should be released if no neighbour is found. Goto label
    free_dst to fix the issue. Besides, the check of ndev against NULL is
    redundant.
    
    Signed-off-by: Pan Bian <bianpan2016@163.com>
    Link: https://lore.kernel.org/r/20210121145738.51091-1-bianpan2016@163.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 1d915c56268fa214c94ef764df8bf31d1bd5f25b
Author: David Collins <collinsd@codeaurora.org>
Date:   Thu Jan 7 17:16:02 2021 -0800

    regulator: core: avoid regulator_resolve_supply() race condition
    
    [ Upstream commit eaa7995c529b54d68d97a30f6344cc6ca2f214a7 ]
    
    The final step in regulator_register() is to call
    regulator_resolve_supply() for each registered regulator
    (including the one in the process of being registered).  The
    regulator_resolve_supply() function first checks if rdev->supply
    is NULL, then it performs various steps to try to find the supply.
    If successful, rdev->supply is set inside of set_supply().
    
    This procedure can encounter a race condition if two concurrent
    tasks call regulator_register() near to each other on separate CPUs
    and one of the regulators has rdev->supply_name specified.  There
    is currently nothing guaranteeing atomicity between the rdev->supply
    check and set steps.  Thus, both tasks can observe rdev->supply==NULL
    in their regulator_resolve_supply() calls.  This then results in
    both creating a struct regulator for the supply.  One ends up
    actually stored in rdev->supply and the other is lost (though still
    present in the supply's consumer_list).
    
    Here is a kernel log snippet showing the issue:
    
    [   12.421768] gpu_cc_gx_gdsc: supplied by pm8350_s5_level
    [   12.425854] gpu_cc_gx_gdsc: supplied by pm8350_s5_level
    [   12.429064] debugfs: Directory 'regulator.4-SUPPLY' with parent
                   '17a00000.rsc:rpmh-regulator-gfxlvl-pm8350_s5_level'
                   already present!
    
    Avoid this race condition by holding the rdev->mutex lock inside
    of regulator_resolve_supply() while checking and setting
    rdev->supply.
    
    Signed-off-by: David Collins <collinsd@codeaurora.org>
    Link: https://lore.kernel.org/r/1610068562-4410-1-git-send-email-collinsd@codeaurora.org
    Signed-off-by: Mark Brown <broonie@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit fac13c1dd417f7d117c28d4929175c3b05820234
Author: Cong Wang <cong.wang@bytedance.com>
Date:   Sat Dec 26 16:50:20 2020 -0800

    af_key: relax availability checks for skb size calculation
    
    [ Upstream commit afbc293add6466f8f3f0c3d944d85f53709c170f ]
    
    xfrm_probe_algs() probes kernel crypto modules and changes the
    availability of struct xfrm_algo_desc. But there is a small window
    where ealg->available and aalg->available get changed between
    count_ah_combs()/count_esp_combs() and dump_ah_combs()/dump_esp_combs(),
    in this case we may allocate a smaller skb but later put a larger
    amount of data and trigger the panic in skb_put().
    
    Fix this by relaxing the checks when counting the size, that is,
    skipping the test of ->available. We may waste some memory for a few
    of sizeof(struct sadb_comb), but it is still much better than a panic.
    
    Reported-by: syzbot+b2bf2652983d23734c5c@syzkaller.appspotmail.com
    Cc: Steffen Klassert <steffen.klassert@secunet.com>
    Cc: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Cong Wang <cong.wang@bytedance.com>
    Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4f12385298d474541a794f4c47980861299f20e7
Author: Sibi Sankar <sibis@codeaurora.org>
Date:   Thu Jul 23 01:40:45 2020 +0530

    remoteproc: qcom_q6v5_mss: Validate MBA firmware size before load
    
    commit e013f455d95add874f310dc47c608e8c70692ae5 upstream
    
    The following mem abort is observed when the mba firmware size exceeds
    the allocated mba region. MBA firmware size is restricted to a maximum
    size of 1M and remaining memory region is used by modem debug policy
    firmware when available. Hence verify whether the MBA firmware size lies
    within the allocated memory region and is not greater than 1M before
    loading.
    
    Err Logs:
    Unable to handle kernel paging request at virtual address
    Mem abort info:
    ...
    Call trace:
      __memcpy+0x110/0x180
      rproc_start+0x40/0x218
      rproc_boot+0x5b4/0x608
      state_store+0x54/0xf8
      dev_attr_store+0x44/0x60
      sysfs_kf_write+0x58/0x80
      kernfs_fop_write+0x140/0x230
      vfs_write+0xc4/0x208
      ksys_write+0x74/0xf8
      __arm64_sys_write+0x24/0x30
    ...
    
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Fixes: 051fb70fd4ea4 ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
    Link: https://lore.kernel.org/r/20200722201047.12975-2-sibis@codeaurora.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    [sudip: manual backport to old file path]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 96bc573dc8894fffd8859b6796466164053c06c7
Author: Sibi Sankar <sibis@codeaurora.org>
Date:   Thu Jul 23 01:40:46 2020 +0530

    remoteproc: qcom_q6v5_mss: Validate modem blob firmware size before load
    
    commit 135b9e8d1cd8ba5ac9ad9bcf24b464b7b052e5b8 upstream
    
    The following mem abort is observed when one of the modem blob firmware
    size exceeds the allocated mpss region. Fix this by restricting the copy
    size to segment size using request_firmware_into_buf before load.
    
    Err Logs:
    Unable to handle kernel paging request at virtual address
    Mem abort info:
    ...
    Call trace:
      __memcpy+0x110/0x180
      rproc_start+0xd0/0x190
      rproc_boot+0x404/0x550
      state_store+0x54/0xf8
      dev_attr_store+0x44/0x60
      sysfs_kf_write+0x58/0x80
      kernfs_fop_write+0x140/0x230
      vfs_write+0xc4/0x208
      ksys_write+0x74/0xf8
    ...
    
    Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    Fixes: 051fb70fd4ea4 ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
    Link: https://lore.kernel.org/r/20200722201047.12975-3-sibis@codeaurora.org
    Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
    [sudip: manual backport to old file path]
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a19749a5fbd97f2147a8768813d084d584d9e045
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Fri Jan 29 10:13:53 2021 -0500

    fgraph: Initialize tracing_graph_pause at task creation
    
    commit 7e0a9220467dbcfdc5bc62825724f3e52e50ab31 upstream.
    
    On some archs, the idle task can call into cpu_suspend(). The cpu_suspend()
    will disable or pause function graph tracing, as there's some paths in
    bringing down the CPU that can have issues with its return address being
    modified. The task_struct structure has a "tracing_graph_pause" atomic
    counter, that when set to something other than zero, the function graph
    tracer will not modify the return address.
    
    The problem is that the tracing_graph_pause counter is initialized when the
    function graph tracer is enabled. This can corrupt the counter for the idle
    task if it is suspended in these architectures.
    
       CPU 1                                CPU 2
       -----                                -----
      do_idle()
        cpu_suspend()
          pause_graph_tracing()
              task_struct->tracing_graph_pause++ (0 -> 1)
    
                                    start_graph_tracing()
                                      for_each_online_cpu(cpu) {
                                        ftrace_graph_init_idle_task(cpu)
                                          task-struct->tracing_graph_pause = 0 (1 -> 0)
    
          unpause_graph_tracing()
              task_struct->tracing_graph_pause-- (0 -> -1)
    
    The above should have gone from 1 to zero, and enabled function graph
    tracing again. But instead, it is set to -1, which keeps it disabled.
    
    There's no reason that the field tracing_graph_pause on the task_struct can
    not be initialized at boot up.
    
    Cc: stable@vger.kernel.org
    Fixes: 380c4b1411ccd ("tracing/function-graph-tracer: append the tracing_graph_flag")
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=211339
    Reported-by: pierre.gondois@arm.com
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b0393aadc2d2294ba259fe010291f72a130d2d60
Author: zhengbin <zhengbin13@huawei.com>
Date:   Wed Feb 20 21:27:05 2019 +0800

    block: fix NULL pointer dereference in register_disk
    
    commit 4d7c1d3fd7c7eda7dea351f071945e843a46c145 upstream.
    
    If __device_add_disk-->bdi_register_owner-->bdi_register-->
    bdi_register_va-->device_create_vargs fails, bdi->dev is still
    NULL, __device_add_disk-->register_disk will visit bdi->dev->kobj.
    This patch fixes that.
    
    Signed-off-by: zhengbin <zhengbin13@huawei.com>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>

commit 960434acef375b2a73168b467fdfc7fa0a11a68e
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Thu Jan 28 00:37:51 2021 +0900

    tracing/kprobe: Fix to support kretprobe events on unloaded modules
    
    commit 97c753e62e6c31a404183898d950d8c08d752dbd upstream.
    
    Fix kprobe_on_func_entry() returns error code instead of false so that
    register_kretprobe() can return an appropriate error code.
    
    append_trace_kprobe() expects the kprobe registration returns -ENOENT
    when the target symbol is not found, and it checks whether the target
    module is unloaded or not. If the target module doesn't exist, it
    defers to probe the target symbol until the module is loaded.
    
    However, since register_kretprobe() returns -EINVAL instead of -ENOENT
    in that case, it always fail on putting the kretprobe event on unloaded
    modules. e.g.
    
    Kprobe event:
    /sys/kernel/debug/tracing # echo p xfs:xfs_end_io >> kprobe_events
    [   16.515574] trace_kprobe: This probe might be able to register after target module is loaded. Continue.
    
    Kretprobe event: (p -> r)
    /sys/kernel/debug/tracing # echo r xfs:xfs_end_io >> kprobe_events
    sh: write error: Invalid argument
    /sys/kernel/debug/tracing # cat error_log
    [   41.122514] trace_kprobe: error: Failed to register probe event
      Command: r xfs:xfs_end_io
                 ^
    
    To fix this bug, change kprobe_on_func_entry() to detect symbol lookup
    failure and return -ENOENT in that case. Otherwise it returns -EINVAL
    or 0 (succeeded, given address is on the entry).
    
    Link: https://lkml.kernel.org/r/161176187132.1067016.8118042342894378981.stgit@devnote2
    
    Cc: stable@vger.kernel.org
    Fixes: 59158ec4aef7 ("tracing/kprobes: Check the probe on unloaded module correctly")
    Reported-by: Jianlin Lv <Jianlin.Lv@arm.com>
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>