Message ID | 20231121220155.1217090-2-iii@linux.ibm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp942572vqb; Tue, 21 Nov 2023 14:05:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IHck2euVuFm1XK926ZzZgSaU08aYxBHvmr7CDgFgWg+M1/hhBjRxw80Xwt4SVbTAqpIFN+F X-Received: by 2002:a05:6a00:4409:b0:6c4:b182:f3d9 with SMTP id br9-20020a056a00440900b006c4b182f3d9mr654631pfb.21.1700604349071; Tue, 21 Nov 2023 14:05:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700604349; cv=none; d=google.com; s=arc-20160816; b=Y47AcO4rOlObpoHabfgFhukHY/zkcr/FPOmPYCjRmGwPHnpxEB4qPtgJqP003aNCtF utKF+F3vGOnulVBeAGAu7CSGkeaNqb9/PnlXhfNWeg9IYgKg/x1UU9hj2yIPnbXnKhYj Z0UqHw4HiaiNtvDa5FgXaHYdL7a4lynoP2dcNGnypVVZohV/IX/6Sh6qR279j0tSypYZ kerBWHqtNr0B3nJuRs2zXNhsmwLkJ5ev/PkE3hCgLxX/XTvM31EUgc0eQsSNiB0hv7Bd XUGIc7wneU1NKgsHseZCjbZpVkj6/Yy7LOcu0GqkgJmlkg8ai7APLPxUCRCfcVdk/Eex tYtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=CZLHkQEJKjMWj9tFsHKzWIaMVL7MbTldFAitesNVJzU=; fh=TQATEbdDZNcnk8L2eDP6eFL9HlexFaHIexhR1TH2IlY=; b=NJwqvp2ywuwlNE2vHG+aPO4jD5cud3CWRHYvyduV7xeWyjpS49G58GzF3co08Mg7SW 58iJJjQWvvNb3zxDdh7iyMzLkSDaSfA76dMWVwXJJRvoF6Lcgl37kLs8svBJ9+SGeaSn UMXBm7qAYYjr7Usez4anuBkEzMOqtD3tNYD6gtkiXVPKV4x9RRY+Ou8X0AnHsNlbtMDi FaZq24TQ3SS2RkRoDdxmK8dECTes18zsyqIIG6E/45zkppGtqbNC374n9zFCCbdKxcdH tdbd6eVBs2Gnj9mfAJUkZPkefPh66deIgIDSCUGcR3ucwtw1LrBNQAQp7i905uYGFR2t tk0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=pYvkaxpd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id f18-20020a056a0022d200b006cb64909cb5si7682550pfj.7.2023.11.21.14.05.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 14:05:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=pYvkaxpd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id EA99F802886C; Tue, 21 Nov 2023 14:02:57 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229514AbjKUWCm (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Tue, 21 Nov 2023 17:02:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36308 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229488AbjKUWCl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 21 Nov 2023 17:02:41 -0500 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B174B113; Tue, 21 Nov 2023 14:02:37 -0800 (PST) Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3ALLge2H032055; Tue, 21 Nov 2023 22:02:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-transfer-encoding; s=pp1; bh=CZLHkQEJKjMWj9tFsHKzWIaMVL7MbTldFAitesNVJzU=; b=pYvkaxpdEpJG6GKq2nNCKPMJHu32rA/wwXkHyo9FIHw9oMmUMSI8w6QVoIPL8wnQUNbN aWE/ALzgn+TX9VyATcdp7v6s0iX5nuBP1b967GICs6NZH3mcsk3VRXVHA3H7MYqLb7Zh su1VqUcpnGvzNz+XVGcJO4ELdBEqAgIlAmt2bMFcjF30HI1BskYauHsY8EfJGxhfNt+Y 4GpS5/Z45DfGdl1cC4EF0K6cpUlN1/iVl7AjDQFnNeJF/WLS1UchupLTgybJ/j7GSNn/ MSJ63gfTNKr/tIHa7Q0GfBdm5X8ZkPUUdAbF9YxFvra9bKx7PLOCGpw95T07eBKPu3DG hQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uh4pw8etj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Nov 2023 22:02:09 +0000 Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3ALLtc00001991; Tue, 21 Nov 2023 22:02:09 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3uh4pw8esw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Nov 2023 22:02:08 +0000 Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3ALLnSiV004674; Tue, 21 Nov 2023 22:02:07 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3uf7yykveh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Nov 2023 22:02:07 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3ALM246R19333858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Nov 2023 22:02:04 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3F4FA20063; Tue, 21 Nov 2023 22:02:04 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C52042005A; Tue, 21 Nov 2023 22:02:02 +0000 (GMT) Received: from heavy.boeblingen.de.ibm.com (unknown [9.179.23.98]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Tue, 21 Nov 2023 22:02:02 +0000 (GMT) From: Ilya Leoshkevich <iii@linux.ibm.com> To: Alexander Gordeev <agordeev@linux.ibm.com>, Alexander Potapenko <glider@google.com>, Andrew Morton <akpm@linux-foundation.org>, Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>, Heiko Carstens <hca@linux.ibm.com>, Joonsoo Kim <iamjoonsoo.kim@lge.com>, Marco Elver <elver@google.com>, Masami Hiramatsu <mhiramat@kernel.org>, Pekka Enberg <penberg@kernel.org>, Steven Rostedt <rostedt@goodmis.org>, Vasily Gorbik <gor@linux.ibm.com>, Vlastimil Babka <vbabka@suse.cz> Cc: Christian Borntraeger <borntraeger@linux.ibm.com>, Dmitry Vyukov <dvyukov@google.com>, 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 <mark.rutland@arm.com>, Roman Gushchin <roman.gushchin@linux.dev>, Sven Schnelle <svens@linux.ibm.com>, Ilya Leoshkevich <iii@linux.ibm.com> Subject: [PATCH v2 01/33] ftrace: Unpoison ftrace_regs in ftrace_ops_list_func() Date: Tue, 21 Nov 2023 23:00:55 +0100 Message-ID: <20231121220155.1217090-2-iii@linux.ibm.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20231121220155.1217090-1-iii@linux.ibm.com> References: <20231121220155.1217090-1-iii@linux.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: OE_2HhR7p8laIqszHIpA8sx3KovHtydB X-Proofpoint-ORIG-GUID: 5HzIgJAoLjwL41V8x1uA2rXIn0syQQXg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-21_12,2023-11-21_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 impostorscore=0 mlxlogscore=999 phishscore=0 mlxscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311210172 X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 21 Nov 2023 14:02:58 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783212905991333419 X-GMAIL-MSGID: 1783212905991333419 |
Series |
kmsan: Enable on s390
|
|
Commit Message
Ilya Leoshkevich
Nov. 21, 2023, 10 p.m. UTC
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.
Fix by trusting the architecture-specific assembly code and always
unpoisoning ftrace_regs in ftrace_ops_list_func.
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
---
kernel/trace/ftrace.c | 1 +
1 file changed, 1 insertion(+)
Comments
On Tue, 21 Nov 2023 23:00:55 +0100 Ilya Leoshkevich <iii@linux.ibm.com> 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. > > Fix by trusting the architecture-specific assembly code and always > unpoisoning ftrace_regs in ftrace_ops_list_func. You must be very trusting to trust architecture-specific assembly code ;-) Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> -- Steve > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> > --- > kernel/trace/ftrace.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index 8de8bec5f366..dfb8b26966aa 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -7399,6 +7399,7 @@ __ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip, > void arch_ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip, > struct ftrace_ops *op, struct ftrace_regs *fregs) > { > + kmsan_unpoison_memory(fregs, sizeof(*fregs)); > __ftrace_ops_list_func(ip, parent_ip, NULL, fregs); > } > #else
On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich <iii@linux.ibm.com> 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. I couldn't reproduce these warnings on x86, hope you really need this change on s390 :) > Fix by trusting the architecture-specific assembly code and always > unpoisoning ftrace_regs in ftrace_ops_list_func. > > Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com> Reviewed-by: Alexander Potapenko <glider@google.com>
On Fri, 8 Dec 2023 15:16:10 +0100 Alexander Potapenko <glider@google.com> wrote: > On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich <iii@linux.ibm.com> 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. > > 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
On Fri, 2023-12-08 at 09:31 -0500, Steven Rostedt wrote: > On Fri, 8 Dec 2023 15:16:10 +0100 > Alexander Potapenko <glider@google.com> wrote: > > > On Tue, Nov 21, 2023 at 11:02 PM Ilya Leoshkevich > > <iii@linux.ibm.com> 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. > > > > I couldn't reproduce these warnings on x86, hope you really need > > this > > change on s390 :) I just double-checked, and it's still needed. Without it, I get: [ 4.140184] ===================================================== [ 4.140416] BUG: KMSAN: uninit-value in arch_ftrace_ops_list_func+0x8e6/0x14b0 [ 4.140484] arch_ftrace_ops_list_func+0x8e6/0x14b0 [ 4.140546] ftrace_graph_caller+0x0/0x34 [ 4.140614] read_tod_clock+0x6/0x1e0 [ 4.140671] ktime_get+0x3a4/0x670 [ 4.140727] clockevents_program_event+0x1c8/0xb10 [ 4.140785] tick_program_event+0x11e/0x230 [ 4.140842] hrtimer_interrupt+0x118a/0x1d10 [ 4.140898] do_IRQ+0x108/0x150 [ 4.140959] do_irq_async+0xfc/0x270 [ 4.141021] do_ext_irq+0x98/0x120 [ 4.141080] ext_int_handler+0xc4/0xf0 [ 4.141141] _raw_spin_unlock_irqrestore+0xfa/0x190 [ 4.141207] _raw_spin_unlock_irqrestore+0xf6/0x190 [ 4.141271] s390_kernel_write+0x218/0x250 [ 4.141328] ftrace_make_call+0x362/0x4a0 [ 4.141386] __ftrace_replace_code+0xb44/0xbd0 [ 4.141442] ftrace_replace_code+0x1d8/0x440 [ 4.141497] ftrace_modify_all_code+0xfe/0x510 [ 4.141555] ftrace_startup+0x4f0/0xcf0 [ 4.141609] register_ftrace_function+0x1316/0x1440 [ 4.141670] function_trace_init+0x2c0/0x3d0 [ 4.141732] tracer_init+0x282/0x370 [ 4.141789] trace_selftest_startup_function+0x104/0x19d0 [ 4.141857] run_tracer_selftest+0x7c8/0xab0 [ 4.141918] init_trace_selftests+0x200/0x820 [ 4.141977] do_one_initcall+0x35e/0x1090 [ 4.142032] do_initcall_level+0x276/0x660 [ 4.142095] do_initcalls+0x16a/0x2d0 [ 4.142153] kernel_init_freeable+0x632/0x960 [ 4.142216] kernel_init+0x36/0x1810 [ 4.142277] __ret_from_fork+0xc0/0x180 [ 4.142333] ret_from_fork+0xa/0x30 [ 4.142431] Local variable agg.tmp.i.i created at: 02:06:55 [30/1836] [ 4.142476] timekeeping_advance+0x79a/0x2870 [ 4.142394] [ 4.142431] Local variable agg.tmp.i.i created at: [ 4.142476] timekeeping_advance+0x79a/0x2870 [ 4.142534] [ 4.142573] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.7.0-rc4-g7657d31dc545 #4 [ 4.142638] Hardware name: IBM 3931 A01 704 (KVM/Linux) [ 4.142686] ===================================================== [ 4.142734] Kernel panic - not syncing: kmsan.panic set ... [ 4.142734] ===================================================== > 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? It's not that different on s390x. There is indeed no architecture- mandated stack pointer and no push/pop, but other than that it's fairly normal. Linux uses %r15 as a stack pointer. On s390x ftrace_regs is allocated on stack by mcount.S. From what I can see, Intel's ftrace_64.S does the same thing, so I don't immediately see why uninit-value is not detected on Intel, even though I think it should. > -- Steve
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 8de8bec5f366..dfb8b26966aa 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -7399,6 +7399,7 @@ __ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip, void arch_ftrace_ops_list_func(unsigned long ip, unsigned long parent_ip, struct ftrace_ops *op, struct ftrace_regs *fregs) { + kmsan_unpoison_memory(fregs, sizeof(*fregs)); __ftrace_ops_list_func(ip, parent_ip, NULL, fregs); } #else