> 2), Then SmPL A generates another SmPL B based on the function name list; This would be a general data processing possibility. Another option would be to let SmPL scripts to import relevant data from external files or to query facts from databases. > You expect the entire process above to be automated. I hope that this can be achieved finally. > This idea may be interesting, Thanks for your feedback. > but it can't be done now, I got an other view. - Why is your view so limited at the moment? > and it will introduce uncontrollable factors. I suggest to take additional design options into account so that you might get more control on some factors. Which software development challenges are still waiting for better solutions? > We agree with julia's comments: > I would prefer not to put semantic patches that involve iteration into the kernel, for simplicity. I guess that this kind of change reluctance can be also adjusted. Some source code analysis approaches can look simple enough while advanced ones will show more of the inherent complexity. > Our file is called of_node_put.cocci, which contains three rules: r_miss_put, > r_miss_put_ext and r_use_after_put. This combination is interesting, isn't it? > If you separate them, it seems inappropriate. * Would you like to be able to let each source code analysis task to be executed on its own? * I guess that it can become possible with additional development efforts to support also a mixture of analysis patterns. * The patch subject “… missing …” does probably not fit to the detection “use after …”. >>> v3: delete the global set, … >> >> To which previous implementation detail do you refer here? > > Here is an improvement based on julia's comments: > https://lkml.org/lkml/2019/7/5/55 I would find an other description clearer then. * Drop of functions around “add_if_not_present” * Omission of iteration functionality Are any more adjustments worth to be explicitly mentioned in this patch change log? > Here are some improvements. Are you going to contribute further patch versions? > Adding an asterisk here is more convenient to use, This might be. - I wonder how good additional data fit to supported output formats. > it can mark the location of the code of interest, such as: I know its functionality also. - I got the impression that the use of SmPL asterisks will be safe for the operation mode “context”. >>> +... when != e = (T)x >>> + when != true x == NULL >> >> Will assignment exclusions get any more software development attention? >> https://lore.kernel.org/lkml/03cc4df5-ce7f-ba91-36b5-687fec8c7297@xxxxxx/ >> https://lore.kernel.org/patchwork/patch/1095169/#1291892 >> https://lkml.org/lkml/2019/6/29/193 Will this aspect evolve further anyhow? >> You propose once more to use a SmPL conjunction in the rule “r_miss_put_ext”. >> I am also still waiting for a definitive explanation on the applicability >> of this combination. Would you like to clarify this software detail any more? >>> +@r_use_after_put exists@ >>> +expression r_put.E, subE<=r_put.E; >> >> I have got an understanding difficulty around the interpretation >> of the shown SmPL constraint. >> How will the clarification be continued? More helpful information? > +| > + f(...,c,...,(T)E,...) I would interpret such passing of a pointer for a device node as an undesirable “use after free (or put)”. Will this SmPL disjunction need further adjustments? Regards, Markus
