summaryrefslogtreecommitdiffstats
path: root/block
diff options
context:
space:
mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2014-02-24 16:40:01 +0100
committerJens Axboe <axboe@fb.com>2014-02-24 14:47:09 -0800
commitfce8ad1568c57e7f334018dec4fa1744c926c135 (patch)
tree7660f5d36efc83f90b35200f28c807423549afde /block
parente0a23b0628b10d25f2c178be6fcfc17c1ab49fda (diff)
downloadlinux-0-day-fce8ad1568c57e7f334018dec4fa1744c926c135.tar.gz
linux-0-day-fce8ad1568c57e7f334018dec4fa1744c926c135.tar.xz
smp: Remove wait argument from __smp_call_function_single()
The main point of calling __smp_call_function_single() is to send an IPI in a pure asynchronous way. By embedding a csd in an object, a caller can send the IPI without waiting for a previous one to complete as is required by smp_call_function_single() for example. As such, sending this kind of IPI can be safe even when irqs are disabled. This flexibility comes at the expense of the caller who then needs to synchronize the csd lifecycle by himself and make sure that IPIs on a single csd are serialized. This is how __smp_call_function_single() works when wait = 0 and this usecase is relevant. Now there don't seem to be any usecase with wait = 1 that can't be covered by smp_call_function_single() instead, which is safer. Lets look at the two possible scenario: 1) The user calls __smp_call_function_single(wait = 1) on a csd embedded in an object. It looks like a nice and convenient pattern at the first sight because we can then retrieve the object from the IPI handler easily. But actually it is a waste of memory space in the object since the csd can be allocated from the stack by smp_call_function_single(wait = 1) and the object can be passed an the IPI argument. Besides that, embedding the csd in an object is more error prone because the caller must take care of the serialization of the IPIs for this csd. 2) The user calls __smp_call_function_single(wait = 1) on a csd that is allocated on the stack. It's ok but smp_call_function_single() can do it as well and it already takes care of the allocation on the stack. Again it's more simple and less error prone. Therefore, using the underscore prepend API version with wait = 1 is a bad pattern and a sign that the caller can do safer and more simple. There was a single user of that which has just been converted. So lets remove this option to discourage further users. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Christoph Hellwig <hch@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Jens Axboe <axboe@fb.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by: Jens Axboe <axboe@fb.com>
Diffstat (limited to 'block')
-rw-r--r--block/blk-mq.c2
-rw-r--r--block/blk-softirq.c2
2 files changed, 2 insertions, 2 deletions
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 1fa9dd153fde2..62154edf1489b 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -353,7 +353,7 @@ void __blk_mq_complete_request(struct request *rq)
rq->csd.func = __blk_mq_complete_request_remote;
rq->csd.info = rq;
rq->csd.flags = 0;
- __smp_call_function_single(ctx->cpu, &rq->csd, 0);
+ __smp_call_function_single(ctx->cpu, &rq->csd);
} else {
rq->q->softirq_done_fn(rq);
}
diff --git a/block/blk-softirq.c b/block/blk-softirq.c
index b5c37d96cf0e4..6345b7ebd0dff 100644
--- a/block/blk-softirq.c
+++ b/block/blk-softirq.c
@@ -70,7 +70,7 @@ static int raise_blk_irq(int cpu, struct request *rq)
data->info = rq;
data->flags = 0;
- __smp_call_function_single(cpu, data, 0);
+ __smp_call_function_single(cpu, data);
return 0;
}