From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 4D6A01DFF3; Fri, 8 Dec 2023 14:31:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EF08C433C7; Fri, 8 Dec 2023 14:31:01 +0000 (UTC) Date: Fri, 8 Dec 2023 09:31:33 -0500 From: Steven Rostedt To: Alexander Potapenko Cc: Ilya Leoshkevich , Alexander Gordeev , Andrew Morton , Christoph Lameter , David Rientjes , Heiko Carstens , Joonsoo Kim , Marco Elver , Masami Hiramatsu , Pekka Enberg , 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 Subject: Re: [PATCH v2 01/33] ftrace: Unpoison ftrace_regs in ftrace_ops_list_func() Message-ID: <20231208093133.62aae274@gandalf.local.home> In-Reply-To: References: <20231121220155.1217090-1-iii@linux.ibm.com> <20231121220155.1217090-2-iii@linux.ibm.com> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-trace-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 8 Dec 2023 15:16:10 +0100 Alexander Potapenko wrote: > On Tue, Nov 21, 2023 at 11:02=E2=80=AFPM Ilya Leoshkevich wrote: > > > > Architectures use assembly code to initialize ftrace_regs and call > > ftrace_ops_list_func(). Therefore, from the KMSAN's point of view, > > ftrace_regs is poisoned on ftrace_ops_list_func entry(). This causes > > KMSAN warnings when running the ftrace testsuite. =20 >=20 > I couldn't reproduce these warnings on x86, hope you really need this > change on s390 :) On x86, ftrace_regs sits on the stack. And IIUC, s390 doesn't have the same concept of a "stack" as other architectures. Perhaps that's the reason s390 needs this? -- Steve