From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-mw2nam12on2053.outbound.protection.outlook.com ([40.107.244.53]:32736 "EHLO NAM12-MW2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S243623AbhEJOOm (ORCPT ); Mon, 10 May 2021 10:14:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=whamcloud.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LbsMFqamyaXPQ+t9ZeM0wuVZoApG72JXblEQAiVOwR0=; b=t+xa0jfFcexdM74FIXryd3XMJGa5kxRegWw/eppj1x59pEEcV4iUD2QHeB8UzWqu0/9J179oYmmDQsJ0daWquKSpnKL0baeHBElZXpu/5IzYxmp0oNQfxnpDcbGzGWewYoQLNh73Hpa7d/Xw8dTxUtrWwFMWsdmu99OPSzNhLDM= From: Oleg Drokin Subject: Re: Smatch mailing list archives Date: Mon, 10 May 2021 14:13:30 +0000 Message-ID: References: <20210508051626.GI1955@kadam> <1880256A-6D72-4EFC-84FE-8BD8FDC85095@whamcloud.com> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <506BE95056234A439FDA6A72723D1A03@namprd19.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 List-ID: To: "Reshetova, Elena" Cc: Dan Carpenter , "smatch@vger.kernel.org" , "Kleen, Andi" > On May 10, 2021, at 5:31 AM, Reshetova, Elena = wrote: >=20 >>> On May 10, 2021, at 2:17 AM, Reshetova, Elena >> wrote: >>>=20 >>> What is the best way to create identifiers for the findings that certai= n smatch >>> pattern finds in the kernel? Let's say I have a new pattern that is abl= e to find >>> different problematic places and report them in usual smatch way: error= s and >>> warnings with file name, line number, function name, etc. >>> Now for our pattern in order to be sure that the reported issue exists/= does not >>> exists, somebody needs to go and look at the code manually and make a c= all. >>> After this, it would be nice to mark this place as safe/concern in the = report and be >>> able to transfer these results for kernel versions bumps (5.11->5.12, e= tc.) as soon >> as >>> the code in this function where finding was reported has not changed (a= nd there >>> might be multiple findings per function). >>=20 >> When I was doing a similar thing to integrate smatch into gerrit, I deci= ded that >> line numbers are too unreliable a metric to really depend on. >> Instead for most cases just using the rest of the message seems to be go= od enough? >> Function name, whatever variable or the message there is and such is use= d to filter >> out >> known failures (two kinds: false positives and actual bugs that need to = be fixed, but >> are yet unfixed so no point in alerting people to them again and again o= n unrelated >> review requests) >>=20 >> Seems to be working well though I am sure might not be super perfect. >=20 > I don't think this would be good enough for our case, since what we essen= tially looking=20 > for with smatch is a set of function calls to a specific functions. So, I= end up with=20 > smth like: >=20 > drivers/vme/boards/vme_vmivme7805.c:69 vmic_probe() warn: read using func= tion > 'ioread32' to an int type local variable 'data', type is uint > drivers/vme/boards/vme_vmivme7805.c:74 vmic_probe() warn: read using func= tion > 'ioread32' to an int type local variable 'data', type is uint >=20 > The two above items are in the same function vmic_probe(), making the sam= e function > call " ioread32" and writing down the result of this function call into t= he same var 'data'. > They just happen to do this in two different places in vmic_probe functio= n.=20 > So, essentially they are even exactly the same lines in this case and the= only difference is > relative line position within the analyzed vmic_probe() function.=20 So is your concern that one of those warnings might be a real bug while ano= ther one is not? Because if they both are correct or both are incorrect seemingly it does not matter (for filtering purposes) that you have two instead of on= e?