1. 12 Mar, 2015 40 commits
    • Takashi Iwai's avatar
      ALSA: hda - Add pin configs for ASUS mobo with IDT 92HD73XX codec · cbe3fbcd
      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 avatarJiri Slaby <jslaby@suse.cz>
      cbe3fbcd
    • Takashi Iwai's avatar
      ALSA: pcm: Don't leave PREPARED state after draining · f9b3a7f0
      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 avatarJiri Slaby <jslaby@suse.cz>
      f9b3a7f0
    • Ben Hutchings's avatar
      splice: Apply generic position and size checks to each write · d7e3ae47
      Ben Hutchings authored
      We need to check the position and size of file writes against various
      limits, using generic_write_check().  This was not being done for
      the splice write path.  It was fixed upstream by commit 8d020765
      ("->splice_write() via ->write_iter()") but we can't apply that.
      
      CVE-2014-7822
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      [ kamal: port to 3.13-stable: context ]
      Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      d7e3ae47
    • Linus Torvalds's avatar
      vm: make stack guard page errors return VM_FAULT_SIGSEGV rather than SIGBUS · 43bf73e1
      Linus Torvalds authored
      commit 9c145c56 upstream.
      
      The stack guard page error case has long incorrectly caused a SIGBUS
      rather than a SIGSEGV, but nobody actually noticed until commit
      fee7e49d ("mm: propagate error from stack expansion even for guard
      page") because that error case was never actually triggered in any
      normal situations.
      
      Now that we actually report the error, people noticed the wrong signal
      that resulted.  So far, only the test suite of libsigsegv seems to have
      actually cared, but there are real applications that use libsigsegv, so
      let's not wait for any of those to break.
      Reported-and-tested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Tested-by: default avatarJan Engelhardt <jengelh@inai.de>
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
      Cc: linux-arch@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      43bf73e1
    • Guenter Roeck's avatar
      arc: mm: Fix build failure · 07713861
      Guenter Roeck authored
      commit e262eb93 upstream.
      
      Fix misspelled define.
      
      Fixes: 33692f27 ("vm: add VM_FAULT_SIGSEGV handling support")
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      07713861
    • Linus Torvalds's avatar
      vm: add VM_FAULT_SIGSEGV handling support · 1868445f
      Linus Torvalds authored
      commit 33692f27 upstream.
      
      The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
      "you should SIGSEGV" error, because the SIGSEGV case was generally
      handled by the caller - usually the architecture fault handler.
      
      That results in lots of duplication - all the architecture fault
      handlers end up doing very similar "look up vma, check permissions, do
      retries etc" - but it generally works.  However, there are cases where
      the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.
      
      In particular, when accessing the stack guard page, libsigsegv expects a
      SIGSEGV.  And it usually got one, because the stack growth is handled by
      that duplicated architecture fault handler.
      
      However, when the generic VM layer started propagating the error return
      from the stack expansion in commit fee7e49d ("mm: propagate error
      from stack expansion even for guard page"), that now exposed the
      existing VM_FAULT_SIGBUS result to user space.  And user space really
      expected SIGSEGV, not SIGBUS.
      
      To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
      duplicate architecture fault handlers about it.  They all already have
      the code to handle SIGSEGV, so it's about just tying that new return
      value to the existing code, but it's all a bit annoying.
      
      This is the mindless minimal patch to do this.  A more extensive patch
      would be to try to gather up the mostly shared fault handling logic into
      one generic helper routine, and long-term we really should do that
      cleanup.
      
      Just from this patch, you can generally see that most architectures just
      copied (directly or indirectly) the old x86 way of doing things, but in
      the meantime that original x86 model has been improved to hold the VM
      semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
      "newer" things, so it would be a good idea to bring all those
      improvements to the generic case and teach other architectures about
      them too.
      Reported-and-tested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Tested-by: default avatarJan Engelhardt <jengelh@inai.de>
      Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> # "s390 still compiles and boots"
      Cc: linux-arch@vger.kernel.org
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      1868445f
    • Linus Torvalds's avatar
      x86: mm: move mmap_sem unlock from mm_fault_error() to caller · 7c5c89ac
      Linus Torvalds authored
      commit 7fb08eca upstream.
      
      This replaces four copies in various stages of mm_fault_error() handling
      with just a single one.  It will also allow for more natural placement
      of the unlocking after some further cleanup.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      7c5c89ac
    • Björn Gerhart's avatar
      cdc-acm: Add support for Denso cradle CU-321 · e3bc1153
      Björn Gerhart authored
      commit b20b1618 upstream.
      
      In order to support an older USB cradle by Denso, I added its vendor- and product-ID to the array of usb_device_id acm_ids. In this way cdc-acm feels responsible for this cradle. The related /dev/ttyACM node is being created properly, and the data transfer works.
      
      However, later cradle models by Denso do have proper descriptors, so the patch is not required for these. At the same time both the older and the later model have the same vendor- and product-ID, but they both work with the patched driver.
      
      Declaration of the Denso cradles I tested:
      - both models have the same IDs: vendorID 0x076d, productID 0x0006
      - older model: Denso CU-321 (descriptors not properly set)
      - later model: Denso CU-821 (with proper descriptors)
      Signed-off-by: default avatarBjoern Gerhart <oss@airbjorn.de>
      Acked-by: default avatarOliver Neukum <oneukum@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e3bc1153
    • Felipe Balbi's avatar
      usb: musb: core: add pm_runtime_irq_safe() · 95353e35
      Felipe Balbi authored
      commit 3e43a072 upstream.
      
      We need a pm_runtime_get_sync() call from
      within musb_gadget_pullup() to make sure
      registers are accessible at that time.
      
      The problem is that musb_gadget_pullup() is
      called with IRQs disabled and, because of that,
      we need to tell pm_runtime that this pm_runtime_get_sync()
      is IRQ safe.
      
      We can simply add pm_runtime_irq_safe(), however, because
      we need to make our read/write accessor function pointers
      have been initialized before trying to use them. This means
      that all pm_runtime initialization for musb_core needs to
      be moved down so that when we call pm_runtime_irq_safe(),
      the pm_runtime_get_sync() that it calls on the parent, won't
      cause a crash due to NULL musb_read/write accessors.
      Reported-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      95353e35
    • Felipe Balbi's avatar
      usb: gadget: function: phonet: balance usb_ep_disable calls · 2019319b
      Felipe Balbi authored
      commit 9ec36f7f upstream.
      
      f_phonet's ->set_alt() method will call usb_ep_disable()
      potentially on an endpoint which is already disabled. That's
      something the gadget/function driver must guarantee that it's
      always balanced.
      
      In order to balance the calls, just make sure the endpoint
      was enabled before by means of checking the validity of
      driver_data.
      Reported-by: default avatarPali Rohár <pali.rohar@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      2019319b
    • Anton Staaf's avatar
      USB: serial: add Google simple serial SubClass support · 476b1ec9
      Anton Staaf authored
      commit 679315e5 upstream.
      
      Add support for Google devices that export simple serial
      interfaces using the vendor specific SubClass/Protocol pair
      0x50/0x01.
      Signed-off-by: default avatarAnton Staaf <robotboy@chromium.org>
      Reviewed-by: default avatarBenson Leung <bleung@chromium.org>
      [johan: move id entries and update Kconfig]
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      476b1ec9
    • Alan Wu's avatar
      HID: microsoft: add support for Japanese Surface Type Cover 3 · 8a4eb1f9
      Alan Wu authored
      commit 5e7e9e90 upstream.
      
      Based on code for the US Surface Type Cover 3
      from commit be3b1634
      ("HID: add support for MS Surface Pro 3 Type Cover"):
      Signed-off-by: default avatarAlan Wu <alan.c.wu@gmail.com>
      Tested-by: default avatarKarlis Dreizis <karlisdreizis@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      8a4eb1f9
    • Alan Wu's avatar
      HID: add support for MS Surface Pro 3 Type Cover · 6e6b7a85
      Alan Wu authored
      commit be3b1634 upstream.
      
      Surface Pro 3 Type Cover that works with Ubuntu (and possibly Arch) from this thread. Both trackpad and keyboard work after compiling my own kernel.
      http://ubuntuforums.org/showthread.php?t=2231207&page=2&s=44910e0c56047e4f93dfd9fea58121ef
      
      Also includes Jarrad Whitaker's message which sources
      http://winaero.com/blog/how-to-install-linux-on-surface-pro-3/
      which he says is sourced from a Russian site
      Signed-off-by: default avatarAlan Wu <alan.c.wu@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6e6b7a85
    • Hans de Goede's avatar
      HID: hid-microsoft: Add support for scrollwheel and special keypad keys · 3d6797be
      Hans de Goede authored
      commit 3faed1af upstream.
      
      The Microsoft Office keyboard has a scrollwheel as well as some special keys
      above the keypad which are handled through the custom MS usage page, this
      commit adds support for these.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      3d6797be
    • Jim Keir's avatar
      HID: pidff: Fix initialisation forMicrosoft Sidewinder FF Pro 2 · c8b25999
      Jim Keir authored
      commit afd700d9 upstream.
      
      The FF2 driver (usbhid/hid-pidff.c) sends commands to the stick during ff_init.
      However, this is called inside a block where driver_input_lock is locked, so
      the results of these initial commands are discarded. This behavior is the
      "killer", without this nothing else works.
      
      ff_init issues commands using "hid_hw_request". This eventually goes to
      hid_input_report, which returns -EBUSY because driver_input_lock is locked. The
      change is to delay the ff_init call in hid-core.c until after this lock has
      been released.
      
      Calling hid_device_io_start() releases the lock so the device can be
      configured.  We also need to call hid_device_io_stop() on exit for the lock to
      remain locked while ending the init of the drivers.
      
      [ benjamin.tissoires@redhat.com: imrpoved the changelog a lot ]
      Signed-off-by: default avatarJim Keir <jimkeir@oracledbadirect.com>
      Reviewed-by: default avatarBenjamin.tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c8b25999
    • Ross Skaliotis's avatar
      HID: apple: fix battery support for the 2009 ANSI wireless keyboard · 0bea50e7
      Ross Skaliotis authored
      commit cbd366be upstream.
      
      Enabled quirks necessary for correct battery capacity reporting. Cleaned up
      surrounding style.
      Signed-off-by: default avatarRoss Skaliotis <rskaliotis@gmail.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      0bea50e7
    • Jiri Slaby's avatar
      tty: fix up atime/mtime mess, take four · c4772e57
      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 avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      c4772e57
    • Vineet Gupta's avatar
      ARC: Fix KSTK_ESP() · 47746745
      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 avatarJiri Slaby <jslaby@suse.cz>
      47746745
    • Al Viro's avatar
      sunrpc: fix braino in ->poll() · eeb8704a
      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 avatarJiri Slaby <jslaby@suse.cz>
      eeb8704a
    • Al Viro's avatar
      procfs: fix race between symlink removals and traversals · 147e702a
      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 avatarJiri Slaby <jslaby@suse.cz>
      147e702a
    • Al Viro's avatar
      debugfs: leave freeing a symlink body until inode eviction · f2331a68
      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 avatarJiri Slaby <jslaby@suse.cz>
      f2331a68
    • Al Viro's avatar
      autofs4 copy_dev_ioctl(): keep the value of ->size we'd used for allocation · fde71321
      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 avatarJiri Slaby <jslaby@suse.cz>
      fde71321
    • Johan Hovold's avatar
      USB: serial: fix tty-device error handling at probe · c3765073
      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 avatarJiri Slaby <jslaby@suse.cz>
      c3765073
    • Johan Hovold's avatar
      USB: serial: fix potential use-after-free after failed probe · 63953db3
      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 avatarJiri Slaby <jslaby@suse.cz>
      63953db3
    • Johan Hovold's avatar
      TTY: fix tty_wait_until_sent on 64-bit machines · 9bfa61c9
      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 avatarJiri Slaby <jslaby@suse.cz>
      9bfa61c9
    • Johan Hovold's avatar
      USB: serial: fix infinite wait_until_sent timeout · 6fc812b4
      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 avatarJiri Slaby <jslaby@suse.cz>
      6fc812b4
    • Johan Hovold's avatar
      net: irda: fix wait_until_sent poll timeout · a1f87712
      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 avatarJiri Slaby <jslaby@suse.cz>
      a1f87712
    • Jouni Malinen's avatar
      mac80211: Send EAPOL frames at lowest rate · af1fe3c6
      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 avatarJiri Slaby <jslaby@suse.cz>
      af1fe3c6
    • Aleksander Morgado's avatar
      xhci: fix reporting of 0-sized URBs in control endpoint · f2a7b61c
      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 avatarJiri Slaby <jslaby@suse.cz>
      f2a7b61c
    • Mathias Nyman's avatar
      xhci: Allocate correct amount of scratchpad buffers · bbadcecc
      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 avatarJiri Slaby <jslaby@suse.cz>
      bbadcecc
    • George Cherian's avatar
      usb: dwc3: dwc3-omap: Fix disable IRQ · 660c8a72
      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 avatarJiri Slaby <jslaby@suse.cz>
      660c8a72
    • Max Mansfield's avatar
      usb: ftdi_sio: Add jtag quirk support for Cyber Cortex AV boards · 349fbd79
      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 avatarJiri Slaby <jslaby@suse.cz>
      349fbd79
    • Mark Glover's avatar
      USB: ftdi_sio: add PIDs for Actisense USB devices · 2576c7db
      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 avatarJiri Slaby <jslaby@suse.cz>
      2576c7db
    • Alan Stern's avatar
      USB: usbfs: don't leak kernel data in siginfo · 17671b2f
      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 avatarJiri Slaby <jslaby@suse.cz>
      17671b2f
    • Michiel vd Garde's avatar
      USB: serial: cp210x: Adding Seletek device id's · a8e48840
      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 avatarJiri Slaby <jslaby@suse.cz>
      a8e48840
    • James Hogan's avatar
      KVM: MIPS: Fix trace event to save PC directly · f14b3c6a
      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 avatarJiri Slaby <jslaby@suse.cz>
      f14b3c6a
    • Paolo Bonzini's avatar
      KVM: emulate: fix CMPXCHG8B on 32-bit hosts · 6dd5cd79
      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 avatarJiri Slaby <jslaby@suse.cz>
      6dd5cd79
    • Quentin Casasnovas's avatar
      Btrfs:__add_inode_ref: out of bounds memory read when looking for extended ref. · 377121bb
      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 avatarJiri Slaby <jslaby@suse.cz>
      377121bb
    • Filipe Manana's avatar
      Btrfs: fix data loss in the fast fsync path · cf217634
      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 avatarJiri Slaby <jslaby@suse.cz>
      cf217634
    • David Sterba's avatar
      btrfs: fix lost return value due to variable shadowing · 3caad0ed
      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 avatarJiri Slaby <jslaby@suse.cz>
      3caad0ed