From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B0DFEC433F5 for ; Wed, 18 May 2022 17:17:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240786AbiERRR0 (ORCPT ); Wed, 18 May 2022 13:17:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47550 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240773AbiERRRZ (ORCPT ); Wed, 18 May 2022 13:17:25 -0400 Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B812A1A076C; Wed, 18 May 2022 10:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1652894240; bh=yVInD2ur8lshXLO5aqsUYWbjdUNfxk5T6cUDSenQZ3I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lZK46HNW4fJXLujCWUhLHT+kiSe/ZidY50cfUAUUDAHliDzwGoesdBndz3PXWbnzB qpzwN8AdlFv5eabPkHgztrrxQifxYbuzEEC5ghng/ZEs3Kl5AsOB8r0OUWXuDMS4cD 9nVNUaEQyyYJ4q0alshFYulLAf8Uk+KSzeIcrhNg= Received: from [192.168.9.172] (unknown [101.88.28.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 4947960691; Thu, 19 May 2022 01:17:20 +0800 (CST) Message-ID: <36f11c19-0cc5-cf56-b41d-6cad4878ddb3@xen0n.name> Date: Thu, 19 May 2022 01:17:19 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0a1 Subject: Re: [PATCH V11 14/22] LoongArch: Add signal handling support Content-Language: en-US To: Huacai Chen , "Eric W. Biederman" Cc: Huacai Chen , Arnd Bergmann , Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Airlie , Jonathan Corbet , Linus Torvalds , linux-arch , "open list:DOCUMENTATION" , LKML , Xuefeng Li , Yanteng Si , Guo Ren , Xuerui Wang , Jiaxun Yang , Stephen Rothwell , Al Viro References: <20220518092619.1269111-1-chenhuacai@loongson.cn> <20220518092619.1269111-15-chenhuacai@loongson.cn> <87ilq294mg.fsf@email.froward.int.ebiederm.org> From: WANG Xuerui In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On 5/19/22 00:54, Huacai Chen wrote: > Hi, Eric, > > On Thu, May 19, 2022 at 12:40 AM Eric W. Biederman > wrote: >> Huacai Chen writes: >> >>> Add ucontext/sigcontext definition and signal handling support for >>> LoongArch. >>> >>> Cc: Eric Biederman >>> Cc: Al Viro >>> Signed-off-by: Huacai Chen >>> --- >>> 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 >>> + * Huacai Chen >>> + * >>> + * Copyright (C) 2020-2022 Loongson Technology Corporation Limited >>> + */ >>> +#ifndef _UAPI_ASM_SIGCONTEXT_H >>> +#define _UAPI_ASM_SIGCONTEXT_H >>> + >>> +#include >>> +#include >>> + >>> +/* 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