From patchwork Wed Mar 27 19:36:02 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Palmer Dabbelt X-Patchwork-Id: 1917037 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=qNfBNDmR; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sourceware.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=libc-alpha-bounces+incoming=patchwork.ozlabs.org@sourceware.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4V4g4k0yG4z1yWr for ; Thu, 28 Mar 2024 08:37:42 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6550D385E45F for ; Wed, 27 Mar 2024 21:37:40 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by sourceware.org (Postfix) with ESMTPS id 454D43858D20 for ; Wed, 27 Mar 2024 21:37:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 454D43858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 454D43858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::42c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711575442; cv=none; b=CDboUQJ6NROBFl7QGQg1qEpa2Ls03N61f43nJkiG/pmR0xN+tNTCVfl7NCZNprGZXAcgwF206CO/lCPqs57c9jYmm2ijJFk+CFyD9ci/w96RVaPOvRSnqv3g1+KnfzAXJg4d1XDRkxNtL7ZCBKh+Asu9Tz5Hu9E2b4STPtK2Pp8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1711575442; c=relaxed/simple; bh=rk0jF1rA7taBGQ0C7tzSgpTSLnlgkC3XAbsHXdBebMw=; h=DKIM-Signature:Subject:Date:Message-ID:MIME-Version:From:To; b=Huc6ThfduQovlxme1rqTOK7gNCqg8FZsu2WhJ3QokythupQs1izDwpo7SHHPPLKaEaEsIbpw1hHu9XwlnCad63tD/IeWF/B8JuRWX8PGrqHpWyKeEpMwFOtIuLlDAIF4NQuSkM/wcM+UZpf4ClgzqSRkkdxQ5T4+55j5pIAZqy4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-6ea8a0d1a05so935488b3a.1 for ; Wed, 27 Mar 2024 14:37:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1711575439; x=1712180239; darn=sourceware.org; h=to:from:cc:content-transfer-encoding:mime-version:message-id:date :subject:from:to:cc:subject:date:message-id:reply-to; bh=E5Zu/03lQMkrijQ0XD+I26zQ6FnMu7RYlfI2B67qpYk=; b=qNfBNDmRuTYC0/oypGE/T/hrJVcpPP/yOEc3mrtQCgj9Kl4DReTUqDUujJha7DUQ9b Qvbk5MYSqvIrZuPMPKaN38AGlt8I+L6ZdhSN6b9XRzp1rB35Qzd5k7NMmvLYejucH7wc guw/iAZpCBEHVoTHCwlbg4wVaOmxzD1EX9bgp9R9MJXHL3zGXd546vp6Aki5EOABQMBD wzvRuXsY89J6zrLEOnoIvacsPPlopnndOtspPEbBzBLu/8VqfsNZgSHigOhvKTrsP6z3 FHQJUKz+vaQk0cejWe1lPEodWg9jefCWL+li3IR9TRZEMzp1ZpMx2OhPHsRu7gZNbrQy Nn2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711575439; x=1712180239; h=to:from:cc:content-transfer-encoding:mime-version:message-id:date :subject:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E5Zu/03lQMkrijQ0XD+I26zQ6FnMu7RYlfI2B67qpYk=; b=hCWildBC1fLAQQgdYhsZL0w+Xr+pYbYuctHD9gEQPedNh7xlpl+6PGP6FA9OBwYKRz ARrGsFQWKBpqsPfOSuHNk/dD96wT85PiZzJdhXfyGOuxp4Q9c0M+1pz2MmbHXAHTF7p3 +fotzZXrJNS9qJodaRv0GMutcJuj71alpA5vokVo9I/tLb1xbuygOIgUe9I5cSK3YjSh DkSaHz8wIr1JX+sP3TVm/ng2C9LAkmtEZuASeVGe6CdM1Zuewr6Iyz52d90vnizGSxV2 SaftDumgy9Bseg8nxF2GCFsyP5qacIICdmuAXoCQEuaLsBXQx5GHaw8EoY6zXq8SDJqN cLoA== X-Gm-Message-State: AOJu0Yyjrl/iGFy4kAVm7304U5FNMUR25Kmrdea8G8yrJxeO8WOvcp3M LYE7MyFO+l3THuClPEuxtdT5JSxnRuDXE7X79UNIRCVtP1uOu+A47CRXTLIXzXw= X-Google-Smtp-Source: AGHT+IGsTcPtE6PeO4wyRP3fYU2wOa0kIOUppNx1fahubOWivwkoXRbEB374L5N84XuCXWDSdqisIQ== X-Received: by 2002:a05:6a20:12d6:b0:1a5:6be8:2d70 with SMTP id v22-20020a056a2012d600b001a56be82d70mr358611pzg.21.1711575439100; Wed, 27 Mar 2024 14:37:19 -0700 (PDT) Received: from localhost ([192.184.165.199]) by smtp.gmail.com with ESMTPSA id h6-20020a056a00230600b006e580678dfbsm2447pfh.193.2024.03.27.14.37.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Mar 2024 14:37:18 -0700 (PDT) Subject: [PATCH] RISC-V: Clobber V state on system calls Date: Wed, 27 Mar 2024 12:36:02 -0700 Message-ID: <20240327193601.28903-2-palmer@rivosinc.com> X-Mailer: git-send-email 2.44.0 MIME-Version: 1.0 Cc: Palmer Dabbelt , Vineet Gupta From: Palmer Dabbelt To: libc-alpha@sourceware.org X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+incoming=patchwork.ozlabs.org@sourceware.org The Linux uABI clobbers all V state on syscalls (similar to SVE), but the syscall inline asm macros don't enforce this. So just explicitly clobber everything. Reported-by: Vineet Gupta Signed-off-by: Palmer Dabbelt --- Vineet's been debugging a userspace hang, and it looks like it's uncovered at least three issues: * Linux isn't properly tracking V state, which results in some signal-based userpace return paths missing the V state save. This is almost certainly a Linux bug, Charlie is looking at it. * GCC only discards the V register state on function calls, despite the ABI also mandating that the V CSR state is discarded. I'm not 100% on this one as I don't really understand the vsetvl passes, but we were talking about it on the GCC call yesterday and that's our best guess right now. * glibc doesn't mark the V state as clobbered by syscalls. I don't know if we can actually manifest incorrect behavior here and it definately doesn't build (GCC doesn't support vxsat [1]). I'm sort of just sending this as a placeholder, but I figured with all the other chaos I should send it rather than risking forgetting about it. [1]: https://inbox.sourceware.org/gcc-patches/20240327195403.29732-2-palmer@rivosinc.com/ --- sysdeps/unix/sysv/linux/riscv/sysdep.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sysdeps/unix/sysv/linux/riscv/sysdep.h b/sysdeps/unix/sysv/linux/riscv/sysdep.h index ee015dfeb6..3e3971e321 100644 --- a/sysdeps/unix/sysv/linux/riscv/sysdep.h +++ b/sysdeps/unix/sysv/linux/riscv/sysdep.h @@ -354,7 +354,17 @@ _sys_result; \ }) +#ifdef __riscv_vector +# define __SYSCALL_CLOBBERS "memory", "vl", "vtype", "vxrm", "vxsat", \ + "v0", "v1", "v2", "v3", "v4", "v5", \ + "v6", "v7", "v8", "v9", "v10", "v11", \ + "v12", "v13", "v14", "v15", "v16", "v17", \ + "v18", "v18", "v19", "v20", "v21", "v22", \ + "v23", "v24", "v25", "v26", "v27", "v28", \ + "v29", "v30", "v31" +#else # define __SYSCALL_CLOBBERS "memory" +#endif extern long int __syscall_error (long int neg_errno);