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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_NONE,USER_AGENT_SANE_1 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 B5A57C48BDF for ; Tue, 15 Jun 2021 08:12:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6057F61419 for ; Tue, 15 Jun 2021 08:12:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6057F61419 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id BE87E6B0036; Tue, 15 Jun 2021 04:12:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B976E6B006E; Tue, 15 Jun 2021 04:12:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A10E36B0070; Tue, 15 Jun 2021 04:12:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id 705416B0036 for ; Tue, 15 Jun 2021 04:12:11 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 09C868249980 for ; Tue, 15 Jun 2021 08:12:11 +0000 (UTC) X-FDA: 78255240462.15.DDD510F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id 53C1B6000144 for ; Tue, 15 Jun 2021 08:12:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623744730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zkFswLa16HS+1rAmPsXuA9PEyCn4dKv5EonI+IJkKKQ=; b=IDf/lqqSoM/U6jB9ac6UZSTpUvJk9OIeAwKe+fItVOc2P4Hx8KHHBoXoboYELXmFR25vou 6L9z/+wKdTqdyE/O3g0oGH7EF0FIaq57yDFHei6qfnbtsO+drPTHjM5PunxLaJZ2w6sNSb naMTFBblmKwj2gq4CHDX2GFByIuZCsM= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-184-vkkZ5OOINZafdx8bvfXKsg-1; Tue, 15 Jun 2021 04:12:08 -0400 X-MC-Unique: vkkZ5OOINZafdx8bvfXKsg-1 Received: by mail-wm1-f71.google.com with SMTP id t11-20020a05600c198bb02901bf95ba8642so227370wmq.3 for ; Tue, 15 Jun 2021 01:12:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=zkFswLa16HS+1rAmPsXuA9PEyCn4dKv5EonI+IJkKKQ=; b=g9Mzsf0dASw//fidefbGATRg1t9Os1/J+/2vMpX0zFaxMYGyl6/ZvuenfLcbGqI1G6 h0qUIghYV1E4m/P+9uXAEsuZBhDhbKrXnP1INh2kQ8XRl+KUl1Ogai4bETAyyQuhlo6v oBwZgIl3156bgpuLgAerxhscMc3DkB1bPhIgWGuAlDVZ6T80psb0tDLWbqwfuACiEhEC pxnu7jD9CabLLWmqaQ3AOpITraN5nreB6pynrxzKxTBTTmKanV932CkjU06ZxKnvEN1B jODJIs70CPbojP7K6rhDoKLloW3tRYLDiMAePLTpKlw/LqEUNKvCGAw1RpRVfSMoTz9H Aj1A== X-Gm-Message-State: AOAM530Vfxtm3lwGNfxPp+Nr4E9k2v+wFi8HMCGX/QGSAVQfTz359uOx jrBtzJPs4X2Q4U8GG/F479YdWyKj8ewptD3e6FWbmYwXvbofwdD+g6B1ZVLig9BGTKZPDwcgpBL RXtAc6orDIdY= X-Received: by 2002:adf:a191:: with SMTP id u17mr23646155wru.150.1623744727491; Tue, 15 Jun 2021 01:12:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx9ewGkGMrN8irtKlU0AgoLfsPXPeWdncDLrNCXaTB9Ps384HUoujSkTJh97Njpm8/B2PrHWQ== X-Received: by 2002:adf:a191:: with SMTP id u17mr23646138wru.150.1623744727299; Tue, 15 Jun 2021 01:12:07 -0700 (PDT) Received: from [192.168.3.132] (p5b0c6136.dip0.t-ipconnect.de. [91.12.97.54]) by smtp.gmail.com with ESMTPSA id n1sm15089943wms.18.2021.06.15.01.12.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jun 2021 01:12:07 -0700 (PDT) To: Rustam Kovhaev , Catalin Marinas , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, dvyukov@google.com, gregkh@linuxfoundation.org References: From: David Hildenbrand Organization: Red Hat Subject: Re: kmemleak memory scanning Message-ID: Date: Tue, 15 Jun 2021 10:12:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="IDf/lqqS"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf09.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Stat-Signature: s3kojfea1mx9tikx6ifm4yomku4a37ud X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 53C1B6000144 X-HE-Tag: 1623744725-822732 Content-Transfer-Encoding: quoted-printable 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 14.06.21 22:31, Rustam Kovhaev wrote: > hello Catalin, Andrew! >=20 > 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. Hi, See below regarding documentation. > apologies if some of the questions do not make sense, i am still going > through kmemleak code.. >=20 > 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? I looked into this a while ago to see which parts of the kernel end up=20 reading random physical page content and was happy to see that kmemleak=20 does *not* scan random physical memory :) We have to be very careful when reading random physical page content,=20 especially in virt environments this is really undesired, or when=20 dealing with memory holes, memory with problematic semantics like gart=20 memory ... The doc (Documentation/dev-tools/kmemleak.rst) states "Page allocations=20 and ioremap are not tracked.", which includes the alloc_page() example=20 you gave I think. --=20 Thanks, David / dhildenb