From patchwork Wed May 30 11:42:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chunyu Hu X-Patchwork-Id: 10438745 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 197F8601E9 for ; Wed, 30 May 2018 11:43:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 110242897B for ; Wed, 30 May 2018 11:43:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 058F72897E; Wed, 30 May 2018 11:43:05 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00, MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3FE942897D for ; Wed, 30 May 2018 11:43:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F27306B0006; Wed, 30 May 2018 07:43:02 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id ED6736B026F; Wed, 30 May 2018 07:43:02 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DC6E26B0271; Wed, 30 May 2018 07:43:02 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-ot0-f200.google.com (mail-ot0-f200.google.com [74.125.82.200]) by kanga.kvack.org (Postfix) with ESMTP id AE9AC6B0006 for ; Wed, 30 May 2018 07:43:02 -0400 (EDT) Received: by mail-ot0-f200.google.com with SMTP id 106-v6so11481080otg.22 for ; Wed, 30 May 2018 04:43:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:date:from :reply-to:to:cc:message-id:in-reply-to:references:subject :mime-version:content-transfer-encoding:thread-topic:thread-index; bh=T+orc/eewykWanJtvR23c8yLQVOT3aruCiDPxrA7h3M=; b=dTER/straBTaUQooelBSP3Xl3VFgJT6KqPsgs8w6zkroQi8Mu22FCpLKN3Iic+upcn 85gsWgG4gnoh0HH510v541/Uy2ZrsQ7nuptW1/0PKtsVhUTrnj6mkieDFWZ030+tijRq wswFXFbVKLoI2viuX5a2Hks+VGJr2uMWHgrb4N0m7FqSEQIrhI7QbqtzBtsbzp/1x9xn FSv0u3+syafARpchFhf8nTQKtt7hgdIqoltJ9Zv0H1uujz9EK7CNF9qCEmrIppvi4bwW WvVUqlffUucSMjP7ZGyIUGoNT1QpWlzm5taJ6VfHCvXtXM6ECgU+/9yJOEMqAvnWnWCO 6RBA== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of chuhu@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=chuhu@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com X-Gm-Message-State: APt69E3lxGSS4D5xo4e+y6FEfZRB9j7uKhmUfSQaVGRvytRHtzhS85lH CxYZLqvgqzn2P8qtpXlWdOmaDUf64aXspmbpiFb9Rv1jkWa1ZXEVlHj9XIEfvQFiLRI19foOphX QhVpXPkwvy9p5Dn9L9MmSTzrLF9kKg1cXijl8DbT8Bj/8wkc4Wj1r9ETg31Nylos9iw== X-Received: by 2002:a9d:25cf:: with SMTP id q73-v6mr1337434ota.207.1527680582435; Wed, 30 May 2018 04:43:02 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIR5qjveAMBn95X4eoUum2KV+TNt+r5KRpqpTnGjNkIbX79dDQuQ6VHMrocvG0gDCtPygNL X-Received: by 2002:a9d:25cf:: with SMTP id q73-v6mr1337405ota.207.1527680581501; Wed, 30 May 2018 04:43:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527680581; cv=none; d=google.com; s=arc-20160816; b=YEbmW+CBMz3wi+Dd6v68l6br5WM5XmOH278h1ENOenZb94d5GV7cE5dt4KLIMMZzth XJIivhmooyieyuj/q40V3tTHlvb1pVOHPX77Nptj/B5b8SSHVP4cuPr5752Tw0rB+HdA U6Hzmf/pmu1XTEcLtD93759iP0UcM+apz9BrtxgaVqPCP+mFu3pfYuTIo8rpHpICr5JT 1wsAeV1dPAsI8ZPV6Cy/PR6bg/JZefYzYdoK+SnjzsUn3C0v1T40O0xzZy1UQmqTmDzg 8bqZfHMIjvDPOhEGtvjn7mSded2Y57Wdf1zuVhdkhbaTHD5DwTuaEiSDRfCToe7R6Z0m FvWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=thread-index:thread-topic:content-transfer-encoding:mime-version :subject:references:in-reply-to:message-id:cc:to:reply-to:from:date :arc-authentication-results; bh=T+orc/eewykWanJtvR23c8yLQVOT3aruCiDPxrA7h3M=; b=Dpd9oRpguTJ1ytNhi9F2rT/gCvgPcDpIMYpovE2UcKvSG9whjCdSEYnLMbvGzA/3ki Wgqcyr0zBSgyvo2tnPBKQv44nvrXScvPt+RkMFEJ2nf3+ki21aC0I1tFgrvXEzYmnmi3 GjWcoh88OPhJkuaSjE1RT+xgwix5uyR0OiTHAZg25rhBQo8YalM61ev5YRhodVHxLpXx l78Im1GDwnxwhtGTW1iiqQssDHjsoznQLbN9TG42CnRIUdo4mgbGww9b7WeYRsABHfsB nezxWIaebc806PLdvJFK2rSJ8Bqu5MhS6YmEClb/pvsk2qhn0jqEcHAHTNnaC/x2Qu17 lfBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of chuhu@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=chuhu@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id u12-v6si13368717otu.61.2018.05.30.04.43.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 04:43:01 -0700 (PDT) Received-SPF: pass (google.com: domain of chuhu@redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; Authentication-Results: mx.google.com; spf=pass (google.com: domain of chuhu@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=chuhu@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9577731782B1; Wed, 30 May 2018 11:43:00 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8105C608EF; Wed, 30 May 2018 11:43:00 +0000 (UTC) Received: from zmail23.collab.prod.int.phx2.redhat.com (zmail23.collab.prod.int.phx2.redhat.com [10.5.83.28]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 14CD14BB78; Wed, 30 May 2018 11:43:00 +0000 (UTC) Date: Wed, 30 May 2018 07:42:59 -0400 (EDT) From: Chunyu Hu Reply-To: Chunyu Hu To: Michal Hocko Cc: Tetsuo Handa , malat@debian.org, dvyukov@google.com, linux-mm@kvack.org, catalin marinas , Akinobu Mita Message-ID: <1684479370.5483281.1527680579781.JavaMail.zimbra@redhat.com> In-Reply-To: <20180530104637.GC27180@dhcp22.suse.cz> References: <20180528132410.GD27180@dhcp22.suse.cz> <201805290605.DGF87549.LOVFMFJQSOHtFO@I-love.SAKURA.ne.jp> <1126233373.5118805.1527600426174.JavaMail.zimbra@redhat.com> <1730157334.5467848.1527672937617.JavaMail.zimbra@redhat.com> <20180530104637.GC27180@dhcp22.suse.cz> Subject: Re: [PATCH] kmemleak: don't use __GFP_NOFAIL MIME-Version: 1.0 X-Originating-IP: [10.68.5.41, 10.4.195.25] Thread-Topic: kmemleak: don't use __GFP_NOFAIL Thread-Index: jNkZpf29iE7XjgVWu4YUXEszv3bdTg== X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 30 May 2018 11:43:00 +0000 (UTC) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: X-Virus-Scanned: ClamAV using ClamSMTP ----- Original Message ----- > From: "Michal Hocko" > To: "Chunyu Hu" > Cc: "Tetsuo Handa" , malat@debian.org, dvyukov@google.com, linux-mm@kvack.org, > "catalin marinas" > Sent: Wednesday, May 30, 2018 6:46:37 PM > Subject: Re: [PATCH] kmemleak: don't use __GFP_NOFAIL > > On Wed 30-05-18 05:35:37, Chunyu Hu wrote: > [...] > > I'm trying to reuse the make_it_fail field in task for fault injection. As > > adding > > an extra memory alloc flag is not thought so good, I think adding task > > flag > > is either? > > Yeah, task flag will be reduced to KMEMLEAK enabled configurations > without an additional maint. overhead. Anyway, you should really think > about how to guarantee trackability for atomic allocation requests. You > cannot simply assume that GFP_NOWAIT will succeed. I guess you really Sure. While I'm using task->make_it_fail, I'm still in the direction of making kmemleak avoid fault inject with task flag instead of page alloc flag. > want to have a pre-populated pool of objects for those requests. The > obvious question is how to balance such a pool. It ain't easy to track > memory by allocating more memory... This solution is going to make kmemleak trace really nofail. We can think later. while I'm thinking about if fault inject can be disabled via flag in task. Actually, I'm doing something like below, the disable_fault_inject() is just setting a flag in task->make_it_fail. But this will depend on if fault injection accept a change like this. CCing Akinobu [1] http://lkml.kernel.org/r/1524243513-29118-1-git-send-email-chuhu@redhat.com [2] http://lkml.kernel.org/r/CA+7wUswp_Sr=hHqi1bwRZ3FE2wY5ozZWZ8Z1BgrFnSAmijUKjA@mail.gmail.com [3] commit d9570ee3bd1d ("kmemleak: allow to coexist with fault injection") +#define disable_fault_inject() \ +do { \ + unsigned long flag; \ + local_irq_save(flag); \ + if (in_irq()) \ + current->make_it_fail |= HARDIRQ_NOFAULT_OFFSET; \ + else \ + current->make_it_fail |= TASK_NOFAULT_OFFSET; \ + local_irq_restore(flag); \ +} while (0) > > -- > Michal Hocko > SUSE Labs > --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -111,6 +111,7 @@ #include #include #include +#include /* * Kmemleak configuration and common defines. @@ -126,7 +127,7 @@ /* GFP bitmask for kmemleak internal allocations */ #define gfp_kmemleak_mask(gfp) (((gfp) & (GFP_KERNEL | GFP_ATOMIC)) | \ __GFP_NORETRY | __GFP_NOMEMALLOC | \ - __GFP_NOWARN | __GFP_NOFAIL) + __GFP_NOWARN) /* scanning area inside a memory block */ struct kmemleak_scan_area { @@ -551,12 +552,15 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size, struct kmemleak_object *object, *parent; struct rb_node **link, *rb_parent; + disable_fault_inject(); object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp)); if (!object) { pr_warn("Cannot allocate a kmemleak_object structure\n"); kmemleak_disable(); + enable_fault_inject(); return NULL; } + enable_fault_inject(); INIT_LIST_HEAD(&object->object_list); INIT_LIST_HEAD(&object->gray_list);