1. 26 Jul, 2019 1 commit
  2. 21 Jul, 2019 3 commits
  3. 14 Jul, 2019 3 commits
  4. 10 Jul, 2019 2 commits
    • Daniel Borkmann's avatar
      bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K · 54e8cf41
      Daniel Borkmann authored
      [ Upstream commit fdadd04931c2d7cd294dc5b2b342863f94be53a3 ]
      
      Michael and Sandipan report:
      
        Commit ede95a63b5 introduced a bpf_jit_limit tuneable to limit BPF
        JIT allocations. At compile time it defaults to PAGE_SIZE * 40000,
        and is adjusted again at init time if MODULES_VADDR is defined.
      
        For ppc64 kernels, MODULES_VADDR isn't defined, so we're stuck with
        the compile-time default at boot-time, which is 0x9c400000 when
        using 64K page size. This overflows the signed 32-bit bpf_jit_limit
        value:
      
        root@ubuntu:/tmp# cat /proc/sys/net/core/bpf_jit_limit
        -1673527296
      
        and can cause various unexpected failures throughout the network
        stack. In one case `strace dhclient eth0` reported:
      
        setsockopt(5, SOL_SOCKET, SO_ATTACH_FILTER, {len=11, filter=0x105dd27f8},
                   16) = -1 ENOTSUPP (Unknown error 524)
      
        and similar failures can be seen with tools like tcpdump. This doesn't
        always reproduce however, and I'm not sure why. The more consistent
        failure I've seen is an Ubuntu 18.04 KVM guest booted on a POWER9
        host would time out on systemd/netplan configuring a virtio-net NIC
        with no noticeable errors in the logs.
      
      Given this and also given that in near future some architectures like
      arm64 will have a custom area for BPF JIT image allocations we should
      get rid of the BPF_JIT_LIMIT_DEFAULT fallback / default entirely. For
      4.21, we have an overridable bpf_jit_alloc_exec(), bpf_jit_free_exec()
      so therefore add another overridable bpf_jit_alloc_exec_limit() helper
      function which returns the possible size of the memory area for deriving
      the default heuristic in bpf_jit_charge_init().
      
      Like bpf_jit_alloc_exec() and bpf_jit_free_exec(), the new
      bpf_jit_alloc_exec_limit() assumes that module_alloc() is the default
      JIT memory provider, and therefore in case archs implement their custom
      module_alloc() we use MODULES_{END,_VADDR} for limits and otherwise for
      vmalloc_exec() cases like on ppc64 we use VMALLOC_{END,_START}.
      
      Additionally, for archs supporting large page sizes, we should change
      the sysctl to be handled as long to not run into sysctl restrictions
      in future.
      
      Fixes: ede95a63b5e8 ("bpf: add bpf_jit_limit knob to restrict unpriv allocations")
      Reported-by: default avatarSandipan Das <sandipan@linux.ibm.com>
      Reported-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Tested-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      54e8cf41
    • Eric Dumazet's avatar
      ip6: fix skb leak in ip6frag_expire_frag_queue() · a8891c5e
      Eric Dumazet authored
      [ Upstream commit 47d3d7fdb10a21c223036b58bd70ffdc24a472c4 ]
      
      Since ip6frag_expire_frag_queue() now pulls the head skb
      from frag queue, we should no longer use skb_get(), since
      this leads to an skb leak.
      
      Stefan Bader initially reported a problem in 4.4.stable [1] caused
      by the skb_get(), so this patch should also fix this issue.
      
      296583.091021] kernel BUG at /build/linux-6VmqmP/linux-4.4.0/net/core/skbuff.c:1207!
      [296583.091734] Call Trace:
      [296583.091749]  [<ffffffff81740e50>] __pskb_pull_tail+0x50/0x350
      [296583.091764]  [<ffffffff8183939a>] _decode_session6+0x26a/0x400
      [296583.091779]  [<ffffffff817ec719>] __xfrm_decode_session+0x39/0x50
      [296583.091795]  [<ffffffff818239d0>] icmpv6_route_lookup+0xf0/0x1c0
      [296583.091809]  [<ffffffff81824421>] icmp6_send+0x5e1/0x940
      [296583.091823]  [<ffffffff81753238>] ? __netif_receive_skb+0x18/0x60
      [296583.091838]  [<ffffffff817532b2>] ? netif_receive_skb_internal+0x32/0xa0
      [296583.091858]  [<ffffffffc0199f74>] ? ixgbe_clean_rx_irq+0x594/0xac0 [ixgbe]
      [296583.091876]  [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
      [296583.091893]  [<ffffffff8183d431>] icmpv6_send+0x21/0x30
      [296583.091906]  [<ffffffff8182b500>] ip6_expire_frag_queue+0xe0/0x120
      [296583.091921]  [<ffffffffc04eb27f>] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6]
      [296583.091938]  [<ffffffff810f3b57>] call_timer_fn+0x37/0x140
      [296583.091951]  [<ffffffffc04eb260>] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6]
      [296583.091968]  [<ffffffff810f5464>] run_timer_softirq+0x234/0x330
      [296583.091982]  [<ffffffff8108a339>] __do_softirq+0x109/0x2b0
      
      Fixes: d4289fcc9b16 ("net: IP6 defrag: use rbtrees for IPv6 defrag")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarStefan Bader <stefan.bader@canonical.com>
      Cc: Peter Oskolkov <posk@google.com>
      Cc: Florian Westphal <fw@strlen.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      a8891c5e
  5. 03 Jul, 2019 8 commits
    • Will Deacon's avatar
      futex: Update comments and docs about return values of arch futex code · a319c8ff
      Will Deacon authored
      commit 427503519739e779c0db8afe876c1b33f3ac60ae upstream.
      
      The architecture implementations of 'arch_futex_atomic_op_inuser()' and
      'futex_atomic_cmpxchg_inatomic()' are permitted to return only -EFAULT,
      -EAGAIN or -ENOSYS in the case of failure.
      
      Update the comments in the asm-generic/ implementation and also a stray
      reference in the robust futex documentation.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a319c8ff
    • Daniel Borkmann's avatar
      bpf: fix unconnected udp hooks · 613bc37f
      Daniel Borkmann authored
      commit 983695fa676568fc0fe5ddd995c7267aabc24632 upstream.
      
      Intention of cgroup bind/connect/sendmsg BPF hooks is to act transparently
      to applications as also stated in original motivation in 7828f20e ("Merge
      branch 'bpf-cgroup-bind-connect'"). When recently integrating the latter
      two hooks into Cilium to enable host based load-balancing with Kubernetes,
      I ran into the issue that pods couldn't start up as DNS got broken. Kubernetes
      typically sets up DNS as a service and is thus subject to load-balancing.
      
      Upon further debugging, it turns out that the cgroupv2 sendmsg BPF hooks API
      is currently insufficient and thus not usable as-is for standard applications
      shipped with most distros. To break down the issue we ran into with a simple
      example:
      
        # cat /etc/resolv.conf
        nameserver 147.75.207.207
        nameserver 147.75.207.208
      
      For the purpose of a simple test, we set up above IPs as service IPs and
      transparently redirect traffic to a different DNS backend server for that
      node:
      
        # cilium service list
        ID   Frontend            Backend
        1    147.75.207.207:53   1 => 8.8.8.8:53
        2    147.75.207.208:53   1 => 8.8.8.8:53
      
      The attached BPF program is basically selecting one of the backends if the
      service IP/port matches on the cgroup hook. DNS breaks here, because the
      hooks are not transparent enough to applications which have built-in msg_name
      address checks:
      
        # nslookup 1.1.1.1
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        [...]
        ;; connection timed out; no servers could be reached
      
        # dig 1.1.1.1
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.208#53
        ;; reply from unexpected source: 8.8.8.8#53, expected 147.75.207.207#53
        [...]
      
        ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
        ;; global options: +cmd
        ;; connection timed out; no servers could be reached
      
      For comparison, if none of the service IPs is used, and we tell nslookup
      to use 8.8.8.8 directly it works just fine, of course:
      
        # nslookup 1.1.1.1 8.8.8.8
        1.1.1.1.in-addr.arpa	name = one.one.one.one.
      
      In order to fix this and thus act more transparent to the application,
      this needs reverse translation on recvmsg() side. A minimal fix for this
      API is to add similar recvmsg() hooks behind the BPF cgroups static key
      such that the program can track state and replace the current sockaddr_in{,6}
      with the original service IP. From BPF side, this basically tracks the
      service tuple plus socket cookie in an LRU map where the reverse NAT can
      then be retrieved via map value as one example. Side-note: the BPF cgroups
      static key should be converted to a per-hook static key in future.
      
      Same example after this fix:
      
        # cilium service list
        ID   Frontend            Backend
        1    147.75.207.207:53   1 => 8.8.8.8:53
        2    147.75.207.208:53   1 => 8.8.8.8:53
      
      Lookups work fine now:
      
        # nslookup 1.1.1.1
        1.1.1.1.in-addr.arpa    name = one.one.one.one.
      
        Authoritative answers can be found from:
      
        # dig 1.1.1.1
      
        ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> 1.1.1.1
        ;; global options: +cmd
        ;; Got answer:
        ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 51550
        ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
      
        ;; OPT PSEUDOSECTION:
        ; EDNS: version: 0, flags:; udp: 512
        ;; QUESTION SECTION:
        ;1.1.1.1.                       IN      A
      
        ;; AUTHORITY SECTION:
        .                       23426   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2019052001 1800 900 604800 86400
      
        ;; Query time: 17 msec
        ;; SERVER: 147.75.207.207#53(147.75.207.207)
        ;; WHEN: Tue May 21 12:59:38 UTC 2019
        ;; MSG SIZE  rcvd: 111
      
      And from an actual packet level it shows that we're using the back end
      server when talking via 147.75.207.20{7,8} front end:
      
        # tcpdump -i any udp
        [...]
        12:59:52.698732 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
        12:59:52.698735 IP foo.42011 > google-public-dns-a.google.com.domain: 18803+ PTR? 1.1.1.1.in-addr.arpa. (38)
        12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
        12:59:52.701208 IP google-public-dns-a.google.com.domain > foo.42011: 18803 1/0/0 PTR one.one.one.one. (67)
        [...]
      
      In order to be flexible and to have same semantics as in sendmsg BPF
      programs, we only allow return codes in [1,1] range. In the sendmsg case
      the program is called if msg->msg_name is present which can be the case
      in both, connected and unconnected UDP.
      
      The former only relies on the sockaddr_in{,6} passed via connect(2) if
      passed msg->msg_name was NULL. Therefore, on recvmsg side, we act in similar
      way to call into the BPF program whenever a non-NULL msg->msg_name was
      passed independent of sk->sk_state being TCP_ESTABLISHED or not. Note
      that for TCP case, the msg->msg_name is ignored in the regular recvmsg
      path and therefore not relevant.
      
      For the case of ip{,v6}_recv_error() paths, picked up via MSG_ERRQUEUE,
      the hook is not called. This is intentional as it aligns with the same
      semantics as in case of TCP cgroup BPF hooks right now. This might be
      better addressed in future through a different bpf_attach_type such
      that this case can be distinguished from the regular recvmsg paths,
      for example.
      
      Fixes: 1cedee13 ("bpf: Hooks for sys_sendmsg")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrey Ignatov <rdna@fb.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarMartynas Pumputis <m@lambda.lt>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      613bc37f
    • Martynas Pumputis's avatar
      bpf: simplify definition of BPF_FIB_LOOKUP related flags · 5e558f9a
      Martynas Pumputis authored
      commit b1d6c15b9d824a58c5415673f374fac19e8eccdf upstream.
      
      Previously, the BPF_FIB_LOOKUP_{DIRECT,OUTPUT} flags in the BPF UAPI
      were defined with the help of BIT macro. This had the following issues:
      
      - In order to use any of the flags, a user was required to depend
        on <linux/bits.h>.
      - No other flag in bpf.h uses the macro, so it seems that an unwritten
        convention is to use (1 << (nr)) to define BPF-related flags.
      
      Fixes: 87f5fc7e ("bpf: Provide helper to do forwarding lookups in kernel FIB table")
      Signed-off-by: default avatarMartynas Pumputis <m@lambda.lt>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e558f9a
    • Trond Myklebust's avatar
      SUNRPC: Clean up initialisation of the struct rpc_rqst · dd9f2fb5
      Trond Myklebust authored
      commit 9dc6edcf676fe188430e8b119f91280bbf285163 upstream.
      
      Move the initialisation back into xprt.c.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
      Cc: Yihao Wu <wuyihao@linux.alibaba.com>
      Cc: Caspar Zhang <caspar@linux.alibaba.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd9f2fb5
    • Tomas Bortoli's avatar
      9p: Add refcount to p9_req_t · 3665a4d9
      Tomas Bortoli authored
      [ Upstream commit 728356dedeff8ef999cb436c71333ef4ac51a81c ]
      
      To avoid use-after-free(s), use a refcount to keep track of the
      usable references to any instantiated struct p9_req_t.
      
      This commit adds p9_req_put(), p9_req_get() and p9_req_try_get() as
      wrappers to kref_put(), kref_get() and kref_get_unless_zero().
      These are used by the client and the transports to keep track of
      valid requests' references.
      
      p9_free_req() is added back and used as callback by kref_put().
      
      Add SLAB_TYPESAFE_BY_RCU as it ensures that the memory freed by
      kmem_cache_free() will not be reused for another type until the rcu
      synchronisation period is over, so an address gotten under rcu read
      lock is safe to inc_ref() without corrupting random memory while
      the lock is held.
      
      Link: http://lkml.kernel.org/r/1535626341-20693-1-git-send-email-asmadeus@codewreck.orgCo-developed-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarTomas Bortoli <tomasbortoli@gmail.com>
      Reported-by: syzbot+467050c1ce275af2a5b8@syzkaller.appspotmail.com
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3665a4d9
    • Dominique Martinet's avatar
      9p: add a per-client fcall kmem_cache · be87f21e
      Dominique Martinet authored
      [ Upstream commit 91a76be37ff89795526c452a6799576b03bec501 ]
      
      Having a specific cache for the fcall allocations helps speed up
      end-to-end latency.
      
      The caches will automatically be merged if there are multiple caches
      of items with the same size so we do not need to try to share a cache
      between different clients of the same size.
      
      Since the msize is negotiated with the server, only allocate the cache
      after that negotiation has happened - previous allocations or
      allocations of different sizes (e.g. zero-copy fcall) are made with
      kmalloc directly.
      
      Some figures on two beefy VMs with Connect-IB (sriov) / trans=rdma,
      with ior running 32 processes in parallel doing small 32 bytes IOs:
       - no alloc (4.18-rc7 request cache): 65.4k req/s
       - non-power of two alloc, no patch: 61.6k req/s
       - power of two alloc, no patch: 62.2k req/s
       - non-power of two alloc, with patch: 64.7k req/s
       - power of two alloc, with patch: 65.1k req/s
      
      Link: http://lkml.kernel.org/r/1532943263-24378-2-git-send-email-asmadeus@codewreck.orgSigned-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Acked-by: default avatarJun Piao <piaojun@huawei.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Greg Kurz <groug@kaod.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      be87f21e
    • Dominique Martinet's avatar
      9p: embed fcall in req to round down buffer allocs · 1555583b
      Dominique Martinet authored
      [ Upstream commit 523adb6cc10b48655c0abe556505240741425b49 ]
      
      'msize' is often a power of two, or at least page-aligned, so avoiding
      an overhead of two dozen bytes for each allocation will help the
      allocator do its work and reduce memory fragmentation.
      
      Link: http://lkml.kernel.org/r/1533825236-22896-1-git-send-email-asmadeus@codewreck.orgSuggested-by: default avatarMatthew Wilcox <willy@infradead.org>
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
      Acked-by: default avatarJun Piao <piaojun@huawei.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1555583b
    • Matthew Wilcox's avatar
      9p: Use a slab for allocating requests · 3ea4cf42
      Matthew Wilcox authored
      [ Upstream commit 996d5b4db4b191f2676cf8775565cab8a5e2753b ]
      
      Replace the custom batch allocation with a slab.  Use an IDR to store
      pointers to the active requests instead of an array.  We don't try to
      handle P9_NOTAG specially; the IDR will happily shrink all the way back
      once the TVERSION call has completed.
      
      Link: http://lkml.kernel.org/r/20180711210225.19730-6-willy@infradead.orgSigned-off-by: default avatarMatthew Wilcox <willy@infradead.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Ron Minnich <rminnich@sandia.gov>
      Cc: Latchesar Ionkov <lucho@ionkov.net>
      Signed-off-by: default avatarDominique Martinet <dominique.martinet@cea.fr>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3ea4cf42
  6. 25 Jun, 2019 4 commits
    • Manikanta Pubbisetty's avatar
      {nl,mac}80211: allow 4addr AP operation on crypto controlled devices · ccf6a155
      Manikanta Pubbisetty authored
      commit 33d915d9e8ce811d8958915ccd18d71a66c7c495 upstream.
      
      As per the current design, in the case of sw crypto controlled devices,
      it is the device which advertises the support for AP/VLAN iftype based
      on it's ability to tranmsit packets encrypted in software
      (In VLAN functionality, group traffic generated for a specific
      VLAN group is always encrypted in software). Commit db3bdcb9
      ("mac80211: allow AP_VLAN operation on crypto controlled devices")
      has introduced this change.
      
      Since 4addr AP operation also uses AP/VLAN iftype, this conditional
      way of advertising AP/VLAN support has broken 4addr AP mode operation on
      crypto controlled devices which do not support VLAN functionality.
      
      In the case of ath10k driver, not all firmwares have support for VLAN
      functionality but all can support 4addr AP operation. Because AP/VLAN
      support is not advertised for these devices, 4addr AP operations are
      also blocked.
      
      Fix this by allowing 4addr operation on devices which do not support
      AP/VLAN iftype but can support 4addr AP operation (decision is based on
      the wiphy flag WIPHY_FLAG_4ADDR_AP).
      
      Cc: stable@vger.kernel.org
      Fixes: db3bdcb9 ("mac80211: allow AP_VLAN operation on crypto controlled devices")
      Signed-off-by: default avatarManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ccf6a155
    • Marcel Holtmann's avatar
      Bluetooth: Align minimum encryption key size for LE and BR/EDR connections · 5e9a6c68
      Marcel Holtmann authored
      commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.
      
      The minimum encryption key size for LE connections is 56 bits and to
      align LE with BR/EDR, enforce 56 bits of minimum encryption key size for
      BR/EDR connections as well.
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e9a6c68
    • Douglas Anderson's avatar
      mmc: core: Add sdio_retune_hold_now() and sdio_retune_release() · 0349dbeb
      Douglas Anderson authored
      commit b4c9f938d542d5f88c501744d2d12fad4fd2915f upstream.
      
      We want SDIO drivers to be able to temporarily stop retuning when the
      driver knows that the SDIO card is not in a state where retuning will
      work (maybe because the card is asleep).  We'll move the relevant
      functions to a place where drivers can call them.
      
      Cc: stable@vger.kernel.org #v4.18+
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0349dbeb
    • Douglas Anderson's avatar
      mmc: core: API to temporarily disable retuning for SDIO CRC errors · 7ed49e1b
      Douglas Anderson authored
      commit 0a55f4ab9678413a01e740c86e9367ba0c612b36 upstream.
      
      Normally when the MMC core sees an "-EILSEQ" error returned by a host
      controller then it will trigger a retuning of the card.  This is
      generally a good idea.
      
      However, if a command is expected to sometimes cause transfer errors
      then these transfer errors shouldn't cause a re-tuning.  This
      re-tuning will be a needless waste of time.  One example case where a
      transfer is expected to cause errors is when transitioning between
      idle (sometimes referred to as "sleep" in Broadcom code) and active
      state on certain Broadcom WiFi SDIO cards.  Specifically if the card
      was already transitioning between states when the command was sent it
      could cause an error on the SDIO bus.
      
      Let's add an API that the SDIO function drivers can call that will
      temporarily disable the auto-tuning functionality.  Then we can add a
      call to this in the Broadcom WiFi driver and any other driver that
      might have similar needs.
      
      NOTE: this makes the assumption that the card is already tuned well
      enough that it's OK to disable the auto-retuning during one of these
      error-prone situations.  Presumably the driver code performing the
      error-prone transfer knows how to recover / retry from errors.  ...and
      after we can get back to a state where transfers are no longer
      error-prone then we can enable the auto-retuning again.  If we truly
      find ourselves in a case where the card needs to be retuned sometimes
      to handle one of these error-prone transfers then we can always try a
      few transfers first without auto-retuning and then re-try with
      auto-retuning if the first few fail.
      
      Without this change on rk3288-veyron-minnie I periodically see this in
      the logs of a machine just sitting there idle:
        dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ
      
      Cc: stable@vger.kernel.org #v4.18+
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ed49e1b
  7. 22 Jun, 2019 1 commit
    • Andrea Arcangeli's avatar
      coredump: fix race condition between collapse_huge_page() and core dumping · 465ce9a5
      Andrea Arcangeli authored
      commit 59ea6d06cfa9247b586a695c21f94afa7183af74 upstream.
      
      When fixing the race conditions between the coredump and the mmap_sem
      holders outside the context of the process, we focused on
      mmget_not_zero()/get_task_mm() callers in 04f5866e41fb70 ("coredump: fix
      race condition between mmget_not_zero()/get_task_mm() and core
      dumping"), but those aren't the only cases where the mmap_sem can be
      taken outside of the context of the process as Michal Hocko noticed
      while backporting that commit to older -stable kernels.
      
      If mmgrab() is called in the context of the process, but then the
      mm_count reference is transferred outside the context of the process,
      that can also be a problem if the mmap_sem has to be taken for writing
      through that mm_count reference.
      
      khugepaged registration calls mmgrab() in the context of the process,
      but the mmap_sem for writing is taken later in the context of the
      khugepaged kernel thread.
      
      collapse_huge_page() after taking the mmap_sem for writing doesn't
      modify any vma, so it's not obvious that it could cause a problem to the
      coredump, but it happens to modify the pmd in a way that breaks an
      invariant that pmd_trans_huge_lock() relies upon.  collapse_huge_page()
      needs the mmap_sem for writing just to block concurrent page faults that
      call pmd_trans_huge_lock().
      
      Specifically the invariant that "!pmd_trans_huge()" cannot become a
      "pmd_trans_huge()" doesn't hold while collapse_huge_page() runs.
      
      The coredump will call __get_user_pages() without mmap_sem for reading,
      which eventually can invoke a lockless page fault which will need a
      functional pmd_trans_huge_lock().
      
      So collapse_huge_page() needs to use mmget_still_valid() to check it's
      not running concurrently with the coredump...  as long as the coredump
      can invoke page faults without holding the mmap_sem for reading.
      
      This has "Fixes: khugepaged" to facilitate backporting, but in my view
      it's more a bug in the coredump code that will eventually have to be
      rewritten to stop invoking page faults without the mmap_sem for reading.
      So the long term plan is still to drop all mmget_still_valid().
      
      Link: http://lkml.kernel.org/r/20190607161558.32104-1-aarcange@redhat.com
      Fixes: ba76149f ("thp: khugepaged")
      Signed-off-by: default avatarAndrea Arcangeli <aarcange@redhat.com>
      Reported-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Acked-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: Mike Kravetz <mike.kravetz@oracle.com>
      Cc: Peter Xu <peterx@redhat.com>
      Cc: Jason Gunthorpe <jgg@mellanox.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      465ce9a5
  8. 19 Jun, 2019 3 commits
    • Jani Nikula's avatar
      drm: add fallback override/firmware EDID modes workaround · 04757d0e
      Jani Nikula authored
      commit 48eaeb7664c76139438724d520a1ea4a84a3ed92 upstream.
      
      We've moved the override and firmware EDID (simply "override EDID" from
      now on) handling to the low level drm_do_get_edid() function in order to
      transparently use the override throughout the stack. The idea is that
      you get the override EDID via the ->get_modes() hook.
      
      Unfortunately, there are scenarios where the DDC probe in drm_get_edid()
      called via ->get_modes() fails, although the preceding ->detect()
      succeeds.
      
      In the case reported by Paul Wise, the ->detect() hook,
      intel_crt_detect(), relies on hotplug detect, bypassing the DDC. In the
      case reported by Ilpo Järvinen, there is no ->detect() hook, which is
      interpreted as connected. The subsequent DDC probe reached via
      ->get_modes() fails, and we don't even look at the override EDID,
      resulting in no modes being added.
      
      Because drm_get_edid() is used via ->detect() all over the place, we
      can't trivially remove the DDC probe, as it leads to override EDID
      effectively meaning connector forcing. The goal is that connector
      forcing and override EDID remain orthogonal.
      
      Generally, the underlying problem here is the conflation of ->detect()
      and ->get_modes() via drm_get_edid(). The former should just detect, and
      the latter should just get the modes, typically via reading the EDID. As
      long as drm_get_edid() is used in ->detect(), it needs to retain the DDC
      probe. Or such users need to have a separate DDC probe step first.
      
      The EDID caching between ->detect() and ->get_modes() done by some
      drivers is a further complication that prevents us from making
      drm_do_get_edid() adapt to the two cases.
      
      Work around the regression by falling back to a separate attempt at
      getting the override EDID at drm_helper_probe_single_connector_modes()
      level. With a working DDC and override EDID, it'll never be called; the
      override EDID will come via ->get_modes(). There will still be a failing
      DDC probe attempt in the cases that require the fallback.
      
      v2:
      - Call drm_connector_update_edid_property (Paul)
      - Update commit message about EDID caching (Daniel)
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107583Reported-by: default avatarPaul Wise <pabs3@bonedaddy.net>
      Cc: Paul Wise <pabs3@bonedaddy.net>
      References: http://mid.mail-archive.com/alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fiReported-by: default avatarIlpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
      Cc: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi>
      Suggested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      References: 15f080f0 ("drm/edid: respect connector force for drm_get_edid ddc probe")
      Fixes: 53fd40a9 ("drm: handle override and firmware EDID at drm_do_get_edid() level")
      Cc: <stable@vger.kernel.org> # v4.15+ 56a2b7f2a39a drm/edid: abstract override/firmware EDID retrieval
      Cc: <stable@vger.kernel.org> # v4.15+
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Harish Chegondi <harish.chegondi@intel.com>
      Tested-by: default avatarPaul Wise <pabs3@bonedaddy.net>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190610093054.28445-1-jani.nikula@intel.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      04757d0e
    • Borislav Petkov's avatar
      x86/microcode, cpuhotplug: Add a microcode loader CPU hotplug callback · ecec31ce
      Borislav Petkov authored
      commit 78f4e932f7760d965fb1569025d1576ab77557c5 upstream.
      
      Adric Blake reported the following warning during suspend-resume:
      
        Enabling non-boot CPUs ...
        x86: Booting SMP configuration:
        smpboot: Booting Node 0 Processor 1 APIC 0x2
        unchecked MSR access error: WRMSR to 0x10f (tried to write 0x0000000000000000) \
         at rIP: 0xffffffff8d267924 (native_write_msr+0x4/0x20)
        Call Trace:
         intel_set_tfa
         intel_pmu_cpu_starting
         ? x86_pmu_dead_cpu
         x86_pmu_starting_cpu
         cpuhp_invoke_callback
         ? _raw_spin_lock_irqsave
         notify_cpu_starting
         start_secondary
         secondary_startup_64
        microcode: sig=0x806ea, pf=0x80, revision=0x96
        microcode: updated to revision 0xb4, date = 2019-04-01
        CPU1 is up
      
      The MSR in question is MSR_TFA_RTM_FORCE_ABORT and that MSR is emulated
      by microcode. The log above shows that the microcode loader callback
      happens after the PMU restoration, leading to the conjecture that
      because the microcode hasn't been updated yet, that MSR is not present
      yet, leading to the #GP.
      
      Add a microcode loader-specific hotplug vector which comes before
      the PERF vectors and thus executes earlier and makes sure the MSR is
      present.
      
      Fixes: 400816f60c54 ("perf/x86/intel: Implement support for TSX Force Abort")
      Reported-by: default avatarAdric Blake <promarbler14@gmail.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: <stable@vger.kernel.org>
      Cc: x86@kernel.org
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=203637Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ecec31ce
    • Tejun Heo's avatar
      cgroup: Use css_tryget() instead of css_tryget_online() in task_get_css() · c3b85bda
      Tejun Heo authored
      commit 18fa84a2db0e15b02baa5d94bdb5bd509175d2f6 upstream.
      
      A PF_EXITING task can stay associated with an offline css.  If such
      task calls task_get_css(), it can get stuck indefinitely.  This can be
      triggered by BSD process accounting which writes to a file with
      PF_EXITING set when racing against memcg disable as in the backtrace
      at the end.
      
      After this change, task_get_css() may return a css which was already
      offline when the function was called.  None of the existing users are
      affected by this change.
      
        INFO: rcu_sched self-detected stall on CPU
        INFO: rcu_sched detected stalls on CPUs/tasks:
        ...
        NMI backtrace for cpu 0
        ...
        Call Trace:
         <IRQ>
         dump_stack+0x46/0x68
         nmi_cpu_backtrace.cold.2+0x13/0x57
         nmi_trigger_cpumask_backtrace+0xba/0xca
         rcu_dump_cpu_stacks+0x9e/0xce
         rcu_check_callbacks.cold.74+0x2af/0x433
         update_process_times+0x28/0x60
         tick_sched_timer+0x34/0x70
         __hrtimer_run_queues+0xee/0x250
         hrtimer_interrupt+0xf4/0x210
         smp_apic_timer_interrupt+0x56/0x110
         apic_timer_interrupt+0xf/0x20
         </IRQ>
        RIP: 0010:balance_dirty_pages_ratelimited+0x28f/0x3d0
        ...
         btrfs_file_write_iter+0x31b/0x563
         __vfs_write+0xfa/0x140
         __kernel_write+0x4f/0x100
         do_acct_process+0x495/0x580
         acct_process+0xb9/0xdb
         do_exit+0x748/0xa00
         do_group_exit+0x3a/0xa0
         get_signal+0x254/0x560
         do_signal+0x23/0x5c0
         exit_to_usermode_loop+0x5d/0xa0
         prepare_exit_to_usermode+0x53/0x80
         retint_user+0x8/0x8
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: stable@vger.kernel.org # v4.2+
      Fixes: ec438699 ("cgroup, block: implement task_get_css() and use it in bio_associate_current()")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c3b85bda
  9. 17 Jun, 2019 3 commits
    • Eric Dumazet's avatar
      tcp: add tcp_min_snd_mss sysctl · 7f9f8a37
      Eric Dumazet authored
      commit 5f3e2bf008c2221478101ee72f5cb4654b9fc363 upstream.
      
      Some TCP peers announce a very small MSS option in their SYN and/or
      SYN/ACK messages.
      
      This forces the stack to send packets with a very high network/cpu
      overhead.
      
      Linux has enforced a minimal value of 48. Since this value includes
      the size of TCP options, and that the options can consume up to 40
      bytes, this means that each segment can include only 8 bytes of payload.
      
      In some cases, it can be useful to increase the minimal value
      to a saner value.
      
      We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility
      reasons.
      
      Note that TCP_MAXSEG socket option enforces a minimal value
      of (TCP_MIN_MSS). David Miller increased this minimal value
      in commit c39508d6 ("tcp: Make TCP_MAXSEG minimum more correct.")
      from 64 to 88.
      
      We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS.
      
      CVE-2019-11479 -- tcp mss hardcoded to 48
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Suggested-by: default avatarJonathan Looney <jtl@netflix.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Tyler Hicks <tyhicks@canonical.com>
      Cc: Bruce Curtis <brucec@netflix.com>
      Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f9f8a37
    • Eric Dumazet's avatar
      tcp: tcp_fragment() should apply sane memory limits · ec839218
      Eric Dumazet authored
      commit f070ef2ac66716357066b683fb0baf55f8191a2e upstream.
      
      Jonathan Looney reported that a malicious peer can force a sender
      to fragment its retransmit queue into tiny skbs, inflating memory
      usage and/or overflow 32bit counters.
      
      TCP allows an application to queue up to sk_sndbuf bytes,
      so we need to give some allowance for non malicious splitting
      of retransmit queue.
      
      A new SNMP counter is added to monitor how many times TCP
      did not allow to split an skb if the allowance was exceeded.
      
      Note that this counter might increase in the case applications
      use SO_SNDBUF socket option to lower sk_sndbuf.
      
      CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the
      	socket is already using more than half the allowed space
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarJonathan Looney <jtl@netflix.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Acked-by: default avatarYuchung Cheng <ycheng@google.com>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: Bruce Curtis <brucec@netflix.com>
      Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec839218
    • Eric Dumazet's avatar
      tcp: limit payload size of sacked skbs · c09be314
      Eric Dumazet authored
      commit 3b4929f65b0d8249f19a50245cd88ed1a2f78cff upstream.
      
      Jonathan Looney reported that TCP can trigger the following crash
      in tcp_shifted_skb() :
      
      	BUG_ON(tcp_skb_pcount(skb) < pcount);
      
      This can happen if the remote peer has advertized the smallest
      MSS that linux TCP accepts : 48
      
      An skb can hold 17 fragments, and each fragment can hold 32KB
      on x86, or 64KB on PowerPC.
      
      This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs
      can overflow.
      
      Note that tcp_sendmsg() builds skbs with less than 64KB
      of payload, so this problem needs SACK to be enabled.
      SACK blocks allow TCP to coalesce multiple skbs in the retransmit
      queue, thus filling the 17 fragments to maximal capacity.
      
      CVE-2019-11477 -- u16 overflow of TCP_SKB_CB(skb)->tcp_gso_segs
      
      Fixes: 832d11c5 ("tcp: Try to restore large SKBs while SACK processing")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarJonathan Looney <jtl@netflix.com>
      Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
      Reviewed-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Bruce Curtis <brucec@netflix.com>
      Cc: Jonathan Lemon <jonathan.lemon@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c09be314
  10. 15 Jun, 2019 2 commits
    • Greg Kroah-Hartman's avatar
      Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections" · 8e5483ae
      Greg Kroah-Hartman authored
      This reverts commit 38f092c4 which is
      commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.
      
      Lots of people have reported issues with this patch, and as there does
      not seem to be a fix going into Linus's kernel tree any time soon,
      revert the commit in the stable trees so as to get people's machines
      working properly again.
      Reported-by: default avatarVasily Khoruzhick <anarsoul@gmail.com>
      Reported-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: Jeremy Cline <jeremy@jcline.org>
      Cc: Marcel Holtmann <marcel@holtmann.org>
      Cc: Johan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8e5483ae
    • Phong Hoang's avatar
      pwm: Fix deadlock warning when removing PWM device · 384642ff
      Phong Hoang authored
      [ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ]
      
      This patch fixes deadlock warning if removing PWM device
      when CONFIG_PROVE_LOCKING is enabled.
      
      This issue can be reproceduced by the following steps on
      the R-Car H3 Salvator-X board if the backlight is disabled:
      
       # cd /sys/class/pwm/pwmchip0
       # echo 0 > export
       # ls
       device  export  npwm  power  pwm0  subsystem  uevent  unexport
       # cd device/driver
       # ls
       bind  e6e31000.pwm  uevent  unbind
       # echo e6e31000.pwm > unbind
      
      [   87.659974] ======================================================
      [   87.666149] WARNING: possible circular locking dependency detected
      [   87.672327] 5.0.0 #7 Not tainted
      [   87.675549] ------------------------------------------------------
      [   87.681723] bash/2986 is trying to acquire lock:
      [   87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
      [   87.694528]
      [   87.694528] but task is already holding lock:
      [   87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
      [   87.707405]
      [   87.707405] which lock already depends on the new lock.
      [   87.707405]
      [   87.715574]
      [   87.715574] the existing dependency chain (in reverse order) is:
      [   87.723048]
      [   87.723048] -> #1 (pwm_lock){+.+.}:
      [   87.728017]        __mutex_lock+0x70/0x7e4
      [   87.732108]        mutex_lock_nested+0x1c/0x24
      [   87.736547]        pwm_request_from_chip.part.6+0x34/0x74
      [   87.741940]        pwm_request_from_chip+0x20/0x40
      [   87.746725]        export_store+0x6c/0x1f4
      [   87.750820]        dev_attr_store+0x18/0x28
      [   87.754998]        sysfs_kf_write+0x54/0x64
      [   87.759175]        kernfs_fop_write+0xe4/0x1e8
      [   87.763615]        __vfs_write+0x40/0x184
      [   87.767619]        vfs_write+0xa8/0x19c
      [   87.771448]        ksys_write+0x58/0xbc
      [   87.775278]        __arm64_sys_write+0x18/0x20
      [   87.779721]        el0_svc_common+0xd0/0x124
      [   87.783986]        el0_svc_compat_handler+0x1c/0x24
      [   87.788858]        el0_svc_compat+0x8/0x18
      [   87.792947]
      [   87.792947] -> #0 (kn->count#58){++++}:
      [   87.798260]        lock_acquire+0xc4/0x22c
      [   87.802353]        __kernfs_remove+0x258/0x2c4
      [   87.806790]        kernfs_remove_by_name_ns+0x50/0xa0
      [   87.811836]        remove_files.isra.1+0x38/0x78
      [   87.816447]        sysfs_remove_group+0x48/0x98
      [   87.820971]        sysfs_remove_groups+0x34/0x4c
      [   87.825583]        device_remove_attrs+0x6c/0x7c
      [   87.830197]        device_del+0x11c/0x33c
      [   87.834201]        device_unregister+0x14/0x2c
      [   87.838638]        pwmchip_sysfs_unexport+0x40/0x4c
      [   87.843509]        pwmchip_remove+0xf4/0x13c
      [   87.847773]        rcar_pwm_remove+0x28/0x34
      [   87.852039]        platform_drv_remove+0x24/0x64
      [   87.856651]        device_release_driver_internal+0x18c/0x21c
      [   87.862391]        device_release_driver+0x14/0x1c
      [   87.867175]        unbind_store+0xe0/0x124
      [   87.871265]        drv_attr_store+0x20/0x30
      [   87.875442]        sysfs_kf_write+0x54/0x64
      [   87.879618]        kernfs_fop_write+0xe4/0x1e8
      [   87.884055]        __vfs_write+0x40/0x184
      [   87.888057]        vfs_write+0xa8/0x19c
      [   87.891887]        ksys_write+0x58/0xbc
      [   87.895716]        __arm64_sys_write+0x18/0x20
      [   87.900154]        el0_svc_common+0xd0/0x124
      [   87.904417]        el0_svc_compat_handler+0x1c/0x24
      [   87.909289]        el0_svc_compat+0x8/0x18
      [   87.913378]
      [   87.913378] other info that might help us debug this:
      [   87.913378]
      [   87.921374]  Possible unsafe locking scenario:
      [   87.921374]
      [   87.927286]        CPU0                    CPU1
      [   87.931808]        ----                    ----
      [   87.936331]   lock(pwm_lock);
      [   87.939293]                                lock(kn->count#58);
      [   87.945120]                                lock(pwm_lock);
      [   87.950599]   lock(kn->count#58);
      [   87.953908]
      [   87.953908]  *** DEADLOCK ***
      [   87.953908]
      [   87.959821] 4 locks held by bash/2986:
      [   87.963563]  #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
      [   87.971044]  #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
      [   87.978872]  #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
      [   87.988001]  #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
      [   87.995481]
      [   87.995481] stack backtrace:
      [   87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
      [   88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
      [   88.012791] Call trace:
      [   88.015235]  dump_backtrace+0x0/0x190
      [   88.018891]  show_stack+0x14/0x1c
      [   88.022204]  dump_stack+0xb0/0xec
      [   88.025514]  print_circular_bug.isra.32+0x1d0/0x2e0
      [   88.030385]  __lock_acquire+0x1318/0x1864
      [   88.034388]  lock_acquire+0xc4/0x22c
      [   88.037958]  __kernfs_remove+0x258/0x2c4
      [   88.041874]  kernfs_remove_by_name_ns+0x50/0xa0
      [   88.046398]  remove_files.isra.1+0x38/0x78
      [   88.050487]  sysfs_remove_group+0x48/0x98
      [   88.054490]  sysfs_remove_groups+0x34/0x4c
      [   88.058580]  device_remove_attrs+0x6c/0x7c
      [   88.062671]  device_del+0x11c/0x33c
      [   88.066154]  device_unregister+0x14/0x2c
      [   88.070070]  pwmchip_sysfs_unexport+0x40/0x4c
      [   88.074421]  pwmchip_remove+0xf4/0x13c
      [   88.078163]  rcar_pwm_remove+0x28/0x34
      [   88.081906]  platform_drv_remove+0x24/0x64
      [   88.085996]  device_release_driver_internal+0x18c/0x21c
      [   88.091215]  device_release_driver+0x14/0x1c
      [   88.095478]  unbind_store+0xe0/0x124
      [   88.099048]  drv_attr_store+0x20/0x30
      [   88.102704]  sysfs_kf_write+0x54/0x64
      [   88.106359]  kernfs_fop_write+0xe4/0x1e8
      [   88.110275]  __vfs_write+0x40/0x184
      [   88.113757]  vfs_write+0xa8/0x19c
      [   88.117065]  ksys_write+0x58/0xbc
      [   88.120374]  __arm64_sys_write+0x18/0x20
      [   88.124291]  el0_svc_common+0xd0/0x124
      [   88.128034]  el0_svc_compat_handler+0x1c/0x24
      [   88.132384]  el0_svc_compat+0x8/0x18
      
      The sysfs unexport in pwmchip_remove() is completely asymmetric
      to what we do in pwmchip_add_with_polarity() and commit 0733424c
      ("pwm: Unexport children before chip removal") is a strong indication
      that this was wrong to begin with. We should just move
      pwmchip_sysfs_unexport() where it belongs, which is right after
      pwmchip_sysfs_unexport_children(). In that case, we do not need
      separate functions anymore either.
      
      We also really want to remove sysfs irrespective of whether or not
      the chip will be removed as a result of pwmchip_remove(). We can only
      assume that the driver will be gone after that, so we shouldn't leave
      any dangling sysfs files around.
      
      This warning disappears if we move pwmchip_sysfs_unexport() to
      the top of pwmchip_remove(), pwmchip_sysfs_unexport_children().
      That way it is also outside of the pwm_lock section, which indeed
      doesn't seem to be needed.
      
      Moving the pwmchip_sysfs_export() call outside of that section also
      seems fine and it'd be perfectly symmetric with pwmchip_remove() again.
      
      So, this patch fixes them.
      Signed-off-by: default avatarPhong Hoang <phong.hoang.wz@renesas.com>
      [shimoda: revise the commit log and code]
      Fixes: 76abbdde ("pwm: Add sysfs interface")
      Fixes: 0733424c ("pwm: Unexport children before chip removal")
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Tested-by: default avatarHoan Nguyen An <na-hoan@jinso.co.jp>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: default avatarThierry Reding <thierry.reding@gmail.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      384642ff
  11. 11 Jun, 2019 8 commits
    • David Ahern's avatar
      ipv4: Define __ipv4_neigh_lookup_noref when CONFIG_INET is disabled · 645fa685
      David Ahern authored
      commit 9b3040a6aafd7898ece7fc7efcbca71e42aa8069 upstream.
      
      Define __ipv4_neigh_lookup_noref to return NULL when CONFIG_INET is disabled.
      
      Fixes: 4b2a2bfeb3f0 ("neighbor: Call __ipv4_neigh_lookup_noref in neigh_xmit")
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Cc: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      645fa685
    • Helen Koike's avatar
      drm: don't block fb changes for async plane updates · fbb7e114
      Helen Koike authored
      commit 89a4aac0ab0e6f5eea10d7bf4869dd15c3de2cd4 upstream.
      
      In the case of a normal sync update, the preparation of framebuffers (be
      it calling drm_atomic_helper_prepare_planes() or doing setups with
      drm_framebuffer_get()) are performed in the new_state and the respective
      cleanups are performed in the old_state.
      
      In the case of async updates, the preparation is also done in the
      new_state but the cleanups are done in the new_state (because updates
      are performed in place, i.e. in the current state).
      
      The current code blocks async udpates when the fb is changed, turning
      async updates into sync updates, slowing down cursor updates and
      introducing regressions in igt tests with errors of type:
      
      "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
      expect to complete approximately 15360 updates, with the threshold set
      at 7680"
      
      Fb changes in async updates were prevented to avoid the following scenario:
      
      - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
      - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
      - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2 (wrong)
      Where we have a single call to prepare fb2 but double cleanup call to fb2.
      
      To solve the above problems, instead of blocking async fb changes, we
      place the old framebuffer in the new_state object, so when the code
      performs cleanups in the new_state it will cleanup the old_fb and we
      will have the following scenario instead:
      
      - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
      - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
      - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
      
      Where calls to prepare/cleanup are balanced.
      
      Cc: <stable@vger.kernel.org> # v4.14+
      Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
      Suggested-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Signed-off-by: default avatarHelen Koike <helen.koike@collabora.com>
      Reviewed-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Reviewed-by: default avatarNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@collabora.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190603165610.24614-6-helen.koike@collabora.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fbb7e114
    • Chris Wilson's avatar
      drm/i915: Fix I915_EXEC_RING_MASK · 554f4253
      Chris Wilson authored
      commit d90c06d57027203f73021bb7ddb30b800d65c636 upstream.
      
      This was supposed to be a mask of all known rings, but it is being used
      by execbuffer to filter out invalid rings, and so is instead mapping high
      unused values onto valid rings. Instead of a mask of all known rings,
      we need it to be the mask of all possible rings.
      
      Fixes: 549f7365 ("drm/i915: Enable SandyBridge blitter ring")
      Fixes: de1add36 ("drm/i915: Decouple execbuf uAPI from internal implementation")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: <stable@vger.kernel.org> # v4.6+
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190301140404.26690-21-chris@chris-wilson.co.ukSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      554f4253
    • Jiri Kosina's avatar
      x86/power: Fix 'nosmt' vs hibernation triple fault during resume · 4d166206
      Jiri Kosina authored
      commit ec527c318036a65a083ef68d8ba95789d2212246 upstream.
      
      As explained in
      
      	0cc3cd21 ("cpu/hotplug: Boot HT siblings at least once")
      
      we always, no matter what, have to bring up x86 HT siblings during boot at
      least once in order to avoid first MCE bringing the system to its knees.
      
      That means that whenever 'nosmt' is supplied on the kernel command-line,
      all the HT siblings are as a result sitting in mwait or cpudile after
      going through the online-offline cycle at least once.
      
      This causes a serious issue though when a kernel, which saw 'nosmt' on its
      commandline, is going to perform resume from hibernation: if the resume
      from the hibernated image is successful, cr3 is flipped in order to point
      to the address space of the kernel that is being resumed, which in turn
      means that all the HT siblings are all of a sudden mwaiting on address
      which is no longer valid.
      
      That results in triple fault shortly after cr3 is switched, and machine
      reboots.
      
      Fix this by always waking up all the SMT siblings before initiating the
      'restore from hibernation' process; this guarantees that all the HT
      siblings will be properly carried over to the resumed kernel waiting in
      resume_play_dead(), and acted upon accordingly afterwards, based on the
      target kernel configuration.
      
      Symmetricaly, the resumed kernel has to push the SMT siblings to mwait
      again in case it has SMT disabled; this means it has to online all
      the siblings when resuming (so that they come out of hlt) and offline
      them again to let them reach mwait.
      
      Cc: 4.19+ <stable@vger.kernel.org> # v4.19+
      Debugged-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Fixes: 0cc3cd21 ("cpu/hotplug: Boot HT siblings at least once")
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4d166206
    • Kees Cook's avatar
      pstore: Convert buf_lock to semaphore · d4128a1b
      Kees Cook authored
      commit ea84b580b95521644429cc6748b6c2bf27c8b0f3 upstream.
      
      Instead of running with interrupts disabled, use a semaphore. This should
      make it easier for backends that may need to sleep (e.g. EFI) when
      performing a write:
      
      |BUG: sleeping function called from invalid context at kernel/sched/completion.c:99
      |in_atomic(): 1, irqs_disabled(): 1, pid: 2236, name: sig-xstate-bum
      |Preemption disabled at:
      |[<ffffffff99d60512>] pstore_dump+0x72/0x330
      |CPU: 26 PID: 2236 Comm: sig-xstate-bum Tainted: G      D           4.20.0-rc3 #45
      |Call Trace:
      | dump_stack+0x4f/0x6a
      | ___might_sleep.cold.91+0xd3/0xe4
      | __might_sleep+0x50/0x90
      | wait_for_completion+0x32/0x130
      | virt_efi_query_variable_info+0x14e/0x160
      | efi_query_variable_store+0x51/0x1a0
      | efivar_entry_set_safe+0xa3/0x1b0
      | efi_pstore_write+0x109/0x140
      | pstore_dump+0x11c/0x330
      | kmsg_dump+0xa4/0xd0
      | oops_exit+0x22/0x30
      ...
      Reported-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Fixes: 21b3ddd3 ("efi: Don't use spinlocks for efi vars")
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4128a1b
    • Linus Torvalds's avatar
      rcu: locking and unlocking need to always be at least barriers · 6726307d
      Linus Torvalds authored
      commit 66be4e66a7f422128748e3c3ef6ee72b20a6197b upstream.
      
      Herbert Xu pointed out that commit bb73c52b ("rcu: Don't disable
      preemption for Tiny and Tree RCU readers") was incorrect in making the
      preempt_disable/enable() be conditional on CONFIG_PREEMPT_COUNT.
      
      If CONFIG_PREEMPT_COUNT isn't enabled, the preemption enable/disable is
      a no-op, but still is a compiler barrier.
      
      And RCU locking still _needs_ that compiler barrier.
      
      It is simply fundamentally not true that RCU locking would be a complete
      no-op: we still need to guarantee (for example) that things that can
      trap and cause preemption cannot migrate into the RCU locked region.
      
      The way we do that is by making it a barrier.
      
      See for example commit 386afc91 ("spinlocks and preemption points
      need to be at least compiler barriers") from back in 2013 that had
      similar issues with spinlocks that become no-ops on UP: they must still
      constrain the compiler from moving other operations into the critical
      region.
      
      Now, it is true that a lot of RCU operations already use READ_ONCE() and
      WRITE_ONCE() (which in practice likely would never be re-ordered wrt
      anything remotely interesting), but it is also true that that is not
      globally the case, and that it's not even necessarily always possible
      (ie bitfields etc).
      Reported-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Fixes: bb73c52b ("rcu: Don't disable preemption for Tiny and Tree RCU readers")
      Cc: stable@kernel.org
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6726307d
    • Jakub Kicinski's avatar
      net/tls: replace the sleeping lock around RX resync with a bit lock · be0343af
      Jakub Kicinski authored
      [ Upstream commit e52972c11d6b1262964db96d65934196db621685 ]
      
      Commit 38030d7cb779 ("net/tls: avoid NULL-deref on resync during device removal")
      tried to fix a potential NULL-dereference by taking the
      context rwsem.  Unfortunately the RX resync may get called
      from soft IRQ, so we can't use the rwsem to protect from
      the device disappearing.  Because we are guaranteed there
      can be only one resync at a time (it's called from strparser)
      use a bit to indicate resync is busy and make device
      removal wait for the bit to get cleared.
      
      Note that there is a leftover "flags" field in struct
      tls_context already.
      
      Fixes: 4799ac81 ("tls: Add rx inline crypto offload")
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      be0343af
    • Xin Long's avatar
      ipv6: fix the check before getting the cookie in rt6_get_cookie · 9fd19a3b
      Xin Long authored
      [ Upstream commit b7999b07726c16974ba9ca3bb9fe98ecbec5f81c ]
      
      In Jianlin's testing, netperf was broken with 'Connection reset by peer',
      as the cookie check failed in rt6_check() and ip6_dst_check() always
      returned NULL.
      
      It's caused by Commit 93531c67 ("net/ipv6: separate handling of FIB
      entries from dst based routes"), where the cookie can be got only when
      'c1'(see below) for setting dst_cookie whereas rt6_check() is called
      when !'c1' for checking dst_cookie, as we can see in ip6_dst_check().
      
      Since in ip6_dst_check() both rt6_dst_from_check() (c1) and rt6_check()
      (!c1) will check the 'from' cookie, this patch is to remove the c1 check
      in rt6_get_cookie(), so that the dst_cookie can always be set properly.
      
      c1:
        (rt->rt6i_flags & RTF_PCPU || unlikely(!list_empty(&rt->rt6i_uncached)))
      
      Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes")
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9fd19a3b
  12. 09 Jun, 2019 2 commits
    • Frank Rowand's avatar
      of: overlay: validate overlay properties #address-cells and #size-cells · 15151d00
      Frank Rowand authored
      commit 6f75118800acf77f8ad6afec61ca1b2349ade371 upstream.
      
      If overlay properties #address-cells or #size-cells are already in
      the live devicetree for any given node, then the values in the
      overlay must match the values in the live tree.
      
      If the properties are already in the live tree then there is no
      need to create a changeset entry to add them since they must
      have the same value.  This reduces the memory used by the
      changeset and eliminates a possible memory leak.
      Tested-by: default avatarAlan Tull <atull@kernel.org>
      Signed-off-by: default avatarFrank Rowand <frank.rowand@sony.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      15151d00
    • Miguel Ojeda's avatar
      include/linux/module.h: copy __init/__exit attrs to init/cleanup_module · 9468870f
      Miguel Ojeda authored
      commit a6e60d84989fa0e91db7f236eda40453b0e44afa upstream.
      
      The upcoming GCC 9 release extends the -Wmissing-attributes warnings
      (enabled by -Wall) to C and aliases: it warns when particular function
      attributes are missing in the aliases but not in their target.
      
      In particular, it triggers for all the init/cleanup_module
      aliases in the kernel (defined by the module_init/exit macros),
      ending up being very noisy.
      
      These aliases point to the __init/__exit functions of a module,
      which are defined as __cold (among other attributes). However,
      the aliases themselves do not have the __cold attribute.
      
      Since the compiler behaves differently when compiling a __cold
      function as well as when compiling paths leading to calls
      to __cold functions, the warning is trying to point out
      the possibly-forgotten attribute in the alias.
      
      In order to keep the warning enabled, we decided to silence
      this case. Ideally, we would mark the aliases directly
      as __init/__exit. However, there are currently around 132 modules
      in the kernel which are missing __init/__exit in their init/cleanup
      functions (either because they are missing, or for other reasons,
      e.g. the functions being called from somewhere else); and
      a section mismatch is a hard error.
      
      A conservative alternative was to mark the aliases as __cold only.
      However, since we would like to eventually enforce __init/__exit
      to be always marked,  we chose to use the new __copy function
      attribute (introduced by GCC 9 as well to deal with this).
      With it, we copy the attributes used by the target functions
      into the aliases. This way, functions that were not marked
      as __init/__exit won't have their aliases marked either,
      and therefore there won't be a section mismatch.
      
      Note that the warning would go away marking either the extern
      declaration, the definition, or both. However, we only mark
      the definition of the alias, since we do not want callers
      (which only see the declaration) to be compiled as if the function
      was __cold (and therefore the paths leading to those calls
      would be assumed to be unlikely).
      
      Link: https://lore.kernel.org/lkml/20190123173707.GA16603@gmail.com/
      Link: https://lore.kernel.org/lkml/20190206175627.GA20399@gmail.com/Suggested-by: default avatarMartin Sebor <msebor@gcc.gnu.org>
      Acked-by: default avatarJessica Yu <jeyu@kernel.org>
      Signed-off-by: default avatarMiguel Ojeda <miguel.ojeda.sandonis@gmail.com>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9468870f