linux-kernel - Re: [PATCH -mmotm] efi: drop kmemleak

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: <CAKv+Gu_fiEDffKq_fONBYTOdSk-L7__+LgNEyVaNF3FGzBfAow@mail.gmail.com>
Date:   Wed, 26 Dec 2018 13:02:38 +0100
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Qian Cai <cai@....pw>, Ingo Molnar <mingo@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Linux-MM <linux-mm@...ck.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -mmotm] efi: drop kmemleak_ignore() for page allocator

On Wed, 26 Dec 2018 at 03:35, Qian Cai <cai@....pw> wrote:
>
> a0fc5578f1d (efi: Let kmemleak ignore false positives) is no longer
> needed due to efi_mem_reserve_persistent() uses __get_free_page()
> instead where kmemelak is not able to track regardless. Otherwise,
> kernel reported "kmemleak: Trying to color unknown object at
> 0xffff801060ef0000 as Black"
>
> Signed-off-by: Qian Cai <cai@....pw>

Why are you sending this to -mmotm?

Andrew, please disregard this patch. This is EFI/tip material.

> ---
>  drivers/firmware/efi/efi.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 7ac09dd8f268..4c46ff6f2242 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -31,7 +31,6 @@
>  #include <linux/acpi.h>
>  #include <linux/ucs2_string.h>
>  #include <linux/memblock.h>
> -#include <linux/kmemleak.h>
>
>  #include <asm/early_ioremap.h>
>
> @@ -1027,8 +1026,6 @@ int __ref efi_mem_reserve_persistent(phys_addr_t addr, u64 size)
>         if (!rsv)
>                 return -ENOMEM;
>
> -       kmemleak_ignore(rsv);
> -
>         rsv->size = EFI_MEMRESERVE_COUNT(PAGE_SIZE);
>         atomic_set(&rsv->count, 1);
>         rsv->entry[0].base = addr;

The patch that adds the kmemleak_ignore() call here is queued in
efi/urgent branch in the tip tree, but did not make it into v4.20.

efi/urgent does not apply cleanly to efi/core, since the kmalloc()
call [which requires the kmemleak_ignore() call] has been replaced
with alloc_pages() [which doesn't], necessitating this patch to remove
the kmemleak_ignore() call again.

So what I would like to suggest is that Ingo resolves this conflict by
simply dropping the call to kmemleak_ignore(). That way, we don't need
this patch, and we can still backport the efi/urgent change to
v4.20-stable.