commit 3c8c23092588a23bf1856a64f58c37f477a413be
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Fri May 7 10:49:26 2021 +0200

    Linux 4.19.190
    
    Tested-by: Jon Hunter <jonathanh@nvidia.com>
    Tested-by: Shuah Khan <skhan@linuxfoundation.org>
    Tested-by: Jason Self <jason@bluehome.net>
    Tested-by: Guenter Roeck <linux@roeck-us.net>
    Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
    Tested-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
    Tested-by: Pavel Machek (CIP) <pavel@denx.de>
    Tested-by: Hulk Robot <hulkrobot@huawei.com>
    Link: https://lore.kernel.org/r/20210505120503.781531508@linuxfoundation.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a130ed5212c3dfff88065db4f62c29bb184748d4
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Mon Apr 12 12:00:37 2021 +0200

    ovl: allow upperdir inside lowerdir
    
    commit 708fa01597fa002599756bf56a96d0de1677375c upstream.
    
    Commit 146d62e5a586 ("ovl: detect overlapping layers") made sure we don't
    have overlapping layers, but it also broke the arguably valid use case of
    
     mount -olowerdir=/,upperdir=/subdir,..
    
    where upperdir overlaps lowerdir on the same filesystem.  This has been
    causing regressions.
    
    Revert the check, but only for the specific case where upperdir and/or
    workdir are subdirectories of lowerdir.  Any other overlap (e.g. lowerdir
    is subdirectory of upperdir, etc) case is crazy, so leave the check in
    place for those.
    
    Overlaps are detected at lookup time too, so reverting the mount time check
    should be safe.
    
    Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
    Cc: <stable@vger.kernel.org> # v5.2
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7642c940f11e4135471c3f1df484cea899060e87
Author: Mark Pearson <markpearson@lenovo.com>
Date:   Wed Apr 7 17:20:15 2021 -0400

    platform/x86: thinkpad_acpi: Correct thermal sensor allocation
    
    commit 6759e18e5cd8745a5dfc5726e4a3db5281ec1639 upstream.
    
    On recent Thinkpad platforms it was reported that temp sensor 11 was
    always incorrectly displaying 66C. It turns out the reason for this is
    that this location in EC RAM is not a temperature sensor but is the
    power supply ID (offset 0xC2).
    
    Based on feedback from the Lenovo firmware team the EC RAM version can
    be determined and for the current version (3) only the 0x78 to 0x7F
    range is used for temp sensors. I don't have any details for earlier
    versions so I have left the implementation unaltered there.
    
    Note - in this block only 0x78 and 0x79 are officially designated (CPU &
    GPU sensors). The use of the other locations in the block will vary from
    platform to platform; but the existing logic to detect a sensor presence
    holds.
    
    Signed-off-by: Mark Pearson <markpearson@lenovo.com>
    Link: https://lore.kernel.org/r/20210407212015.298222-1-markpearson@lenovo.com
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ca3c407ba6a78184aa7cafe101ce36e8e862be08
Author: Chris Chiu <chris.chiu@canonical.com>
Date:   Wed Apr 21 01:46:51 2021 +0800

    USB: Add reset-resume quirk for WD19's Realtek Hub
    
    commit ca91fd8c7643d93bfc18a6fec1a0d3972a46a18a upstream.
    
    Realtek Hub (0bda:5487) in Dell Dock WD19 sometimes fails to work
    after the system resumes from suspend with remote wakeup enabled
    device connected:
    [ 1947.640907] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
    [ 1947.641208] usb 5-2.3-port5: cannot disable (err = -71)
    [ 1947.641401] hub 5-2.3:1.0: hub_ext_port_status failed (err = -71)
    [ 1947.641450] usb 5-2.3-port4: cannot reset (err = -71)
    
    Information of this hub:
    T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 10 Spd=480  MxCh= 5
    D:  Ver= 2.10 Cls=09(hub  ) Sub=00 Prot=02 MxPS=64 #Cfgs=  1
    P:  Vendor=0bda ProdID=5487 Rev= 1.47
    S:  Manufacturer=Dell Inc.
    S:  Product=Dell dock
    C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
    I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=01 Driver=hub
    E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
    I:* If#= 0 Alt= 1 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=02 Driver=hub
    E:  Ad=81(I) Atr=03(Int.) MxPS=   1 Ivl=256ms
    
    The failure results from the ETIMEDOUT by chance when turning on
    the suspend feature for the specified port of the hub. The port
    seems to be in an unknown state so the hub_activate during resume
    fails the hub_port_status, then the hub will fail to work.
    
    The quirky hub needs the reset-resume quirk to function correctly.
    
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
    Cc: stable <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210420174651.6202-1-chris.chiu@canonical.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit add1c1a8446a7d966041391cf3885fe76604e11a
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date:   Mon Apr 12 21:54:53 2021 +0800

    USB: Add LPM quirk for Lenovo ThinkPad USB-C Dock Gen2 Ethernet
    
    commit 8f23fe35ff1e5491b4d279323a8209a31f03ae65 upstream.
    
    This is another branded 8153 device that doesn't work well with LPM
    enabled:
    [ 400.597506] r8152 5-1.1:1.0 enx482ae3a2a6f0: Tx status -71
    
    So disable LPM to resolve the issue.
    
    Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
    BugLink: https://bugs.launchpad.net/bugs/1922651
    Link: https://lore.kernel.org/r/20210412135455.791971-1-kai.heng.feng@canonical.com
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 04491ecf82ebe94426c9866ecac8e53ee8ce6516
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Apr 7 16:45:49 2021 +0200

    ALSA: usb-audio: Add MIDI quirk for Vox ToneLab EX
    
    commit 64f40f9be14106e7df0098c427cb60be645bddb7 upstream.
    
    ToneLab EX guitar pedal device requires the same quirk like ToneLab ST
    for supporting the MIDI.
    
    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212593
    Cc: <stable@vger.kernel.org>
    Link: https://lore.kernel.org/r/20210407144549.1530-1-tiwai@suse.de
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d1273e1a735e758413af40b12f30434e13fc426e
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Sat Apr 17 11:13:39 2021 +0200

    iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_gen2_enqueue_hcmd()
    
    commit e7020bb068d8be50a92f48e36b236a1a1ef9282e upstream.
    
    Analogically to what we did in 2800aadc18a6 ("iwlwifi: Fix softirq/hardirq
    disabling in iwl_pcie_enqueue_hcmd()"), we must apply the same fix to
    iwl_pcie_gen2_enqueue_hcmd(), as it's being called from exactly the same
    contexts.
    
    Reported-by: Heiner Kallweit <hkallweit1@gmail.com
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2104171112390.18270@cbobk.fhfr.pm
    Signed-off-by: Jari Ruusu <jariruusu@protonmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0e2dfdc74a7f4036127356d42ea59388f153f42c
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Apr 30 16:21:46 2021 +0200

    bpf: Fix masking negation logic upon negative dst register
    
    commit b9b34ddbe2076ade359cd5ce7537d5ed019e9807 upstream.
    
    The negation logic for the case where the off_reg is sitting in the
    dst register is not correct given then we cannot just invert the add
    to a sub or vice versa. As a fix, perform the final bitwise and-op
    unconditionally into AX from the off_reg, then move the pointer from
    the src to dst and finally use AX as the source for the original
    pointer arithmetic operation such that the inversion yields a correct
    result. The single non-AX mov in between is possible given constant
    blinding is retaining it as it's not an immediate based operation.
    
    Fixes: 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Tested-by: Piotr Krysiuk <piotras@gmail.com>
    Reviewed-by: Piotr Krysiuk <piotras@gmail.com>
    Reviewed-by: John Fastabend <john.fastabend@gmail.com>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 502adca1f04b4edee1c40d5c2e26867d35b33f5f
Author: Romain Naour <romain.naour@gmail.com>
Date:   Tue Apr 20 22:12:10 2021 +0100

    mips: Do not include hi and lo in clobber list for R6
    
    commit 1d7ba0165d8206ac073f7ac3b14fc0836b66eae7 upstream
    
    >From [1]
    "GCC 10 (PR 91233) won't silently allow registers that are not
    architecturally available to be present in the clobber list anymore,
    resulting in build failure for mips*r6 targets in form of:
    ...
    .../sysdep.h:146:2: error: the register ‘lo’ cannot be clobbered in ‘asm’ for the current target
      146 |  __asm__ volatile (      \
          |  ^~~~~~~
    
    This is because base R6 ISA doesn't define hi and lo registers w/o DSP
    extension. This patch provides the alternative clobber list for r6 targets
    that won't include those registers."
    
    Since kernel 5.4 and mips support for generic vDSO [2], the kernel fail to
    build for mips r6 cpus with gcc 10 for the same reason as glibc.
    
    [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=020b2a97bb15f807c0482f0faee2184ed05bcad8
    [2] '24640f233b46 ("mips: Add support for generic vDSO")'
    
    Signed-off-by: Romain Naour <romain.naour@gmail.com>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
    Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36442e983ec04b7c13ef081e285c319a2a3fc832
Author: Jiri Kosina <jkosina@suse.cz>
Date:   Tue Mar 2 11:26:55 2021 +0100

    iwlwifi: Fix softirq/hardirq disabling in iwl_pcie_enqueue_hcmd()
    
    commit 2800aadc18a64c96b051bcb7da8a7df7d505db3f upstream.
    
    It's possible for iwl_pcie_enqueue_hcmd() to be called with hard IRQs
    disabled (e.g. from LED core). We can't enable BHs in such a situation.
    
    Turn the unconditional BH-enable/BH-disable code into
    hardirq-disable/conditional-enable.
    
    This fixes the warning below.
    
     WARNING: CPU: 1 PID: 1139 at kernel/softirq.c:178 __local_bh_enable_ip+0xa5/0xf0
     CPU: 1 PID: 1139 Comm: NetworkManager Not tainted 5.12.0-rc1-00004-gb4ded168af79 #7
     Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017
     RIP: 0010:__local_bh_enable_ip+0xa5/0xf0
     Code: f7 69 e8 ee 23 14 00 fb 66 0f 1f 44 00 00 65 8b 05 f0 f4 f7 69 85 c0 74 3f 48 83 c4 08 5b c3 65 8b 05 9b fe f7 69 85 c0 75 8e <0f> 0b eb 8a 48 89 3c 24 e8 4e 20 14 00 48 8b 3c 24 eb 91 e8 13 4e
     RSP: 0018:ffffafd580b13298 EFLAGS: 00010046
     RAX: 0000000000000000 RBX: 0000000000000201 RCX: 0000000000000000
     RDX: 0000000000000003 RSI: 0000000000000201 RDI: ffffffffc1272389
     RBP: ffff96517ae4c018 R08: 0000000000000001 R09: 0000000000000000
     R10: ffffafd580b13178 R11: 0000000000000001 R12: ffff96517b060000
     R13: 0000000000000000 R14: ffffffff80000000 R15: 0000000000000001
     FS:  00007fc604ebefc0(0000) GS:ffff965267480000(0000) knlGS:0000000000000000
     CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
     CR2: 000055fb3fef13b2 CR3: 0000000109112004 CR4: 00000000003706e0
     Call Trace:
      ? _raw_spin_unlock_bh+0x1f/0x30
      iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi]
      iwl_trans_txq_send_hcmd+0x6c/0x430 [iwlwifi]
      iwl_trans_send_cmd+0x88/0x170 [iwlwifi]
      ? lock_acquire+0x277/0x3d0
      iwl_mvm_send_cmd+0x32/0x80 [iwlmvm]
      iwl_mvm_led_set+0xc2/0xe0 [iwlmvm]
      ? led_trigger_event+0x46/0x70
      led_trigger_event+0x46/0x70
      ieee80211_do_open+0x5c5/0xa20 [mac80211]
      ieee80211_open+0x67/0x90 [mac80211]
      __dev_open+0xd4/0x150
      __dev_change_flags+0x19e/0x1f0
      dev_change_flags+0x23/0x60
      do_setlink+0x30d/0x1230
      ? lock_is_held_type+0xb4/0x120
      ? __nla_validate_parse.part.7+0x57/0xcb0
      ? __lock_acquire+0x2e1/0x1a50
      __rtnl_newlink+0x560/0x910
      ? __lock_acquire+0x2e1/0x1a50
      ? __lock_acquire+0x2e1/0x1a50
      ? lock_acquire+0x277/0x3d0
      ? sock_def_readable+0x5/0x290
      ? lock_is_held_type+0xb4/0x120
      ? find_held_lock+0x2d/0x90
      ? sock_def_readable+0xb3/0x290
      ? lock_release+0x166/0x2a0
      ? lock_is_held_type+0x90/0x120
      rtnl_newlink+0x47/0x70
      rtnetlink_rcv_msg+0x25c/0x470
      ? netlink_deliver_tap+0x97/0x3e0
      ? validate_linkmsg+0x350/0x350
      netlink_rcv_skb+0x50/0x100
      netlink_unicast+0x1b2/0x280
      netlink_sendmsg+0x336/0x450
      sock_sendmsg+0x5b/0x60
      ____sys_sendmsg+0x1ed/0x250
      ? copy_msghdr_from_user+0x5c/0x90
      ___sys_sendmsg+0x88/0xd0
      ? lock_is_held_type+0xb4/0x120
      ? find_held_lock+0x2d/0x90
      ? lock_release+0x166/0x2a0
      ? __fget_files+0xfe/0x1d0
      ? __sys_sendmsg+0x5e/0xa0
      __sys_sendmsg+0x5e/0xa0
      ? lockdep_hardirqs_on_prepare+0xd9/0x170
      do_syscall_64+0x33/0x80
      entry_SYSCALL_64_after_hwframe+0x44/0xae
     RIP: 0033:0x7fc605c9572d
     Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 da ee ff ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 2e ef ff ff 48
     RSP: 002b:00007fffc83789f0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
     RAX: ffffffffffffffda RBX: 000055ef468570c0 RCX: 00007fc605c9572d
     RDX: 0000000000000000 RSI: 00007fffc8378a30 RDI: 000000000000000c
     RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000000
     R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
     R13: 00007fffc8378b80 R14: 00007fffc8378b7c R15: 0000000000000000
     irq event stamp: 170785
     hardirqs last  enabled at (170783): [<ffffffff9609a8c2>] __local_bh_enable_ip+0x82/0xf0
     hardirqs last disabled at (170784): [<ffffffff96a8613d>] _raw_read_lock_irqsave+0x8d/0x90
     softirqs last  enabled at (170782): [<ffffffffc1272389>] iwl_pcie_enqueue_hcmd+0x5d9/0xa00 [iwlwifi]
     softirqs last disabled at (170785): [<ffffffffc1271ec6>] iwl_pcie_enqueue_hcmd+0x116/0xa00 [iwlwifi]
    
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc3
    Acked-by: Luca Coelho <luciano.coelho@intel.com>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2103021125430.12405@cbobk.fhfr.pm
    Signed-off-by: Jari Ruusu <jariruusu@protonmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9e0c8b649d213877e84c1940b302d937e019a43
Author: Phillip Potter <phil@philpotter.co.uk>
Date:   Thu Apr 1 23:36:07 2021 +0100

    net: usb: ax88179_178a: initialize local variables before use
    
    commit bd78980be1a68d14524c51c4b4170782fada622b upstream.
    
    Use memset to initialize local array in drivers/net/usb/ax88179_178a.c, and
    also set a local u16 and u32 variable to 0. Fixes a KMSAN found uninit-value bug
    reported by syzbot at:
    https://syzkaller.appspot.com/bug?id=00371c73c72f72487c1d0bfe0cc9d00de339d5aa
    
    Reported-by: syzbot+4993e4a0e237f1b53747@syzkaller.appspotmail.com
    Signed-off-by: Phillip Potter <phil@philpotter.co.uk>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9a5ba778b50d6c6c50597febf3a30387a80ac05d
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Apr 13 16:01:00 2021 +0200

    ACPI: x86: Call acpi_boot_table_init() after acpi_table_upgrade()
    
    commit 6998a8800d73116187aad542391ce3b2dd0f9e30 upstream.
    
    Commit 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by
    ACPI tables") attempted to address an issue with reserving the memory
    occupied by ACPI tables, but it broke the initrd-based table override
    mechanism relied on by multiple users.
    
    To restore the initrd-based ACPI table override functionality, move
    the acpi_boot_table_init() invocation in setup_arch() on x86 after
    the acpi_table_upgrade() one.
    
    Fixes: 1a1c130ab757 ("ACPI: tables: x86: Reserve memory occupied by ACPI tables")
    Reported-by: Hans de Goede <hdegoede@redhat.com>
    Tested-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Cc: George Kennedy <george.kennedy@oracle.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7d329dd0a1b3302e10f0f25ef08538c7598d118f
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Tue Mar 23 20:26:52 2021 +0100

    ACPI: tables: x86: Reserve memory occupied by ACPI tables
    
    commit 1a1c130ab7575498eed5bcf7220037ae09cd1f8a upstream.
    
    The following problem has been reported by George Kennedy:
    
     Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail
     in __free_pages_core()") the following use after free occurs
     intermittently when ACPI tables are accessed.
    
     BUG: KASAN: use-after-free in ibft_init+0x134/0xc49
     Read of size 4 at addr ffff8880be453004 by task swapper/0/1
     CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1-7a7fd0d #1
     Call Trace:
      dump_stack+0xf6/0x158
      print_address_description.constprop.9+0x41/0x60
      kasan_report.cold.14+0x7b/0xd4
      __asan_report_load_n_noabort+0xf/0x20
      ibft_init+0x134/0xc49
      do_one_initcall+0xc4/0x3e0
      kernel_init_freeable+0x5af/0x66b
      kernel_init+0x16/0x1d0
      ret_from_fork+0x22/0x30
    
     ACPI tables mapped via kmap() do not have their mapped pages
     reserved and the pages can be "stolen" by the buddy allocator.
    
    Apparently, on the affected system, the ACPI table in question is
    not located in "reserved" memory, like ACPI NVS or ACPI Data, that
    will not be used by the buddy allocator, so the memory occupied by
    that table has to be explicitly reserved to prevent the buddy
    allocator from using it.
    
    In order to address this problem, rearrange the initialization of the
    ACPI tables on x86 to locate the initial tables earlier and reserve
    the memory occupied by them.
    
    The other architectures using ACPI should not be affected by this
    change.
    
    Link: https://lore.kernel.org/linux-acpi/1614802160-29362-1-git-send-email-george.kennedy@oracle.com/
    Reported-by: George Kennedy <george.kennedy@oracle.com>
    Tested-by: George Kennedy <george.kennedy@oracle.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
    Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5cd7d4573c1032cb5bc6591583e0d3c613ed9f2a
Author: Gao Xiang <hsiangkao@redhat.com>
Date:   Thu Jul 30 01:58:01 2020 +0800

    erofs: fix extended inode could cross boundary
    
    commit 0dcd3c94e02438f4a571690e26f4ee997524102a upstream.
    
    Each ondisk inode should be aligned with inode slot boundary
    (32-byte alignment) because of nid calculation formula, so all
    compact inodes (32 byte) cannot across page boundary. However,
    extended inode is now 64-byte form, which can across page boundary
    in principle if the location is specified on purpose, although
    it's hard to be generated by mkfs due to the allocation policy
    and rarely used by Android use case now mainly for > 4GiB files.
    
    For now, only two fields `i_ctime_nsec` and `i_nlink' couldn't
    be read from disk properly and cause out-of-bound memory read
    with random value.
    
    Let's fix now.
    
    Fixes: 431339ba9042 ("staging: erofs: add inode operations")
    Cc: <stable@vger.kernel.org> # 4.19+
    Link: https://lore.kernel.org/r/20200729175801.GA23973@xiangao.remote.csb
    Reviewed-by: Chao Yu <yuchao0@huawei.com>
    Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
    [ Gao Xiang: resolve non-trivial conflicts for latest 4.19.y. ]
    Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>