From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f193.google.com (mail-yw1-f193.google.com [209.85.128.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 91EE71A83ED; Thu, 6 Mar 2025 08:52:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.193 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741251161; cv=none; b=MtE5NQtFSxRV2E1M1P8XQ728rUNMnsq6M88ghogEct2SK6iBD5A4zBC8DTQuYxtwFV9uuQttlSuqzRR/D2sxmKKXMJC0OR/WKDKTgrjJHQC23HsZvMo2fbYuZdaw7NsqxqR+7qlUmbPs0vL7CRH71jXHbwi+GSb8P5GNeJrwKFo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741251161; c=relaxed/simple; bh=XXs8uZWN9WWnGCHphGrfM+z/OKcBjkW6AX8J7E+t69Y=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nvWLY5dgc4v0EKiA4C0lVkR/6N00tWO9qOTVlp/SuUlo6DmYh2VwZyBd2mUG8smMFksk1f2HMDf8CNNSybkPjNeLjZJcstoIHMI59nin+VopCXeZM3FEIJUYt668ENrHPmMVXyGWi7+621HjOEuzYs/LcQI3unY/tji+TATz/54= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WYL/lECD; arc=none smtp.client-ip=209.85.128.193 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="WYL/lECD" Received: by mail-yw1-f193.google.com with SMTP id 00721157ae682-6ef7c9e9592so3532527b3.1; Thu, 06 Mar 2025 00:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741251158; x=1741855958; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=XXs8uZWN9WWnGCHphGrfM+z/OKcBjkW6AX8J7E+t69Y=; b=WYL/lECD/6JlqWhX9RYHhAA2g2y+5llFJmL2bkMLkoS9yuVVPljQgSBG8lICn7iD5k otAGDP15oBIQJjrIC24CJZzYBsvLOEyQrgGvmQ7VXKcVDRy0g1v7JFQ1B0x2b/VO0K8M PZ71h/h1I4gAmn2qp9sGFGGJkCwA1ecOwplWxIsjcf7NB5/UnVMnYf5yw1Dx6WiR1OM+ 1fVsBlh5a96tjMCUFlk5TS1ujPv0CU2VMMwhfgIdcRrSfq2Ue2JD1JLzvSReg3IVUylk ZQA38y7nR4jlJvwfdAEoJMfzYsW5ER/GpedU2kcRw5YoLb73lFk3eti19JbUrMctagTg QmBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741251158; x=1741855958; h=content-transfer-encoding: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=XXs8uZWN9WWnGCHphGrfM+z/OKcBjkW6AX8J7E+t69Y=; b=u3Dm5FrTpVtpxvABx06usUJrYAaw0N3wKuRjnqil+hPpcW7WQExz6/Q4o9v06YQTC2 s2EgxO18p/jf/XFzL/t7ewCJ8U/jipMHpeybkF0RKjur85gRHcRAiPpvontZiQSUOSdn soiK2Zcuar6CKHm/xPss9PelYZj05BULPJKYNh+igm/+TzH5O2P4BBSExUMYM1h7DLy6 w9NGlfQZ6MajglCrGfwh8IhmHBnoiLbGkDPsiVFJY2iA3QdMWhqzVqclzteyOYTTdEgp czOiYuT5cldeDXtzD//fK929N6aU1ZO38u8QplBSJeMSIJVnrjvZcI5zjU4sRyZ95uTA dPmg== X-Forwarded-Encrypted: i=1; AJvYcCW1mOWHaOXmP0IapArRnt7tDHoD72lI2BCDKwSQhPTLlUbi7U6tnBk/226X1BqWo7Nd7PQ=@vger.kernel.org, AJvYcCW3oOT3+XjTnVzUTrOu66fw8EDk5m249DysahljvLIiFTe0SdiHlcrKDdSpqCosGJPVApEQoJPH@vger.kernel.org, AJvYcCW5U6SwoQBuoQpQaRxEbBHEvyqjC6N6k80NpNuxLGFct4Wzv98hF46094VdvpuCk63GDprx44MIcAaJbmzF@vger.kernel.org, AJvYcCWyAesTNLAt4b9i8uxF11/HZVY6LzLXP/iOirqrtUa1YbkNCLHWengE4RTC/gUGaoWv5hD+oqgYM4MQPFX3oN64PfX0@vger.kernel.org X-Gm-Message-State: AOJu0YxxASEINJGo1aZ5GbPoQPI2XBp0zr2pYOBDXjKgSCrSos3de4ES cdpVjSdFCGApbWwMQ7JhhQw8BkjLQieqXksxygWAQ8U1GGUjipCQThVCElCyqTCe5pZDDt2V+eV HScX1S1czCauYJHvvU6WGop1lmzg= X-Gm-Gg: ASbGncs3WXbzpAca2FJtMZnGMcNAlzivcKQtm/HWVqHHFkh0UCp7Av27ru56FLc+EcK nLYVOlDnpMT8hPXOfExWI7ufY+25evVbRo4n+izPqMlABodjEvXbfoOYaJc3TqtplDMOEqu7KhE KxlZSBvxUeToq8zLhrwDaW2TEWrA== X-Google-Smtp-Source: AGHT+IHUPHaw0YZdo+mDMRAkSmdnWIm6D16Vg79ihR5A4Mv8LJil7rF/h/OfZk/ywEv5+Ey8+JWj4dl2X5zMiVr1zBQ= X-Received: by 2002:a05:690c:2b03:b0:6fe:b88e:4d82 with SMTP id 00721157ae682-6feb88e57c7mr3700567b3.28.1741251158459; Thu, 06 Mar 2025 00:52:38 -0800 (PST) Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250303132837.498938-1-dongml2@chinatelecom.cn> <20250303132837.498938-2-dongml2@chinatelecom.cn> <20250303165454.GB11590@noisy.programming.kicks-ass.net> <20250304053853.GA7099@noisy.programming.kicks-ass.net> <20250304061635.GA29480@noisy.programming.kicks-ass.net> <20250304094220.GC11590@noisy.programming.kicks-ass.net> <6F9EF5C3-4CAE-4C5E-B70E-F73462AC7CA0@zytor.com> <20250305100306.4685333a@gandalf.local.home> In-Reply-To: From: Menglong Dong Date: Thu, 6 Mar 2025 16:50:58 +0800 X-Gm-Features: AQ5f1JpgFvunO0OQTqf93RDkyeUwF-IllYoHkeBCNOU1pNT2c-N8DSTxA6mOAMI Message-ID: Subject: Re: [PATCH v4 1/4] x86/ibt: factor out cfi and fineibt offset To: Alexei Starovoitov Cc: Steven Rostedt , "H. Peter Anvin" , Peter Zijlstra , Mark Rutland , Catalin Marinas , Will Deacon , Masami Hiramatsu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Eddy Z , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Jiri Olsa , "David S. Miller" , David Ahern , Mathieu Desnoyers , Nathan Chancellor , Nick Desaulniers , Bill Wendling , Sami Tolvanen , Kees Cook , dongml2@chinatelecom.cn, Andrew Morton , Rik van Riel , Mike Rapoport , linux-arm-kernel , LKML , linux-trace-kernel , bpf , Network Development , clang-built-linux Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 6, 2025 at 11:39=E2=80=AFAM Alexei Starovoitov wrote: > > On Wed, Mar 5, 2025 at 6:59=E2=80=AFPM Menglong Dong wrote: > > > > I'm not sure if it works. However, indirect call is also used > > in function graph, so we still have better performance. Isn't it? > > > > Let me have a look at the code of the function graph first :/ > > Menglong, > > Function graph infra isn't going to help. > "call foo" isn't a problem either. > > But we have to step back. > per-function metadata is an optimization and feels like > we're doing a premature optimization here without collecting > performance numbers first. > > Let's implement multi-fentry with generic get_metadata_by_ip() first. > get_metadata_by_ip() will be a hashtable in such a case and > then we can compare its performance when it's implemented as > a direct lookup from ip-4 (this patch) vs hash table > (that does 'ip' to 'metadata' lookup). Hi, Alexei You are right, I should do such a performance comparison. > > If/when we decide to do this per-function metadata we can also > punt to generic hashtable for cfi, IBT, FineIBT, etc configs. > When mitigations are enabled the performance suffers anyway, > so hashtable lookup vs direct ip-4 lookup won't make much difference. > So we can enable per-function metadata only on non-mitigation configs > when FUNCTION_ALIGNMENT=3D16. > There will be some number of bytes available before every function > and if we can tell gcc/llvm to leave at least 5 bytes there > the growth of vmlinux .text will be within a noise. Sounds great! It's so different to make the per-function metadata work in all the cases. Especially, we can't implement it in arm64 if CFI_CLANG is enabled. And the fallbacking to the hash table makes it much easier in these cases. > > So let's figure out the design of multi-fenty first with a hashtable > for metadata and decide next steps afterwards. Ok, I'll develop a version for fentry multi-link with both hashtable and function metadata, and do some performance testing. Thank you for your advice :/ Thanks! Menglong Dong