> On May 10, 2021, at 2:17 AM, Reshetova, Elena <elena.reshetova@xxxxxxxxx> wrote: > > 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. > 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 call. > 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, 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 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 on unrelated 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 from two different kernel versions and there are some minute changes, are you just trying to avoid retriaging things in unchanged code only? That might be quite a burden if you have lots of false positives, for example.
