Messages in this thread | | | Subject | Re: [PATCH v2] mm, slub: emit the "free" trace report before freeing memory in kmem_cache_free() | From | Yunfeng Ye <> | Date | Wed, 3 Nov 2021 11:41:26 +0800 |
| |
On 2021/11/3 2:37, John Hubbard wrote: > On 11/2/21 04:43, Yunfeng Ye wrote: >> After the memory is freed, it can be immediately allocated by other >> CPUs, before the "free" trace report has been emitted. This causes >> inaccurate traces. >> >> For example, if the following sequence of events occurs: >> >> CPU 0 CPU 1 >> >> (1) alloc xxxxxx >> (2) free xxxxxx >> (3) alloc xxxxxx >> (4) free xxxxxx >> >> Then they will be inaccurately reported via tracing, so that they appear >> to have happened in this order: >> >> CPU 0 CPU 1 >> >> (1) alloc xxxxxx >> (2) alloc xxxxxx >> (3) free xxxxxx >> (4) free xxxxxx >> >> This makes it look like CPU 1 somehow managed to allocate mmemory that > > > I see I created a typo for you, sorry about that: s/mmemory/memory/ > > But anyway, the wording looks good now. Please feel free to add: > > Reviewed-by: John Hubbard <jhubbard@nvidia.com> > Ok, I will fix the typo in the v3 patch.
Thanks.
> > thanks,
| |