Re: [PATCH] mm, slub: place the trace before freeing memory in kmem_cache_free()

On Sat, Oct 30, 2021 at 08:23:12PM +0800, Muchun Song wrote:

On Sat, Oct 30, 2021 at 6:12 PM Yunfeng Ye [off-list ref] wrote:

quoted

After the memory is freed, it may be allocated by other CPUs and has
been recorded by trace. So the timing sequence of the memory tracing is
inaccurate.

For example, we expect the following timing sequeuce:

    CPU 0                 CPU 1

  (1) alloc xxxxxx
  (2) free  xxxxxx
                         (3) alloc xxxxxx
                         (4) free  xxxxxx

However, the following timing sequence may occur:

    CPU 0                 CPU 1

  (1) alloc xxxxxx
                         (2) alloc xxxxxx
  (3) free  xxxxxx
                         (4) free  xxxxxx

So place the trace before freeing memory in kmem_cache_free().

Could you tell me what problem you have encountered
here?

It's confusing to see the memory allocated before it's freed.  If you're
unaware of this problem, you might think it was being used after free
because (1) happened a long time ago, so you see (2) immediately followed
by (3) and then see the memory being used.

The patch makes sense to me.