RE: memleak on efi_enter_virtual_mode()

["Zhang, Tianfei" <tianfei.zhang@xxxxxxxxx>]

Hi dy:
When free the memory ( efi_runtime_map) krealloc in save_runtime_map() function?

Hi all:

We are using Linux-3.14 for Android device, we found that it is a memleak on efi_enter_virtual_mode() by kmemleak checking.
Anyone would like to give some suggestion?

Best,
tianfei


root@latte:/ # cat /sys/kernel/debug/kmemleak                                  
unreferenced object 0xffff88007a05b400 (size 1024):
  comm "swapper/0", pid 0, jiffies 4294667647 (age 73.936s)
  hex dump (first 32 bytes):
    06 00 00 00 00 00 00 00 00 00 01 7b 00 00 00 00  ...........{....
    00 00 61 fe fe ff ff ff 4c 00 00 00 00 00 00 00  ..a.....L.......
  backtrace:
    [<ffffffff81990f9e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff8119b119>] __kmalloc_track_caller+0xb9/0x4c0
    [<ffffffff8116d60f>] krealloc+0x4f/0xa0
    [<ffffffff8224396b>] efi_enter_virtual_mode+0x229/0x49a
    [<ffffffff8222ee6a>] start_kernel+0x3d5/0x466
    [<ffffffff8222e5ad>] x86_64_start_reservations+0x2a/0x2c
    [<ffffffff8222e6a5>] x86_64_start_kernel+0xf6/0xf9
[<ffffffffffffffff>] 0xffffffffffffffff


(gdb) file out/target/product/cht/linux/kernel/cht/vmlinux
Load new symbol table from "/home/figo/work/android/cherrytrail/cht/out/target/product/lat/linux/kernel/cht/vmlinux"? (y or n) y
Reading symbols from /home/figo/work/android/cherrytrail/cht/out/target/product/lat/linux/kernel/cht/vmlinux...done.
(gdb) l *efi_enter_virtual_mode+0x229
0xffffffff8224396b is at /home/figo/work/android/cherrytrail/cht/kernel/cht/arch/x86/platform/efi/efi.c:909.
904                     if (!(md->attribute & EFI_MEMORY_RUNTIME) ||
905                         (md->type == EFI_BOOT_SERVICES_CODE) ||
906                         (md->type == EFI_BOOT_SERVICES_DATA))
907                            continue;
908                    tmp = krealloc(q, (count + 1) * memmap.desc_size, GFP_KERNEL);
909                     if (!tmp)
910                            goto out;
911                     q = tmp;
912       
913                     memcpy(q + count * memmap.desc_size, md, memmap.desc_size);
(gdb)


> -----Original Message-----
> From: Fleming, Matt
> Sent: Monday, August 24, 2015 7:01 PM
> To: Zhang, Tianfei
> Cc: dyoung@xxxxxxxxxx; bp@xxxxxxx; mingo@xxxxxxxxxx
> Subject: Re: memleak on efi_enter_virtual_mode()
> 
> Folks, please take this to the mailing list (linux-efi@xxxxxxxxxxxxxxx) so that
> other people can join in and benefit from the discussion.
> 
> On Mon, 2015-08-24 at 11:40 +0100, Zhang, Tianfei wrote:
> > When free the memory ( efi_runtime_map) krealloc in save_runtime_map()
> function?
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: dyoung@xxxxxxxxxx [mailto:dyoung@xxxxxxxxxx]
> > > Sent: Monday, August 24, 2015 1:56 PM
> > > To: Zhang, Tianfei
> > > Cc: Fleming, Matt; bp@xxxxxxx; mingo@xxxxxxxxxx
> > > Subject: Re: memleak on efi_enter_virtual_mode()
> > >
> > > On 08/22/15 at 01:06am, Zhang, Tianfei wrote:
> > > > Hi all:
> > > >
> > > > We are using Linux-3.14 for Android device, we found that it is a
> > > > memleak
> > > on efi_enter_virtual_mode() by kmemleak checking.
> > > > Would you like to help to give some suggestion about it?
> > > >
> > > > Best,
> > > > tianfei
> > > >
> > > >
> > > > root@latte:/ # cat /sys/kernel/debug/kmemleak unreferenced object
> > > > 0xffff88007a05b400 (size 1024):
> > > >   comm "swapper/0", pid 0, jiffies 4294667647 (age 73.936s)
> > > >   hex dump (first 32 bytes):
> > > >     06 00 00 00 00 00 00 00 00 00 01 7b 00 00 00 00  ...........{....
> > > >     00 00 61 fe fe ff ff ff 4c 00 00 00 00 00 00 00  ..a.....L.......
> > > >   backtrace:
> > > >     [<ffffffff81990f9e>] kmemleak_alloc+0x4e/0xb0
> > > >     [<ffffffff8119b119>] __kmalloc_track_caller+0xb9/0x4c0
> > > >     [<ffffffff8116d60f>] krealloc+0x4f/0xa0
> > > >     [<ffffffff8224396b>] efi_enter_virtual_mode+0x229/0x49a
> > > >     [<ffffffff8222ee6a>] start_kernel+0x3d5/0x466
> > > >     [<ffffffff8222e5ad>] x86_64_start_reservations+0x2a/0x2c
> > > >     [<ffffffff8222e6a5>] x86_64_start_kernel+0xf6/0xf9
> > > > [<ffffffffffffffff>] 0xffffffffffffffff
> > > >
> > > >
> > > > (gdb) file out/target/product/latte/linux/kernel/cht/vmlinux
> > > > Load new symbol table from
> > > >
> > > "/home/figo/work/android/cherrytrail/xiaomi/out/target/product/latte
> > > /linu x/kernel/cht/vmlinux"? (y or n) y Reading symbols from
> > > /home/figo/work/android/cherrytrail/xiaomi/out/target/product/latte/
> > > linux
> > > /kernel/cht/vmlinux...done.
> > > > (gdb) l *efi_enter_virtual_mode+0x229 0xffffffff8224396b is at
> > > /home/figo/work/android/cherrytrail/xiaomi/kernel/cht/arch/x86/platf
> > > orm/
> > > efi/efi.c:909.
> > > > 904                     if (!(md->attribute &
> EFI_MEMORY_RUNTIME)
> > > ||
> > > > 905                         (md->type ==
> EFI_BOOT_SERVICES_CODE)
> > > ||
> > > > 906                         (md->type ==
> EFI_BOOT_SERVICES_DATA))
> > > > 907                            continue;
> > > > 908                    tmp = krealloc(q, (count + 1) *
> > > memmap.desc_size, GFP_KERNEL);
> > > > 909                     if (!tmp)
> > > > 910                            goto out;
> > > > 911                     q = tmp;
> > > > 912
> > > > 913                     memcpy(q + count * memmap.desc_size,
> md,
> > > memmap.desc_size);
> > > > (gdb)
> > >
> > > I do not see problem in the code it should be a false positive
> > > report, The runtime maps are copied to krealloced buffer for kexec use.
> > >
> > > Thanks
> > > Dave
> 

��.n��������+%������w��{.n�����{����*jg��������ݢj����G�������j:+v���w�m������w�������h�����٥