* Re: Spinlock bug??
2007-01-24 16:55 Spinlock bug?? JWM
@ 2007-01-25 9:12 ` Simon Derr
2007-01-25 17:39 ` Christoph Lameter
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Simon Derr @ 2007-01-25 9:12 UTC (permalink / raw)
To: linux-ia64
> Hi all;
> I'm working on a Bull - 8 way ia64 system running a RedHat variant of
> 2.6.17.
> I keep getting a spin lock bug and dump , attached.
Hello,
If you are running a Bull Linux kernel, I suggest that you contact
directly Bull for this kind of issues. We have added a few custom patches
that could hardly be adressed by other people from this list.
That being said, I'm going to see what's going on in this particular case.
You're probably right.
Simon.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Spinlock bug??
2007-01-24 16:55 Spinlock bug?? JWM
2007-01-25 9:12 ` Simon Derr
@ 2007-01-25 17:39 ` Christoph Lameter
2007-01-25 21:49 ` JWM
2007-01-25 21:51 ` JWM
3 siblings, 0 replies; 5+ messages in thread
From: Christoph Lameter @ 2007-01-25 17:39 UTC (permalink / raw)
To: linux-ia64
On Wed, 24 Jan 2007, JWM wrote:
> Hi all;
> I'm working on a Bull - 8 way ia64 system running a RedHat variant of
> 2.6.17.
> I keep getting a spin lock bug and dump , attached.
> It appears that cpuset_set_cpus_affinity is taking doing a task_lock on the
> task structure and only releaseing it after the cpu has changed. That
> naturally causes the spin_bug function to get upset.
> The lock doesn't appear to be required since set_cpus_allowed makes sure
> that things are serialized pretty well.
> Am I missing something here or is this lock not required.
Try a newer kernel. That piece was reworked and cpuset_set_cpus_affinity
no longer exists in recent kernels. 2.6.20-rc6 has:
long sched_setaffinity(pid_t pid, cpumask_t new_mask)
{
cpumask_t cpus_allowed;
struct task_struct *p;
int retval;
lock_cpu_hotplug();
read_lock(&tasklist_lock);
p = find_process_by_pid(pid);
if (!p) {
read_unlock(&tasklist_lock);
unlock_cpu_hotplug();
return -ESRCH;
}
/*
* It is not safe to call set_cpus_allowed with the
* tasklist_lock held. We will bump the task_struct's
* usage count and then drop tasklist_lock.
*/
get_task_struct(p);
read_unlock(&tasklist_lock);
retval = -EPERM;
if ((current->euid != p->euid) && (current->euid != p->uid) &&
!capable(CAP_SYS_NICE))
goto out_unlock;
retval = security_task_setscheduler(p, 0, NULL);
if (retval)
goto out_unlock;
cpus_allowed = cpuset_cpus_allowed(p);
cpus_and(new_mask, new_mask, cpus_allowed);
retval = set_cpus_allowed(p, new_mask);
out_unlock:
put_task_struct(p);
unlock_cpu_hotplug();
return retval;
}
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Spinlock bug??
2007-01-24 16:55 Spinlock bug?? JWM
2007-01-25 9:12 ` Simon Derr
2007-01-25 17:39 ` Christoph Lameter
@ 2007-01-25 21:49 ` JWM
2007-01-25 21:51 ` JWM
3 siblings, 0 replies; 5+ messages in thread
From: JWM @ 2007-01-25 21:49 UTC (permalink / raw)
To: linux-ia64
Simon;
I've looked at the code and the function that calls
cpuset_set_cpus_affinity does a get_task. That bumps the usage count and
should protect from an exiting process doing evil - shouldn't it?
So the sched_setaffinity locks, bumps the task useage and then unlocks
and calls cpuset_set_cpus_affinity. The in the Bull code
cpuset_set_cpuaffinity takes a spin lock on the structure and then
(potentially) moves it to another CPU.
It doesn't look like a change is required other than removing the lock
in cpuset_set_cpus_affinity.
Is there a possible race here I'm missing?
....JW
----- Original Message -----
From: "Simon Derr" <Simon.Derr@bull.net>
To: "JWM" <jwm@systemfabricworks.com>
Cc: <linux-ia64@vger.kernel.org>; "Philippe Garrigues"
<philippe.garrigues@bull.net>
Sent: Thursday, January 25, 2007 3:12 AM
Subject: Re: Spinlock bug??
>> Hi all;
>> I'm working on a Bull - 8 way ia64 system running a RedHat variant of
>> 2.6.17.
>> I keep getting a spin lock bug and dump , attached.
>
> Hello,
>
> If you are running a Bull Linux kernel, I suggest that you contact
> directly Bull for this kind of issues. We have added a few custom patches
> that could hardly be adressed by other people from this list.
>
> That being said, I'm going to see what's going on in this particular case.
> You're probably right.
>
> Simon.
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: Spinlock bug??
2007-01-24 16:55 Spinlock bug?? JWM
` (2 preceding siblings ...)
2007-01-25 21:49 ` JWM
@ 2007-01-25 21:51 ` JWM
3 siblings, 0 replies; 5+ messages in thread
From: JWM @ 2007-01-25 21:51 UTC (permalink / raw)
To: linux-ia64
Thanks
When I saw that code you pasted in it became clear. The potential switch
in CPU's is protected by bumping the usage on the task structure. I haven't
looked at the exit code, but I would think that should protect this from
exiting processes wouldn't you?
....JW
----- Original Message -----
From: "Christoph Lameter" <clameter@sgi.com>
To: "JWM" <jwm@systemfabricworks.com>
Cc: <linux-ia64@vger.kernel.org>; <pj@sgi.com>
Sent: Thursday, January 25, 2007 11:39 AM
Subject: Re: Spinlock bug??
> On Wed, 24 Jan 2007, JWM wrote:
>
>> Hi all;
>> I'm working on a Bull - 8 way ia64 system running a RedHat variant of
>> 2.6.17.
>> I keep getting a spin lock bug and dump , attached.
>> It appears that cpuset_set_cpus_affinity is taking doing a task_lock
>> on the
>> task structure and only releaseing it after the cpu has changed. That
>> naturally causes the spin_bug function to get upset.
>> The lock doesn't appear to be required since set_cpus_allowed makes
>> sure
>> that things are serialized pretty well.
>> Am I missing something here or is this lock not required.
>
> Try a newer kernel. That piece was reworked and cpuset_set_cpus_affinity
> no longer exists in recent kernels. 2.6.20-rc6 has:
>
> long sched_setaffinity(pid_t pid, cpumask_t new_mask)
> {
> cpumask_t cpus_allowed;
> struct task_struct *p;
> int retval;
>
> lock_cpu_hotplug();
> read_lock(&tasklist_lock);
>
> p = find_process_by_pid(pid);
> if (!p) {
> read_unlock(&tasklist_lock);
> unlock_cpu_hotplug();
> return -ESRCH;
> }
>
> /*
> * It is not safe to call set_cpus_allowed with the
> * tasklist_lock held. We will bump the task_struct's
> * usage count and then drop tasklist_lock.
> */
> get_task_struct(p);
> read_unlock(&tasklist_lock);
>
> retval = -EPERM;
> if ((current->euid != p->euid) && (current->euid != p->uid) &&
> !capable(CAP_SYS_NICE))
> goto out_unlock;
>
> retval = security_task_setscheduler(p, 0, NULL);
> if (retval)
> goto out_unlock;
>
> cpus_allowed = cpuset_cpus_allowed(p);
> cpus_and(new_mask, new_mask, cpus_allowed);
> retval = set_cpus_allowed(p, new_mask);
>
> out_unlock:
> put_task_struct(p);
> unlock_cpu_hotplug();
> return retval;
> }
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 5+ messages in thread