[PATCH] ip_fw.c not SMP safe

Paul Rusty Russell (Paul.Russell@rustcorp.com.au)
Mon, 07 Dec 1998 17:51:32 +1130

In message <199812061022.CAA17204@dm.cobaltmicro.com> you write:
> Why? Just do what the scheduler does, by using asking
> cpu_number_map[smp_processor_id()], that returns the kind of number
> you believed smp_processor_id() to be. (grep for "idle_task" in
> kernel/sched.c)

Thanks Dave. Please apply (compiles for both SMP and non-SMP).

Thanks for the persistence, Brian: sorry it was such a tail chase!

Rusty.
--- linux/net/ipv4/ip_fw.c.~3~ Tue Oct 13 14:02:32 1998
+++ linux/net/ipv4/ip_fw.c Mon Dec 7 17:15:01 1998
@@ -115,8 +115,8 @@
* UP.
*
* For backchains and counters, we use an array, indexed by
- * [smp_processor_id()*2 + !in_interrupt()]; the array is of size
- * [smp_num_cpus*2]. For v2.0, smp_num_cpus is effectively 1. So,
+ * [cpu_number_map[smp_processor_id()]*2 + !in_interrupt()]; the array is of
+ * size [smp_num_cpus*2]. For v2.0, smp_num_cpus is effectively 1. So,
* confident of uniqueness, we modify counters even though we only
* have a read lock (to read the counters, you need a write lock,
* though). */
@@ -140,7 +140,11 @@
static struct sock *ipfwsk;
#endif

-#define SLOT_NUMBER() (smp_processor_id()*2 + !in_interrupt())
+#ifdef __SMP__
+#define SLOT_NUMBER() (cpu_number_map[smp_processor_id()]*2 + !in_interrupt())
+#else
+#define SLOT_NUMBER() (!in_interrupt())
+#endif
#define NUM_SLOTS (smp_num_cpus*2)

#define SIZEOF_STRUCT_IP_CHAIN (sizeof(struct ip_chain) \

--
 .sig lost in the mail.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/