On Wed, Sep 23, 2026 at 12:26 AM Kees Cook <[email protected]> wrote: > On Wed, Sep 23, 2026 at 04:16:30AM +0000, Bill Wendling wrote: > > The compiler attribute __counted_by_ptr can be used by KASAN and UBSAN > > to detect out-of-bounds accesses to pointer fields in structs where a > > corresponding element count field is available. > > > > In "struct iio_gts", there are multiple pointer fields associated with > > an element count. This patch annotates these pointer fields with > > "__counted_by_ptr" to improve runtime safety: > > > > - 'hwgain_table': counted by 'num_hwgain' > > - 'itime_table': counted by 'num_itime' > > - 'per_time_avail_scale_tables': counted by 'num_itime' > > - 'avail_all_scales_table': counted by 'num_avail_all_scales' > > - 'avail_time_tables': counted by 'num_avail_time_tables' > > > > To ensure that the count is set correctly before any pointer is > > accessed or assigned, we update "iio_init_iio_gts()" to set the counts > > prior to assigning the pointers. > > "Accessed" yes, "assigned" no. :) Let's not churn on assignment ordering > unless there is some problem I'm not seeing. The only time this should > ever matter is if there is multithread visibility on the object already, > but that would require both counter and pointer be set, so that'd be a > general locking issue, but ordering during initialization doesn't > matter. > In a separate patch, Sashiko flagged the assignments being "out of order". It's not an error, but I did submit a "v2" that reordered the assignments (that Sashiko is still complaining about, but I think it's a pre-existing issue). I can weed out the needless reordering changes from the patches, however, I like the idea of people thinking about the ordering of such assignments.
It's a small thing I know, but I need something to hold on to. :-D -bw
