From: Michael Ellerman <mpe@ellerman.id.au>
To: "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>,
Luming Yu <luming.yu@shingroup.cn>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
npiggin@gmail.com, christophe.leroy@csgroup.eu
Cc: shenghui.qu@shingroup.cn, Luming Yu <luming.yu@shingroup.cn>,
dawei.li@shingroup.cn, ke.zhao@shingroup.cn, luming.yu@gmail.com
Subject: Re: [PATCH v1 2/2] powerpc/debug: hook to user return notifier infrastructure
Date: Tue, 19 Dec 2023 17:33:33 +1100 [thread overview]
Message-ID: <8734vyn1ky.fsf@mail.lhotse> (raw)
In-Reply-To: <8734vzsw0q.fsf@kernel.org>
Aneesh Kumar K.V <aneesh.kumar@kernel.org> writes:
> Luming Yu <luming.yu@shingroup.cn> writes:
>
>> Before we have powerpc to use the generic entry infrastructure,
>> the call to fire user return notifier is made temporarily in powerpc
>> entry code.
>>
>
> It is still not clear what will be registered as user return notifier.
> Can you summarize that here?
fire_user_return_notifiers() is defined in kernel/user-return-notifier.c
That's built when CONFIG_USER_RETURN_NOTIFIER=y.
That is not user selectable, it's only enabled by:
arch/x86/kvm/Kconfig: select USER_RETURN_NOTIFIER
So it looks to me like (currently) it's always a nop and does nothing.
Which makes me wonder what the point of wiring this feature up is :)
Maybe it's needed for some other feature I don't know about?
Arguably we could just enable it because we can, and it currently does
nothing so it's unlikely to break anything. But that also makes it
impossible to test the implementation is correct, and runs the risk that
one day in the future when it does get enabled only then do we discover
it doesn't work.
cheers
next prev parent reply other threads:[~2023-12-19 6:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 3:13 [PATCH v1 2/2] powerpc/debug: hook to user return notifier infrastructure Luming Yu
2023-12-18 9:24 ` Aneesh Kumar K.V
2023-12-19 6:33 ` Michael Ellerman [this message]
2024-02-20 8:51 ` Christophe Leroy
2024-02-20 9:02 ` Christophe Leroy
2024-08-28 3:17 ` 虞陆铭
2024-08-28 5:46 ` Christophe Leroy
2024-08-28 6:50 ` Luming Yu
2024-08-28 7:27 ` Christophe Leroy
2024-08-29 9:58 ` Luming Yu
2024-09-02 8:34 ` Luming Yu
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=8734vyn1ky.fsf@mail.lhotse \
--to=mpe@ellerman.id.au \
--cc=aneesh.kumar@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=dawei.li@shingroup.cn \
--cc=ke.zhao@shingroup.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luming.yu@gmail.com \
--cc=luming.yu@shingroup.cn \
--cc=npiggin@gmail.com \
--cc=shenghui.qu@shingroup.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).