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
#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 */
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)
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
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;