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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 488EEC369D1 for ; Thu, 24 Apr 2025 11:52:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E36F26B00AE; Thu, 24 Apr 2025 07:52:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE4FC6B00B0; Thu, 24 Apr 2025 07:52:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C37566B00B1; Thu, 24 Apr 2025 07:52:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id A35376B00AE for ; Thu, 24 Apr 2025 07:52:46 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id DCDF66A303 for ; Thu, 24 Apr 2025 11:52:47 +0000 (UTC) X-FDA: 83368775574.18.BF0B19B Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf02.hostedemail.com (Postfix) with ESMTP id CBEEE80006 for ; Thu, 24 Apr 2025 11:52:45 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=ghWr4d2U; dmarc=none; spf=pass (imf02.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745495566; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=s+dd0LSkGUj1HE7Y4OEfSLazS5H3NN900Vi5gbnC580=; b=IAqh5tVvYp5MHnqepwEADXl6nfSLWdAYo8C/046z3Cl+I8xxW2qojFL3saON3oysR+6mgV iQrQuo1Jj5zdi4XxjwodL7aOY7k9bAxHD4ALIFCW9ZxGyHsq+m6qD5IIZ80k/oYv493ldS 5gcmgnrLXHv0pJjT9Fj+sumfYZ9CGYk= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=ghWr4d2U; dmarc=none; spf=pass (imf02.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745495566; a=rsa-sha256; cv=none; b=sgu25Qg2cKZlMSiuyDhAc3NOYmL63/8UJPb0Gh9WxlO0hA6c88UnTozcxJ/dN1cAwufehp T+2vr/kUK/+YErOXfn+L0jiZyNssnAs4w0xX6ECc0l/5WzUj7g/y9uysZbeGt/GAJbST8q i+qude/r+GX3QmDp/bpxYN6IsU2CnDM= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-44069f5f3aaso1256365e9.2 for ; Thu, 24 Apr 2025 04:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1745495564; x=1746100364; darn=kvack.org; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=s+dd0LSkGUj1HE7Y4OEfSLazS5H3NN900Vi5gbnC580=; b=ghWr4d2UGxO3IlrlrP6E04qIK3dLytQVTO8AClLYl9luttKympDKkuesu4VzFMGXiT LRQ0W16H+XYE+A7oAQIarS8F08OEnUBofbCkUEOYv07d1B9Bzftxi2iA5q+y53J1dmwD p4or/dnLMXBzer7+kSHiyJCm9rNLEhLct3BLFRfMDQSeUhp9SydNdspKqPQZBJ94rL6m YzZfcBwXLTUJ35C8CTIVfvYElYQ+d1EjMskMl5GP0FKKZlikI19xkSQBWp0WKhZIQvHL yzIOf3IIf5T3HXdjoaVabxqTFmUUWxn+bK4qwvtBWRvRHx1P0/FPs6qetbp9zaqHEF2x hW4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745495564; x=1746100364; h=in-reply-to:references:from:to:cc:subject:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=s+dd0LSkGUj1HE7Y4OEfSLazS5H3NN900Vi5gbnC580=; b=OnaR2sXM7bkQFeJtOZTvtig7+l7co9jWxbZR+5DmuhbEW+pbykeDEt74gDuU5IAD9J dOXPDfrZ4Qvp8Xx8yt7fIbMx7DaMzEq3yhRUs+Yg207QheQctTWIdcjiHViz/yFAEIBL b35OfPbHqquCqaLUHvC1TUE8WuKB6Qclv+uVnnbHc9DobJ+6lO0FPMEmfajEWJ5sk0Oj fBOkgV0VBSemJmXtuaMDZUZZPAozOHk3jKT8cz5rPLAkE8DcCvcO8iC8n0j7zUWrHq3f ofswk/cgPlTbjavcRHiCjtZrPgwgNE4dZZgrhpj52JwPSiUTi53OW9QQ4KZV8mlvh/oc 0u3Q== X-Forwarded-Encrypted: i=1; AJvYcCVr3jM/ftaacB7008kRs+NrxIDyVNfWQZKIhhp1iTrF5KZH5cSK60g1Nz1aEKLUyXPHBsrGw6xJ5A==@kvack.org X-Gm-Message-State: AOJu0YyYbh7qMMJV4CkZrHKyz0RyuVmKRa3bI3jMk4+b5ZO0rhSX3Ouo umsgjQ+4iWpb04Hg7ubWqz8aSzaEgHRUWhLD7uEoWfoxsT57iZPLZb0Z06aZ7D4= X-Gm-Gg: ASbGncsceA7LlM8kH+3nggVmSGUKuPZFmcf2polsbQsp5lVwnYOblR5lXd1thngliGk y2BouebtwIKpzDYKeJ0nhOpHhncUjUPWf4GZDxuuXM3BbWO/KUmS7pALGDgd+NMJpEWoOV84Ziw wRZvzbOdn0y+g4OojK3C5nEk8SEughsuIXmB9WRlN6Pmd4e5H9xxReubCYpHZapbY3CRSScEPGe 1dQt/5TjIuyapNjuwcWxo6DwmLFvASRB3ThRgJrT+/LvMWy3045us4C0XljoZMagRqGMnVJdSbH GoSZl/0eN7Ci3MXIcEFAJ0jT9MhrwtpE24wbjoFoVyJo4nHi X-Google-Smtp-Source: AGHT+IF8wqwUphleYE2qKoazIUMOkR8h6x1rMfa0xrlvKXCx8csAkRx3P4JsSRpMyeAudqq5D+3jRA== X-Received: by 2002:a5d:6d8a:0:b0:3a0:678f:ddd8 with SMTP id ffacd0b85a97d-3a06cf5262cmr625001f8f.2.1745495563895; Thu, 24 Apr 2025 04:52:43 -0700 (PDT) Received: from localhost ([2a02:8308:a00c:e200:b30c:ee4d:9e10:6a46]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a06d5323casm1860957f8f.75.2025.04.24.04.52.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Apr 2025 04:52:43 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 24 Apr 2025 13:52:43 +0200 Message-Id: Subject: Re: [PATCH v12 05/28] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit Cc: "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , , "H. Peter Anvin" , "Andrew Morton" , "Liam R. Howlett" , "Vlastimil Babka" , "Lorenzo Stoakes" , "Paul Walmsley" , "Palmer Dabbelt" , "Albert Ou" , "Conor Dooley" , "Rob Herring" , "Krzysztof Kozlowski" , "Arnd Bergmann" , "Christian Brauner" , "Peter Zijlstra" , "Oleg Nesterov" , "Eric Biederman" , "Kees Cook" , "Jonathan Corbet" , "Shuah Khan" , "Jann Horn" , "Conor Dooley" , , , , , , , , , , , , , , , , , , , , "Zong Li" , "linux-riscv" To: "Deepak Gupta" From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= References: <20250314-v5_user_cfi_series-v12-0-e51202b53138@rivosinc.com> <20250314-v5_user_cfi_series-v12-5-e51202b53138@rivosinc.com> In-Reply-To: X-Stat-Signature: n9sq73fbeb7tziaw51httoneww9rxhcd X-Rspamd-Queue-Id: CBEEE80006 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1745495565-995651 X-HE-Meta: U2FsdGVkX1+DVzxbzwOBnWIFD5UUmdZk/Nelsj1Xo4OZI//mfA17QFo1PtkbQnICLZX0EsZoQ5WRlPy/2gh7jC87qOGtxiYrDpooGOZpWvgE0XykPpTCzsb0S0CoyfYN5IzAGT/NR8hYlZSA1QLqQG9BsXvEcS7Z2rPIvhY0AzkWYQSycNu64UniPssvnF0J+IOsUIauB4k+bX3SaWfPVzYH4eknClq3oe8SMMoVNE+dSip9yH4jf/xh5Dt+KvX2fH1fPS4pMWEtmfrhKb/ka+ov9GdOOcnadgj++AlbdkkyVqnpLOR1QvMKTo3YZ1XMxtbWSLEA33qG53zPnwtr7EZMVlbDuKrON2uBZAhaSI/ZbsKonITv6+ZQSiPKLEVj7iUiPjq/zaBtu93apC0DP+/KfqAIM4XEabIhG8j8QOiWhzyi4uO2NDgS/NcjiVEQ4IXUXINyd7cxPDXOBi5s/kCLII60YQ5Hph4NKF+juQ+BKFAiDv8DpLLYXhXBwZkuyeGoXi3c9iXDudljvSN0Mg/+0lZrMGwH3b7Fa4CpUCuKTgrM+aXTfbKisSM/yhL/zai1A8WrvnqozbpkHePEWpqRHGWpyjkDl/Gw17To3F8CF7x4iFCXui6F5wK9xUbOiAhlq8dospuNAyn2QO21QajgLUMuc7rwk67gmmIJdow2V5voi1ZJM4GawInGWKftoB69ajLmySjPYh6KRWJfL+rtN7Qcy8C2f37uiXXTi6HwVoglmqqVTdbMiWB4EUhRJMXW0+X3a56HKzcLj3CsODedXSQjKoDuqAmgHEkUhhlx0vV1ZH5ViHbvRDCK/26NdQ1DQOOvP61n4yKTENbHkjE3+J68prhZjd0WdkY7noy8Hb4V+1OiURzh+URue285kH4G7aI1tMJN1V1V9YmRTwSp9Kear7w/bQd3ZHvhnLo/1cq7oIOSqHymRKybA9Rb7/TthlxW6SgznzyNooW Vso7W2Rh +bPo4XcZ6XI4zRenJNkPKpcjW5sckWNvsyhLxlW9tkHaZojqtGbjjREaTNNI064KKnnmXGX0wbzTPsuPlnLUwsIodiNgUzFdoEbLxk6oElUIsCk30MpH2u17+C3oNjvPf2+S9Hb3/4WM5H3OnRFdXNp+pRfoIMNMBDA96YXq1q3RonUVJomvCbRCJ3qeMlQtZyXXuacANPJ+Q4POkpykQJLQDG0EhvnGcQ5qcfizxSu7MNnXIuvA8cSvbF+kTAkFnkkysZ9onxz7O0toBIczVgHKe2An/4hk9XnUgE0Bg6bm12tbIrZtOVengyJqOmOMsGfxlcGsILxVVmX7uScoVEVJCsCrGHIhYd20eiZ2eJajeZ2t7fHgkPDCDK0Gg/R6CsOAxy0re2DAjLCk/7ssX2euxM9kqFOMUa7yyqdCs7Af3cCqj6Ab4JwKCnbSdcoqVZ9SUcH3PNil2Y5V15p1rrG7w5xDsYzAsNCIEYHa23l56GOOdVKubWLnE5+JXMqtdMcFn4cHACyPkWTXhvVx/qj74CmiPaRk9eNJY2dD/yk+iWYZxoGs9lQA+2DZyydxQRRcCTK6tjuqG0BZKUIrLMrNSC6lNjiz/MFph+D0tLFf8Eoqbzg586y5xtMwNoe/zYkiSktvLC6OfInc8e+rOHcST6fD7Sg6BWVgdKNF9JanUk0tDesmT1rYaoNf8Sv/PzdxiDCjrkvJ8WSI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 2025-04-23T17:00:29-07:00, Deepak Gupta : > On Thu, Apr 10, 2025 at 01:04:39PM +0200, Radim Kr=C4=8Dm=C3=A1=C5=99 wro= te: >>2025-03-14T14:39:24-07:00, Deepak Gupta : >>> diff --git a/arch/riscv/include/asm/thread_info.h b/arch/riscv/include/= asm/thread_info.h >>> @@ -62,6 +62,9 @@ struct thread_info { >>> long user_sp; /* User stack pointer */ >>> int cpu; >>> unsigned long syscall_work; /* SYSCALL_WORK_ flags */ >>> +#ifdef CONFIG_RISCV_USER_CFI >>> + struct cfi_status user_cfi_state; >>> +#endif >> >>I don't think it makes sense to put all the data in thread_info. >>kernel_ssp and user_ssp is more than enough and the rest can comfortably >>live elsewhere in task_struct. >> >>thread_info is supposed to be as small as possible -- just spanning >>multiple cache-lines could be noticeable. > > I can change it to only include only `user_ssp`, base and size. No need for base and size either -- we don't touch that in the common exception code. > But before we go there, see below: > > $ pahole -C thread_info kbuild/vmlinux > struct thread_info { > long unsigned int flags; /* 0 8 = */ > int preempt_count; /* 8 4 = */ > > /* XXX 4 bytes hole, try to pack */ > > long int kernel_sp; /* 16 8 = */ > long int user_sp; /* 24 8 = */ > int cpu; /* 32 4 = */ > > /* XXX 4 bytes hole, try to pack */ > > long unsigned int syscall_work; /* 40 8 = */ > struct cfi_status user_cfi_state; /* 48 32 = */ > /* --- cacheline 1 boundary (64 bytes) was 16 bytes ago --- */ > long unsigned int a0; /* 80 8 = */ > long unsigned int a1; /* 88 8 = */ > long unsigned int a2; /* 96 8 = */ > > /* size: 104, cachelines: 2, members: 10 */ > /* sum members: 96, holes: 2, sum holes: 8 */ > /* last cacheline: 40 bytes */ > }; > > If we were to remove entire `cfi_status`, it would still be 72 bytes (88 = bytes > if shadow call stack were enabled) and already spans across two cacheline= s. It has only 64 bytes of data without shadow call stack, but it wasted 8 bytes on the holes. a2 is somewhat an outlier that is not used most exception paths and excluding it makes everything fit nicely even now. > if shadow call stack were enabled) and already spans across two cacheline= s. I > did see the comment above that it should fit inside a cacheline. Although= I > assumed its stale comment given that it already spans across cacheline an= d I > didn't see any special mention in commit messages of changes which grew t= his > structure above one cacheline. So I assumed this was a stale comment. > > On the other hand, whenever enable/lock bits are checked, there is a high > likelyhood that user_ssp and other fields are going to be accessed and > thus it actually might be helpful to have it all in one cacheline during > runtime. Yes, although accessing enable/lock bits will be relatively rare. It seems better to have the overhead during thread setup, rather than on every trap. > So I am not sure if its helpful sticking to the comment which already is = stale. We could fix the holes and also use sp instead of a0 in the new_vmalloc_check, so everything would fit better. We are really close to fitting into a single cache-line, so I'd prefer if shadow stack only filled thread_info with data that is used very often in the exception handling code. I think we could do without user_sp in thread_info as well, so there are other packing options. Btw. could ssp be added to pt_regs? Thanks.