All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chunyu Hu <chuhu@redhat.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Michal Hocko <mhocko@kernel.org>,
	Chunyu Hu <chuhu.ncepu@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask
Date: Wed, 25 Apr 2018 05:50:41 -0400 (EDT)	[thread overview]
Message-ID: <482146467.19754107.1524649841393.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <20180424134148.qkvqqa4c37l6irvg@armageddon.cambridge.arm.com>



----- Original Message -----
> From: "Catalin Marinas" <catalin.marinas@arm.com>
> To: "Michal Hocko" <mhocko@kernel.org>
> Cc: "Chunyu Hu" <chuhu.ncepu@gmail.com>, "Dmitry Vyukov" <dvyukov@google.com>, "Chunyu Hu" <chuhu@redhat.com>, "LKML"
> <linux-kernel@vger.kernel.org>, "Linux-MM" <linux-mm@kvack.org>
> Sent: Tuesday, April 24, 2018 9:41:48 PM
> Subject: Re: [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask
> 
> On Tue, Apr 24, 2018 at 07:20:57AM -0600, Michal Hocko wrote:
> > On Mon 23-04-18 12:17:32, Chunyu Hu wrote:
> > [...]
> > > So if there is a new flag, it would be the 25th bits.
> > 
> > No new flags please. Can you simply store a simple bool into
> > fail_page_alloc
> > and have save/restore api for that?
> 
> For kmemleak, we probably first hit failslab. Something like below may
> do the trick:
> 
> diff --git a/mm/failslab.c b/mm/failslab.c
> index 1f2f248e3601..63f13da5cb47 100644
> --- a/mm/failslab.c
> +++ b/mm/failslab.c
> @@ -29,6 +29,9 @@ bool __should_failslab(struct kmem_cache *s, gfp_t
> gfpflags)
>  	if (failslab.cache_filter && !(s->flags & SLAB_FAILSLAB))
>  		return false;
>  
> +	if (s->flags & SLAB_NOLEAKTRACE)
> +		return false;
> +
>  	return should_fail(&failslab.attr, s->object_size);
>  }

This maybe is the easy enough way for skipping fault injection for kmemleak slab object. 
 
>  
> 
> Can we get a second should_fail() via should_fail_alloc_page() if a new
> slab page is allocated?

looking at code path blow, what do you mean by getting a second should_fail() via
fail_alloc_page?  Seems we need to insert the flag between alloc_slab_page and 
alloc_pages()? Without GFP flag, it's difficult to pass info to should_fail_alloc_page
and keep simple at same time. 

Or as Michal suggested, completely disabling page alloc fail injection when kmemleak
enabled. And enable it again when kmemleak off. 

 alloc_slab_page   
          <========= flag to change the behavior of should_fail_alloc_page
     alloc_pages
         alloc_pages_current
             __alloc_pages_nodemask
                 prepare_alloc_pages
                     should_fail_alloc_page

> 
> --
> Catalin
> 

-- 
Regards,
Chunyu Hu

  reply	other threads:[~2018-04-25  9:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20 16:58 [RFC] mm: kmemleak: replace __GFP_NOFAIL to GFP_NOWAIT in gfp_kmemleak_mask Chunyu Hu
2018-04-20 17:50 ` Catalin Marinas
2018-04-20 17:52   ` Dmitry Vyukov
2018-04-22 12:51   ` Michal Hocko
2018-04-22 15:00     ` Dmitry Vyukov
2018-04-23  4:17       ` Chunyu Hu
2018-04-24 13:20         ` Michal Hocko
2018-04-24 13:41           ` Catalin Marinas
2018-04-25  9:50             ` Chunyu Hu [this message]
2018-04-25 12:51               ` Catalin Marinas
2018-04-25 14:33                 ` Chunyu Hu
2018-04-27 10:13                   ` Chunyu Hu
2018-04-24 16:48           ` Chunyu Hu
2018-04-24 17:02             ` Michal Hocko
2018-04-24 17:16               ` Dmitry Vyukov
2018-04-26 12:23               ` Chunyu Hu
2018-04-26 12:56                 ` Catalin Marinas
2018-04-27 10:17                   ` Chunyu Hu
2018-04-23  3:30   ` Chunyu Hu

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=482146467.19754107.1524649841393.JavaMail.zimbra@redhat.com \
    --to=chuhu@redhat.com \
    --cc=catalin.marinas@arm.com \
    --cc=chuhu.ncepu@gmail.com \
    --cc=dvyukov@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    /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.