Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Nov 24, 2023
    • Kent Overstreet's avatar
      closures: CLOSURE_CALLBACK() to fix type punning · d4e3b928
      Kent Overstreet authored 
      
Control flow integrity is now checking that type signatures match on
indirect function calls. That breaks closures, which embed a work_struct
in a closure in such a way that a closure_fn may also be used as a
workqueue fn by the underlying closure code.

So we have to change closure fns to take a work_struct as their
argument - but that results in a loss of clarity, as closure fns have
different semantics from normal workqueue functions (they run owning a
ref on the closure, which must be released with continue_at() or
closure_return()).

Thus, this patc introduces CLOSURE_CALLBACK() and closure_type() macros
as suggested by Kees, to smooth things over a bit.

Suggested-by: default avatarKees Cook <keescook@chromium.org>
Cc: Coly Li <colyli@suse.de>
Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      d4e3b928
  3. Oct 31, 2023
    • Kent Overstreet's avatar
      closures: Fix race in closure_sync() · ee526b88
      Kent Overstreet authored 
      
As pointed out by Linus, closure_sync() was racy; we could skip blocking
immediately after a get() and a put(), but then that would skip any
barrier corresponding to the other thread's put() barrier.

To fix this, always do the full __closure_sync() sequence whenever any
get() has happened and the closure might have been used by other
threads.

Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      ee526b88
    • Kent Overstreet's avatar
      closures: Better memory barriers · 2bce6368
      Kent Overstreet authored 
      
atomic_(dec|sub)_return_release() are a thing now - use them.

Also, delete the useless barrier in set_closure_fn(): it's redundant
with the memory barrier in closure_put(0.

Since closure_put() would now otherwise just have a release barrier, we
also need a new barrier when the ref hits 0 -
smp_acquire__after_ctrl_dep().

Signed-off-by: default avatarKent Overstreet <kent.overstreet@linux.dev>
      2bce6368
  5. Oct 19, 2023
  7. Oct 02, 2020
  9. Nov 13, 2019
  11. Sep 03, 2019
  13. Aug 11, 2018
  15. Aug 09, 2018
    • Coly Li's avatar
      bcache: do not check return value of debugfs_create_dir() · 78ac2107
      Coly Li authored 
      
Greg KH suggests that normal code should not care about debugfs. Therefore
no matter successful or failed of debugfs_create_dir() execution, it is
unncessary to check its return value.

There are two functions called debugfs_create_dir() and check the return
value, which are bch_debug_init() and closure_debug_init(). This patch
changes these two functions from int to void type, and ignore return values
of debugfs_create_dir().

This patch does not fix exact bug, just makes things work as they should.

Signed-off-by: default avatarColy Li <colyli@suse.de>
Suggested-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: stable@vger.kernel.org
Cc: Kai Krakow <kai@kaishome.de>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      78ac2107
  17. Mar 19, 2018
  19. Jan 08, 2018
  21. Sep 27, 2017
    • Coly Li's avatar
      bcache: use llist_for_each_entry_safe() in __closure_wake_up() · a5f3d8a5
      Coly Li authored 
      
Commit 09b3efec ("bcache: Don't reinvent the wheel but use existing llist
API") replaces the following while loop by llist_for_each_entry(),

-
-	while (reverse) {
-		cl = container_of(reverse, struct closure, list);
-		reverse = llist_next(reverse);
-
+	llist_for_each_entry(cl, reverse, list) {
 		closure_set_waiting(cl, 0);
 		closure_sub(cl, CLOSURE_WAITING + 1);
 	}

This modification introduces a potential race by iterating a corrupted
list. Here is how it happens.

In the above modification, closure_sub() may wake up a process which is
waiting on reverse list. If this process decides to wait again by calling
closure_wait(), its cl->list will be added to another wait list. Then
when llist_for_each_entry() continues to iterate next node, it will travel
on another new wait list which is added in closure_wait(), not the
original reverse list in __closure_wake_up(). It is more probably to
happen on UP machine because the waked up process may preempt the process
which wakes up it.

Use llist_for_each_entry_safe() will fix the issue, the safe version fetch
next node before waking up a process. Then the copy of next node will make
sure list iteration stays on original reverse list.

Fixes: 09b3efec ("bcache: Don't reinvent the wheel but use existing llist API")
Signed-off-by: default avatarColy Li <colyli@suse.de>
Reported-by: default avatarMichael Lyle <mlyle@lyle.org>
Reviewed-by: default avatarByungchul Park <byungchul.park@lge.com>
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      a5f3d8a5
  23. Sep 06, 2017
  25. Jul 05, 2016
  27. Nov 06, 2015
  29. Jan 08, 2014
  31. Nov 11, 2013
  33. Jul 12, 2013
    • 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
  35. Mar 26, 2013
  37. Mar 25, 2013
    • Kent Overstreet's avatar
      bcache: Build fixes from test robot · 07e86ccb
      Kent Overstreet authored 
      
config: make ARCH=i386 allmodconfig

All error/warnings:

   drivers/md/bcache/bset.c: In function 'bch_ptr_bad':
>> drivers/md/bcache/bset.c:164:2: warning: format '%li' expects argument of type 'long int', but argument 4 has type 'size_t' [-Wformat]
--
   drivers/md/bcache/debug.c: In function 'bch_pbtree':
>> drivers/md/bcache/debug.c:86:4: warning: format '%li' expects argument of type 'long int', but argument 4 has type 'size_t' [-Wformat]
--
   drivers/md/bcache/btree.c: In function 'bch_btree_read_done':
>> drivers/md/bcache/btree.c:245:8: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' [-Wformat]
--
   drivers/md/bcache/closure.o: In function `closure_debug_init':
>> (.init.text+0x0): multiple definition of `init_module'
>> drivers/md/bcache/super.o:super.c:(.init.text+0x0): first defined here

Signed-off-by: default avatarKent Overstreet <koverstreet@google.com>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: linux-bcache@vger.kernel.org
Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      07e86ccb
  39. Mar 23, 2013