On Wed, Jul 19, 2017 at 11:42 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote: > On Wed, Jul 19, 2017 at 2:14 PM, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: >> When I see this description, the first thing I think is: >> "you have a problem with an object, you duplicate the object, >> not you have two problem (at least)". >> In short, how you will keep coherency between the two? > > We don't :-). Both the remove case and insert case has been > discussed. First of all, the ptrlist-refcount patch check for the > insert case, there is none so far. If you believe there is one, > I would like to know. Some add_user() can be called in this loop. so it's just a question to some input code complex enough to have an add_user() done on the same pseudo as the one concerned in the outer loop. > About the looping on the deleted entry. That is the very first > thing I shout in the V1 version of the patch. The thing is, > the pseudo_user have a point to instruction. If the instruction > is deleted then that instruction will have insn->bb = NULL. > > Not a perfect fix. But better than the previous. Because > the for loop is actually looping on reverse order. Any delete > will cause major align problem __nr counting from the tail. Yes, those list delete inside iteration loops are definitively to avoid. > Any way, My V1 and email asking for suggestion how to fix it > About 10 days ago. I haven't heard any thing better. If you > have other way to fix it properly, I am all for it. It is not too late > but time is running out soon. I stated several times that the only real solution will be to mark the elements as being deleted (and only effectively delete them in some safe situations) exactly like it is done for instruction (which are probably the type the most often deleted from lists. Trying to effectively removing them from lists like it is currently done for the others types would most probably fail in the most horrible ways). It's a simple & clean solution, provably correct in *all* situations. But I don't remember having seen any replies from you on this subject. -- 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
