From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35346 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232299AbiCJJn6 (ORCPT ); Thu, 10 Mar 2022 04:43:58 -0500 Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75AF362A2C for ; Thu, 10 Mar 2022 01:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : content-type : content-transfer-encoding : in-reply-to : mime-version; s=corp-2021-07-09; bh=meCHUHrgru/hrsflKR2a3YZbJc5xE/W+rJNBstQCqI0=; b=gjDLkOWWVsM2sZQXuSjnV7PBGz5N81Q3qyzrji6n9YyLIahKs2Cg4P1FkecGl/sZYfPn aPFeqRCM3IG7YMHkTRB07Dwilq4AtW0db8+ABJm5Jm3DAB56MePEz2ivG0gHVZD7wJCL CzZDIQVd3kZY3RRiMv+38JnMmmHO44MTwfJLJeZc2tyuH/hHlfKW//w4sw0pL8QEfSPy GSkNiwv+9L+sipTqTW73iKg3aIQfl1eTiboMy17DmX5IN6YXfw/0zXBGV5/lC+9zG2qS p25PiNuPher/FSJaOQPkw2qGL0IKxBHUOkec7ENCpWAsgCa/Zq2H1j3qAsysKkDBM5RH Ow== 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=meCHUHrgru/hrsflKR2a3YZbJc5xE/W+rJNBstQCqI0=; b=QlWHZTGypk6yo22N2rYTh/kieIasfGpEqVxa1GBjNXsYneZ2Rzc20SWB0TEueYryyW/ySbW+EyRe9E+HaCNz/dD3rYUEpcqNmWGP4xrQWxXvmlp7iHzU30b4bQshFuQboGtmUD8bZwOC44tpSBbPwple9wjjRRT59Tj92v07ur4= Date: Thu, 10 Mar 2022 12:42:35 +0300 From: Dan Carpenter Subject: Re: alloc_page leaks tracing Message-ID: <20220310094235.GH3293@kadam> References: <1E9B599B-743A-4327-A36A-9DB2AE9E6E51@linuxhacker.ru> Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1E9B599B-743A-4327-A36A-9DB2AE9E6E51@linuxhacker.ru> MIME-Version: 1.0 List-ID: To: Oleg Drokin Cc: smatch@vger.kernel.org On Tue, Mar 08, 2022 at 12:28:59PM -0500, Oleg Drokin wrote: > Hello! > > I am wondering why alloc_page and friends are not considering an allocation function? > Found a bit of code where there was an obvious alloc_page leak that was not caught that is caught if I change alloc_page to kmalloc. > > And while trying to put the support into smatch I suddenly found the structure changed so much from the previous time I looked at it it’s very non-obvious how to add it. > > I tried adding hooks in check_free_strict.c, check_frees_argument.c, check_leaks.c, smatch_constraints_required.c, smatch_fresh_alloc.c, smatch_parse_call_math.c > and tried to insert it alongside kmalloc in smatch_scripts/gen_allocation_list.sh and I still cannot make > it work in the actual kernel code even though a modified testcase from validation/sm_memory.c works. > > > Any hint? The check_leaks.c function is really limitted in the type of leaks it looks for. It has basically no false positives, but misses 90% of bugs. If you're looking for leaks the right place to add it is probably in check_unwind.c. regards, dan carpenter diff --git a/check_unwind.c b/check_unwind.c index 569792ad5a57..7ef040d2ca59 100644 --- a/check_unwind.c +++ b/check_unwind.c @@ -92,6 +92,10 @@ static struct ref_func_info func_table[] = { { "ieee80211_alloc_hw", ALLOC, -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval }, { "ieee80211_free_hw", RELEASE, 0, "$" }, + + { "alloc_pages", ALLOC, -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval }, + { "__get_free_pages", ALLOC, -1, "$", &valid_ptr_min_sval, &valid_ptr_max_sval }, + { "free_pages", RELEASE, 0, "$" }, }; static struct smatch_state *unmatched_state(struct sm_state *sm)