Messages in this thread | | | Date | Thu, 19 May 2022 01:17:19 +0800 | Subject | Re: [PATCH V11 14/22] LoongArch: Add signal handling support | From | WANG Xuerui <> |
| |
On 5/19/22 00:54, Huacai Chen wrote: > Hi, Eric, > > On Thu, May 19, 2022 at 12:40 AM Eric W. Biederman > <ebiederm@xmission.com> wrote: >> Huacai Chen <chenhuacai@loongson.cn> writes: >> >>> Add ucontext/sigcontext definition and signal handling support for >>> LoongArch. >>> >>> Cc: Eric Biederman <ebiederm@xmission.com> >>> Cc: Al Viro <viro@zeniv.linux.org.uk> >>> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> >>> --- >>> arch/loongarch/include/uapi/asm/sigcontext.h | 44 ++ >>> arch/loongarch/include/uapi/asm/signal.h | 13 + >>> arch/loongarch/include/uapi/asm/ucontext.h | 35 ++ >>> arch/loongarch/kernel/signal.c | 566 +++++++++++++++++++ >>> 4 files changed, 658 insertions(+) >>> create mode 100644 arch/loongarch/include/uapi/asm/sigcontext.h >>> create mode 100644 arch/loongarch/include/uapi/asm/signal.h >>> create mode 100644 arch/loongarch/include/uapi/asm/ucontext.h >>> create mode 100644 arch/loongarch/kernel/signal.c >>> >>> diff --git a/arch/loongarch/include/uapi/asm/sigcontext.h b/arch/loongarch/include/uapi/asm/sigcontext.h >>> new file mode 100644 >>> index 000000000000..be3d3c6ac83e >>> --- /dev/null >>> +++ b/arch/loongarch/include/uapi/asm/sigcontext.h >>> @@ -0,0 +1,44 @@ >>> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ >>> +/* >>> + * Author: Hanlu Li <lihanlu@loongson.cn> >>> + * Huacai Chen <chenhuacai@loongson.cn> >>> + * >>> + * Copyright (C) 2020-2022 Loongson Technology Corporation Limited >>> + */ >>> +#ifndef _UAPI_ASM_SIGCONTEXT_H >>> +#define _UAPI_ASM_SIGCONTEXT_H >>> + >>> +#include <linux/types.h> >>> +#include <linux/posix_types.h> >>> + >>> +/* FP context was used */ >>> +#define SC_USED_FP (1 << 0) >>> +/* Address error was due to memory load */ >>> +#define SC_ADDRERR_RD (1 << 30) >>> +/* Address error was due to memory store */ >>> +#define SC_ADDRERR_WR (1 << 31) >>> + >>> +struct sigcontext { >>> + __u64 sc_pc; >>> + __u64 sc_regs[32]; >>> + __u32 sc_flags; >>> + __u64 sc_extcontext[0] __attribute__((__aligned__(16))); >>> +}; >>> + >>> +#define CONTEXT_INFO_ALIGN 16 >>> +struct _ctxinfo { >>> + __u32 magic; >>> + __u32 size; >>> + __u64 padding; /* padding to 16 bytes */ >>> +}; >> This is probably something I a missing but what is struct _ctxinfo and >> why is it in a uapi header? >> >> I don't see anything else in the uapi implementation using it. > This is used by get_ctx_through_ctxinfo() in signal.c and I think > similar function is also needed by userspace. > > Its name is once before called context_info but conflict with another > software, then I want to use ctx_info but conflict with another kernel > struct. :( >> Symbols that start with an underscore "_" are reserved and should not >> be used in general, and especially not in uapi header files. > Then, maybe we can use sctx_info here?
Actually it seems to me that this struct is the header of each sc_extcontext; i.e. one struct sigcontext with 0~N trailing "sc_extcontext", and each "sc_extcontext" consists of one "struct _ctxinfo" header plus the real content. For now there's only the FPU context but the LSX/LASX/LBT contexts will come later. The "magic" and "size" fields also matches the definitions following.
So I'd suggest something like "struct sc_extcontext_head" while naming the individual contexts like "struct sc_extcontext_foo", e.g. "struct sc_extcontext_fpu". The "sc_extcontext" part could use some further abbreviation but the end result should be something intuitive.
> > Huacai >> Eric
| |