1. 12 Jul, 2013 5 commits
    • Kent Overstreet's avatar
      bcache: Shutdown fix · 5caa52af
      Kent Overstreet authored
      Stopping a cache set is supposed to make it stop attached backing
      devices, but somewhere along the way that code got lost. Fixing this
      mainly has the effect of fixing our reboot notifier.
      Signed-off-by: default avatarKent Overstreet <kmo@daterainc.com>
      Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
      5caa52af
    • Kent Overstreet's avatar
      bcache: Fix a sysfs splat on shutdown · c9502ea4
      Kent Overstreet authored
      If we stopped a bcache device when we were already detaching (or
      something like that), bcache_device_unlink() would try to remove a
      symlink from sysfs that was already gone because the bcache dev kobject
      had already been removed from sysfs.
      
      So keep track of whether we've removed stuff from sysfs.
      Signed-off-by: default avatarKent Overstreet <kmo@daterainc.com>
      Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
      c9502ea4
    • Kent Overstreet's avatar
      bcache: Advertise that flushes are supported · 54d12f2b
      Kent Overstreet authored
      Whoops - bcache's flush/FUA was mostly correct, but flushes get filtered
      out unless we say we support them...
      Signed-off-by: default avatarKent Overstreet <kmo@daterainc.com>
      Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
      54d12f2b
    • Dan Carpenter's avatar
      bcache: check for allocation failures · d2a65ce2
      Dan Carpenter authored
      There is a missing NULL check after the kzalloc().
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      d2a65ce2
    • Kent Overstreet's avatar
      bcache: Fix a dumb race · 6aa8f1a6
      Kent Overstreet authored
      In the far-too-complicated closure code - closures can have destructors,
      for probably dubious reasons; they get run after the closure is no
      longer waiting on anything but before dropping the parent ref, intended
      just for freeing whatever memory the closure is embedded in.
      
      Trouble is, when remaining goes to 0 and we've got nothing more to run -
      we also have to unlock the closure, setting remaining to -1. If there's
      a destructor, that unlock isn't doing anything - nobody could be trying
      to lock it if we're about to free it - but if the unlock _is needed...
      that check for a destructor was racy. Argh.
      Signed-off-by: default avatarKent Overstreet <kmo@daterainc.com>
      Cc: linux-stable <stable@vger.kernel.org> # >= v3.10
      6aa8f1a6
  2. 01 Jul, 2013 5 commits
  3. 27 Jun, 2013 15 commits
  4. 22 Jun, 2013 9 commits
  5. 21 Jun, 2013 6 commits