Am Donnerstag, dem 10.04.2025 um 06:56 -0400 schrieb Siddhesh Poyarekar: > On 2025-04-10 01:41, Martin Uecker wrote: > > I have some questions about this: The access would add new reads > > to the size field. For counted_by, so far, those are somehow > > coupled to the access to the member. From this you would assume > > For the currently implemented subset, updates to the storage of the > annotated FAM and updates to its counted_by size need to be coupled to > prevent reordering because their relationship is otherwise implicit. > > This proposed feature would need the counted_by size and the containing > struct of the FAM to be coupled to make that relationship explicit, but > it's not necessarily to prevent reordering because this case needs to > only be considered when the update of the storage for the struct (or its > containing FAM) is not visible. That is, the pointer either comes in as > a parameter or a non-allocator call returning that pointer.
So the assumption here is that you never pass around a pointer to an uninitialized (or otherwise not validely initialized) structure. > > Now it is entirely possible that further inlining gets the allocator in > and it would be possible to thread through the .ACCESS_WITH_SIZE to > reach the allocator, but I would argue that the counted_by + size of > struct should be the canonical result. I am thinking about use cases where the user does its own memory management, e.g. there is larger arena the structure is allocated in or there is a capacity field because the structure was overallocated. > > > that inserting the new accesses to the size field are ok (e.g. > > one can assume the struct is accessible, there are no new race > > conditions under some assumptions, it is initialized). If you > > now want to read the size at different points, all this is even > > less clear to me. > > I'm not sure about race conditions, the coupling was to prevent > reordering. Would you be able to elaborate on the race condition question? If you materialize a read to the size field it could race with a write to this field in another thread. I am not sure whether there are use cases where this can happen, but it is something to worry about. > > > I may miss something, but I think one would have to first > > define a clear criterion when it is ok to access the size > > field. > > This is a contentious issue I had not thought of; if the pointer ends up > being NULL at runtime, a dereference due to the size expression for the > containing struct will end up validating it for subsequent passes, which > may makes things even worse. The size expression will also need a NULL > check to work around this. Yes. But there could be other issues. The memory could be protected. > > So to me it seems we can not simply insert it at specific > > point in the C FE where a pointer to the struct is > > used, but only when there is some specific trigger. > > > > An example I could imagine is when you memcpy > > the struct. (but it is also not entirely clear why this > > should not be allowed to go beyond the counted_by size > > if the underlying storage is larger). > > IMO, I don't think underallocation/overallocation (and expecting the > additional allocation to be usable) and counted_by for FAM should be > allowed to coexist. That's just a source for confusion. It certainly makes it more complex. But people like to use their own memory management (or have to) and not being able to use counted_by then would be a limitation. > > > Maybe you could add it when a pointer to an annotated > > struct is passed as parameter, but also there it is not > > clear to me that we might want to materialize new > > accesses to the struct at this point. > > > > An alternative approach could be to just do it when > > such a pointer is explicitely passed to the BDOS builtin. > > I suppose bounds sanitizer won't be affected by this but wouldn't this > then exclude the object-size sanitizer? I don't know if its > instrumentation runs early enough. I am not sure. Martin
