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 <surya1@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Issue #83

diff --git a/include/sys/zfs_context.h b/include/sys/zfs_context.h
index 7bcdc9e..6201214 100644 (file)
--- a/include/sys/zfs_context.h
+++ b/include/sys/zfs_context.h
@@ -61,6 +61,7 @@
 #include <sys/fm/fs/zfs.h>
 #include <sys/sunddi.h>
 #include <sys/ctype.h>
+#include <sys/disp.h>
 #include <linux/dcache_compat.h>
 
 #else /* _KERNEL */
@@ -228,6 +229,9 @@ extern kthread_t *zk_thread_create(caddr_t stk, size_t  stksize,
        proc_t *pp, int state, pri_t pri);
 extern void zk_thread_join(kt_did_t tid);
 
+#define        kpreempt_disable()      ((void)0)
+#define        kpreempt_enable()       ((void)0)
+
 #define        PS_NONE         -1
 
 #define        issig(why)      (FALSE)

diff --git a/module/zfs/fm.c b/module/zfs/fm.c
index e4ecfea..a41d353 100644 (file)
--- a/module/zfs/fm.c
+++ b/module/zfs/fm.c
@@ -1413,7 +1413,13 @@ fm_ena_generate_cpu(uint64_t timestamp, processorid_t cpuid, uchar_t format)
 uint64_t
 fm_ena_generate(uint64_t timestamp, uchar_t format)
 {
-       return (fm_ena_generate_cpu(timestamp, getcpuid(), format));
+       uint64_t ena;
+
+       kpreempt_disable();
+       ena = fm_ena_generate_cpu(timestamp, getcpuid(), format);
+       kpreempt_enable();
+
+       return (ena);
 }
 
 uint64_t

diff --git a/module/zfs/txg.c b/module/zfs/txg.c
index 6e64adf..1cb3cb6 100644 (file)
--- 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;