From: Michael Ellerman <mpe@ellerman.id.au>
To: "Christopher M. Riedl" <cmr@codefail.de>,
Gabriel Paubert <paubert@iram.es>
Cc: David Laight <David.Laight@ACULAB.COM>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v4 02/10] powerpc/signal: Add unsafe_copy_{vsx, fpr}_from_user()
Date: Thu, 04 Feb 2021 17:09:24 +1100 [thread overview]
Message-ID: <87mtwkpdnv.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <C8YHSKQ99VC4.M9Y0WOFVUTBQ@geist>
"Christopher M. Riedl" <cmr@codefail.de> writes:
> On Mon Feb 1, 2021 at 10:54 AM CST, Gabriel Paubert wrote:
>> On Mon, Feb 01, 2021 at 09:55:44AM -0600, Christopher M. Riedl wrote:
>> > On Thu Jan 28, 2021 at 4:38 AM CST, David Laight wrote:
>> > > From: Christopher M. Riedl
>> > > > Sent: 28 January 2021 04:04
>> > > >
>> > > > Reuse the "safe" implementation from signal.c except for calling
>> > > > unsafe_copy_from_user() to copy into a local buffer.
>> > > >
>> > > > Signed-off-by: Christopher M. Riedl <cmr@codefail.de>
>> > > > ---
>> > > > arch/powerpc/kernel/signal.h | 33 +++++++++++++++++++++++++++++++++
>> > > > 1 file changed, 33 insertions(+)
>> > > >
>> > > > diff --git a/arch/powerpc/kernel/signal.h b/arch/powerpc/kernel/signal.h
>> > > > index 2559a681536e..c18402d625f1 100644
>> > > > --- a/arch/powerpc/kernel/signal.h
>> > > > +++ b/arch/powerpc/kernel/signal.h
>> > > > @@ -53,6 +53,33 @@ unsigned long copy_ckfpr_from_user(struct task_struct *task, void __user *from);
>> > > > &buf[i], label);\
>> > > > } while (0)
>> > > >
>> > > > +#define unsafe_copy_fpr_from_user(task, from, label) do { \
>> > > > + struct task_struct *__t = task; \
>> > > > + u64 __user *__f = (u64 __user *)from; \
>> > > > + u64 buf[ELF_NFPREG]; \
>> > >
>> > > How big is that buffer?
>> > > Isn't is likely to be reasonably large compared to a reasonable
>> > > kernel stack frame.
>> > > Especially since this isn't even a leaf function.
>> > >
>> >
>> > I think Christophe answered this - I don't really have an opinion either
>> > way. What would be a 'reasonable' kernel stack frame for reference?
>>
>> See include/linux/poll.h, where the limit is of the order of 800 bytes
>> and the number of entries in an on stack array is chosen at compile time
>> (different between 32 and 64 bit for example).
>>
>> The values are used in do_sys_poll, which, with almost 1000 bytes of
>> stack footprint, appears close to the top of "make checkstack". In
>> addition do_sys_poll has to call the ->poll function of every file
>> descriptor in its table, so it is not a tail function.
>>
>> This 264 bytes array looks reasonable, but please use 'make checkstack'
>> to verify that the function's total stack usage stays within reason.
>
> Neat, looks like total usage is a bit larger but still reasonable and
> less than half of 800B:
>
> 0xc000000000017e900 __unsafe_restore_sigcontext.constprop.0 [vmlinux]:352
We warn for frames larger than 2KB on 64-bit, see FRAME_WARN in
lib/Kconfig.debug.
So 264 bytes is entirely reasonable IMHO.
cheers
next prev parent reply other threads:[~2021-02-04 6:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 4:04 [PATCH v4 00/10] Improve signal performance on PPC64 with KUAP Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 01/10] powerpc/uaccess: Add unsafe_copy_from_user Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 02/10] powerpc/signal: Add unsafe_copy_{vsx, fpr}_from_user() Christopher M. Riedl
2021-01-28 10:38 ` David Laight
2021-01-28 12:05 ` Christophe Leroy
2021-02-01 15:55 ` Christopher M. Riedl
2021-02-01 16:15 ` David Laight
2021-02-01 16:55 ` Christopher M. Riedl
2021-02-01 17:37 ` David Laight
2021-02-01 17:43 ` Christopher M. Riedl
2021-02-01 16:54 ` Gabriel Paubert
2021-02-01 20:55 ` Christopher M. Riedl
2021-02-04 6:09 ` Michael Ellerman [this message]
2021-01-28 4:04 ` [PATCH v4 03/10] powerpc/signal64: Move non-inline functions out of setup_sigcontext() Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 04/10] powerpc: Reference param in MSR_TM_ACTIVE() macro Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 05/10] powerpc/signal64: Remove TM ifdefery in middle of if/else block Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 06/10] powerpc/signal64: Replace setup_sigcontext() w/ unsafe_setup_sigcontext() Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 07/10] powerpc/signal64: Replace restore_sigcontext() w/ unsafe_restore_sigcontext() Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 08/10] powerpc/signal64: Rewrite handle_rt_signal64() to minimise uaccess switches Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 09/10] powerpc/signal64: Rewrite rt_sigreturn() " Christopher M. Riedl
2021-01-28 4:04 ` [PATCH v4 10/10] powerpc/signal64: Use __get_user() to copy sigset_t Christopher M. Riedl
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=87mtwkpdnv.fsf@mpe.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=David.Laight@ACULAB.COM \
--cc=cmr@codefail.de \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paubert@iram.es \
/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.