From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19A1BC49EA6 for ; Thu, 24 Jun 2021 17:36:58 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9F315613E3 for ; Thu, 24 Jun 2021 17:36:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9F315613E3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8B13B6B0036; Thu, 24 Jun 2021 13:36:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 861846B005D; Thu, 24 Jun 2021 13:36:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 701C26B006C; Thu, 24 Jun 2021 13:36:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0133.hostedemail.com [216.40.44.133]) by kanga.kvack.org (Postfix) with ESMTP id 344F36B0036 for ; Thu, 24 Jun 2021 13:36:56 -0400 (EDT) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 5B19C1828FDD1 for ; Thu, 24 Jun 2021 17:36:56 +0000 (UTC) X-FDA: 78289322832.31.CDAF8F4 Received: from mail-pf1-f171.google.com (mail-pf1-f171.google.com [209.85.210.171]) by imf15.hostedemail.com (Postfix) with ESMTP id 1CAF8A000275 for ; Thu, 24 Jun 2021 17:36:55 +0000 (UTC) Received: by mail-pf1-f171.google.com with SMTP id a127so5776460pfa.10 for ; Thu, 24 Jun 2021 10:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=PeRKsgy74/XMQSubNA8psgjoWJKBQi8NTy2S1z7EZtA=; b=N/X8xyzRMvKBxZFAr3CR8HD6HGsZwVBeIe1wh3HdrE8VLQVtSsen5KkxX2ZdLIVwAT Ko+DoSRx662BsfDGZPoGFnWai4VGGC8J+GL8KPN/UKFYlAr96orvk5HXFA5kWJ45ZtpT t7GkirUt+ls5zr4SR2UZToo9tZ91JhYCzI2/QC96FkNcHfZEhXFg4/WY4J59U0TSTdxo q+NfcdszvkjEd9hzVIwNvYCWRDDydMgIUrf5oF+x6yuvhDB9WvmDXlrmJrvc82rdMc4s ea+njS9uyYa2eOeokpSTb66SogV6aLjpq02mSLTPc9R7V0TwgnsZYVZ/DlnBp2UdV1vx ei1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=PeRKsgy74/XMQSubNA8psgjoWJKBQi8NTy2S1z7EZtA=; b=LWbUThEKfoKuaCpkqQ2cpPHbElgvZsJm3XpMUbtT9CrG1xMkwzBQOxhQ8zFwGgR+tk mzh5yRo7x+O2HhtxuvtCAS6RY/p7S6Esc/6jjE60P1KFe4vBerOFrUfGG3cql8H1a5yM GApB/9BBnq+fll7m0InyUTTekPSYKCDUxD+4qbLvPv3O9Amsj4TXK/yA02XPaj3Qjecv ACYeK2n5VRnt8yskWTsgwpeVyY41jfWhx+NH+++FHB7UAgTDcSzBMO6JlSdHlajivqFP V+yFE8oKVpFMsBdhKjCbvvFuUb1Adtf+4g21O915VoxrIdk8AsTdA6c60QmfQZX2ptxv vBFw== X-Gm-Message-State: AOAM532dpevjtWGCleeRHboI0cabuR/Qr2i76FUMyoO9wqrgDCWWKo64 3SQQpN0vEBf+MkWZH+dPBM4= X-Google-Smtp-Source: ABdhPJxQicAOfILG7//WbS8jTvHjFyObfpk6flCAdE492wQCWFsR/cO1tsK16a0MK2WxvOVGGOAlRg== X-Received: by 2002:a63:5c04:: with SMTP id q4mr5637097pgb.127.1624556215056; Thu, 24 Jun 2021 10:36:55 -0700 (PDT) Received: from nuc10 (104.36.148.139.aurocloud.com. [104.36.148.139]) by smtp.gmail.com with ESMTPSA id y1sm3542572pfe.72.2021.06.24.10.36.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 10:36:54 -0700 (PDT) Date: Thu, 24 Jun 2021 10:36:50 -0700 From: Rustam Kovhaev To: Dmitry Vyukov Cc: Catalin Marinas , Andrew Morton , Linux-MM , LKML , Greg Kroah-Hartman Subject: Re: kmemleak memory scanning Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b="N/X8xyzR"; spf=pass (imf15.hostedemail.com: domain of rkovhaev@gmail.com designates 209.85.210.171 as permitted sender) smtp.mailfrom=rkovhaev@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: sku43u6ym9jy4yydo1sne5e9ufbfwc35 X-Rspamd-Queue-Id: 1CAF8A000275 X-Rspamd-Server: rspam06 X-HE-Tag: 1624556215-947378 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: On Wed, Jun 16, 2021 at 11:25:22AM -0700, Rustam Kovhaev wrote: > On Tue, Jun 15, 2021 at 07:15:24AM +0200, Dmitry Vyukov wrote: > > On Mon, Jun 14, 2021 at 10:31 PM Rustam Kovhaev wrote: > > > > > > hello Catalin, Andrew! > > > > > > while troubleshooting a false positive syzbot kmemleak report i have > > > noticed an interesting behavior in kmemleak and i wonder whether it is > > > behavior by design and should be documented, or maybe something to > > > improve. > > > apologies if some of the questions do not make sense, i am still going > > > through kmemleak code.. > > > > > > a) kmemleak scans struct page (kmemleak.c:1462), but it does not scan > > > the actual contents (page_address(page)) of the page. > > > if we allocate an object with kmalloc(), then allocate page with > > > alloc_page(), and if we put kmalloc pointer somewhere inside that page, > > > kmemleak will report kmalloc pointer as a false positive. > > > should we improve kmemleak and make it scan page contents? > > > or will this bring too many false negatives? > > > > Hi Rustam, > > > > Nice debugging! > > I assume lots of pages are allocated for slab and we don't want to > > scan the whole page if only a few slab objects are alive on the page. > > However alloc_pages() can be called by end kernel code as well. > > I grepped for any kmemleak annotations around existing calls to > > alloc_pages, but did not find any... > > Does it require an explicit kmemleak_alloc() after allocating the page > > and kmemleak_free () before freeing the page? > > hi Dmitry, thank you! > yes, as Catalin has pointed out, there are a few places where we call > kmemleak_alloc()/kmemleak_free() explicitly in order for the pages to be > scanned, like in blk_mq_alloc_rqs() > > > If there are more than one use case for this, I guess we could add > > some GFP flag for this maybe. > > and this way kernel users won't have to use kmemleak fuctions mentioned > above including some or most kmemleak_not_leak() calls and basically > kmemleak will be kind of "transparent" to them? and they will only need > to use the GFP flag to instruct kmemleak to scan the page contents? > it sounds like a good idea to me.. > i've been thinking about this and it seems like in the scenario where we want kmemleak to scan only some part of the page, we will have to either do separate alloc_page() calls with different flags or use kmemleak_scan_area() to limit the memory scan area. maybe this approach won't simplify things and will produce more code instead of reducing it