1. 08 10月, 2019 40 次提交
    • R
      qmi_wwan: add support for Cinterion CLS8 devices · 7047aae6
      Reinhard Speyerer 提交于
      [ Upstream commit cf74ac6db25d4002089e85cc623ad149ecc25614 ]
      
      Add support for Cinterion CLS8 devices.
      Use QMI_QUIRK_SET_DTR as required for Qualcomm MDM9x07 chipsets.
      
      T:  Bus=01 Lev=03 Prnt=05 Port=01 Cnt=02 Dev#= 25 Spd=480  MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=1e2d ProdID=00b0 Rev= 3.18
      S:  Manufacturer=GEMALTO
      S:  Product=USB Modem
      C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
      I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
      E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=83(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=85(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
      E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      E:  Ad=89(I) Atr=03(Int.) MxPS=   8 Ivl=32ms
      E:  Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
      Signed-off-by: NReinhard Speyerer <rspmn@arcor.de>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7047aae6
    • E
      nfc: fix memory leak in llcp_sock_bind() · dd9c580a
      Eric Dumazet 提交于
      [ Upstream commit a0c2dc1fe63e2869b74c1c7f6a81d1745c8a695d ]
      
      sysbot reported a memory leak after a bind() has failed.
      
      While we are at it, abort the operation if kmemdup() has failed.
      
      BUG: memory leak
      unreferenced object 0xffff888105d83ec0 (size 32):
        comm "syz-executor067", pid 7207, jiffies 4294956228 (age 19.430s)
        hex dump (first 32 bytes):
          00 69 6c 65 20 72 65 61 64 00 6e 65 74 3a 5b 34  .ile read.net:[4
          30 32 36 35 33 33 30 39 37 5d 00 00 00 00 00 00  026533097]......
        backtrace:
          [<0000000036bac473>] kmemleak_alloc_recursive /./include/linux/kmemleak.h:43 [inline]
          [<0000000036bac473>] slab_post_alloc_hook /mm/slab.h:522 [inline]
          [<0000000036bac473>] slab_alloc /mm/slab.c:3319 [inline]
          [<0000000036bac473>] __do_kmalloc /mm/slab.c:3653 [inline]
          [<0000000036bac473>] __kmalloc_track_caller+0x169/0x2d0 /mm/slab.c:3670
          [<000000000cd39d07>] kmemdup+0x27/0x60 /mm/util.c:120
          [<000000008e57e5fc>] kmemdup /./include/linux/string.h:432 [inline]
          [<000000008e57e5fc>] llcp_sock_bind+0x1b3/0x230 /net/nfc/llcp_sock.c:107
          [<000000009cb0b5d3>] __sys_bind+0x11c/0x140 /net/socket.c:1647
          [<00000000492c3bbc>] __do_sys_bind /net/socket.c:1658 [inline]
          [<00000000492c3bbc>] __se_sys_bind /net/socket.c:1656 [inline]
          [<00000000492c3bbc>] __x64_sys_bind+0x1e/0x30 /net/socket.c:1656
          [<0000000008704b2a>] do_syscall_64+0x76/0x1a0 /arch/x86/entry/common.c:296
          [<000000009f4c57a4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: 30cc4587 ("NFC: Move LLCP code to the NFC top level diirectory")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd9c580a
    • M
      net: Unpublish sk from sk_reuseport_cb before call_rcu · d5b1db1c
      Martin KaFai Lau 提交于
      [ Upstream commit 8c7138b33e5c690c308b2a7085f6313fdcb3f616 ]
      
      The "reuse->sock[]" array is shared by multiple sockets.  The going away
      sk must unpublish itself from "reuse->sock[]" before making call_rcu()
      call.  However, this unpublish-action is currently done after a grace
      period and it may cause use-after-free.
      
      The fix is to move reuseport_detach_sock() to sk_destruct().
      Due to the above reason, any socket with sk_reuseport_cb has
      to go through the rcu grace period before freeing it.
      
      It is a rather old bug (~3 yrs).  The Fixes tag is not necessary
      the right commit but it is the one that introduced the SOCK_RCU_FREE
      logic and this fix is depending on it.
      
      Fixes: a4298e45 ("net: add SOCK_RCU_FREE socket flag")
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Suggested-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d5b1db1c
    • N
      net: qlogic: Fix memory leak in ql_alloc_large_buffers · 9d0995cc
      Navid Emamdoost 提交于
      [ Upstream commit 1acb8f2a7a9f10543868ddd737e37424d5c36cf4 ]
      
      In ql_alloc_large_buffers, a new skb is allocated via netdev_alloc_skb.
      This skb should be released if pci_dma_mapping_error fails.
      
      Fixes: 0f8ab89e ("qla3xxx: Check return code from pci_map_single() in ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(), ql_alloc_large_buffers(), and ql3xxx_send()")
      Signed-off-by: NNavid Emamdoost <navid.emamdoost@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d0995cc
    • P
      net: ipv4: avoid mixed n_redirects and rate_tokens usage · 124b64fe
      Paolo Abeni 提交于
      [ Upstream commit b406472b5ad79ede8d10077f0c8f05505ace8b6d ]
      
      Since commit c09551c6ff7f ("net: ipv4: use a dedicated counter
      for icmp_v4 redirect packets") we use 'n_redirects' to account
      for redirect packets, but we still use 'rate_tokens' to compute
      the redirect packets exponential backoff.
      
      If the device sent to the relevant peer any ICMP error packet
      after sending a redirect, it will also update 'rate_token' according
      to the leaking bucket schema; typically 'rate_token' will raise
      above BITS_PER_LONG and the redirect packets backoff algorithm
      will produce undefined behavior.
      
      Fix the issue using 'n_redirects' to compute the exponential backoff
      in ip_rt_send_redirect().
      
      Note that we still clear rate_tokens after a redirect silence period,
      to avoid changing an established behaviour.
      
      The root cause predates git history; before the mentioned commit in
      the critical scenario, the kernel stopped sending redirects, after
      the mentioned commit the behavior more randomic.
      Reported-by: NXiumei Mu <xmu@redhat.com>
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Fixes: c09551c6ff7f ("net: ipv4: use a dedicated counter for icmp_v4 redirect packets")
      Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
      Acked-by: NLorenzo Bianconi <lorenzo.bianconi@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      124b64fe
    • D
      ipv6: Handle missing host route in __ipv6_ifa_notify · 6f8564ed
      David Ahern 提交于
      [ Upstream commit 2d819d250a1393a3e725715425ab70a0e0772a71 ]
      
      Rajendra reported a kernel panic when a link was taken down:
      
          [ 6870.263084] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
          [ 6870.271856] IP: [<ffffffff8efc5764>] __ipv6_ifa_notify+0x154/0x290
      
          <snip>
      
          [ 6870.570501] Call Trace:
          [ 6870.573238] [<ffffffff8efc58c6>] ? ipv6_ifa_notify+0x26/0x40
          [ 6870.579665] [<ffffffff8efc98ec>] ? addrconf_dad_completed+0x4c/0x2c0
          [ 6870.586869] [<ffffffff8efe70c6>] ? ipv6_dev_mc_inc+0x196/0x260
          [ 6870.593491] [<ffffffff8efc9c6a>] ? addrconf_dad_work+0x10a/0x430
          [ 6870.600305] [<ffffffff8f01ade4>] ? __switch_to_asm+0x34/0x70
          [ 6870.606732] [<ffffffff8ea93a7a>] ? process_one_work+0x18a/0x430
          [ 6870.613449] [<ffffffff8ea93d6d>] ? worker_thread+0x4d/0x490
          [ 6870.619778] [<ffffffff8ea93d20>] ? process_one_work+0x430/0x430
          [ 6870.626495] [<ffffffff8ea99dd9>] ? kthread+0xd9/0xf0
          [ 6870.632145] [<ffffffff8f01ade4>] ? __switch_to_asm+0x34/0x70
          [ 6870.638573] [<ffffffff8ea99d00>] ? kthread_park+0x60/0x60
          [ 6870.644707] [<ffffffff8f01ae77>] ? ret_from_fork+0x57/0x70
          [ 6870.650936] Code: 31 c0 31 d2 41 b9 20 00 08 02 b9 09 00 00 0
      
      addrconf_dad_work is kicked to be scheduled when a device is brought
      up. There is a race between addrcond_dad_work getting scheduled and
      taking the rtnl lock and a process taking the link down (under rtnl).
      The latter removes the host route from the inet6_addr as part of
      addrconf_ifdown which is run for NETDEV_DOWN. The former attempts
      to use the host route in __ipv6_ifa_notify. If the down event removes
      the host route due to the race to the rtnl, then the BUG listed above
      occurs.
      
      Since the DAD sequence can not be aborted, add a check for the missing
      host route in __ipv6_ifa_notify. The only way this should happen is due
      to the previously mentioned race. The host route is created when the
      address is added to an interface; it is only removed on a down event
      where the address is kept. Add a warning if the host route is missing
      AND the device is up; this is a situation that should never happen.
      
      Fixes: f1705ec1 ("net: ipv6: Make address flushing on ifdown optional")
      Reported-by: NRajendra Dendukuri <rajendra.dendukuri@broadcom.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Reviewed-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f8564ed
    • E
      ipv6: drop incoming packets having a v4mapped source address · 658d7ee4
      Eric Dumazet 提交于
      [ Upstream commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
      
      This began with a syzbot report. syzkaller was injecting
      IPv6 TCP SYN packets having a v4mapped source address.
      
      After an unsuccessful 4-tuple lookup, TCP creates a request
      socket (SYN_RECV) and calls reqsk_queue_hash_req()
      
      reqsk_queue_hash_req() calls sk_ehashfn(sk)
      
      At this point we have AF_INET6 sockets, and the heuristic
      used by sk_ehashfn() to either hash the IPv4 or IPv6 addresses
      is to use ipv6_addr_v4mapped(&sk->sk_v6_daddr)
      
      For the particular spoofed packet, we end up hashing V4 addresses
      which were not initialized by the TCP IPv6 stack, so KMSAN fired
      a warning.
      
      I first fixed sk_ehashfn() to test both source and destination addresses,
      but then faced various problems, including user-space programs
      like packetdrill that had similar assumptions.
      
      Instead of trying to fix the whole ecosystem, it is better
      to admit that we have a dual stack behavior, and that we
      can not build linux kernels without V4 stack anyway.
      
      The dual stack API automatically forces the traffic to be IPv4
      if v4mapped addresses are used at bind() or connect(), so it makes
      no sense to allow IPv6 traffic to use the same v4mapped class.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Reported-by: Nsyzbot <syzkaller@googlegroups.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      658d7ee4
    • J
      hso: fix NULL-deref on tty open · a495fd19
      Johan Hovold 提交于
      [ Upstream commit 8353da9fa69722b54cba82b2ec740afd3d438748 ]
      
      Fix NULL-pointer dereference on tty open due to a failure to handle a
      missing interrupt-in endpoint when probing modem ports:
      
      	BUG: kernel NULL pointer dereference, address: 0000000000000006
      	...
      	RIP: 0010:tiocmget_submit_urb+0x1c/0xe0 [hso]
      	...
      	Call Trace:
      	hso_start_serial_device+0xdc/0x140 [hso]
      	hso_serial_open+0x118/0x1b0 [hso]
      	tty_open+0xf1/0x490
      
      Fixes: 542f5482 ("tty: Modem functions for the HSO driver")
      Signed-off-by: NJohan Hovold <johan@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a495fd19
    • H
      erspan: remove the incorrect mtu limit for erspan · 7f30c44b
      Haishuang Yan 提交于
      [ Upstream commit 0e141f757b2c78c983df893e9993313e2dc21e38 ]
      
      erspan driver calls ether_setup(), after commit 61e84623
      ("net: centralize net_device min/max MTU checking"), the range
      of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
      
      It causes the dev mtu of the erspan device to not be greater
      than 1500, this limit value is not correct for ipgre tap device.
      
      Tested:
      Before patch:
      # ip link set erspan0 mtu 1600
      Error: mtu greater than device maximum.
      After patch:
      # ip link set erspan0 mtu 1600
      # ip -d link show erspan0
      21: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1600 qdisc noop state DOWN
      mode DEFAULT group default qlen 1000
          link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 0
      
      Fixes: 61e84623 ("net: centralize net_device min/max MTU checking")
      Signed-off-by: NHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f30c44b
    • V
      cxgb4:Fix out-of-bounds MSI-X info array access · 2b838911
      Vishal Kulkarni 提交于
      [ Upstream commit 6b517374f4ea5a3c6e307e1219ec5f35d42e6d00 ]
      
      When fetching free MSI-X vectors for ULDs, check for the error code
      before accessing MSI-X info array. Otherwise, an out-of-bounds access is
      attempted, which results in kernel panic.
      
      Fixes: 94cdb8bb ("cxgb4: Add support for dynamic allocation of resources for ULD")
      Signed-off-by: NShahjada Abul Husain <shahjada@chelsio.com>
      Signed-off-by: NVishal Kulkarni <vishal@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b838911
    • D
      bpf: fix use after free in prog symbol exposure · ed568ca7
      Daniel Borkmann 提交于
      commit c751798aa224fadc5124b49eeb38fb468c0fa039 upstream.
      
      syzkaller managed to trigger the warning in bpf_jit_free() which checks via
      bpf_prog_kallsyms_verify_off() for potentially unlinked JITed BPF progs
      in kallsyms, and subsequently trips over GPF when walking kallsyms entries:
      
        [...]
        8021q: adding VLAN 0 to HW filter on device batadv0
        8021q: adding VLAN 0 to HW filter on device batadv0
        WARNING: CPU: 0 PID: 9869 at kernel/bpf/core.c:810 bpf_jit_free+0x1e8/0x2a0
        Kernel panic - not syncing: panic_on_warn set ...
        CPU: 0 PID: 9869 Comm: kworker/0:7 Not tainted 5.0.0-rc8+ #1
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        Workqueue: events bpf_prog_free_deferred
        Call Trace:
         __dump_stack lib/dump_stack.c:77 [inline]
         dump_stack+0x113/0x167 lib/dump_stack.c:113
         panic+0x212/0x40b kernel/panic.c:214
         __warn.cold.8+0x1b/0x38 kernel/panic.c:571
         report_bug+0x1a4/0x200 lib/bug.c:186
         fixup_bug arch/x86/kernel/traps.c:178 [inline]
         do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271
         do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290
         invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:973
        RIP: 0010:bpf_jit_free+0x1e8/0x2a0
        Code: 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 86 00 00 00 48 ba 00 02 00 00 00 00 ad de 0f b6 43 02 49 39 d6 0f 84 5f fe ff ff <0f> 0b e9 58 fe ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1
        RSP: 0018:ffff888092f67cd8 EFLAGS: 00010202
        RAX: 0000000000000007 RBX: ffffc90001947000 RCX: ffffffff816e9d88
        RDX: dead000000000200 RSI: 0000000000000008 RDI: ffff88808769f7f0
        RBP: ffff888092f67d00 R08: fffffbfff1394059 R09: fffffbfff1394058
        R10: fffffbfff1394058 R11: ffffffff89ca02c7 R12: ffffc90001947002
        R13: ffffc90001947020 R14: ffffffff881eca80 R15: ffff88808769f7e8
        BUG: unable to handle kernel paging request at fffffbfff400d000
        #PF error: [normal kernel read fault]
        PGD 21ffee067 P4D 21ffee067 PUD 21ffed067 PMD 9f942067 PTE 0
        Oops: 0000 [#1] PREEMPT SMP KASAN
        CPU: 0 PID: 9869 Comm: kworker/0:7 Not tainted 5.0.0-rc8+ #1
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        Workqueue: events bpf_prog_free_deferred
        RIP: 0010:bpf_get_prog_addr_region kernel/bpf/core.c:495 [inline]
        RIP: 0010:bpf_tree_comp kernel/bpf/core.c:558 [inline]
        RIP: 0010:__lt_find include/linux/rbtree_latch.h:115 [inline]
        RIP: 0010:latch_tree_find include/linux/rbtree_latch.h:208 [inline]
        RIP: 0010:bpf_prog_kallsyms_find+0x107/0x2e0 kernel/bpf/core.c:632
        Code: 00 f0 ff ff 44 38 c8 7f 08 84 c0 0f 85 fa 00 00 00 41 f6 45 02 01 75 02 0f 0b 48 39 da 0f 82 92 00 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 30 84 c0 74 08 3c 03 0f 8e 45 01 00 00 8b 03 48 c1 e0
        [...]
      
      Upon further debugging, it turns out that whenever we trigger this
      issue, the kallsyms removal in bpf_prog_ksym_node_del() was /skipped/
      but yet bpf_jit_free() reported that the entry is /in use/.
      
      Problem is that symbol exposure via bpf_prog_kallsyms_add() but also
      perf_event_bpf_event() were done /after/ bpf_prog_new_fd(). Once the
      fd is exposed to the public, a parallel close request came in right
      before we attempted to do the bpf_prog_kallsyms_add().
      
      Given at this time the prog reference count is one, we start to rip
      everything underneath us via bpf_prog_release() -> bpf_prog_put().
      The memory is eventually released via deferred free, so we're seeing
      that bpf_jit_free() has a kallsym entry because we added it from
      bpf_prog_load() but /after/ bpf_prog_put() from the remote CPU.
      
      Therefore, move both notifications /before/ we install the fd. The
      issue was never seen between bpf_prog_alloc_id() and bpf_prog_new_fd()
      because upon bpf_prog_get_fd_by_id() we'll take another reference to
      the BPF prog, so we're still holding the original reference from the
      bpf_prog_load().
      
      Fixes: 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT")
      Fixes: 74451e66 ("bpf: make jited programs visible in traces")
      Reported-by: syzbot+bd3bba6ff3fcea7a6ec6@syzkaller.appspotmail.com
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Song Liu <songliubraving@fb.com>
      Signed-off-by: NZubin Mithra <zsm@chromium.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ed568ca7
    • D
      block: mq-deadline: Fix queue restart handling · dbb7339c
      Damien Le Moal 提交于
      [ Upstream commit cb8acabbe33b110157955a7425ee876fb81e6bbc ]
      
      Commit 7211aef86f79 ("block: mq-deadline: Fix write completion
      handling") added a call to blk_mq_sched_mark_restart_hctx() in
      dd_dispatch_request() to make sure that write request dispatching does
      not stall when all target zones are locked. This fix left a subtle race
      when a write completion happens during a dispatch execution on another
      CPU:
      
      CPU 0: Dispatch			CPU1: write completion
      
      dd_dispatch_request()
          lock(&dd->lock);
          ...
          lock(&dd->zone_lock);	dd_finish_request()
          rq = find request		lock(&dd->zone_lock);
          unlock(&dd->zone_lock);
          				zone write unlock
      				unlock(&dd->zone_lock);
      				...
      				__blk_mq_free_request
                                            check restart flag (not set)
      				      -> queue not run
          ...
          if (!rq && have writes)
              blk_mq_sched_mark_restart_hctx()
          unlock(&dd->lock)
      
      Since the dispatch context finishes after the write request completion
      handling, marking the queue as needing a restart is not seen from
      __blk_mq_free_request() and blk_mq_sched_restart() not executed leading
      to the dispatch stall under 100% write workloads.
      
      Fix this by moving the call to blk_mq_sched_mark_restart_hctx() from
      dd_dispatch_request() into dd_finish_request() under the zone lock to
      ensure full mutual exclusion between write request dispatch selection
      and zone unlock on write request completion.
      
      Fixes: 7211aef86f79 ("block: mq-deadline: Fix write completion handling")
      Cc: stable@vger.kernel.org
      Reported-by: NHans Holmberg <Hans.Holmberg@wdc.com>
      Reviewed-by: NHans Holmberg <hans.holmberg@wdc.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dbb7339c
    • A
      arm: use STACK_TOP when computing mmap base address · af10ffa6
      Alexandre Ghiti 提交于
      [ Upstream commit 86e568e9c0525fc40e76d827212d5e9721cf7504 ]
      
      mmap base address must be computed wrt stack top address, using TASK_SIZE
      is wrong since STACK_TOP and TASK_SIZE are not equivalent.
      
      Link: http://lkml.kernel.org/r/20190730055113.23635-8-alex@ghiti.frSigned-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      af10ffa6
    • A
      arm: properly account for stack randomization and stack guard gap · f91a9c65
      Alexandre Ghiti 提交于
      [ Upstream commit af0f4297286f13a75edf93677b1fb2fc16c412a7 ]
      
      This commit takes care of stack randomization and stack guard gap when
      computing mmap base address and checks if the task asked for
      randomization.  This fixes the problem uncovered and not fixed for arm
      here: https://lkml.kernel.org/r/20170622200033.25714-1-riel@redhat.com
      
      Link: http://lkml.kernel.org/r/20190730055113.23635-7-alex@ghiti.frSigned-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f91a9c65
    • A
      mips: properly account for stack randomization and stack guard gap · 53ba8d43
      Alexandre Ghiti 提交于
      [ Upstream commit b1f61b5bde3a1f50392c97b4c8513d1b8efb1cf2 ]
      
      This commit takes care of stack randomization and stack guard gap when
      computing mmap base address and checks if the task asked for
      randomization.  This fixes the problem uncovered and not fixed for arm
      here: https://lkml.kernel.org/r/20170622200033.25714-1-riel@redhat.com
      
      Link: http://lkml.kernel.org/r/20190730055113.23635-10-alex@ghiti.frSigned-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NPaul Burton <paul.burton@mips.com>
      Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      53ba8d43
    • A
      arm64: consider stack randomization for mmap base only when necessary · e1b391ab
      Alexandre Ghiti 提交于
      [ Upstream commit e8d54b62c55ab6201de6d195fc2c276294c1f6ae ]
      
      Do not offset mmap base address because of stack randomization if current
      task does not want randomization.  Note that x86 already implements this
      behaviour.
      
      Link: http://lkml.kernel.org/r/20190730055113.23635-4-alex@ghiti.frSigned-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e1b391ab
    • N
      kmemleak: increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE default to 16K · 30ab799e
      Nicolas Boichat 提交于
      [ Upstream commit b751c52bb587ae66f773b15204ef7a147467f4c7 ]
      
      The current default value (400) is too low on many systems (e.g.  some
      ARM64 platform takes up 1000+ entries).
      
      syzbot uses 16000 as default value, and has proved to be enough on beefy
      configurations, so let's pick that value.
      
      This consumes more RAM on boot (each entry is 160 bytes, so in total
      ~2.5MB of RAM), but the memory would later be freed (early_log is
      __initdata).
      
      Link: http://lkml.kernel.org/r/20190730154027.101525-1-drinkcat@chromium.orgSigned-off-by: NNicolas Boichat <drinkcat@chromium.org>
      Suggested-by: NDmitry Vyukov <dvyukov@google.com>
      Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
      Acked-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Cc: Joe Lawrence <joe.lawrence@redhat.com>
      Cc: Uladzislau Rezki <urezki@gmail.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      30ab799e
    • C
      ocfs2: wait for recovering done after direct unlock request · 52132ff5
      Changwei Ge 提交于
      [ Upstream commit 0a3775e4f883912944481cf2ef36eb6383a9cc74 ]
      
      There is a scenario causing ocfs2 umount hang when multiple hosts are
      rebooting at the same time.
      
      NODE1                           NODE2               NODE3
      send unlock requset to NODE2
                                      dies
                                                          become recovery master
                                                          recover NODE2
      find NODE2 dead
      mark resource RECOVERING
      directly remove lock from grant list
      calculate usage but RECOVERING marked
      **miss the window of purging
      clear RECOVERING
      
      To reproduce this issue, crash a host and then umount ocfs2
      from another node.
      
      To solve this, just let unlock progress wait for recovery done.
      
      Link: http://lkml.kernel.org/r/1550124866-20367-1-git-send-email-gechangwei@live.cnSigned-off-by: NChangwei Ge <gechangwei@live.cn>
      Reviewed-by: NJoseph Qi <joseph.qi@linux.alibaba.com>
      Cc: Mark Fasheh <mark@fasheh.com>
      Cc: Joel Becker <jlbec@evilplan.org>
      Cc: Junxiao Bi <junxiao.bi@oracle.com>
      Cc: Changwei Ge <gechangwei@live.cn>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      52132ff5
    • G
      kbuild: clean compressed initramfs image · d4a54645
      Greg Thelen 提交于
      [ Upstream commit 6279eb3dd7946c69346a3b98473ed13d3a44adb5 ]
      
      Since 9e3596b0 ("kbuild: initramfs cleanup, set target from Kconfig")
      "make clean" leaves behind compressed initramfs images.  Example:
      
        $ make defconfig
        $ sed -i 's|CONFIG_INITRAMFS_SOURCE=""|CONFIG_INITRAMFS_SOURCE="/tmp/ir.cpio"|' .config
        $ make olddefconfig
        $ make -s
        $ make -s clean
        $ git clean -ndxf | grep initramfs
        Would remove usr/initramfs_data.cpio.gz
      
      clean rules do not have CONFIG_* context so they do not know which
      compression format was used.  Thus they don't know which files to delete.
      
      Tell clean to delete all possible compression formats.
      
      Once patched usr/initramfs_data.cpio.gz and friends are deleted by
      "make clean".
      
      Link: http://lkml.kernel.org/r/20190722063251.55541-1-gthelen@google.com
      Fixes: 9e3596b0 ("kbuild: initramfs cleanup, set target from Kconfig")
      Signed-off-by: NGreg Thelen <gthelen@google.com>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d4a54645
    • Y
      crypto: hisilicon - Fix double free in sec_free_hw_sgl() · d983182d
      Yunfeng Ye 提交于
      [ Upstream commit 24fbf7bad888767bed952f540ac963bc57e47e15 ]
      
      There are two problems in sec_free_hw_sgl():
      
      First, when sgl_current->next is valid, @hw_sgl will be freed in the
      first loop, but it free again after the loop.
      
      Second, sgl_current and sgl_current->next_sgl is not match when
      dma_pool_free() is invoked, the third parameter should be the dma
      address of sgl_current, but sgl_current->next_sgl is the dma address
      of next chain, so use sgl_current->next_sgl is wrong.
      
      Fix this by deleting the last dma_pool_free() in sec_free_hw_sgl(),
      modifying the condition for while loop, and matching the address for
      dma_pool_free().
      
      Fixes: 915e4e84 ("crypto: hisilicon - SEC security accelerator driver")
      Signed-off-by: NYunfeng Ye <yeyunfeng@huawei.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      d983182d
    • D
      hypfs: Fix error number left in struct pointer member · 22c788ba
      David Howells 提交于
      [ Upstream commit b54c64f7adeb241423cd46598f458b5486b0375e ]
      
      In hypfs_fill_super(), if hypfs_create_update_file() fails,
      sbi->update_file is left holding an error number.  This is passed to
      hypfs_kill_super() which doesn't check for this.
      
      Fix this by not setting sbi->update_value until after we've checked for
      error.
      
      Fixes: 24bbb1fa ("[PATCH] s390_hypfs filesystem")
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      cc: linux-s390@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      22c788ba
    • J
      pktcdvd: remove warning on attempting to register non-passthrough dev · bbd76d95
      Jens Axboe 提交于
      [ Upstream commit eb09b3cc464d2c3bbde9a6648603c8d599ea8582 ]
      
      Anatoly reports that he gets the below warning when booting -git on
      a sparc64 box on debian unstable:
      
      ...
      [   13.352975] aes_sparc64: Using sparc64 aes opcodes optimized AES
      implementation
      [   13.428002] ------------[ cut here ]------------
      [   13.428081] WARNING: CPU: 21 PID: 586 at
      drivers/block/pktcdvd.c:2597 pkt_setup_dev+0x2e4/0x5a0 [pktcdvd]
      [   13.428147] Attempt to register a non-SCSI queue
      [   13.428184] Modules linked in: pktcdvd libdes cdrom aes_sparc64
      n2_rng md5_sparc64 sha512_sparc64 rng_core sha256_sparc64 flash
      sha1_sparc64 ip_tables x_tables ipv6 crc_ccitt nf_defrag_ipv6 autofs4
      ext4 crc16 mbcache jbd2 raid10 raid456 async_raid6_recov async_memcpy
      async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear
      md_mod crc32c_sparc64
      [   13.428452] CPU: 21 PID: 586 Comm: pktsetup Not tainted
      5.3.0-10169-g574cc4539762 #1234
      [   13.428507] Call Trace:
      [   13.428542]  [00000000004635c0] __warn+0xc0/0x100
      [   13.428582]  [0000000000463634] warn_slowpath_fmt+0x34/0x60
      [   13.428626]  [000000001045b244] pkt_setup_dev+0x2e4/0x5a0 [pktcdvd]
      [   13.428674]  [000000001045ccf4] pkt_ctl_ioctl+0x94/0x220 [pktcdvd]
      [   13.428724]  [00000000006b95c8] do_vfs_ioctl+0x628/0x6e0
      [   13.428764]  [00000000006b96c8] ksys_ioctl+0x48/0x80
      [   13.428803]  [00000000006b9714] sys_ioctl+0x14/0x40
      [   13.428847]  [0000000000406294] linux_sparc_syscall+0x34/0x44
      [   13.428890] irq event stamp: 4181
      [   13.428924] hardirqs last  enabled at (4189): [<00000000004e0a74>]
      console_unlock+0x634/0x6c0
      [   13.428984] hardirqs last disabled at (4196): [<00000000004e0540>]
      console_unlock+0x100/0x6c0
      [   13.429048] softirqs last  enabled at (3978): [<0000000000b2e2d8>]
      __do_softirq+0x498/0x520
      [   13.429110] softirqs last disabled at (3967): [<000000000042cfb4>]
      do_softirq_own_stack+0x34/0x60
      [   13.429172] ---[ end trace 2220ca468f32967d ]---
      [   13.430018] pktcdvd: setup of pktcdvd device failed
      [   13.455589] des_sparc64: Using sparc64 des opcodes optimized DES
      implementation
      [   13.515334] camellia_sparc64: Using sparc64 camellia opcodes
      optimized CAMELLIA implementation
      [   13.522856] pktcdvd: setup of pktcdvd device failed
      [   13.529327] pktcdvd: setup of pktcdvd device failed
      [   13.532932] pktcdvd: setup of pktcdvd device failed
      [   13.536165] pktcdvd: setup of pktcdvd device failed
      [   13.539372] pktcdvd: setup of pktcdvd device failed
      [   13.542834] pktcdvd: setup of pktcdvd device failed
      [   13.546536] pktcdvd: setup of pktcdvd device failed
      [   15.431071] XFS (dm-0): Mounting V5 Filesystem
      ...
      
      Apparently debian auto-attaches any cdrom like device to pktcdvd, which
      can lead to the above warning. There's really no reason to warn for this
      situation, kill it.
      Reported-by: NAnatoly Pugachev <matorola@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      bbd76d95
    • O
      fat: work around race with userspace's read via blockdev while mounting · 0840daee
      OGAWA Hirofumi 提交于
      [ Upstream commit 07bfa4415ab607e459b69bd86aa7e7602ce10b4f ]
      
      If userspace reads the buffer via blockdev while mounting,
      sb_getblk()+modify can race with buffer read via blockdev.
      
      For example,
      
                  FS                               userspace
          bh = sb_getblk()
          modify bh->b_data
                                        read
      				    ll_rw_block(bh)
      				      fill bh->b_data by on-disk data
      				      /* lost modified data by FS */
      				      set_buffer_uptodate(bh)
          set_buffer_uptodate(bh)
      
      Userspace should not use the blockdev while mounting though, the udev
      seems to be already doing this.  Although I think the udev should try to
      avoid this, workaround the race by small overhead.
      
      Link: http://lkml.kernel.org/r/87pnk7l3sw.fsf_-_@mail.parknet.co.jpSigned-off-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Reported-by: NJan Stancek <jstancek@redhat.com>
      Tested-by: NJan Stancek <jstancek@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0840daee
    • M
      ARM: 8903/1: ensure that usable memory in bank 0 starts from a PMD-aligned address · 297904ea
      Mike Rapoport 提交于
      [ Upstream commit 00d2ec1e6bd82c0538e6dd3e4a4040de93ba4fef ]
      
      The calculation of memblock_limit in adjust_lowmem_bounds() assumes that
      bank 0 starts from a PMD-aligned address. However, the beginning of the
      first bank may be NOMAP memory and the start of usable memory
      will be not aligned to PMD boundary. In such case the memblock_limit will
      be set to the end of the NOMAP region, which will prevent any memblock
      allocations.
      
      Mark the region between the end of the NOMAP area and the next PMD-aligned
      address as NOMAP as well, so that the usable memory will start at
      PMD-aligned address.
      Signed-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      297904ea
    • J
      security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb() · 9a87ab2b
      Jia-Ju Bai 提交于
      [ Upstream commit 3f4287e7d98a2954f20bf96c567fdffcd2b63eb9 ]
      
      In smack_socket_sock_rcv_skb(), there is an if statement
      on line 3920 to check whether skb is NULL:
          if (skb && skb->secmark != 0)
      
      This check indicates skb can be NULL in some cases.
      
      But on lines 3931 and 3932, skb is used:
          ad.a.u.net->netif = skb->skb_iif;
          ipv6_skb_to_auditdata(skb, &ad.a, NULL);
      
      Thus, possible null-pointer dereferences may occur when skb is NULL.
      
      To fix these possible bugs, an if statement is added to check skb.
      
      These bugs are found by a static analysis tool STCheck written by us.
      Signed-off-by: NJia-Ju Bai <baijiaju1990@gmail.com>
      Signed-off-by: NCasey Schaufler <casey@schaufler-ca.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9a87ab2b
    • T
      PCI: exynos: Propagate errors for optional PHYs · 69a32a73
      Thierry Reding 提交于
      [ Upstream commit ddd6960087d4b45759434146d681a94bbb1c54ad ]
      
      devm_of_phy_get() can fail for a number of reasons besides probe
      deferral. It can for example return -ENOMEM if it runs out of memory as
      it tries to allocate devres structures. Propagating only -EPROBE_DEFER
      is problematic because it results in these legitimately fatal errors
      being treated as "PHY not specified in DT".
      
      What we really want is to ignore the optional PHYs only if they have not
      been specified in DT. devm_of_phy_get() returns -ENODEV in this case, so
      that's the special case that we need to handle. So we propagate all
      errors, except -ENODEV, so that real failures will still cause the
      driver to fail probe.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NAndrew Murray <andrew.murray@arm.com>
      Cc: Jingoo Han <jingoohan1@gmail.com>
      Cc: Kukjin Kim <kgene@kernel.org>
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      69a32a73
    • T
      PCI: imx6: Propagate errors for optional regulators · 1264d2e7
      Thierry Reding 提交于
      [ Upstream commit 2170a09fb4b0f66e06e5bcdcbc98c9ccbf353650 ]
      
      regulator_get_optional() can fail for a number of reasons besides probe
      deferral. It can for example return -ENOMEM if it runs out of memory as
      it tries to allocate data structures. Propagating only -EPROBE_DEFER is
      problematic because it results in these legitimately fatal errors being
      treated as "regulator not specified in DT".
      
      What we really want is to ignore the optional regulators only if they
      have not been specified in DT. regulator_get_optional() returns -ENODEV
      in this case, so that's the special case that we need to handle. So we
      propagate all errors, except -ENODEV, so that real failures will still
      cause the driver to fail probe.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NAndrew Murray <andrew.murray@arm.com>
      Cc: Richard Zhu <hongxing.zhu@nxp.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Fabio Estevam <festevam@gmail.com>
      Cc: kernel@pengutronix.de
      Cc: linux-imx@nxp.com
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1264d2e7
    • T
      PCI: histb: Propagate errors for optional regulators · 403d6c92
      Thierry Reding 提交于
      [ Upstream commit 8f9e1641ba445437095411d9fda2324121110d5d ]
      
      regulator_get_optional() can fail for a number of reasons besides probe
      deferral. It can for example return -ENOMEM if it runs out of memory as
      it tries to allocate data structures. Propagating only -EPROBE_DEFER is
      problematic because it results in these legitimately fatal errors being
      treated as "regulator not specified in DT".
      
      What we really want is to ignore the optional regulators only if they
      have not been specified in DT. regulator_get_optional() returns -ENODEV
      in this case, so that's the special case that we need to handle. So we
      propagate all errors, except -ENODEV, so that real failures will still
      cause the driver to fail probe.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NAndrew Murray <andrew.murray@arm.com>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      403d6c92
    • T
      PCI: rockchip: Propagate errors for optional regulators · ac9c0e2e
      Thierry Reding 提交于
      [ Upstream commit 0e3ff0ac5f71bdb6be2a698de0ed0c7e6e738269 ]
      
      regulator_get_optional() can fail for a number of reasons besides probe
      deferral. It can for example return -ENOMEM if it runs out of memory as
      it tries to allocate data structures. Propagating only -EPROBE_DEFER is
      problematic because it results in these legitimately fatal errors being
      treated as "regulator not specified in DT".
      
      What we really want is to ignore the optional regulators only if they
      have not been specified in DT. regulator_get_optional() returns -ENODEV
      in this case, so that's the special case that we need to handle. So we
      propagate all errors, except -ENODEV, so that real failures will still
      cause the driver to fail probe.
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NAndrew Murray <andrew.murray@arm.com>
      Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
      Acked-by: NShawn Lin <shawn.lin@rock-chips.com>
      Cc: Shawn Lin <shawn.lin@rock-chips.com>
      Cc: Heiko Stuebner <heiko@sntech.de>
      Cc: linux-rockchip@lists.infradead.org
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ac9c0e2e
    • J
      HID: apple: Fix stuck function keys when using FN · 709c4841
      Joao Moreno 提交于
      [ Upstream commit aec256d0ecd561036f188dbc8fa7924c47a9edfd ]
      
      This fixes an issue in which key down events for function keys would be
      repeatedly emitted even after the user has raised the physical key. For
      example, the driver fails to emit the F5 key up event when going through
      the following steps:
      - fnmode=1: hold FN, hold F5, release FN, release F5
      - fnmode=2: hold F5, hold FN, release F5, release FN
      
      The repeated F5 key down events can be easily verified using xev.
      Signed-off-by: NJoao Moreno <mail@joaomoreno.com>
      Co-developed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      709c4841
    • B
      rtc: pcf85363/pcf85263: fix regmap error in set_time · 31e98cba
      Biwen Li 提交于
      [ Upstream commit 7ef66122bdb3b839e9f51b76d7e600b6e21ef648 ]
      
      Issue:
          - # hwclock -w
            hwclock: RTC_SET_TIME: Invalid argument
      
      Why:
          - Relative commit: 8b9f9d4dc511 ("regmap: verify if register is
            writeable before writing operations"), this patch
            will always check for unwritable registers, it will compare reg
            with max_register in regmap_writeable.
      
          - The pcf85363/pcf85263 has the capability of address wrapping
            which means if you access an address outside the allowed range
            (0x00-0x2f) hardware actually wraps the access to a lower address.
            The rtc-pcf85363 driver will use this feature to configure the time
            and execute 2 actions in the same i2c write operation (stopping the
            clock and configure the time). However the driver has also
            configured the `regmap maxregister` protection mechanism that will
            block accessing addresses outside valid range (0x00-0x2f).
      
      How:
          - Split of writing regs to two parts, first part writes control
            registers about stop_enable and resets, second part writes
            RTC time and date registers.
      Signed-off-by: NBiwen Li <biwen.li@nxp.com>
      Link: https://lore.kernel.org/r/20190829021418.4607-1-biwen.li@nxp.comSigned-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      31e98cba
    • A
      rtc: snvs: fix possible race condition · 607f9578
      Anson Huang 提交于
      [ Upstream commit 6fd4fe9b496d9ba3382992ff4fde3871d1b6f63d ]
      
      The RTC IRQ is requested before the struct rtc_device is allocated,
      this may lead to a NULL pointer dereference in IRQ handler.
      
      To fix this issue, allocating the rtc_device struct before requesting
      the RTC IRQ using devm_rtc_allocate_device, and use rtc_register_device
      to register the RTC device.
      Signed-off-by: NAnson Huang <Anson.Huang@nxp.com>
      Reviewed-by: NDong Aisheng <aisheng.dong@nxp.com>
      Link: https://lore.kernel.org/r/20190716071858.36750-1-Anson.Huang@nxp.comSigned-off-by: NAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      607f9578
    • N
      ARM: 8875/1: Kconfig: default to AEABI w/ Clang · 07893754
      Nick Desaulniers 提交于
      [ Upstream commit a05b9608456e0d4464c6f7ca8572324ace57a3f4 ]
      
      Clang produces references to __aeabi_uidivmod and __aeabi_idivmod for
      arm-linux-gnueabi and arm-linux-gnueabihf targets incorrectly when AEABI
      is not selected (such as when OABI_COMPAT is selected).
      
      While this means that OABI userspaces wont be able to upgraded to
      kernels built with Clang, it means that boards that don't enable AEABI
      like s3c2410_defconfig will stop failing to link in KernelCI when built
      with Clang.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/482
      Link: https://groups.google.com/forum/#!msg/clang-built-linux/yydsAAux5hk/GxjqJSW-AQAJSuggested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      07893754
    • P
      soundwire: intel: fix channel number reported by hardware · 3039c788
      Pierre-Louis Bossart 提交于
      [ Upstream commit 18046335643de6d21327f5ae034c8fb8463f6715 ]
      
      On all released Intel controllers (CNL/CML/ICL), PDI2 reports an
      invalid count, force the correct hardware-supported value
      
      This may have to be revisited with platform-specific values if the
      hardware changes, but for now this is good enough.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/20190806005522.22642-3-pierre-louis.bossart@linux.intel.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3039c788
    • W
      ARM: 8898/1: mm: Don't treat faults reported from cache maintenance as writes · 6a684e00
      Will Deacon 提交于
      [ Upstream commit 834020366da9ab3fb87d1eb9a3160eb22dbed63a ]
      
      Translation faults arising from cache maintenance instructions are
      rather unhelpfully reported with an FSR value where the WnR field is set
      to 1, indicating that the faulting access was a write. Since cache
      maintenance instructions on 32-bit ARM do not require any particular
      permissions, this can cause our private 'cacheflush' system call to fail
      spuriously if a translation fault is generated due to page aging when
      targetting a read-only VMA.
      
      In this situation, we will return -EFAULT to userspace, although this is
      unfortunately suppressed by the popular '__builtin___clear_cache()'
      intrinsic provided by GCC, which returns void.
      
      Although it's tempting to write this off as a userspace issue, we can
      actually do a little bit better on CPUs that support LPAE, even if the
      short-descriptor format is in use. On these CPUs, cache maintenance
      faults additionally set the CM field in the FSR, which we can use to
      suppress the write permission checks in the page fault handler and
      succeed in performing cache maintenance to read-only areas even in the
      presence of a translation fault.
      Reported-by: NOrion Hodson <oth@google.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      6a684e00
    • M
      livepatch: Nullify obj->mod in klp_module_coming()'s error path · 0f0ced70
      Miroslav Benes 提交于
      [ Upstream commit 4ff96fb52c6964ad42e0a878be8f86a2e8052ddd ]
      
      klp_module_coming() is called for every module appearing in the system.
      It sets obj->mod to a patched module for klp_object obj. Unfortunately
      it leaves it set even if an error happens later in the function and the
      patched module is not allowed to be loaded.
      
      klp_is_object_loaded() uses obj->mod variable and could currently give a
      wrong return value. The bug is probably harmless as of now.
      Signed-off-by: NMiroslav Benes <mbenes@suse.cz>
      Reviewed-by: NPetr Mladek <pmladek@suse.com>
      Acked-by: NJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: NPetr Mladek <pmladek@suse.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      0f0ced70
    • J
      HID: wacom: Fix several minor compiler warnings · 78a11386
      Jason Gerecke 提交于
      [ Upstream commit 073b50bccbbf99a3b79a1913604c656d0e1a56c9 ]
      
      Addresses a few issues that were noticed when compiling with non-default
      warnings enabled. The trimmed-down warnings in the order they are fixed
      below are:
      
      * declaration of 'size' shadows a parameter
      
      * '%s' directive output may be truncated writing up to 5 bytes into a
        region of size between 1 and 64
      
      * pointer targets in initialization of 'char *' from 'unsigned char *'
        differ in signedness
      
      * left shift of negative value
      Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: NAaron Armstrong Skomra <aaron.skomra@wacom.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      78a11386
    • N
      PCI: tegra: Fix OF node reference leak · 3b7fbbdd
      Nishka Dasgupta 提交于
      [ Upstream commit 9e38e690ace3e7a22a81fc02652fc101efb340cf ]
      
      Each iteration of for_each_child_of_node() executes of_node_put() on the
      previous node, but in some return paths in the middle of the loop
      of_node_put() is missing thus causing a reference leak.
      
      Hence stash these mid-loop return values in a variable 'err' and add a
      new label err_node_put which executes of_node_put() on the previous node
      and returns 'err' on failure.
      
      Change mid-loop return statements to point to jump to this label to
      fix the reference leak.
      
      Issue found with Coccinelle.
      Signed-off-by: NNishka Dasgupta <nishkadg.linux@gmail.com>
      [lorenzo.pieralisi@arm.com: rewrote commit log]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      3b7fbbdd
    • K
      mfd: intel-lpss: Remove D3cold delay · c74a801d
      Kai-Heng Feng 提交于
      [ Upstream commit 76380a607ba0b28627c9b4b55cd47a079a59624b ]
      
      Goodix touchpad may drop its first couple input events when
      i2c-designware-platdrv and intel-lpss it connects to took too long to
      runtime resume from runtime suspended state.
      
      This issue happens becuase the touchpad has a rather small buffer to
      store up to 13 input events, so if the host doesn't read those events in
      time (i.e. runtime resume takes too long), events are dropped from the
      touchpad's buffer.
      
      The bottleneck is D3cold delay it waits when transitioning from D3cold
      to D0, hence remove the delay to make the resume faster. I've tested
      some systems with intel-lpss and haven't seen any regression.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202683Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c74a801d
    • H
      i2c-cht-wc: Fix lockdep warning · 70bb4bf9
      Hans de Goede 提交于
      [ Upstream commit 232219b9a464c2479c98aa589acb1bd3383ae9d6 ]
      
      When the kernel is build with lockdep support and the i2c-cht-wc driver is
      used, the following warning is shown:
      
      [   66.674334] ======================================================
      [   66.674337] WARNING: possible circular locking dependency detected
      [   66.674340] 5.3.0-rc4+ #83 Not tainted
      [   66.674342] ------------------------------------------------------
      [   66.674345] systemd-udevd/1232 is trying to acquire lock:
      [   66.674349] 00000000a74dab07 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}, at: regmap_write+0x31/0x70
      [   66.674360]
                     but task is already holding lock:
      [   66.674362] 00000000d44a85b7 (i2c_register_adapter){+.+.}, at: i2c_smbus_xfer+0x49/0xf0
      [   66.674370]
                     which lock already depends on the new lock.
      
      [   66.674371]
                     the existing dependency chain (in reverse order) is:
      [   66.674374]
                     -> #1 (i2c_register_adapter){+.+.}:
      [   66.674381]        rt_mutex_lock_nested+0x46/0x60
      [   66.674384]        i2c_smbus_xfer+0x49/0xf0
      [   66.674387]        i2c_smbus_read_byte_data+0x45/0x70
      [   66.674391]        cht_wc_byte_reg_read+0x35/0x50
      [   66.674394]        _regmap_read+0x63/0x1a0
      [   66.674396]        _regmap_update_bits+0xa8/0xe0
      [   66.674399]        regmap_update_bits_base+0x63/0xa0
      [   66.674403]        regmap_irq_update_bits.isra.0+0x3b/0x50
      [   66.674406]        regmap_add_irq_chip+0x592/0x7a0
      [   66.674409]        devm_regmap_add_irq_chip+0x89/0xed
      [   66.674412]        cht_wc_probe+0x102/0x158
      [   66.674415]        i2c_device_probe+0x95/0x250
      [   66.674419]        really_probe+0xf3/0x380
      [   66.674422]        driver_probe_device+0x59/0xd0
      [   66.674425]        device_driver_attach+0x53/0x60
      [   66.674428]        __driver_attach+0x92/0x150
      [   66.674431]        bus_for_each_dev+0x7d/0xc0
      [   66.674434]        bus_add_driver+0x14d/0x1f0
      [   66.674437]        driver_register+0x6d/0xb0
      [   66.674440]        i2c_register_driver+0x45/0x80
      [   66.674445]        do_one_initcall+0x60/0x2f4
      [   66.674450]        kernel_init_freeable+0x20d/0x2b4
      [   66.674453]        kernel_init+0xa/0x10c
      [   66.674457]        ret_from_fork+0x3a/0x50
      [   66.674459]
                     -> #0 (intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock){+.+.}:
      [   66.674465]        __lock_acquire+0xe07/0x1930
      [   66.674468]        lock_acquire+0x9d/0x1a0
      [   66.674472]        __mutex_lock+0xa8/0x9a0
      [   66.674474]        regmap_write+0x31/0x70
      [   66.674480]        cht_wc_i2c_adap_smbus_xfer+0x72/0x240 [i2c_cht_wc]
      [   66.674483]        __i2c_smbus_xfer+0x1a3/0x640
      [   66.674486]        i2c_smbus_xfer+0x67/0xf0
      [   66.674489]        i2c_smbus_read_byte_data+0x45/0x70
      [   66.674494]        bq24190_probe+0x26b/0x410 [bq24190_charger]
      [   66.674497]        i2c_device_probe+0x189/0x250
      [   66.674500]        really_probe+0xf3/0x380
      [   66.674503]        driver_probe_device+0x59/0xd0
      [   66.674506]        device_driver_attach+0x53/0x60
      [   66.674509]        __driver_attach+0x92/0x150
      [   66.674512]        bus_for_each_dev+0x7d/0xc0
      [   66.674515]        bus_add_driver+0x14d/0x1f0
      [   66.674518]        driver_register+0x6d/0xb0
      [   66.674521]        i2c_register_driver+0x45/0x80
      [   66.674524]        do_one_initcall+0x60/0x2f4
      [   66.674528]        do_init_module+0x5c/0x230
      [   66.674531]        load_module+0x2707/0x2a20
      [   66.674534]        __do_sys_init_module+0x188/0x1b0
      [   66.674537]        do_syscall_64+0x5c/0xb0
      [   66.674541]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      [   66.674543]
                     other info that might help us debug this:
      
      [   66.674545]  Possible unsafe locking scenario:
      
      [   66.674547]        CPU0                    CPU1
      [   66.674548]        ----                    ----
      [   66.674550]   lock(i2c_register_adapter);
      [   66.674553]                                lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock);
      [   66.674556]                                lock(i2c_register_adapter);
      [   66.674559]   lock(intel_soc_pmic_chtwc:167:(&cht_wc_regmap_cfg)->lock);
      [   66.674561]
                      *** DEADLOCK ***
      
      The problem is that the CHT Whiskey Cove PMIC's builtin i2c-adapter is
      itself a part of an i2c-client (the PMIC). This means that transfers done
      through it take adapter->bus_lock twice, once for the parent i2c-adapter
      and once for its own bus_lock. Lockdep does not like this nested locking.
      
      To make lockdep happy in the case of busses with muxes, the i2c-core's
      i2c_adapter_lock_bus function calls:
      
       rt_mutex_lock_nested(&adapter->bus_lock, i2c_adapter_depth(adapter));
      
      But i2c_adapter_depth only works when the direct parent of the adapter is
      another adapter, as it is only meant for muxes. In this case there is an
      i2c-client and MFD instantiated platform_device in the parent->child chain
      between the 2 devices.
      
      This commit overrides the default i2c_lock_operations, passing a hardcoded
      depth of 1 to rt_mutex_lock_nested, making lockdep happy.
      
      Note that if there were to be a mux attached to the i2c-wc-cht adapter,
      this would break things again since the i2c-mux code expects the
      root-adapter to have a locking depth of 0. But the i2c-wc-cht adapter
      always has only 1 client directly attached in the form of the charger IC
      paired with the CHT Whiskey Cove PMIC.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      70bb4bf9