commit ad5e80d0d772cea9c08eceaceda3b30131cdaaac
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Nov 10 10:22:21 2020 +0100

    Linux 4.4.242
    
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Link: https://lore.kernel.org/r/20201109125020.852643676@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f529a9a58f7edc578210e92cb32c602493d0ad84
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date:   Mon Oct 19 19:19:57 2020 -0700

    Revert "ARC: entry: fix potential EFA clobber when TIF_SYSCALL_TRACE"
    
    This reverts commit 00fdec98d9881bf5173af09aebd353ab3b9ac729.
    (but only from 5.2 and prior kernels)
    
    The original commit was a preventive fix based on code-review and was
    auto-picked for stable back-port (for better or worse).
    It was OK for v5.3+ kernels, but turned up needing an implicit change
    68e5c6f073bcf70 "(ARC: entry: EV_Trap expects r10 (vs. r9) to have
     exception cause)" merged in v5.3 which itself was not backported.
    So to summarize the stable backport of this patch for v5.2 and prior
    kernels is busted and it won't boot.
    
    The obvious solution is backport 68e5c6f073bcf70 but that is a pain as
    it doesn't revert cleanly and each of affected kernels (so far v4.19,
    v4.14, v4.9, v4.4) needs a slightly different massaged varaint.
    So the easier fix is to simply revert the backport from 5.2 and prior.
    The issue was not a big deal as it would cause strace to sporadically
    not work correctly.
    
    Waldemar Brodkorb first reported this when running ARC uClibc regressions
    on latest stable kernels (with offending backport). Once he bisected it,
    the analysis was trivial, so thx to him for this.
    
    Reported-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
    Bisected-by: Waldemar Brodkorb <wbx@uclibc-ng.org>
    Cc: stable <stable@vger.kernel.org> # 5.2 and prior
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 949dcf04df95e5c4bddea51733b53a8a4ab2114a
Author: Vineet Gupta <vgupta@synopsys.com>
Date:   Tue Oct 27 15:01:17 2020 -0700

    ARC: stack unwinding: avoid indefinite looping
    
    commit 328d2168ca524d501fc4b133d6be076142bd305c upstream.
    
    Currently stack unwinder is a while(1) loop which relies on the dwarf
    unwinder to signal termination, which in turn relies on dwarf info to do
    so. This in theory could cause an infinite loop if the dwarf info was
    somehow messed up or the register contents were etc.
    
    This fix thus detects the excessive looping and breaks the loop.
    
    | Mem: 26184K used, 1009136K free, 0K shrd, 0K buff, 14416K cached
    | CPU:  0.0% usr 72.8% sys  0.0% nic 27.1% idle  0.0% io  0.0% irq  0.0% sirq
    | Load average: 4.33 2.60 1.11 2/74 139
    |   PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
    |   133     2 root     SWN      0  0.0   3 22.9 [rcu_torture_rea]
    |   132     2 root     SWN      0  0.0   0 22.0 [rcu_torture_rea]
    |   131     2 root     SWN      0  0.0   3 21.5 [rcu_torture_rea]
    |   126     2 root     RW       0  0.0   2  5.4 [rcu_torture_wri]
    |   129     2 root     SWN      0  0.0   0  0.2 [rcu_torture_fak]
    |   137     2 root     SW       0  0.0   0  0.2 [rcu_torture_cbf]
    |   127     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
    |   138   115 root     R     1464  0.1   2  0.1 top
    |   130     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
    |   128     2 root     SWN      0  0.0   0  0.1 [rcu_torture_fak]
    |   115     1 root     S     1472  0.1   1  0.0 -/bin/sh
    |   104     1 root     S     1464  0.1   0  0.0 inetd
    |     1     0 root     S     1456  0.1   2  0.0 init
    |    78     1 root     S     1456  0.1   0  0.0 syslogd -O /var/log/messages
    |   134     2 root     SW       0  0.0   2  0.0 [rcu_torture_sta]
    |    10     2 root     IW       0  0.0   1  0.0 [rcu_preempt]
    |    88     2 root     IW       0  0.0   1  0.0 [kworker/1:1-eve]
    |    66     2 root     IW       0  0.0   2  0.0 [kworker/2:2-eve]
    |    39     2 root     IW       0  0.0   2  0.0 [kworker/2:1-eve]
    | unwinder looping too long, aborting !
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fc3fcc09ee09fce82c9893d7d96cd5243b54740e
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Nov 2 09:58:21 2020 -0500

    USB: Add NO_LPM quirk for Kingston flash drive
    
    commit afaa2e745a246c5ab95103a65b1ed00101e1bc63 upstream.
    
    In Bugzilla #208257, Julien Humbert reports that a 32-GB Kingston
    flash drive spontaneously disconnects and reconnects, over and over.
    Testing revealed that disabling Link Power Management for the drive
    fixed the problem.
    
    This patch adds a quirk entry for that drive to turn off LPM permanently.
    
    CC: Hans de Goede <jwrdegoede@fedoraproject.org>
    CC: <stable@vger.kernel.org>
    Reported-and-tested-by: Julien Humbert <julroy67@gmail.com>
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Link: https://lore.kernel.org/r/20201102145821.GA1478741@rowland.harvard.edu
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f39e125ed6c3d13d9b59d0dadbb0de0435f76eba
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Tue Nov 3 13:44:25 2020 +0100

    USB: serial: option: add Telit FN980 composition 0x1055
    
    commit db0362eeb22992502764e825c79b922d7467e0eb upstream.
    
    Add the following Telit FN980 composition:
    
    0x1055: tty, adb, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20201103124425.12940-1-dnlplm@gmail.com
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit cad4904cfca957062f36c8fef2ba7b01cf8a0af9
Author: Daniele Palmas <dnlplm@gmail.com>
Date:   Sat Oct 31 23:54:58 2020 +0100

    USB: serial: option: add LE910Cx compositions 0x1203, 0x1230, 0x1231
    
    commit 489979b4aab490b6b917c11dc02d81b4b742784a upstream.
    
    Add following Telit LE910Cx compositions:
    
    0x1203: rndis, tty, adb, tty, tty, tty, tty
    0x1230: tty, adb, rmnet, audio, tty, tty, tty, tty
    0x1231: rndis, tty, adb, audio, tty, tty, tty, tty
    
    Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
    Link: https://lore.kernel.org/r/20201031225458.10512-1-dnlplm@gmail.com
    [ johan: add comments after entries ]
    Cc: stable@vger.kernel.org
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d722e7ed6446347a76f65d83620cfa545546e204
Author: Johan Hovold <johan@kernel.org>
Date:   Mon Oct 26 09:25:48 2020 +0100

    USB: serial: cyberjack: fix write-URB completion race
    
    commit 985616f0457d9f555fff417d0da56174f70cc14f upstream.
    
    The write-URB busy flag was being cleared before the completion handler
    was done with the URB, something which could lead to corrupt transfers
    due to a racing write request if the URB is resubmitted.
    
    Fixes: 507ca9bc0476 ("[PATCH] USB: add ability for usb-serial drivers to determine if their write urb is currently being used.")
    Cc: stable <stable@vger.kernel.org>     # 2.6.13
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8675c12b1cf04fa1f6d83a98401856f87c436ce
Author: Qinglang Miao <miaoqinglang@huawei.com>
Date:   Tue Nov 3 16:49:42 2020 +0800

    serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init
    
    commit 0c5fc92622ed5531ff324b20f014e9e3092f0187 upstream.
    
    Add the missing platform_driver_unregister() before return
    from serial_txx9_init in the error handling case when failed
    to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI
    defined.
    
    Fixes: ab4382d27412 ("tty: move drivers/serial/ to drivers/tty/serial/")
    Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
    Link: https://lore.kernel.org/r/20201103084942.109076-1-miaoqinglang@huawei.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9afd6f7811855974546ce217eb7a3f0f76a09011
Author: Claire Chang <tientzu@chromium.org>
Date:   Mon Nov 2 20:07:49 2020 +0800

    serial: 8250_mtk: Fix uart_get_baud_rate warning
    
    commit 912ab37c798770f21b182d656937072b58553378 upstream.
    
    Mediatek 8250 port supports speed higher than uartclk / 16. If the baud
    rates in both the new and the old termios setting are higher than
    uartclk / 16, the WARN_ON in uart_get_baud_rate() will be triggered.
    Passing NULL as the old termios so uart_get_baud_rate() will use
    uartclk / 16 - 1 as the new baud rate which will be replaced by the
    original baud rate later by tty_termios_encode_baud_rate() in
    mtk8250_set_termios().
    
    Fixes: 551e553f0d4a ("serial: 8250_mtk: Fix high-speed baud rates clamping")
    Signed-off-by: Claire Chang <tientzu@chromium.org>
    Link: https://lore.kernel.org/r/20201102120749.374458-1-tientzu@chromium.org
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 33175e2d8fdf7b07be9691ee7747a3982dcf52cd
Author: Eddy Wu <itseddy0402@gmail.com>
Date:   Sat Nov 7 14:47:22 2020 +0800

    fork: fix copy_process(CLONE_PARENT) race with the exiting ->real_parent
    
    commit b4e00444cab4c3f3fec876dc0cccc8cbb0d1a948 upstream.
    
    current->group_leader->exit_signal may change during copy_process() if
    current->real_parent exits.
    
    Move the assignment inside tasklist_lock to avoid the race.
    
    Signed-off-by: Eddy Wu <eddy_wu@trendmicro.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81f26642406c16bf52015683511c814ecbe2abc3
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Nov 8 16:38:06 2020 +0100

    vt: Disable KD_FONT_OP_COPY
    
    commit 3c4e0dff2095c579b142d5a0693257f1c58b4804 upstream.
    
    It's buggy:
    
    On Fri, Nov 06, 2020 at 10:30:08PM +0800, Minh Yuan wrote:
    > We recently discovered a slab-out-of-bounds read in fbcon in the latest
    > kernel ( v5.10-rc2 for now ).  The root cause of this vulnerability is that
    > "fbcon_do_set_font" did not handle "vc->vc_font.data" and
    > "vc->vc_font.height" correctly, and the patch
    > <https://lkml.org/lkml/2020/9/27/223> for VT_RESIZEX can't handle this
    > issue.
    >
    > Specifically, we use KD_FONT_OP_SET to set a small font.data for tty6, and
    > use  KD_FONT_OP_SET again to set a large font.height for tty1. After that,
    > we use KD_FONT_OP_COPY to assign tty6's vc_font.data to tty1's vc_font.data
    > in "fbcon_do_set_font", while tty1 retains the original larger
    > height. Obviously, this will cause an out-of-bounds read, because we can
    > access a smaller vc_font.data with a larger vc_font.height.
    
    Further there was only one user ever.
    - Android's loadfont, busybox and console-tools only ever use OP_GET
      and OP_SET
    - fbset documentation only mentions the kernel cmdline font: option,
      not anything else.
    - systemd used OP_COPY before release 232 published in Nov 2016
    
    Now unfortunately the crucial report seems to have gone down with
    gmane, and the commit message doesn't say much. But the pull request
    hints at OP_COPY being broken
    
    https://github.com/systemd/systemd/pull/3651
    
    So in other words, this never worked, and the only project which
    foolishly every tried to use it, realized that rather quickly too.
    
    Instead of trying to fix security issues here on dead code by adding
    missing checks, fix the entire thing by removing the functionality.
    
    Note that systemd code using the OP_COPY function ignored the return
    value, so it doesn't matter what we're doing here really - just in
    case a lone server somewhere happens to be extremely unlucky and
    running an affected old version of systemd. The relevant code from
    font_copy_to_all_vcs() in systemd was:
    
            /* copy font from active VT, where the font was uploaded to */
            cfo.op = KD_FONT_OP_COPY;
            cfo.height = vcs.v_active-1; /* tty1 == index 0 */
            (void) ioctl(vcfd, KDFONTOP, &cfo);
    
    Note this just disables the ioctl, garbage collecting the now unused
    callbacks is left for -next.
    
    v2: Tetsuo found the old mail, which allowed me to find it on another
    archive. Add the link too.
    
    Acked-by: Peilin Ye <yepeilin.cs@gmail.com>
    Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
    References: https://lists.freedesktop.org/archives/systemd-devel/2016-June/036935.html
    References: https://github.com/systemd/systemd/pull/3651
    Cc: Greg KH <greg@kroah.com>
    Cc: Peilin Ye <yepeilin.cs@gmail.com>
    Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
    Link: https://lore.kernel.org/r/20201108153806.3140315-1-daniel.vetter@ffwll.ch
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 89236e8cdaa77387180e72d71017d4ac0b2ae4e3
Author: Jeff Vander Stoep <jeffv@google.com>
Date:   Fri Oct 23 16:37:57 2020 +0200

    vsock: use ns_capable_noaudit() on socket create
    
    [ Upstream commit af545bb5ee53f5261db631db2ac4cde54038bdaf ]
    
    During __vsock_create() CAP_NET_ADMIN is used to determine if the
    vsock_sock->trusted should be set to true. This value is used later
    for determing if a remote connection should be allowed to connect
    to a restricted VM. Unfortunately, if the caller doesn't have
    CAP_NET_ADMIN, an audit message such as an selinux denial is
    generated even if the caller does not want a trusted socket.
    
    Logging errors on success is confusing. To avoid this, switch the
    capable(CAP_NET_ADMIN) check to the noaudit version.
    
    Reported-by: Roman Kiryanov <rkir@google.com>
    https://android-review.googlesource.com/c/device/generic/goldfish/+/1468545/
    Signed-off-by: Jeff Vander Stoep <jeffv@google.com>
    Reviewed-by: James Morris <jamorris@linux.microsoft.com>
    Link: https://lore.kernel.org/r/20201023143757.377574-1-jeffv@google.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit cba7a192c1e17ae7e74e2d7ecc73e9ea5a48faaf
