Wrap smp_processor_id in kpreempt_[dis|en]able

After surveying the code, the few places where smp_processor_id is used
were deemed to be safe to use with a preempt enabled kernel. As such, no
core logic had to be changed. These smp_processor_id call sites are simply
are wrapped in kpreempt_disable and kpreempt_enabled to prevent the
Linux kernel from emitting scary warnings.

Signed-off-by: Prakash Surya <[email protected]>
Signed-off-by: Brian Behlendorf <[email protected]>
Signed-off-by: Richard Yao <[email protected]>
Issue #83

1 files changed, 11 insertions, 1 deletions

diff --git a/module/zfs/txg.c b/module/zfs/txg.c
index 6e64adf93..1cb3cb61c 100644
--- a/module/zfs/txg.c
+++ b/module/zfs/txg.c
@@ -218,9 +218,19 @@ uint64_t
 txg_hold_open(dsl_pool_t *dp, txg_handle_t *th)
 {
 	tx_state_t *tx = &dp->dp_tx;
-	tx_cpu_t *tc = &tx->tx_cpu[CPU_SEQID];
+	tx_cpu_t *tc;
 	uint64_t txg;
 
+	/*
+	 * It appears the processor id is simply used as a "random"
+	 * number to index into the array, and there isn't any other
+	 * significance to the chosen tx_cpu. Because.. Why not use
+	 * the current cpu to index into the array?
+	 */
+	kpreempt_disable();
+	tc = &tx->tx_cpu[CPU_SEQID];
+	kpreempt_enable();
+
 	mutex_enter(&tc->tc_lock);
 
 	txg = tx->tx_open_txg;