On Tue, 2019-03-19 at 16:38 +-0800, Ming Lei wrote:
+AD4 Inside sbitmap+AF8-queue+AF8-clear(), once the clear bit is set, it will be
+AD4 visiable to allocation path immediately. Meantime READ/WRITE on old
+AD4 associated instance(such as request in case of blk-mq) may be
+AD4 out-of-order with the setting clear bit, so race with re-allocation
+AD4 may be triggered.
+AD4
+AD4 Adds one memory barrier for ordering READ/WRITE of the freed associated
+AD4 instance with setting clear bit for avoiding race with re-allocation.
+AD4
+AD4 The following kernel oops triggerd by block/006 on aarch64 may be fixed:
+AF4AXgBe
Does that mean that it has not been verified whether this patch fixes the
NULL pointer issue mentioned in the patch description?
+AD4 diff --git a/lib/sbitmap.c b/lib/sbitmap.c
+AD4 index 5b382c1244ed..941a46495e12 100644
+AD4 --- a/lib/sbitmap.c
+AD4 +-+-+- b/lib/sbitmap.c
+AD4 +AEAAQA -591,6 +-591,17 +AEAAQA EXPORT+AF8-SYMBOL+AF8-GPL(sbitmap+AF8-queue+AF8-wake+AF8-up)+ADs
+AD4 void sbitmap+AF8-queue+AF8-clear(struct sbitmap+AF8-queue +ACo-sbq, unsigned int nr,
+AD4 unsigned int cpu)
+AD4 +AHs
+AD4 +- /+ACo
+AD4 +- +ACo Once the clear bit is set, the bit may be allocated out.
+AF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4
This comment is confusing. Did you perhaps mean +ACI-Once the bit is cleared+ACI?
+AD4 +- +ACo
+AD4 +- +ACo Orders READ/WRITE on the asssociated instance(such as request
+AD4 +- +ACo of blk+AF8-mq) by this bit for avoiding race with re-allocation,
+AD4 +- +ACo and its pair is the memory barrier implied in +AF8AXw-sbitmap+AF8-get+AF8-word.
+AD4 +- +ACo
+AD4 +- +ACo One invarient is that the clear bit has to be zero when the bit
+AF4AXgBeAF4AXgBeAF4AXgBe +AF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4AXgBeAF4
invariant? I cant' make sense of this.
+AD4 +- +ACo is in use.
+AD4 +- +ACo-/
+AD4 +- smp+AF8-mb+AF8AXw-before+AF8-atomic()+ADs
+AD4 sbitmap+AF8-deferred+AF8-clear+AF8-bit(+ACY-sbq-+AD4-sb, nr)+ADs
Thanks,
Bart.
