Commit 7abc70d7 authored by Yijing Wang's avatar Yijing Wang Committed by Jens Axboe

bcache: update document info

There is no return in continue_at(), update the documentation.
Signed-off-by: default avatarYijing Wang <wangyijing@huawei.com>
Acked-by: default avatarColy Li <colyli@suse.de>
Signed-off-by: default avatarJens Axboe <axboe@fb.com>
parent c50d4d5d
...@@ -112,7 +112,7 @@ bool closure_wait(struct closure_waitlist *waitlist, struct closure *cl) ...@@ -112,7 +112,7 @@ bool closure_wait(struct closure_waitlist *waitlist, struct closure *cl)
EXPORT_SYMBOL(closure_wait); EXPORT_SYMBOL(closure_wait);
/** /**
* closure_sync - sleep until a closure a closure has nothing left to wait on * closure_sync - sleep until a closure has nothing left to wait on
* *
* Sleeps until the refcount hits 1 - the thread that's running the closure owns * Sleeps until the refcount hits 1 - the thread that's running the closure owns
* the last refcount. * the last refcount.
......
...@@ -31,7 +31,8 @@ ...@@ -31,7 +31,8 @@
* passing it, as you might expect, the function to run when nothing is pending * passing it, as you might expect, the function to run when nothing is pending
* and the workqueue to run that function out of. * and the workqueue to run that function out of.
* *
* continue_at() also, critically, is a macro that returns the calling function. * continue_at() also, critically, requires a 'return' immediately following the
* location where this macro is referenced, to return to the calling function.
* There's good reason for this. * There's good reason for this.
* *
* To use safely closures asynchronously, they must always have a refcount while * To use safely closures asynchronously, they must always have a refcount while
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment