From: "JWM" <jwm@systemfabricworks.com>
To: linux-ia64@vger.kernel.org
Subject: Re: Spinlock bug??
Date: Thu, 25 Jan 2007 21:51:44 +0000 [thread overview]
Message-ID: <002201c740cb$01966240$7401a8c0@Maelstrom> (raw)
In-Reply-To: <003e01c73fd8$6a46f730$7401a8c0@Maelstrom>
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
>
prev parent reply other threads:[~2007-01-25 21:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='002201c740cb$01966240$7401a8c0@Maelstrom' \
--to=jwm@systemfabricworks.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox