public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Cotte-Barrot <Christian.Cotte-Barrot@bull.net>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH&RFC 2/2] OS_MCA Recovery from poisoned memory read
Date: Mon, 23 Aug 2004 08:29:20 +0000	[thread overview]
Message-ID: <4129AAE0.4726DAC8@bull.net> (raw)
In-Reply-To: <41121484.40804@jp.fujitsu.com>

Hidetoshi Seto wrote:
> 
> Keith Owens wrote:
> > mca_handler_bh() is running as an extension of the MCA event which
> > means that it is not irq safe.  It is not safe to get any external lock
> > in mca_page_isolate() or mca_handler_bh().
> 
> Therefore the MCA handler couldn't recover the system if the process is
> running in kernel-mode since it possibly has such important kernel locks.
> 
> > AFAICT, my concerns about the MCA event and mca_handler_bh() not being
> > irq safe are only a problem for the case when the MCA was triggered by
> > user space code but was delivered when the cpu was in kernel code.
> > Maybe we do not support the problem case.
> >
> > *    offending process  affected process  OS MCA do
> > *     kernel mode        kernel mode       down system
> > *     kernel mode        user   mode       kill the process
> > *     user   mode        kernel mode       kill the process <== problem
> > *     user   mode        user   mode       kill the process
> 
> So we have to guarantee that the process is running in user-mode,
> which all processes can't have any locks of kernel, right?
> 
> It would be happy if this fixed patch satisfy your requirement.
> 

Surprising it looks like a discovery (locking problem within the
mca handler) ?

Here is Zoltan's document including a design that exposes a solution 
how to avoid race (paragraphs 3.5, 3.5.1, 3.5.2 ...) and many other
stuff :
  http://mca-recovery.sourceforge.net
    Linux Itanium MCA Recovery Design Document, third draft
      http://mca-recovery.sourceforge.net/mca3.html

-- 
+======+============+=================+
|  |\/\/\/| |                       |                                  |
|  |      | |Christian Cotte-Barrot |org.  :BULL/                      |
|  | (~)(o) |Bull S.A.              |office:FREC/B1-401                |
| C      _) |1, rue de Provence     |mailto:                           |
|  | ,___|  |B.P. 208               |   Christian.Cotte-Barrot@bull.net|
|  |   /    |38432 ECHIROLLES CEDEX |phone :+33 (0)476297725 (229 7725)|
| /----\    |FRANCE                 |fax   :+33 (0)476297518 (229 7518)|
+======+============+=================+

      parent reply	other threads:[~2004-08-23  8:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-05 11:05 [PATCH&RFC 2/2] OS_MCA Recovery from poisoned memory read Hidetoshi Seto
2004-08-05 12:52 ` Keith Owens
2004-08-05 18:49 ` Grant Grundler
2004-08-06 12:17 ` Hidetoshi Seto
2004-08-06 14:32 ` Keith Owens
2004-08-10  7:39 ` Hidetoshi Seto
2004-08-23  8:29 ` Christian Cotte-Barrot [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=4129AAE0.4726DAC8@bull.net \
    --to=christian.cotte-barrot@bull.net \
    --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