> On Mon, May 10, 2021 at 06:17:27AM +0000, Reshetova, Elena wrote: > > > On Fri, May 07, 2021 at 02:22:37PM +0000, Reshetova, Elena wrote: > > > > Hi, > > > > > > > > I have been working for a while now on a new smatch pattern, but > > > > would really appreciate additional information points such as past > > > > email discussions, etc. > > > > > > > > So I am wondering if there is a way to browse through > > > > the archives of this mailing list in order to try to find the > > > > information I need? > > > > > > Sorry, I don't think it's archived anywhere. There isn't a lot of > > > traffic on the list. About three times a year someone reports that > > > Smatch is crashing for them. > > > > > > I'm always happy to answer questions if there is any way I can help? > > > > Thank you Dan! I am pretty new with smatch so that's why I was > > hoping to browse through the existing mails to see if my simple questions > > are already answered, but here is my current issue. > > > > 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). > > > > What is the best way of doing it? > > I was first thinking of using some simple hash for the reported line (lines around, > relative > > position within the reported function), > > but now I think I need also to hash the whole function in addition to the finding > itself. > > > > Then the logic of transferring the result would be: > > > > For each finding calculate: > > 1. finding_line_hash: the hash of the line that resulted in finding (becomes a > unique id > > within the function). > > 2. finding_function_hash: the hash of the function that produced the finding > (becomes a > > unique global id within the kernel) and helps to determine if the function has not > been > > changed between the kernel versions. > > > > Logic for the result transfer: > > > > If both finding_line_hash and finding_function_hash match between the two > smatch reports > > for two different versions, then it is relatively safe to transfer this concrete smatch > finding > > and its manual audit result automatically. > > > > Does it make sense overall? If yes, what is the easiest way in smatch to get hash > data for > > 1 and 2? I.e. get full reported line as a string and full function content as a string? > > I use the a script smatch_scripts/new_bugs.pl It strips out the > variables names from the single quotes and any numbers and the > parentheses so it looks like this: > > Original warning: > > fs/fuse/virtio_fs.c:1468 virtio_fs_get_tree() error: double free of 'fm' > > Stripped: > > fs.fuse.virtio_fs.c.virtio_fs_get_tree_error:_double_free_of_'' > > You could hash the stripped string. Looking at it now, the variable > name is actually useful and shouldn't be stripped out. Doh... Even with the variable name would not be enough for us. The below two lines would hash to the same value: 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 So, I really need a relative position within the function at least to distinguish between the two cases above. I can do it with scripting I guess on top, but would be handy if I can get the line number where vmic_probe() is defined from within the smatch pattern and calculate relative position when printing the smatch error/warning. > > I don't know what the zero day bot does for this to mark warnings as > dealt with or not. There is also the Aiaiai project > (https://www.openhub.net/p/aiaiai) which probably has a feature for > marking warnings as reviewed. Thank you very much for pointers, let me see if I can use smth from them! Best Regards, Elena. > > regards, > dan carpenter
