linux-kernel - Re: How to analyze kmemleak message?

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]

Date:	Mon, 23 Feb 2009 20:29:00 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To:	catalin.marinas@....com, penberg@...helsinki.fi
Cc:	linux-kernel@...r.kernel.org
Subject: Re: How to analyze kmemleak message?

Hello.

Thank you for explanation.

Catalin Marinas wrote:
> As Pekka said, they refer to the place where the object was allocated.
OK. The trace shows where that memory was allocated.

> This object can no longer be found to be referred by other objects or
> from the data section, hence it is assumed to be a leak (it could, as
> well, be a false positive, transient or not).
Kmemleak scans all data section for addresses returned by kmalloc() etc.

  void *p1;
  
  void foo(void)
  {
      void *p2 = kmalloc(1, GFP_KERNEL);
      p1 = kmalloc(1, GFP_KERNEL);
  }

"p1" will be reported by default.
To report "p2", we need to write "stack=on" to /sys/kernel/debug/kmemleak .
Is this correct?

> Basically, you need check
> where the pointer returned by kmalloc/kmem_cache_alloc etc. should be
> stored and whether it can still be referred from that place (or a
> different one) later.
> 
> Kmemleak tries to avoid the reporting of transient leaks by only
> reporting objects with a life time of more than 5 seconds.
kjournald's commit interval (default to 5 sec?) + a few seconds
might be better. (No reason. Just my feeling.)

> To make sure
> the reports you got aren't transient leaks, you can read
> the /sys/kernel/debug/kmemleak file a few times to see whether they
> disappear.
Well, I couldn't check /sys/kernel/debug/kmemleak etc. because
I couldn't reach login prompt.

> There is a Documentation/kmemleak.txt file where you may find some
> useful information.
I see.

I have a question. My module uses kmalloc(PATH_MAX, GFP_KERNEL) which
won't be released by kfree(). I count up how many bytes are allocated but
I don't want kmemleak to report such memory as memory leaks.
Can I do so by

  void bar(void)
  {
      static void *p;
      if (!p) {
          p = kmalloc(PATH_MAX, GFP_KERNEL);
          kmemleak_not_leak(p);
      }
      ...
  }

(or kmemleak_ignore() (which one to use and how to use))?

Regards.
--
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/