From: Catalin Marinas <catalin.marinas@arm.com>
To: Liu Shixin <liushixin2@huawei.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Patrick Wang <patrick.wang.shcn@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH 1/2] Revert "mm/kmemleak: move the initialisation of object to __link_object"
Date: Wed, 15 Nov 2023 14:17:04 +0000 [thread overview]
Message-ID: <ZVTS4DN1nVFIvdOe@arm.com> (raw)
In-Reply-To: <20231115082138.2649870-2-liushixin2@huawei.com>
On Wed, Nov 15, 2023 at 04:21:37PM +0800, Liu Shixin wrote:
> Move the initialisation of object back to__alloc_object() because
> set_track_prepare() attempt to acquire zone->lock(spinlocks) while
> __link_object is holding kmemleak_lock(raw_spinlocks). This is not
> right for RT mode.
>
> This reverts commit 245245c2fffd0050772a3f30ba50e2be92537a32.
>
> Signed-off-by: Liu Shixin <liushixin2@huawei.com>
You can also add:
Fixes: 245245c2fffd ("mm/kmemleak: move the initialisation of object to __link_object")
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
I now realised that we update the object allocation stack trace via the
delete_object_part() when we shouldn't. I'd say __alloc_object() can
take a trace_handle as argument and if it's !0, set it directly whithout
calling set_track_prepare() (as a separate patch).
--
Catalin
next prev parent reply other threads:[~2023-11-15 14:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-15 8:21 [PATCH 0/2] Fix invalid wait context of set_track_prepare() Liu Shixin
2023-11-15 8:21 ` [PATCH 1/2] Revert "mm/kmemleak: move the initialisation of object to __link_object" Liu Shixin
2023-11-15 8:19 ` Geert Uytterhoeven
2023-11-15 14:17 ` Catalin Marinas [this message]
2023-11-15 8:21 ` [PATCH 2/2] mm/kmemleak: move set_track_prepare() outside raw_spinlocks Liu Shixin
2023-11-15 14:19 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZVTS4DN1nVFIvdOe@arm.com \
--to=catalin.marinas@arm.com \
--cc=akpm@linux-foundation.org \
--cc=geert@linux-m68k.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=liushixin2@huawei.com \
--cc=patrick.wang.shcn@gmail.com \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.