From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <smatch-owner@vger.kernel.org>
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51528 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S229437AbiCVIHL (ORCPT
        <rfc822;smatch@vger.kernel.org>); Tue, 22 Mar 2022 04:07:11 -0400
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5BF3422516
        for <smatch@vger.kernel.org>; Tue, 22 Mar 2022 01:05:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc
 : subject : message-id : references : content-type : in-reply-to :
 mime-version; s=corp-2021-07-09;
 bh=6vSj67yJN+JM5LtcnUZAPPSpV2+vBkHqaA46tqMW5P0=;
 b=ZcSX9kh1R26P2Neb04Kqr/5UDPssinJBciBG7z492BuYFVjict/Mr0+yjWI96vTAwaDx
 bblSUwAGRGS8mn9U2QD/tcgaP1QQgJy2/4w+WmTbqzIjejNK0lKi5lCAvRFhJJlp4nt9
 xN5d7t+mHtWI5MlmxJSemsA47XpGXggjDW6FNMCDEnKhdyJAxmh8BszFv9SxD8qaOPyc
 jVXBnRTc41rJgmZfLezUJ5YP2nw61SVVkAxH6zqxU8XmwW8ZPyBk/HTl9xB8P5nafCiG
 sl6eaifCyFnMJMOKs8RCEjbgj+CZmZvDuFtSbX4PdQVBdC6RHCaCaG9oF7Mkv5+ytgjD jw== 
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=6vSj67yJN+JM5LtcnUZAPPSpV2+vBkHqaA46tqMW5P0=;
 b=nHcoVfTPR5dGTV5Y0SHDLwWi4SwRn1H2T4U1XrFtNdH75c6Qe0aeR4cVBp5Sj1qngkr0vzYebVISiUB3h959CCyQgUTvGlor1GD8YlxeAwGUUFMjxVuxoKOiw9W+qmPJu8UelPF1Y0MLW9h94IlGW3cnO9uj7iswx5HPGUCL2k4=
Date: Tue, 22 Mar 2022 11:05:13 +0300
From: Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: alloc_page leaks tracing
Message-ID: <20220322080513.GS336@kadam>
References: <1E9B599B-743A-4327-A36A-9DB2AE9E6E51@linuxhacker.ru>
 <20220310094235.GH3293@kadam>
 <82B7079C-AD17-4E5E-A245-71E9ED53E5A3@linuxhacker.ru>
 <20220311211215.GN3315@kadam>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220311211215.GN3315@kadam>
MIME-Version: 1.0
List-ID: <smatch.vger.kernel.org>
To: Oleg Drokin <green@linuxhacker.ru>
Cc: smatch@vger.kernel.org

I've pushed some changes to the check_unwind.c script so now the results
say which function allocated it.

I still haven't added the alloc_pages() and related functions to the
function table.  I need to do that.  I'm also still thinking about the
correct solution to the return_implies_param_key_exact() problem.  I
guess on my system, I just hardcoded the return values.  There is no
harm in pushing that so let me do that.

There are bunch of common false positives like:
1) put_device() frees the page.  I've been sort of working towards
   making put_device() handled in the correct way where we figure out
   what function it calls and parse the container_of() correctly and
   then it's all handled transparently by the check_kernel.c.  But for
   now probably the right thing is to add a special case to
   check_unwind.c.
2) Arrays.  Again, probably add a special case in check_unwind.c
3) Direct calls to a function which frees pointers from container_of().
   Eventually this will work correctly.  Another option for this would
   be to do what check_locking does and just record whenever a function
   frees something and then in the caller try to guess which resource
   it was based on the name.

So there is quite a bit of work which can be done still.

regards,
dan carpenter