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 A5FE6C433F5 for ; Mon, 16 May 2022 03:52:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239805AbiEPDwS (ORCPT ); Sun, 15 May 2022 23:52:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229590AbiEPDvu (ORCPT ); Sun, 15 May 2022 23:51:50 -0400 Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 03FDAEE19; Sun, 15 May 2022 20:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1652673103; bh=Z71zRCq+dshK3U5Kgw1jKAD9VUgjjOItP3j/oz3YKXc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rulWXkCgxaSLAImIBl0wNW+vvtjmepp2O7Y1CDKpR0hscjCG1Or/EwLHqlhmHvcE7 Bsq8Ad+d2rq9CnAw4fLwI8pGwXgm6ODQdbae50JVxhKkgyFz6ZdC2EYUy9nfWpcUNV RyKnEVek/UrVXNsPPNdONTnOru3nPlJXYXHI0yf0= 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 5853060074; Mon, 16 May 2022 11:51:43 +0800 (CST) Message-ID: Date: Mon, 16 May 2022 11:51:42 +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 V10 14/22] LoongArch: Add signal handling support Content-Language: en-US To: Huacai Chen , WANG Xuerui 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 , Jiaxun Yang , Stephen Rothwell , Eric Biederman , Al Viro References: <20220514080402.2650181-1-chenhuacai@loongson.cn> <20220514080402.2650181-15-chenhuacai@loongson.cn> 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-kernel@vger.kernel.org Hi, On 5/15/22 21:48, Huacai Chen wrote: > diff --git a/arch/loongarch/include/uapi/asm/sigcontext.h b/arch/loongarch/include/uapi/asm/sigcontext.h > new file mode 100644 > index 000000000000..efeb8b3f8236 > --- /dev/null > +++ b/arch/loongarch/include/uapi/asm/sigcontext.h > @@ -0,0 +1,63 @@ > +/* 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 USED_FP (1 << 0) > +/* Load/Store access flags for address error */ > +#define ADRERR_RD (1 << 30) > +#define ADRERR_WR (1 << 31) >> I've searched GitHub globally, and my local glibc checkout, for usages >> of these 3 constants, and there seems to be none; please consider >> removing these if doable. We don't want cruft in uapi right from the >> beginning. > They will be used in our glibc, I promise. Okay then. Seems simple enough, and from my quick grepping these appear to be original creations -- not carried over from somewhere else, so it's already highly likely that some of the userland tools need these anyway, just not released yet. >>> + >>> +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 */ >>> +}; >>> + >>> +/* FPU context */ >>> +#define FPU_CTX_MAGIC 0x46505501 >>> +#define FPU_CTX_ALIGN 8 >>> +struct fpu_context { >>> + __u64 regs[32]; >>> + __u64 fcc; >>> + __u32 fcsr; >>> +}; >> The 3 structs above should already see usage downstream (glibc and other >> low-level friends), so they probably shouldn't be touched by now. At >> least I can't see problems. >>> + >>> +/* LSX context */ >>> +#define LSX_CTX_MAGIC 0x53580001 >>> +#define LSX_CTX_ALIGN 16 >>> +struct lsx_context { >>> + __u64 regs[2*32]; >>> + __u64 fcc; >>> + __u32 fcsr; >>> + __u32 vcsr; >>> +}; >>> + >>> +/* LASX context */ >>> +#define LASX_CTX_MAGIC 0x41535801 >>> +#define LASX_CTX_ALIGN 32 >>> +struct lasx_context { >>> + __u64 regs[4*32]; >>> + __u64 fcc; >>> + __u32 fcsr; >>> + __u32 vcsr; >>> +}; >> Do we want to freeze the LSX/LASX layout this early, before any detail >> of said extension are published? We'll need to update kernel later >> anyway, so I'd recommend leaving them out for the initial bring-up. > Yes, they are freezed. Okay too, I remember these are the same values as in the old world, so it should be easy to support both worlds at least in this regard. >>> + >>> +#endif /* _UAPI_ASM_SIGCONTEXT_H */ Then I have no problems with this patch then ;-)