1. 08 May, 2016 6 commits
  2. 25 Apr, 2016 3 commits
  3. 20 Apr, 2016 31 commits
    • Eric Dumazet's avatar
      tcp_cubic: better follow cubic curve after idle period · 1d155a6c
      Eric Dumazet authored
      [ Upstream commit 30927520 ]
      
      Jana Iyengar found an interesting issue on CUBIC :
      
      The epoch is only updated/reset initially and when experiencing losses.
      The delta "t" of now - epoch_start can be arbitrary large after app idle
      as well as the bic_target. Consequentially the slope (inverse of
      ca->cnt) would be really large, and eventually ca->cnt would be
      lower-bounded in the end to 2 to have delayed-ACK slow-start behavior.
      
      This particularly shows up when slow_start_after_idle is disabled
      as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle
      time.
      
      Jana initial fix was to reset epoch_start if app limited,
      but Neal pointed out it would ask the CUBIC algorithm to recalculate the
      curve so that we again start growing steeply upward from where cwnd is
      now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth
      curve to be the same shape, just shifted later in time by the amount of
      the idle period.
      Reported-by: default avatarJana Iyengar <jri@google.com>
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
      Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Sangtae Ha <sangtae.ha@gmail.com>
      Cc: Lawrence Brakmo <lawrence@brakmo.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1d155a6c
    • Robert Dobrowolski's avatar
      usb: hcd: out of bounds access in for_each_companion · b016f99b
      Robert Dobrowolski authored
      [ Upstream commit e86103a7 ]
      
      On BXT platform Host Controller and Device Controller figure as
      same PCI device but with different device function. HCD should
      not pass data to Device Controller but only to Host Controllers.
      Checking if companion device is Host Controller, otherwise skip.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarRobert Dobrowolski <robert.dobrowolski@linux.intel.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b016f99b
    • Hans de Goede's avatar
      USB: uas: Add a new NO_REPORT_LUNS quirk · 17c094b0
      Hans de Goede authored
      [ Upstream commit 13630746 ]
      
      Add a new NO_REPORT_LUNS quirk and set it for Seagate drives with
      an usb-id of: 0bc2:331a, as these will fail to respond to a
      REPORT_LUNS command.
      
      Cc: stable@vger.kernel.org
      Reported-and-tested-by: default avatarDavid Webb <djw@noc.ac.uk>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      17c094b0
    • Mathias Nyman's avatar
      xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers · c5fcfe5f
      Mathias Nyman authored
      [ Upstream commit 98d74f9c ]
      
      PCI hotpluggable xhci controllers such as some Alpine Ridge solutions will
      remove the xhci controller from the PCI bus when the last USB device is
      disconnected.
      
      Add a flag to indicate that the host is being removed to avoid queueing
      configure_endpoint commands for the dropped endpoints.
      For PCI hotplugged controllers this will prevent 5 second command timeouts
      For static xhci controllers the configure_endpoint command is not needed
      in the removal case as everything will be returned, freed, and the
      controller is reset.
      
      For now the flag is only set for PCI connected host controllers.
      
      Cc: <stable@vger.kernel.org>
      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>
      c5fcfe5f
    • Roger Quadros's avatar
      usb: xhci: fix xhci locking up during hcd remove · 5d0b7d47
      Roger Quadros authored
      [ Upstream commit ad6b1d91 ]
      
      The problem seems to be that if a new device is detected
      while we have already removed the shared HCD, then many of the
      xhci operations (e.g.  xhci_alloc_dev(), xhci_setup_device())
      hang as command never completes.
      
      I don't think XHCI can operate without the shared HCD as we've
      already called xhci_halt() in xhci_only_stop_hcd() when shared HCD
      goes away. We need to prevent new commands from being queued
      not only when HCD is dying but also when HCD is halted.
      
      The following lockup was detected while testing the otg state
      machine.
      
      [  178.199951] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
      [  178.205799] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
      [  178.214458] xhci-hcd xhci-hcd.0.auto: hcc params 0x0220f04c hci version 0x100 quirks 0x00010010
      [  178.223619] xhci-hcd xhci-hcd.0.auto: irq 400, io mem 0x48890000
      [  178.230677] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
      [  178.237796] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
      [  178.245358] usb usb1: Product: xHCI Host Controller
      [  178.250483] usb usb1: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
      [  178.257783] usb usb1: SerialNumber: xhci-hcd.0.auto
      [  178.267014] hub 1-0:1.0: USB hub found
      [  178.272108] hub 1-0:1.0: 1 port detected
      [  178.278371] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
      [  178.284171] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
      [  178.294038] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
      [  178.301183] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
      [  178.308776] usb usb2: Product: xHCI Host Controller
      [  178.313902] usb usb2: Manufacturer: Linux 4.0.0-rc1-00024-g6111320 xhci-hcd
      [  178.321222] usb usb2: SerialNumber: xhci-hcd.0.auto
      [  178.329061] hub 2-0:1.0: USB hub found
      [  178.333126] hub 2-0:1.0: 1 port detected
      [  178.567585] dwc3 48890000.usb: usb_otg_start_host 0
      [  178.572707] xhci-hcd xhci-hcd.0.auto: remove, state 4
      [  178.578064] usb usb2: USB disconnect, device number 1
      [  178.586565] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered
      [  178.592585] xhci-hcd xhci-hcd.0.auto: remove, state 1
      [  178.597924] usb usb1: USB disconnect, device number 1
      [  178.603248] usb 1-1: new high-speed USB device number 2 using xhci-hcd
      [  190.597337] INFO: task kworker/u4:0:6 blocked for more than 10 seconds.
      [  190.604273]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
      [  190.610228] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  190.618443] kworker/u4:0    D c05c0ac0     0     6      2 0x00000000
      [  190.625120] Workqueue: usb_otg usb_otg_work
      [  190.629533] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
      [  190.636915] [<c05c10ac>] (schedule) from [<c05c1318>] (schedule_preempt_disabled+0xc/0x10)
      [  190.645591] [<c05c1318>] (schedule_preempt_disabled) from [<c05c23d0>] (mutex_lock_nested+0x1ac/0x3fc)
      [  190.655353] [<c05c23d0>] (mutex_lock_nested) from [<c046cf8c>] (usb_disconnect+0x3c/0x208)
      [  190.664043] [<c046cf8c>] (usb_disconnect) from [<c0470cf0>] (_usb_remove_hcd+0x98/0x1d8)
      [  190.672535] [<c0470cf0>] (_usb_remove_hcd) from [<c0485da8>] (usb_otg_start_host+0x50/0xf4)
      [  190.681299] [<c0485da8>] (usb_otg_start_host) from [<c04849a4>] (otg_set_protocol+0x5c/0xd0)
      [  190.690153] [<c04849a4>] (otg_set_protocol) from [<c0484b88>] (otg_set_state+0x170/0xbfc)
      [  190.698735] [<c0484b88>] (otg_set_state) from [<c0485740>] (otg_statemachine+0x12c/0x470)
      [  190.707326] [<c0485740>] (otg_statemachine) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
      [  190.716162] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
      [  190.724742] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
      [  190.732328] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
      [  190.739898] 5 locks held by kworker/u4:0/6:
      [  190.744274]  #0:  ("%s""usb_otg"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
      [  190.752799]  #1:  ((&otgd->work)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
      [  190.761326]  #2:  (&otgd->fsm.lock){+.+.+.}, at: [<c048562c>] otg_statemachine+0x18/0x470
      [  190.769934]  #3:  (usb_bus_list_lock){+.+.+.}, at: [<c0470ce8>] _usb_remove_hcd+0x90/0x1d8
      [  190.778635]  #4:  (&dev->mutex){......}, at: [<c046cf8c>] usb_disconnect+0x3c/0x208
      [  190.786700] INFO: task kworker/1:0:14 blocked for more than 10 seconds.
      [  190.793633]       Not tainted 4.0.0-rc1-00024-g6111320 #1058
      [  190.799567] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
      [  190.807783] kworker/1:0     D c05c0ac0     0    14      2 0x00000000
      [  190.814457] Workqueue: usb_hub_wq hub_event
      [  190.818866] [<c05c0ac0>] (__schedule) from [<c05c10ac>] (schedule+0x34/0x98)
      [  190.826252] [<c05c10ac>] (schedule) from [<c05c4e40>] (schedule_timeout+0x13c/0x1ec)
      [  190.834377] [<c05c4e40>] (schedule_timeout) from [<c05c19f0>] (wait_for_common+0xbc/0x150)
      [  190.843062] [<c05c19f0>] (wait_for_common) from [<bf068a3c>] (xhci_setup_device+0x164/0x5cc [xhci_hcd])
      [  190.852986] [<bf068a3c>] (xhci_setup_device [xhci_hcd]) from [<c046b7f4>] (hub_port_init+0x3f4/0xb10)
      [  190.862667] [<c046b7f4>] (hub_port_init) from [<c046eb64>] (hub_event+0x704/0x1018)
      [  190.870704] [<c046eb64>] (hub_event) from [<c0053c84>] (process_one_work+0x1b4/0x4a0)
      [  190.878919] [<c0053c84>] (process_one_work) from [<c00540f8>] (worker_thread+0x154/0x44c)
      [  190.887503] [<c00540f8>] (worker_thread) from [<c0058f88>] (kthread+0xd4/0xf0)
      [  190.895076] [<c0058f88>] (kthread) from [<c000e810>] (ret_from_fork+0x14/0x24)
      [  190.902650] 5 locks held by kworker/1:0/14:
      [  190.907023]  #0:  ("usb_hub_wq"){.+.+.+}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
      [  190.915454]  #1:  ((&hub->events)){+.+.+.}, at: [<c0053bf4>] process_one_work+0x124/0x4a0
      [  190.924070]  #2:  (&dev->mutex){......}, at: [<c046e490>] hub_event+0x30/0x1018
      [  190.931768]  #3:  (&port_dev->status_lock){+.+.+.}, at: [<c046eb50>] hub_event+0x6f0/0x1018
      [  190.940558]  #4:  (&bus->usb_address0_mutex){+.+.+.}, at: [<c046b458>] hub_port_init+0x58/0xb10
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.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>
      5d0b7d47
    • Lu Baolu's avatar
      usb: xhci: fix wild pointers in xhci_mem_cleanup · bd713f99
      Lu Baolu authored
      [ Upstream commit 71504062 ]
      
      This patch fixes some wild pointers produced by xhci_mem_cleanup.
      These wild pointers will cause system crash if xhci_mem_cleanup()
      is called twice.
      Reported-and-tested-by: default avatarPengcheng Li <lpc.li@hisilicon.com>
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Cc: stable@vger.kernel.org
      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>
      bd713f99
    • Yoshihiro Shimoda's avatar
      usb: host: xhci: add a new quirk XHCI_NO_64BIT_SUPPORT · 1edb54d1
      Yoshihiro Shimoda authored
      [ Upstream commit 0a380be8 ]
      
      On some xHCI controllers (e.g. R-Car SoCs), the AC64 bit (bit 0) of
      HCCPARAMS1 is set to 1. However, the xHCs don't support 64-bit
      address memory pointers actually. So, in this case, this driver should
      call dma_set_coherent_mask(dev, DMA_BIT_MASK(32)) in xhci_gen_setup().
      Otherwise, the xHCI controller will be died after a usb device is
      connected if it runs on above 4GB physical memory environment.
      
      So, this patch adds a new quirk XHCI_NO_64BIT_SUPPORT to resolve
      such an issue.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Reviewed-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.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>
      1edb54d1
    • Mathias Nyman's avatar
      xhci: resume USB 3 roothub first · 52b5bfb0
      Mathias Nyman authored
      [ Upstream commit 671ffdff ]
      
      Give USB3 devices a better chance to enumerate at USB 3 speeds if
      they are connected to a suspended host.
      Solves an issue with NEC uPD720200 host hanging when partially
      enumerating a USB3 device as USB2 after host controller runtime resume.
      
      Cc: <stable@vger.kernel.org>
      Tested-by: default avatarMike Murdoch <main.haarp@gmail.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>
      52b5bfb0
    • Rafal Redzimski's avatar
      usb: xhci: applying XHCI_PME_STUCK_QUIRK to Intel BXT B0 host · d49e9fc7
      Rafal Redzimski authored
      [ Upstream commit 0d46faca ]
      
      Broxton B0 also requires XHCI_PME_STUCK_QUIRK.
      Adding PCI device ID for Broxton B and adding to quirk.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarRafal Redzimski <rafal.f.redzimski@intel.com>
      Signed-off-by: default avatarRobert Dobrowolski <robert.dobrowolski@linux.intel.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>
      d49e9fc7
    • Rui Salvaterra's avatar
      lib: lz4: fixed zram with lz4 on big endian machines · da56dbea
      Rui Salvaterra authored
      [ Upstream commit 3e26a691 ]
      
      Based on Sergey's test patch [1], this fixes zram with lz4 compression
      on big endian cpus.
      
      Note that the 64-bit preprocessor test is not a cleanup, it's part of
      the fix, since those identifiers are bogus (for example, __ppc64__
      isn't defined anywhere else in the kernel, which means we'd fall into
      the 32-bit definitions on ppc64).
      
      Tested on ppc64 with no regression on x86_64.
      
      [1] http://marc.info/?l=linux-kernel&m=145994470805853&w=4
      
      Cc: stable@vger.kernel.org
      Suggested-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarRui Salvaterra <rsalvaterra@gmail.com>
      Reviewed-by: default avatarSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      da56dbea
    • Andy Shevchenko's avatar
      dmaengine: dw: fix master selection · bd58e66e
      Andy Shevchenko authored
      [ Upstream commit 3fe6409c ]
      
      The commit 89500520 ("dmaengine: dw: apply both HS interfaces and remove
      slave_id usage") cleaned up the code to avoid usage of depricated slave_id
      member of generic slave configuration.
      
      Meanwhile it broke the master selection by removing important call to
      dwc_set_masters() in ->device_alloc_chan_resources() which copied masters from
      custom slave configuration to the internal channel structure.
      
      Everything works until now since there is no customized connection of
      DesignWare DMA IP to the bus, i.e. one bus and one or more masters are in use.
      The configurations where 2 masters are connected to the different masters are
      not working anymore. We are expecting one user of such configuration and need
      to select masters properly. Besides that it is obviously a performance
      regression since only one master is in use in multi-master configuration.
      
      Select masters in accordance with what user asked for. Keep this patch in a form
      more suitable for back porting.
      
      We are safe to take necessary data in ->device_alloc_chan_resources() because
      we don't support generic slave configuration embedded into custom one, and thus
      the only way to provide such is to use the parameter to a filter function which
      is called exactly before channel resource allocation.
      
      While here, replase BUG_ON to less noisy dev_warn() and prevent channel
      allocation in case of error.
      
      Fixes: 89500520 ("dmaengine: dw: apply both HS interfaces and remove slave_id usage")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      bd58e66e
    • Seth Forshee's avatar
      debugfs: Make automount point inodes permanently empty · 6650ec2e
      Seth Forshee authored
      [ Upstream commit 87243deb ]
      
      Starting with 4.1 the tracing subsystem has its own filesystem
      which is automounted in the tracing subdirectory of debugfs.
      Prior to this debugfs could be bind mounted in a cloned mount
      namespace, but if tracefs has been mounted under debugfs this
      now fails because there is a locked child mount. This creates
      a regression for container software which bind mounts debugfs
      to satisfy the assumption of some userspace software.
      
      In other pseudo filesystems such as proc and sysfs we're already
      creating mountpoints like this in such a way that no dirents can
      be created in the directories, allowing them to be exceptions to
      some MNT_LOCKED tests. In fact we're already do this for the
      tracefs mountpoint in sysfs.
      
      Do the same in debugfs_create_automount(), since the intention
      here is clearly to create a mountpoint. This fixes the regression,
      as locked child mounts on permanently empty directories do not
      cause a bind mount to fail.
      
      Cc: stable@vger.kernel.org # v4.1+
      Signed-off-by: default avatarSeth Forshee <seth.forshee@canonical.com>
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      6650ec2e
    • Kailang Yang's avatar
      ALSA: usb-audio: Skip volume controls triggers hangup on Dell USB Dock · a789498e
      Kailang Yang authored
      [ Upstream commit adcdd0d5 ]
      
      This is Dell usb dock audio workaround.
      It was fixed the master volume keep lower.
      
      [Some background: the patch essentially skips the controls of a couple
       of FU volumes.  Although the firmware exposes the dB and the value
       information via the usb descriptor, changing the values (we set the
       min volume as default) screws up the device.  Although this has been
       fixed in the newer firmware, the devices are shipped with the old
       firmware, thus we need the workaround in the driver side.  -- tiwai]
      Signed-off-by: default avatarKailang Yang <kailang@realtek.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a789498e
    • Sven Eckelmann's avatar
      ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T460s · 330d83a5
      Sven Eckelmann authored
      [ Upstream commit c636b95e ]
      
      The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in
      order to get working sound output on the docking stations headphone jack.
      
      Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock
      on kernel 4.4.6.
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Tested-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      330d83a5
    • Hui Wang's avatar
      ALSA: hda - fix front mic problem for a HP desktop · b2eecded
      Hui Wang authored
      [ Upstream commit e549d190 ]
      
      The front mic jack (pink color) can't detect any plug or unplug. After
      applying this fix, both detecting function and recording function
      work well.
      
      BugLink: https://bugs.launchpad.net/bugs/1564712
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHui Wang <hui.wang@canonical.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b2eecded
    • David Matlack's avatar
      kvm: x86: do not leak guest xcr0 into host interrupt handlers · da3bd147
      David Matlack authored
      [ Upstream commit fc5b7f3b ]
      
      An interrupt handler that uses the fpu can kill a KVM VM, if it runs
      under the following conditions:
       - the guest's xcr0 register is loaded on the cpu
       - the guest's fpu context is not loaded
       - the host is using eagerfpu
      
      Note that the guest's xcr0 register and fpu context are not loaded as
      part of the atomic world switch into "guest mode". They are loaded by
      KVM while the cpu is still in "host mode".
      
      Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
      interrupt handler will look something like this:
      
      if (irq_fpu_usable()) {
              kernel_fpu_begin();
      
              [... code that uses the fpu ...]
      
              kernel_fpu_end();
      }
      
      As long as the guest's fpu is not loaded and the host is using eager
      fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
      returns true). The interrupt handler proceeds to use the fpu with
      the guest's xcr0 live.
      
      kernel_fpu_begin() saves the current fpu context. If this uses
      XSAVE[OPT], it may leave the xsave area in an undesirable state.
      According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
      if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
      xcr0[i] == 0 following an XSAVE.
      
      kernel_fpu_end() restores the fpu context. Now if any bit i in
      XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
      fault is trapped and SIGSEGV is delivered to the current process.
      
      Only pre-4.2 kernels appear to be vulnerable to this sequence of
      events. Commit 653f52c3 ("kvm,x86: load guest FPU context more eagerly")
      from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.
      
      This patch fixes the bug by keeping the host's xcr0 loaded outside
      of the interrupts-disabled region where KVM switches into guest mode.
      
      Cc: stable@vger.kernel.org
      Suggested-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Signed-off-by: default avatarDavid Matlack <dmatlack@google.com>
      [Move load after goto cancel_injection. - Paolo]
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      da3bd147
    • Helge Deller's avatar
      parisc: Unbreak handling exceptions from kernel modules · e213cce4
      Helge Deller authored
      [ Upstream commit 2ef4dfd9 ]
      
      Handling exceptions from modules never worked on parisc.
      It was just masked by the fact that exceptions from modules
      don't happen during normal use.
      
      When a module triggers an exception in get_user() we need to load the
      main kernel dp value before accessing the exception_data structure, and
      afterwards restore the original dp value of the module on exit.
      Noticed-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e213cce4
    • Helge Deller's avatar
      parisc: Fix kernel crash with reversed copy_from_user() · 9ccccafe
      Helge Deller authored
      [ Upstream commit ef72f311 ]
      
      The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
      crash on parisc if the parameters for copy_from_user were reversed
      ("illegal reversed copy_to_user" testcase).
      
      Fix this potential crash by checking the fault handler if the faulting
      address is in the exception table.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9ccccafe
    • Helge Deller's avatar
      parisc: Avoid function pointers for kernel exception routines · 073cac90
      Helge Deller authored
      [ Upstream commit e3893027 ]
      
      We want to avoid the kernel module loader to create function pointers
      for the kernel fixup routines of get_user() and put_user(). Changing
      the external reference from function type to int type fixes this.
      
      This unbreaks exception handling for get_user() and put_user() when
      called from a kernel module.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      073cac90
    • Yong Li's avatar
      gpio: pca953x: Use correct u16 value for register word write · 7227a0df
      Yong Li authored
      [ Upstream commit 9b8e3ec3 ]
      
      The current implementation only uses the first byte in val,
      the second byte is always 0. Change it to use cpu_to_le16
      to write the two bytes into the register
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarYong Li <sdliyong@gmail.com>
      Reviewed-by: default avatarPhil Reid <preid@electromag.com.au>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7227a0df
    • Michael S. Tsirkin's avatar
      virtio: virtio 1.0 cs04 spec compliance for reset · 0ffbec8d
      Michael S. Tsirkin authored
      [ Upstream commit 05dbcb43 ]
      
      The spec says: after writing 0 to device_status, the driver MUST wait
      for a read of device_status to return 0 before reinitializing the
      device.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0ffbec8d
    • Bjørn Mork's avatar
      USB: option: add "D-Link DWM-221 B1" device id · e649832a
      Bjørn Mork authored
      [ Upstream commit d48d5691 ]
      
      Thomas reports:
      "Windows:
      
      00 diagnostics
      01 modem
      02 at-port
      03 nmea
      04 nic
      
      Linux:
      
      T:  Bus=02 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
      D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
      P:  Vendor=2001 ProdID=7e19 Rev=02.32
      S:  Manufacturer=Mobile Connect
      S:  Product=Mobile Connect
      S:  SerialNumber=0123456789ABCDEF
      C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=500mA
      I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
      I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
      I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
      I:  If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
      Reported-by: default avatarThomas Schäfer <tschaefer@t-online.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e649832a
    • Martyn Welch's avatar
      USB: serial: cp210x: Adding GE Healthcare Device ID · ad660596
      Martyn Welch authored
      [ Upstream commit cddc9434 ]
      
      The CP2105 is used in the GE Healthcare Remote Alarm Box, with the
      Manufacturer ID of 0x1901 and Product ID of 0x0194.
      Signed-off-by: default avatarMartyn Welch <martyn.welch@collabora.co.uk>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ad660596
    • Josh Boyer's avatar
      USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices · 2e007c67
      Josh Boyer authored
      [ Upstream commit ea6db90e ]
      
      A Fedora user reports that the ftdi_sio driver works properly for the
      ICP DAS I-7561U device.  Further, the user manual for these devices
      instructs users to load the driver and add the ids using the sysfs
      interface.
      
      Add support for these in the driver directly so that the devices work
      out of the box instead of needing manual configuration.
      
      Reported-by: <thesource@mail.ru>
      CC: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      2e007c67
    • Filipe Manana's avatar
      Btrfs: fix file/data loss caused by fsync after rename and new inode · 033ad030
      Filipe Manana authored
      [ Upstream commit 56f23fdb ]
      
      If we rename an inode A (be it a file or a directory), create a new
      inode B with the old name of inode A and under the same parent directory,
      fsync inode B and then power fail, at log tree replay time we end up
      removing inode A completely. If inode A is a directory then all its files
      are gone too.
      
      Example scenarios where this happens:
      This is reproducible with the following steps, taken from a couple of
      test cases written for fstests which are going to be submitted upstream
      soon:
      
         # Scenario 1
      
         mkfs.btrfs -f /dev/sdc
         mount /dev/sdc /mnt
         mkdir -p /mnt/a/x
         echo "hello" > /mnt/a/x/foo
         echo "world" > /mnt/a/x/bar
         sync
         mv /mnt/a/x /mnt/a/y
         mkdir /mnt/a/x
         xfs_io -c fsync /mnt/a/x
         <power failure happens>
      
         The next time the fs is mounted, log tree replay happens and
         the directory "y" does not exist nor do the files "foo" and
         "bar" exist anywhere (neither in "y" nor in "x", nor the root
         nor anywhere).
      
         # Scenario 2
      
         mkfs.btrfs -f /dev/sdc
         mount /dev/sdc /mnt
         mkdir /mnt/a
         echo "hello" > /mnt/a/foo
         sync
         mv /mnt/a/foo /mnt/a/bar
         echo "world" > /mnt/a/foo
         xfs_io -c fsync /mnt/a/foo
         <power failure happens>
      
         The next time the fs is mounted, log tree replay happens and the
         file "bar" does not exists anymore. A file with the name "foo"
         exists and it matches the second file we created.
      
      Another related problem that does not involve file/data loss is when a
      new inode is created with the name of a deleted snapshot and we fsync it:
      
         mkfs.btrfs -f /dev/sdc
         mount /dev/sdc /mnt
         mkdir /mnt/testdir
         btrfs subvolume snapshot /mnt /mnt/testdir/snap
         btrfs subvolume delete /mnt/testdir/snap
         rmdir /mnt/testdir
         mkdir /mnt/testdir
         xfs_io -c fsync /mnt/testdir # or fsync some file inside /mnt/testdir
         <power failure>
      
         The next time the fs is mounted the log replay procedure fails because
         it attempts to delete the snapshot entry (which has dir item key type
         of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
         resulting in the following error that causes mount to fail:
      
         [52174.510532] BTRFS info (device dm-0): failed to delete reference to snap, inode 257 parent 257
         [52174.512570] ------------[ cut here ]------------
         [52174.513278] WARNING: CPU: 12 PID: 28024 at fs/btrfs/inode.c:3986 __btrfs_unlink_inode+0x178/0x351 [btrfs]()
         [52174.514681] BTRFS: Transaction aborted (error -2)
         [52174.515630] Modules linked in: btrfs dm_flakey dm_mod overlay crc32c_generic ppdev xor raid6_pq acpi_cpufreq parport_pc tpm_tis sg parport tpm evdev i2c_piix4 proc
         [52174.521568] CPU: 12 PID: 28024 Comm: mount Tainted: G        W       4.5.0-rc6-btrfs-next-27+ #1
         [52174.522805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
         [52174.524053]  0000000000000000 ffff8801df2a7710 ffffffff81264e93 ffff8801df2a7758
         [52174.524053]  0000000000000009 ffff8801df2a7748 ffffffff81051618 ffffffffa03591cd
         [52174.524053]  00000000fffffffe ffff88015e6e5000 ffff88016dbc3c88 ffff88016dbc3c88
         [52174.524053] Call Trace:
         [52174.524053]  [<ffffffff81264e93>] dump_stack+0x67/0x90
         [52174.524053]  [<ffffffff81051618>] warn_slowpath_common+0x99/0xb2
         [52174.524053]  [<ffffffffa03591cd>] ? __btrfs_unlink_inode+0x178/0x351 [btrfs]
         [52174.524053]  [<ffffffff81051679>] warn_slowpath_fmt+0x48/0x50
         [52174.524053]  [<ffffffffa03591cd>] __btrfs_unlink_inode+0x178/0x351 [btrfs]
         [52174.524053]  [<ffffffff8118f5e9>] ? iput+0xb0/0x284
         [52174.524053]  [<ffffffffa0359fe8>] btrfs_unlink_inode+0x1c/0x3d [btrfs]
         [52174.524053]  [<ffffffffa038631e>] check_item_in_log+0x1fe/0x29b [btrfs]
         [52174.524053]  [<ffffffffa0386522>] replay_dir_deletes+0x167/0x1cf [btrfs]
         [52174.524053]  [<ffffffffa038739e>] fixup_inode_link_count+0x289/0x2aa [btrfs]
         [52174.524053]  [<ffffffffa038748a>] fixup_inode_link_counts+0xcb/0x105 [btrfs]
         [52174.524053]  [<ffffffffa038a5ec>] btrfs_recover_log_trees+0x258/0x32c [btrfs]
         [52174.524053]  [<ffffffffa03885b2>] ? replay_one_extent+0x511/0x511 [btrfs]
         [52174.524053]  [<ffffffffa034f288>] open_ctree+0x1dd4/0x21b9 [btrfs]
         [52174.524053]  [<ffffffffa032b753>] btrfs_mount+0x97e/0xaed [btrfs]
         [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
         [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
         [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
         [52174.524053]  [<ffffffffa032af81>] btrfs_mount+0x1ac/0xaed [btrfs]
         [52174.524053]  [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
         [52174.524053]  [<ffffffff8108c262>] ? lockdep_init_map+0xb9/0x1b3
         [52174.524053]  [<ffffffff8117bafa>] mount_fs+0x67/0x131
         [52174.524053]  [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
         [52174.524053]  [<ffffffff8119590f>] do_mount+0x8a6/0x9e8
         [52174.524053]  [<ffffffff811358dd>] ? strndup_user+0x3f/0x59
         [52174.524053]  [<ffffffff81195c65>] SyS_mount+0x77/0x9f
         [52174.524053]  [<ffffffff814935d7>] entry_SYSCALL_64_fastpath+0x12/0x6b
         [52174.561288] ---[ end trace 6b53049efb1a3ea6 ]---
      
      Fix this by forcing a transaction commit when such cases happen.
      This means we check in the commit root of the subvolume tree if there
      was any other inode with the same reference when the inode we are
      fsync'ing is a new inode (created in the current transaction).
      
      Test cases for fstests, covering all the scenarios given above, were
      submitted upstream for fstests:
      
        * fstests: generic test for fsync after renaming directory
          https://patchwork.kernel.org/patch/8694281/
      
        * fstests: generic test for fsync after renaming file
          https://patchwork.kernel.org/patch/8694301/
      
        * fstests: add btrfs test for fsync after snapshot deletion
          https://patchwork.kernel.org/patch/8670671/
      
      Cc: stable@vger.kernel.org
      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>
      033ad030
    • Filipe Manana's avatar
      Btrfs: fix fsync after truncate when no_holes feature is enabled · 091537b5
      Filipe Manana authored
      [ Upstream commit a89ca6f2 ]
      
      When we have the no_holes feature enabled, if a we truncate a file to a
      smaller size, truncate it again but to a size greater than or equals to
      its original size and fsync it, the log tree will not have any information
      about the hole covering the range [truncate_1_offset, new_file_size[.
      Which means if the fsync log is replayed, the file will remain with the
      state it had before both truncate operations.
      
      Without the no_holes feature this does not happen, since when the inode
      is logged (full sync flag is set) it will find in the fs/subvol tree a
      leaf with a generation matching the current transaction id that has an
      explicit extent item representing the hole.
      
      Fix this by adding an explicit extent item representing a hole between
      the last extent and the inode's i_size if we are doing a full sync.
      
      The issue is easy to reproduce with the following test case for fstests:
      
        . ./common/rc
        . ./common/filter
        . ./common/dmflakey
      
        _need_to_be_root
        _supported_fs generic
        _supported_os Linux
        _require_scratch
        _require_dm_flakey
      
        # This test was motivated by an issue found in btrfs when the btrfs
        # no-holes feature is enabled (introduced in kernel 3.14). So enable
        # the feature if the fs being tested is btrfs.
        if [ $FSTYP == "btrfs" ]; then
            _require_btrfs_fs_feature "no_holes"
            _require_btrfs_mkfs_feature "no-holes"
            MKFS_OPTIONS="$MKFS_OPTIONS -O no-holes"
        fi
      
        rm -f $seqres.full
      
        _scratch_mkfs >>$seqres.full 2>&1
        _init_flakey
        _mount_flakey
      
        # Create our test files and make sure everything is durably persisted.
        $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 64K"         \
                        -c "pwrite -S 0xbb 64K 61K"       \
                        $SCRATCH_MNT/foo | _filter_xfs_io
        $XFS_IO_PROG -f -c "pwrite -S 0xee 0 64K"         \
                        -c "pwrite -S 0xff 64K 61K"       \
                        $SCRATCH_MNT/bar | _filter_xfs_io
        sync
      
        # Now truncate our file foo to a smaller size (64Kb) and then truncate
        # it to the size it had before the shrinking truncate (125Kb). Then
        # fsync our file. If a power failure happens after the fsync, we expect
        # our file to have a size of 125Kb, with the first 64Kb of data having
        # the value 0xaa and the second 61Kb of data having the value 0x00.
        $XFS_IO_PROG -c "truncate 64K" \
                     -c "truncate 125K" \
                     -c "fsync" \
                     $SCRATCH_MNT/foo
      
        # Do something similar to our file bar, but the first truncation sets
        # the file size to 0 and the second truncation expands the size to the
        # double of what it was initially.
        $XFS_IO_PROG -c "truncate 0" \
                     -c "truncate 253K" \
                     -c "fsync" \
                     $SCRATCH_MNT/bar
      
        _load_flakey_table $FLAKEY_DROP_WRITES
        _unmount_flakey
      
        # Allow writes again, mount to trigger log replay and validate file
        # contents.
        _load_flakey_table $FLAKEY_ALLOW_WRITES
        _mount_flakey
      
        # We expect foo to have a size of 125Kb, the first 64Kb of data all
        # having the value 0xaa and the remaining 61Kb to be a hole (all bytes
        # with value 0x00).
        echo "File foo content after log replay:"
        od -t x1 $SCRATCH_MNT/foo
      
        # We expect bar to have a size of 253Kb and no extents (any byte read
        # from bar has the value 0x00).
        echo "File bar content after log replay:"
        od -t x1 $SCRATCH_MNT/bar
      
        status=0
        exit
      
      The expected file contents in the golden output are:
      
        File foo content after log replay:
        0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
        *
        0200000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        *
        0372000
        File bar content after log replay:
        0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        *
        0772000
      
      Without this fix, their contents are:
      
        File foo content after log replay:
        0000000 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
        *
        0200000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
        *
        0372000
        File bar content after log replay:
        0000000 ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee ee
        *
        0200000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
        *
        0372000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        *
        0772000
      
      A test case submission for fstests follows soon.
      Signed-off-by: default avatarFilipe Manana <fdmanana@suse.com>
      Reviewed-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarChris Mason <clm@fb.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      091537b5
    • Filipe Manana's avatar
      Btrfs: fix fsync xattr loss in the fast fsync path · db4043df
      Filipe Manana authored
      [ Upstream commit 36283bf7 ]
      
      After commit 4f764e51 ("Btrfs: remove deleted xattrs on fsync log
      replay"), we can end up in a situation where during log replay we end up
      deleting xattrs that were never deleted when their file was last fsynced.
      
      This happens in the fast fsync path (flag BTRFS_INODE_NEEDS_FULL_SYNC is
      not set in the inode) if the inode has the flag BTRFS_INODE_COPY_EVERYTHING
      set, the xattr was added in a past transaction and the leaf where the
      xattr is located was not updated (COWed or created) in the current
      transaction. In this scenario the xattr item never ends up in the log
      tree and therefore at log replay time, which makes the replay code delete
      the xattr from the fs/subvol tree as it thinks that xattr was deleted
      prior to the last fsync.
      
      Fix this by always logging all xattrs, which is the simplest and most
      reliable way to detect deleted xattrs and replay the deletes at log replay
      time.
      
      This issue is reproducible with the following test case for fstests:
      
        seq=`basename $0`
        seqres=$RESULT_DIR/$seq
        echo "QA output created by $seq"
      
        here=`pwd`
        tmp=/tmp/$$
        status=1	# failure is the default!
      
        _cleanup()
        {
            _cleanup_flakey
            rm -f $tmp.*
        }
        trap "_cleanup; exit \$status" 0 1 2 3 15
      
        # get standard environment, filters and checks
        . ./common/rc
        . ./common/filter
        . ./common/dmflakey
        . ./common/attr
      
        # real QA test starts here
      
        # We create a lot of xattrs for a single file. Only btrfs and xfs are currently
        # able to store such a large mount of xattrs per file, other filesystems such
        # as ext3/4 and f2fs for example, fail with ENOSPC even if we attempt to add
        # less than 1000 xattrs with very small values.
        _supported_fs btrfs xfs
        _supported_os Linux
        _need_to_be_root
        _require_scratch
        _require_dm_flakey
        _require_attrs
        _require_metadata_journaling $SCRATCH_DEV
      
        rm -f $seqres.full
      
        _scratch_mkfs >> $seqres.full 2>&1
        _init_flakey
        _mount_flakey
      
        # Create the test file with some initial data and make sure everything is
        # durably persisted.
        $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 32k" $SCRATCH_MNT/foo | _filter_xfs_io
        sync
      
        # Add many small xattrs to our file.
        # We create such a large amount because it's needed to trigger the issue found
        # in btrfs - we need to have an amount that causes the fs to have at least 3
        # btree leafs with xattrs stored in them, and it must work on any leaf size
        # (maximum leaf/node size is 64Kb).
        num_xattrs=2000
        for ((i = 1; i <= $num_xattrs; i++)); do
            name="user.attr_$(printf "%04d" $i)"
            $SETFATTR_PROG -n $name -v "val_$(printf "%04d" $i)" $SCRATCH_MNT/foo
        done
      
        # Sync the filesystem to force a commit of the current btrfs transaction, this
        # is a necessary condition to trigger the bug on btrfs.
        sync
      
        # Now update our file's data and fsync the file.
        # After a successful fsync, if the fsync log/journal is replayed we expect to
        # see all the xattrs we added before with the same values (and the updated file
        # data of course). Btrfs used to delete some of these xattrs when it replayed
        # its fsync log/journal.
        $XFS_IO_PROG -c "pwrite -S 0xbb 8K 16K" \
                     -c "fsync" \
                     $SCRATCH_MNT/foo | _filter_xfs_io
      
        # Simulate a crash/power loss.
        _load_flakey_table $FLAKEY_DROP_WRITES
        _unmount_flakey
      
        # Allow writes again and mount. This makes the fs replay its fsync log.
        _load_flakey_table $FLAKEY_ALLOW_WRITES
        _mount_flakey
      
        echo "File content after crash and log replay:"
        od -t x1 $SCRATCH_MNT/foo
      
        echo "File xattrs after crash and log replay:"
        for ((i = 1; i <= $num_xattrs; i++)); do
            name="user.attr_$(printf "%04d" $i)"
            echo -n "$name="
            $GETFATTR_PROG --absolute-names -n $name --only-values $SCRATCH_MNT/foo
            echo
        done
      
        status=0
        exit
      
      The golden output expects all xattrs to be available, and with the correct
      values, after the fsync log is replayed.
      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>
      db4043df
    • Jerome Marchand's avatar
      assoc_array: don't call compare_object() on a node · 32d1b672
      Jerome Marchand authored
      [ Upstream commit 8d4a2ec1 ]
      
      Changes since V1: fixed the description and added KASan warning.
      
      In assoc_array_insert_into_terminal_node(), we call the
      compare_object() method on all non-empty slots, even when they're
      not leaves, passing a pointer to an unexpected structure to
      compare_object(). Currently it causes an out-of-bound read access
      in keyring_compare_object detected by KASan (see below). The issue
      is easily reproduced with keyutils testsuite.
      Only call compare_object() when the slot is a leave.
      
      KASan warning:
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in keyring_compare_object+0x213/0x240 at addr ffff880060a6f838
      Read of size 8 by task keyctl/1655
      =============================================================================
      BUG kmalloc-192 (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in assoc_array_insert+0xfd0/0x3a60 age=69 cpu=1 pid=1647
      	___slab_alloc+0x563/0x5c0
      	__slab_alloc+0x51/0x90
      	kmem_cache_alloc_trace+0x263/0x300
      	assoc_array_insert+0xfd0/0x3a60
      	__key_link_begin+0xfc/0x270
      	key_create_or_update+0x459/0xaf0
      	SyS_add_key+0x1ba/0x350
      	entry_SYSCALL_64_fastpath+0x12/0x76
      INFO: Slab 0xffffea0001829b80 objects=16 used=8 fp=0xffff880060a6f550 flags=0x3fff8000004080
      INFO: Object 0xffff880060a6f740 @offset=5952 fp=0xffff880060a6e5d1
      
      Bytes b4 ffff880060a6f730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f740: d1 e5 a6 60 00 88 ff ff 0e 00 00 00 00 00 00 00  ...`............
      Object ffff880060a6f750: 02 cf 8e 60 00 88 ff ff 02 c0 8e 60 00 88 ff ff  ...`.......`....
      Object ffff880060a6f760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f770: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f790: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      Object ffff880060a6f7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      CPU: 0 PID: 1655 Comm: keyctl Tainted: G    B           4.5.0-rc4-kasan+ #291
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       0000000000000000 000000001b2800b4 ffff880060a179e0 ffffffff81b60491
       ffff88006c802900 ffff880060a6f740 ffff880060a17a10 ffffffff815e2969
       ffff88006c802900 ffffea0001829b80 ffff880060a6f740 ffff880060a6e650
      Call Trace:
       [<ffffffff81b60491>] dump_stack+0x85/0xc4
       [<ffffffff815e2969>] print_trailer+0xf9/0x150
       [<ffffffff815e9454>] object_err+0x34/0x40
       [<ffffffff815ebe50>] kasan_report_error+0x230/0x550
       [<ffffffff819949be>] ? keyring_get_key_chunk+0x13e/0x210
       [<ffffffff815ec62d>] __asan_report_load_n_noabort+0x5d/0x70
       [<ffffffff81994cc3>] ? keyring_compare_object+0x213/0x240
       [<ffffffff81994cc3>] keyring_compare_object+0x213/0x240
       [<ffffffff81bc238c>] assoc_array_insert+0x86c/0x3a60
       [<ffffffff81bc1b20>] ? assoc_array_cancel_edit+0x70/0x70
       [<ffffffff8199797d>] ? __key_link_begin+0x20d/0x270
       [<ffffffff8199786c>] __key_link_begin+0xfc/0x270
       [<ffffffff81993389>] key_create_or_update+0x459/0xaf0
       [<ffffffff8128ce0d>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff81992f30>] ? key_type_lookup+0xc0/0xc0
       [<ffffffff8199e19d>] ? lookup_user_key+0x13d/0xcd0
       [<ffffffff81534763>] ? memdup_user+0x53/0x80
       [<ffffffff819983ea>] SyS_add_key+0x1ba/0x350
       [<ffffffff81998230>] ? key_get_type_from_user.constprop.6+0xa0/0xa0
       [<ffffffff828bcf4e>] ? retint_user+0x18/0x23
       [<ffffffff8128cc7e>] ? trace_hardirqs_on_caller+0x3fe/0x580
       [<ffffffff81004017>] ? trace_hardirqs_on_thunk+0x17/0x19
       [<ffffffff828bc432>] entry_SYSCALL_64_fastpath+0x12/0x76
      Memory state around the buggy address:
       ffff880060a6f700: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
       ffff880060a6f780: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
      >ffff880060a6f800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                              ^
       ffff880060a6f880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
       ffff880060a6f900: fc fc fc fc fc fc 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      Signed-off-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      32d1b672
    • Dennis Kadioglu's avatar
      ALSA: usb-audio: Add a quirk for Plantronics BT300 · 7ec80465
      Dennis Kadioglu authored
      [ Upstream commit b4203ff5 ]
      
      Plantronics BT300 does not support reading the sample rate which leads
      to many lines of "cannot get freq at ep 0x1". This patch adds the USB
      ID of the BT300 to quirks.c and avoids those error messages.
      Signed-off-by: default avatarDennis Kadioglu <denk@post.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7ec80465
    • David Disseldorp's avatar
      rbd: use GFP_NOIO consistently for request allocations · 54080a77
      David Disseldorp authored
      [ Upstream commit 2224d879 ]
      
      As of 5a60e876, RBD object request
      allocations are made via rbd_obj_request_create() with GFP_NOIO.
      However, subsequent OSD request allocations in rbd_osd_req_create*()
      use GFP_ATOMIC.
      
      With heavy page cache usage (e.g. OSDs running on same host as krbd
      client), rbd_osd_req_create() order-1 GFP_ATOMIC allocations have been
      observed to fail, where direct reclaim would have allowed GFP_NOIO
      allocations to succeed.
      
      Cc: stable@vger.kernel.org # 3.18+
      Suggested-by: default avatarVlastimil Babka <vbabka@suse.cz>
      Suggested-by: default avatarNeil Brown <neilb@suse.com>
      Signed-off-by: default avatarDavid Disseldorp <ddiss@suse.de>
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      54080a77
    • Paolo Bonzini's avatar
      compiler-gcc: disable -ftracer for __noclone functions · 9b561b87
      Paolo Bonzini authored
      [ Upstream commit 95272c29 ]
      
      -ftracer can duplicate asm blocks causing compilation to fail in
      noclone functions.  For example, KVM declares a global variable
      in an asm like
      
          asm("2: ... \n
               .pushsection data \n
               .global vmx_return \n
               vmx_return: .long 2b");
      
      and -ftracer causes a double declaration.
      
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: stable@vger.kernel.org
      Cc: kvm@vger.kernel.org
      Reported-by: default avatarLinda Walsh <lkml@tlinx.org>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9b561b87