Le 28/03/2023 à 13:47, Michael Ellerman a écrit :
> "Nicholas Piggin" <npig...@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
