From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Christophe Leroy" <christophe.leroy@csgroup.eu>,
"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: Tue, 28 Mar 2023 16:16:31 +1000 [thread overview]
Message-ID: <CRHSOZ15ORYN.1DMP7BFBDRFII@bobo> (raw)
In-Reply-To: <6727b289-aef6-89f9-8b4f-d63cbaeb81e5@csgroup.eu>
On Mon Mar 27, 2023 at 8:26 PM AEST, Christophe Leroy wrote:
>
>
> Le 27/03/2023 à 08:36, Nicholas Piggin a écrit :
> > On Mon Mar 27, 2023 at 8:15 AM AEST, Jens Axboe wrote:
> >> Powerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which
> >> from my (arguably very short) checking is not commonly done for other
> >> archs. This is fine, except when PF_IO_WORKER's have been created and
> >> the task does something that causes a coredump to be generated. Then we
> >> get this crash:
> >
> > Hey Jens,
> >
> > Thanks for the testing and the patch.
> >
> > I think your patch would work, but I'd be inclined to give the IO worker
> > a pt_regs so it looks more like other archs and a regular user thread.
> >
> > Your IO worker bug reminded me to resurrect some copy_thread patches I
> > had and I think they should do that
> >
> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2023-March/256271.html
> >
> > I wouldn't ask you to test it until I've at least tried, do you have a
> > test case that triggers this?
>
> I fact, most architectures don't have thread.regs, but rely on something
> like:
>
> #define task_pt_regs(p) \
> ((struct pt_regs *)(THREAD_SIZE + task_stack_page(p)) - 1)
>
>
> In powerpc, thread.regs was there because of the regs not being at the
> same place in the stack depending on which interrupt it was.
>
> However with the two commits below, we now have stable fixed location
> for the regs, so thread.regs shouldn't be needed anymore:
> - db297c3b07af ("powerpc/32: Don't save thread.regs on interrupt entry")
> - b5cfc9cd7b04 ("powerpc/32: Fix critical and debug interrupts on BOOKE")
>
> But in the meantime, thread.regs started to be used for additional
> purpose, like knowing if it is a user thread or a kernel thread by using
> thread.regs nullity.
>
>
> 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.
Thanks,
Nick
next prev parent reply other threads:[~2023-03-28 6:17 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 [this message]
2023-03-28 11:47 ` Michael Ellerman
2023-03-30 8:44 ` Christophe Leroy
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=CRHSOZ15ORYN.1DMP7BFBDRFII@bobo \
--to=npiggin@gmail.com \
--cc=axboe@kernel.dk \
--cc=christophe.leroy@csgroup.eu \
--cc=linuxppc-dev@lists.ozlabs.org \
/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.