From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-mw2nam10on2056.outbound.protection.outlook.com ([40.107.94.56]:19552 "EHLO NAM10-MW2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S230056AbhEJHAc (ORCPT ); Mon, 10 May 2021 03:00:32 -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=UNVKGmrW4/dQSo/llbIJl2febOuGhJMeEZi9u/AdiYk=; b=2581aywAq0Gwe2rZqXfQiKsY7f68uv0hfDsOGOG3rCzLOe4uS6FBra956BLfk7n47g0Kz15GJUgduRpJkgCfq7c5XhB8AJoZP5G7zug0mz77JyFYbUpSEUyVg4f2v8Lus74MVxQ4OtpM/ErYaX/Af7VnuUv37RNsa+gaSAfb3ps= From: Oleg Drokin Subject: Re: Smatch mailing list archives Date: Mon, 10 May 2021 06:59:24 +0000 Message-ID: <1880256A-6D72-4EFC-84FE-8BD8FDC85095@whamcloud.com> References: <20210508051626.GI1955@kadam> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <82D14E24ACCA024F95552AEB481C3D13@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 2:17 AM, Reshetova, Elena = wrote: >=20 > What is the best way to create identifiers for the findings that certain = smatch > pattern finds in the kernel? Let's say I have a new pattern that is able = to find > different problematic places and report them in usual smatch way: errors = and > warnings with file name, line number, function name, etc.=20 > Now for our pattern in order to be sure that the reported issue exists/do= es not > exists, somebody needs to go and look at the code manually and make a cal= l.=20 > After this, it would be nice to mark this place as safe/concern in the re= port and be > able to transfer these results for kernel versions bumps (5.11->5.12, etc= .) as soon as > the code in this function where finding was reported has not changed (and= there > might be multiple findings per function). When I was doing a similar thing to integrate smatch into gerrit, I decided= 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 good = enough? Function name, whatever variable or the message there is and such is used t= o 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 on u= nrelated review requests) Seems to be working well though I am sure might not be super perfect. In the end I guess your end goal is unclear? Once you have those results fr= om two different kernel versions and there are some minute changes, are you just t= rying to avoid retriaging things in unchanged code only? That might be quite a burde= n if you have lots of false positives, for example.=