On Sat, Jul 08, 2017 at 10:54:18PM -0700, Christopher Li wrote: > Hi Luc, > > I make some progress of the ptrlist ref count patch. > A lot of update to make the ref count right. > Most of the case is "return" or "jmp" inside a ptrlist > loop. Yes, I saw that when running your previous version on the testsuite. > Another issue I hit is that, if return inside two level > of ptrlist, it need to release both ptr list. > > My patch can pass the testsuit without complaining > any more. > > When I use it to check the kernel. I found some thing. > Looking from the back trace, I think it is a real bug that > it catch (instead of a false alarm like last one). > > The list in question is pseudo->users. Yes, the recursive kill_instruction I talked about. I have already been bitten by it several time (not especially about ptrlist thing, but other stuff too), it's quite dangerous. > I am convince this is a real one. Yes, most probably. > I think you are the expert in simplify.c, I can use some help here. > > I am looking for simple ways to avoid nested looping delete. > For example, less aggressive on simplify things is fine. Alas, I don't think this can be done because: 1) it would be a big code change 2) change in simplification have non-onbious impact on the diagnostics that are emitted (simplification -> dead code elimination (1st impact) -> branch simplification/mergin (2nd impact)). But theer exist other simple fixes. > The goal is find simple way let sparse pass the full kernel check without die on > the ptr ref count checking patch. Proper fix the ptrlist nested > looping delete might > be too big for this up coming release. Avoid it if we can. > > BTW, I am not going to push ptr ref count patch into the 0.5.1 release. > It is just for checking. Yes, sure. -- Luc -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
