Latest working kernel version: v2.6.28 Earliest failing kernel version: v2.6.28-5716-gfe0bdec (maybe earlier) Distribution: Ubuntu Hardware Environment: Dell XPS M1330 Software Environment: dcdbas? Problem Description: I see this often (all the time) with v2.6.28-5716-gfe0bdec. It is a Dell XPS M1330 (iwl3945, the newer, "...-2" firmware). Jan 5 19:49:36 blimp kernel: BUG: using smp_processor_id() in preemptible [00000000] code: dellWirelessCtl/14180 Jan 5 19:49:36 blimp kernel: caller is smi_request+0x89/0xc8 Jan 5 19:49:36 blimp kernel: Pid: 14180, comm: dellWirelessCtl Not tainted 2.6.28-t #146 Jan 5 19:49:36 blimp kernel: Call Trace: Jan 5 19:49:36 blimp kernel: [<ffffffff8033ee83>] debug_smp_processor_id+0xdb/0xf0 Jan 5 19:49:36 blimp kernel: [<ffffffff8046a6d8>] smi_request+0x89/0xc8 Jan 5 19:49:36 blimp kernel: [<ffffffff8046a78e>] smi_request_store+0x77/0xa5 Jan 5 19:49:36 blimp kernel: [<ffffffff803c69cb>] dev_attr_store+0x1e/0x20 Jan 5 19:49:36 blimp kernel: [<ffffffff802e66e8>] sysfs_write_file+0xe4/0x119 Jan 5 19:49:36 blimp kernel: [<ffffffff802a0084>] vfs_write+0xae/0x124 Jan 5 19:49:36 blimp kernel: [<ffffffff802a01be>] sys_write+0x47/0x70 Jan 5 19:49:36 blimp kernel: [<ffffffff8020b69b>] system_call_fastpath+0x16/0x1b The function smi_request: /** * smi_request: generate SMI request * * Called with smi_data_lock. */ static int smi_request(struct smi_cmd *smi_cmd) { cpumask_t old_mask; int ret = 0; if (smi_cmd->magic != SMI_CMD_MAGIC) { dev_info(&dcdbas_pdev->dev, "%s: invalid magic value\n", __func__); return -EBADR; } /* SMI requires CPU 0 */ old_mask = current->cpus_allowed; set_cpus_allowed_ptr(current, &cpumask_of_cpu(0)); if (smp_processor_id() != 0) { <==== here? dev_dbg(&dcdbas_pdev->dev, "%s: failed to get CPU 0\n", __func__); ret = -EBUSY; goto out; } /* generate SMI */ asm volatile ( "outb %b0,%w1" : /* no output args */ : "a" (smi_cmd->command_code), "d" (smi_cmd->command_address), "b" (smi_cmd->ebx), "c" (smi_cmd->ecx) : "memory" ); out: set_cpus_allowed_ptr(current, &old_mask); return ret; } As the problem points at dcdbas driver, it was also reported to Dell's Doug Warzecha <Douglas_Warzecha@dell.com>. No answer yet
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 21 Jan 2009 14:21:09 -0800 (PST) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12518 > > Summary: BUG: using smp_processor_id() in preemptible [00000000] > code: dellWirelessCtl/... > Product: Other > Version: 2.5 > KernelVersion: v2.6.28-5716-gfe0bdec (also happens with v2.6.29-rc2) > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: other_other@kernel-bugs.osdl.org > ReportedBy: fork0@users.sf.net > > > Latest working kernel version: v2.6.28 > Earliest failing kernel version: v2.6.28-5716-gfe0bdec (maybe earlier) > Distribution: Ubuntu > Hardware Environment: Dell XPS M1330 > Software Environment: dcdbas? > Problem Description: > > I see this often (all the time) with v2.6.28-5716-gfe0bdec. It is a > Dell XPS M1330 (iwl3945, the newer, "...-2" firmware). > > Jan 5 19:49:36 blimp kernel: BUG: using smp_processor_id() in preemptible > [00000000] code: dellWirelessCtl/14180 > Jan 5 19:49:36 blimp kernel: caller is smi_request+0x89/0xc8 > Jan 5 19:49:36 blimp kernel: Pid: 14180, comm: dellWirelessCtl Not tainted > 2.6.28-t #146 > Jan 5 19:49:36 blimp kernel: Call Trace: > Jan 5 19:49:36 blimp kernel: [<ffffffff8033ee83>] > debug_smp_processor_id+0xdb/0xf0 > Jan 5 19:49:36 blimp kernel: [<ffffffff8046a6d8>] smi_request+0x89/0xc8 > Jan 5 19:49:36 blimp kernel: [<ffffffff8046a78e>] > smi_request_store+0x77/0xa5 > Jan 5 19:49:36 blimp kernel: [<ffffffff803c69cb>] dev_attr_store+0x1e/0x20 > Jan 5 19:49:36 blimp kernel: [<ffffffff802e66e8>] > sysfs_write_file+0xe4/0x119 > Jan 5 19:49:36 blimp kernel: [<ffffffff802a0084>] vfs_write+0xae/0x124 > Jan 5 19:49:36 blimp kernel: [<ffffffff802a01be>] sys_write+0x47/0x70 > Jan 5 19:49:36 blimp kernel: [<ffffffff8020b69b>] > system_call_fastpath+0x16/0x1b > > The function smi_request: > > /** > * smi_request: generate SMI request > * > * Called with smi_data_lock. > */ > static int smi_request(struct smi_cmd *smi_cmd) > { > cpumask_t old_mask; > int ret = 0; > > if (smi_cmd->magic != SMI_CMD_MAGIC) { > dev_info(&dcdbas_pdev->dev, "%s: invalid magic value\n", > __func__); > return -EBADR; > } > > /* SMI requires CPU 0 */ > old_mask = current->cpus_allowed; > set_cpus_allowed_ptr(current, &cpumask_of_cpu(0)); > if (smp_processor_id() != 0) { <==== here? > dev_dbg(&dcdbas_pdev->dev, "%s: failed to get CPU 0\n", > __func__); > ret = -EBUSY; > goto out; > } > > /* generate SMI */ > asm volatile ( > "outb %b0,%w1" > : /* no output args */ > : "a" (smi_cmd->command_code), > "d" (smi_cmd->command_address), > "b" (smi_cmd->ebx), > "c" (smi_cmd->ecx) > : "memory" > ); > > out: > set_cpus_allowed_ptr(current, &old_mask); > return ret; > } > > As the problem points at dcdbas driver, it was also reported > to Dell's Doug Warzecha <Douglas_Warzecha@dell.com>. > No answer yet Well that's odd. debug_smp_processor_id() has an explicit test to see if this thread is pinned to a single CPU. I'm assuming that the recent cpumack changes broke that somehow. Perhaps it is already fixed?
Reply-To: fork0@users.sourceforge.net Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: > On Wed, 21 Jan 2009 14:21:09 -0800 (PST) > bugme-daemon@bugzilla.kernel.org wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=12518 > > > > Summary: BUG: using smp_processor_id() in preemptible [00000000] > > code: dellWirelessCtl/... > > > > I see this often (all the time) with v2.6.28-5716-gfe0bdec. It is a > > Dell XPS M1330 (iwl3945, the newer, "...-2" firmware). > > > > ... > > > > As the problem points at dcdbas driver, it was also reported > > to Dell's Doug Warzecha <Douglas_Warzecha@dell.com>. > > No answer yet > > Well that's odd. debug_smp_processor_id() has an explicit test to see > if this thread is pinned to a single CPU. > > I'm assuming that the recent cpumack changes broke that somehow. > Perhaps it is already fixed? > No: BUG: using smp_processor_id() in preemptible [00000000] code: hald-addon-dell/4246 caller is dcdbas_smi_request+0x8c/0x131 Pid: 4246, comm: hald-addon-dell Not tainted 2.6.29-rc3-t #180 Call Trace: [<ffffffff8037b477>] debug_smp_processor_id+0xdb/0xf0 [<ffffffff804d7108>] dcdbas_smi_request+0x8c/0x131 [<ffffffff804d7229>] smi_request_store+0x7c/0xab [<ffffffff804178e5>] dev_attr_store+0x23/0x25 [<ffffffff802fbf70>] sysfs_write_file+0xe9/0x11e [<ffffffff802b2bd0>] vfs_write+0xb3/0x129 [<ffffffff802b2d14>] sys_write+0x4c/0x75 [<ffffffff8020b8cb>] system_call_fastpath+0x16/0x1b
Reply-To: akpm@linux-foundation.org On Wed, 28 Jan 2009 23:41:19 +0100 Alex Riesen <fork0@users.sourceforge.net> wrote: > Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: > > On Wed, 21 Jan 2009 14:21:09 -0800 (PST) > > bugme-daemon@bugzilla.kernel.org wrote: > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=12518 > > > > > > Summary: BUG: using smp_processor_id() in preemptible > [00000000] > > > code: dellWirelessCtl/... > > > > > > I see this often (all the time) with v2.6.28-5716-gfe0bdec. It is a > > > Dell XPS M1330 (iwl3945, the newer, "...-2" firmware). > > > > > > ... > > > > > > As the problem points at dcdbas driver, it was also reported > > > to Dell's Doug Warzecha <Douglas_Warzecha@dell.com>. > > > No answer yet > > > > Well that's odd. debug_smp_processor_id() has an explicit test to see > > if this thread is pinned to a single CPU. > > > > I'm assuming that the recent cpumack changes broke that somehow. > > Perhaps it is already fixed? > > > > No: > > BUG: using smp_processor_id() in preemptible [00000000] code: > hald-addon-dell/4246 > caller is dcdbas_smi_request+0x8c/0x131 > Pid: 4246, comm: hald-addon-dell Not tainted 2.6.29-rc3-t #180 > Call Trace: > [<ffffffff8037b477>] debug_smp_processor_id+0xdb/0xf0 > [<ffffffff804d7108>] dcdbas_smi_request+0x8c/0x131 > [<ffffffff804d7229>] smi_request_store+0x7c/0xab > [<ffffffff804178e5>] dev_attr_store+0x23/0x25 > [<ffffffff802fbf70>] sysfs_write_file+0xe9/0x11e > [<ffffffff802b2bd0>] vfs_write+0xb3/0x129 > [<ffffffff802b2d14>] sys_write+0x4c/0x75 > [<ffffffff8020b8cb>] system_call_fastpath+0x16/0x1b Rusty, Mike: could you please take a look at this one? debug_smp_processor_id() shouldn't be warning if the task is pinned to a single CPU, which dcdbas_smi_request() clearly just did. (reads the new cpumask code for a while) (falls over and dies) (posthumously wonders why debug_smp_processor_id() doesn't just do if (cpus_weight(¤t->cpus_allowed) == 1) or something)
On Thursday 29 January 2009 09:11:19 Alex Riesen wrote: > Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: > > Well that's odd. debug_smp_processor_id() has an explicit test to see > > if this thread is pinned to a single CPU. > > > > I'm assuming that the recent cpumack changes broke that somehow. > > Perhaps it is already fixed? > > > > No: > > BUG: using smp_processor_id() in preemptible [00000000] code: > hald-addon-dell/4246 This *is* weird. I have a fix for this driver to use work_on_cpu, which I sent out twice, but hasn't been applied. I will be pushing it for .30 regardless. Try this which shouldn't do anything, but you never know: cpumask: convert lib/smp_processor_id to new cpumask ops. Impact: cleanup Convert other misc kernel functions to use struct cpumask. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- lib/smp_processor_id.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.28.orig/lib/smp_processor_id.c +++ linux-2.6.28/lib/smp_processor_id.c @@ -22,7 +22,7 @@ notrace unsigned int debug_smp_processor * Kernel threads bound to a single CPU can safely use * smp_processor_id(): */ - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) goto out; /*
Rusty Russell wrote: > On Thursday 29 January 2009 09:11:19 Alex Riesen wrote: >> Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: >>> Well that's odd. debug_smp_processor_id() has an explicit test to see >>> if this thread is pinned to a single CPU. >>> >>> I'm assuming that the recent cpumack changes broke that somehow. >>> Perhaps it is already fixed? >>> >> No: >> >> BUG: using smp_processor_id() in preemptible [00000000] code: >> hald-addon-dell/4246 > > This *is* weird. I have a fix for this driver to use work_on_cpu, which > I sent out twice, but hasn't been applied. I will be pushing it for .30 > regardless. It's in tip/cpus4096: commit 651f8118cf0a5724f23fe1de4a3d9d36b2e01c2e Author: Rusty Russell <rusty@rustcorp.com.au> Date: Sat Jan 10 21:58:09 2009 -0800 cpumask: convert other misc kernel functions Impact: use new cpumask API. Convert other misc kernel functions to use struct cpumask. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c index 0f8fc22..4689cb0 100644 --- a/lib/smp_processor_id.c +++ b/lib/smp_processor_id.c @@ -22,7 +22,7 @@ notrace unsigned int debug_smp_processor_id(void) * Kernel threads bound to a single CPU can safely use * smp_processor_id(): */ - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) goto out; /* > > Try this which shouldn't do anything, but you never know: > > cpumask: convert lib/smp_processor_id to new cpumask ops. > > Impact: cleanup > > Convert other misc kernel functions to use struct cpumask. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > --- > lib/smp_processor_id.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux-2.6.28.orig/lib/smp_processor_id.c > +++ linux-2.6.28/lib/smp_processor_id.c > @@ -22,7 +22,7 @@ notrace unsigned int debug_smp_processor > * Kernel threads bound to a single CPU can safely use > * smp_processor_id(): > */ > - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) > + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) > goto out; > > /*
Reply-To: akpm@linux-foundation.org On Thu, 29 Jan 2009 09:32:19 -0800 Mike Travis <travis@sgi.com> wrote: > Rusty Russell wrote: > > On Thursday 29 January 2009 09:11:19 Alex Riesen wrote: > >> Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: > >>> Well that's odd. debug_smp_processor_id() has an explicit test to see > >>> if this thread is pinned to a single CPU. > >>> > >>> I'm assuming that the recent cpumack changes broke that somehow. > >>> Perhaps it is already fixed? > >>> > >> No: > >> > >> BUG: using smp_processor_id() in preemptible [00000000] code: > hald-addon-dell/4246 > > > > This *is* weird. I have a fix for this driver to use work_on_cpu, which > > I sent out twice, but hasn't been applied. I will be pushing it for .30 > > regardless. > > It's in tip/cpus4096: Ingo, it's needed in mainline. > commit 651f8118cf0a5724f23fe1de4a3d9d36b2e01c2e > Author: Rusty Russell <rusty@rustcorp.com.au> > Date: Sat Jan 10 21:58:09 2009 -0800 > > cpumask: convert other misc kernel functions > > Impact: use new cpumask API. > > Convert other misc kernel functions to use struct cpumask. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > Signed-off-by: Mike Travis <travis@sgi.com> > > diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c > index 0f8fc22..4689cb0 100644 > --- a/lib/smp_processor_id.c > +++ b/lib/smp_processor_id.c > @@ -22,7 +22,7 @@ notrace unsigned int debug_smp_processor_id(void) > * Kernel threads bound to a single CPU can safely use > * smp_processor_id(): > */ > - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) > + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) > goto out; > > /* > This is superficialy srtange. Why would cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu)) and cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu)) return differing values?
Andrew Morton wrote: > On Thu, 29 Jan 2009 09:32:19 -0800 Mike Travis <travis@sgi.com> wrote: > >> Rusty Russell wrote: >>> On Thursday 29 January 2009 09:11:19 Alex Riesen wrote: >>>> Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: >>>>> Well that's odd. debug_smp_processor_id() has an explicit test to see >>>>> if this thread is pinned to a single CPU. >>>>> >>>>> I'm assuming that the recent cpumack changes broke that somehow. >>>>> Perhaps it is already fixed? >>>>> >>>> No: >>>> >>>> BUG: using smp_processor_id() in preemptible [00000000] code: >>>> hald-addon-dell/4246 >>> This *is* weird. I have a fix for this driver to use work_on_cpu, which >>> I sent out twice, but hasn't been applied. I will be pushing it for .30 >>> regardless. >> It's in tip/cpus4096: > > Ingo, it's needed in mainline. > >> commit 651f8118cf0a5724f23fe1de4a3d9d36b2e01c2e >> Author: Rusty Russell <rusty@rustcorp.com.au> >> Date: Sat Jan 10 21:58:09 2009 -0800 >> >> cpumask: convert other misc kernel functions >> >> Impact: use new cpumask API. >> >> Convert other misc kernel functions to use struct cpumask. >> >> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> >> Signed-off-by: Mike Travis <travis@sgi.com> >> >> diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c >> index 0f8fc22..4689cb0 100644 >> --- a/lib/smp_processor_id.c >> +++ b/lib/smp_processor_id.c >> @@ -22,7 +22,7 @@ notrace unsigned int debug_smp_processor_id(void) >> * Kernel threads bound to a single CPU can safely use >> * smp_processor_id(): >> */ >> - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) >> + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) >> goto out; >> >> /* >> > > This is superficialy srtange. Why would > > cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu)) > > and > > cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu)) > > return differing values? I wonder if some bits >= nr_cpu_ids are being set in current->cpus_allowed? (Since the only difference between the above two is the first uses NR_CPUS and the second uses nr_cpu_ids.) -Mike
Reply-To: fork0@users.sourceforge.net Rusty Russell, Thu, Jan 29, 2009 11:59:41 +0100: > On Thursday 29 January 2009 09:11:19 Alex Riesen wrote: > > Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: > > > Well that's odd. debug_smp_processor_id() has an explicit test to see > > > if this thread is pinned to a single CPU. > > > > > > I'm assuming that the recent cpumack changes broke that somehow. > > > Perhaps it is already fixed? > > > > > > > No: > > > > BUG: using smp_processor_id() in preemptible [00000000] code: > hald-addon-dell/4246 > > This *is* weird. I have a fix for this driver to use work_on_cpu, which > I sent out twice, but hasn't been applied. I will be pushing it for .30 > regardless. > > Try this which shouldn't do anything, but you never know: > > cpumask: convert lib/smp_processor_id to new cpumask ops. > It did something: it fixed the BUG.
Created attachment 20043 [details] dmesg booting v2.6.29-rc3 + 651f8118cf0a5724
On Friday 30 January 2009 04:20:15 Andrew Morton wrote: > This is superficialy srtange. Why would > > cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu)) > > and > > cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu)) > > return differing values? Ingo, another fix (Alex, I assume you have CONFIG_CPUMASK_OFFSTACK=y?). Subject: cpumask: convert lib/smp_processor_id to new cpumask ops. Impact: fix debug_smp_processor_id() for CONFIG_CPUMASK_OFFSTACK=y The scheduler now uses the new cpumask API, which deals up to nr_cpumask_bits, whereas the API used NR_CPUS bits. If CONFIG_CPUMASK_OFFSTACK=y these two are not equal, so the top bits are undefined. Leading to bug 12518 "BUG: using smp_processor_id() in preemptible [00000000] code: dellWirelessCtl/..." The fix is simple: use the modern API in the check. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- lib/smp_processor_id.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.28.orig/lib/smp_processor_id.c +++ linux-2.6.28/lib/smp_processor_id.c @@ -22,7 +22,7 @@ notrace unsigned int debug_smp_processor * Kernel threads bound to a single CPU can safely use * smp_processor_id(): */ - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) goto out; /*
On Friday 30 January 2009 04:02:19 Mike Travis wrote: > Rusty Russell wrote: > > On Thursday 29 January 2009 09:11:19 Alex Riesen wrote: > >> Andrew Morton, Wed, Jan 28, 2009 00:51:50 +0100: > >>> Well that's odd. debug_smp_processor_id() has an explicit test to see > >>> if this thread is pinned to a single CPU. > >>> > >>> I'm assuming that the recent cpumack changes broke that somehow. > >>> Perhaps it is already fixed? > >>> > >> No: > >> > >> BUG: using smp_processor_id() in preemptible [00000000] code: > hald-addon-dell/4246 > > > > This *is* weird. I have a fix for this driver to use work_on_cpu, which > > I sent out twice, but hasn't been applied. I will be pushing it for .30 > > regardless. > > It's in tip/cpus4096: > > commit 651f8118cf0a5724f23fe1de4a3d9d36b2e01c2e > Author: Rusty Russell <rusty@rustcorp.com.au> > Date: Sat Jan 10 21:58:09 2009 -0800 > > cpumask: convert other misc kernel functions > > Impact: use new cpumask API. That wasn't the patch I was referring to (the one which convers the dcbdas driver to work_on_cpu is what I meant) but I just re-submitted this identical one-liner with a much longer explanation of why it's now a bug fix, not a cleanup. Since they're textually identical, I don't care which one goes in, but it's now urgent. Thanks, Rusty.
Reply-To: fork0@users.sourceforge.net Rusty Russell, Fri, Jan 30, 2009 02:42:52 +0100: > On Friday 30 January 2009 04:20:15 Andrew Morton wrote: > > This is superficialy srtange. Why would > > > > cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu)) > > > > and > > > > cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu)) > > > > return differing values? > > Ingo, another fix (Alex, I assume you have CONFIG_CPUMASK_OFFSTACK=y?). > Yes, I do.
* Rusty Russell <rusty@rustcorp.com.au> wrote: > On Friday 30 January 2009 04:20:15 Andrew Morton wrote: > > This is superficialy srtange. Why would > > > > cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu)) > > > > and > > > > cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu)) > > > > return differing values? > > Ingo, another fix (Alex, I assume you have CONFIG_CPUMASK_OFFSTACK=y?). > > Subject: cpumask: convert lib/smp_processor_id to new cpumask ops. > > Impact: fix debug_smp_processor_id() for CONFIG_CPUMASK_OFFSTACK=y > > The scheduler now uses the new cpumask API, which deals up to > nr_cpumask_bits, whereas the API used NR_CPUS bits. > > If CONFIG_CPUMASK_OFFSTACK=y these two are not equal, so the top bits > are undefined. Leading to bug 12518 "BUG: using smp_processor_id() in > preemptible [00000000] code: dellWirelessCtl/..." > > The fix is simple: use the modern API in the check. > > Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> > --- > lib/smp_processor_id.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) > + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) > goto out; this change was already added to tip/master two weeks ago, via: 651f811: cpumask: convert other misc kernel functions but (see the changelog below) it was not realized that it's a fix for upstream too. So i've cherry-picked it over into tip/core/urgent, and i've added your more specific bug description above. Thanks, Ingo ---------------> From 651f8118cf0a5724f23fe1de4a3d9d36b2e01c2e Mon Sep 17 00:00:00 2001 From: Rusty Russell <rusty@rustcorp.com.au> Date: Sat, 10 Jan 2009 21:58:09 -0800 Subject: [PATCH] cpumask: convert other misc kernel functions Impact: use new cpumask API. Convert other misc kernel functions to use struct cpumask. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Mike Travis <travis@sgi.com> --- lib/smp_processor_id.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/smp_processor_id.c b/lib/smp_processor_id.c index 0f8fc22..4689cb0 100644 --- a/lib/smp_processor_id.c +++ b/lib/smp_processor_id.c @@ -22,7 +22,7 @@ notrace unsigned int debug_smp_processor_id(void) * Kernel threads bound to a single CPU can safely use * smp_processor_id(): */ - if (cpus_equal(current->cpus_allowed, cpumask_of_cpu(this_cpu))) + if (cpumask_equal(¤t->cpus_allowed, cpumask_of(this_cpu))) goto out; /*
Fixed by commit 4ab0a9409af5fad74ad1fc9e46d5a8b460f353e9 .