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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.