lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAE9FiQVcKHxsahF95URvpCORAqj8Cy9KrC70zizSStFYVWo0=w@mail.gmail.com>
Date:	Mon, 8 Jun 2015 17:20:19 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] x86/crash: Allocate enough low memory when crashkernel=high

On Mon, Jun 8, 2015 at 12:49 AM, Borislav Petkov <bp@...en8.de> wrote:
> From: Joerg Roedel <jroedel@...e.de>
>
> When the crash kernel is loaded above 4GiB in memory, the
> first kernel allocates only 72MiB of low-memory for the DMA
> requirements of the second kernel. On systems with many
> devices this is not enough and causes device driver
> initialization errors and failed crash dumps. Testing by
> SUSE and Redhat has shown that 256MiB is a good default
> value for now and the discussion has lead to this value as
> well. So set this default value to 256MiB to make sure there
> is enough memory available for DMA.

Is the 256MiB too big?

BTW, the affected system does not support iommu?

on my intel test box with 6T and 16 pcie cards does not hit the 72MiB
limit.

So the affected system is 12T and more cards?

>
> Signed-off-by: Joerg Roedel <jroedel@...e.de>
> Acked-by: Baoquan He <bhe@...hat.com>
> Cc: Baoquan He <bhe@...hat.com>
> Cc: Dave Young <dyoung@...hat.com>
> Cc: "H. Peter Anvin" <hpa@...or.com>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Jörg Rödel <joro@...tes.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Vivek Goyal <vgoyal@...hat.com>
> Cc: kexec@...ts.infradead.org
> Cc: x86-ml <x86@...nel.org>
> Link: http://lkml.kernel.org/r/1433500202-25531-4-git-send-email-joro@8bytes.org
> [ Reflow comment. ]
> Signed-off-by: Borislav Petkov <bp@...e.de>
> ---
>  arch/x86/kernel/setup.c | 13 ++++++++-----
>  1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d74ac33290ae..5a697e56634c 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -531,12 +531,15 @@ static void __init reserve_crashkernel_low(void)
>         if (ret != 0) {
>                 /*
>                  * two parts from lib/swiotlb.c:
> -                *      swiotlb size: user specified with swiotlb= or default.
> -                *      swiotlb overflow buffer: now is hardcoded to 32k.
> -                *              We round it to 8M for other buffers that
> -                *              may need to stay low too.
> +                * - swiotlb size: user-specified with swiotlb= or default.
> +                *
> +                * -swiotlb overflow buffer: now hardcoded to 32k.

why do you need to treat them differently ?
"- swiotlb" and "-swiotlb"

> +                *

Why do you need to put extra blank line here? that 8M round up
is for swiotlb overflow buffer.

> +                * We round it to 8M for other buffers that may need to stay low
> +                * too. Also make sure we allocate enough extra low memory so
> +                * that we don't run out of DMA buffers for 32-bit devices.
>                  */
> -               low_size = swiotlb_size_or_default() + (8UL<<20);
> +               low_size = max(swiotlb_size_or_default() + (8UL<<20), 256UL<<20);
>                 auto_set = true;
>         } else {
>                 /* passed with crashkernel=0,low ? */
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