All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernhard Walle <bwalle@suse.de>
To: Vivek Goyal <vgoyal@in.ibm.com>
Cc: akpm@linux-foundation.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, ak@suse.de
Subject: Re: [patch 0/2] Protect crashkernel against BSS overlap
Date: Tue, 16 Oct 2007 18:28:06 +0200	[thread overview]
Message-ID: <20071016162806.GB16521@suse.de> (raw)
In-Reply-To: <20071016054956.GA4659@in.ibm.com>

* Vivek Goyal <vgoyal@in.ibm.com> [2007-10-16 07:49]:
> 
> Shouldn't bootmem allocator have the functionality to flag an error if
> we try to reserve a memory which is already reserved? I see that bootmem
> allocator is currently printing a warning under CONFIG_DEBUG_BOOTMEM.

That's probably better, yes. See the next version.

> Wouldn't it be better if we reserve the code, data and bss memory also
> using bootmem allocator and when somebody tries to reserve craskernel memory
> and if there is an overlap, boot memory allocator should scream?

It's already marked as reserved. At least on i386 in my test.

> In second patch, you are checking for crash kernel reserved memory being
> beyond _end. That will make sure that there is no overlap with kernel
> text, data or bss. I am wondering then why do we need first patch and
> why should we register bss memory in the resources list. Second patch 
> would make sure that there is no overlap with crash kernel memory and kexec
> will not place any segment outside crashkernel memory.

I think we should also present the BSS to the user like we present
text and data.


Thanks,
   Bernhard

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Bernhard Walle <bwalle@suse.de>
To: Vivek Goyal <vgoyal@in.ibm.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	akpm@linux-foundation.org, ak@suse.de
Subject: Re: [patch 0/2] Protect crashkernel against BSS overlap
Date: Tue, 16 Oct 2007 18:28:06 +0200	[thread overview]
Message-ID: <20071016162806.GB16521@suse.de> (raw)
In-Reply-To: <20071016054956.GA4659@in.ibm.com>

* Vivek Goyal <vgoyal@in.ibm.com> [2007-10-16 07:49]:
> 
> Shouldn't bootmem allocator have the functionality to flag an error if
> we try to reserve a memory which is already reserved? I see that bootmem
> allocator is currently printing a warning under CONFIG_DEBUG_BOOTMEM.

That's probably better, yes. See the next version.

> Wouldn't it be better if we reserve the code, data and bss memory also
> using bootmem allocator and when somebody tries to reserve craskernel memory
> and if there is an overlap, boot memory allocator should scream?

It's already marked as reserved. At least on i386 in my test.

> In second patch, you are checking for crash kernel reserved memory being
> beyond _end. That will make sure that there is no overlap with kernel
> text, data or bss. I am wondering then why do we need first patch and
> why should we register bss memory in the resources list. Second patch 
> would make sure that there is no overlap with crash kernel memory and kexec
> will not place any segment outside crashkernel memory.

I think we should also present the BSS to the user like we present
text and data.


Thanks,
   Bernhard

  parent reply	other threads:[~2007-10-16 16:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-15 11:50 [patch 0/2] Protect crashkernel against BSS overlap Bernhard Walle
2007-10-15 11:50 ` Bernhard Walle
2007-10-15 11:50 ` [patch 1/2] Add BSS to resource tree Bernhard Walle
2007-10-15 11:50   ` Bernhard Walle
2007-10-15 18:32   ` Andrew Morton
2007-10-15 18:32     ` Andrew Morton
2007-10-15 21:24     ` Bernhard Walle
2007-10-15 21:24       ` Bernhard Walle
2007-10-15 11:50 ` [patch 2/2] Check if the crashkernel area is behind BSS Bernhard Walle
2007-10-15 11:50   ` Bernhard Walle
2007-10-16  5:49 ` [patch 0/2] Protect crashkernel against BSS overlap Vivek Goyal
2007-10-16  5:49   ` Vivek Goyal
2007-10-16  9:59   ` Andi Kleen
2007-10-16  9:59     ` Andi Kleen
2007-10-16 16:26     ` Bernhard Walle
2007-10-16 16:26       ` Bernhard Walle
2007-10-16 16:28   ` Bernhard Walle [this message]
2007-10-16 16:28     ` Bernhard Walle

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=20071016162806.GB16521@suse.de \
    --to=bwalle@suse.de \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@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 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.