1. 24 Mar, 2015 4 commits
  2. 14 Mar, 2015 36 commits
    • Takashi Iwai's avatar
      ALSA: hda - Add pin configs for ASUS mobo with IDT 92HD73XX codec · c78962a5
      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 avatarSasha Levin <sasha.levin@oracle.com>
      c78962a5
    • Takashi Iwai's avatar
      ALSA: pcm: Don't leave PREPARED state after draining · 10556d5c
      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 avatarSasha Levin <sasha.levin@oracle.com>
      10556d5c
    • Sebastian Andrzej Siewior's avatar
      serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO" · d2d74ad4
      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 avatarSasha Levin <sasha.levin@oracle.com>
      d2d74ad4
    • Jiri Slaby's avatar
      tty: fix up atime/mtime mess, take four · 8ca9d129
      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 avatarSasha Levin <sasha.levin@oracle.com>
      8ca9d129
    • Vineet Gupta's avatar
      ARC: Fix KSTK_ESP() · b7dc640d
      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 avatarSasha Levin <sasha.levin@oracle.com>
      b7dc640d
    • Chuck Lever's avatar
      SUNRPC: Always manipulate rpc_rqst::rq_bc_pa_list under xprt->bc_pa_lock · 8ed378b1
      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 avatarSasha Levin <sasha.levin@oracle.com>
      8ed378b1
    • Al Viro's avatar
      sunrpc: fix braino in ->poll() · ca261c91
      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 avatarSasha Levin <sasha.levin@oracle.com>
      ca261c91
    • Al Viro's avatar
      procfs: fix race between symlink removals and traversals · 208fb83d
      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 avatarSasha Levin <sasha.levin@oracle.com>
      208fb83d
    • Al Viro's avatar
      debugfs: leave freeing a symlink body until inode eviction · c74eb981
      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 avatarSasha Levin <sasha.levin@oracle.com>
      c74eb981
    • Al Viro's avatar
      autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation · be9eb995
      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 avatarSasha Levin <sasha.levin@oracle.com>
      be9eb995
    • Johan Hovold's avatar
      USB: serial: fix tty-device error handling at probe · 318dc9ce
      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 avatarSasha Levin <sasha.levin@oracle.com>
      318dc9ce
    • Johan Hovold's avatar
      USB: serial: fix potential use-after-free after failed probe · acc69639
      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 avatarSasha Levin <sasha.levin@oracle.com>
      acc69639
    • Johan Hovold's avatar
      TTY: fix tty_wait_until_sent on 64-bit machines · 2e52da5f
      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 avatarSasha Levin <sasha.levin@oracle.com>
      2e52da5f
    • Johan Hovold's avatar
      USB: serial: fix infinite wait_until_sent timeout · ec02f95f
      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 avatarSasha Levin <sasha.levin@oracle.com>
      ec02f95f
    • Johan Hovold's avatar
      net: irda: fix wait_until_sent poll timeout · d6bc66d7
      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 avatarSasha Levin <sasha.levin@oracle.com>
      d6bc66d7
    • Jouni Malinen's avatar
      mac80211: Send EAPOL frames at lowest rate · 13c54411
      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 avatarSasha Levin <sasha.levin@oracle.com>
      13c54411
    • Mathias Nyman's avatar
      xhci: Workaround for PME stuck issues in Intel xhci · 1d2dcde8
      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 avatarSasha Levin <sasha.levin@oracle.com>
      1d2dcde8
    • Aleksander Morgado's avatar
      xhci: fix reporting of 0-sized URBs in control endpoint · 662a8fbc
      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 avatarSasha Levin <sasha.levin@oracle.com>
      662a8fbc
    • Mathias Nyman's avatar
      xhci: Allocate correct amount of scratchpad buffers · cc405315
      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 avatarSasha Levin <sasha.levin@oracle.com>
      cc405315
    • Maxime Ripard's avatar
      usb: XHCI: platform: Move the Marvell quirks after the enabling the clocks · 9e3e203f
      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 avatarSasha Levin <sasha.levin@oracle.com>
      9e3e203f
    • Andrzej Pietrasiewicz's avatar
      usb: gadget: configfs: don't NUL-terminate (sub)compatible ids · 8bea8b45
      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 avatarSasha Levin <sasha.levin@oracle.com>
      8bea8b45
    • George Cherian's avatar
      usb: dwc3: dwc3-omap: Fix disable IRQ · 09214016
      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 avatarSasha Levin <sasha.levin@oracle.com>
      09214016
    • Max Mansfield's avatar
      usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards · e377af70
      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 avatarSasha Levin <sasha.levin@oracle.com>
      e377af70
    • Mark Glover's avatar
      USB: ftdi_sio: add PIDs for Actisense USB devices · 7ab63060
      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 avatarSasha Levin <sasha.levin@oracle.com>
      7ab63060
    • Alan Stern's avatar
      USB: usbfs: don't leak kernel data in siginfo · 9705b410
      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 avatarSasha Levin <sasha.levin@oracle.com>
      9705b410
    • Johan Hovold's avatar
      USB: mxuport: fix null deref when used as a console · 40570334
      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 avatarSasha Levin <sasha.levin@oracle.com>
      40570334
    • Michiel vd Garde's avatar
      USB: serial: cp210x: Adding Seletek device id's · e7d3ac35
      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 avatarSasha Levin <sasha.levin@oracle.com>
      e7d3ac35
    • Johan Hovold's avatar
      Revert "USB: serial: make bulk_out_size a lower limit" · 64264c33
      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 avatarSasha Levin <sasha.levin@oracle.com>
      64264c33
    • Hans de Goede's avatar
      uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS539 · ddcc85e5
      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 avatarSasha Levin <sasha.levin@oracle.com>
      ddcc85e5
    • James Hogan's avatar
      KVM: MIPS: Fix trace event to save PC directly · a3ee1048
      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 avatarSasha Levin <sasha.levin@oracle.com>
      a3ee1048
    • Paolo Bonzini's avatar
      KVM: emulate: fix CMPXCHG8B on 32-bit hosts · c8b6504b
      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 avatarSasha Levin <sasha.levin@oracle.com>
      c8b6504b
    • Quentin Casasnovas's avatar
      Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref. · 218c8863
      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 avatarSasha Levin <sasha.levin@oracle.com>
      218c8863
    • Filipe Manana's avatar
      Btrfs: fix data loss in the fast fsync path · 0ab92529
      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 avatarSasha Levin <sasha.levin@oracle.com>
      0ab92529
    • David Sterba's avatar
      btrfs: fix lost return value due to variable shadowing · d771f1d4
      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 avatarSasha Levin <sasha.levin@oracle.com>
      d771f1d4
    • Filipe Manana's avatar
      Btrfs: fix fsync race leading to ordered extent memory leaks · 67b67dfa
      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 avatarSasha Levin <sasha.levin@oracle.com>
      67b67dfa
    • Alexander Usyskin's avatar
      mei: make device disabled on stop unconditionally · 85f1ab83
      Alexander Usyskin authored
      commit 6c15a851 upstream.
      
      Set the internal device state to to disabled after hardware reset in stop flow.
      This will cover cases when driver was not brought to disabled state because of
      an error and in stop flow we wish not to retry the reset.
      Signed-off-by: default avatarAlexander Usyskin <alexander.usyskin@intel.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      85f1ab83