On Thu, Nov 17, 2016 at 06:46:44AM +0800, Christopher Li wrote: > On Mon, Nov 7, 2016 at 6:00 PM, Luc Van Oostenryck > <luc.vanoostenryck@xxxxxxxxx> wrote: > > OK, I've checked this on a more substantial amount of code > > than the testsuite: the kernel for x86-64 with allyesconfig > > and I confirm that there is not a single out-of-bounds access > > to any ->list[], wich is what matters. > > > > Nevertheless, there are two cases (in cse.c and evaluate.c) > > where elements are deleted from a list which is not directly > > repacked at the end of the loop and it's not obvious in the code > > why it's OK to not repack them. > > Thanks for the extensive testing. As for the repacking, I think its > better to repack the list to after the delete of the entry. However, > we don't want to repack the list if there is not deletion at all. > > How about this, we can introduce a bit field on "struct ptr_list" to > keep track of the list needs repack or not. On deletion the ptr_list will > be dirty. The other function which assuming the packed list will > check the dirty bit and complain if list is not packed. > > We can even make keep the "struct ptr_list" the same size. > Just squeeze some bits from "int nr". However, that will break the > binary interface of sparse as a library. The application link with > sparse will need to be recompiled. > > Chris > -- Sound good. I'll look at this, probably tomorrow. 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
