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 45FF1C2D0CD for ; Mon, 19 May 2025 12:39:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BED76B00D0; Mon, 19 May 2025 08:39:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 742B76B00D1; Mon, 19 May 2025 08:39:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BCA46B00D2; Mon, 19 May 2025 08:39:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 331986B00D0 for ; Mon, 19 May 2025 08:39:13 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 899B758CF0 for ; Mon, 19 May 2025 12:39:13 +0000 (UTC) X-FDA: 83459612586.05.A250359 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf23.hostedemail.com (Postfix) with ESMTP id 8EA3A14000D for ; Mon, 19 May 2025 12:39:11 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=gty4ZDRY; spf=pass (imf23.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747658351; 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=8TID/8Or9YAzKWADzCmDKYmYbQ3PtBl4rxavpksxXcw=; b=BgngUY75ueS34wIRoflQwYl/2FdMlDjYZldeyCzTbFjcDVIymKLYFwUAMVKsQaVjIjYOsE AvN0ukmjJakRJ/hal/2GNXip+veCCRtVJ5bAhumrYHgEqhhpL4edCa7DpGNUj1ZS0AV9/T L/MpABFT7oB/cV7yaSL+TzoEb3fgsls= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=ventanamicro.com header.s=google header.b=gty4ZDRY; spf=pass (imf23.hostedemail.com: domain of rkrcmar@ventanamicro.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=rkrcmar@ventanamicro.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747658351; a=rsa-sha256; cv=none; b=pH5+BrYKGDao0/YPln//X/zi++bH7ip+r+g8fULfU+S3PXgE3LLM8XiW4yY4D+KQL9Kkei po5n19VmWJGbIFgBogJhjriU5NEVCwJOe32W9lPXmB3FwX4uenVL37UTuEf4BckZsUUDuv EF3xPmxzY/dpZ/YT9cZHf9olD7f8rsg= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-43d72b749dcso3738425e9.1 for ; Mon, 19 May 2025 05:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1747658350; x=1748263150; darn=kvack.org; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8TID/8Or9YAzKWADzCmDKYmYbQ3PtBl4rxavpksxXcw=; b=gty4ZDRYHmFCDA5o/2+wbDwIF9pL06JtfdG+qpIXbaSS6SFLLiQ/8UbhvbkWISzVSn sZt7ZDDcGDcN+mmVoyuR+Vj3Z88F7G/JxnT3abQt5d51IgIYFe8G/ZMoUS1CF+iYYnm/ wHa84MK7oPpuibparnOQsK6oqd6WByVgJ2Y4Poh4W/q0sxMUyd71yTfoKsORGqfq0lcx f0GJgAsIiN9drFRH0gcVUQ0e1VlvPCmEtvuBZoQnplJJCq9osBBL5vw93ggJu3oN5vIu XNLmJgE6+xJpPIZegwGli/1e78fr7lZ76+oK+Yt8JPtHPRvCqDvbq47GmYGdXtti49K2 9CZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747658350; x=1748263150; h=in-reply-to:references:to:cc:subject:from:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=8TID/8Or9YAzKWADzCmDKYmYbQ3PtBl4rxavpksxXcw=; b=kZ2sYrCxQaboSAJShvhLUIlM6g3NQ22QISc2aonj6ZSXlrhcwJOQtK0SSCyRFdCNeZ 4oZ5jOM0Vk6TaYqB4/okGqCK0RoNJ/8T9kKs8arvXEqq6T8Yef75S8fBpUQKzUXYhbBv 2Dc0/MmUXTMJzdiJ0o04L/U5IXH4YfblplhE4gGq4Se784EiIKPAPoq1HBW3M5AVBT1h onKHUVZmRIJGqFdLa7qrJ6GqEp8+UmxRc57UmPQq/Sk9IUROXFC3T1Dyaxyfft+Ub9U8 lCZyOUoLoLZB+Hcp9qQY/36UXRTsELjWYeghlWKRlwmZHymHR7UG0/wuRMeXK9sPPoBQ t97Q== X-Forwarded-Encrypted: i=1; AJvYcCX33pzOtp4rtBi9V/C9jl88N0fW7mdLDM0UTA8lfgavqkqVr8B8pUx+VFmTaHpaPPgppsZNfXY8Fw==@kvack.org X-Gm-Message-State: AOJu0YxKiW2lkQbzktBsnVPbN21qUrLNXI7f3Z3mk/6eLgCURjlCknuT shbo9xMK5DGtxbVHcqywCA6JC0YNN/MyMIJ4vnrzbrAaDzeZ7P6bY452K427EnCk2OI= X-Gm-Gg: ASbGncvdVPb8tUyBZND8d0GFIk9zgIHAFNuBWiMDMwzQo6/czcGcI5z6O4u71tWSHf0 h3xVSErlb3e7DEEhiV0saH+wDqDtbiHnUEWiNaZsGKwbIH94bK3A5YiJknQ1svbYdWrT0+6Sjfj ZCJo05QFJl3fQdpN4oZThZi6nLWfRwyWCW32Ir/rmMKRTTAoYiS4bQD1n00U/QgfXh/HKotXFTh 7DUaSqiDv/tR7NEYnlwfnuMlWahH0xL6CQ4FZHJ8n8FulvMWWbdja4hOuk+1MVFycj9X2T0wlPP imPcV94azF7z2lMvl7V6F2Iq2OW9fStBXKoD1g97ro9GgpUlC/T/AYmORuQ= X-Google-Smtp-Source: AGHT+IFfWi9oi0Jcra9sXbpqrxyg3hOkHnBuCeesfYKMaPVxn3iQR7mctJDpcqzl/F4hYBE/NRWxrg== X-Received: by 2002:a05:600d:108:10b0:43b:c0fa:f9bf with SMTP id 5b1f17b1804b1-442fd7165b7mr23100365e9.3.1747658349729; Mon, 19 May 2025 05:39:09 -0700 (PDT) Received: from localhost ([2a02:8308:a00c:e200:29b7:4911:a29c:2135]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-442fd583f20sm136362615e9.28.2025.05.19.05.39.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 May 2025 05:39:09 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 19 May 2025 14:39:08 +0200 Message-Id: From: =?utf-8?q?Radim_Kr=C4=8Dm=C3=A1=C5=99?= Subject: Re: [PATCH v15 05/27] riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit Cc: "Alexandre Ghiti" , "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" , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , , , , , , , , , , , , , , , , , , , , , , , "Zong Li" , "linux-riscv" To: "Deepak Gupta" References: <20250502-v5_user_cfi_series-v15-0-914966471885@rivosinc.com> <20250502-v5_user_cfi_series-v15-5-914966471885@rivosinc.com> <122fc6cd-2e21-4fca-979d-bcf558107b81@ghiti.fr> In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 8EA3A14000D X-Rspamd-Server: rspam09 X-Stat-Signature: 4ktfpzofczj5g8q7pbb1nph8fkno58a9 X-HE-Tag: 1747658351-284184 X-HE-Meta: U2FsdGVkX18jnOmxxd86AugaPhP9O+/r55K39F8J5R8Bplet7vokuEWib2a665yEKUZS4iSNdXBbFVaJv1BfozD53yXoSB7TRUdxifXux4vg16B3bW6VSgD+qov0rr8tAoWo23nhhNy9ApUEMLSrIPrVRaaGKhsmnNzUU8P6Hp1Cdfcf2FkuJntdjj6bjuuB6e0/TWWPLKRo9k7/OPKKSz/MBr+v0XhdNEsJLwgt2nxly/QzvYEGu4oOCKX+WwLyj7PiO46f3BFjmiV8CFd4s7x0M5ytjF+2u4nbgvhgQWXC+BCHl9ggGPgcIdAyEVCj/eU1OeZhKy0dTA0AqdSjPFpN3CnjKWI8WIH6ST0yAGN+XbO9EczFRvm8wkTRIZkoJ2yKICb7RrPqBqcAXOGtVPqJIaW90Uz5Kw8m7ZtqLMGU6u0mPIF+t/ZabH8yrFGb4GaZp9S7VZ/aU7DkUGcvPIKHqf8o6sOIsetcOal9DXiZVQ8gqchqMVj3gCq/Y6Xg80GPFt7MF+FcybTQC7yAPwnnaoOZaE9w+F4Z3N64Vwag80+1x2mgl3AUpXyQHnYF4aaLBqUz3uwqSfjvLgJqfx40U5uLPeoAnCGqDXztNUO0sJk995ijYAJqmX3/dqJ0vVXo1Fi/W8f/oqy37EJdc0CHL1emT+iuHLSwHB4hcg4GEOGbvKZZekRPs4kJ03WuPGCjuQ+D+G102wpaJo8M+gbQfs0iz5aIBU1eUOb4uKcLSCHDHzi2O22ffu22TkwmQP5iRnFuph7zzfrHgjLJNdDF7IAfjlpDT3PpjxMIvL9+dTTWg0Nq8rP0Lf6y71r4MiVB9obwgpl3jP0z5pE2f2jaqOBRQhmKBUSRYxPWDV5Yu0/sywmh8WpkgUMvgpiJ7tnxjAoF+O821GSTPL6uVb1lnjaMWqv8yNOmdvuH4LDKw7AYtJj5lHLsRhJTSWTj0b0hI1ujqQTJrgkTwCK l2ADtrNL oSR27hRa/gLm46+Vd6Lk8Rew0OQNNGhgCHcefMD+fXD/fVwOc/k9Ck4hROwT5vMzrxMu0lYTeiBOIdyeS+8dIguPg/Kj/OV4XtKLEbUQQOm0jZxheg4JEqTmrXB6epPXRWBh07Gs3iRy9HdFo9WXcFe6r5hFIurBeX0dkr8eNI6RgJNHGAAZDtQuQ6lzEPDuDwax0UHohNnZG3nlKR5ON7EPZuWtvlTTRdWfeEjzMEH73Fehjm6OFO6k2edONa39TB/sxjhMeYxaDZPrJsk4Zy1kBnu3uBQT/vUchciksDL0Ngzp3B3rBjiDRX+3EGJGMw84/ZUCMjH4FpEiAwzbXpB+yTgAy/+UjUIdYi0vuGfmb20u5IwAxEfrkmE0V/OMJ+wNmgD4JfJhZAcvh9++x0Uv4trLE6BCdE7IjfGYCdd49dW6bsr3Ix6dUHxM/PM5dX9nRRh1fDnH6jPia+ShnkW1YviDYVtP/8iTjg1Cd4PwaKV5o32gInVuL95k1qilChPCL4teGKiFDSR1MMG2iO9zCleqz3J3v/ef2WkSHXYZOdMOsD/cAC8sDQgI4HZYrp3yCZB03A1CS88XJoIzIJ77fuWlRGUFubyso6MdzFasJlSlqV0uVoG3PH0InMPptTWvSah+TcjcnjPhFtZhQd0Zw4P0+KQdb3ds9Z3dH2PDdu3jOY5sRwCml9MUW1/SylzH1HRnUYBpxHvE= 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-05-16T08:34:25-07:00, Deepak Gupta : > On Thu, May 15, 2025 at 10:48:35AM +0200, Radim Kr=C4=8Dm=C3=A1=C5=99 wro= te: >>2025-05-15T09:28:25+02:00, Alexandre Ghiti : >>> On 06/05/2025 12:10, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >>>> 2025-05-02T16:30:36-07:00, Deepak Gupta : >>>>> diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S >>>>> @@ -91,6 +91,32 @@ >>>>> +.macro restore_userssp tmp >>>>> + ALTERNATIVE("nops(2)", >>>>> + __stringify( \ >>>>> + REG_L \tmp, TASK_TI_USER_SSP(tp); \ >>>>> + csrw CSR_SSP, \tmp), >>>>> + 0, >>>>> + RISCV_ISA_EXT_ZICFISS, >>>>> + CONFIG_RISCV_USER_CFI) >>>>> +.endm >>>> Do we need to emit the nops when CONFIG_RISCV_USER_CFI isn't selected? >>>> >>>> (Why not put #ifdef CONFIG_RISCV_USER_CFI around the ALTERNATIVES?) >>> >>> The alternatives are used to create a generic kernel that contains the >>> code for a large number of extensions and only enable it at runtime >>> depending on the platform capabilities. This way distros can ship a >>> single kernel that works on all platforms. >> >>Yup, and if a kernel is compiled without CONFIG_RISCV_USER_CFI, the nops >>will only enlarge the binary and potentially slow down execution. >>In other words, why we don't do something like this >> >> (!CONFIG_RISCV_USER_CFI ? "" : >> (RISCV_ISA_EXT_ZICFISS ? __stringify(...) : "nops(x)")) >> >>instead of the current >> >> (CONFIG_RISCV_USER_CFI && >> RISCV_ISA_EXT_ZICFISS ? __stringify(...) : "nops(x)") >> >>It could be a new preprocessor macro in case we wanted to make it nice, >>but it's probably not a common case, so an ifdef could work as well. >> >>Do we just generally not care about such minor optimizations? > > On its own just for this series, I am not sure if I would call it even a > minor optimization. This patch uses ifdef in thread_info, but not here. Both places minimize the runtime impact on kernels that don't have CONFIG_RISCV_USER_CFI, so I would like to understand the reasoning behind the decision to include one and not the other. > But sure, it may (or may not) have noticeable effect if someone were > to go around and muck with ALTERNATIVES macro and emit `old_c` only > if config were selected. That should be a patch set on its own with > data providing benefits from it. The difference is small and each build and implementation can behave differently, so code analysis seems the most appropriate tool here. We must still do a lot of subjective guesswork, because it is hard to predict the future development. We should be moving on the pareto front and there are 3 roughly optimization parameters in this case: the C code, the binary code, and the work done by the programmer. The current patch is forgoing the binary quality (nops are strictly worse). The ifdef and the macro solutions prefer binary quality, and then differ if they consider work minimization (ifdef) or nice C (macro). Does the current patch represent the ideal compromise? (I can just recalibrate my values for future reviews...) Thanks.