On 13.10.2021 18:10, Andrew Cooper wrote: > On 13/10/2021 16:36, Jan Beulich wrote: >> It's not clear to me why the tool spotted them now and not before, > > Several reasons. > > The Coverity backend is a software product just like everything else. > IIRC, it releases quarterly. > > "If something's free, then you are the product". The value of offering > free scanning of open source codebases comes from us (the free users) > integrating a massive corpus of code into Coverity's system, upon which > they can evaluate the effectiveness of new heuristics. > > > Second, and far more likely in this case, "x86/mm: avoid building > multiple .o from a single .c file". Coverity has always choked on that > in Xen, because it's intermediate database is keyed on source file with > latest takes precedent, so we were only seeing the 4-level case previously. > > > And to also answer your question from patch 1 here, there are upper time > and complexity bounds on all analysis, because scanning is an > exponential problem with the size of the source file. I don't know > exactly where the cutoffs are, and I fear that some of our larger files > never have later functions looked at.
Thanks for the explanations. I have to admit that I would find it helpful if the tool distinguished new issues it found just because code previously wasn't scanned from ones that were truly introduced anew. For patch 1 here this might mean that the report was previously put off when reported against the 4-level case; I think it shouldn't have been ignored, but opinions might diverge and hence there might be a reason why patch 1 isn't wanted then. Patch 2, otoh, doesn't have a 4-level equivalent so is likely to be wanted. Unfortunately your reply didn't include an ack, nak, or at least a vague indication towards either, so I don't really know what (if anything) it means towards the actual patches. Jan
