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 B068AC4167B for ; Fri, 8 Dec 2023 16:57:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D1FF6B009C; Fri, 8 Dec 2023 11:57:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 459FD6B009D; Fri, 8 Dec 2023 11:57:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D4816B009E; Fri, 8 Dec 2023 11:57:08 -0500 (EST) 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 180E46B009C for ; Fri, 8 Dec 2023 11:57:08 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B6E0DC0289 for ; Fri, 8 Dec 2023 16:57:07 +0000 (UTC) X-FDA: 81544256094.25.A9CFA3A Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf18.hostedemail.com (Postfix) with ESMTP id EB9891C0007 for ; Fri, 8 Dec 2023 16:57:05 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4pIVTrGe; spf=pass (imf18.hostedemail.com: domain of glider@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=glider@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=1702054626; 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=p7eBdMYz2oO1gCYv2gO3b03vyzDyBixdRfjwy6xmbYk=; b=etmnzhbjzDi6xMrAd0oatVD6J0q3Ai6n1y8OZnuPSipIz+jZ4QU6ltCvX9OSSlB8HRhPR7 PKUNZbdUNdSiiSouhGLBX3mDluRYMRBoPYol2HB+h8veU2cXOFRVib6ADRwtF5pkfxGTOv vqjt0JCqMWGzNv9+8+DcDaxGMCWxuxM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702054626; a=rsa-sha256; cv=none; b=zaIdLbZqO5ZMSZCO7aSqc3ukfOu+IAtsbNxxsNF+is4BwJhTwMIGKB4+Bwp/BSqMxCe3OK wLCW9PHFckz2PFE5Tq3plB75p73TXHimuNsGtD7LioIZ2Jg03d0QwmrFQwsButN2Z4lT2I 2K/gxX/0aM3zQeHVLHqCZZMCXJPXk7E= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4pIVTrGe; spf=pass (imf18.hostedemail.com: domain of glider@google.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=glider@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-4259a275fa9so8455131cf.2 for ; Fri, 08 Dec 2023 08:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702054625; x=1702659425; darn=kvack.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=p7eBdMYz2oO1gCYv2gO3b03vyzDyBixdRfjwy6xmbYk=; b=4pIVTrGen4XVJ/nzzWBG57PNRFvgHa7vokDtdruwOFxYB/6jpeLfhCmG2XP2NI5ZMT Ei0V74zdFvglMjs4JB69c2YP1ZXDvij0L+dnUVw8FkawrXMFFhlZneaXy4PDkL3+IbJB PxTCTbSqbQOZgXBixB6K3m3NMOhkd9ZbC0+RGce8lnu40SDvu+e2K9eCCpmRCX9lj5VI SbyU6dUF5UkMZObilHtkwdaiBdzUlc+HvnIfumBtKIjv6RbssDnDtraW5ccSuSJCzNBX NMpjyn/H5OCrKu1/19TPue8CDi+TsvxnMocRTvuWRxFB11gdrVMqhd5CyiP2UESwJ5gq mHSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702054625; x=1702659425; 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=p7eBdMYz2oO1gCYv2gO3b03vyzDyBixdRfjwy6xmbYk=; b=dt0xiBvv8ui08EK8QwxEorWlUI2BVVxsWAL3NkAIWwh1DAlV9HrFmVViM43pO59Ubp dCq+N1OWBj1lkiaM5pb71J0GCyFuKeOrnA1/ap3hE9zJRGuYnDRMG8UuqZnE4KYO0yU9 FQl6I9dxwkwXULSJPDKO1MH2yyZOrXOPF4nlE839CM5fSEHi0zpOGF487c15BBJ+ZAiF 7Qh0+LGKCotNL9rtZ5ozSVM7ZGcu6qvAr45XtdJMpnMkGmZAuWqsDd2s2VB/Dv6rvbHH mvwfjnGZHe2H9TlNW8BBNZn4X4IBnl6iVExbKfGdTIl7W9q8ryPApOTGt/JTrVVm2SJM mseQ== X-Gm-Message-State: AOJu0YyAlTnJMdnVqvqhk/UDkwxe69iVA87bChQwcoJOuXygYmBlXgYQ sX5eNJrR073Qun4f2y9/R+b3W45Y2bPiPCsOKA7HXg== X-Google-Smtp-Source: AGHT+IFqYgMXAGDwUGZm2GmXNNwAMogbqw1hEfBIGvEGXG3bN5nU/GorXmHvariAzFFNL09Kz1paH2mUu+0Ssar9SoY= X-Received: by 2002:a05:6214:d0:b0:67a:49c5:8cc3 with SMTP id f16-20020a05621400d000b0067a49c58cc3mr269853qvs.32.1702054625028; Fri, 08 Dec 2023 08:57:05 -0800 (PST) MIME-Version: 1.0 References: <20231121220155.1217090-1-iii@linux.ibm.com> <20231121220155.1217090-24-iii@linux.ibm.com> In-Reply-To: <20231121220155.1217090-24-iii@linux.ibm.com> From: Alexander Potapenko Date: Fri, 8 Dec 2023 17:56:29 +0100 Message-ID: Subject: Re: [PATCH v2 23/33] s390/boot: Add the KMSAN runtime stub To: Ilya Leoshkevich Cc: Alexander Gordeev , Andrew Morton , Christoph Lameter , David Rientjes , Heiko Carstens , Joonsoo Kim , Marco Elver , Masami Hiramatsu , Pekka Enberg , Steven Rostedt , Vasily Gorbik , Vlastimil Babka , Christian Borntraeger , Dmitry Vyukov , Hyeonggon Yoo <42.hyeyoo@gmail.com>, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Mark Rutland , Roman Gushchin , Sven Schnelle Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9owszu1f55yr81ai46jt3qfe7jaqu9kt X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EB9891C0007 X-Rspam-User: X-HE-Tag: 1702054625-64795 X-HE-Meta: U2FsdGVkX189If1xA59GdPX2zAkkj7dktv5dybFCvAPd5B/e+sj+vnDsdybnek4UUZcH/M5M7ir/V4Ecdg5pPioDDe4atSGrmeeC4yEJj7CFBka23lxXClkF0gbw94v3Jk0cE3sCTynqZVctXhdCQn2KIGz1t08LEDYL2aDrrszIEvlViQHUjm4kOsJ8x91BmrCgrNHi4QLmVNqQ+aAZA+87rgSpnOz8WDpCmgM7tJ7ThkGo3PkMRbseTYhgHL1i5reX78ih1pGUfqbdh35fkPXqgfeSwERDKXCdWMaj6PKQCHNmhBG1/heh2tKszut2MU/dsoN94fX4RqrX3n/Q0lykDHGP0DSt7Uq5s9VXq1rdGNYZkcWp5wjDVLbir5F5bwm4WucY3RuoA5ikgOTj/12+dGzyW3opE1cSrAmj9NOfFf+q24ItTdCEl1w9/M6telUkLtn8aAe/TM+EQV9ssigCkmph4wMBjZ422+JVnADqCUG6MSu5NFqGZIT86TsBZhvn/Oe1lCO2fgp8n0HdvAS5IY0IfgWtdOmBeCmDXHr1vHlkhXNcC0KLFil1SkvAtQdwNjIjBRuiNkA7//fL0Nyr0ZHxe54DmCKfjN7VWhZntCBzHGVjenfU90k6OYGCSUj4uYZIJJYiWU74sgJg565cnrhYahlelwMKuecwWFSZ3in4fFNbzECDDsCsdz1ER52l1H1nydxmGHkg5T8vRww7IZ8B7ToZqNxUlPP90yxTpKDMHKZLyGS8m4vno3j+QoByIOQxdgMrJeWEe/njLABTuvRVlWrPzk3UT6bV6qf2q/bNugjltPCF1sIEqhpBD7M4SAwPdJAviZX2InhnqyXkHyeIhJzWmMrmxkOLFKRZeTJZN+CTF4szSWN8hjRbQHORiAln+aZCvNChL/P6J2xMd/sIuRxyXQ9NBoEIXeqSsaDfJoxziN1PDEud4oiuNBqyOaGOr9ThrS+dNtB KLv3uJlz 8klNyiLAl0g/btmHOwXauve/0Z44GcfJGiTZ4AdFl1SasiPYjhG5+VRj2/Q1CxOMYKgPvrRd6hvPHHq4IWxQ3fLili42w+WMUrn7ir78b2bfK0yj+25WI4nH69vKjDqxtw9igLTeVMCXDmw8ifEPt81KM3LH4BlPZpCg9hgEEoEjdMsJirZjnIygP05g+/moM4tVVbBMOSkE9QDwC6nAUcO7yCGHwn25rOYFUA/6IA27JgUJckzUKAsFHJbUAjZwgcrCzNhd5chb0eIJx5dRFeSQuyD/xgYvoUZgGqa9vqWu/l0HoCQbXcn0KccSkzU2SQAlAihLj1+gufgiTO0wt2xNM//hs/tLwFPrR X-Bogosity: Ham, tests=bogofilter, spamicity=0.011223, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Nov 21, 2023 at 11:02=E2=80=AFPM Ilya Leoshkevich wrote: > > It should be possible to have inline functions in the s390 header > files, which call kmsan_unpoison_memory(). The problem is that these > header files might be included by the decompressor, which does not > contain KMSAN runtime, causing linker errors. > > Not compiling these calls if __SANITIZE_MEMORY__ is not defined - > either by changing kmsan-checks.h or at the call sites - may cause > unintended side effects, since calling these functions from an > uninstrumented code that is linked into the kernel is valid use case. > > One might want to explicitly distinguish between the kernel and the > decompressor. Checking for a decompressor-specific #define is quite > heavy-handed, and will have to be done at all call sites. > > A more generic approach is to provide a dummy kmsan_unpoison_memory() > definition. This produces some runtime overhead, but only when building > with CONFIG_KMSAN. The benefit is that it does not disturb the existing > KMSAN build logic and call sites don't need to be changed. > > Signed-off-by: Ilya Leoshkevich Reviewed-by: Alexander Potapenko