From: Michal Hocko <mhocko@suse.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Chunyu Hu <chuhu@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
malat@debian.org, Linux-MM <linux-mm@kvack.org>,
Akinobu Mita <akinobu.mita@gmail.com>
Subject: Re: [PATCH] kmemleak: don't use __GFP_NOFAIL
Date: Mon, 4 Jun 2018 14:42:10 +0200 [thread overview]
Message-ID: <20180604124210.GQ19202@dhcp22.suse.cz> (raw)
In-Reply-To: <CACT4Y+ZE_qbnqzjnhbrk=vhLqijKZ5x1QbtbJSyNuqA3htFgFA@mail.gmail.com>
On Mon 04-06-18 10:41:39, Dmitry Vyukov wrote:
[...]
> FWIW this problem is traditionally solved in dynamic analysis tools by
> embedding meta info right in headers of heap blocks. All of KASAN,
> KMSAN, slub debug, LeakSanitizer, asan, valgrind work this way. Then
> an object is either allocated or not. If caller has something to
> prevent allocations from failing in any context, then the same will be
> true for KMEMLEAK meta data.
>
This makes much more sense, of course. I thought there were some
fundamental reasons why kmemleak needs to have an off-object tracking
which makes the whole thing much more complicated of course.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2018-06-04 12:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-26 7:14 WARNING: CPU: 0 PID: 21 at ../mm/page_alloc.c:4258 __alloc_pages_nodemask+0xa88/0xfec Mathieu Malaterre
2018-05-28 8:34 ` Michal Hocko
2018-05-28 13:05 ` [PATCH] kmemleak: don't use __GFP_NOFAIL Tetsuo Handa
2018-05-28 13:24 ` Michal Hocko
2018-05-28 21:05 ` Tetsuo Handa
2018-05-29 13:27 ` Chunyu Hu
2018-05-29 13:46 ` Tetsuo Handa
2018-05-30 9:35 ` Chunyu Hu
2018-05-30 10:46 ` Michal Hocko
2018-05-30 11:42 ` Chunyu Hu
2018-05-30 12:38 ` Michal Hocko
2018-05-31 10:51 ` Chunyu Hu
2018-05-31 11:35 ` Michal Hocko
2018-05-31 12:28 ` Chunyu Hu
2018-05-31 15:22 ` Catalin Marinas
2018-05-31 18:41 ` Michal Hocko
2018-06-01 1:50 ` Chunyu Hu
2018-06-01 4:53 ` Chunyu Hu
2018-06-04 8:41 ` Dmitry Vyukov
2018-06-04 12:42 ` Michal Hocko [this message]
2018-06-04 15:08 ` Catalin Marinas
2018-06-04 15:36 ` Dmitry Vyukov
2018-06-04 16:41 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180604124210.GQ19202@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=akinobu.mita@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=chuhu@redhat.com \
--cc=dvyukov@google.com \
--cc=linux-mm@kvack.org \
--cc=malat@debian.org \
--cc=penguin-kernel@i-love.sakura.ne.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.