> > 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. I don't think this would be good enough for our case, since what we essentially looking for with smatch is a set of function calls to a specific functions. So, I end up with smth like: drivers/vme/boards/vme_vmivme7805.c:69 vmic_probe() warn: read using function 'ioread32' to an int type local variable 'data', type is uint drivers/vme/boards/vme_vmivme7805.c:74 vmic_probe() warn: read using function 'ioread32' to an int type local variable 'data', type is uint The two above items are in the same function vmic_probe(), making the same function call " ioread32" and writing down the result of this function call into the same var 'data'. They just happen to do this in two different places in vmic_probe function. 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. > > 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. Yes, I want to avoid retriaging the things that have been triaged before and if the code has not been changed within the single function. Best Regards, Elena.
