All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vernet <void@manifault.com>
To: Dave Marchevsky <davemarchevsky@fb.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Rik van Riel <riel@surriel.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>, Yonghong Song <yhs@fb.com>,
	kernel-team@fb.com
Subject: Re: [RFC PATCH bpf-next 1/5] x86/fpu: Move context.h to include/asm
Date: Thu, 12 May 2022 06:56:31 -0700	[thread overview]
Message-ID: <20220512135631.arfh7ofamo6xmlls@dev0025.ash9.facebook.com> (raw)
In-Reply-To: <20220512074321.2090073-2-davemarchevsky@fb.com>

On Thu, May 12, 2022 at 12:43:17AM -0700, Dave Marchevsky wrote:
> The file's fpregs_state_valid function is useful outside of
> arch/x86/kernel/fpu dir. Further commits in this series use
> fpregs_state_valid to determine whether a BPF helper should fetch
> fpu reg value from xsave'd memory or register.
> 
> Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com>
> ---
>  arch/x86/{kernel => include/asm}/fpu/context.h | 2 ++
>  arch/x86/kernel/fpu/core.c                     | 2 +-
>  arch/x86/kernel/fpu/regset.c                   | 2 +-
>  arch/x86/kernel/fpu/signal.c                   | 2 +-
>  arch/x86/kernel/fpu/xstate.c                   | 2 +-
>  5 files changed, 6 insertions(+), 4 deletions(-)
>  rename arch/x86/{kernel => include/asm}/fpu/context.h (96%)
> 
> diff --git a/arch/x86/kernel/fpu/context.h b/arch/x86/include/asm/fpu/context.h
> similarity index 96%
> rename from arch/x86/kernel/fpu/context.h
> rename to arch/x86/include/asm/fpu/context.h
> index 958accf2ccf0..39dac18cd22c 100644
> --- a/arch/x86/kernel/fpu/context.h
> +++ b/arch/x86/include/asm/fpu/context.h
> @@ -51,6 +51,8 @@ static inline void fpregs_activate(struct fpu *fpu)
>  	trace_x86_fpu_regs_activated(fpu);
>  }
>  
> +extern void restore_fpregs_from_fpstate(struct fpstate *fpstate, u64 mask);

This signature is already included in arch/x86/include/asm/fpu/signal.h.
Should we just include that header from arch/x86/include/asm/fpu/context.h
rather than declaring the signature twice?

> +
>  /* Internal helper for switch_fpu_return() and signal frame setup */
>  static inline void fpregs_restore_userregs(void)
>  {
> diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
> index c049561f373a..5296112d4273 100644
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -7,6 +7,7 @@
>   *	Gareth Hughes <gareth@valinux.com>, May 2000
>   */
>  #include <asm/fpu/api.h>
> +#include <asm/fpu/context.h>
>  #include <asm/fpu/regset.h>
>  #include <asm/fpu/sched.h>
>  #include <asm/fpu/signal.h>
> @@ -18,7 +19,6 @@
>  #include <linux/pkeys.h>
>  #include <linux/vmalloc.h>
>  
> -#include "context.h"
>  #include "internal.h"
>  #include "legacy.h"
>  #include "xstate.h"
> diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c
> index 75ffaef8c299..f93336f332e3 100644
> --- a/arch/x86/kernel/fpu/regset.c
> +++ b/arch/x86/kernel/fpu/regset.c
> @@ -6,10 +6,10 @@
>  #include <linux/vmalloc.h>
>  
>  #include <asm/fpu/api.h>
> +#include <asm/fpu/context.h>
>  #include <asm/fpu/signal.h>
>  #include <asm/fpu/regset.h>
>  
> -#include "context.h"
>  #include "internal.h"
>  #include "legacy.h"
>  #include "xstate.h"
> diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c
> index 91d4b6de58ab..f099a56c9a93 100644
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -7,6 +7,7 @@
>  #include <linux/cpu.h>
>  #include <linux/pagemap.h>
>  
> +#include <asm/fpu/context.h>
>  #include <asm/fpu/signal.h>
>  #include <asm/fpu/regset.h>
>  #include <asm/fpu/xstate.h>
> @@ -15,7 +16,6 @@
>  #include <asm/trapnr.h>
>  #include <asm/trace/fpu.h>
>  
> -#include "context.h"
>  #include "internal.h"
>  #include "legacy.h"
>  #include "xstate.h"
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index 39e1c8626ab9..ab5e26075716 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -15,6 +15,7 @@
>  #include <linux/vmalloc.h>
>  
>  #include <asm/fpu/api.h>
> +#include <asm/fpu/context.h>
>  #include <asm/fpu/regset.h>
>  #include <asm/fpu/signal.h>
>  #include <asm/fpu/xcr.h>
> @@ -23,7 +24,6 @@
>  #include <asm/prctl.h>
>  #include <asm/elf.h>
>  
> -#include "context.h"
>  #include "internal.h"
>  #include "legacy.h"
>  #include "xstate.h"
> -- 
> 2.30.2
> 

Looks reasonable otherwise, though it's unclear to me (as I'm not an expert
in this code) whether we should or shouldn't export all of these functions
if some of them are specific to the logic in arch/x86/kernel/fpu. It looks
like there's already a precedent for doing that with e.g.
fpu__clear_user_states(), so it seems fine.

Thanks,
David

  reply	other threads:[~2022-05-12 13:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12  7:43 [RFC PATCH bpf-next 0/5] bpf: add get_reg_val helper Dave Marchevsky
2022-05-12  7:43 ` [RFC PATCH bpf-next 1/5] x86/fpu: Move context.h to include/asm Dave Marchevsky
2022-05-12 13:56   ` David Vernet [this message]
2022-05-14  0:44   ` Alexei Starovoitov
2022-05-12  7:43 ` [RFC PATCH bpf-next 2/5] bpf: add get_reg_val helper Dave Marchevsky
2022-05-12 15:29   ` David Vernet
2022-05-18  8:07     ` Dave Marchevsky
2022-05-14  0:41   ` Alexei Starovoitov
2022-05-18  7:35     ` Dave Marchevsky
2022-05-12  7:43 ` [RFC PATCH bpf-next 3/5] libbpf: usdt lib wiring of xmm reads Dave Marchevsky
2022-05-14  0:43   ` Alexei Starovoitov
2022-05-16 23:26   ` Andrii Nakryiko
2022-05-18  8:20     ` Dave Marchevsky
2022-05-12  7:43 ` [RFC PATCH bpf-next 4/5] selftests/bpf: Add test for USDT parse of xmm reg Dave Marchevsky
2022-05-16 23:31   ` Andrii Nakryiko
2022-05-17  1:17     ` Alexei Starovoitov
2022-05-18 23:56       ` Andrii Nakryiko
2022-05-12  7:43 ` [RFC PATCH bpf-next 5/5] selftests/bpf: get_reg_val test exercising fxsave fetch Dave Marchevsky
2022-05-12 17:47   ` Dave Marchevsky
2022-05-16 23:28   ` Andrii Nakryiko

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=20220512135631.arfh7ofamo6xmlls@dev0025.ash9.facebook.com \
    --to=void@manifault.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davemarchevsky@fb.com \
    --cc=iii@linux.ibm.com \
    --cc=kernel-team@fb.com \
    --cc=riel@surriel.com \
    --cc=yhs@fb.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.