From patchwork Mon Jun 14 20:31:14 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rustam Kovhaev X-Patchwork-Id: 12319909 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=-7.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 04967C2B9F4 for ; Mon, 14 Jun 2021 20:31:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AB32761246 for ; Mon, 14 Jun 2021 20:31:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AB32761246 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 4EC566B0070; Mon, 14 Jun 2021 16:31:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4C2866B0071; Mon, 14 Jun 2021 16:31:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 363486B0072; Mon, 14 Jun 2021 16:31:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 068E76B0070 for ; Mon, 14 Jun 2021 16:31:20 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A3FDD8415 for ; Mon, 14 Jun 2021 20:31:20 +0000 (UTC) X-FDA: 78253474320.04.84859D5 Received: from mail-pf1-f177.google.com (mail-pf1-f177.google.com [209.85.210.177]) by imf23.hostedemail.com (Postfix) with ESMTP id D2D13A000271 for ; Mon, 14 Jun 2021 20:31:12 +0000 (UTC) Received: by mail-pf1-f177.google.com with SMTP id a127so5653326pfa.10 for ; Mon, 14 Jun 2021 13:31:20 -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:mime-version:content-disposition; bh=X0Dlg1OxNcsAdJyU64IBe8AUMc5WPVAjSibLW2UVq4k=; b=u/rQ3fhLYXFiYDBOqpfaVdMnzxd6fBR1/DfmyScke8pC/ffiziSws6MXqcTVQQZ7Pb xahdwAoWXKtSEAlqGsLgALVYebwLyupy/HuZxqRXfvvrywcuxRrVBpr8cbhIK2RZ+KOS su0J3AXxY+d4MG2YPFAur8SPkUwZcDfmgAg2tm4RFINhvEkB08yu+bOSTwd4Dn9n8XYb 0kJpYABBJPz3pXA1sCDieibPiNaoERngiqXvtKqMPuoXXX4x3A2awSCVbark81IMBNlQ 7YyAkvQ42preQ+dkLuGuA3Go8xTWgD7ChBrH7tdU8MguIcW3CZeuwKqPSw3G7SsSVaMs sjWA== 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:mime-version :content-disposition; bh=X0Dlg1OxNcsAdJyU64IBe8AUMc5WPVAjSibLW2UVq4k=; b=ceGQCnoLsWTSRUbPQGIXiLpgDD1AVUjB2gt9ba1sjzbXmHjzE2eKOi273nRaoqGDRM hRcStPdhbBxPwFh1YxqRwKuYmWkERyrO8kaRmUGT531l4Beq5WV+CF1MWtxnVIJLOaKc wFD3+nVm/u8XtfIRKQ18lFH1PQUHEC8qbp2d78j961iUHw/wdOvkDMS1pbdpI08pa9gs V5K02vC7aWkVoszDWpvBSdCXxYexEl0XNmG2wXgM2L80UwOtA2Hel2F7nWxC6qhSQgUU qnGF/uBelC+dlaAMmFnuRKmbhdNXOPUnlL8SlzZsAJjAyi8cl0jwi/M8cM/IrgMsD7/2 yM/A== X-Gm-Message-State: AOAM533QsqE16uARgcZA5Ppw+Zl7bDm+NNKiufxbTAL24G/Sxm3y7Z3l vP9m+92jr1aan9coMgjUwUk= X-Google-Smtp-Source: ABdhPJxxitlMoVrI5knF2a1+7X2aj42K8fpVmke45+iVElm+Oq8nBXyo1LvwuMFm8Ibg1DnYsoOsiw== X-Received: by 2002:aa7:820d:0:b029:2f1:d22d:f21d with SMTP id k13-20020aa7820d0000b02902f1d22df21dmr767579pfi.7.1623702679195; Mon, 14 Jun 2021 13:31:19 -0700 (PDT) Received: from nuc10 (104.36.148.139.aurocloud.com. [104.36.148.139]) by smtp.gmail.com with ESMTPSA id r24sm301621pjz.11.2021.06.14.13.31.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 13:31:18 -0700 (PDT) Date: Mon, 14 Jun 2021 13:31:14 -0700 From: Rustam Kovhaev To: Catalin Marinas , Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, dvyukov@google.com, gregkh@linuxfoundation.org Subject: kmemleak memory scanning Message-ID: MIME-Version: 1.0 Content-Disposition: inline Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20161025 header.b="u/rQ3fhL"; spf=pass (imf23.hostedemail.com: domain of rkovhaev@gmail.com designates 209.85.210.177 as permitted sender) smtp.mailfrom=rkovhaev@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D2D13A000271 X-Stat-Signature: iwa4i91w9rfrkkzxj5c15c6ddeqxqwog X-HE-Tag: 1623702672-744771 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: 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? b) when kmemleak object gets created (kmemleak.c:598) it gets checksum of 0, by the time user requests kmemleak "scan" via debugfs the pointer will be most likely changed to some value by the kernel and during first scan kmemleak won't report the object as orphan even if it did not find any reference to it, because it will execute update_checksum() and after that will proceed to updating object->count (kmemleak.c:1502). and so the user will have to initiate a second "scan" via debugfs and only then kmemleak will produce the report. should we document this? below i am attaching a simplified reproducer for the false positive kmemleak report (a). i could have done it in the module, but i found it to be easier and faster to test when done in a syscall, so that i did not have to modprobe/modprobe -r. tyvm! --- arch/x86/entry/syscalls/syscall_64.tbl | 1 + include/linux/syscalls.h | 1 + mm/Makefile | 2 +- mm/kmemleak_test.c | 45 ++++++++++++++++++++++++++ 4 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 mm/kmemleak_test.c diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index ce18119ea0d0..da967a87eb78 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -343,6 +343,7 @@ 332 common statx sys_statx 333 common io_pgetevents sys_io_pgetevents 334 common rseq sys_rseq +335 common kmemleak_test sys_kmemleak_test # don't use numbers 387 through 423, add new calls after the last # 'common' entry 424 common pidfd_send_signal sys_pidfd_send_signal diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index 050511e8f1f8..0602308aabf4 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -1029,6 +1029,7 @@ asmlinkage long sys_statx(int dfd, const char __user *path, unsigned flags, unsigned mask, struct statx __user *buffer); asmlinkage long sys_rseq(struct rseq __user *rseq, uint32_t rseq_len, int flags, uint32_t sig); +asmlinkage long sys_kmemleak_test() asmlinkage long sys_open_tree(int dfd, const char __user *path, unsigned flags); asmlinkage long sys_move_mount(int from_dfd, const char __user *from_path, int to_dfd, const char __user *to_path, diff --git a/mm/Makefile b/mm/Makefile index bf71e295e9f6..878783838fa1 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -97,7 +97,7 @@ obj-$(CONFIG_CGROUP_HUGETLB) += hugetlb_cgroup.o obj-$(CONFIG_GUP_TEST) += gup_test.o obj-$(CONFIG_MEMORY_FAILURE) += memory-failure.o obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o -obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o +obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o kmemleak_test.o obj-$(CONFIG_DEBUG_RODATA_TEST) += rodata_test.o obj-$(CONFIG_DEBUG_VM_PGTABLE) += debug_vm_pgtable.o obj-$(CONFIG_PAGE_OWNER) += page_owner.o diff --git a/mm/kmemleak_test.c b/mm/kmemleak_test.c new file mode 100644 index 000000000000..828246e20b7f --- /dev/null +++ b/mm/kmemleak_test.c @@ -0,0 +1,45 @@ +// SPDX-License-Identifier: GPL-2.0+ + +#include +#include +#include +#include + +struct kmemleak_check { + unsigned long canary; + struct work_struct work; + struct page **pages; +}; + +static void work_func(struct work_struct *work) +{ + struct page **pages; + struct kmemleak_check *ptr; + + set_current_state(TASK_INTERRUPTIBLE); + schedule_timeout(3600*HZ); + + ptr = container_of(work, struct kmemleak_check, work); + pages = ptr->pages; + __free_page(pages[0]); + kvfree(pages); +} + +SYSCALL_DEFINE0(kmemleak_test) +{ + struct page **pages, *page; + struct kmemleak_check *ptr; + + pages = kzalloc(sizeof(*pages), GFP_KERNEL); + page = alloc_page(GFP_KERNEL); + pages[0] = page; + ptr = page_address(page); + ptr->canary = 0x00FF00FF00FF00FF; + ptr->pages = pages; + pr_info("DEBUG: pages %px page %px ptr %px\n", pages, page, ptr); + + INIT_WORK(&ptr->work, work_func); + schedule_work(&ptr->work); + + return 0; +}