headers
Paul Gortmaker | 2 Jan 2011 08:18
Favicon

[34-longterm 232/260] x86, kdump: Change copy_oldmem_page() to use cached addressing

From: Cliff Wickman <cpw@...>

commit 37a2f9f30a360fb03522d15c85c78265ccd80287 upstream.

The copy of /proc/vmcore to a user buffer proceeds much faster
if the kernel addresses memory as cached.

With this patch we have seen an increase in transfer rate from
less than 15MB/s to 80-460MB/s, depending on size of the
transfer. This makes a big difference in time needed to save a
system dump.

Signed-off-by: Cliff Wickman <cpw@...>
Acked-by: "Eric W. Biederman" <ebiederm@...>
Cc: kexec@...
LKML-Reference: <E1OtMLz-0001yp-Ia@...>
Signed-off-by: Ingo Molnar <mingo@...>
Signed-off-by: Paul Gortmaker <paul.gortmaker@...>
---
 arch/x86/kernel/crash_dump_64.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
index ce96a6b..9948288 100644
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
 <at>  <at>  -34,7 +34,7  <at>  <at>  ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
 	if (!csize)
 		return 0;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Gortmaker | 2 Jan 2011 08:18
Favicon

[34-longterm 226/260] mm, x86: Saving vmcore with non-lazy freeing of vmas

From: Cliff Wickman <cpw@...>

commit 3ee48b6af49cf534ca2f481ecc484b156a41451d upstream.

During the reading of /proc/vmcore the kernel is doing
ioremap()/iounmap() repeatedly. And the buildup of un-flushed
vm_area_struct's is causing a great deal of overhead. (rb_next()
is chewing up most of that time).

This solution is to provide function set_iounmap_nonlazy(). It
causes a subsequent call to iounmap() to immediately purge the
vma area (with try_purge_vmap_area_lazy()).

With this patch we have seen the time for writing a 250MB
compressed dump drop from 71 seconds to 44 seconds.

Signed-off-by: Cliff Wickman <cpw@...>
Cc: Andrew Morton <akpm@...>
Cc: kexec@...
LKML-Reference: <E1OwHZ4-0005WK-Tw@...>
Signed-off-by: Ingo Molnar <mingo@...>
Signed-off-by: Paul Gortmaker <paul.gortmaker@...>
---
 arch/x86/include/asm/io.h       |    1 +
 arch/x86/kernel/crash_dump_64.c |    1 +
 mm/vmalloc.c                    |    9 +++++++++
 3 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 30a3e97..6a45ec4 100644
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vivek Goyal | 3 Jan 2011 06:01
Picon
Favicon

Re: How does kdump deal with trampoline allocation?

On Mon, Dec 27, 2010 at 04:13:55PM -0800, H. Peter Anvin wrote:
> On 12/27/2010 04:06 PM, Vivek Goyal wrote:
> > On Mon, Dec 27, 2010 at 12:31:20PM -0800, H. Peter Anvin wrote:
> >> Hi guys,
> >>
> >> I'm planning a major overhaul of the trampoline allocation in x86, and
> >> I'm trying to understand how kdump deals with it.  The trampoline has to
> >> be allocated in low memory (< 1 MiB) and obviously that doesn't include
> >> the kdump area at all.
> > 
> > Hi Peter,
> > 
> > Kdump has the concept of backup area. We backup the contents of first
> > 640KB of physical RAM in kdump reserved area and then allow kdump kernel
> > to use first 640KB of memory. So any trampoline allocation can be done
> > in low memory area without overwritting the contents of first kernel.
> > 
> 
> OK, that's straightforward.  That presumably means that the low 640K is
> marked unused in the memory map that memblock sees during early startup.

Yes, the available memory for second kernel is told to second kernel with
kernel command line option "memmap=", hence it should be visible to 
memblock and it should be able to allocate this memory.

Thanks
Vivek
Permalink | Reply | 0 comments |
headers
Stephan von Krawczynski | 3 Jan 2011 17:06

kexec on mobile ARM device

Hello all,

as quite some of us have mobile android phones with arm, how are chances to get kexec working with such
kernels? The memory model is assumed to be "discontigmem", kernel version 2.6.32.9. Has anyone tried
that already?

--

-- 
Regards,
Stephan
Permalink | Reply | 0 comments |
headers
Cong Wang | 6 Jan 2011 09:27
Picon
Favicon

Re: [Patch] kexec_load: check CAP_SYS_MODULE

