1. 18 Mar, 2015 40 commits
    • Takashi Sakamoto's avatar
      ALSA: fireworks/bebob/dice/oxfw: allow stream destructor after releasing runtime · 7e6dddf2
      Takashi Sakamoto authored
      commit d23c2cc4 upstream.
      
      Currently stream destructor in each driver has a problem to be called in
      a context in which sound card object is released, because the destructors
      call amdtp_stream_pcm_abort() and touch PCM runtime data.
      
      The PCM runtime data is destroyed in application's context with
      snd_pcm_close(), on the other hand PCM substream data is destroyed after
      sound card object is released, in most case after all of ALSA character
      devices are released. When PCM runtime is destroyed and PCM substream is
      remained, amdtp_stream_pcm_abort() touches PCM runtime data and causes
      Null-pointer-dereference.
      
      This commit changes stream destructors and allows each driver to call
      it after releasing runtime.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e6dddf2
    • Takashi Sakamoto's avatar
      ALSA: firewire-lib: remove reference counting · c1972576
      Takashi Sakamoto authored
      commit c6f224dc upstream.
      
      AMDTP helper functions increment/decrement reference counter for an
      instance of FireWire unit, while it's complicated for each driver to
      process error state.
      
      In previous commit, each driver has the role of reference counting. This
      commit removes this role from the helper function.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1972576
    • Takashi Sakamoto's avatar
      ALSA: fireworks/bebob/dice/oxfw: add reference-counting for FireWire unit · 2a5d626d
      Takashi Sakamoto authored
      commit 12ed7192 upstream.
      
      Fireworks and Dice drivers try to touch instances of FireWire unit after
      sound card object is released, while references to the unit is decremented
      in .remove(). When unplugging during streaming, sound card object is
      released after .remove(), thus Fireworks and Dice drivers causes GPF or
      Null-pointer-dereferencing to application processes because an instance of
      FireWire unit was already released.
      
      This commit adds reference-counting for FireWire unit in drivers to allow
      them to touch an instance of FireWire unit after .remove(). In most case,
      any operations after .remove() may be failed safely.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a5d626d
    • Takashi Iwai's avatar
      ALSA: hda - Add pin configs for ASUS mobo with IDT 92HD73XX codec · e820f2b2
      Takashi Iwai authored
      commit 6426460e upstream.
      
      BIOS doesn't seem to set up pins for 5.1 and the SPDIF out, so we need
      to give explicitly here.
      Reported-and-tested-by: default avatarMisan Thropos <misanthropos@gmx.de>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e820f2b2
    • Takashi Iwai's avatar
      ALSA: pcm: Don't leave PREPARED state after draining · 39bba749
      Takashi Iwai authored
      commit 70372a75 upstream.
      
      When a PCM draining is performed to an empty stream that has been
      already in PREPARED state, the current code just ignores and leaves as
      it is, although the drain is supposed to set all such streams to SETUP
      state.  This patch covers that overlooked case.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39bba749
    • Sebastian Andrzej Siewior's avatar
      serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO" · fb1ca99e
      Sebastian Andrzej Siewior authored
      commit ca8bb4ae upstream.
      
      This reverts commit 0aa525d1.
      
      The conditional RX-FIFO read seems to cause spurious interrupts and we
      see just:
      |serial8250: too much work for irq29
      
      The previous behaviour was "default" for decades and Marvell's 88f6282 SoC
      might not be the only that relies on it. Therefore the Omap fix is
      reverted for now.
      
      Fixes: 0aa525d1 ("tty: serial: 8250_core: read only RX if there is
      something in the FIFO")
      Reported-By: default avatarNicolas Schichan <nschichan@freebox.fr>
      Debuged-By: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fb1ca99e
    • Jiri Slaby's avatar
      tty: fix up atime/mtime mess, take four · c6656cf2
      Jiri Slaby authored
      commit f0bf0bd0 upstream.
      
      This problem was taken care of three times already in
      * b0de59b5 (TTY: do not update
        atime/mtime on read/write),
      * 37b7f3c7 (TTY: fix atime/mtime
        regression), and
      * b0b88565 (tty: fix up atime/mtime
        mess, take three)
      
      But it still misses one point. As John Paul correctly points out, we
      do not care about setting date. If somebody ever changes wall
      time backwards (by mistake for example), tty timestamps are never
      updated until the original wall time passes.
      
      So check the absolute difference of times and if it large than "8
      seconds or so", always update the time. That means we will update
      immediatelly when changing time. Ergo, CAP_SYS_TIME can foul the
      check, but it was always that way.
      
      Thanks John for serving me this so nicely debugged.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Reported-by: default avatarJohn Paul Perry <john_paul.perry@alcatel-lucent.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6656cf2
    • Vineet Gupta's avatar
      ARC: Fix KSTK_ESP() · 14e96578
      Vineet Gupta authored
      commit 13648b01 upstream.
      
      /proc/<pid>/maps currently don't annotate stack vma with "[stack]"
      This is because KSTK_ESP ie expected to return usermode SP of tsk while
      currently it returns the kernel mode SP of a sleeping tsk.
      
      While the fix is trivial, we also need to adjust the ARC kernel stack
      unwinder to not use KSTK_SP and friends any more.
      Reported-and-suggested-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14e96578
    • Chuck Lever's avatar
      SUNRPC: Always manipulate rpc_rqst::rq_bc_pa_list under xprt->bc_pa_lock · 7fed3a79
      Chuck Lever authored
      commit 813b00d6 upstream.
      
      Other code that accesses rq_bc_pa_list holds xprt->bc_pa_lock.
      xprt_complete_bc_request() should do the same.
      
      Fixes: 2ea24497 ("SUNRPC: RPC callbacks may be split . . .")
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fed3a79
    • Al Viro's avatar
      sunrpc: fix braino in ->poll() · 202935e6
      Al Viro authored
      commit 1711fd9a upstream.
      
      POLL_OUT isn't what callers of ->poll() are expecting to see; it's
      actually __SI_POLL | 2 and it's a siginfo code, not a poll bitmap
      bit...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Cc: Bruce Fields <bfields@fieldses.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      202935e6
    • Al Viro's avatar
      procfs: fix race between symlink removals and traversals · e95e69b8
      Al Viro authored
      commit 7e0e953b upstream.
      
      use_pde()/unuse_pde() in ->follow_link()/->put_link() resp.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e95e69b8
    • Al Viro's avatar
      debugfs: leave freeing a symlink body until inode eviction · ea149d39
      Al Viro authored
      commit 0db59e59 upstream.
      
      As it is, we have debugfs_remove() racing with symlink traversals.
      Supply ->evict_inode() and do freeing there - inode will remain
      pinned until we are done with the symlink body.
      
      And rip the idiocy with checking if dentry is positive right after
      we'd verified debugfs_positive(), which is a stronger check...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ea149d39
    • Rasmus Villemoes's avatar
      autofs4: Wrong format for printing dentry · 17a75de1
      Rasmus Villemoes authored
      commit 76bf3f6b upstream.
      
      %pD for struct file*, %pd for struct dentry*.
      
      Fixes: a455589f ("assorted conversions to %p[dD]")
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17a75de1
    • Al Viro's avatar
      autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation · a2f96bd0
      Al Viro authored
      commit 0a280962 upstream.
      
      X-Coverup: just ask spender
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2f96bd0
    • Johan Hovold's avatar
      USB: serial: fix tty-device error handling at probe · a2cfb7dc
      Johan Hovold authored
      commit ca4383a3 upstream.
      
      Add missing error handling when registering the tty device at port
      probe. This avoids trying to remove an uninitialised character device
      when the port device is removed.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a2cfb7dc
    • Johan Hovold's avatar
      USB: serial: fix potential use-after-free after failed probe · 0db70c6d
      Johan Hovold authored
      commit 07fdfc5e upstream.
      
      Fix return value in probe error path, which could end up returning
      success (0) on errors. This could in turn lead to use-after-free or
      double free (e.g. in port_remove) when the port device is removed.
      
      Fixes: c706ebdf ("USB: usb-serial: call port_probe and port_remove
      at the right times")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0db70c6d
    • Johan Hovold's avatar
      TTY: fix tty_wait_until_sent on 64-bit machines · c1fdf10b
      Johan Hovold authored
      commit 79fbf4a5 upstream.
      
      Fix overflow bug in tty_wait_until_sent on 64-bit machines, where an
      infinite timeout (0) would be passed to the underlying tty-driver's
      wait_until_sent-operation as a negative timeout (-1), causing it to
      return immediately.
      
      This manifests itself for example as tcdrain() returning immediately,
      drivers not honouring the drain flags when setting terminal attributes,
      or even dropped data on close as a requested infinite closing-wait
      timeout would be ignored.
      
      The first symptom  was reported by Asier LLANO who noted that tcdrain()
      returned prematurely when using the ftdi_sio usb-serial driver.
      
      Fix this by passing 0 rather than MAX_SCHEDULE_TIMEOUT (LONG_MAX) to the
      underlying tty driver.
      
      Note that the serial-core wait_until_sent-implementation is not affected
      by this bug due to a lucky chance (comparison to an unsigned maximum
      timeout), and neither is the cyclades one that had an explicit check for
      negative timeouts, but all other tty drivers appear to be affected.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Reported-by: default avatarZIV-Asier Llano Palacios <asier.llano@cgglobal.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Reviewed-by: default avatarPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1fdf10b
    • Johan Hovold's avatar
      USB: serial: fix infinite wait_until_sent timeout · 0385cedc
      Johan Hovold authored
      commit f528bf4f upstream.
      
      Make sure to handle an infinite timeout (0).
      
      Note that wait_until_sent is currently never called with a 0-timeout
      argument due to a bug in tty_wait_until_sent.
      
      Fixes: dcf01050 ("USB: serial: add generic wait_until_sent
      implementation")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0385cedc
    • Johan Hovold's avatar
      net: irda: fix wait_until_sent poll timeout · a0c9b824
      Johan Hovold authored
      commit 2c3fbe3c upstream.
      
      In case an infinite timeout (0) is requested, the irda wait_until_sent
      implementation would use a zero poll timeout rather than the default
      200ms.
      
      Note that wait_until_sent is currently never called with a 0-timeout
      argument due to a bug in tty_wait_until_sent.
      
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0c9b824
    • Luciano Coelho's avatar
      mac80211: notify channel switch at the end of ieee80211_chswitch_post_beacon() · 8239b52a
      Luciano Coelho authored
      commit 688b1ecf upstream.
      
      The call to cfg80211_ch_switch_notify() should be at the end of the
      ieee80211_chswitch_post_beacon() function, because it should only be
      sent if everything succeeded.
      
      Fixes: d04b5ac9 ("cfg80211/mac80211: allow any interface to send channel switch notifications")
      Signed-off-by: default avatarLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8239b52a
    • Jouni Malinen's avatar
      mac80211: Send EAPOL frames at lowest rate · 5a34f1cb
      Jouni Malinen authored
      commit 9c1c98a3 upstream.
      
      The current minstrel_ht rate control behavior is somewhat optimistic in
      trying to find optimum TX rate. While this is usually fine for normal
      Data frames, there are cases where a more conservative set of retry
      parameters would be beneficial to make the connection more robust.
      
      EAPOL frames are critical to the authentication and especially the
      EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
      important to get through to the AP. If that message is lost, the only
      recovery mechanism in many cases is to reassociate with the AP and start
      from scratch. This can often be avoided by trying to send the frame with
      more conservative rate and/or with more link layer retries.
      
      In most cases, minstrel_ht is currently using the initial EAPOL-Key
      frames for probing higher rates and this results in only five link layer
      transmission attempts (one at high(ish) MCS and four at MCS0). While
      this works with most APs, it looks like there are some deployed APs that
      may have issues with the EAPOL frames using HT MCS immediately after
      association. Similarly, there may be issues in cases where the signal
      strength or radio environment is not good enough to be able to get
      frames through even at couple of MCS 0 tries.
      
      The best approach for this would likely to be to reduce the TX rate for
      the last rate (3rd rate parameter in the set) to a low basic rate (say,
      6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
      requires some more effort. For now, we can start with a simple one-liner
      that forces the minimum rate to be used for EAPOL frames similarly how
      the TX rate is selected for the IEEE 802.11 Management frames. This does
      result in a small extra latency added to the cases where the AP would be
      able to receive the higher rate, but taken into account how small number
      of EAPOL frames are used, this is likely to be insignificant. A future
      optimization in the minstrel_ht design can also allow this patch to be
      reverted to get back to the more optimized initial TX rate.
      
      It should also be noted that many drivers that do not use minstrel as
      the rate control algorithm are already doing similar workarounds by
      forcing the lowest TX rate to be used for EAPOL frames.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Tested-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJouni Malinen <jouni@qca.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a34f1cb
    • Mathias Nyman's avatar
      xhci: Workaround for PME stuck issues in Intel xhci · f51b8a1b
      Mathias Nyman authored
      commit b8cb91e0 upstream.
      
      The xhci in Intel Sunrisepoint and Cherryview platforms need a driver
      workaround for a Stuck PME that might either block PME events in suspend,
      or create spurious PME events preventing runtime suspend.
      
      Workaround is to clear a internal PME flag, BIT(28) in a vendor specific
      PMCTRL register at offset 0x80a4, in both suspend resume callbacks
      
      Without this, xhci connected usb devices might never be able to wake up the
      system from suspend, or prevent device from going to suspend (xhci d3)
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f51b8a1b
    • Aleksander Morgado's avatar
      xhci: fix reporting of 0-sized URBs in control endpoint · 19584ca9
      Aleksander Morgado authored
      commit 45ba2154 upstream.
      
      When a control transfer has a short data stage, the xHCI controller generates
      two transfer events: a COMP_SHORT_TX event that specifies the untransferred
      amount, and a COMP_SUCCESS event. But when the data stage is not short, only the
      COMP_SUCCESS event occurs. Therefore, xhci-hcd must set urb->actual_length to
      urb->transfer_buffer_length while processing the COMP_SUCCESS event, unless
      urb->actual_length was set already by a previous COMP_SHORT_TX event.
      
      The driver checks this by seeing whether urb->actual_length == 0, but this alone
      is the wrong test, as it is entirely possible for a short transfer to have an
      urb->actual_length = 0.
      
      This patch changes the xhci driver to rely on a new td->urb_length_set flag,
      which is set to true when a COMP_SHORT_TX event is received and the URB length
      updated at that stage.
      
      This fixes a bug which affected the HSO plugin, which relies on URBs with
      urb->actual_length == 0 to halt re-submitting the RX URB in the control
      endpoint.
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      19584ca9
    • Mathias Nyman's avatar
      xhci: Allocate correct amount of scratchpad buffers · 7f88b032
      Mathias Nyman authored
      commit 6596a926 upstream.
      
      Include the high order bit fields for Max scratchpad buffers when
      calculating how many scratchpad buffers are needed.
      
      I'm suprised this hasn't caused more issues, we never allocated more than
      32 buffers even if xhci needed more. Either we got lucky and xhci never
      really used past that area, or then we got enough zeroed dma memory anyway.
      
      Should be backported as far back as possible
      Reported-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Tested-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7f88b032
    • Maxime Ripard's avatar
      usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks · 6ae02126
      Maxime Ripard authored
      commit 1e7e4fb6 upstream.
      
      The commit 97374792 ("usb: host: xhci-plat: add support for the Armada
      375/38x XHCI controllers") extended the xhci-plat driver to support the Armada
      375/38x SoCs, mostly by adding a quirk configuring the MBUS window.
      
      However, that quirk was run before the clock the controllers needs has been
      enabled. This usually worked because the clock was first enabled by the
      bootloader, and left as such until the driver is probe, where it tries to
      access the MBUS configuration registers before enabling the clock.
      
      Things get messy when EPROBE_DEFER is involved during the probe, since as part
      of its error path, the driver will rightfully disable the clock. When the
      driver will be reprobed, it will retry to access the MBUS registers, but this
      time with the clock disabled, which hangs forever.
      
      Fix this by running the quirks after the clock has been enabled by the driver.
      Signed-off-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6ae02126
    • Andrzej Pietrasiewicz's avatar
      usb: gadget: configfs: don't NUL-terminate (sub)compatible ids · f735fd33
      Andrzej Pietrasiewicz authored
      commit a0456399 upstream.
      
      The "Extended Compat ID OS Feature Descriptor Specification" does not
      require the (sub)compatible ids to be NUL-terminated, because they
      are placed in a fixed-size buffer and only unused parts of it should
      contain NULs. If the buffer is fully utilized, there is no place for NULs.
      
      Consequently, the code which uses desc->ext_compat_id never expects the
      data contained to be NUL terminated.
      
      If the compatible id is stored after sub-compatible id, and the compatible
      id is full length (8 bytes), the (useless) NUL terminator overwrites the
      first byte of the sub-compatible id.
      
      If the sub-compatible id is full length (8 bytes), the (useless) NUL
      terminator ends up out of the buffer. The situation can happen in the RNDIS
      function, where the buffer is a part of struct f_rndis_opts. The next
      member of struct f_rndis_opts is a mutex, so its first byte gets
      overwritten. The said byte is a part of a mutex'es member which contains
      the information on whether the muext is locked or not. This can lead to a
      deadlock, because, in a configfs-composed gadget when a function is linked
      into a configuration with config_usb_cfg_link(), usb_get_function()
      is called, which then calls rndis_alloc(), which tries locking the same
      mutex and (wrongly) finds it already locked.
      
      This patch eliminates NUL terminating of the (sub)compatible id.
      
      Fixes: da424314: "usb: gadget: configfs: OS Extended Compatibility descriptors support"
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@samsung.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f735fd33
    • George Cherian's avatar
      usb: dwc3: dwc3-omap: Fix disable IRQ · 1ebbda9f
      George Cherian authored
      commit 96e5d312 upstream.
      
      In the wrapper the IRQ disable should be done by writing 1's to the
      IRQ*_CLR register. Existing code is broken because it instead writes
      zeros to IRQ*_SET register.
      
      Fix this by adding functions dwc3_omap_write_irqmisc_clr() and
      dwc3_omap_write_irq0_clr() which do the right thing.
      
      Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
      Signed-off-by: default avatarGeorge Cherian <george.cherian@ti.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ebbda9f
    • Max Mansfield's avatar
      usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards · d3ecce09
      Max Mansfield authored
      commit c7d373c3 upstream.
      
      This patch integrates Cyber Cortex AV boards with the existing
      ftdi_jtag_quirk in order to use serial port 0 with JTAG which is
      required by the manufacturers' software.
      
      Steps: 2
      
      [ftdi_sio_ids.h]
      1. Defined the device PID
      
      [ftdi_sio.c]
      2. Added a macro declaration to the ids array, in order to enable the
      jtag quirk for the device.
      Signed-off-by: default avatarMax Mansfield <max.m.mansfield@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3ecce09
    • Mark Glover's avatar
      USB: ftdi_sio: add PIDs for Actisense USB devices · d8a475bd
      Mark Glover authored
      commit f6950344 upstream.
      
      These product identifiers (PID) all deal with marine NMEA format data
      used on motor boats and yachts. We supply the programmed devices to
      Chetco, for use inside their equipment. The PIDs are a direct copy of
      our Windows device drivers (FTDI drivers with altered PIDs).
      Signed-off-by: default avatarMark Glover <mark@actisense.com>
      [johan: edit commit message slightly ]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8a475bd
    • Alan Stern's avatar
      USB: usbfs: don't leak kernel data in siginfo · af774ee8
      Alan Stern authored
      commit f0c2b681 upstream.
      
      When a signal is delivered, the information in the siginfo structure
      is copied to userspace.  Good security practice dicatates that the
      unused fields in this structure should be initialized to 0 so that
      random kernel stack data isn't exposed to the user.  This patch adds
      such an initialization to the two places where usbfs raises signals.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Reported-by: default avatarDave Mielke <dave@mielke.cc>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af774ee8
    • Johan Hovold's avatar
      USB: mxuport: fix null deref when used as a console · 4e1f2e34
      Johan Hovold authored
      commit db81de76 upstream.
      
      Fix null-pointer dereference at probe when the device is used as a
      console, in which case the tty argument to open will be NULL.
      
      Fixes: ee467a1f ("USB: serial: add Moxa UPORT 12XX/14XX/16XX
      driver")
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Acked-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e1f2e34
    • Michiel vd Garde's avatar
      USB: serial: cp210x: Adding Seletek device id's · 63834eef
      Michiel vd Garde authored
      commit 675af708 upstream.
      
      These device ID's are not associated with the cp210x module currently,
      but should be. This patch allows the devices to operate upon connecting
      them to the usb bus as intended.
      Signed-off-by: default avatarMichiel van de Garde <mgparser@gmail.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      63834eef
    • Johan Hovold's avatar
      Revert "USB: serial: make bulk_out_size a lower limit" · 8356c502
      Johan Hovold authored
      commit bc4b1f48 upstream.
      
      This reverts commit 5083fd7b.
      
      A bulk-out size smaller than the end-point size is indeed valid. The
      offending commit broke the usb-debug driver for EHCI debug devices,
      which use 8-byte buffers.
      
      Fixes: 5083fd7b ("USB: serial: make bulk_out_size a lower limit")
      Reported-by: default avatar"Li, Elvin" <elvin.li@intel.com>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8356c502
    • Hans de Goede's avatar
      uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539 · a5c2f30b
      Hans de Goede authored
      commit 59e980ef upstream.
      
      Like the JMicron JMS567 enclosures with the JMS539 choke on report-opcodes,
      so avoid it.
      Tested-and-reported-by: default avatarTom Arild Naess <tanaess@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5c2f30b
    • James Hogan's avatar
      KVM: MIPS: Fix trace event to save PC directly · 89fce062
      James Hogan authored
      commit b3cffac0 upstream.
      
      Currently the guest exit trace event saves the VCPU pointer to the
      structure, and the guest PC is retrieved by dereferencing it when the
      event is printed rather than directly from the trace record. This isn't
      safe as the printing may occur long afterwards, after the PC has changed
      and potentially after the VCPU has been freed. Usually this results in
      the same (wrong) PC being printed for multiple trace events. It also
      isn't portable as userland has no way to access the VCPU data structure
      when interpreting the trace record itself.
      
      Lets save the actual PC in the structure so that the correct value is
      accessible later.
      
      Fixes: 669e846e ("KVM/MIPS32: MIPS arch specific APIs for KVM")
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Marcelo Tosatti <mtosatti@redhat.com>
      Cc: Gleb Natapov <gleb@kernel.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarMarcelo Tosatti <mtosatti@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89fce062
    • Paolo Bonzini's avatar
      KVM: emulate: fix CMPXCHG8B on 32-bit hosts · d1feb252
      Paolo Bonzini authored
      commit 4ff6f8e6 upstream.
      
      This has been broken for a long time: it broke first in 2.6.35, then was
      almost fixed in 2.6.36 but this one-liner slipped through the cracks.
      The bug shows up as an infinite loop in Windows 7 (and newer) boot on
      32-bit hosts without EPT.
      
      Windows uses CMPXCHG8B to write to page tables, which causes a
      page fault if running without EPT; the emulator is then called from
      kvm_mmu_page_fault.  The loop then happens if the higher 4 bytes are
      not 0; the common case for this is that the NX bit (bit 63) is 1.
      
      Fixes: 6550e1f1
      Fixes: 16518d5aReported-by: default avatarErik Rull <erik.rull@rdsoftware.de>
      Tested-by: default avatarErik Rull <erik.rull@rdsoftware.de>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d1feb252
    • Quentin Casasnovas's avatar
      Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref. · b0539dd5
      Quentin Casasnovas authored
      commit dd9ef135 upstream.
      
      Improper arithmetics when calculting the address of the extended ref could
      lead to an out of bounds memory read and kernel panic.
      Signed-off-by: default avatarQuentin Casasnovas <quentin.casasnovas@oracle.com>
      Reviewed-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b0539dd5
    • Filipe Manana's avatar
      Btrfs: fix data loss in the fast fsync path · f4a7f91a
      Filipe Manana authored
      commit 3a8b36f3 upstream.
      
      When using the fast file fsync code path we can miss the fact that new
      writes happened since the last file fsync and therefore return without
      waiting for the IO to finish and write the new extents to the fsync log.
      
      Here's an example scenario where the fsync will miss the fact that new
      file data exists that wasn't yet durably persisted:
      
      1. fs_info->last_trans_committed == N - 1 and current transaction is
         transaction N (fs_info->generation == N);
      
      2. do a buffered write;
      
      3. fsync our inode, this clears our inode's full sync flag, starts
         an ordered extent and waits for it to complete - when it completes
         at btrfs_finish_ordered_io(), the inode's last_trans is set to the
         value N (via btrfs_update_inode_fallback -> btrfs_update_inode ->
         btrfs_set_inode_last_trans);
      
      4. transaction N is committed, so fs_info->last_trans_committed is now
         set to the value N and fs_info->generation remains with the value N;
      
      5. do another buffered write, when this happens btrfs_file_write_iter
         sets our inode's last_trans to the value N + 1 (that is
         fs_info->generation + 1 == N + 1);
      
      6. transaction N + 1 is started and fs_info->generation now has the
         value N + 1;
      
      7. transaction N + 1 is committed, so fs_info->last_trans_committed
         is set to the value N + 1;
      
      8. fsync our inode - because it doesn't have the full sync flag set,
         we only start the ordered extent, we don't wait for it to complete
         (only in a later phase) therefore its last_trans field has the
         value N + 1 set previously by btrfs_file_write_iter(), and so we
         have:
      
             inode->last_trans <= fs_info->last_trans_committed
                 (N + 1)              (N + 1)
      
         Which made us not log the last buffered write and exit the fsync
         handler immediately, returning success (0) to user space and resulting
         in data loss after a crash.
      
      This can actually be triggered deterministically and the following excerpt
      from a testcase I made for xfstests triggers the issue. It moves a dummy
      file across directories and then fsyncs the old parent directory - this
      is just to trigger a transaction commit, so moving files around isn't
      directly related to the issue but it was chosen because running 'sync' for
      example does more than just committing the current transaction, as it
      flushes/waits for all file data to be persisted. The issue can also happen
      at random periods, since the transaction kthread periodicaly commits the
      current transaction (about every 30 seconds by default).
      The body of the test is:
      
        _scratch_mkfs >> $seqres.full 2>&1
        _init_flakey
        _mount_flakey
      
        # Create our main test file 'foo', the one we check for data loss.
        # By doing an fsync against our file, it makes btrfs clear the 'needs_full_sync'
        # bit from its flags (btrfs inode specific flags).
        $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 8K" \
                        -c "fsync" $SCRATCH_MNT/foo | _filter_xfs_io
      
        # Now create one other file and 2 directories. We will move this second file
        # from one directory to the other later because it forces btrfs to commit its
        # currently open transaction if we fsync the old parent directory. This is
        # necessary to trigger the data loss bug that affected btrfs.
        mkdir $SCRATCH_MNT/testdir_1
        touch $SCRATCH_MNT/testdir_1/bar
        mkdir $SCRATCH_MNT/testdir_2
      
        # Make sure everything is durably persisted.
        sync
      
        # Write more 8Kb of data to our file.
        $XFS_IO_PROG -c "pwrite -S 0xbb 8K 8K" $SCRATCH_MNT/foo | _filter_xfs_io
      
        # Move our 'bar' file into a new directory.
        mv $SCRATCH_MNT/testdir_1/bar $SCRATCH_MNT/testdir_2/bar
      
        # Fsync our first directory. Because it had a file moved into some other
        # directory, this made btrfs commit the currently open transaction. This is
        # a condition necessary to trigger the data loss bug.
        $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir_1
      
        # Now fsync our main test file. If the fsync succeeds, we expect the 8Kb of
        # data we wrote previously to be persisted and available if a crash happens.
        # This did not happen with btrfs, because of the transaction commit that
        # happened when we fsynced the parent directory.
        $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
      
        # Simulate a crash/power loss.
        _load_flakey_table $FLAKEY_DROP_WRITES
        _unmount_flakey
      
        _load_flakey_table $FLAKEY_ALLOW_WRITES
        _mount_flakey
      
        # Now check that all data we wrote before are available.
        echo "File content after log replay:"
        od -t x1 $SCRATCH_MNT/foo
      
        status=0
        exit
      
      The expected golden output for the test, which is what we get with this
      fix applied (or when running against ext3/4 and xfs), is:
      
        wrote 8192/8192 bytes at offset 0
        XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
        wrote 8192/8192 bytes at offset 8192
        XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
        File content after log replay:
        0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
        *
        0020000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
        *
        0040000
      
      Without this fix applied, the output shows the test file does not have
      the second 8Kb extent that we successfully fsynced:
      
        wrote 8192/8192 bytes at offset 0
        XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
        wrote 8192/8192 bytes at offset 8192
        XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
        File content after log replay:
        0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
        *
        0020000
      
      So fix this by skipping the fsync only if we're doing a full sync and
      if the inode's last_trans is <= fs_info->last_trans_committed, or if
      the inode is already in the log. Also remove setting the inode's
      last_trans in btrfs_file_write_iter since it's useless/unreliable.
      
      Also because btrfs_file_write_iter no longer sets inode->last_trans to
      fs_info->generation + 1, don't set last_trans to 0 if we bail out and don't
      bail out if last_trans is 0, otherwise something as simple as the following
      example wouldn't log the second write on the last fsync:
      
        1. write to file
      
        2. fsync file
      
        3. fsync file
             |--> btrfs_inode_in_log() returns true and it set last_trans to 0
      
        4. write to file
             |--> btrfs_file_write_iter() no longers sets last_trans, so it
                  remained with a value of 0
        5. fsync
             |--> inode->last_trans == 0, so it bails out without logging the
                  second write
      
      A test case for xfstests will be sent soon.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f4a7f91a
    • David Sterba's avatar
      btrfs: fix lost return value due to variable shadowing · a0d0ff38
      David Sterba authored
      commit 1932b7be upstream.
      
      A block-local variable stores error code but btrfs_get_blocks_direct may
      not return it in the end as there's a ret defined in the function scope.
      
      Fixes: d187663e ("Btrfs: lock extents as we map them in DIO")
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0d0ff38
    • Filipe Manana's avatar
      Btrfs: fix fsync race leading to ordered extent memory leaks · f3ee1f70
      Filipe Manana authored
      commit 4d884fce upstream.
      
      We can have multiple fsync operations against the same file during the
      same transaction and they can collect the same ordered extents while they
      don't complete (still accessible from the inode's ordered tree). If this
      happens, those ordered extents will never get their reference counts
      decremented to 0, leading to memory leaks and inode leaks (an iput for an
      ordered extent's inode is scheduled only when the ordered extent's refcount
      drops to 0). The following sequence diagram explains this race:
      
               CPU 1                                         CPU 2
      
      btrfs_sync_file()
      
                                                       btrfs_sync_file()
      
        mutex_lock(inode->i_mutex)
        btrfs_log_inode()
          btrfs_get_logged_extents()
            --> collects ordered extent X
            --> increments ordered
                extent X's refcount
          btrfs_submit_logged_extents()
        mutex_unlock(inode->i_mutex)
      
                                                         mutex_lock(inode->i_mutex)
        btrfs_sync_log()
           btrfs_wait_logged_extents()
             --> list_del_init(&ordered->log_list)
                                                           btrfs_log_inode()
                                                             btrfs_get_logged_extents()
                                                               --> Adds ordered extent X
                                                                   to logged_list because
                                                                   at this point:
                                                                   list_empty(&ordered->log_list)
                                                                   && test_bit(BTRFS_ORDERED_LOGGED,
                                                                               &ordered->flags) == 0
                                                               --> Increments ordered extent
                                                                   X's refcount
             --> check if ordered extent's io is
                 finished or not, start it if
                 necessary and wait for it to finish
             --> sets bit BTRFS_ORDERED_LOGGED
                 on ordered extent X's flags
                 and adds it to trans->ordered
        btrfs_sync_log() finishes
      
                                                             btrfs_submit_logged_extents()
                                                           btrfs_log_inode() finishes
                                                         mutex_unlock(inode->i_mutex)
      
      btrfs_sync_file() finishes
      
                                                         btrfs_sync_log()
                                                            btrfs_wait_logged_extents()
                                                              --> Sees ordered extent X has the
                                                                  bit BTRFS_ORDERED_LOGGED set in
                                                                  its flags
                                                              --> X's refcount is untouched
                                                         btrfs_sync_log() finishes
      
                                                       btrfs_sync_file() finishes
      
      btrfs_commit_transaction()
        --> called by transaction kthread for e.g.
        btrfs_wait_pending_ordered()
          --> waits for ordered extent X to
              complete
          --> decrements ordered extent X's
              refcount by 1 only, corresponding
              to the increment done by the fsync
              task ran by CPU 1
      
      In the scenario of the above diagram, after the transaction commit,
      the ordered extent will remain with a refcount of 1 forever, leaking
      the ordered extent structure and preventing the i_count of its inode
      from ever decreasing to 0, since the delayed iput is scheduled only
      when the ordered extent's refcount drops to 0, preventing the inode
      from ever being evicted by the VFS.
      
      Fix this by using the flag BTRFS_ORDERED_LOGGED differently. Use it to
      mean that an ordered extent is already being processed by an fsync call,
      which will attach it to the current transaction, preventing it from being
      collected by subsequent fsync operations against the same inode.
      
      This race was introduced with the following change (added in 3.19 and
      backported to stable 3.18 and 3.17):
      
        Btrfs: make sure logged extents complete in the current transaction V3
        commit 50d9aa99
      
      I ran into this issue while running xfstests/generic/113 in a loop, which
      failed about 1 out of 10 runs with the following warning in dmesg:
      
      [ 2612.440038] WARNING: CPU: 4 PID: 22057 at fs/btrfs/disk-io.c:3558 free_fs_root+0x36/0x133 [btrfs]()
      [ 2612.442810] Modules linked in: btrfs crc32c_generic xor raid6_pq nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc loop processor parport_pc parport psmouse therma
      l_sys i2c_piix4 serio_raw pcspkr evdev microcode button i2c_core ext4 crc16 jbd2 mbcache sd_mod sg sr_mod cdrom virtio_scsi ata_generic virtio_pci ata_piix virtio_ring libata virtio flo
      ppy e1000 scsi_mod [last unloaded: btrfs]
      [ 2612.452711] CPU: 4 PID: 22057 Comm: umount Tainted: G        W      3.19.0-rc5-btrfs-next-4+ #1
      [ 2612.454921] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
      [ 2612.457709]  0000000000000009 ffff8801342c3c78 ffffffff8142425e ffff88023ec8f2d8
      [ 2612.459829]  0000000000000000 ffff8801342c3cb8 ffffffff81045308 ffff880046460000
      [ 2612.461564]  ffffffffa036da56 ffff88003d07b000 ffff880046460000 ffff880046460068
      [ 2612.463163] Call Trace:
      [ 2612.463719]  [<ffffffff8142425e>] dump_stack+0x4c/0x65
      [ 2612.464789]  [<ffffffff81045308>] warn_slowpath_common+0xa1/0xbb
      [ 2612.466026]  [<ffffffffa036da56>] ? free_fs_root+0x36/0x133 [btrfs]
      [ 2612.467247]  [<ffffffff810453c5>] warn_slowpath_null+0x1a/0x1c
      [ 2612.468416]  [<ffffffffa036da56>] free_fs_root+0x36/0x133 [btrfs]
      [ 2612.469625]  [<ffffffffa036f2a7>] btrfs_drop_and_free_fs_root+0x93/0x9b [btrfs]
      [ 2612.471251]  [<ffffffffa036f353>] btrfs_free_fs_roots+0xa4/0xd6 [btrfs]
      [ 2612.472536]  [<ffffffff8142612e>] ? wait_for_completion+0x24/0x26
      [ 2612.473742]  [<ffffffffa0370bbc>] close_ctree+0x1f3/0x33c [btrfs]
      [ 2612.475477]  [<ffffffff81059d1d>] ? destroy_workqueue+0x148/0x1ba
      [ 2612.476695]  [<ffffffffa034e3da>] btrfs_put_super+0x19/0x1b [btrfs]
      [ 2612.477911]  [<ffffffff81153e53>] generic_shutdown_super+0x73/0xef
      [ 2612.479106]  [<ffffffff811540e2>] kill_anon_super+0x13/0x1e
      [ 2612.480226]  [<ffffffffa034e1e3>] btrfs_kill_super+0x17/0x23 [btrfs]
      [ 2612.481471]  [<ffffffff81154307>] deactivate_locked_super+0x3b/0x50
      [ 2612.482686]  [<ffffffff811547a7>] deactivate_super+0x3f/0x43
      [ 2612.483791]  [<ffffffff8116b3ed>] cleanup_mnt+0x59/0x78
      [ 2612.484842]  [<ffffffff8116b44c>] __cleanup_mnt+0x12/0x14
      [ 2612.485900]  [<ffffffff8105d019>] task_work_run+0x8f/0xbc
      [ 2612.486960]  [<ffffffff810028d8>] do_notify_resume+0x5a/0x6b
      [ 2612.488083]  [<ffffffff81236e5b>] ? trace_hardirqs_on_thunk+0x3a/0x3f
      [ 2612.489333]  [<ffffffff8142a17f>] int_signal+0x12/0x17
      [ 2612.490353] ---[ end trace 54a960a6bdcb8d93 ]---
      [ 2612.557253] VFS: Busy inodes after unmount of sdb. Self-destruct in 5 seconds.  Have a nice day...
      
      Kmemleak confirmed the ordered extent leak (and btrfs inode specific
      structures such as delayed nodes):
      
      $ cat /sys/kernel/debug/kmemleak
      unreferenced object 0xffff880154290db0 (size 576):
        comm "btrfsck", pid 21980, jiffies 4295542503 (age 1273.412s)
        hex dump (first 32 bytes):
          01 40 00 00 01 00 00 00 b0 1d f1 4e 01 88 ff ff  .@.........N....
          00 00 00 00 00 00 00 00 c8 0d 29 54 01 88 ff ff  ..........)T....
        backtrace:
          [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a
          [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83
          [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190
          [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac
          [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs]
          [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs]
          [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs]
          [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs]
          [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs]
          [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed
          [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa
          [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b
          [<ffffffff81429e92>] system_call_fastpath+0x12/0x17
          [<ffffffffffffffff>] 0xffffffffffffffff
      unreferenced object 0xffff88014ef11db0 (size 576):
        comm "rm", pid 22009, jiffies 4295542593 (age 1273.052s)
        hex dump (first 32 bytes):
          02 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
          00 00 00 00 00 00 00 00 c8 1d f1 4e 01 88 ff ff  ...........N....
        backtrace:
          [<ffffffff8141d74d>] kmemleak_update_trace+0x4c/0x6a
          [<ffffffff8122f2c0>] radix_tree_node_alloc+0x6d/0x83
          [<ffffffff8122fb26>] __radix_tree_create+0x109/0x190
          [<ffffffff8122fbdd>] radix_tree_insert+0x30/0xac
          [<ffffffffa03b9bde>] btrfs_get_or_create_delayed_node+0x130/0x187 [btrfs]
          [<ffffffffa03bb82d>] btrfs_delayed_delete_inode_ref+0x32/0xac [btrfs]
          [<ffffffffa0379dae>] __btrfs_unlink_inode+0xee/0x288 [btrfs]
          [<ffffffffa037c715>] btrfs_unlink_inode+0x1e/0x40 [btrfs]
          [<ffffffffa037c797>] btrfs_unlink+0x60/0x9b [btrfs]
          [<ffffffff8115d7f0>] vfs_unlink+0x9c/0xed
          [<ffffffff8115f5de>] do_unlinkat+0x12c/0x1fa
          [<ffffffff811601a7>] SyS_unlinkat+0x29/0x2b
          [<ffffffff81429e92>] system_call_fastpath+0x12/0x17
          [<ffffffffffffffff>] 0xffffffffffffffff
      unreferenced object 0xffff8800336feda8 (size 584):
        comm "aio-stress", pid 22031, jiffies 4295543006 (age 1271.400s)
        hex dump (first 32 bytes):
          00 40 3e 00 00 00 00 00 00 00 8f 42 00 00 00 00  .@>........B....
          00 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
        backtrace:
          [<ffffffff8114eb34>] create_object+0x172/0x29a
          [<ffffffff8141d790>] kmemleak_alloc+0x25/0x41
          [<ffffffff81141ae6>] kmemleak_alloc_recursive.constprop.52+0x16/0x18
          [<ffffffff81145288>] kmem_cache_alloc+0xf7/0x198
          [<ffffffffa0389243>] __btrfs_add_ordered_extent+0x43/0x309 [btrfs]
          [<ffffffffa038968b>] btrfs_add_ordered_extent_dio+0x12/0x14 [btrfs]
          [<ffffffffa03810e2>] btrfs_get_blocks_direct+0x3ef/0x571 [btrfs]
          [<ffffffff81181349>] do_blockdev_direct_IO+0x62a/0xb47
          [<ffffffff8118189a>] __blockdev_direct_IO+0x34/0x36
          [<ffffffffa03776e5>] btrfs_direct_IO+0x16a/0x1e8 [btrfs]
          [<ffffffff81100373>] generic_file_direct_write+0xb8/0x12d
          [<ffffffffa038615c>] btrfs_file_write_iter+0x24b/0x42f [btrfs]
          [<ffffffff8118bb0d>] aio_run_iocb+0x2b7/0x32e
          [<ffffffff8118c99a>] do_io_submit+0x26e/0x2ff
          [<ffffffff8118ca3b>] SyS_io_submit+0x10/0x12
          [<ffffffff81429e92>] system_call_fastpath+0x12/0x17
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f3ee1f70