From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56933C07E85 for ; Fri, 7 Dec 2018 12:32:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1839620989 for ; Fri, 7 Dec 2018 12:32:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1839620989 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gmx.us Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726081AbeLGMcn convert rfc822-to-8bit (ORCPT ); Fri, 7 Dec 2018 07:32:43 -0500 Received: from mout.gmx.net ([212.227.15.18]:45871 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725997AbeLGMcn (ORCPT ); Fri, 7 Dec 2018 07:32:43 -0500 Received: from [71.184.117.43] ([71.184.117.43]) by msvc-mesg-gmx023.server.lan (via HTTP); Fri, 7 Dec 2018 13:32:40 +0100 MIME-Version: 1.0 Message-ID: From: "Qian Cai" To: "Ard Biesheuvel" Cc: "Andrew Morton" , "Marc Zyngier" , "Linux Kernel Mailing List" , linux-efi , "Catalin Marinas" Subject: Re: [RESEND PATCH] efi: let kmemleak ignore false positives Content-Type: text/plain; charset=UTF-8 Date: Fri, 7 Dec 2018 13:32:40 +0100 In-Reply-To: References: <1543517152-23969-1-git-send-email-cai@gmx.us> <20181206161633.36292-1-cai@gmx.us> <20181206175958.GS54495@arrakis.emea.arm.com> <1544119499.12945.48.camel@gmx.us> Content-Transfer-Encoding: 8BIT X-Provags-ID: V03:K1:I+BmsAiDbNTCEKOEFTpsXQRKcKTAjcJ7IwIEA5sjIbIlPOdZA2xpA5Hy7xagLt1UeKC0i R8fqyi99yO65X+sEDTMtEgD+DtLHsiOsG6hJ7qpTLZANBJKYWpgCj8NHpCDSOPhyiXZghTv/OhKo BOQXHmitLJMDEW50aoEwg8nKnrStMwnwcWgtu7Jv6P2eSeogNO2ShRpWZrZlhE2ufEOPmnd2JYeK 3SGEzwLNtjcSwRjgQddWGjZT5c/fyySRiCK3WZfssB3smQlXJLaMtuhxZFdFspHQlKHtqgG8haJE 3Jt6hT1ESkskA3r/wl/S1so X-UI-Out-Filterresults: notjunk:1;V03:K0:qSHSn5Xw4nc=:jbS+xP2pwLy48NmVB2vgag boNR7TiUp/ea2JVIgdqrHItYU960qe6IPUNHUsH5YVi+hSdW6Jw/0Y1T3pGTt5YJIy4FzNWWC fYvhZB7Y+JadZ793h+XjGZBIOqFn9rK6SyGsvZVpiKdi7FwvYd/bPxCEpJZ79HcQ/56vFjtN3 x+mnRIcwGkciFoCXTdJJ55TTw7PF6vEQBoW4f470sjX1WuynODYuCGmAbOwgngAYTQSwN6JTu UpUblZ7tAsFaY4c3X+WUMaMQy81Au8rHmqvOKHhaXEIQgj6qlov2R3xTYAGzLEgGmDi8FofrD 3HyS9m/wpKCkYLNDKVHhXJ0Jt/0zKsaRXqmw1QXCiIbUC19ikvTs56L6bS9XkEvb3quyt1Bjr q1W9YqMt94A8QmKbvJU7pSEEc7AzblG1mLrsOF9U+FdPbqjq+c3XSLRVH4t2LFoGh0xkpj55t uamK1lQpd1avt0KSnGQj15ibXRWBLVa+pDGhUFANZ5+yBzS3LSLR54Gz2wRZhyrvvuJdm7ZL1 5qaW039/Z7IaRm0Dav3tIXl3v/Cp6c8OEQOiKIcVOSadS63JoexuFTT+OLBdZs7TByd/HI90Z mLX0slhXR1+iOkXmN3aAik5J0CvVzewWcZ Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/7/18 at 6:28 AM, Ard Biesheuvel wrote: > On Thu, 6 Dec 2018 at 19:05, Qian Cai wrote: > > > > On Thu, 2018-12-06 at 19:01 +0100, Ard Biesheuvel wrote: > > > On Thu, 6 Dec 2018 at 19:00, Catalin Marinas wrote: > > > > > > > > On Thu, Dec 06, 2018 at 11:16:33AM -0500, Qian Cai wrote: > > > > > unreferenced object 0xffff8096c1acf580 (size 128): > > > > > comm "swapper/63", pid 0, jiffies 4294937418 (age 1201.230s) > > > > > hex dump (first 32 bytes): > > > > > 80 87 b5 c1 96 00 00 00 00 00 cc c2 16 00 00 00 ................ > > > > > 00 00 01 00 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b ........kkkkkkkk > > > > > backtrace: > > > > > [<000000001d2549ba>] kmem_cache_alloc_trace+0x430/0x500 > > > > > [<0000000093a6dfab>] efi_mem_reserve_persistent+0x50/0xf8 > > > > > [<000000000a730828>] its_cpu_init_lpis+0x394/0x4b8 > > > > > [<00000000edf04e07>] its_cpu_init+0x104/0x150 > > > > > [<000000004d0342c5>] gic_starting_cpu+0x34/0x40 > > > > > [<000000005d9da772>] cpuhp_invoke_callback+0x228/0x1d68 > > > > > [<0000000061eace9b>] notify_cpu_starting+0xc0/0x118 > > > > > [<0000000048bc2dc5>] secondary_start_kernel+0x23c/0x3b0 > > > > > [<0000000015137d6a>] 0xffffffffffffffff > > > > > > > > > > efi_mem_reserve_persistent+0x50/0xf8: > > > > > kmalloc at include/linux/slab.h:546 > > > > > (inlined by) efi_mem_reserve_persistent at drivers/firmware/efi/efi.c:979 > > > > > > > > > > This line, > > > > > > > > > > rsv = kmalloc(sizeof(*rsv), GFP_ATOMIC); > > > > > > > > > > Kmemleak has a known limitation that can only track pointers in the kernel > > > > > virtual space. Hence, it will report false positives due to "rsv" will > > > > > only > > > > > reference to other physical addresses, > > > > > > > > > > rsv->next = efi_memreserve_root->next; > > > > > efi_memreserve_root->next = __pa(rsv); > > > > > > > > > > Signed-off-by: Qian Cai > > > > > > > > Acked-by: Catalin Marinas \ > > > > > > I don't see the patch and I wasn't cc'ed > > > > That is strange. Please see, > > > > https://lore.kernel.org/lkml/1543517152-23969-1-git-send-email-cai@gmx.us/ > > OK, I found it in my spam folder, apologies for that. > > This kmalloc() will be replaced in the next merge window by a call to > __get_free_page(). Does kmemleak still require the kmemleak_ignore() > for that case? Or is it only for kmalloc()? Looks like kmemleak won’t be able to track page allocation, so it should be fine then without kmemleak_ignore().