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 3F5BFD0C609 for ; Fri, 25 Oct 2024 13:21:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C640F6B0088; Fri, 25 Oct 2024 09:21:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C3AC96B0089; Fri, 25 Oct 2024 09:21:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B028D6B008A; Fri, 25 Oct 2024 09:21:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9103B6B0088 for ; Fri, 25 Oct 2024 09:21:25 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D109E160A66 for ; Fri, 25 Oct 2024 13:21:02 +0000 (UTC) X-FDA: 82712185500.26.84DFB91 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf24.hostedemail.com (Postfix) with ESMTP id 65182180012 for ; Fri, 25 Oct 2024 13:21:20 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="rIco/W7/"; spf=pass (imf24.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729862328; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7bTA5XEv/pSAM+W1H3oIEVE2GosaAWU3ljRxi1KlB14=; b=GmbZMKpA+cyWxcYVMxHY+Rntx0stkzQ6YxzlgBaG71A14YjLJMoMKyiRWRN31lN6ORmYIw NoWEsN2yV72QLzahhf85wewGQY2Xo1try9vHLG0sCVuKp6qOF2sh1DuG3Zw+T4ThlBiEfM msTuH8V1Mt+lxCZYys4s+8T5TCGu8qg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729862328; a=rsa-sha256; cv=none; b=FTxVhHtbTKq/LklFhUD1j9gmpHJZwowPamoseoMKI1Qbl5Oz0DE8K6JJzM6CZpqY2wP1lD 4nH9GdlxPS4MMYQCBPZWKCwDTXdeQAN6o4mep/aZ0Npgnjku8BVqfw6sudj3eWYb/tv87W meV6KDN3aRc/C9bzle91Svyjsyfu5ss= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="rIco/W7/"; spf=pass (imf24.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-460969c49f2so260591cf.0 for ; Fri, 25 Oct 2024 06:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729862482; x=1730467282; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7bTA5XEv/pSAM+W1H3oIEVE2GosaAWU3ljRxi1KlB14=; b=rIco/W7/FhUnNzQ0begDUfIqTa3X6oxk33Ny5uGdKGs6h0Y7dQpPv0rJ/A4p0HAN2n q1dxbZ4wZsB9faZUAppnRPE3XJ13SCe/mpQ9Ki8ql+QZa1Zh5SjmXPLE32D+C3xOHcYo OjFtryMFhm8g3QiePTZ2LVl/ADMlY/NQhZA0WCkwl/W9hSfICarvTf0YRgLgkCY9ZLZE pjgKseHWBdH5fgYEhGkoFF3cPUK4IZWP4O+Kd4B66R8a5m1VGQLPGRgWg/HoNsUcRKHE RMD8+cIxOAi7iE+nmwB0wF6qYge+6pYYkhNpZHiJmIQu8ukp7YjJP5XzIOCw4D1ciE1E R2Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729862482; x=1730467282; 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=7bTA5XEv/pSAM+W1H3oIEVE2GosaAWU3ljRxi1KlB14=; b=VgtqLFuyvAnKnel0nBP+AO6t0jvkCQk8+K0/cSJpBYkemdLxqp5m6D6uODp0+J8GcF /O3KXUoqzKSetNFvGj/L77tZIMNaL+Q+P7XeromoNh22tHmfpyqxcUz7rrLf33uBj5cd LbDJs4DC0x8lF9E0XsRaVtUAOIb9+TeSxPOBkuqk/J6FgkqMu4C9vTyRLn966d2uS+Lp w2ak3bSOkZhedx1bJ21h/HbzZgdlCblCH6eu5/cgK/TQTrHkXLE4Tw/k59S8GtbHeOKd Z+FMV96uDziZMmB0ReXvze6h6qs0CcZc6sS80+rvbhXm6Zcwa/gl55IkEPsZt7bsYChk 7sew== X-Forwarded-Encrypted: i=1; AJvYcCW1k+1wdHbeTj6MvEUVjctVcX7/FjnzKe6tH0pC003ib3mp6SQpWvz4+kvuyA0t7DE7MyhuXgmB7Q==@kvack.org X-Gm-Message-State: AOJu0YwSUclVjAlms7AZFhDK+c/btiw2J+HsiMYMJkij3I6GH4/Qr0EZ cR8VQV1gYkNm6C1PhtGV7gQSVh46xmioeHZcapZ/GwslMB2f/WNAzh9OheQofdmBfBX78wyGVsY rKJ5hgzYBV41CAGpmelaB+J2o91Asgn2cTaXx X-Google-Smtp-Source: AGHT+IFLcF2W2NrORj/Xb8SC12qeyC5KVAM9B79QtrQcqFpidlzCS6ayGMpyXO+mm8gBR/NQWaXXOnPJfjuALjSAZEE= X-Received: by 2002:a05:622a:152:b0:460:4638:78c0 with SMTP id d75a77b69052e-4612eb81fbfmr3022001cf.14.1729862482147; Fri, 25 Oct 2024 06:21:22 -0700 (PDT) MIME-Version: 1.0 References: <20240712-asi-rfc-24-v1-0-144b319a40d8@google.com> <20240712-asi-rfc-24-v1-1-144b319a40d8@google.com> <20241025113455.GMZxuCX2Tzu8ulwN3o@fat_crate.local> In-Reply-To: <20241025113455.GMZxuCX2Tzu8ulwN3o@fat_crate.local> From: Brendan Jackman Date: Fri, 25 Oct 2024 15:21:11 +0200 Message-ID: Subject: Re: [PATCH 01/26] mm: asi: Make some utility functions noinstr compatible To: Borislav Petkov Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , Andy Lutomirski , Peter Zijlstra , Sean Christopherson , Paolo Bonzini , Alexandre Chartre , Liran Alon , Jan Setje-Eilers , Catalin Marinas , Will Deacon , Mark Rutland , Andrew Morton , Mel Gorman , Lorenzo Stoakes , David Hildenbrand , Vlastimil Babka , Michal Hocko , Khalid Aziz , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Valentin Schneider , Paul Turner , Reiji Watanabe , Junaid Shahid , Ofir Weisse , Yosry Ahmed , Patrick Bellasi , KP Singh , Alexandra Sandulescu , Matteo Rizzo , Jann Horn , x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: h7ht983mbup3mb5ku5y6xi3ff8hrg9dj X-Rspamd-Queue-Id: 65182180012 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1729862480-908387 X-HE-Meta: U2FsdGVkX18MIWeaP3TFPkSWS3yeEvfJ+GAyd85Stfvf5LQRSi6x504/kuIdLK9veEjSPeM1+iJFP6YySxsSkmiVAxrbgnJ9O5DOY/874B8ggsJXeMv9QNK5JswqWbaq3IKrIYLKjEDcmVo03ED71D6D3BtGM4JiVtBSnp5ZzaXfPGBvT6WilazCxB3IivNMTjvKvPo14fNt5L5AOMS2w0C3ARtZKlY7NxsYmnX9+sfC62f/CoX/MOhwQIl/3MDfC/h0BqtnLq2pA2GxZ2O1P/JIDH2zZ92NgJMHq7DTddIp9g8QhH/m5XsW+nGkErFk1E7Fuf1DnuI9gObLG3YeO0/wKc9fPWUr7PIIpP/nx52MqSj7eAUbx/VS+g8NnmzON4wAQuVfTdXa4MulkhBqRkebDI9xYB3qZtVAGpTGIHyCD7sY4Ri/gVMFD9rVrOyC/bIDmk2GDjwmXwcoCUWyIxfHiCdbk3qTXi++RrmHrK25FKM/iwy3B9yW2R1y+IGmXI0VgBjAJJ31l+42VZ+w+90buhqok6gZAX0GwkhB7CjZ0Rmth+PHfYbQTFolfkS0MQ6gHxXk2lTZvbTw13Bwkpfm73FsQYuufv0I/YbAX56obGy24ZNjCbJNuy2wG0gtu+oRk11wAH9HREyfjkA0K2/wQI49zLNaWhAOmw8vBr3W9XXFW9MUBnhKvWIxmfjLsvPuLEoU3Wbtc0l9/g9uDcZkaMh0cwAXIkSY8ld1qgpzO7zE/txA9IWcAolZcbXdsYuCSPwV94kj14PrpQ/QoPJx8QmzwtkoYzwI6uce8EwUUTGRbEWnpXVp+N7TyuxyKMYcNA5J1IuYn5n8yVsdhiSVEr/EuTbXtqd0zMLMx/iThX1Vem0upAOp2mLgAwj0Nur3vg8VQy4ql4y9ZG9BJN6oRuEEnrdqfxH+7qFGrJVR5xgEzoS6oT2A7JN9fS5G6tlBOG7+3YiNIN9JPN5 VpBUWCof mDAWBt7FWn/E2kmXuwxrWklNY0jUgWpIGktLfRI3VqGhqC75ZMoH7S6545Nyxy2OeYDCoiOw5EMBJVff3aOEu5Z+dPsYYIkUbDP4ncK4CtB6OqGRMQjBpCZbn7pEGQIqfFrbsLFNNwAx3Wq3hfCTi2CqsQAmL6vwOvBFGM04hM1rZX/wcfidecofTRoTNRr2sRHkz 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: Hey Boris, On Fri, 25 Oct 2024 at 13:41, Borislav Petkov wrote: > > On Fri, Jul 12, 2024 at 05:00:19PM +0000, Brendan Jackman wrote: > > +/* > > + * Can be used for functions which themselves are not strictly noinstr, but > > + * may be called from noinstr code. > > + */ > > +#define inline_or_noinstr \ > > Hmm, this is confusing. So is it noinstr or is it getting inlined? We don't care if it's getting inlined, which is kinda the point. This annotation means "you may call this function from noinstr code". My current understanding is that the normal noinstr annotation means "this function fundamentally mustn't be instrumented". So with inline_or_noinstr you get: 1. "Documentation" that the function itself doesn't have any problem with getting traced etc. 2. Freedom for the compiler to inline or not. > I'd expect you either always inline the small functions - as you do for some > aleady - or mark the others noinstr. But not something in between. > > Why this? Overall it's pretty likely I'm wrong about the subtlety of noinstr's meaning. And the benefits I listed above are pretty minor. I should have looked into this as it would have been an opportunity to reduce the patch count of this RFC! Maybe I'm also forgetting something more important, perhaps Junaid will weigh in...