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 -- 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
