From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FA4C19CC3D; Sun, 25 May 2025 21:53:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748210015; cv=none; b=mSEPmm4Jjlnlo1Tqrphlq8aCTHWadcFVyjaKeQu+hV7EtLJS4KkUMQi/+DGphSacqnVcOPEuYWuMGnTXsuOs2qreM/JRz8eFq0GIisjqLq/Sw9OkJJ/ybdUzs5SQjEXC/LbkDo32/KBji46736+ERETKDqby/qE4F73LwsmWsSs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1748210015; c=relaxed/simple; bh=y5rT2ewj429hL1YZNClBKAuoapp2CjjiHYqsoHYBDa8=; h=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=ivfXgqeQQawE+Act3qu6cJPHXlg2C9Rr1WGWgN2cmDTcH+gUfTWq62Qp8eMh/+ZnjW7AXEjyT46xzM9pNAuFWqcxakVkLnSozkfH4KzYT5OBLjeHBpSkk+9kYid/0nB+RzdPGzEQq3Gr4+SkcwfTCUC29R/FajMtoLLjIhKMqyQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=ceT//yHx; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="ceT//yHx" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1748210014; x=1779746014; h=from:date:to:cc:subject:in-reply-to:message-id: references:mime-version:content-id; bh=y5rT2ewj429hL1YZNClBKAuoapp2CjjiHYqsoHYBDa8=; b=ceT//yHx7F0JqM4+bzORHTA3Hi0DK9vzfTD1ChrJRaNLXIhJqaQrPXuV jeTpNhnEGDPaw8H78PwGHktNfpPl6dAdZnMrVh6xm1h0OeNOrtjXYgAQP HYJvVZ8LewX/ce74CBC3V2xjHqrvNUpVDNL6sJy8F3rmaul/SA3qqMHai 2894vABY/4tUZ5uOvuNyUXGwk9+lY+VakC1LK4rQ/xwTjuuYThHsIEazu MYeuZPolTV3eA+ejC3fihWhKEDYqtSrkTEPhz6SgE0HplDA2/xcMU0C6H ve00bhfgJ3wnSFXHsbgX+rFdoGEUqCKzyEaz8CigT+qrPQKOHfw4ry55i A==; X-CSE-ConnectionGUID: HQGD0TEPSUq8fOLusNMwCQ== X-CSE-MsgGUID: NdAAS2XBR6u4/DLqkNH5Dg== X-IronPort-AV: E=McAfee;i="6700,10204,11444"; a="60435792" X-IronPort-AV: E=Sophos;i="6.15,314,1739865600"; d="scan'208";a="60435792" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2025 14:53:32 -0700 X-CSE-ConnectionGUID: srkUUk2LSiS9AVRoLfAP+A== X-CSE-MsgGUID: abYToWTKQVe6L6ZrKUUaNQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,314,1739865600"; d="scan'208";a="141991367" Received: from ijarvine-mobl1.ger.corp.intel.com (HELO localhost) ([10.245.245.99]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2025 14:53:16 -0700 From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Date: Mon, 26 May 2025 00:53:13 +0300 (EEST) To: Kees Cook cc: Arnd Bergmann , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Paolo Bonzini , Vitaly Kuznetsov , Henrique de Moraes Holschuh , Hans de Goede , "Rafael J. Wysocki" , Len Brown , Masami Hiramatsu , Ard Biesheuvel , Mike Rapoport , Michal Wilczynski , Juergen Gross , Andy Shevchenko , "Kirill A. Shutemov" , Roger Pau Monne , David Woodhouse , Usama Arif , "Guilherme G. Piccoli" , Thomas Huth , Brian Gerst , kvm@vger.kernel.org, ibm-acpi-devel@lists.sourceforge.net, platform-driver-x86@vger.kernel.org, linux-acpi@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, "Gustavo A. R. Silva" , Christoph Hellwig , Marco Elver , Andrey Konovalov , Andrey Ryabinin , Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , LKML , kasan-dev@googlegroups.com, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-hardening@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kselftest@vger.kernel.org, sparclinux@vger.kernel.org, llvm@lists.linux.dev Subject: Re: [PATCH v2 04/14] x86: Handle KCOV __init vs inline mismatches In-Reply-To: <20250523043935.2009972-4-kees@kernel.org> Message-ID: References: <20250523043251.it.550-kees@kernel.org> <20250523043935.2009972-4-kees@kernel.org> Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323328-965883235-1748206555=:933" Content-ID: <8656ab6c-8f8d-81d1-5dfa-740e7f21544c@linux.intel.com> This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-965883235-1748206555=:933 Content-Type: text/plain; CHARSET=ISO-8859-15 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Thu, 22 May 2025, Kees Cook wrote: > When KCOV is enabled all functions get instrumented, unless the > __no_sanitize_coverage attribute is used. To prepare for > __no_sanitize_coverage being applied to __init functions, we have to > handle differences in how GCC's inline optimizations get resolved. For > x86 this means forcing several functions to be inline with > __always_inline. >=20 > Signed-off-by: Kees Cook > --- > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: Dave Hansen > Cc: > Cc: "H. Peter Anvin" > Cc: Paolo Bonzini > Cc: Vitaly Kuznetsov > Cc: Henrique de Moraes Holschuh > Cc: Hans de Goede > Cc: "Ilpo J=E4rvinen" > Cc: "Rafael J. Wysocki" > Cc: Len Brown > Cc: Masami Hiramatsu > Cc: Ard Biesheuvel > Cc: Mike Rapoport > Cc: Michal Wilczynski > Cc: Juergen Gross > Cc: Andy Shevchenko > Cc: "Kirill A. Shutemov" > Cc: Roger Pau Monne > Cc: David Woodhouse > Cc: Usama Arif > Cc: "Guilherme G. Piccoli" > Cc: Thomas Huth > Cc: Brian Gerst > Cc: > Cc: > Cc: > Cc: > Cc: > Cc: > Cc: > --- > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/= thinkpad_acpi.c > index e7350c9fa3aa..0518d5b1f4ec 100644 > --- a/drivers/platform/x86/thinkpad_acpi.c > +++ b/drivers/platform/x86/thinkpad_acpi.c > @@ -559,12 +559,12 @@ static unsigned long __init tpacpi_check_quirks( > =09return 0; > } > =20 > -static inline bool __pure __init tpacpi_is_lenovo(void) > +static __always_inline bool __pure tpacpi_is_lenovo(void) > { > =09return thinkpad_id.vendor =3D=3D PCI_VENDOR_ID_LENOVO; > } > =20 > -static inline bool __pure __init tpacpi_is_ibm(void) > +static __always_inline bool __pure tpacpi_is_ibm(void) > { > =09return thinkpad_id.vendor =3D=3D PCI_VENDOR_ID_IBM; > } Hi Kees, What's your plan on upstreaming route/timeline for this? I'd prefer to=20 retain full control over this file as we were planning on some=20 reorganization of files into lenovo/ subdir. --=20 i. --8323328-965883235-1748206555=:933--