(Forgot Cc'ing Eric Paris, adding.)

> Eric pointed out that kexec_load() actually allows you to
> run any code you want in ring0, this is more like CAP_SYS_MODULE.
>
> Reported-by: Eric Paris<eparis@...>
> Signed-off-by: WANG Cong<amwang@...>
>
> ---
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index b55045b..c30d613 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
>  <at>  <at>  -945,7 +945,7  <at>  <at>  SYSCALL_DEFINE4(kexec_load, unsigned long, entry, unsigned long, nr_segments,
>   	int result;
>
>   	/* We only trust the superuser with rebooting the system. */
> -	if (!capable(CAP_SYS_BOOT))
> +	if (!capable(CAP_SYS_BOOT) || !capable(CAP_SYS_MODULE))
>   		return -EPERM;
>
>   	/*
Permalink | Reply | 0 comments |
headers
Centro de Noticias | 8 Jan 2011 08:24
Picon
Favicon

Re


Usted tiene una transferencia de dinero de $ 85.000. Por favor confirmar la
recepcion con su nombre y su pais. Enviar por correo electronico:
wudept <at> w.cn
Permalink | Reply | 0 comments |
headers
Leonardo Chiquitto | 10 Jan 2011 12:19
Picon

[PATCH] ifdown: really set down all active interfaces

Hello,

We've got a bug report of random memory corruption when using kexec.
The test case to reproduce the problem sets up bonding between two
tg3 NICs and transmits some data just before calling kexec to boot
the new kernel. Around one in every one hundred boots would crash
early with different signatures.

We confirmed that the patch below resolves the problem. Please, could
you review and consider it for upstream inclusion?

Thanks,
Leonardo

Before executing the new kernel, kexec disables all network interfaces
to prevent problems like random memory corruption caused by in flight
DMAs.

The current algorithm uses the SIOCGIFCONF to enumerate all interfaces
before shutting them down. However, this ioctl returns only the interfaces
that have an IP address set. This means that in some setups, kexec may
skip interfaces that are up and running. A common example is in bonding,
where the enslaved interfaces are up but may not have an IP address
configured.

This patch replaces SIOCGIFCONF with if_nameindex() to enumerate all
network interfaces available, regardless of having an IP address set
or not.

Signed-off-by: Leonardo Chiquitto <lchiquitto@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
H. Peter Anvin | 10 Jan 2011 23:06
Favicon

kexec and relocatable kernels

Hi guys,

I received a query last week regarding kexec's handling of relocatable
kernels.  In particular, it appears that kexec does not take advantage
of relocatable kernels -- except for kdump -- in avoiding low memory holes.

The system in question had an issue with a low memory hole in the
14-16 MiB range, which caused the kernel to crash on decompress.  They
have a hack in their bootloader to avoid that memory range (that's a
problem in itself and another issue, but the bottom line is that all
bootloaders, not just kexec, needs this awareness.)

Since bzImage 2.10, the kernel gives enough information that the
bootloader (including kexec) can reliably find a place for the kernel
away from memory holes, or fail if no acceptable memory exists.

On another subject, there has been an increasing tendency to put
utilities which are by their nature tightly coupled with the kernel into
the kernel source tree.  I'm kind of thinking that kexec might fit that
bill, what do you think?

	-hpa
Permalink | Reply | 3 comments |
headers
Neil Horman | 11 Jan 2011 13:06
Picon
Favicon

Re: kexec and relocatable kernels

On Mon, Jan 10, 2011 at 02:06:24PM -0800, H. Peter Anvin wrote:
> Hi guys,
> 
> I received a query last week regarding kexec's handling of relocatable
> kernels.  In particular, it appears that kexec does not take advantage
> of relocatable kernels -- except for kdump -- in avoiding low memory holes.
> 
> The system in question had an issue with a low memory hole in the
> 14-16 MiB range, which caused the kernel to crash on decompress.  They
> have a hack in their bootloader to avoid that memory range (that's a
> problem in itself and another issue, but the bottom line is that all
> bootloaders, not just kexec, needs this awareness.)
> 
> Since bzImage 2.10, the kernel gives enough information that the
> bootloader (including kexec) can reliably find a place for the kernel
> away from memory holes, or fail if no acceptable memory exists.
> 
Not sure I completely follow here.  Clearly kdump uses relocatable kernels, and
so can avoid this problem.  But what part of the reboot path affects relocation
such that if your not using kdump, you wind up relocating into a memory hole.
As I understood it (and I admittedly haven't gone back to look as I write this),
the relocation code lives in the header of the kernel image, so it should be the
same weather we're booting on panic (via kdump), or just booting a new kernel
(via kexec -e).  Is something getting messed up in the header data that kexec
doesn't inform the kernel of the presence of a memory hole in some cases?

> On another subject, there has been an increasing tendency to put
> utilities which are by their nature tightly coupled with the kernel into
> the kernel source tree.  I'm kind of thinking that kexec might fit that
> bill, what do you think?
(Continue reading)

Permalink | Reply | 2 comments |
headers
H. Peter Anvin | 11 Jan 2011 17:22
Favicon

Re: kexec and relocatable kernels

On 01/11/2011 04:06 AM, Neil Horman wrote:
>>
> Not sure I completely follow here.  Clearly kdump uses relocatable kernels, and
> so can avoid this problem.  But what part of the reboot path affects relocation
> such that if your not using kdump, you wind up relocating into a memory hole.
> As I understood it (and I admittedly haven't gone back to look as I write this),
> the relocation code lives in the header of the kernel image, so it should be the
> same weather we're booting on panic (via kdump), or just booting a new kernel
> (via kexec -e).  Is something getting messed up in the header data that kexec
> doesn't inform the kernel of the presence of a memory hole in some cases?
> 

No, the problem is that kexec doesn't check if the placement of the
kernel will interfere with a memory hole when picking a default load
location; it always load a replacement (as opposed to kdump) kernel at
0x100000.  For at least a >= 2.10 kernel, it can do better: check to see
if the actual placement will interfere with the memory map and if so,
place it differently.

	-hpa
Permalink | Reply | 1 comment |

Gmane