1. 24 Feb, 2015 24 commits
  2. 19 Feb, 2015 2 commits
    • Michael S. Tsirkin's avatar
      virtio_pci: document why we defer kfree · ae4aaf87
      Michael S. Tsirkin authored
      commit a1eb03f5 upstream.
      
      The reason we defer kfree until release function is because it's a
      general rule for kobjects: kfree of the reference counter itself is only
      legal in the release function.
      
      Previous patch didn't make this clear, document this in code.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      [ luis: backported to 3.16:
        - file rename: virtio_pci_legacy.c -> virtio_pci.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ae4aaf87
    • Sasha Levin's avatar
      virtio_pci: defer kfree until release callback · 29616921
      Sasha Levin authored
      commit 63bd62a0 upstream.
      
      A struct device which has just been unregistered can live on past the
      point at which a driver decides to drop it's initial reference to the
      kobject gained on allocation.
      
      This implies that when releasing a virtio device, we can't free a struct
      virtio_device until the underlying struct device has been released,
      which might not happen immediately on device_unregister().
      
      Unfortunately, this is exactly what virtio pci does:
      it has an empty release callback, and frees memory immediately
      after unregistering the device.
      
      This causes an easy to reproduce crash if CONFIG_DEBUG_KOBJECT_RELEASE
      it enabled.
      
      To fix, free the memory only once we know the device is gone in the release
      callback.
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      [ luis: backported to 3.16:
        - file rename: virtio_pci_legacy.c -> virtio_pci.c ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      29616921
  3. 18 Feb, 2015 1 commit
  4. 17 Feb, 2015 4 commits
    • Anantha Krishnan's avatar
      Bluetooth: Add support for Acer [0489:e078] · 9abc3bde
      Anantha Krishnan authored
      commit 4b552bc9 upstream.
      
      Add support for the QCA6174 chip.
      
          T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
          D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
          P:  Vendor=0489 ProdID=e078 Rev=00.01
          C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
          I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
          I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      Signed-off-by: default avatarAnantha Krishnan <ananthk@codeaurora.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      9abc3bde
    • Janne Heikkinen's avatar
      Bluetooth: Add USB device 04ca:3010 as Atheros AR3012 · c692ea0b
      Janne Heikkinen authored
      commit 134d3b35 upstream.
      
      Asus X553MA has USB device 04ca:3010 that is Atheros AR3012
      or compatible.
      
      Device from /sys/kernel/debug/usb/devices:
      
      T:  Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 27 Spd=12   MxCh= 0
      D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
      P:  Vendor=04ca ProdID=3010 Rev= 0.02
      C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
      A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
      I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
      E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
      I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
      I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
      I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
      I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
      I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
      I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
      E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
      Signed-off-by: default avatarJanne Heikkinen <janne.m.heikkinen@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c692ea0b
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Don't use memory accounting for kernel-side fence objects · 113f22aa
      Thomas Hellstrom authored
      commit 1f563a6a upstream.
      
      Kernel side fence objects are used when unbinding resources and may thus be
      created as part of a memory reclaim operation. This might trigger recursive
      memory reclaims and result in the kernel running out of stack space.
      
      So a simple way out is to avoid accounting of these fence objects.
      In principle this is OK since while user-space can trigger the creation of
      such objects, it can't really hold on to them. However, their lifetime is
      quite long, so some form of accounting should perhaps be implemented in the
      future.
      
      Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3
      with low system memory settings.
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarJakob Bornecrantz <jakob@vmware.com>
      Reviewed-by: default avatarSinclair Yeh <syeh@vmware.com>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      113f22aa
    • Yan, Zheng's avatar
      ceph: introduce global empty snap context · 67d95da5
      Yan, Zheng authored
      commit 97c85a82 upstream.
      
      Current snaphost code does not properly handle moving inode from one
      empty snap realm to another empty snap realm. After changing inode's
      snap realm, some dirty pages' snap context can be not equal to inode's
      i_head_snap. This can trigger BUG() in ceph_put_wrbuffer_cap_refs()
      
      The fix is introduce a global empty snap context for all empty snap
      realm. This avoids triggering the BUG() for filesystem with no snapshot.
      
      Fixes: http://tracker.ceph.com/issues/9928Signed-off-by: default avatarYan, Zheng <zyan@redhat.com>
      Reviewed-by: default avatarIlya Dryomov <idryomov@redhat.com>
      Cc: Markus Blank-Burian <burian@muenster.de>
      [ luis: backported to 3.16: adjusted context ]
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      67d95da5
  5. 16 Feb, 2015 9 commits