Author: Ming Lei <ming.lei@redhat.com>
Date:   Sat Oct 10 11:25:39 2020 +0800

    scsi: core: Don't start concurrent async scan on same host
    
    [ Upstream commit 831e3405c2a344018a18fcc2665acc5a38c3a707 ]
    
    The current scanning mechanism is supposed to fall back to a synchronous
    host scan if an asynchronous scan is in progress. However, this rule isn't
    strictly respected, scsi_prep_async_scan() doesn't hold scan_mutex when
    checking shost->async_scan. When scsi_scan_host() is called concurrently,
    two async scans on same host can be started and a hang in do_scan_async()
    is observed.
    
    Fixes this issue by checking & setting shost->async_scan atomically with
    shost->scan_mutex.
    
    Link: https://lore.kernel.org/r/20201010032539.426615-1-ming.lei@redhat.com
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Ewan D. Milne <emilne@redhat.com>
    Cc: Hannes Reinecke <hare@suse.de>
    Cc: Bart Van Assche <bvanassche@acm.org>
    Reviewed-by: Lee Duncan <lduncan@suse.com>
    Reviewed-by: Bart Van Assche <bvanassche@acm.org>
    Signed-off-by: Ming Lei <ming.lei@redhat.com>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 9c9fab488cf7364df658e9accb4ec0d34906b603
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date:   Wed Oct 21 11:53:59 2020 +0200

    of: Fix reserved-memory overlap detection
    
    [ Upstream commit ca05f33316559a04867295dd49f85aeedbfd6bfd ]
    
    The reserved-memory overlap detection code fails to detect overlaps if
    either of the regions starts at address 0x0.  The code explicitly checks
    for and ignores such regions, apparently in order to ignore dynamically
    allocated regions which have an address of 0x0 at this point.  These
    dynamically allocated regions also have a size of 0x0 at this point, so
    fix this by removing the check and sorting the dynamically allocated
    regions ahead of any static regions at address 0x0.
    
    For example, there are two overlaps in this case but they are not
    currently reported:
    
            foo@0 {
                    reg = <0x0 0x2000>;
            };
    
            bar@0 {
                    reg = <0x0 0x1000>;
            };
    
            baz@1000 {
                    reg = <0x1000 0x1000>;
            };
    
            quux {
                    size = <0x1000>;
            };
    
    but they are after this patch:
    
     OF: reserved mem: OVERLAP DETECTED!
     bar@0 (0x00000000--0x00001000) overlaps with foo@0 (0x00000000--0x00002000)
     OF: reserved mem: OVERLAP DETECTED!
     foo@0 (0x00000000--0x00002000) overlaps with baz@1000 (0x00001000--0x00002000)
    
    Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
    Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com
    Signed-off-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit a05262846df1c4f125815ba81b1de9472ec0a1e3
