public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Suparna Bhattacharya <suparna@in.ibm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Corey Minyard <cminyard@mvista.com>,
	Kenneth Sumrall <ken@mvista.com>,
	linux-kernel@vger.kernel.org, lkcd-devel@lists.sourceforge.net
Subject: Re: Kexec, DMA, and SMP
Date: Tue, 11 Feb 2003 19:10:27 +0530	[thread overview]
Message-ID: <20030211191027.A2999@in.ibm.com> (raw)
In-Reply-To: <20030211182508.A2936@in.ibm.com>; from suparna@in.ibm.com on Tue, Feb 11, 2003 at 06:25:08PM +0530

On Tue, Feb 11, 2003 at 06:25:08PM +0530, Suparna Bhattacharya wrote:
> On Mon, Feb 10, 2003 at 10:56:43AM -0700, Eric W. Biederman wrote:
> > Suparna Bhattacharya <suparna@in.ibm.com> writes:
> [snip]
> > 
> > Not primarily.  Instead I am trying to address the possibility that
> > DMA is overwriting the recovery code due to a device not being shutdown
> > properly.  Though it would happen to cover many cases of the wrong
> > memory address being passed to a device.
> > 
> 
> OK, I see where you are coming from. It is an interesting
> possibility, if you know how to pull it off for various 
> architectures, and the working area that the new kernel needs 
> to do operate to the extent of issuing the writeout is not 
> too big (i.e.  doesn't take away too much memory from the 
> operational kernel). Perhaps we could hide this memory from 
> the normal kernel virtual address space most of the time, so 
> its less susceptable to software corruption (i.e. besides
> physical access via DMA).

For the sort of problems which Ken is seeing, maybe we can,
for a start, do without all the modifications to make the 
new kernel run at a different address, if we can assume 
that most i/o is likely is happen on dynamically allocated 
buffers.

We could just reserve a memory area of reasonable size (how
much ?) which would be used by the new kernel for all its 
allocations. We already have the infrastructure to tell the 
new kernel which memory areas not to use, so its simple 
enough to ask it exclude all but the reserved area. 
By issuing the i/o as early as possible during bootup
(for lkcd all we need is the block device to be setup for
i/o requests), we can minimize the amount of memory to
reserve in this manner.

That might address a large percentage of the regular cases,
i.e. except where statically allocated buffers could be
targets for DMA. If we are using in-use (user) pages
for saving the dump, then there is a possibility of a dump
getting corrupted by a DMA, but there may be a way to
minimize that when we chose destination pages to use.

Regards
Suparna

-- 
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Labs, India


  reply	other threads:[~2003-02-11 13:25 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3E448745.9040707@mvista.com>
     [not found] ` <m1isvuzjj2.fsf@frodo.biederman.org>
2003-02-08 20:18   ` Kexec, DMA, and SMP Corey Minyard
2003-02-09 18:39     ` Eric W. Biederman
2003-02-10 11:14       ` Kexec on 2.5.59 problems ? Suparna Bhattacharya
2003-02-10 17:09         ` [Fastboot] " Andy Pfiffer
2003-02-10 18:07           ` Eric W. Biederman
2003-02-11  7:21             ` Suparna Bhattacharya
2003-02-11 17:04               ` Andy Pfiffer
2003-02-11 23:46                 ` Andy Pfiffer
2003-02-12  4:29                   ` Eric W. Biederman
2003-02-12 22:31                     ` Andy Pfiffer
2003-02-13  9:50                       ` Suparna Bhattacharya
2003-02-13 15:10                         ` Eric W. Biederman
2003-02-18 10:59                           ` Suparna Bhattacharya
2003-02-18 15:06                             ` Eric W. Biederman
2003-02-10 12:12       ` Kexec, DMA, and SMP Suparna Bhattacharya
2003-02-10 13:56         ` Corey Minyard
2003-02-10 15:07           ` Suparna Bhattacharya
2003-02-10 15:22             ` Corey Minyard
2003-02-10 17:56         ` Eric W. Biederman
2003-02-11  1:35           ` Kenneth Sumrall
2003-02-11  5:08             ` Eric W. Biederman
2003-02-11 17:09               ` Stephen Hemminger
2003-02-11 12:55           ` Suparna Bhattacharya
2003-02-11 13:40             ` Suparna Bhattacharya [this message]
2003-02-11 14:06               ` Corey Minyard
2003-02-11 14:40                 ` Suparna Bhattacharya
2003-02-11 15:20                   ` Corey Minyard
2003-02-12  4:28                     ` Eric W. Biederman
2003-02-12 14:17                       ` Corey Minyard
2003-02-12 14:51                         ` Eric W. Biederman
2003-02-12 16:06                           ` Corey Minyard
2003-02-13 11:13                             ` Suparna Bhattacharya
2003-02-14  3:13                             ` Werner Almesberger
2003-02-14 14:20                               ` Corey Minyard
2003-02-14 18:10                                 ` Werner Almesberger
2003-02-14 18:23                                   ` Corey Minyard
2003-02-14 19:26                                     ` Zwane Mwaikambo
2003-02-14 19:44                                       ` Werner Almesberger
2003-02-14 20:00                                         ` Corey Minyard
2003-02-15  6:03                                           ` Eric W. Biederman
2003-02-16 16:22                                             ` Corey Minyard
2003-02-16 21:48                                               ` Eric W. Biederman
2003-02-17  4:26                                                 ` Corey Minyard
2003-02-17  7:18                                                   ` Eric W. Biederman
2003-02-17 17:32                                                     ` Corey Minyard
2003-02-12  4:47                     ` Suparna Bhattacharya

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=20030211191027.A2999@in.ibm.com \
    --to=suparna@in.ibm.com \
    --cc=cminyard@mvista.com \
    --cc=ebiederm@xmission.com \
    --cc=ken@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkcd-devel@lists.sourceforge.net \
    /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