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 A317EC4167B for ; Fri, 8 Dec 2023 14:26:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 177B36B0095; Fri, 8 Dec 2023 09:26:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 128326B0096; Fri, 8 Dec 2023 09:26:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 015956B0098; Fri, 8 Dec 2023 09:26:00 -0500 (EST) 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 E704E6B0095 for ; Fri, 8 Dec 2023 09:26:00 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B5ADDA108A for ; Fri, 8 Dec 2023 14:26:00 +0000 (UTC) X-FDA: 81543875280.25.25A1DA2 Received: from mail-oo1-f51.google.com (mail-oo1-f51.google.com [209.85.161.51]) by imf22.hostedemail.com (Postfix) with ESMTP id C95B2C001A for ; Fri, 8 Dec 2023 14:25:58 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=t29aD+EP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of glider@google.com designates 209.85.161.51 as permitted sender) smtp.mailfrom=glider@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702045558; 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=gMzKOjsadOdlzFzBDSAqUHFYwgT1E5TMaJuAbqx/ofA=; b=3Eh4h0nbPjCjZhYrr3sf81QrGI3JzHPuLnFXrf2Fe+a5P2FyYpfV92lntM5B+AIlz+Xlcp s3XQbV/PBcvyDAZt4os+J/J4d2YkU3oili4lYxJaBUHnWaGF+SCwaoSpxgvNJb8qKLtD/L CtDk+ip4HrCIw3v4KFQq44eyyZoI2zE= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=t29aD+EP; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of glider@google.com designates 209.85.161.51 as permitted sender) smtp.mailfrom=glider@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702045558; a=rsa-sha256; cv=none; b=33Yb52jNyD/hsXY7mrxZCVVWTHNfS8HsC+WYFdFwsUjhFnClIJwAZshjypJuUzWs5+z+4w f50BUMKf0mG2N64Agd9svUAQOFp61JzWcsCiype09Ws1xlpkcJxyDchZU4/TH4uyVNRzBk WqQyAbaDdeZVjOemrDpPZIOlPBaQqqA= Received: by mail-oo1-f51.google.com with SMTP id 006d021491bc7-58d956c8c38so1048815eaf.2 for ; Fri, 08 Dec 2023 06:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702045558; x=1702650358; 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=gMzKOjsadOdlzFzBDSAqUHFYwgT1E5TMaJuAbqx/ofA=; b=t29aD+EPkj9SfKadcKiNE9WWgm/Leg3OM5nfczTFrqV80tT4p9evcUqit4vm0LYou4 Rt83iRA73bJDv033jtOm68PH+AubNtLUXbhzHYYCsrj3ZlJ3V4v++2kqJIzAtPzyZkWO Hj87SRpuzxct6Hdzfxlkb6r5IANrZqXaQK5vS25eyK7bmZ8KcMtl+BTXUMRSEXXs3WcB 089D8P+4t2Z5IJdxVZ91EzrJb57hQGB+kRHY9QCLNhF1wBlbUMuN+1Ty4X58cxgzgdAn NncpJgak2etOTiD/L+7aHUcMgsp0UZ5X5FgH4OMIiKuIO+iI9ZSnH3tu16z2y5uJlFn/ KLww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702045558; x=1702650358; 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=gMzKOjsadOdlzFzBDSAqUHFYwgT1E5TMaJuAbqx/ofA=; b=LNVGN4Rne2VkvQLag/FjowCMlB3LhGRbQ1Z+Kr5wB4VKOmm4c/EwTK5HW/bjI5b9V/ ERQnYmsWuVa8VrTdvMmuevTI/7DhArXJnWhr0nxLZCQRr5/SzY5qo370eciIm/WMx6rd ZdIAjTVxtdK0x9yHFe34e4W6gFc3ZrXIGmAEg4cWHxcXpQL9CE2tspdSGJ4tF0S3MovK Ctni51xTF3m/lSM5Dzv423rgcN1KUOrpVr4XHhbVayHHfIXAlUdrObtCU6V/DTGwTgDX 7YUQMkzIs2gbEC33aElSfLZgy6Z88n4mjbM+MP5VatThHKknJPkZCIkV+QJuNsIxgXOL dDAg== X-Gm-Message-State: AOJu0YynYmqQocim68bE5XUW6TrEakA6Fh5j96m/QjAbZzFRbCH4Gga5 XD3ZMymXixjobMLWvO5PillZEycxYQ4UmX5mixcoSw== X-Google-Smtp-Source: AGHT+IE/E5Zk6lpM+Q8iq+g4LL35DztvA78a9rnsgBC2xnye70UOmh2YC4gbKyaDqDSFpsQYE13Fz8eacxBaFlVCob8= X-Received: by 2002:a05:6358:10c:b0:170:4403:83a6 with SMTP id f12-20020a056358010c00b00170440383a6mr3947511rwa.52.1702045557641; Fri, 08 Dec 2023 06:25:57 -0800 (PST) MIME-Version: 1.0 References: <20231121220155.1217090-1-iii@linux.ibm.com> <20231121220155.1217090-20-iii@linux.ibm.com> <4f0eb4b4d4f6830f39555dc8a35f6ff88d6f8e63.camel@linux.ibm.com> In-Reply-To: <4f0eb4b4d4f6830f39555dc8a35f6ff88d6f8e63.camel@linux.ibm.com> From: Alexander Potapenko Date: Fri, 8 Dec 2023 15:25:21 +0100 Message-ID: Subject: Re: [PATCH v2 19/33] lib/zlib: Unpoison DFLTCC output buffers 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 , Mikhail Zaslonko Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: C95B2C001A X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: q4oncx5z41jkpan7ausnn3qijdc916mm X-HE-Tag: 1702045558-602859 X-HE-Meta: U2FsdGVkX18+aOnYnFMebQZbquVWw/Bfs5wKdi13TbQ4IuGK/6AzKFNezrW7G7ENvuTC/5Vchs0dmuVNDU3S4r38SkQzedRibtiqVyKrmIIXX5E+Qiz0oepCRZnSt0O5Q9plxzwcESnPlu2bPxlCkZMGh3oSTvH/Gv2QWqeOf803d3habCA/D2OcJUW7FNKn+PReLUUZaoy9bP4XlYArFYU6bMNnuBtfP3XwOuGkKQTak7aLbJp2n0DloA4nuZE1OuhhILD7hPcbYAh/+cfqJLx/IoxB/7oEaFd8IyIHhOnDCbvnRazXF1lrbVCzrnWhf//Az4UM/pfNUB6VY/PlX1vQFBG0709PB/x1bhfwxWo2RRJ9j0jU52F79zT1LREhubm4HRRdNWHdTu0KhajQU358TVTwxWz0FAg58FKLuPaLYfyRT+So+TfJCFGDUYvVtZMeKvSyxfTvGeCwlJJzOZQWmToUn3JHu19znMPmzLCrn1GiD0iSVug/o/RjVsJ3CLPv8UnKw7juKzFDGU61xzFmGvVy2Jly14rdep5dUiPm2kyh/7yj8Ggs+24+DpB1BxpJv0XgMO2yg3jHlWW3zj0581DiCqXwjNAZKNUzhNHVDtGYCKvGVeZYQdK7ZGs8CMW+7xh77VXvogiI/lI1V0lRJqAqs0wyJYljXejjBUGbb16GECTPzNnVAPqEHH77+z05/uNREyWJtXYx2f20FWjA5Aj8zIaUXjgt61qN2nn4Bnx/6tLZMWc2PlMjOC0wBhUHxHp+DOTAR1rhYPJgHJu4ubqv61zdhzo0W6rDU5dkBfrmIFkhgggBv5qAOCOK7FJmhIdlkZTynH+YzdKLfBhNNrs+RvmHZZn43gzbCSRhDdAZjPvjexIXtmQu3b9cRqZS+IKTsaNiV9Y+V8yXQlJ8E2Mnt/8rWvCyUR5XcjJ36pNgAs1QXjhc1cUNEM5dJvIQSBXQVlEAza/XycL UFOSqrLR 7h4Kda0+Ki56Qks6HK6/cl2rXNESIM1bgx2f0l0x6QeFOhg6t9c0VTwH5iYE5MViaVraS6VM1z9rABiuuLAjTWkkjhJwI8grGBE486EWhkgdbLQXTuEU86r0JisVtOtjvU/yFWLHn6eTfJ7gBy1OTP63s7fGY+n40EMLwWnAKCjEeYIZq+jr9De6Ashh10l3ECc3sP6sy9RFdSA0pGQ/3tdfFL4RcndLHSxlZQu19eOoPhSC9NLaukdiZFPtI+qzc58YX4hiBtQP2b9lpCGuBMyRbWI0r8Z3aQBn6dXDimzde8Exsoj+PrPvhJWT3S5HDUwmr X-Bogosity: Ham, tests=bogofilter, spamicity=0.017073, 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 Fri, Dec 8, 2023 at 3:14=E2=80=AFPM Ilya Leoshkevich = wrote: > > On Fri, 2023-12-08 at 14:32 +0100, Alexander Potapenko wrote: > > On Tue, Nov 21, 2023 at 11:07=E2=80=AFPM Ilya Leoshkevich > > wrote: > > > > > > The constraints of the DFLTCC inline assembly are not precise: they > > > do not communicate the size of the output buffers to the compiler, > > > so > > > it cannot automatically instrument it. > > > > KMSAN usually does a poor job instrumenting inline assembly. > > Wouldn't be it better to switch to pure C ZLIB implementation, making > > ZLIB_DFLTCC depend on !KMSAN? > > Normally I would agree, but the kernel DFLTCC code base is synced with > the zlib-ng code base to the extent that it uses the zlib-ng code style > instead of the kernel code style, and MSAN annotations are already a > part of the zlib-ng code base. So I would prefer to keep them for > consistency. Hm, I didn't realize this code is being taken from elsewhere. If so, maybe we should come up with an annotation that can be contributed to zlib-ng, so that it doesn't cause merge conflicts every time Mikhail is doing an update? (leaving this up to you to decide). If you decide to go with the current solution, please consider adding an #include for kmsan-checks.h, which introduces kmsan_unpoison_memory().