From: Mark Gross <mgross@unix-os.sc.intel.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: alan@lxorguk.ukuu.org.uk (Alan Cox),
dan@debian.org (Daniel Jacobowitz),
vamsi@in.ibm.com (Vamsi Krishna S .),
pavel@suse.cz (Pavel Machek),
linux-kernel@vger.kernel.org, marcelo@conectiva.com.br,
tachino@jp.fujitsu.com, jefreyr@pacbell.net,
vamsi_krishna@in.ibm.com, richardj_moore@uk.ibm.com,
hanharat@us.ibm.com, bsuparna@in.ibm.com, bharata@in.ibm.com,
asit.k.mallick@intel.com, david.p.howell@intel.com,
tony.luck@intel.com, sunil.saxena@intel.com
Subject: Re: [PATCH] multithreaded coredumps for elf exeecutables
Date: Thu, 21 Mar 2002 09:59:49 -0500 [thread overview]
Message-ID: <200203211756.g2LHuvW11535@unix-os.sc.intel.com> (raw)
In-Reply-To: <E16o6SJ-0005mD-00@the-village.bc.nu>
On Thursday 21 March 2002 12:34 pm, Alan Cox wrote:
> > This why I grabbed all those locks, and did the two sets of IPI's in the
> > tcore patch. Once the runqueue lock is grabbed, even if that process on
> > the
>
> If you IPI holding a lock whats going to happen if while the IPI is going
> across the cpus the other processor tries to grab the runqueue lock and
> is spinning on it with interrupts off ?
Then the at least 2 CPU's would quickly become dead locked on the
synchronization IPI this patch sends at the end of the suspend_other_threads
function call.
Interrupts shouldn't be turned off when grabbing the runqueue lock. Its also
a bad thing if they would happen to be off while calling into to schedule.
I think schedule was designed to be called only while interrupts are turned
on. It BUG's if "in_interrupt" to enforce this.
--mgross
next prev parent reply other threads:[~2002-03-21 17:57 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-15 11:37 Vamsi Krishna S .
2002-03-19 15:29 ` Pavel Machek
2002-03-19 18:49 ` Mark Gross
2002-03-20 6:06 ` Vamsi Krishna S .
2002-03-20 18:37 ` Daniel Jacobowitz
2002-03-20 16:14 ` Mark Gross
2002-03-21 10:03 ` Vamsi Krishna S .
2002-03-22 16:19 ` Mark Gross
2002-03-21 10:16 ` Vamsi Krishna S .
2002-03-21 16:27 ` Daniel Jacobowitz
2002-03-21 16:52 ` Alan Cox
2002-03-21 14:10 ` Mark Gross
2002-03-21 17:34 ` Alan Cox
2002-03-21 14:59 ` Mark Gross [this message]
2002-03-21 20:25 ` Pavel Machek
2002-03-22 6:06 Suparna Bhattacharya
2002-03-29 5:43 ` Jeff Jenkins
2002-03-29 12:50 ` Mark Gross
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=200203211756.g2LHuvW11535@unix-os.sc.intel.com \
--to=mgross@unix-os.sc.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=asit.k.mallick@intel.com \
--cc=bharata@in.ibm.com \
--cc=bsuparna@in.ibm.com \
--cc=dan@debian.org \
--cc=david.p.howell@intel.com \
--cc=hanharat@us.ibm.com \
--cc=jefreyr@pacbell.net \
--cc=linux-kernel@vger.kernel.org \
--cc=marcelo@conectiva.com.br \
--cc=pavel@suse.cz \
--cc=richardj_moore@uk.ibm.com \
--cc=sunil.saxena@intel.com \
--cc=tachino@jp.fujitsu.com \
--cc=tony.luck@intel.com \
--cc=vamsi@in.ibm.com \
--cc=vamsi_krishna@in.ibm.com \
/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
all inboxes | Powered by JetHome®