From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>, Jens Axboe <axboe@kernel.dk>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs
Date: Thu, 30 Mar 2023 08:44:32 +0000 [thread overview]
Message-ID: <644648e1-3f62-8bde-f974-e40265abade8@csgroup.eu> (raw)
In-Reply-To: <87ilelcd1w.fsf@mpe.ellerman.id.au>
Le 28/03/2023 à 13:47, Michael Ellerman a écrit :
> "Nicholas Piggin" <npiggin@gmail.com> writes:
>> On Mon Mar 27, 2023 at 8:26 PM AEST, Christophe Leroy wrote:
> ...
>>>
>>> Now that thread.regs doesn't change anymore at each interrupt, it would
>>> probably be worth dropping it and falling back to task_pt_regs() as
>>> defined on most architecture.
>>> Knowing whether a thread is a kernel or user thread can for instance be
>>> known with PF_KTHREAD flag, so no need of thread.regs for that.
>>
>> That would be nice if we can define regs that way, I agree. We should
>> look into doing that.
>
> Yeah it's on the long-list of things that need cleaning up.
>
> I think there's some complication in working out which sites are OK to
> use/give-out the value in pt_regs that's potentially a dummy value, vs
> cases that actually want to check PF_KTHREAD and do something different.
> But that's just my hunch I haven't looked through all the sites.
>
> The thread.regs = NULL for kernel threads goes back to arch/ppc, about
> 2002 by the looks:
>
> https://github.com/mpe/linux-fullhistory/commit/2a8e186c384c0c911f91cd12367658eabdc820d8#diff-939b705cff722ee75595fad30d56bb1175dfdce49a69adb4d5656f354be076c6
>
> There's no change log of course :)
>
> Still maybe it doesn't matter why it was originally done that way, if we
> can do it differently now.
>
I have the feeling that our logic is broken after commit 5bd2e97c868a
("fork: Generalize PF_IO_WORKER handling")
Christophe
next prev parent reply other threads:[~2023-03-30 8:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-26 22:15 [PATCH] powerpc: don't try to copy ppc for task with NULL pt_regs Jens Axboe
2023-03-27 6:36 ` Nicholas Piggin
2023-03-27 10:26 ` Christophe Leroy
2023-03-28 6:16 ` Nicholas Piggin
2023-03-28 11:47 ` Michael Ellerman
2023-03-30 8:44 ` Christophe Leroy [this message]
2023-03-27 12:42 ` Jens Axboe
2023-03-27 13:54 ` Michael Ellerman
2023-03-27 16:10 ` Jens Axboe
2023-03-28 11:32 ` Michael Ellerman
2023-03-28 12:39 ` Jens Axboe
2023-04-06 0:26 ` Michael Ellerman
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=644648e1-3f62-8bde-f974-e40265abade8@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=axboe@kernel.dk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.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.