From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 9E6E71F852 for ; Fri, 23 Dec 2022 02:28:12 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (2048-bit key; unprotected) header.d=sifive.com header.i=@sifive.com header.b="Jgkq2vT6"; dkim-atps=neutral Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3008A385B515 for ; Fri, 23 Dec 2022 02:28:08 +0000 (GMT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) by sourceware.org (Postfix) with ESMTPS id 71AA73858425 for ; Fri, 23 Dec 2022 02:27:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 71AA73858425 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-ua1-x92f.google.com with SMTP id k23so801897ual.8 for ; Thu, 22 Dec 2022 18:27:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T5uMSrtLuu9RORD8OGsSVOlpmTM1AJbSU+v28i5O2jc=; b=Jgkq2vT6Nv4Mj5Qx8YcJGsd2E16MF+OnlXNeCVIxPGz7EqovjRVVkPA1RdoJ6gBpyh CYjbRNGL55SHXLkTt7C7HafAUyP6vTTwkbWDPl+R6O65PG6AMngKwTKoL4u+G3TP2JOs jdX8QmEy/+4gF/aJdV5NXi4mmEbmNFixm5i0EkmbqBSCePcgYD1oZkjthFGVr4SQzwdv 9uQ0sSo7BsXGBU6Qds1S0tLC7qTnCLI0cWwjgFJqvNUGKkl/GKKvg2N90y/nQwKM7Eay JFPlxU7s6LiFX5IUc2yVnuHTWPgCXoc9dJSUHlzQ1SSdnLqkl9vPpMW9e9Au9aYO84W7 Txcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T5uMSrtLuu9RORD8OGsSVOlpmTM1AJbSU+v28i5O2jc=; b=E4t6JSlSKXD91xy3uT/jj/6D0VRfIlf7nlFELe6ni7whj8wuJvNzg194ZrxKoSV7LH xiEq7JVo2x0ETu8k7aE1PNV9fMJCbPTld95zjL1SywRea21jdWLSX1KDT2LGHR2MiC/h o7L0i2c1NHmDWO1cwTfKFS98va9zLaD88IIRpcue1u8S9bHCvHFenLPTIHgyHXsCOywl gY6E1tWjncQoaYScNsT40CQDMxT7QNVtqtbFgu9Z0e9Je4SXsYLKlEZy3smJEbcJNp5G 1OvEtDl8uYyRMzFtZwe3toJkwEOi9j59GYRaM1lJeAmSQqUj5aZZdEZ3eTcbzizjh+si paUQ== X-Gm-Message-State: AFqh2kremZ1rTgCdEVpp1q4qznWKsXlv5T1zTr3y5KxKfMfcgvBggWZ/ W7hH2RZufLk0+zjNLTv4Lw37W2Cas+BnHhpDCA3Yww== X-Google-Smtp-Source: AMrXdXuoglMLlAMWmT5MjunC88drKtLEW3p/9VX5wFKbukFrLvBz0VrvHImZZRFKebrgIzXx29wT72oxd5OyB2PadeM= X-Received: by 2002:ab0:1c44:0:b0:419:9e81:21fd with SMTP id o4-20020ab01c44000000b004199e8121fdmr782371uaj.3.1671762470670; Thu, 22 Dec 2022 18:27:50 -0800 (PST) MIME-Version: 1.0 References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> <1631497278-29829-3-git-send-email-vincent.chen@sifive.com> <871r5sd1zq.fsf@oldenburg.str.redhat.com> <20210913135247.GL13220@brightrain.aerifal.cx> <87sfy5ndid.fsf@oldenburg.str.redhat.com> <73c0124c-4794-6e40-460c-b26df407f322@rivosinc.com> <50c598a6-e3b3-3062-abe7-23a406067533@rivosinc.com> <7430f494-9b43-5e03-c1e9-6b83e2611a11@rivosinc.com> In-Reply-To: From: Vincent Chen Date: Fri, 23 Dec 2022 10:27:39 +0800 Message-ID: Subject: Re: Adding V-ext regs to signal context w/o expanding kernel struct sigcontext to avoid glibc ABI break To: Vineet Gupta Cc: Florian Weimer , Rich Felker , Andrew Waterman , Palmer Dabbelt , Kito Cheng , =?UTF-8?Q?Christoph_M=C3=BCllner?= , davidlt@rivosinc.com, Arnd Bergmann , =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Philipp Tomsich , Szabolcs Nagy , Andy Chiu , Greentime Hu , Aaron Durbin , Andrew de los Reyes , linux-riscv , GNU C Library Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Fri, Dec 23, 2022 at 3:25 AM Vineet Gupta wrote: > > > On 12/21/22 19:37, Vincent Chen wrote: > > On Thu, Dec 22, 2022 at 3:52 AM Vineet Gupta wrote: > >> > >> > >> On 12/21/22 11:45, Vineet Gupta wrote: > >>> 4. Kernel with RVV support + user program using original Glibc sigcontext > >>> In this case, the kernel needs to save vector registers context to > >>> memory. The user program may encounter memory issues if the user space > >>> does not reserve enough memory size for the kernel to create the > >>> sigcontext. However, we can't seem to avoid this case since there is > >>> no flexible memory area in struct sigcontext for future expansion. > >> This is not an issue, if we don't change sigcontext (in kernel and > >> glibc) - it is essentially the case of existing binaries. > >> kernel still saves regs on user stack, in rt_sigframe, its just that > >> userspace is not able to access them in SA_SIGINFO signal handers. > >> aarch64 have this implemented this approach and it is likely they can't > >> do that either for SVE regs. > > Sorry, I don't clearly describe the case. As you mentioned, the kernel > > will save the vector registers to the user stack or user-specified > > memory region by struct rt_sigframe in your patch. But, if there is an > > existing binary compiled with the original sigcontext.h, it will > > assume that the kernel only occupies the sizeof(struct sigcontext) to > > save these registers. It will not aware the RVV extension is supported > > and not expect that the kernel with RVV support needs an extra huge > > memory region on its stack or specified memory region to save vector > > registers context. In this case, the user program will encounter > > memory corruption issues if the size of the memory region specified by > > the user program is not enough to store these vector registers' > > context. > > No, it will not. In this scheme struct sigcontext remains same as > before. Kernel is copying the RVV context not in sigcontext, but beyond > the canonical sigcontext, in layout specified in the rt_sigframe. Please > take a look at my patch again. It works. If I understand correctly, in your patch, the kernel uses rt_sigframe to back up all register contexts in the user space, including RVV registers. Therefore, the user program needs to reserve enough memory space for the kernel, which enough size of this memory space is the sizeof(rt_sigframe) plus rvv_sc_size. However, the rvv_sc_size is unexpected to existing RISC-V programs. Therefore, some memory of the existing program may be corrupted by the kernel when the kernel backs up the RVV registers context. > > Again I don't care what scheme we follow, I just want o make forward > progress. > I understand your thoughts and I sincerely appreciate everything you do. > -Vineet >