[PATCH] D69208: [asan] Provide an interface to update an allocation stack trace.

Mon Oct 28 12:59:25 PDT 2019

eugenis marked an inline comment as done.
eugenis added a comment.

In D69208#1716241 <https://reviews.llvm.org/D69208#1716241>, @dvyukov wrote:

> FWIW for kernel sanitizers we want an ability to memorize few _additional_ stacks per heap object:
>  https://bugzilla.kernel.org/show_bug.cgi?id=198437
>  That's very useful for any kind of asynchronous processing environments that involves tasks, callbacks, thread pools, etc (read - almost all large C/C++ software today) because allocation/free stack may be meaningless and/or other stacks may be crucially important.

Agreed. We don't have space in the chunk header to fit any additional stack traces for free though. And the kernel has its own runtime implementation anyway.

================
Comment at: compiler-rt/include/sanitizer/asan_interface.h:320
+/// trace. Returns 1 if successfull, 0 if not.
+int __asan_update_allocation(void* addr);
+
----------------
kcc wrote:
> eugenis wrote:
> > kcc wrote:
> > > Add some explanation of when it is going to be successful. 
> > > Also, what about threads? 
> > > This API is racey
> > Racey, as in someone could be deallocating this memory on another thread?
> > This API should be used in a situation when this is possible, of course.
> > It's exactly the same as malloc_usable_size().
> > 
> malloc_usable_size() only reads the data. 
> __asan_update_allocation writes the data, so if two threads try to simultaneously call this function, we'll have a race on alloc_context_id
> 
> BTW, the name "__asan_update_allocation" doesn't seem to reflect the action. 
> Maybe "__asan_update_allocation_context"?
> 
OK, I made the store atomic. It could still race with deallocation, but the same is true for malloc_usable_size.

Changed the name to asan_update_allocation_context

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69208/new/

https://reviews.llvm.org/D69208