1. 11 Oct, 2020 1 commit
    • Kirill Smelkov's avatar
      [4.9-debian] Fix build under Debian9 · a0cf4c42
      Kirill Smelkov authored
      Previously I was building this package from under Debian10 and it was
      working ok. But trying to build in pristine Debian9 environment revealed
      that there is not debhelper-compat support at that version. Adjust
      control correspondingly (see debian/changelog for details). I've verified
      that the resulting built deb is exactly the same as it was before this
      change when built on Debian10.
      a0cf4c42
  2. 08 Oct, 2020 6 commits
    • Kirill Smelkov's avatar
      d9349bde
    • Kirill Smelkov's avatar
      [4.9-debian] nxd-fuse: Kill commented PACKAGE_VERSION in nxd-fuse-dkms.dkms · acc841ba
      Kirill Smelkov authored
      DKMS passes in debian package version thanks to
      PACKAGE_VERSION=#MODULE_VERSION# on next line.
      acc841ba
    • Kirill Smelkov's avatar
      [4.9-debian] nxd-fuse: Hook into udev/systemd so that... · 565efccc
      Kirill Smelkov authored
      [4.9-debian] nxd-fuse: Hook into udev/systemd so that /sys/fs/fuse/connections/ is automatically mounted
      
      on nxd-fuse.ko module load. The same is done for std fuse module (note
      "*" in KERNEL="*fuse" - rule for std module uses KERNEl="fuse" - note no
      "*" there)
      565efccc
    • Kirill Smelkov's avatar
      b28b4d6d
    • Kirill Smelkov's avatar
      [4.9 backport] fuse: allow filesystems to have precise control over data cache · ae273c49
      Kirill Smelkov authored
      On networked filesystems file data can be changed externally.  FUSE
      provides notification messages for filesystem to inform kernel that
      metadata or data region of a file needs to be invalidated in local page
      cache. That provides the basis for filesystem implementations to invalidate
      kernel cache explicitly based on observed filesystem-specific events.
      
      FUSE has also "automatic" invalidation mode(*) when the kernel
      automatically invalidates data cache of a file if it sees mtime change.  It
      also automatically invalidates whole data cache of a file if it sees file
      size being changed.
      
      The automatic mode has corresponding capability - FUSE_AUTO_INVAL_DATA.
      However, due to probably historical reason, that capability controls only
      whether mtime change should be resulting in automatic invalidation or
      not. A change in file size always results in invalidating whole data cache
      of a file irregardless of whether FUSE_AUTO_INVAL_DATA was negotiated(+).
      
      The filesystem I write[1] represents data arrays stored in networked
      database as local files suitable for mmap. It is read-only filesystem -
      changes to data are committed externally via database interfaces and the
      filesystem only glues data into contiguous file streams suitable for mmap
      and traditional array processing. The files are big - starting from
      hundreds gigabytes and more. The files change regularly, and frequently by
      data being appended to their end. The size of files thus changes
      frequently.
      
      If a file was accessed locally and some part of its data got into page
      cache, we want that data to stay cached unless there is memory pressure, or
      unless corresponding part of the file was actually changed. However current
      FUSE behaviour - when it sees file size change - is to invalidate the whole
      file. The data cache of the file is thus completely lost even on small size
      change, and despite that the filesystem server is careful to accurately
      translate database changes into FUSE invalidation messages to kernel.
      
      Let's fix it: if a filesystem, through new FUSE_EXPLICIT_INVAL_DATA
      capability, indicates to kernel that it is fully responsible for data cache
      invalidation, then the kernel won't invalidate files data cache on size
      change and only truncate that cache to new size in case the size decreased.
      
      (*) see 72d0d248 "fuse: add FUSE_AUTO_INVAL_DATA init flag",
      eed2179e "fuse: invalidate inode mapping if mtime changes"
      
      (+) in writeback mode the kernel does not invalidate data cache on file
      size change, but neither it allows the filesystem to set the size due to
      external event (see 8373200b "fuse: Trust kernel i_size only")
      
      [1] https://lab.nexedi.com/kirr/wendelin.core/blob/a50f1d9f/wcfs/wcfs.go#L20Signed-off-by: Kirill Smelkov's avatarKirill Smelkov <kirr@nexedi.com>
      Signed-off-by: 's avatarMiklos Szeredi <mszeredi@redhat.com>
      ae273c49
    • Kirill Smelkov's avatar
      176ef8f1
  3. 01 Oct, 2020 33 commits
    • Greg Kroah-Hartman's avatar
    • Jiri Slaby's avatar
      ata: sata_mv, avoid trigerrable BUG_ON · a12763bd
      Jiri Slaby authored
      commit e9f691d8 upstream.
      
      There are several reports that the BUG_ON on unsupported command in
      mv_qc_prep can be triggered under some circumstances:
      https://bugzilla.suse.com/show_bug.cgi?id=1110252
      https://serverfault.com/questions/888897/raid-problems-after-power-outage
      https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652185
      https://bugs.centos.org/view.php?id=14998
      
      Let sata_mv handle the failure gracefully: warn about that incl. the
      failed command number and return an AC_ERR_INVALID error. We can do that
      now thanks to the previous patch.
      
      Remove also the long-standing FIXME.
      
      [v2] use %.2x as commands are defined as hexa.
      Signed-off-by: 's avatarJiri Slaby <jslaby@suse.cz>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: linux-ide@vger.kernel.org
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a12763bd
    • Jiri Slaby's avatar
      ata: make qc_prep return ata_completion_errors · 6cf0ac58
      Jiri Slaby authored
      commit 95364f36 upstream.
      
      In case a driver wants to return an error from qc_prep, return enum
      ata_completion_errors. sata_mv is one of those drivers -- see the next
      patch. Other drivers return the newly defined AC_ERR_OK.
      
      [v2] use enum ata_completion_errors and AC_ERR_OK.
      Signed-off-by: 's avatarJiri Slaby <jslaby@suse.cz>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: linux-ide@vger.kernel.org
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6cf0ac58
    • Jiri Slaby's avatar
      ata: define AC_ERR_OK · 9961f297
      Jiri Slaby authored
      commit 25937580 upstream.
      
      Since we will return enum ata_completion_errors from qc_prep in the next
      patch, let's define AC_ERR_OK to mark the OK status.
      Signed-off-by: 's avatarJiri Slaby <jslaby@suse.cz>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: linux-ide@vger.kernel.org
      Signed-off-by: 's avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9961f297
    • Nick Desaulniers's avatar
      lib/string.c: implement stpcpy · 586d6f17
      Nick Desaulniers authored
      commit 1e1b6d63 upstream.
      
      LLVM implemented a recent "libcall optimization" that lowers calls to
      `sprintf(dest, "%s", str)` where the return value is used to
      `stpcpy(dest, str) - dest`.
      
      This generally avoids the machinery involved in parsing format strings.
      `stpcpy` is just like `strcpy` except it returns the pointer to the new
      tail of `dest`.  This optimization was introduced into clang-12.
      
      Implement this so that we don't observe linkage failures due to missing
      symbol definitions for `stpcpy`.
      
      Similar to last year's fire drill with: commit 5f074f3e
      ("lib/string.c: implement a basic bcmp")
      
      The kernel is somewhere between a "freestanding" environment (no full
      libc) and "hosted" environment (many symbols from libc exist with the
      same type, function signature, and semantics).
      
      As Peter Anvin notes, there's not really a great way to inform the
      compiler that you're targeting a freestanding environment but would like
      to opt-in to some libcall optimizations (see pr/47280 below), rather
      than opt-out.
      
      Arvind notes, -fno-builtin-* behaves slightly differently between GCC
      and Clang, and Clang is missing many __builtin_* definitions, which I
      consider a bug in Clang and am working on fixing.
      
      Masahiro summarizes the subtle distinction between compilers justly:
        To prevent transformation from foo() into bar(), there are two ways in
        Clang to do that; -fno-builtin-foo, and -fno-builtin-bar.  There is
        only one in GCC; -fno-buitin-foo.
      
      (Any difference in that behavior in Clang is likely a bug from a missing
      __builtin_* definition.)
      
      Masahiro also notes:
        We want to disable optimization from foo() to bar(),
        but we may still benefit from the optimization from
        foo() into something else. If GCC implements the same transform, we
        would run into a problem because it is not -fno-builtin-bar, but
        -fno-builtin-foo that disables that optimization.
      
        In this regard, -fno-builtin-foo would be more future-proof than
        -fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
        may want to prevent calls from foo() being optimized into calls to
        bar(), but we still may want other optimization on calls to foo().
      
      It seems that compilers today don't quite provide the fine grain control
      over which libcall optimizations pseudo-freestanding environments would
      prefer.
      
      Finally, Kees notes that this interface is unsafe, so we should not
      encourage its use.  As such, I've removed the declaration from any
      header, but it still needs to be exported to avoid linkage errors in
      modules.
      Reported-by: 's avatarSami Tolvanen <samitolvanen@google.com>
      Suggested-by: 's avatarAndy Lavr <andy.lavr@gmail.com>
      Suggested-by: 's avatarArvind Sankar <nivedita@alum.mit.edu>
      Suggested-by: 's avatarJoe Perches <joe@perches.com>
      Suggested-by: 's avatarKees Cook <keescook@chromium.org>
      Suggested-by: 's avatarMasahiro Yamada <masahiroy@kernel.org>
      Suggested-by: 's avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: 's avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: 's avatarAndrew Morton <akpm@linux-foundation.org>
      Tested-by: 's avatarNathan Chancellor <natechancellor@gmail.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lkml.kernel.org/r/20200914161643.938408-1-ndesaulniers@google.com
      Link: https://bugs.llvm.org/show_bug.cgi?id=47162
      Link: https://bugs.llvm.org/show_bug.cgi?id=47280
      Link: https://github.com/ClangBuiltLinux/linux/issues/1126
      Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
      Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
      Link: https://reviews.llvm.org/D85963Signed-off-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      586d6f17
    • Masami Hiramatsu's avatar
      kprobes: Fix to check probe enabled before disarm_kprobe_ftrace() · 9b55d84d
      Masami Hiramatsu authored
      commit 3031313e upstream.
      
      Commit 0cb2f137 ("kprobes: Fix NULL pointer dereference at
      kprobe_ftrace_handler") fixed one bug but not completely fixed yet.
      If we run a kprobe_module.tc of ftracetest, kernel showed a warning
      as below.
      
      # ./ftracetest test.d/kprobe/kprobe_module.tc
      === Ftrace unit tests ===
      [1] Kprobe dynamic event - probing module
      ...
      [   22.400215] ------------[ cut here ]------------
      [   22.400962] Failed to disarm kprobe-ftrace at trace_printk_irq_work+0x0/0x7e [trace_printk] (-2)
      [   22.402139] WARNING: CPU: 7 PID: 200 at kernel/kprobes.c:1091 __disarm_kprobe_ftrace.isra.0+0x7e/0xa0
      [   22.403358] Modules linked in: trace_printk(-)
      [   22.404028] CPU: 7 PID: 200 Comm: rmmod Not tainted 5.9.0-rc2+ #66
      [   22.404870] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
      [   22.406139] RIP: 0010:__disarm_kprobe_ftrace.isra.0+0x7e/0xa0
      [   22.406947] Code: 30 8b 03 eb c9 80 3d e5 09 1f 01 00 75 dc 49 8b 34 24 89 c2 48 c7 c7 a0 c2 05 82 89 45 e4 c6 05 cc 09 1f 01 01 e8 a9 c7 f0 ff <0f> 0b 8b 45 e4 eb b9 89 c6 48 c7 c7 70 c2 05 82 89 45 e4 e8 91 c7
      [   22.409544] RSP: 0018:ffffc90000237df0 EFLAGS: 00010286
      [   22.410385] RAX: 0000000000000000 RBX: ffffffff83066024 RCX: 0000000000000000
      [   22.411434] RDX: 0000000000000001 RSI: ffffffff810de8d3 RDI: ffffffff810de8d3
      [   22.412687] RBP: ffffc90000237e10 R08: 0000000000000001 R09: 0000000000000001
      [   22.413762] R10: 0000000000000000 R11: 0000000000000001 R12: ffff88807c478640
      [   22.414852] R13: ffffffff8235ebc0 R14: ffffffffa00060c0 R15: 0000000000000000
      [   22.415941] FS:  00000000019d48c0(0000) GS:ffff88807d7c0000(0000) knlGS:0000000000000000
      [   22.417264] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   22.418176] CR2: 00000000005bb7e3 CR3: 0000000078f7a000 CR4: 00000000000006a0
      [   22.419309] Call Trace:
      [   22.419990]  kill_kprobe+0x94/0x160
      [   22.420652]  kprobes_module_callback+0x64/0x230
      [   22.421470]  notifier_call_chain+0x4f/0x70
      [   22.422184]  blocking_notifier_call_chain+0x49/0x70
      [   22.422979]  __x64_sys_delete_module+0x1ac/0x240
      [   22.423733]  do_syscall_64+0x38/0x50
      [   22.424366]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [   22.425176] RIP: 0033:0x4bb81d
      [   22.425741] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e0 ff ff ff f7 d8 64 89 01 48
      [   22.428726] RSP: 002b:00007ffc70fef008 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
      [   22.430169] RAX: ffffffffffffffda RBX: 00000000019d48a0 RCX: 00000000004bb81d
      [   22.431375] RDX: 0000000000000000 RSI: 0000000000000880 RDI: 00007ffc70fef028
      [   22.432543] RBP: 0000000000000880 R08: 00000000ffffffff R09: 00007ffc70fef320
      [   22.433692] R10: 0000000000656300 R11: 0000000000000246 R12: 00007ffc70fef028
      [   22.434635] R13: 0000000000000000 R14: 0000000000000002 R15: 0000000000000000
      [   22.435682] irq event stamp: 1169
      [   22.436240] hardirqs last  enabled at (1179): [<ffffffff810df542>] console_unlock+0x422/0x580
      [   22.437466] hardirqs last disabled at (1188): [<ffffffff810df19b>] console_unlock+0x7b/0x580
      [   22.438608] softirqs last  enabled at (866): [<ffffffff81c0038e>] __do_softirq+0x38e/0x490
      [   22.439637] softirqs last disabled at (859): [<ffffffff81a00f42>] asm_call_on_stack+0x12/0x20
      [   22.440690] ---[ end trace 1e7ce7e1e4567276 ]---
      [   22.472832] trace_kprobe: This probe might be able to register after target module is loaded. Continue.
      
      This is because the kill_kprobe() calls disarm_kprobe_ftrace() even
      if the given probe is not enabled. In that case, ftrace_set_filter_ip()
      fails because the given probe point is not registered to ftrace.
      
      Fix to check the given (going) probe is enabled before invoking
      disarm_kprobe_ftrace().
      
      Link: https://lkml.kernel.org/r/159888672694.1411785.5987998076694782591.stgit@devnote2
      
      Fixes: 0cb2f137 ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: "Naveen N . Rao" <naveen.n.rao@linux.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Muchun Song <songmuchun@bytedance.com>
      Cc: Chengming Zhou <zhouchengming@bytedance.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: 's avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b55d84d
    • Wei Li's avatar
      MIPS: Add the missing 'CPU_1074K' into __get_cpu_type() · c8a9c4f1
      Wei Li authored
      [ Upstream commit e393fbe6 ]
      
      Commit 442e14a2 ("MIPS: Add 1074K CPU support explicitly.") split
      1074K from the 74K as an unique CPU type, while it missed to add the
      'CPU_1074K' in __get_cpu_type(). So let's add it back.
      
      Fixes: 442e14a2 ("MIPS: Add 1074K CPU support explicitly.")
      Signed-off-by: 's avatarWei Li <liwei391@huawei.com>
      Signed-off-by: 's avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      c8a9c4f1
    • Tom Rix's avatar
      ALSA: asihpi: fix iounmap in error handler · c93d30f5
      Tom Rix authored
      [ Upstream commit 472eb391 ]
      
      clang static analysis flags this problem
      hpioctl.c:513:7: warning: Branch condition evaluates to
        a garbage value
                      if (pci.ap_mem_base[idx]) {
                          ^~~~~~~~~~~~~~~~~~~~
      
      If there is a failure in the middle of the memory space loop,
      only some of the memory spaces need to be cleaned up.
      
      At the error handler, idx holds the number of successful
      memory spaces mapped.  So rework the handler loop to use the
      old idx.
      
      There is a second problem, the memory space loop conditionally
      iomaps()/sets the mem_base so it is necessay to initize pci.
      
      Fixes: 719f82d3 ("ALSA: Add support of AudioScience ASI boards")
      Signed-off-by: 's avatarTom Rix <trix@redhat.com>
      Link: https://lore.kernel.org/r/20200913165230.17166-1-trix@redhat.comSigned-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      c93d30f5
    • Linus Lüssing's avatar
      batman-adv: mcast: fix duplicate mcast packets in BLA backbone from mesh · f3474ef3
      Linus Lüssing authored
      [ Upstream commit 74c09b72 ]
      
      Scenario:
      * Multicast frame send from mesh to a BLA backbone (multiple nodes
        with their bat0 bridged together, with BLA enabled)
      
      Issue:
      * BLA backbone nodes receive the frame multiple times on bat0,
        once from mesh->bat0 and once from each backbone_gw from LAN
      
      For unicast, a node will send only to the best backbone gateway
      according to the TQ. However for multicast we currently cannot determine
      if multiple destination nodes share the same backbone if they don't share
      the same backbone with us. So we need to keep sending the unicasts to
      all backbone gateways and let the backbone gateways decide which one
      will forward the frame. We can use the CLAIM mechanism to make this
      decision.
      
      One catch: The batman-adv gateway feature for DHCP packets potentially
      sends multicast packets in the same batman-adv unicast header as the
      multicast optimizations code. And we are not allowed to drop those even
      if we did not claim the source address of the sender, as for such
      packets there is only this one multicast-in-unicast packet.
      
      How can we distinguish the two cases?
      
      The gateway feature uses a batman-adv unicast 4 address header. While
      the multicast-to-unicasts feature uses a simple, 3 address batman-adv
      unicast header. So let's use this to distinguish.
      
      Fixes: fe2da6ff ("batman-adv: check incoming packet type for bla")
      Signed-off-by: 's avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: 's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: 's avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f3474ef3
    • Sven Eckelmann's avatar
      batman-adv: Add missing include for in_interrupt() · be23ff8b
      Sven Eckelmann authored
      [ Upstream commit 4bba9dab ]
      
      The fix for receiving (internally generated) bla packets outside the
      interrupt context introduced the usage of in_interrupt(). But this
      functionality is only defined in linux/preempt.h which was not included
      with the same patch.
      
      Fixes: 279e89b2 ("batman-adv: bla: use netif_rx_ni when not in interrupt context")
      Signed-off-by: 's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: 's avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      be23ff8b
    • Eric Dumazet's avatar
      mac802154: tx: fix use-after-free · 20191c79
      Eric Dumazet authored
      [ Upstream commit 0ff4628f ]
      
      syzbot reported a bug in ieee802154_tx() [1]
      
      A similar issue in ieee802154_xmit_worker() is also fixed in this patch.
      
      [1]
      BUG: KASAN: use-after-free in ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
      Read of size 4 at addr ffff8880251a8c70 by task syz-executor.3/928
      
      CPU: 0 PID: 928 Comm: syz-executor.3 Not tainted 5.9.0-rc3-syzkaller #0
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      Call Trace:
       __dump_stack lib/dump_stack.c:77 [inline]
       dump_stack+0x198/0x1fd lib/dump_stack.c:118
       print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
       __kasan_report mm/kasan/report.c:513 [inline]
       kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
       ieee802154_tx+0x3d2/0x480 net/mac802154/tx.c:88
       ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
       __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
       netdev_start_xmit include/linux/netdevice.h:4648 [inline]
       dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
       packet_snd net/packet/af_packet.c:2989 [inline]
       packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      RIP: 0033:0x45d5b9
      Code: 5d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
      RSP: 002b:00007fc98e749c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
      RAX: ffffffffffffffda RBX: 000000000002ccc0 RCX: 000000000045d5b9
      RDX: 0000000000000000 RSI: 0000000020007780 RDI: 000000000000000b
      RBP: 000000000118d020 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000246 R12: 000000000118cfec
      R13: 00007fff690c720f R14: 00007fc98e74a9c0 R15: 000000000118cfec
      
      Allocated by task 928:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track mm/kasan/common.c:56 [inline]
       __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
       slab_post_alloc_hook mm/slab.h:518 [inline]
       slab_alloc_node mm/slab.c:3254 [inline]
       kmem_cache_alloc_node+0x136/0x3e0 mm/slab.c:3574
       __alloc_skb+0x71/0x550 net/core/skbuff.c:198
       alloc_skb include/linux/skbuff.h:1094 [inline]
       alloc_skb_with_frags+0x92/0x570 net/core/skbuff.c:5771
       sock_alloc_send_pskb+0x72a/0x880 net/core/sock.c:2348
       packet_alloc_skb net/packet/af_packet.c:2837 [inline]
       packet_snd net/packet/af_packet.c:2932 [inline]
       packet_sendmsg+0x19fb/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Freed by task 928:
       kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
       kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
       kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
       __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
       __cache_free mm/slab.c:3418 [inline]
       kmem_cache_free.part.0+0x74/0x1e0 mm/slab.c:3693
       kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:622
       __kfree_skb net/core/skbuff.c:679 [inline]
       consume_skb net/core/skbuff.c:838 [inline]
       consume_skb+0xcf/0x160 net/core/skbuff.c:832
       __dev_kfree_skb_any+0x9c/0xc0 net/core/dev.c:3107
       fakelb_hw_xmit+0x20e/0x2a0 drivers/net/ieee802154/fakelb.c:81
       drv_xmit_async net/mac802154/driver-ops.h:16 [inline]
       ieee802154_tx+0x282/0x480 net/mac802154/tx.c:81
       ieee802154_subif_start_xmit+0xbe/0xe4 net/mac802154/tx.c:130
       __netdev_start_xmit include/linux/netdevice.h:4634 [inline]
       netdev_start_xmit include/linux/netdevice.h:4648 [inline]
       dev_direct_xmit+0x4e9/0x6e0 net/core/dev.c:4203
       packet_snd net/packet/af_packet.c:2989 [inline]
       packet_sendmsg+0x2413/0x5290 net/packet/af_packet.c:3014
       sock_sendmsg_nosec net/socket.c:651 [inline]
       sock_sendmsg+0xcf/0x120 net/socket.c:671
       ____sys_sendmsg+0x6e8/0x810 net/socket.c:2353
       ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
       __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
       do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
       entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      The buggy address belongs to the object at ffff8880251a8c00
       which belongs to the cache skbuff_head_cache of size 224
      The buggy address is located 112 bytes inside of
       224-byte region [ffff8880251a8c00, ffff8880251a8ce0)
      The buggy address belongs to the page:
      page:0000000062b6a4f1 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x251a8
      flags: 0xfffe0000000200(slab)
      raw: 00fffe0000000200 ffffea0000435c88 ffffea00028b6c08 ffff8880a9055d00
      raw: 0000000000000000 ffff8880251a80c0 000000010000000c 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff8880251a8b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff8880251a8b80: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc
      >ffff8880251a8c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                                   ^
       ffff8880251a8c80: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
       ffff8880251a8d00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
      
      Fixes: 409c3b0c ("mac802154: tx: move stats tx increment")
      Signed-off-by: 's avatarEric Dumazet <edumazet@google.com>
      Reported-by: 's avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Alexander Aring <alex.aring@gmail.com>
      Cc: Stefan Schmidt <stefan@datenfreihafen.org>
      Cc: linux-wpan@vger.kernel.org
      Link: https://lore.kernel.org/r/20200908104025.4009085-1-edumazet@google.comSigned-off-by: 's avatarStefan Schmidt <stefan@datenfreihafen.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      20191c79
    • Linus Lüssing's avatar
      batman-adv: mcast/TT: fix wrongly dropped or rerouted packets · ae1ff3f5
      Linus Lüssing authored
      [ Upstream commit 7dda5b33 ]
      
      The unicast packet rerouting code makes several assumptions. For
      instance it assumes that there is always exactly one destination in the
      TT. This breaks for multicast frames in a unicast packets in several ways:
      
      For one thing if there is actually no TT entry and the destination node
      was selected due to the multicast tvlv flags it announced. Then an
      intermediate node will wrongly drop the packet.
      
      For another thing if there is a TT entry but the TTVN of this entry is
      newer than the originally addressed destination node: Then the
      intermediate node will wrongly redirect the packet, leading to
      duplicated multicast packets at a multicast listener and missing
      packets at other multicast listeners or multicast routers.
      
      Fixing this by not applying the unicast packet rerouting to batman-adv
      unicast packets with a multicast payload. We are not able to detect a
      roaming multicast listener at the moment and will just continue to send
      the multicast frame to both the new and old destination for a while in
      case of such a roaming multicast listener.
      
      Fixes: a73105b8 ("batman-adv: improved client announcement mechanism")
      Signed-off-by: 's avatarLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: 's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: 's avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      ae1ff3f5
    • Jing Xiangfeng's avatar
      atm: eni: fix the missed pci_disable_device() for eni_init_one() · 17100ced
      Jing Xiangfeng authored
      [ Upstream commit c2b94787 ]
      
      eni_init_one() misses to call pci_disable_device() in an error path.
      Jump to err_disable to fix it.
      
      Fixes: ede58ef2 ("atm: remove deprecated use of pci api")
      Signed-off-by: 's avatarJing Xiangfeng <jingxiangfeng@huawei.com>
      Signed-off-by: 's avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      17100ced
    • Linus Lüssing's avatar
      batman-adv: bla: fix type misuse for backbone_gw hash indexing · c5edfd85
      Linus Lüssing authored
      [ Upstream commit 097930e8 ]
      
      It seems that due to a copy & paste error the void pointer
      in batadv_choose_backbone_gw() is cast to the wrong type.
      
      Fixing this by using "struct batadv_bla_backbone_gw" instead of "struct
      batadv_bla_claim" which better matches the caller's side.
      
      For now it seems that we were lucky because the two structs both have
      their orig/vid and addr/vid in the beginning. However I stumbled over
      this issue when I was trying to add some debug variables in front of
      "orig" in batadv_backbone_gw, which caused hash lookups to fail.
      
      Fixes: 07568d03 ("batman-adv: don't rely on positions in struct for hashing")
      Signed-off-by: 's avatarLinus Lüssing <ll@simonwunderlich.de>
      Signed-off-by: 's avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      c5edfd85
    • Maximilian Luz's avatar
      mwifiex: Increase AES key storage size to 256 bits · 4cef2618
      Maximilian Luz authored
      [ Upstream commit 4afc850e ]
      
      Following commit e1869678 ("mwifiex: Prevent memory corruption
      handling keys") the mwifiex driver fails to authenticate with certain
      networks, specifically networks with 256 bit keys, and repeatedly asks
      for the password. The kernel log repeats the following lines (id and
      bssid redacted):
      
          mwifiex_pcie 0000:01:00.0: info: trying to associate to '<id>' bssid <bssid>
          mwifiex_pcie 0000:01:00.0: info: associated to bssid <bssid> successfully
          mwifiex_pcie 0000:01:00.0: crypto keys added
          mwifiex_pcie 0000:01:00.0: info: successfully disconnected from <bssid>: reason code 3
      
      Tracking down this problem lead to the overflow check introduced by the
      aforementioned commit into mwifiex_ret_802_11_key_material_v2(). This
      check fails on networks with 256 bit keys due to the current storage
      size for AES keys in struct mwifiex_aes_param being only 128 bit.
      
      To fix this issue, increase the storage size for AES keys to 256 bit.
      
      Fixes: e1869678 ("mwifiex: Prevent memory corruption handling keys")
      Signed-off-by: 's avatarMaximilian Luz <luzmaximilian@gmail.com>
      Reported-by: 's avatarKaloyan Nikolov <konik98@gmail.com>
      Tested-by: 's avatarKaloyan Nikolov <konik98@gmail.com>
      Reviewed-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: 's avatarBrian Norris <briannorris@chromium.org>
      Tested-by: 's avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: 's avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20200825153829.38043-1-luzmaximilian@gmail.comSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      4cef2618
    • Tianjia Zhang's avatar
      clocksource/drivers/h8300_timer8: Fix wrong return value in h8300_8timer_init() · 92ec195f
      Tianjia Zhang authored
      [ Upstream commit 400d033f ]
      
      In the init function, if the call to of_iomap() fails, the return
      value is ENXIO instead of -ENXIO.
      
      Change to the right negative errno.
      
      Fixes: 691f8f87 ("clocksource/drivers/h8300_timer8: Convert init function to return error")
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Signed-off-by: 's avatarTianjia Zhang <tianjia.zhang@linux.alibaba.com>
      Signed-off-by: 's avatarDaniel Lezcano <daniel.lezcano@linaro.org>
      Link: https://lore.kernel.org/r/20200802111541.5429-1-tianjia.zhang@linux.alibaba.comSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      92ec195f
    • Tom Rix's avatar
      ieee802154/adf7242: check status of adf7242_read_reg · 39c96742
      Tom Rix authored
      [ Upstream commit e3914ed6 ]
      
      Clang static analysis reports this error
      
      adf7242.c:887:6: warning: Assigned value is garbage or undefined
              len = len_u8;
                  ^ ~~~~~~
      
      len_u8 is set in
             adf7242_read_reg(lp, 0, &len_u8);
      
      When this call fails, len_u8 is not set.
      
      So check the return code.
      
      Fixes: 7302b9d9 ("ieee802154/adf7242: Driver for ADF7242 MAC IEEE802154")
      Signed-off-by: 's avatarTom Rix <trix@redhat.com>
      Acked-by: 's avatarMichael Hennerich <michael.hennerich@analog.com>
      Link: https://lore.kernel.org/r/20200802142339.21091-1-trix@redhat.comSigned-off-by: 's avatarStefan Schmidt <stefan@datenfreihafen.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      39c96742
    • Josh Poimboeuf's avatar
      objtool: Fix noreturn detection for ignored functions · 0ce70ef5
      Josh Poimboeuf authored
      [ Upstream commit db6c6a0d ]
      
      When a function is annotated with STACK_FRAME_NON_STANDARD, objtool
      doesn't validate its code paths.  It also skips sibling call detection
      within the function.
      
      But sibling call detection is actually needed for the case where the
      ignored function doesn't have any return instructions.  Otherwise
      objtool naively marks the function as implicit static noreturn, which
      affects the reachability of its callers, resulting in "unreachable
      instruction" warnings.
      
      Fix it by just enabling sibling call detection for ignored functions.
      The 'insn->ignore' check in add_jump_destinations() is no longer needed
      after
      
        e6da9567 ("objtool: Don't use ignore flag for fake jumps").
      
      Fixes the following warning:
      
        arch/x86/kvm/vmx/vmx.o: warning: objtool: vmx_handle_exit_irqoff()+0x142: unreachable instruction
      
      which triggers on an allmodconfig with CONFIG_GCOV_KERNEL unset.
      Reported-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: 's avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: 's avatarBorislav Petkov <bp@suse.de>
      Acked-by: 's avatarLinus Torvalds <torvalds@linux-foundation.org>
      Link: https://lkml.kernel.org/r/5b1e2536cdbaa5246b60d7791b76130a74082c62.1599751464.git.jpoimboe@redhat.comSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      0ce70ef5
    • Hans de Goede's avatar
      i2c: core: Call i2c_acpi_install_space_handler() before i2c_acpi_register_devices() · 8b086aa9
      Hans de Goede authored
      [ Upstream commit 21653a41 ]
      
      Some ACPI i2c-devices _STA method (which is used to detect if the device
      is present) use autodetection code which probes which device is present
      over i2c. This requires the I2C ACPI OpRegion handler to be registered
      before we enumerate i2c-clients under the i2c-adapter.
      
      This fixes the i2c touchpad on the Lenovo ThinkBook 14-IIL and
      ThinkBook 15 IIL not getting an i2c-client instantiated and thus not
      working.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1842039Signed-off-by: 's avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: 's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: 's avatarWolfram Sang <wsa@kernel.org>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      8b086aa9
    • Ilya Leoshkevich's avatar
      s390/init: add missing __init annotations · efa34358
      Ilya Leoshkevich authored
      [ Upstream commit fcb2b70c ]
      
      Add __init to reserve_memory_end, reserve_oldmem and remove_oldmem.
      Sometimes these functions are not inlined, and then the build
      complains about section mismatch.
      Signed-off-by: 's avatarIlya Leoshkevich <iii@linux.ibm.com>
      Signed-off-by: 's avatarHeiko Carstens <hca@linux.ibm.com>
      Signed-off-by: 's avatarVasily Gorbik <gor@linux.ibm.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      efa34358
    • Zeng Tao's avatar
      vfio/pci: fix racy on error and request eventfd ctx · f18c38ad
      Zeng Tao authored
      [ Upstream commit b872d064 ]
      
      The vfio_pci_release call will free and clear the error and request
      eventfd ctx while these ctx could be in use at the same time in the
      function like vfio_pci_request, and it's expected to protect them under
      the vdev->igate mutex, which is missing in vfio_pci_release.
      
      This issue is introduced since commit 1518ac27 ("vfio/pci: fix memory
      leaks of eventfd ctx"),and since commit 5c5866c5 ("vfio/pci: Clear
      error and request eventfd ctx after releasing"), it's very easily to
      trigger the kernel panic like this:
      
      [ 9513.904346] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008
      [ 9513.913091] Mem abort info:
      [ 9513.915871]   ESR = 0x96000006
      [ 9513.918912]   EC = 0x25: DABT (current EL), IL = 32 bits
      [ 9513.924198]   SET = 0, FnV = 0
      [ 9513.927238]   EA = 0, S1PTW = 0
      [ 9513.930364] Data abort info:
      [ 9513.933231]   ISV = 0, ISS = 0x00000006
      [ 9513.937048]   CM = 0, WnR = 0
      [ 9513.940003] user pgtable: 4k pages, 48-bit VAs, pgdp=0000007ec7d12000
      [ 9513.946414] [0000000000000008] pgd=0000007ec7d13003, p4d=0000007ec7d13003, pud=0000007ec728c003, pmd=0000000000000000
      [ 9513.956975] Internal error: Oops: 96000006 [#1] PREEMPT SMP
      [ 9513.962521] Modules linked in: vfio_pci vfio_virqfd vfio_iommu_type1 vfio hclge hns3 hnae3 [last unloaded: vfio_pci]
      [ 9513.972998] CPU: 4 PID: 1327 Comm: bash Tainted: G        W         5.8.0-rc4+ #3
      [ 9513.980443] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B270.01 05/08/2020
      [ 9513.989274] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--)
      [ 9513.994827] pc : _raw_spin_lock_irqsave+0x48/0x88
      [ 9513.999515] lr : eventfd_signal+0x6c/0x1b0
      [ 9514.003591] sp : ffff800038a0b960
      [ 9514.006889] x29: ffff800038a0b960 x28: ffff007ef7f4da10
      [ 9514.012175] x27: ffff207eefbbfc80 x26: ffffbb7903457000
      [ 9514.017462] x25: ffffbb7912191000 x24: ffff007ef7f4d400
      [ 9514.022747] x23: ffff20be6e0e4c00 x22: 0000000000000008
      [ 9514.028033] x21: 0000000000000000 x20: 0000000000000000
      [ 9514.033321] x19: 0000000000000008 x18: 0000000000000000
      [ 9514.038606] x17: 0000000000000000 x16: ffffbb7910029328
      [ 9514.043893] x15: 0000000000000000 x14: 0000000000000001
      [ 9514.049179] x13: 0000000000000000 x12: 0000000000000002
      [ 9514.054466] x11: 0000000000000000 x10: 0000000000000a00
      [ 9514.059752] x9 : ffff800038a0b840 x8 : ffff007ef7f4de60
      [ 9514.065038] x7 : ffff007fffc96690 x6 : fffffe01faffb748
      [ 9514.070324] x5 : 0000000000000000 x4 : 0000000000000000
      [ 9514.075609] x3 : 0000000000000000 x2 : 0000000000000001
      [ 9514.080895] x1 : ffff007ef7f4d400 x0 : 0000000000000000
      [ 9514.086181] Call trace:
      [ 9514.088618]  _raw_spin_lock_irqsave+0x48/0x88
      [ 9514.092954]  eventfd_signal+0x6c/0x1b0
      [ 9514.096691]  vfio_pci_request+0x84/0xd0 [vfio_pci]
      [ 9514.101464]  vfio_del_group_dev+0x150/0x290 [vfio]
      [ 9514.106234]  vfio_pci_remove+0x30/0x128 [vfio_pci]
      [ 9514.111007]  pci_device_remove+0x48/0x108
      [ 9514.115001]  device_release_driver_internal+0x100/0x1b8
      [ 9514.120200]  device_release_driver+0x28/0x38
      [ 9514.124452]  pci_stop_bus_device+0x68/0xa8
      [ 9514.128528]  pci_stop_and_remove_bus_device+0x20/0x38
      [ 9514.133557]  pci_iov_remove_virtfn+0xb4/0x128
      [ 9514.137893]  sriov_disable+0x3c/0x108
      [ 9514.141538]  pci_disable_sriov+0x28/0x38
      [ 9514.145445]  hns3_pci_sriov_configure+0x48/0xb8 [hns3]
      [ 9514.150558]  sriov_numvfs_store+0x110/0x198
      [ 9514.154724]  dev_attr_store+0x44/0x60
      [ 9514.158373]  sysfs_kf_write+0x5c/0x78
      [ 9514.162018]  kernfs_fop_write+0x104/0x210
      [ 9514.166010]  __vfs_write+0x48/0x90
      [ 9514.169395]  vfs_write+0xbc/0x1c0
      [ 9514.172694]  ksys_write+0x74/0x100
      [ 9514.176079]  __arm64_sys_write+0x24/0x30
      [ 9514.179987]  el0_svc_common.constprop.4+0x110/0x200
      [ 9514.184842]  do_el0_svc+0x34/0x98
      [ 9514.188144]  el0_svc+0x14/0x40
      [ 9514.191185]  el0_sync_handler+0xb0/0x2d0
      [ 9514.195088]  el0_sync+0x140/0x180
      [ 9514.198389] Code: b9001020 d2800000 52800022 f9800271 (885ffe61)
      [ 9514.204455] ---[ end trace 648de00c8406465f ]---
      [ 9514.212308] note: bash[1327] exited with preempt_count 1
      
      Cc: Qian Cai <cai@lca.pw>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Fixes: 1518ac27 ("vfio/pci: fix memory leaks of eventfd ctx")
      Signed-off-by: 's avatarZeng Tao <prime.zeng@hisilicon.com>
      Signed-off-by: 's avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f18c38ad
    • Andy Lutomirski's avatar
      selftests/x86/syscall_nt: Clear weird flags after each test · 2566557b
      Andy Lutomirski authored
      [ Upstream commit a61fa279 ]
      
      Clear the weird flags before logging to improve strace output --
      logging results while, say, TF is set does no one any favors.
      Signed-off-by: 's avatarAndy Lutomirski <luto@kernel.org>
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://lkml.kernel.org/r/907bfa5a42d4475b8245e18b67a04b13ca51ffdb.1593191971.git.luto@kernel.orgSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      2566557b
    • Zhang Xiaoxu's avatar
      cifs: Fix double add page to memcg when cifs_readpages · d1a2a1c9
      Zhang Xiaoxu authored
      [ Upstream commit 95a3d8f3 ]
      
      When xfstests generic/451, there is an BUG at mm/memcontrol.c:
        page:ffffea000560f2c0 refcount:2 mapcount:0 mapping:000000008544e0ea
             index:0xf
        mapping->aops:cifs_addr_ops dentry name:"tst-aio-dio-cycle-write.451"
        flags: 0x2fffff80000001(locked)
        raw: 002fffff80000001 ffffc90002023c50 ffffea0005280088 ffff88815cda0210
        raw: 000000000000000f 0000000000000000 00000002ffffffff ffff88817287d000
        page dumped because: VM_BUG_ON_PAGE(page->mem_cgroup)
        page->mem_cgroup:ffff88817287d000
        ------------[ cut here ]------------
        kernel BUG at mm/memcontrol.c:2659!
        invalid opcode: 0000 [#1] SMP
        CPU: 2 PID: 2038 Comm: xfs_io Not tainted 5.8.0-rc1 #44
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_
          073836-buildvm-ppc64le-16.ppc.4
        RIP: 0010:commit_charge+0x35/0x50
        Code: 0d 48 83 05 54 b2 02 05 01 48 89 77 38 c3 48 c7
              c6 78 4a ea ba 48 83 05 38 b2 02 05 01 e8 63 0d9
        RSP: 0018:ffffc90002023a50 EFLAGS: 00010202
        RAX: 0000000000000000 RBX: ffff88817287d000 RCX: 0000000000000000
        RDX: 0000000000000000 RSI: ffff88817ac97ea0 RDI: ffff88817ac97ea0
        RBP: ffffea000560f2c0 R08: 0000000000000203 R09: 0000000000000005
        R10: 0000000000000030 R11: ffffc900020237a8 R12: 0000000000000000
        R13: 0000000000000001 R14: 0000000000000001 R15: ffff88815a1272c0
        FS:  00007f5071ab0800(0000) GS:ffff88817ac80000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 000055efcd5ca000 CR3: 000000015d312000 CR4: 00000000000006e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         mem_cgroup_charge+0x166/0x4f0
         __add_to_page_cache_locked+0x4a9/0x710
         add_to_page_cache_locked+0x15/0x20
         cifs_readpages+0x217/0x1270
         read_pages+0x29a/0x670
         page_cache_readahead_unbounded+0x24f/0x390
         __do_page_cache_readahead+0x3f/0x60
         ondemand_readahead+0x1f1/0x470
         page_cache_async_readahead+0x14c/0x170
         generic_file_buffered_read+0x5df/0x1100
         generic_file_read_iter+0x10c/0x1d0
         cifs_strict_readv+0x139/0x170
         new_sync_read+0x164/0x250
         __vfs_read+0x39/0x60
         vfs_read+0xb5/0x1e0
         ksys_pread64+0x85/0xf0
         __x64_sys_pread64+0x22/0x30
         do_syscall_64+0x69/0x150
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x7f5071fcb1af
        Code: Bad RIP value.
        RSP: 002b:00007ffde2cdb8e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000011
        RAX: ffffffffffffffda RBX: 00007ffde2cdb990 RCX: 00007f5071fcb1af
        RDX: 0000000000001000 RSI: 000055efcd5ca000 RDI: 0000000000000003
        RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000001000 R11: 0000000000000293 R12: 0000000000000001
        R13: 000000000009f000 R14: 0000000000000000 R15: 0000000000001000
        Modules linked in:
        ---[ end trace 725fa14a3e1af65c ]---
      
      Since commit 3fea5a49 ("mm: memcontrol: convert page cache to a new
      mem_cgroup_charge() API") not cancel the page charge, the pages maybe
      double add to pagecache:
      thread1                       | thread2
      cifs_readpages
      readpages_get_pages
       add_to_page_cache_locked(head,index=n)=0
                                    | readpages_get_pages
                                    | add_to_page_cache_locked(head,index=n+1)=0
       add_to_page_cache_locked(head, index=n+1)=-EEXIST
       then, will next loop with list head page's
       index=n+1 and the page->mapping not NULL
      readpages_get_pages
      add_to_page_cache_locked(head, index=n+1)
       commit_charge
        VM_BUG_ON_PAGE
      
      So, we should not do the next loop when any page add to page cache
      failed.
      Reported-by: 's avatarHulk Robot <hulkci@huawei.com>
      Signed-off-by: 's avatarZhang Xiaoxu <zhangxiaoxu5@huawei.com>
      Signed-off-by: 's avatarSteve French <stfrench@microsoft.com>
      Acked-by: 's avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d1a2a1c9
    • Alex Williamson's avatar
      vfio/pci: Clear error and request eventfd ctx after releasing · f71d82a6
      Alex Williamson authored
      [ Upstream commit 5c5866c5 ]
      
      The next use of the device will generate an underflow from the
      stale reference.
      
      Cc: Qian Cai <cai@lca.pw>
      Fixes: 1518ac27 ("vfio/pci: fix memory leaks of eventfd ctx")
      Reported-by: 's avatarDaniel Wagner <dwagner@suse.de>
      Reviewed-by: 's avatarCornelia Huck <cohuck@redhat.com>
      Tested-by: 's avatarDaniel Wagner <dwagner@suse.de>
      Signed-off-by: 's avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f71d82a6
    • Thomas Gleixner's avatar
      x86/speculation/mds: Mark mds_user_clear_cpu_buffers() __always_inline · 590bcc21
      Thomas Gleixner authored
      [ Upstream commit a7ef9ba9 ]
      
      Prevent the compiler from uninlining and creating traceable/probable
      functions as this is invoked _after_ context tracking switched to
      CONTEXT_USER and rcu idle.
      Signed-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: 's avatarAlexandre Chartre <alexandre.chartre@oracle.com>
      Acked-by: 's avatarPeter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20200505134340.902709267@linutronix.deSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      590bcc21
    • Boris Brezillon's avatar
      mtd: parser: cmdline: Support MTD names containing one or more colons · 95d6ed69
      Boris Brezillon authored
      [ Upstream commit eb13fa02 ]
      
      Looks like some drivers define MTD names with a colon in it, thus
      making mtdpart= parsing impossible. Let's fix the parser to gracefully
      handle that case: the last ':' in a partition definition sequence is
      considered instead of the first one.
      Signed-off-by: 's avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: 's avatarRon Minnich <rminnich@google.com>
      Tested-by: 's avatarRon Minnich <rminnich@google.com>
      Signed-off-by: 's avatarRichard Weinberger <richard@nod.at>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      95d6ed69
    • Jeff Layton's avatar
      ceph: fix potential race in ceph_check_caps · 43137370
      Jeff Layton authored
      [ Upstream commit dc3da046 ]
      
      Nothing ensures that session will still be valid by the time we
      dereference the pointer. Take and put a reference.
      
      In principle, we should always be able to get a reference here, but
      throw a warning if that's ever not the case.
      Signed-off-by: 's avatarJeff Layton <jlayton@kernel.org>
      Signed-off-by: 's avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      43137370
    • Dinghao Liu's avatar
      mtd: rawnand: omap_elm: Fix runtime PM imbalance on error · 5a30a810
      Dinghao Liu authored
      [ Upstream commit 37f72121 ]
      
      pm_runtime_get_sync() increments the runtime PM usage counter even
      when it returns an error code. Thus a pairing decrement is needed on
      the error handling path to keep the counter balanced.
      Signed-off-by: 's avatarDinghao Liu <dinghao.liu@zju.edu.cn>
      Signed-off-by: 's avatarMiquel Raynal <miquel.raynal@bootlin.com>
      Link: https://lore.kernel.org/linux-mtd/20200522104008.28340-1-dinghao.liu@zju.edu.cnSigned-off-by: 's avatarSasha Levin <sashal@kernel.org>
      5a30a810
    • Adrian Hunter's avatar
      perf kcore_copy: Fix module map when there are no modules loaded · 2bf6a49c
      Adrian Hunter authored
      [ Upstream commit 61f82e3f ]
      
      In the absence of any modules, no "modules" map is created, but there
      are other executable pages to map, due to eBPF JIT, kprobe or ftrace.
      Map them by recognizing that the first "module" symbol is not
      necessarily from a module, and adjust the map accordingly.
      Signed-off-by: 's avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: x86@kernel.org
      Link: http://lore.kernel.org/lkml/20200512121922.8997-10-adrian.hunter@intel.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      2bf6a49c
    • Xie XiuQi's avatar
      perf util: Fix memory leak of prefix_if_not_in · ba749719
      Xie XiuQi authored
      [ Upstream commit 07e9a6f5 ]
      
      Need to free "str" before return when asprintf() failed to avoid memory
      leak.
      Signed-off-by: 's avatarXie XiuQi <xiexiuqi@huawei.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Hongbo Yao <yaohongbo@huawei.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Li Bin <huawei.libin@huawei.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lore.kernel.org/lkml/20200521133218.30150-4-liwei391@huawei.comSigned-off-by: 's avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      ba749719
    • Qian Cai's avatar
      vfio/pci: fix memory leaks of eventfd ctx · f93c17d3
      Qian Cai authored
      [ Upstream commit 1518ac27 ]
      
      Finished a qemu-kvm (-device vfio-pci,host=0001:01:00.0) triggers a few
      memory leaks after a while because vfio_pci_set_ctx_trigger_single()
      calls eventfd_ctx_fdget() without the matching eventfd_ctx_put() later.
      Fix it by calling eventfd_ctx_put() for those memory in
      vfio_pci_release() before vfio_device_release().
      
      unreferenced object 0xebff008981cc2b00 (size 128):
        comm "qemu-kvm", pid 4043, jiffies 4294994816 (age 9796.310s)
        hex dump (first 32 bytes):
          01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de  ....kkkk.....N..
          ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff  ....kkkk........
        backtrace:
          [<00000000917e8f8d>] slab_post_alloc_hook+0x74/0x9c
          [<00000000df0f2aa2>] kmem_cache_alloc_trace+0x2b4/0x3d4
          [<000000005fcec025>] do_eventfd+0x54/0x1ac
          [<0000000082791a69>] __arm64_sys_eventfd2+0x34/0x44
          [<00000000b819758c>] do_el0_svc+0x128/0x1dc
          [<00000000b244e810>] el0_sync_handler+0xd0/0x268
          [<00000000d495ef94>] el0_sync+0x164/0x180
      unreferenced object 0x29ff008981cc4180 (size 128):
        comm "qemu-kvm", pid 4043, jiffies 4294994818 (age 9796.290s)
        hex dump (first 32 bytes):
          01 00 00 00 6b 6b 6b 6b 00 00 00 00 ad 4e ad de  ....kkkk.....N..
          ff ff ff ff 6b 6b 6b 6b ff ff ff ff ff ff ff ff  ....kkkk........
        backtrace:
          [<00000000917e8f8d>] slab_post_alloc_hook+0x74/0x9c
          [<00000000df0f2aa2>] kmem_cache_alloc_trace+0x2b4/0x3d4
          [<000000005fcec025>] do_eventfd+0x54/0x1ac
          [<0000000082791a69>] __arm64_sys_eventfd2+0x34/0x44
          [<00000000b819758c>] do_el0_svc+0x128/0x1dc
          [<00000000b244e810>] el0_sync_handler+0xd0/0x268
          [<00000000d495ef94>] el0_sync+0x164/0x180
      Signed-off-by: 's avatarQian Cai <cai@lca.pw>
      Signed-off-by: 's avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      f93c17d3
    • David Sterba's avatar
      btrfs: don't force read-only after error in drop snapshot · 2b8c5a91
      David Sterba authored
      [ Upstream commit 7c09c030 ]
      
      Deleting a subvolume on a full filesystem leads to ENOSPC followed by a
      forced read-only. This is not a transaction abort and the filesystem is
      otherwise ok, so the error should be just propagated to the callers.
      
      This is caused by unnecessary call to btrfs_handle_fs_error for all
      errors, except EAGAIN. This does not make sense as the standard
      transaction abort mechanism is in btrfs_drop_snapshot so all relevant
      failures are handled.
      
      Originally in commit cb1b69f4 ("Btrfs: forced readonly when
      btrfs_drop_snapshot() fails") there was no return value at all, so the
      btrfs_std_error made some sense but once the error handling and
      propagation has been implemented we don't need it anymore.
      Signed-off-by: 's avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      2b8c5a91
    • Shreyas Joshi's avatar
      printk: handle blank console arguments passed in. · d8593121
      Shreyas Joshi authored
      [ Upstream commit 48021f98 ]
      
      If uboot passes a blank string to console_setup then it results in
      a trashed memory. Ultimately, the kernel crashes during freeing up
      the memory.
      
      This fix checks if there is a blank parameter being
      passed to console_setup from uboot. In case it detects that
      the console parameter is blank then it doesn't setup the serial
      device and it gracefully exits.
      
      Link: https://lore.kernel.org/r/20200522065306.83-1-shreyas.joshi@biamp.comSigned-off-by: 's avatarShreyas Joshi <shreyas.joshi@biamp.com>
      Acked-by: 's avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      [pmladek@suse.com: Better format the commit message and code, remove unnecessary brackets.]
      Signed-off-by: 's avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: 's avatarSasha Levin <sashal@kernel.org>
      d8593121