Author: Kairui Song <kasong@redhat.com>
Date:   Wed Oct 14 17:24:28 2020 +0800

    x86/kexec: Use up-to-dated screen_info copy to fill boot params
    
    [ Upstream commit afc18069a2cb7ead5f86623a5f3d4ad6e21f940d ]
    
    kexec_file_load() currently reuses the old boot_params.screen_info,
    but if drivers have change the hardware state, boot_param.screen_info
    could contain invalid info.
    
    For example, the video type might be no longer VGA, or the frame buffer
    address might be changed. If the kexec kernel keeps using the old screen_info,
    kexec'ed kernel may attempt to write to an invalid framebuffer
    memory region.
    
    There are two screen_info instances globally available, boot_params.screen_info
    and screen_info. Later one is a copy, and is updated by drivers.
    
    So let kexec_file_load use the updated copy.
    
    [ mingo: Tidied up the changelog. ]
    
    Signed-off-by: Kairui Song <kasong@redhat.com>
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Link: https://lore.kernel.org/r/20201014092429.1415040-2-kasong@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 39f68339223d47d778cc757963dfaa8001830a88
Author: Clément Péron <peron.clem@gmail.com>
Date:   Sat Oct 3 12:03:32 2020 +0200

    ARM: dts: sun4i-a10: fix cpu_alert temperature
    
    [ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ]
    
    When running dtbs_check thermal_zone warn about the
    temperature declared.
    
    thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000
    
    It's indeed wrong the real value is 85°C and not 850°C.
    
    Signed-off-by: Clément Péron <peron.clem@gmail.com>
    Signed-off-by: Maxime Ripard <maxime@cerno.tech>
    Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 735d0265dac9768fd4281b39ee1bdc3e5d42d3ee
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Oct 29 19:35:08 2020 -0400

    ftrace: Handle tracing when switching between context
    
    commit 726b3d3f141fba6f841d715fc4d8a4a84f02c02a upstream.
    
    When an interrupt or NMI comes in and switches the context, there's a delay
    from when the preempt_count() shows the update. As the preempt_count() is
    used to detect recursion having each context have its own bit get set when
    tracing starts, and if that bit is already set, it is considered a recursion
    and the function exits. But if this happens in that section where context
    has changed but preempt_count() has not been updated, this will be
    incorrectly flagged as a recursion.
    
    To handle this case, create another bit call TRANSITION and test it if the
    current context bit is already set. Flag the call as a recursion if the
    TRANSITION bit is already set, and if not, set it and continue. The
    TRANSITION bit will be cleared normally on the return of the function that
    set it, or if the current context bit is clear, set it and clear the
    TRANSITION bit to allow for another transition between the current context
    and an even higher one.
    
    Cc: stable@vger.kernel.org
    Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4130add27ceb2ce7a73a9fb5f3bf359bd8dc8968
Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
Date:   Thu Oct 29 17:31:45 2020 -0400

    ftrace: Fix recursion check for NMI test
    
    commit ee11b93f95eabdf8198edd4668bf9102e7248270 upstream.
    
    The code that checks recursion will work to only do the recursion check once
    if there's nested checks. The top one will do the check, the other nested
    checks will see recursion was already checked and return zero for its "bit".
    On the return side, nothing will be done if the "bit" is zero.
    
    The problem is that zero is returned for the "good" bit when in NMI context.
    This will set the bit for NMIs making it look like *all* NMI tracing is
    recursing, and prevent tracing of anything in NMI context!
    
    The simple fix is to return "bit + 1" and subtract that bit on the end to
    get the real bit.
    
    Cc: stable@vger.kernel.org
    Fixes: edc15cafcbfa3 ("tracing: Avoid unnecessary multiple recursion checks")
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5dbe2f34d5d526c8b7ad0febeb273dd1a560d3b0
Author: Geoffrey D. Bennett <g@b4.vu>
Date:   Wed Nov 4 22:27:17 2020 +1030

    ALSA: usb-audio: Add implicit feedback quirk for Qu-16
    
    commit 0938ecae432e7ac8b01080c35dd81d50a1e43033 upstream.
    
    This patch fixes audio distortion on playback for the Allen&Heath
    Qu-16.
    
    Signed-off-by: Geoffrey D. Bennett <g@b4.vu>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20201104115717.GA19046@b4.vu
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e0e6f91b1a31bf37dfbeab1f6bf80dae3d27087
Author: Lee Jones <lee.jones@linaro.org>
Date:   Mon Nov 2 13:32:42 2020 -0500

    Fonts: Replace discarded const qualifier
    
    commit 9522750c66c689b739e151fcdf895420dc81efc0 upstream.
    
    Commit 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros for built-in
    fonts") introduced the following error when building rpc_defconfig (only
    this build appears to be affected):
    
     `acorndata_8x8' referenced in section `.text' of arch/arm/boot/compressed/ll_char_wr.o:
        defined in discarded section `.data' of arch/arm/boot/compressed/font.o
     `acorndata_8x8' referenced in section `.data.rel.ro' of arch/arm/boot/compressed/font.o:
        defined in discarded section `.data' of arch/arm/boot/compressed/font.o
     make[3]: *** [/scratch/linux/arch/arm/boot/compressed/Makefile:191: arch/arm/boot/compressed/vmlinux] Error 1
     make[2]: *** [/scratch/linux/arch/arm/boot/Makefile:61: arch/arm/boot/compressed/vmlinux] Error 2
     make[1]: *** [/scratch/linux/arch/arm/Makefile:317: zImage] Error 2
    
    The .data section is discarded at link time.  Reinstating acorndata_8x8 as
    const ensures it is still available after linking.  Do the same for the
    other 12 built-in fonts as well, for consistency purposes.
    
    Cc: <stable@vger.kernel.org>
    Cc: Russell King <linux@armlinux.org.uk>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Fixes: 6735b4632def ("Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts")
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Co-developed-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20201102183242.2031659-1-yepeilin.cs@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2a0f579faf7a0cd5338df059aabbb340e2ff85d5
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Tue Oct 20 20:36:05 2020 +0300

    gianfar: Account for Tx PTP timestamp in the skb headroom
    
    [ Upstream commit d6a076d68c6b5d6a5800f3990a513facb7016dea ]
    
    When PTP timestamping is enabled on Tx, the controller
    inserts the Tx timestamp at the beginning of the frame
    buffer, between SFD and the L2 frame header. This means
    that the skb provided by the stack is required to have
    enough headroom otherwise a new skb needs to be created
    by the driver to accommodate the timestamp inserted by h/w.
    Up until now the driver was relying on the second option,
    using skb_realloc_headroom() to create a new skb to accommodate
    PTP frames. Turns out that this method is not reliable, as
    reallocation of skbs for PTP frames along with the required
    overhead (skb_set_owner_w, consume_skb) is causing random
    crashes in subsequent skb_*() calls, when multiple concurrent
    TCP streams are run at the same time on the same device
    (as seen in James' report).
    Note that these crashes don't occur with a single TCP stream,
    nor with multiple concurrent UDP streams, but only when multiple
    TCP streams are run concurrently with the PTP packet flow
    (doing skb reallocation).
    This patch enforces the first method, by requesting enough
    headroom from the stack to accommodate PTP frames, and so avoiding
    skb_realloc_headroom() & co, and the crashes no longer occur.
    There's no reason not to set needed_headroom to a large enough
    value to accommodate PTP frames, so in this regard this patch
    is a fix.
    
    Reported-by: James Jurack <james.jurack@ametek.com>
    Fixes: bee9e58c9e98 ("gianfar:don't add FCB length to hard_header_len")
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Link: https://lore.kernel.org/r/20201020173605.1173-1-claudiu.manoil@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 32e8d079c4d5bef645497cd48f993ee3b397543c
Author: Claudiu Manoil <claudiu.manoil@nxp.com>
Date:   Thu Oct 29 10:10:56 2020 +0200

    gianfar: Replace skb_realloc_headroom with skb_cow_head for PTP
    
    [ Upstream commit d145c9031325fed963a887851d9fa42516efd52b ]
    
    When PTP timestamping is enabled on Tx, the controller
    inserts the Tx timestamp at the beginning of the frame
    buffer, between SFD and the L2 frame header.  This means
    that the skb provided by the stack is required to have
    enough headroom otherwise a new skb needs to be created
    by the driver to accommodate the timestamp inserted by h/w.
    Up until now the driver was relying on skb_realloc_headroom()
    to create new skbs to accommodate PTP frames.  Turns out that
    this method is not reliable in this context at least, as
    skb_realloc_headroom() for PTP frames can cause random crashes,
    mostly in subsequent skb_*() calls, when multiple concurrent
    TCP streams are run at the same time with the PTP flow
    on the same device (as seen in James' report).  I also noticed
    that when the system is loaded by sending multiple TCP streams,
    the driver receives cloned skbs in large numbers.
    skb_cow_head() instead proves to be stable in this scenario,
    and not only handles cloned skbs too but it's also more efficient
    and widely used in other drivers.
    The commit introducing skb_realloc_headroom in the driver
    goes back to 2009, commit 93c1285c5d92
    ("gianfar: reallocate skb when headroom is not enough for fcb").
    For practical purposes I'm referencing a newer commit (from 2012)
    that brings the code to its current structure (and fixes the PTP
    case).
    
    Fixes: 9c4886e5e63b ("gianfar: Fix invalid TX frames returned on error queue when time stamping")
    Reported-by: James Jurack <james.jurack@ametek.com>
    Suggested-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com>
    Link: https://lore.kernel.org/r/20201029081057.8506-1-claudiu.manoil@nxp.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ae010785847f89122ba38f0eb94947c782f842ad
Author: Hoang Huu Le <hoang.h.le@dektech.com.au>
Date:   Thu Aug 27 09:56:51 2020 +0700

    tipc: fix use-after-free in tipc_bcast_get_mode
    
    commit fdeba99b1e58ecd18c2940c453e19e4ef20ff591 upstream.
    
    Syzbot has reported those issues as:
    
    ==================================================================
    BUG: KASAN: use-after-free in tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759
    Read of size 1 at addr ffff88805e6b3571 by task kworker/0:6/3850
    
    CPU: 0 PID: 3850 Comm: kworker/0:6 Not tainted 5.8.0-rc7-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events tipc_net_finalize_work
    
    Thread 1's call trace:
    [...]
      kfree+0x103/0x2c0 mm/slab.c:3757 <- bcbase releasing
      tipc_bcast_stop+0x1b0/0x2f0 net/tipc/bcast.c:721
      tipc_exit_net+0x24/0x270 net/tipc/core.c:112
    [...]
    
    Thread 2's call trace:
    [...]
      tipc_bcast_get_mode+0x3ab/0x400 net/tipc/bcast.c:759 <- bcbase
    has already been freed by Thread 1
    
      tipc_node_broadcast+0x9e/0xcc0 net/tipc/node.c:1744
      tipc_nametbl_publish+0x60b/0x970 net/tipc/name_table.c:752
      tipc_net_finalize net/tipc/net.c:141 [inline]
      tipc_net_finalize+0x1fa/0x310 net/tipc/net.c:131
      tipc_net_finalize_work+0x55/0x80 net/tipc/net.c:150
    [...]
    
    ==================================================================
    BUG: KASAN: use-after-free in tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344
    Read of size 8 at addr ffff888052ab2000 by task kworker/0:13/30628
    CPU: 0 PID: 30628 Comm: kworker/0:13 Not tainted 5.8.0-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    Workqueue: events tipc_net_finalize_work
    Call Trace:
     __dump_stack lib/dump_stack.c:77 [inline]
     dump_stack+0x1f0/0x31e lib/dump_stack.c:118
     print_address_description+0x66/0x5a0 mm/kasan/report.c:383
     __kasan_report mm/kasan/report.c:513 [inline]
     kasan_report+0x132/0x1d0 mm/kasan/report.c:530
     tipc_named_reinit+0xef/0x290 net/tipc/name_distr.c:344
     tipc_net_finalize+0x85/0xe0 net/tipc/net.c:138
     tipc_net_finalize_work+0x50/0x70 net/tipc/net.c:150
     process_one_work+0x789/0xfc0 kernel/workqueue.c:2269
     worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415
     kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
    [...]
    Freed by task 14058:
     save_stack mm/kasan/common.c:48 [inline]
     set_track mm/kasan/common.c:56 [inline]
     kasan_set_free_info mm/kasan/common.c:316 [inline]
     __kasan_slab_free+0x114/0x170 mm/kasan/common.c:455
     __cache_free mm/slab.c:3426 [inline]
     kfree+0x10a/0x220 mm/slab.c:3757
     tipc_exit_net+0x29/0x50 net/tipc/core.c:113
     ops_exit_list net/core/net_namespace.c:186 [inline]
     cleanup_net+0x708/0xba0 net/core/net_namespace.c:603
     process_one_work+0x789/0xfc0 kernel/workqueue.c:2269
     worker_thread+0xaa4/0x1460 kernel/workqueue.c:2415
     kthread+0x37e/0x3a0 drivers/block/aoe/aoecmd.c:1234
     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
    
    Fix it by calling flush_scheduled_work() to make sure the
    tipc_net_finalize_work() stopped before releasing bcbase object.
    
    Reported-by: syzbot+6ea1f7a8df64596ef4d7@syzkaller.appspotmail.com
    Reported-by: syzbot+e9cc557752ab126c1b99@syzkaller.appspotmail.com
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Signed-off-by: Hoang Huu Le <hoang.h.le@dektech.com.au>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f3fd25106bb96a8808731b66baf539fedeb0af7e
Author: Juergen Gross <jgross@suse.com>
Date:   Wed Sep 30 11:16:14 2020 +0200

    xen/events: don't use chip_data for legacy IRQs
    
    commit 0891fb39ba67bd7ae023ea0d367297ffff010781 upstream.
    
    Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.")
    Xen is using the chip_data pointer for storing IRQ specific data. When
    running as a HVM domain this can result in problems for legacy IRQs, as
    those might use chip_data for their own purposes.
    
    Use a local array for this purpose in case of legacy IRQs, avoiding the
    double use.
    
    Cc: stable@vger.kernel.org
    Fixes: c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.")
    Signed-off-by: Juergen Gross <jgross@suse.com>
    Tested-by: Stefan Bader <stefan.bader@canonical.com>
    Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Link: https://lore.kernel.org/r/20200930091614.13660-1-jgross@suse.com
    Signed-off-by: Juergen Gross <jgross@suse.com>
    [bwh: Backported to 4.9: adjust context]
    Signed-off-by: Ben Hutchings <benh@debian.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 354e0ccb567822071871a13e5d5873f99f7a39c2
Author: Ian Abbott <abbotti@mev.co.uk>
Date:   Wed Oct 21 13:21:42 2020 +0100

    staging: comedi: cb_pcidas: Allow 2-channel commands for AO subdevice
    
    commit 647a6002cb41d358d9ac5de101a8a6dc74748a59 upstream.
    
    The "cb_pcidas" driver supports asynchronous commands on the analog
    output (AO) subdevice for those boards that have an AO FIFO.  The code
    (in `cb_pcidas_ao_check_chanlist()` and `cb_pcidas_ao_cmd()`) to
    validate and set up the command supports output to a single channel or
    to two channels simultaneously (the boards have two AO channels).
    However, the code in `cb_pcidas_auto_attach()` that initializes the
    subdevices neglects to initialize the AO subdevice's `len_chanlist`
    member, leaving it set to 0, but the Comedi core will "correct" it to 1
    if the driver neglected to set it.  This limits commands to use a single
    channel (either channel 0 or 1), but the limit should be two channels.
    Set the AO subdevice's `len_chanlist` member to be the same value as the
    `n_chan` member, which will be 2.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
    Link: https://lore.kernel.org/r/20201021122142.81628-1-abbotti@mev.co.uk
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 067afbdf31d2d340b1e2645f23ef112f60c63cb7
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Oct 22 21:41:00 2020 +0300

    device property: Don't clear secondary pointer for shared primary firmware node
    
    commit 99aed9227073fb34ce2880cbc7063e04185a65e1 upstream.
    
    It appears that firmware nodes can be shared between devices. In such case
    when a (child) device is about to be deleted, its firmware node may be shared
    and ACPI_COMPANION_SET(..., NULL) call for it breaks the secondary link
    of the shared primary firmware node.
    
    In order to prevent that, check, if the device has a parent and parent's
    firmware node is shared with its child, and avoid crashing the link.
    
    Fixes: c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()")
    Reported-by: Ferry Toth <fntoth@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Tested-by: Ferry Toth <fntoth@gmail.com>
    Cc: 5.9+ <stable@vger.kernel.org> # 5.9+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e80a513b2984fcc8f810986e2d930c4d9d01084
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Oct 22 21:40:59 2020 +0300

    device property: Keep secondary firmware node secondary by type
    
    commit d5dcce0c414fcbfe4c2037b66ac69ea5f9b3f75c upstream.
    
    Behind primary and secondary we understand the type of the nodes
    which might define their ordering. However, if primary node gone,
    we can't maintain the ordering by definition of the linked list.
    Thus, by ordering secondary node becomes first in the list.
    But in this case the meaning of it is still secondary (or auxiliary).
    The type of the node is maintained by the secondary pointer in it:
    
            secondary pointer               Meaning
            NULL or valid                   primary node
            ERR_PTR(-ENODEV)                secondary node
    
    So, if by some reason we do the following sequence of calls
    
            set_primary_fwnode(dev, NULL);
            set_primary_fwnode(dev, primary);
    
    we should preserve secondary node.
    
    This concept is supported by the description of set_primary_fwnode()
    along with implementation of set_secondary_fwnode(). Hence, fix
    the commit c15e1bdda436 to follow this as well.
    
    Fixes: c15e1bdda436 ("device property: Fix the secondary firmware node handling in set_primary_fwnode()")
    Cc: Ferry Toth <fntoth@gmail.com>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
    Tested-by: Ferry Toth <fntoth@gmail.com>
    Cc: 5.9+ <stable@vger.kernel.org> # 5.9+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 83810e195b770306cef1bcb25549959b4d2e919d
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Tue Aug 4 21:26:49 2020 +0200

    ARM: s3c24xx: fix missing system reset
    
    commit f6d7cde84f6c5551586c8b9b68d70f8e6dc9a000 upstream.
    
    Commit f6361c6b3880 ("ARM: S3C24XX: remove separate restart code")
    removed usage of the watchdog reset platform code in favor of the
    Samsung SoC watchdog driver.  However the latter was not selected thus
    S3C24xx platforms lost reset abilities.
    
    Cc: <stable@vger.kernel.org>
    Fixes: f6361c6b3880 ("ARM: S3C24XX: remove separate restart code")
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01edca9f3fbd615b8ce41941a3c969cd3a1c38bc
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Thu Sep 10 17:41:49 2020 +0200

    ARM: samsung: fix PM debug build with DEBUG_LL but !MMU
    
    commit 7be0d19c751b02db778ca95e3274d5ea7f31891c upstream.
    
    Selecting CONFIG_SAMSUNG_PM_DEBUG (depending on CONFIG_DEBUG_LL) but
    without CONFIG_MMU leads to build errors:
    
      arch/arm/plat-samsung/pm-debug.c: In function ‘s3c_pm_uart_base’:
      arch/arm/plat-samsung/pm-debug.c:57:2: error:
        implicit declaration of function ‘debug_ll_addr’ [-Werror=implicit-function-declaration]
    
    Fixes: 99b2fc2b8b40 ("ARM: SAMSUNG: Use debug_ll_addr() to get UART base address")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200910154150.3318-1-krzk@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f39f857f8188a4063e6e11d3c9d5e6db41f0268d
Author: Helge Deller <deller@gmx.de>
Date:   Mon Oct 19 16:57:50 2020 +0200

    hil/parisc: Disable HIL driver when it gets stuck
    
    commit 879bc2d27904354b98ca295b6168718e045c4aa2 upstream.
    
    When starting a HP machine with HIL driver but without an HIL keyboard
    or HIL mouse attached, it may happen that data written to the HIL loop
    gets stuck (e.g. because the transaction queue is full).  Usually one
    will then have to reboot the machine because all you see is and endless
    output of:
     Transaction add failed: transaction already queued?
    
    In the higher layers hp_sdc_enqueue_transaction() is called to queued up
    a HIL packet. This function returns an error code, and this patch adds
    the necessary checks for this return code and disables the HIL driver if
    further packets can't be sent.
    
    Tested on a HP 730 and a HP 715/64 machine.
    
    Signed-off-by: Helge Deller <deller@gmx.de>
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4921e45dcf0903d6a81044deb2e966bdae5be7b3
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Mon Oct 26 09:12:10 2020 +0000

    cachefiles: Handle readpage error correctly
    
    commit 9480b4e75b7108ee68ecf5bc6b4bd68e8031c521 upstream.
    
    If ->readpage returns an error, it has already unlocked the page.
    
    Fixes: 5e929b33c393 ("CacheFiles: Handle truncate unlocking the page we're reading")
    Cc: stable@vger.kernel.org
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: David Howells <dhowells@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 11db9417af9f98c71abab3adbdb03c5ef3ddb6b5
Author: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
Date:   Fri Oct 9 15:08:31 2020 +0800

    arm64: berlin: Select DW_APB_TIMER_OF
    
    commit b0fc70ce1f028e14a37c186d9f7a55e51439b83a upstream.
    
    Berlin SoCs always contain some DW APB timers which can be used as an
    always-on broadcast timer.
    
    Link: https://lore.kernel.org/r/20201009150536.214181fb@xhacker.debian
    Cc: <stable@vger.kernel.org> # v3.14+
    Signed-off-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e847c4e2ccc80295338cc96136aec2877be82359
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Oct 26 13:15:23 2020 -0700

    tty: make FONTX ioctl use the tty pointer they were actually passed
    
    commit 90bfdeef83f1d6c696039b6a917190dcbbad3220 upstream.
    
    Some of the font tty ioctl's always used the current foreground VC for
    their operations.  Don't do that then.
    
    This fixes a data race on fg_console.
    
    Side note: both Michael Ellerman and Jiri Slaby point out that all these
    ioctls are deprecated, and should probably have been removed long ago,
    and everything seems to be using the KDFONTOP ioctl instead.
    
    In fact, Michael points out that it looks like busybox's loadfont
    program seems to have switched over to using KDFONTOP exactly _because_
    of this bug (ahem.. 12 years ago ;-).
    
    Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
    Acked-by: Michael Ellerman <mpe@ellerman.id.au>
    Acked-by: Jiri Slaby <jirislaby@kernel.org>
    Cc: Greg KH <greg@kroah.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e861fa7413af7c3db3d575af0631177e171f12fd
Author: Stefano Garzarella <sgarzare@redhat.com>
Date:   Thu Oct 8 22:42:56 2020 +0200

    vringh: fix __vringh_iov() when riov and wiov are different
    
    commit 5745bcfbbf89b158416075374254d3c013488f21 upstream.
    
    If riov and wiov are both defined and they point to different
    objects, only riov is initialized. If the wiov is not initialized
    by the caller, the function fails returning -EINVAL and printing
    "Readable desc 0x... after writable" error message.
    
    This issue happens when descriptors have both readable and writable
    buffers (eg. virtio-blk devices has virtio_blk_outhdr in the readable
    buffer and status as last byte of writable buffer) and we call
    __vringh_iov() to get both type of buffers in two different iovecs.
    
    Let's replace the 'else if' clause with 'if' to initialize both
    riov and wiov if they are not NULL.
    
    As checkpatch pointed out, we also avoid crashing the kernel
    when riov and wiov are both NULL, replacing BUG() with WARN_ON()
    and returning -EINVAL.
    
    Fixes: f87d0fbb5798 ("vringh: host-side implementation of virtio rings.")
    Cc: stable@vger.kernel.org
    Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
    Link: https://lore.kernel.org/r/20201008204256.162292-1-sgarzare@redhat.com
    Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 687b0d6084708094d6681815b2a7e3c6a51ea762
Author: Qiujun Huang <hqjagain@gmail.com>
Date:   Mon Oct 19 22:22:42 2020 +0800

    ring-buffer: Return 0 on success from ring_buffer_resize()
    
    commit 0a1754b2a97efa644aa6e84d1db5b17c42251483 upstream.
    
    We don't need to check the new buffer size, and the return value
    had confused resize_buffer_duplicate_size().
    ...
            ret = ring_buffer_resize(trace_buf->buffer,
                    per_cpu_ptr(size_buf->data,cpu_id)->entries, cpu_id);
            if (ret == 0)
                    per_cpu_ptr(trace_buf->data, cpu_id)->entries =
                            per_cpu_ptr(size_buf->data, cpu_id)->entries;
    ...
    
    Link: https://lkml.kernel.org/r/20201019142242.11560-1-hqjagain@gmail.com
    
    Cc: stable@vger.kernel.org
    Fixes: d60da506cbeb3 ("tracing: Add a resize function to make one buffer equivalent to another buffer")
    Signed-off-by: Qiujun Huang <hqjagain@gmail.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 68c3ab8037cbe953638bffcbf097b8fbd480ba37
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Sun Oct 4 19:04:22 2020 +0100

    9P: Cast to loff_t before multiplying
    
    commit f5f7ab168b9a60e12a4b8f2bb6fcc91321dc23c1 upstream.
    
    On 32-bit systems, this multiplication will overflow for files larger
    than 4GB.
    
    Link: http://lkml.kernel.org/r/20201004180428.14494-2-willy@infradead.org
    Cc: stable@vger.kernel.org
    Fixes: fb89b45cdfdc ("9P: introduction of a new cache=mmap model.")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1f0137aec9c83e881b3d53958ae2416834311a4
Author: Ilya Dryomov <idryomov@gmail.com>
Date:   Wed Oct 7 20:06:48 2020 +0200

    libceph: clear con->out_msg on Policy::stateful_server faults
    
    commit 28e1581c3b4ea5f98530064a103c6217bedeea73 upstream.
    
    con->out_msg must be cleared on Policy::stateful_server
    (!CEPH_MSG_CONNECT_LOSSY) faults.  Not doing so botches the
    reconnection attempt, because after writing the banner the
    messenger moves on to writing the data section of that message
    (either from where it got interrupted by the connection reset or
    from the beginning) instead of writing struct ceph_msg_connect.
    This results in a bizarre error message because the server
    sends CEPH_MSGR_TAG_BADPROTOVER but we think we wrote struct
    ceph_msg_connect:
    
      libceph: mds0 (1)172.21.15.45:6828 socket error on write
      ceph: mds0 reconnect start
      libceph: mds0 (1)172.21.15.45:6829 socket closed (con state OPEN)
      libceph: mds0 (1)172.21.15.45:6829 protocol version mismatch, my 32 != server's 32
      libceph: mds0 (1)172.21.15.45:6829 protocol version mismatch
    
    AFAICT this bug goes back to the dawn of the kernel client.
    The reason it survived for so long is that only MDS sessions
    are stateful and only two MDS messages have a data section:
    CEPH_MSG_CLIENT_RECONNECT (always, but reconnecting is rare)
    and CEPH_MSG_CLIENT_REQUEST (only when xattrs are involved).
    The connection has to get reset precisely when such message
    is being sent -- in this case it was the former.
    
    Cc: stable@vger.kernel.org
    Link: https://tracker.ceph.com/issues/47723
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0af192244e4dbfc4346afdc667c17aad65d3626f
Author: Matthew Wilcox (Oracle) <willy@infradead.org>
Date:   Sun Oct 4 19:04:24 2020 +0100

    ceph: promote to unsigned long long before shifting
    
    commit c403c3a2fbe24d4ed33e10cabad048583ebd4edf upstream.
    
    On 32-bit systems, this shift will overflow for files larger than 4GB.
    
    Cc: stable@vger.kernel.org
    Fixes: 61f68816211e ("ceph: check caps in filemap_fault and page_mkwrite")
    Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
    Reviewed-by: Jeff Layton <jlayton@kernel.org>
    Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15ed2b6c8f10a01e8cf59200fe3f9e55e1ac9c76
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Sat Oct 17 16:13:37 2020 -0700

    ia64: fix build error with !COREDUMP
    
    commit 7404840d87557c4092bf0272bce5e0354c774bf9 upstream.
    
    Fix linkage error when CONFIG_BINFMT_ELF is selected but CONFIG_COREDUMP
    is not:
    
        ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function `elf_core_write_extra_phdrs':
        elfcore.c:(.text+0x172): undefined reference to `dump_emit'
        ia64-linux-ld: arch/ia64/kernel/elfcore.o: in function `elf_core_write_extra_data':
        elfcore.c:(.text+0x2b2): undefined reference to `dump_emit'
    
    Fixes: 1fcccbac89f5 ("elf coredump: replace ELF_CORE_EXTRA_* macros by functions")
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Fenghua Yu <fenghua.yu@intel.com>
    Cc: <stable@vger.kernel.org>
    Link: https://lkml.kernel.org/r/20200819064146.12529-1-krzk@kernel.org
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6ba1a785caf9458fac57d173c254e3e479fdd301
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Mon Jun 1 17:12:31 2020 +0800

    ubi: check kthread_should_stop() after the setting of task state
    
    commit d005f8c6588efcfbe88099b6edafc6f58c84a9c1 upstream.
    
    A detach hung is possible when a race occurs between the detach process
    and the ubi background thread. The following sequences outline the race:
    
      ubi thread: if (list_empty(&ubi->works)...
    
      ubi detach: set_bit(KTHREAD_SHOULD_STOP, &kthread->flags)
                  => by kthread_stop()
                  wake_up_process()
                  => ubi thread is still running, so 0 is returned
    
      ubi thread: set_current_state(TASK_INTERRUPTIBLE)
                  schedule()
                  => ubi thread will never be scheduled again
    
      ubi detach: wait_for_completion()
                  => hung task!
    
    To fix that, we need to check kthread_should_stop() after we set the
    task state, so the ubi thread will either see the stop bit and exit or
    the task state is reset to runnable such that it isn't scheduled out
    indefinitely.
    
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 801c135ce73d5df1ca ("UBI: Unsorted Block Images")
    Reported-by: syzbot+853639d0cb16c31c7a14@syzkaller.appspotmail.com
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1b37f532653e9805c069e663280324921bf3a1a2
Author: Zhihao Cheng <chengzhihao1@huawei.com>
Date:   Mon Jun 1 17:10:37 2020 +0800

    ubifs: dent: Fix some potential memory leaks while iterating entries
    
    commit 58f6e78a65f1fcbf732f60a7478ccc99873ff3ba upstream.
    
    Fix some potential memory leaks in error handling branches while
    iterating dent entries. For example, function dbg_check_dir()
    forgets to free pdent if it exists.
    
    Signed-off-by: Zhihao Cheng <chengzhihao1@huawei.com>
    Cc: <stable@vger.kernel.org>
    Fixes: 1e51764a3c2ac05a2 ("UBIFS: add new flash file system")
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b5f70e3a7619a453c0a6f3d3fb66fcc8617ad955
Author: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Date:   Tue Oct 6 13:02:18 2020 +0530

    powerpc/powernv/elog: Fix race while processing OPAL error log event.
    
    commit aea948bb80b478ddc2448f7359d574387521a52d upstream.
    
    Every error log reported by OPAL is exported to userspace through a
    sysfs interface and notified using kobject_uevent(). The userspace
    daemon (opal_errd) then reads the error log and acknowledges the error
    log is saved safely to disk. Once acknowledged the kernel removes the
    respective sysfs file entry causing respective resources to be
    released including kobject.
    
    However it's possible the userspace daemon may already be scanning
    elog entries when a new sysfs elog entry is created by the kernel.
    User daemon may read this new entry and ack it even before kernel can
    notify userspace about it through kobject_uevent() call. If that
    happens then we have a potential race between
    elog_ack_store->kobject_put() and kobject_uevent which can lead to
    use-after-free of a kernfs object resulting in a kernel crash. eg:
    
      BUG: Unable to handle kernel data access on read at 0x6b6b6b6b6b6b6bfb
      Faulting instruction address: 0xc0000000008ff2a0
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV
      CPU: 27 PID: 805 Comm: irq/29-opal-elo Not tainted 5.9.0-rc2-gcc-8.2.0-00214-g6f56a67bcbb5-dirty #363
      ...
      NIP kobject_uevent_env+0xa0/0x910
      LR  elog_event+0x1f4/0x2d0
      Call Trace:
        0x5deadbeef0000122 (unreliable)
        elog_event+0x1f4/0x2d0
        irq_thread_fn+0x4c/0xc0
        irq_thread+0x1c0/0x2b0
        kthread+0x1c4/0x1d0
        ret_from_kernel_thread+0x5c/0x6c
    
    This patch fixes this race by protecting the sysfs file
    creation/notification by holding a reference count on kobject until we
    safely send kobject_uevent().
    
    The function create_elog_obj() returns the elog object which if used
    by caller function will end up in use-after-free problem again.
    However, the return value of create_elog_obj() function isn't being
    used today and there is no need as well. Hence change it to return
    void to make this fix complete.
    
    Fixes: 774fea1a38c6 ("powerpc/powernv: Read OPAL error log and export it through sysfs")
    Cc: stable@vger.kernel.org # v3.15+
    Reported-by: Oliver O'Halloran <oohall@gmail.com>
    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
    Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
    Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
    [mpe: Rework the logic to use a single return, reword comments, add oops]
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20201006122051.190176-1-mpe@ellerman.id.au
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 708bb8c17c90d20fa7ec50ad595986cd36dd173a
Author: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Date:   Wed Jul 22 16:50:41 2020 +0100

    iio:gyro:itg3200: Fix timestamp alignment and prevent data leak.
    
    commit 10ab7cfd5522f0041028556dac864a003e158556 upstream.
    
    One of a class of bugs pointed out by Lars in a recent review.
    iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
    to the size of the timestamp (8 bytes).  This is not guaranteed in
    this driver which uses a 16 byte array of smaller elements on the stack.
    This is fixed by using an explicit c structure. As there are no
    holes in the structure, there is no possiblity of data leakage
    in this case.
    
    The explicit alignment of ts is not strictly necessary but potentially
    makes the code slightly less fragile.  It also removes the possibility
    of this being cut and paste into another driver where the alignment
    isn't already true.
    
    Fixes: 36e0371e7764 ("iio:itg3200: Use iio_push_to_buffers_with_timestamp()")
    Reported-by: Lars-Peter Clausen <lars@metafoo.de>
    Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Cc: <Stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20200722155103.979802-6-jic23@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92293ee597dab5aaa9f2e868dab4fda7784acaf0
Author: Paul Cercueil <paul@crapouillou.net>
Date:   Sun Oct 4 16:03:07 2020 +0200

    dmaengine: dma-jz4780: Fix race in jz4780_dma_tx_status
    
    commit baf6fd97b16ea8f981b8a8b04039596f32fc2972 upstream.
    
    The jz4780_dma_tx_status() function would check if a channel's cookie
    state was set to 'completed', and if not, it would enter the critical
    section. However, in that time frame, the jz4780_dma_chan_irq() function
    was able to set the cookie to 'completed', and clear the jzchan->vchan
    pointer, which was deferenced in the critical section of the first
    function.
    
    Fix this race by checking the channel's cookie state after entering the
    critical function and not before.
    
    Fixes: d894fc6046fe ("dmaengine: jz4780: add driver for the Ingenic JZ4780 DMA controller")
    Cc: stable@vger.kernel.org # v4.0
    Signed-off-by: Paul Cercueil <paul@crapouillou.net>
    Reported-by: Artur Rojek <contact@artur-rojek.eu>
    Tested-by: Artur Rojek <contact@artur-rojek.eu>
    Link: https://lore.kernel.org/r/20201004140307.885556-1-paul@crapouillou.net
    Signed-off-by: Vinod Koul <vkoul@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f4cfdf9b1487d3512da27a1a542b4c33a4737bca
Author: Jiri Slaby <jirislaby@kernel.org>
Date:   Mon Oct 19 10:55:17 2020 +0200

    vt: keyboard, extend func_buf_lock to readers
    
    commit 82e61c3909db51d91b9d3e2071557b6435018b80 upstream.
    
    Both read-side users of func_table/func_buf need locking. Without that,
    one can easily confuse the code by repeatedly setting altering strings
    like:
    while (1)
            for (a = 0; a < 2; a++) {
                    struct kbsentry kbs = {};
                    strcpy((char *)kbs.kb_string, a ? ".\n" : "88888\n");
                    ioctl(fd, KDSKBSENT, &kbs);
            }
    
    When that program runs, one can get unexpected output by holding F1
    (note the unxpected period on the last line):
    .
    88888
    .8888
    
    So protect all accesses to 'func_table' (and func_buf) by preexisting
    'func_buf_lock'.
    
    It is easy in 'k_fn' handler as 'puts_queue' is expected not to sleep.
    On the other hand, KDGKBSENT needs a local (atomic) copy of the string
    because copy_to_user can sleep. Use already allocated, but unused
    'kbs->kb_string' for that purpose.
    
    Note that the program above needs at least CAP_SYS_TTY_CONFIG.
    
    This depends on the previous patch and on the func_buf_lock lock added
    in commit 46ca3f735f34 (tty/vt: fix write/write race in ioctl(KDSKBSENT)
    handler) in 5.2.
    
    Likely fixes CVE-2020-25656.
    
    Cc: <stable@vger.kernel.org>
    Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20201019085517.10176-2-jslaby@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d837ad15b8af447fe4eddbdd9554ede52953f1cb
Author: Jiri Slaby <jirislaby@kernel.org>
Date:   Mon Oct 19 10:55:16 2020 +0200

    vt: keyboard, simplify vt_kdgkbsent
    
    commit 6ca03f90527e499dd5e32d6522909e2ad390896b upstream.
    
    Use 'strlen' of the string, add one for NUL terminator and simply do
    'copy_to_user' instead of the explicit 'for' loop. This makes the
    KDGKBSENT case more compact.
    
    The only thing we need to take care about is NULL 'func_table[i]'. Use
    an empty string in that case.
    
    The original check for overflow could never trigger as the func_buf
    strings are always shorter or equal to 'struct kbsentry's.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Jiri Slaby <jslaby@suse.cz>
    Link: https://lore.kernel.org/r/20201019085517.10176-1-jslaby@suse.cz
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 39407c3a7a1a94a8abfbaf63155537102e16f318
Author: Filipe Manana <fdmanana@suse.com>
Date:   Mon Sep 14 15:27:50 2020 +0100

    btrfs: reschedule if necessary when logging directory items
    
    commit bb56f02f26fe23798edb1b2175707419b28c752a upstream.
    
    Logging directories with many entries can take a significant amount of
    time, and in some cases monopolize a cpu/core for a long time if the
    logging task doesn't happen to block often enough.
    
    Johannes and Lu Fengqi reported test case generic/041 triggering a soft
    lockup when the kernel has CONFIG_SOFTLOCKUP_DETECTOR=y. For this test
    case we log an inode with 3002 hard links, and because the test removed
    one hard link before fsyncing the file, the inode logging causes the
    parent directory do be logged as well, which has 6004 directory items to
    log (3002 BTRFS_DIR_ITEM_KEY items plus 3002 BTRFS_DIR_INDEX_KEY items),
    so it can take a significant amount of time and trigger the soft lockup.
    
    So just make tree-log.c:log_dir_items() reschedule when necessary,
    releasing the current search path before doing so and then resume from
    where it was before the reschedule.
    
    The stack trace produced when the soft lockup happens is the following:
    
    [10480.277653] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [xfs_io:28172]
    [10480.279418] Modules linked in: dm_thin_pool dm_persistent_data (...)
    [10480.284915] irq event stamp: 29646366
    [10480.285987] hardirqs last  enabled at (29646365): [<ffffffff85249b66>] __slab_alloc.constprop.0+0x56/0x60
    [10480.288482] hardirqs last disabled at (29646366): [<ffffffff8579b00d>] irqentry_enter+0x1d/0x50
    [10480.290856] softirqs last  enabled at (4612): [<ffffffff85a00323>] __do_softirq+0x323/0x56c
    [10480.293615] softirqs last disabled at (4483): [<ffffffff85800dbf>] asm_call_on_stack+0xf/0x20
    [10480.296428] CPU: 2 PID: 28172 Comm: xfs_io Not tainted 5.9.0-rc4-default+ #1248
    [10480.298948] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014
    [10480.302455] RIP: 0010:__slab_alloc.constprop.0+0x19/0x60
    [10480.304151] Code: 86 e8 31 75 21 00 66 66 2e 0f 1f 84 00 00 00 (...)
    [10480.309558] RSP: 0018:ffffadbe09397a58 EFLAGS: 00000282
    [10480.311179] RAX: ffff8a495ab92840 RBX: 0000000000000282 RCX: 0000000000000006
    [10480.313242] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff85249b66
    [10480.315260] RBP: ffff8a497d04b740 R08: 0000000000000001 R09: 0000000000000001
    [10480.317229] R10: ffff8a497d044800 R11: ffff8a495ab93c40 R12: 0000000000000000
    [10480.319169] R13: 0000000000000000 R14: 0000000000000c40 R15: ffffffffc01daf70
    [10480.321104] FS:  00007fa1dc5c0e40(0000) GS:ffff8a497da00000(0000) knlGS:0000000000000000
    [10480.323559] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [10480.325235] CR2: 00007fa1dc5befb8 CR3: 0000000004f8a006 CR4: 0000000000170ea0
    [10480.327259] Call Trace:
    [10480.328286]  ? overwrite_item+0x1f0/0x5a0 [btrfs]
    [10480.329784]  __kmalloc+0x831/0xa20
    [10480.331009]  ? btrfs_get_32+0xb0/0x1d0 [btrfs]
    [10480.332464]  overwrite_item+0x1f0/0x5a0 [btrfs]
    [10480.333948]  log_dir_items+0x2ee/0x570 [btrfs]
    [10480.335413]  log_directory_changes+0x82/0xd0 [btrfs]
    [10480.336926]  btrfs_log_inode+0xc9b/0xda0 [btrfs]
    [10480.338374]  ? init_once+0x20/0x20 [btrfs]
    [10480.339711]  btrfs_log_inode_parent+0x8d3/0xd10 [btrfs]
    [10480.341257]  ? dget_parent+0x97/0x2e0
    [10480.342480]  btrfs_log_dentry_safe+0x3a/0x50 [btrfs]
    [10480.343977]  btrfs_sync_file+0x24b/0x5e0 [btrfs]
    [10480.345381]  do_fsync+0x38/0x70
    [10480.346483]  __x64_sys_fsync+0x10/0x20
    [10480.347703]  do_syscall_64+0x2d/0x70
    [10480.348891]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    [10480.350444] RIP: 0033:0x7fa1dc80970b
    [10480.351642] Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 (...)
    [10480.356952] RSP: 002b:00007fffb3d081d0 EFLAGS: 00000293 ORIG_RAX: 000000000000004a
    [10480.359458] RAX: ffffffffffffffda RBX: 0000562d93d45e40 RCX: 00007fa1dc80970b
    [10480.361426] RDX: 0000562d93d44ab0 RSI: 0000562d93d45e60 RDI: 0000000000000003
    [10480.363367] RBP: 0000000000000001 R08: 0000000000000000 R09: 00007fa1dc7b2a40
    [10480.365317] R10: 0000562d93d0e366 R11: 0000000000000293 R12: 0000000000000001
    [10480.367299] R13: 0000562d93d45290 R14: 0000562d93d45e40 R15: 0000562d93d45e60
    
    Link: https://lore.kernel.org/linux-btrfs/20180713090216.GC575@fnst.localdomain/
    Reported-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    CC: stable@vger.kernel.org # 4.4+
    Tested-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
    Signed-off-by: Filipe Manana <fdmanana@suse.com>
    Reviewed-by: David Sterba <dsterba@suse.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d00557d2b486ec742a9938099646067325d0fbf
Author: Helge Deller <deller@gmx.de>
Date:   Thu Oct 22 11:00:05 2020 +0200

    scsi: mptfusion: Fix null pointer dereferences in mptscsih_remove()
    
    commit 2f4843b172c2c0360ee7792ad98025fae7baefde upstream.
    
    The mptscsih_remove() function triggers a kernel oops if the Scsi_Host
    pointer (ioc->sh) is NULL, as can be seen in this syslog:
    
     ioc0: LSI53C1030 B2: Capabilities={Initiator,Target}
     Begin: Waiting for root file system ...
     scsi host2: error handler thread failed to spawn, error = -4
     mptspi: ioc0: WARNING - Unable to register controller with SCSI subsystem
     Backtrace:
      [<000000001045b7cc>] mptspi_probe+0x248/0x3d0 [mptspi]
      [<0000000040946470>] pci_device_probe+0x1ac/0x2d8
      [<0000000040add668>] really_probe+0x1bc/0x988
      [<0000000040ade704>] driver_probe_device+0x160/0x218
      [<0000000040adee24>] device_driver_attach+0x160/0x188
      [<0000000040adef90>] __driver_attach+0x144/0x320
      [<0000000040ad7c78>] bus_for_each_dev+0xd4/0x158
      [<0000000040adc138>] driver_attach+0x4c/0x80
      [<0000000040adb3ec>] bus_add_driver+0x3e0/0x498
      [<0000000040ae0130>] driver_register+0xf4/0x298
      [<00000000409450c4>] __pci_register_driver+0x78/0xa8
      [<000000000007d248>] mptspi_init+0x18c/0x1c4 [mptspi]
    
    This patch adds the necessary NULL-pointer checks.  Successfully tested on
    a HP C8000 parisc workstation with buggy SCSI drives.
    
    Link: https://lore.kernel.org/r/20201022090005.GA9000@ls3530.fritz.box
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Helge Deller <deller@gmx.de>
    Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e69731a854e269e844fdd64d628991d20d905c4a
Author: Martin Fuzzey <martin.fuzzey@flowbird.group>
Date:   Wed Sep 30 10:36:46 2020 +0200

    w1: mxc_w1: Fix timeout resolution problem leading to bus error
    
    commit c9723750a699c3bd465493ac2be8992b72ccb105 upstream.
    
    On my platform (i.MX53) bus access sometimes fails with
            w1_search: max_slave_count 64 reached, will continue next search.
    
    The reason is the use of jiffies to implement a 200us timeout in
    mxc_w1_ds2_touch_bit().
    On some platforms the jiffies timer resolution is insufficient for this.
    
    Fix by replacing jiffies by ktime_get().
    
    For consistency apply the same change to the other use of jiffies in
    mxc_w1_ds2_reset_bus().
    
    Fixes: f80b2581a706 ("w1: mxc_w1: Optimize mxc_w1_ds2_touch_bit()")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
    Link: https://lore.kernel.org/r/1601455030-6607-1-git-send-email-martin.fuzzey@flowbird.group
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aec3d9d432d9aac82e3dab4cdd5cc7314601f2a8
Author: Wei Huang <wei.huang2@amd.com>
Date:   Sun Oct 18 22:57:41 2020 -0500

    acpi-cpufreq: Honor _PSD table setting on new AMD CPUs
    
    commit 5368512abe08a28525d9b24abbfc2a72493e8dba upstream.
    
    acpi-cpufreq has a old quirk that overrides the _PSD table supplied by
    BIOS on AMD CPUs. However the _PSD table of new AMD CPUs (Family 19h+)
    now accurately reports the P-state dependency of CPU cores. Hence this
    quirk needs to be fixed in order to support new CPUs' frequency control.
    
    Fixes: acd316248205 ("acpi-cpufreq: Add quirk to disable _PSD usage on all AMD CPUs")
    Signed-off-by: Wei Huang <wei.huang2@amd.com>
    [ rjw: Subject edit ]
    Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa0562e23c438f2616aed8174ae05bcdc255389a
Author: Alex Hung <alex.hung@canonical.com>
Date:   Sun Sep 13 16:34:03 2020 -0600

    ACPI: video: use ACPI backlight for HP 635 Notebook
    
    commit b226faab4e7890bbbccdf794e8b94276414f9058 upstream.
    
    The default backlight interface is AMD's radeon_bl0 which does not
    work on this system, so use the ACPI backlight interface on it
    instead.
    
    BugLink: https://bugs.launchpad.net/bugs/1894667
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Alex Hung <alex.hung@canonical.com>
    [ rjw: Changelog edits ]
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 71fa83623923fb561337713cf8ee9757fb7fe4ff
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Sun Sep 27 22:50:42 2020 +0100

    ACPI / extlog: Check for RDMSR failure
    
    commit 7cecb47f55e00282f972a1e0b09136c8cd938221 upstream.
    
    extlog_init() uses rdmsrl() to read an MSR, which on older CPUs
    provokes a error message at boot:
    
        unchecked MSR access error: RDMSR from 0x179 at rIP: 0xcd047307 (native_read_msr+0x7/0x40)
    
    Use rdmsrl_safe() instead, and return -ENODEV if it fails.
    
    Reported-by: jim@photojim.ca
    References: https://bugs.debian.org/971058
    Cc: All applicable <stable@vger.kernel.org>
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 20a7c9a7966c842698ac22bfaae48da7f4cc9935
Author: Ashish Sangwan <ashishsangwan2@gmail.com>
Date:   Mon Oct 5 02:22:43 2020 -0700

    NFS: fix nfs_path in case of a rename retry
    
    commit 247db73560bc3e5aef6db50c443c3c0db115bc93 upstream.
    
    We are generating incorrect path in case of rename retry because
    we are restarting from wrong dentry. We should restart from the
    dentry which was received in the call to nfs_path.
    
    CC: stable@vger.kernel.org
    Signed-off-by: Ashish Sangwan <ashishsangwan2@gmail.com>
    Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92728df6369842bea92fcaa02251ae904b1faa2b
Author: Marek Behún <marek.behun@nic.cz>
Date:   Fri Sep 18 00:32:58 2020 +0200

    leds: bcm6328, bcm6358: use devres LED registering function
    
    commit ff5c89d44453e7ad99502b04bf798a3fc32c758b upstream.
    
    These two drivers do not provide remove method and use devres for
    allocation of other resources, yet they use led_classdev_register
    instead of the devres variant, devm_led_classdev_register.
    
    Fix this.
    
    Signed-off-by: Marek Behún <marek.behun@nic.cz>
    Cc: Álvaro Fernández Rojas <noltari@gmail.com>
    Cc: Kevin Cernekee <cernekee@gmail.com>
    Cc: Jaedon Shin <jaedon.shin@gmail.com>
    Signed-off-by: Pavel Machek <pavel@ucw.cz>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa4504ee6e8f5e6cd2a63e3698fafc6fe6136d6a
Author: Song Liu <songliubraving@fb.com>
Date:   Mon Oct 5 09:35:21 2020 -0700

    md/raid5: fix oops during stripe resizing
    
    commit b44c018cdf748b96b676ba09fdbc5b34fc443ada upstream.
    
    KoWei reported crash during raid5 reshape:
    
    [ 1032.252932] Oops: 0002 [#1] SMP PTI
    [...]
    [ 1032.252943] RIP: 0010:memcpy_erms+0x6/0x10
    [...]
    [ 1032.252947] RSP: 0018:ffffba1ac0c03b78 EFLAGS: 00010286
    [ 1032.252949] RAX: 0000784ac0000000 RBX: ffff91bec3d09740 RCX: 0000000000001000
    [ 1032.252951] RDX: 0000000000001000 RSI: ffff91be6781c000 RDI: 0000784ac0000000
    [ 1032.252953] RBP: ffffba1ac0c03bd8 R08: 0000000000001000 R09: ffffba1ac0c03bf8
    [ 1032.252954] R10: 0000000000000000 R11: 0000000000000000 R12: ffffba1ac0c03bf8
    [ 1032.252955] R13: 0000000000001000 R14: 0000000000000000 R15: 0000000000000000
    [ 1032.252958] FS:  0000000000000000(0000) GS:ffff91becf500000(0000) knlGS:0000000000000000
    [ 1032.252959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 1032.252961] CR2: 0000784ac0000000 CR3: 000000031780a002 CR4: 00000000001606e0
    [ 1032.252962] Call Trace:
    [ 1032.252969]  ? async_memcpy+0x179/0x1000 [async_memcpy]
    [ 1032.252977]  ? raid5_release_stripe+0x8e/0x110 [raid456]
    [ 1032.252982]  handle_stripe_expansion+0x15a/0x1f0 [raid456]
    [ 1032.252988]  handle_stripe+0x592/0x1270 [raid456]
    [ 1032.252993]  handle_active_stripes.isra.0+0x3cb/0x5a0 [raid456]
    [ 1032.252999]  raid5d+0x35c/0x550 [raid456]
    [ 1032.253002]  ? schedule+0x42/0xb0
    [ 1032.253006]  ? schedule_timeout+0x10e/0x160
    [ 1032.253011]  md_thread+0x97/0x160
    [ 1032.253015]  ? wait_woken+0x80/0x80
    [ 1032.253019]  kthread+0x104/0x140
    [ 1032.253022]  ? md_start_sync+0x60/0x60
    [ 1032.253024]  ? kthread_park+0x90/0x90
    [ 1032.253027]  ret_from_fork+0x35/0x40
    
    This is because cache_size_mutex was unlocked too early in resize_stripes,
    which races with grow_one_stripe() that grow_one_stripe() allocates a
    stripe with wrong pool_size.
    
    Fix this issue by unlocking cache_size_mutex after updating pool_size.
    
    Cc: <stable@vger.kernel.org> # v4.4+
    Reported-by: KoWei Sung <winders@amazon.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a1632a97f5d6343cced4e5dde406ee391271c90e
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Sep 7 18:11:24 2020 +0200

    ARM: dts: s5pv210: remove dedicated 'audio-subsystem' node
    
    [ Upstream commit 6c17a2974abf68a58517f75741b15c4aba42b4b8 ]
    
    The 'audio-subsystem' node is an artificial creation, not representing
    real hardware.  The hardware is described by its nodes - AUDSS clock
    controller and I2S0.
    
    Remove the 'audio-subsystem' node along with its undocumented compatible
    to fix dtbs_check warnings like:
    
      audio-subsystem: $nodename:0: 'audio-subsystem' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Jonathan Bakker <xc-racer2@live.ca>
    Link: https://lore.kernel.org/r/20200907161141.31034-9-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit b2c9418de138f43f8d7aa8defde933045bcbf8ba
Author: Krzysztof Kozlowski <krzk@kernel.org>
Date:   Mon Sep 7 18:11:23 2020 +0200

    ARM: dts: s5pv210: move PMU node out of clock controller
    
    [ Upstream commit bb98fff84ad1ea321823759edaba573a16fa02bd ]
    
    The Power Management Unit (PMU) is a separate device which has little
    common with clock controller.  Moving it to one level up (from clock
    controller child to SoC) allows to remove fake simple-bus compatible and
    dtbs_check warnings like:
    
      clock-controller@e0100000: $nodename:0:
        'clock-controller@e0100000' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$'
    
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Tested-by: Jonathan Bakker <xc-racer2@live.ca>
    Link: https://lore.kernel.org/r/20200907161141.31034-8-krzk@kernel.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 31967e2804aff04ac99ecea3b42ab36e4ac6eba6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Wed Aug 26 14:37:59 2020 +0300

    memory: emif: Remove bogus debugfs error handling
    
    [ Upstream commit fd22781648080cc400772b3c68aa6b059d2d5420 ]
    
    Callers are generally not supposed to check the return values from
    debugfs functions.  Debugfs functions never return NULL so this error
    handling will never trigger.  (Historically debugfs functions used to
    return a mix of NULL and error pointers but it was eventually deemed too
    complicated for something which wasn't intended to be used in normal
    situations).
    
    Delete all the error handling.
    
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
    Link: https://lore.kernel.org/r/20200826113759.GF393664@mwanda
    Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6b93e109c18719223bf1f27a0a0829d2d0c36cdf
Author: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Date:   Wed Oct 14 22:01:09 2020 +0530

    gfs2: add validation checks for size of superblock
    
    [ Upstream commit 0ddc5154b24c96f20e94d653b0a814438de6032b ]
    
    In gfs2_check_sb(), no validation checks are performed with regards to
    the size of the superblock.
    syzkaller detected a slab-out-of-bounds bug that was primarily caused
    because the block size for a superblock was set to zero.
    A valid size for a superblock is a power of 2 between 512 and PAGE_SIZE.
    Performing validation checks and ensuring that the size of the superblock
    is valid fixes this bug.
    
    Reported-by: syzbot+af90d47a37376844e731@syzkaller.appspotmail.com
    Tested-by: syzbot+af90d47a37376844e731@syzkaller.appspotmail.com
    Suggested-by: Andrew Price <anprice@redhat.com>
    Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    [Minor code reordering.]
    Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 8665b1ccc3a35e4288b9bb909a71b38f93844077
Author: Jan Kara <jack@suse.cz>
Date:   Thu Oct 15 13:03:30 2020 +0200

    ext4: Detect already used quota file early
    
    [ Upstream commit e0770e91424f694b461141cbc99adf6b23006b60 ]
    
    When we try to use file already used as a quota file again (for the same
    or different quota type), strange things can happen. At the very least
    lockdep annotations may be wrong but also inode flags may be wrongly set
    / reset. When the file is used for two quota types at once we can even
    corrupt the file and likely crash the kernel. Catch all these cases by
    checking whether passed file is already used as quota file and bail
    early in that case.
    
    This fixes occasional generic/219 failure due to lockdep complaint.
    
    Reviewed-by: Andreas Dilger <adilger@dilger.ca>
    Reported-by: Ritesh Harjani <riteshh@linux.ibm.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Link: https://lore.kernel.org/r/20201015110330.28716-1-jack@suse.cz
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 35d4cbf24e91629ad6059b13072c21acbdf0c7bd
Author: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Date:   Fri Aug 7 16:59:02 2020 +0530

    drivers: watchdog: rdc321x_wdt: Fix race condition bugs
    
    [ Upstream commit 4b2e7f99cdd314263c9d172bc17193b8b6bba463 ]
    
    In rdc321x_wdt_probe(), rdc321x_wdt_device.queue is initialized
    after misc_register(), hence if ioctl is called before its
    initialization which can call rdc321x_wdt_start() function,
    it will see an uninitialized value of rdc321x_wdt_device.queue,
    hence initialize it before misc_register().
    Also, rdc321x_wdt_device.default_ticks is accessed in reset()
    function called from write callback, thus initialize it before
    misc_register().
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
    Reviewed-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
    Link: https://lore.kernel.org/r/20200807112902.28764-1-madhuparnabhowmik10@gmail.com
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 92d979f05e17349a4224215474fb9e07514b9302
Author: Anant Thazhemadam <anant.thazhemadam@gmail.com>
Date:   Mon Oct 12 09:54:04 2020 +0530

    net: 9p: initialize sun_server.sun_path to have addr's value only when addr is valid
    
    [ Upstream commit 7ca1db21ef8e0e6725b4d25deed1ca196f7efb28 ]
    
    In p9_fd_create_unix, checking is performed to see if the addr (passed
    as an argument) is NULL or not.
    However, no check is performed to see if addr is a valid address, i.e.,
    it doesn't entirely consist of only 0's.
    The initialization of sun_server.sun_path to be equal to this faulty
    addr value leads to an uninitialized variable, as detected by KMSAN.
    Checking for this (faulty addr) and returning a negative error number
    appropriately, resolves this issue.
    
    Link: http://lkml.kernel.org/r/20201012042404.2508-1-anant.thazhemadam@gmail.com
    Reported-by: syzbot+75d51fe5bf4ebe988518@syzkaller.appspotmail.com
    Tested-by: syzbot+75d51fe5bf4ebe988518@syzkaller.appspotmail.com
    Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>
    Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d5e347e84cc4929c7ddb3818b6272677080d0d3b
Author: Tero Kristo <t-kristo@ti.com>
Date:   Mon Sep 7 11:25:59 2020 +0300

    clk: ti: clockdomain: fix static checker warning
    
    [ Upstream commit b7a7943fe291b983b104bcbd2f16e8e896f56590 ]
    
    Fix a memory leak induced by not calling clk_put after doing of_clk_get.
    
    Reported-by: Dan Murphy <dmurphy@ti.com>
    Signed-off-by: Tero Kristo <t-kristo@ti.com>
    Link: https://lore.kernel.org/r/20200907082600.454-3-t-kristo@ti.com
    Signed-off-by: Stephen Boyd <sboyd@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7a86fabaa63e441d5512d74aa8bd3e8e8edd8a0d
Author: Zhao Heming <heming.zhao@suse.com>
Date:   Tue Oct 6 00:00:24 2020 +0800

    md/bitmap: md_bitmap_get_counter returns wrong blocks
    
    [ Upstream commit d837f7277f56e70d82b3a4a037d744854e62f387 ]
    
    md_bitmap_get_counter() has code:
    
    ```
        if (bitmap->bp[page].hijacked ||
            bitmap->bp[page].map == NULL)
            csize = ((sector_t)1) << (bitmap->chunkshift +
                          PAGE_COUNTER_SHIFT - 1);
    ```
    
    The minus 1 is wrong, this branch should report 2048 bits of space.
    With "-1" action, this only report 1024 bit of space.
    
    This bug code returns wrong blocks, but it doesn't inflence bitmap logic:
    1. Most callers focus this function return value (the counter of offset),
       not the parameter blocks.
    2. The bug is only triggered when hijacked is true or map is NULL.
       the hijacked true condition is very rare.
       the "map == null" only true when array is creating or resizing.
    3. Even the caller gets wrong blocks, current code makes caller just to
       call md_bitmap_get_counter() one more time.
    
    Signed-off-by: Zhao Heming <heming.zhao@suse.com>
    Signed-off-by: Song Liu <songliubraving@fb.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 45fd588b27f418616c22866729dcbc7621da0872
Author: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Date:   Fri Sep 4 14:09:58 2020 +0800

    power: supply: test_power: add missing newlines when printing parameters by sysfs
    
    [ Upstream commit c07fa6c1631333f02750cf59f22b615d768b4d8f ]
    
    When I cat some module parameters by sysfs, it displays as follows.
    It's better to add a newline for easy reading.
    
    root@syzkaller:~# cd /sys/module/test_power/parameters/
    root@syzkaller:/sys/module/test_power/parameters# cat ac_online
    onroot@syzkaller:/sys/module/test_power/parameters# cat battery_present
    trueroot@syzkaller:/sys/module/test_power/parameters# cat battery_health
    goodroot@syzkaller:/sys/module/test_power/parameters# cat battery_status
    dischargingroot@syzkaller:/sys/module/test_power/parameters# cat battery_technology
    LIONroot@syzkaller:/sys/module/test_power/parameters# cat usb_online
    onroot@syzkaller:/sys/module/test_power/parameters#
    
    Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
    Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d5bf26ba1d2574727a4ae8e6f491ec62e0fec50
Author: Xie He <xie.he.0141@gmail.com>
Date:   Mon Sep 28 05:56:43 2020 -0700

    drivers/net/wan/hdlc_fr: Correctly handle special skb->protocol values
    
    [ Upstream commit 8306266c1d51aac9aa7aa907fe99032a58c6382c ]
    
    The fr_hard_header function is used to prepend the header to skbs before
    transmission. It is used in 3 situations:
    1) When a control packet is generated internally in this driver;
    2) When a user sends an skb on an Ethernet-emulating PVC device;
    3) When a user sends an skb on a normal PVC device.
    
    These 3 situations need to be handled differently by fr_hard_header.
    Different headers should be prepended to the skb in different situations.
    
    Currently fr_hard_header distinguishes these 3 situations using
    skb->protocol. For situation 1 and 2, a special skb->protocol value
    will be assigned before calling fr_hard_header, so that it can recognize
    these 2 situations. All skb->protocol values other than these special ones
    are treated by fr_hard_header as situation 3.
    
    However, it is possible that in situation 3, the user sends an skb with
    one of the special skb->protocol values. In this case, fr_hard_header
    would incorrectly treat it as situation 1 or 2.
    
    This patch tries to solve this issue by using skb->dev instead of
    skb->protocol to distinguish between these 3 situations. For situation
    1, skb->dev would be NULL; for situation 2, skb->dev->type would be
    ARPHRD_ETHER; and for situation 3, skb->dev->type would be ARPHRD_DLCI.
    
    This way fr_hard_header would be able to distinguish these 3 situations
    correctly regardless what skb->protocol value the user tries to use in
    situation 3.
    
    Cc: Krzysztof Halasa <khc@pm.waw.pl>
    Signed-off-by: Xie He <xie.he.0141@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 0381f86573272ad3af3242bc0b13d1277b2fa814
Author: Oliver Neukum <oneukum@suse.com>
Date:   Thu Sep 17 13:26:00 2020 +0200

    USB: adutux: fix debugging
    
    [ Upstream commit c56150c1bc8da5524831b1dac2eec3c67b89f587 ]
    
    Handling for removal of the controller was missing at one place.
    Add it.
    
    Signed-off-by: Oliver Neukum <oneukum@suse.com>
    Link: https://lore.kernel.org/r/20200917112600.26508-1-oneukum@suse.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 747ba0eab55f7b47c829b7eec89788b62df7c741
Author: Douglas Anderson <dianders@chromium.org>
Date:   Tue Jun 30 15:14:38 2020 -0700

    kgdb: Make "kgdbcon" work properly with "kgdb_earlycon"
    
    [ Upstream commit b18b099e04f450cdc77bec72acefcde7042bd1f3 ]
    
    On my system the kernel processes the "kgdb_earlycon" parameter before
    the "kgdbcon" parameter.  When we setup "kgdb_earlycon" we'll end up
    in kgdb_register_callbacks() and "kgdb_use_con" won't have been set
    yet so we'll never get around to starting "kgdbcon".  Let's remedy
    this by detecting that the IO module was already registered when
    setting "kgdb_use_con" and registering the console then.
    
    As part of this, to avoid pre-declaring things, move the handling of
    the "kgdbcon" further down in the file.
    
    Signed-off-by: Douglas Anderson <dianders@chromium.org>
    Link: https://lore.kernel.org/r/20200630151422.1.I4aa062751ff5e281f5116655c976dff545c09a46@changeid
    Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit ae6df24b20047eb39cb6cfe35779de00b51cea46
Author: John Ogness <john.ogness@linutronix.de>
Date:   Wed Aug 12 09:37:22 2020 +0206

    printk: reduce LOG_BUF_SHIFT range for H8300
    
    [ Upstream commit 550c10d28d21bd82a8bb48debbb27e6ed53262f6 ]
    
    The .bss section for the h8300 is relatively small. A value of
    CONFIG_LOG_BUF_SHIFT that is larger than 19 will create a static
    printk ringbuffer that is too large. Limit the range appropriately
    for the H8300.
    
    Reported-by: kernel test robot <lkp@intel.com>
    Signed-off-by: John Ogness <john.ogness@linutronix.de>
    Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: Petr Mladek <pmladek@suse.com>
    Link: https://lore.kernel.org/r/20200812073122.25412-1-john.ogness@linutronix.de
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4590499cb652e0ed215cc0ec2b981ae597a964b3
Author: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Date:   Sat Aug 22 11:45:28 2020 +0530

    mmc: via-sdmmc: Fix data race bug
    
    [ Upstream commit 87d7ad089b318b4f319bf57f1daa64eb6d1d10ad ]
    
    via_save_pcictrlreg() should be called with host->lock held
    as it writes to pm_pcictrl_reg, otherwise there can be a race
    condition between via_sd_suspend() and via_sdc_card_detect().
    The same pattern is used in the function via_reset_pcictrl()
    as well, where via_save_pcictrlreg() is called with host->lock
    held.
    
    Found by Linux Driver Verification project (linuxtesting.org).
    
    Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
    Link: https://lore.kernel.org/r/20200822061528.7035-1-madhuparnabhowmik10@gmail.com
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 20e2bc0c5e59d11c5c77f8a4b000a3dc0c34c2d4
Author: Sathishkumar Muruganandam <murugana@codeaurora.org>
Date:   Fri Aug 14 13:46:11 2020 +0530

    ath10k: fix VHT NSS calculation when STBC is enabled
    
    [ Upstream commit 99f41b8e43b8b4b31262adb8ac3e69088fff1289 ]
    
    When STBC is enabled, NSTS_SU value need to be accounted for VHT NSS
    calculation for SU case.
    
    Without this fix, 1SS + STBC enabled case was reported wrongly as 2SS
    in radiotap header on monitor mode capture.
    
    Tested-on: QCA9984 10.4-3.10-00047
    
    Signed-off-by: Sathishkumar Muruganandam <murugana@codeaurora.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/1597392971-3897-1-git-send-email-murugana@codeaurora.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 4d1ad4a182034ad0ecee18da59e000e13f7217ef
Author: Tom Rix <trix@redhat.com>
Date:   Mon Jul 20 12:18:45 2020 -0700

    video: fbdev: pvr2fb: initialize variables
    
    [ Upstream commit 8e1ba47c60bcd325fdd097cd76054639155e5d2e ]
    
    clang static analysis reports this repesentative error
    
    pvr2fb.c:1049:2: warning: 1st function call argument
      is an uninitialized value [core.CallAndMessage]
            if (*cable_arg)
            ^~~~~~~~~~~~~~~
    
    Problem is that cable_arg depends on the input loop to
    set the cable_arg[0].  If it does not, then some random
    value from the stack is used.
    
    A similar problem exists for output_arg.
    
    So initialize cable_arg and output_arg.
    
    Signed-off-by: Tom Rix <trix@redhat.com>
    Acked-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200720191845.20115-1-trix@redhat.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit d202032671cea2bdf82830f1370c8f22e25a15d1
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date:   Wed Oct 7 13:55:16 2020 -0700

    xfs: fix realtime bitmap/summary file truncation when growing rt volume
    
    [ Upstream commit f4c32e87de7d66074d5612567c5eac7325024428 ]
    
    The realtime bitmap and summary files are regular files that are hidden
    away from the directory tree.  Since they're regular files, inode
    inactivation will try to purge what it thinks are speculative
    preallocations beyond the incore size of the file.  Unfortunately,
    xfs_growfs_rt forgets to update the incore size when it resizes the
    inodes, with the result that inactivating the rt inodes at unmount time
    will cause their contents to be truncated.
    
    Fix this by updating the incore size when we change the ondisk size as
    part of updating the superblock.  Note that we don't do this when we're
    allocating blocks to the rt inodes because we actually want those blocks
    to get purged if the growfs fails.
    
    This fixes corruption complaints from the online rtsummary checker when
    running xfs/233.  Since that test requires rmap, one can also trigger
    this by growing an rt volume, cycling the mount, and creating rt files.
    
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
    Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 6cfa39e86befbf8543eed50a8d426c9d7ae71748
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Jun 4 13:23:17 2020 +0200

    um: change sigio_spinlock to a mutex
    
    [ Upstream commit f2d05059e15af3f70502074f4e3a504530af504a ]
    
    Lockdep complains at boot:
    
    =============================
    [ BUG: Invalid wait context ]
    5.7.0-05093-g46d91ecd597b #98 Not tainted
    -----------------------------
    swapper/1 is trying to lock:
    0000000060931b98 (&desc[i].request_mutex){+.+.}-{3:3}, at: __setup_irq+0x11d/0x623
    other info that might help us debug this:
    context-{4:4}
    1 lock held by swapper/1:
     #0: 000000006074fed8 (sigio_spinlock){+.+.}-{2:2}, at: sigio_lock+0x1a/0x1c
    stack backtrace:
    CPU: 0 PID: 1 Comm: swapper Not tainted 5.7.0-05093-g46d91ecd597b #98
    Stack:
     7fa4fab0 6028dfd1 0000002a 6008bea5
     7fa50700 7fa50040 7fa4fac0 6028e016
     7fa4fb50 6007f6da 60959c18 00000000
    Call Trace:
     [<60023a0e>] show_stack+0x13b/0x155
     [<6028e016>] dump_stack+0x2a/0x2c
     [<6007f6da>] __lock_acquire+0x515/0x15f2
     [<6007eb50>] lock_acquire+0x245/0x273
     [<6050d9f1>] __mutex_lock+0xbd/0x325
     [<6050dc76>] mutex_lock_nested+0x1d/0x1f
     [<6008e27e>] __setup_irq+0x11d/0x623
     [<6008e8ed>] request_threaded_irq+0x169/0x1a6
     [<60021eb0>] um_request_irq+0x1ee/0x24b
     [<600234ee>] write_sigio_irq+0x3b/0x76
     [<600383ca>] sigio_broken+0x146/0x2e4
     [<60020bd8>] do_one_initcall+0xde/0x281
    
    Because we hold sigio_spinlock and then get into requesting
    an interrupt with a mutex.
    
    Change the spinlock to a mutex to avoid that.
    
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: Richard Weinberger <richard@nod.at>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit f1f2f4d1a9ccdd503a9bc4883fea452db9064daf
Author: Chao Yu <chao@kernel.org>
Date:   Tue Sep 29 09:23:12 2020 +0800

    f2fs: fix to check segment boundary during SIT page readahead
    
    [ Upstream commit 6a257471fa42c8c9c04a875cd3a2a22db148e0f0 ]
    
    As syzbot reported:
    
    kernel BUG at fs/f2fs/segment.h:657!
    invalid opcode: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 16220 Comm: syz-executor.0 Not tainted 5.9.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    RIP: 0010:f2fs_ra_meta_pages+0xa51/0xdc0 fs/f2fs/segment.h:657
    Call Trace:
     build_sit_entries fs/f2fs/segment.c:4195 [inline]
     f2fs_build_segment_manager+0x4b8a/0xa3c0 fs/f2fs/segment.c:4779
     f2fs_fill_super+0x377d/0x6b80 fs/f2fs/super.c:3633
     mount_bdev+0x32e/0x3f0 fs/super.c:1417
     legacy_get_tree+0x105/0x220 fs/fs_context.c:592
     vfs_get_tree+0x89/0x2f0 fs/super.c:1547
     do_new_mount fs/namespace.c:2875 [inline]
     path_mount+0x1387/0x2070 fs/namespace.c:3192
     do_mount fs/namespace.c:3205 [inline]
     __do_sys_mount fs/namespace.c:3413 [inline]
     __se_sys_mount fs/namespace.c:3390 [inline]
     __x64_sys_mount+0x27f/0x300 fs/namespace.c:3390
     do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
     entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    @blkno in f2fs_ra_meta_pages could exceed max segment count, causing panic
    in following sanity check in current_sit_addr(), add check condition to
    avoid this issue.
    
    Reported-by: syzbot+3698081bcf0bb2d12174@syzkaller.appspotmail.com
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 7c58891cef2850a06188f80c3080002919f5f043
Author: Nicholas Piggin <npiggin@gmail.com>
Date:   Mon Sep 14 14:52:18 2020 +1000

    sparc64: remove mm_cpumask clearing to fix kthread_use_mm race
    
    [ Upstream commit bafb056ce27940c9994ea905336aa8f27b4f7275 ]
    
    The de facto (and apparently uncommented) standard for using an mm had,
    thanks to this code in sparc if nothing else, been that you must have a
    reference on mm_users *and that reference must have been obtained with
    mmget()*, i.e., from a thread with a reference to mm_users that had used
    the mm.
    
    The introduction of mmget_not_zero() in commit d2005e3f41d4
    ("userfaultfd: don't pin the user memory in userfaultfd_file_create()")
    allowed mm_count holders to aoperate on user mappings asynchronously
    from the actual threads using the mm, but they were not to load those
    mappings into their TLB (i.e., walking vmas and page tables is okay,
    kthread_use_mm() is not).
    
    io_uring 2b188cc1bb857 ("Add io_uring IO interface") added code which
    does a kthread_use_mm() from a mmget_not_zero() refcount.
    
    The problem with this is code which previously assumed mm == current->mm
    and mm->mm_users == 1 implies the mm will remain single-threaded at
    least until this thread creates another mm_users reference, has now
    broken.
    
    arch/sparc/kernel/smp_64.c:
    
        if (atomic_read(&mm->mm_users) == 1) {
            cpumask_copy(mm_cpumask(mm), cpumask_of(cpu));
            goto local_flush_and_out;
        }
    
    vs fs/io_uring.c
    
        if (unlikely(!(ctx->flags & IORING_SETUP_SQPOLL) ||
                     !mmget_not_zero(ctx->sqo_mm)))
            return -EFAULT;
        kthread_use_mm(ctx->sqo_mm);
    
    mmget_not_zero() could come in right after the mm_users == 1 test, then
    kthread_use_mm() which sets its CPU in the mm_cpumask. That update could
    be lost if cpumask_copy() occurs afterward.
    
    I propose we fix this by allowing mmget_not_zero() to be a first-class
    reference, and not have this obscure undocumented and unchecked
    restriction.
    
    The basic fix for sparc64 is to remove its mm_cpumask clearing code. The
    optimisation could be effectively restored by sending IPIs to mm_cpumask
    members and having them remove themselves from mm_cpumask. This is more
    tricky so I leave it as an exercise for someone with a sparc64 SMP.
    powerpc has a (currently similarly broken) example.
    
    Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
    Acked-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200914045219.3736466-4-npiggin@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 81d6bbd45a28e617249cac22f498db5cc4e6b839
Author: Oliver O'Halloran <oohall@gmail.com>
Date:   Tue Aug 4 10:54:05 2020 +1000

    powerpc/powernv/smp: Fix spurious DBG() warning
    
    [ Upstream commit f6bac19cf65c5be21d14a0c9684c8f560f2096dd ]
    
    When building with W=1 we get the following warning:
    
     arch/powerpc/platforms/powernv/smp.c: In function ‘pnv_smp_cpu_kill_self’:
     arch/powerpc/platforms/powernv/smp.c:276:16: error: suggest braces around
            empty body in an ‘if’ statement [-Werror=empty-body]
       276 |      cpu, srr1);
           |                ^
     cc1: all warnings being treated as errors
    
    The full context is this block:
    
     if (srr1 && !generic_check_cpu_restart(cpu))
            DBG("CPU%d Unexpected exit while offline srr1=%lx!\n",
                            cpu, srr1);
    
    When building with DEBUG undefined DBG() expands to nothing and GCC emits
    the warning due to the lack of braces around an empty statement.
    
    Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
    Reviewed-by: Joel Stanley <joel@jms.id.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Link: https://lore.kernel.org/r/20200804005410.146094-2-oohall@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

commit 5ca3fb31d499b4811deeabbf7b3dc5f867f9a6aa
Author: Chao Yu <chao@kernel.org>
Date:   Sun Aug 28 22:00:12 2016 +0800

    f2fs crypto: avoid unneeded memory allocation in ->readdir
    
    commit e06f86e61d7a67fe6e826010f57aa39c674f4b1b upstream.
    
    When decrypting dirents in ->readdir, fscrypt_fname_disk_to_usr won't
    change content of original encrypted dirent, we don't need to allocate
    additional buffer for storing mirror of it, so get rid of it.
    
    [This backport fixes a regression in 4.4-stable caused by commit
    11a6e8f89521 ("f2fs: check memory boundary by insane namelen"), which
    depended on this missing commit.  This bad backport broke f2fs
    encryption because it moved the incrementing of 'bit_pos' to earlier in
    f2fs_fill_dentries() without accounting for it being used in the
    encrypted dir case.  This caused readdir() on encrypted directories to
    start failing.  Tested with 'kvm-xfstests -c f2fs -g encrypt'.]
    
    Signed-off-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7e7ce0810d34f90f4551247ac21c6ac61afb6b23
Author: Eric Biggers <ebiggers@google.com>
Date:   Tue Jan 22 16:20:21 2019 -0800

    fscrypt: return -EXDEV for incompatible rename or link into encrypted dir
    
    commit f5e55e777cc93eae1416f0fa4908e8846b6d7825 upstream.
    
    Currently, trying to rename or link a regular file, directory, or
    symlink into an encrypted directory fails with EPERM when the source
    file is unencrypted or is encrypted with a different encryption policy,
    and is on the same mountpoint.  It is correct for the operation to fail,
    but the choice of EPERM breaks tools like 'mv' that know to copy rather
    than rename if they see EXDEV, but don't know what to do with EPERM.
    
    Our original motivation for EPERM was to encourage users to securely
    handle their data.  Encrypting files by "moving" them into an encrypted
    directory can be insecure because the unencrypted data may remain in
    free space on disk, where it can later be recovered by an attacker.
    It's much better to encrypt the data from the start, or at least try to
    securely delete the source data e.g. using the 'shred' program.
    
    However, the current behavior hasn't been effective at achieving its
    goal because users tend to be confused, hack around it, and complain;
    see e.g. https://github.com/google/fscrypt/issues/76.  And in some cases
    it's actually inconsistent or unnecessary.  For example, 'mv'-ing files
    between differently encrypted directories doesn't work even in cases
    where it can be secure, such as when in userspace the same passphrase
    protects both directories.  Yet, you *can* already 'mv' unencrypted
    files into an encrypted directory if the source files are on a different
    mountpoint, even though doing so is often insecure.
    
    There are probably better ways to teach users to securely handle their
    files.  For example, the 'fscrypt' userspace tool could provide a
    command that migrates unencrypted files into an encrypted directory,
    acting like 'shred' on the source files and providing appropriate
    warnings depending on the type of the source filesystem and disk.
    
    Receiving errors on unimportant files might also force some users to
    disable encryption, thus making the behavior counterproductive.  It's
    desirable to make encryption as unobtrusive as possible.
    
    Therefore, change the error code from EPERM to EXDEV so that tools
    looking for EXDEV will fall back to a copy.
    
    This, of course, doesn't prevent users from still doing the right things
    to securely manage their files.  Note that this also matches the
    behavior when a file is renamed between two project quota hierarchies;
    so there's precedent for using EXDEV for things other than mountpoints.
    
    xfstests generic/398 will require an update with this change.
    
    [Rewritten from an earlier patch series by Michael Halcrow.]
    
    Cc: Michael Halcrow <mhalcrow@google.com>
    Cc: Joe Richey <joerichey@google.com>
    Signed-off-by: Eric Biggers <ebiggers@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01d14b28b5114a71eb8d366b5981558e562d3d18
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date:   Thu Sep 17 15:09:20 2020 +0200

    ata: sata_rcar: Fix DMA boundary mask
    
    commit df9c590986fdb6db9d5636d6cd93bc919c01b451 upstream.
    
    Before commit 9495b7e92f716ab2 ("driver core: platform: Initialize
    dma_parms for platform devices"), the R-Car SATA device didn't have DMA
    parameters.  Hence the DMA boundary mask supplied by its driver was
    silently ignored, as __scsi_init_queue() doesn't check the return value
    of dma_set_seg_boundary(), and the default value of 0xffffffff was used.
    
    Now the device has gained DMA parameters, the driver-supplied value is
    used, and the following warning is printed on Salvator-XS:
    
        DMA-API: sata_rcar ee300000.sata: mapping sg segment across boundary [start=0x00000000ffffe000] [end=0x00000000ffffefff] [boundary=0x000000001ffffffe]
        WARNING: CPU: 5 PID: 38 at kernel/dma/debug.c:1233 debug_dma_map_sg+0x298/0x300
    
    (the range of start/end values depend on whether IOMMU support is
     enabled or not)
    
    The issue here is that SATA_RCAR_DMA_BOUNDARY doesn't have bit 0 set, so
    any typical end value, which is odd, will trigger the check.
    
    Fix this by increasing the DMA boundary value by 1.
    
    This also fixes the following WRITE DMA EXT timeout issue:
    
        # dd if=/dev/urandom of=/mnt/de1/file1-1024M bs=1M count=1024
        ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
        ata1.00: failed command: WRITE DMA EXT
        ata1.00: cmd 35/00:00:00:e6:0c/00:0a:00:00:00/e0 tag 0 dma 1310720 out
        res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
        ata1.00: status: { DRDY }
    
    as seen by Shimoda-san since commit 429120f3df2dba2b ("block: fix
    splitting segments on boundary masks").
    
    Fixes: 8bfbeed58665dbbf ("sata_rcar: correct 'sata_rcar_sht'")
    Fixes: 9495b7e92f716ab2 ("driver core: platform: Initialize dma_parms for platform devices")
    Fixes: 429120f3df2dba2b ("block: fix splitting segments on boundary masks")
    Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
    Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c7cfafcb966dc6df733abd8f8de5620082f77674
Author: Gustavo A. R. Silva <gustavo@embeddedor.com>
Date:   Mon Apr 27 14:50:37 2020 -0500

    mtd: lpddr: Fix bad logic in print_drs_error
    
    commit 1c9c02bb22684f6949d2e7ddc0a3ff364fd5a6fc upstream.
    
    Update logic for broken test. Use a more common logging style.
    
    It appears the logic in this function is broken for the
    consecutive tests of
    
            if (prog_status & 0x3)
                    ...
            else if (prog_status & 0x2)
                    ...
            else (prog_status & 0x1)
                    ...
    
    Likely the first test should be
    
            if ((prog_status & 0x3) == 0x3)
    
    Found by inspection of include files using printk.
    
    Fixes: eb3db27507f7 ("[MTD] LPDDR PFOW definition")
    Cc: stable@vger.kernel.org
    Reported-by: Joe Perches <joe@perches.com>
    Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
    Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Link: https://lore.kernel.org/linux-mtd/3fb0e29f5b601db8be2938a01d974b00c8788501.1588016644.git.gustavo@embeddedor.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a373602a898a071898db3797b3e2f9a5cb27ef18
Author: Tung Nguyen <tung.q.nguyen@dektech.com.au>
Date:   Tue Oct 27 10:24:03 2020 +0700

    tipc: fix memory leak caused by tipc_buf_append()
    
    [ Upstream commit ceb1eb2fb609c88363e06618b8d4bbf7815a4e03 ]
    
    Commit ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()")
    replaced skb_unshare() with skb_copy() to not reduce the data reference
    counter of the original skb intentionally. This is not the correct
    way to handle the cloned skb because it causes memory leak in 2
    following cases:
     1/ Sending multicast messages via broadcast link
      The original skb list is cloned to the local skb list for local
      destination. After that, the data reference counter of each skb
      in the original list has the value of 2. This causes each skb not
      to be freed after receiving ACK:
      tipc_link_advance_transmq()
      {
       ...
       /* release skb */
       __skb_unlink(skb, &l->transmq);
       kfree_skb(skb); <-- memory exists after being freed
      }
    
     2/ Sending multicast messages via replicast link
      Similar to the above case, each skb cannot be freed after purging
      the skb list:
      tipc_mcast_xmit()
      {
       ...
       __skb_queue_purge(pkts); <-- memory exists after being freed
      }
    
    This commit fixes this issue by using skb_unshare() instead. Besides,
    to avoid use-after-free error reported by KASAN, the pointer to the
    fragment is set to NULL before calling skb_unshare() to make sure that
    the original skb is not freed after freeing the fragment 2 times in
    case skb_unshare() returns NULL.
    
    Fixes: ed42989eab57 ("tipc: fix the skb_unshare() in tipc_buf_append()")
    Acked-by: Jon Maloy <jmaloy@redhat.com>
    Reported-by: Thang Hoang Ngo <thang.h.ngo@dektech.com.au>
    Signed-off-by: Tung Nguyen <tung.q.nguyen@dektech.com.au>
    Reviewed-by: Xin Long <lucien.xin@gmail.com>
    Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
    Link: https://lore.kernel.org/r/20201027032403.1823-1-tung.q.nguyen@dektech.com.au
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 50050c67b8a10eae96b252c0a3379603fdd74d0c
Author: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Date:   Mon Oct 26 05:21:30 2020 -0500

    ravb: Fix bit fields checking in ravb_hwtstamp_get()
    
    [ Upstream commit 68b9f0865b1ef545da180c57d54b82c94cb464a4 ]
    
    In the function ravb_hwtstamp_get() in ravb_main.c with the existing
    values for RAVB_RXTSTAMP_TYPE_V2_L2_EVENT (0x2) and RAVB_RXTSTAMP_TYPE_ALL
    (0x6)
    
    if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_V2_L2_EVENT)
            config.rx_filter = HWTSTAMP_FILTER_PTP_V2_L2_EVENT;
    else if (priv->tstamp_rx_ctrl & RAVB_RXTSTAMP_TYPE_ALL)
            config.rx_filter = HWTSTAMP_FILTER_ALL;
    
    if the test on RAVB_RXTSTAMP_TYPE_ALL should be true,
    it will never be reached.
    
    This issue can be verified with 'hwtstamp_config' testing program
    (tools/testing/selftests/net/hwtstamp_config.c). Setting filter type
    to ALL and subsequent retrieving it gives incorrect value:
    
    $ hwtstamp_config eth0 OFF ALL
    flags = 0
    tx_type = OFF
    rx_filter = ALL
    $ hwtstamp_config eth0
    flags = 0
    tx_type = OFF
    rx_filter = PTP_V2_L2_EVENT
    
    Correct this by converting if-else's to switch.
    
    Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
    Reported-by: Julia Lawall <julia.lawall@inria.fr>
    Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
    Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
    Link: https://lore.kernel.org/r/20201026102130.29368-1-andrew_gabbasov@mentor.com
    Signed-off-by: Jakub Kicinski <kuba@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c66b46d1b9edf2b69ac3d08c70fab829366f68d
Author: Michael Schaller <misch@google.com>
Date:   Fri Sep 25 09:45:02 2020 +0200

    efivarfs: Replace invalid slashes with exclamation marks in dentries.
    
    commit 336af6a4686d885a067ecea8c3c3dd129ba4fc75 upstream.
    
    Without this patch efivarfs_alloc_dentry creates dentries with slashes in
    their name if the respective EFI variable has slashes in its name. This in
    turn causes EIO on getdents64, which prevents a complete directory listing
    of /sys/firmware/efi/efivars/.
    
    This patch replaces the invalid shlashes with exclamation marks like
    kobject_set_name_vargs does for /sys/firmware/efi/vars/ to have consistently
    named dentries under /sys/firmware/efi/vars/ and /sys/firmware/efi/efivars/.
    
    Signed-off-by: Michael Schaller <misch@google.com>
    Link: https://lore.kernel.org/r/20200925074502.150448-1-misch@google.com
    Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
    Signed-off-by: dann frazier <dann.frazier@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45f9e9e613e095fa0edecce6a39c548d5c8657e4
Author: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
Date:   Mon Feb 20 18:52:11 2017 +0530

    powerpc/powernv/opal-dump : Use IRQ_HANDLED instead of numbers in interrupt handler
    
    commit b29336c0e1785a28bc40a9fd47c2321671e9792e upstream.
    
    Fixes: 8034f715f ("powernv/opal-dump: Convert to irq domain")
    
    Converts all the return explicit number to a more proper IRQ_HANDLED,
    which looks proper incase of interrupt handler returning case.
    
    Here, It also removes error message like "nobody cared" which was
    getting unveiled while returning -1 or 0 from handler.
    
    Signed-off-by: Mukesh Ojha <mukesh02@linux.vnet.ibm.com>
    Reviewed-by: Vasant Hegde <hegdevasant@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Cc: Kamal Mostafa <kamal@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0ca3565a06136cb2979376e6bb6ef54f66253992
Author: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Date:   Thu Sep 17 08:56:11 2020 +0200

    scripts/setlocalversion: make git describe output more reliable
    
    commit 548b8b5168c90c42e88f70fcf041b4ce0b8e7aa8 upstream.
    
    When building for an embedded target using Yocto, we're sometimes
    observing that the version string that gets built into vmlinux (and
    thus what uname -a reports) differs from the path under /lib/modules/
    where modules get installed in the rootfs, but only in the length of
    the -gabc123def suffix. Hence modprobe always fails.
    
    The problem is that Yocto has the concept of "sstate" (shared state),
    which allows different developers/buildbots/etc. to share build
    artifacts, based on a hash of all the metadata that went into building
    that artifact - and that metadata includes all dependencies (e.g. the
    compiler used etc.). That normally works quite well; usually a clean
    build (without using any sstate cache) done by one developer ends up
    being binary identical to a build done on another host. However, one
    thing that can cause two developers to end up with different builds
    [and thus make one's vmlinux package incompatible with the other's
    kernel-dev package], which is not captured by the metadata hashing, is
    this `git describe`: The output of that can be affected by
    
    (1) git version: before 2.11 git defaulted to a minimum of 7, since
    2.11 (git.git commit e6c587) the default is dynamic based on the
    number of objects in the repo
    (2) hence even if both run the same git version, the output can differ
    based on how many remotes are being tracked (or just lots of local
    development branches or plain old garbage)
    (3) and of course somebody could have a core.abbrev config setting in
    ~/.gitconfig
    
    So in order to avoid `uname -a` output relying on such random details
    of the build environment which are rather hard to ensure are
    consistent between developers and buildbots, make sure the abbreviated
    sha1 always consists of exactly 12 hex characters. That is consistent
    with the current rule for -stable patches, and is almost always enough
    to identify the head commit unambigously - in the few cases where it
    does not, the v5.4.3-00021- prefix would certainly nail it down.
    
    [Adapt to `` vs $() differences between 5.4 and upstream.]
    Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
    Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1bda44d10745ebce82172468ad2d8cd9c1cf48d5
Author: NeilBrown <neilb@suse.com>
Date:   Fri Aug 18 17:12:51 2017 +1000

    SUNRPC: ECONNREFUSED should cause a rebind.
    
    commit fd01b2597941d9c17980222999b0721648b383b8 upstream.
    
    If you
     - mount and NFSv3 filesystem
     - do some file locking which requires the server
       to make a GRANT call back
     - unmount
     - mount again and do the same locking
    
    then the second attempt at locking suffers a 30 second delay.
    Unmounting and remounting causes lockd to stop and restart,
    which causes it to bind to a new port.
    The server still thinks the old port is valid and gets ECONNREFUSED
    when trying to contact it.
    ECONNREFUSED should be seen as a hard error that is not worth
    retrying.  Rebinding is the only reasonable response.
    
    This patch forces a rebind if that makes sense.
    
    Signed-off-by: NeilBrown <neilb@suse.com>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Cc: Calum Mackay <calum.mackay@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>