ernel.org; spf=pass smtp.mailfrom=dolcini.it Received: from localhost.localdomain (xcpe-178-82-120-96.dyn.res.sunrise.net [178.82.120.96]) by mail11.truemail.it (Postfix) with ESMTPA id 8C1191FD35; Tue, 9 Dec 2025 09:41:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dolcini.it; s=default; t=1765269694; bh=1VHTUXl3gc+91mo15pIRbZ3NIRKVtsGczrD/Bl81o6k=; h=From:To:Subject; b=tsOl2uc9wCitwZsMNcL9p38pZW303QuaAHYLlQ8kCvOi7+sDaKM5czd9qH1GoqGeX nr0QqhB4E6lCrxxzV767GRSL6iUnGPedZOzoipX+Qt/5xzSz1fcFQP6nBHHbWJjDho iFMoPA6taDB4O9ye1dON//V7eaXDUJuzzJWiA3H3A1uMVLhUSAIWeRmkkFId5WUoHA wNrr5QZ14e4CT8wDCKOg25rqt97EyO5LT2l2TuMfsDlEYwxy7GxYRJXFaLDUz02rPp A8NGeI/xj7MRI99pF2m70kXvvMe/oPIDvGXiP/Y2KAUMek8JLvX0JFMJd4m0YAiMC7 rKuZJh5lqTg5g== From: Francesco Dolcini To: Nishanth Menon , Vignesh Raghavendra , Tero Kristo , Rob Herring , Krzysztof Kozlowski , Conor Dooley Cc: Francesco Dolcini , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v1] arm64: dts: ti: am62p-verdin: Fix SD regulator startup delay Date: Tue, 9 Dec 2025 09:41:25 +0100 Message-ID: <20251209084126.33282-1-francesco@dolcini.it> X-Mailer: git-send-email 2.47.3 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-DKIM: signer='dolcini.it' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: dolcini.it] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 From: Francesco Dolcini The power switch used to power the SD card interface might have more than 2ms turn-on time, increase the startup delay to 20ms to prevent failures. Fixes: 87f95ea316ac ("arm64: dts: ti: Add Toradex Verdin AM62P") Cc: stable@vger.kernel.org Signed-off-by: Francesco Dolcini --- arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi index 5e050cbb9eaf..ec9dd931fe92 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi @@ -112,7 +112,7 @@ reg_sd1_vmmc: regulator-sdhci1-vmmc { regulator-max-microvolt = <3300000>; regulator-min-microvolt = <3300000>; regulator-name = "+V3.3_SD"; - startup-delay-us = <2000>; + startup-delay-us = <20000>; }; reg_sd1_vqmmc: regulator-sdhci1-vqmmc { -- 2.47.3 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id EPdANR8IN2n4PCoAYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 17:17:19 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 17:17:21 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSerP-0000000Cfl9-2jXu for hi@josie.lol; Mon, 08 Dec 2025 17:17:19 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 4053E30220DD for ; Mon, 8 Dec 2025 17:16:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 558EE30FC30; Mon, 8 Dec 2025 17:16:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="GbLBvCqH" X-Original-To: linux-s390@vger.kernel.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 424172FBE02; Mon, 8 Dec 2025 17:16:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214195; cv=none; b=tUMOG85zphaQd/fK4HS96bHHOUvRrEO7pZqZdz+2w44z2aW6a+SU76o9Od2p6gg68UepKgtkVaVy1yALlReow4Un6jV5/YXpsfF+IB1Zgxm1LHxh4pqwPKsJdS4XeEUynqP6PS2n+XdkiDz/V93/b3ZtUMgRXrQnUPqx+gZvBAw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214195; c=relaxed/simple; bh=2b/4Jci+vOAtbEpjAcKcZIeHV/tFcGaQRN/CGJKQBFE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PNvxYwdjkzRE+2R3VayQg5ZUGTaNQVaGkWOM20tOTwbteMnR+okscbI0GlQEfzRkKPs/vno230PTsc91hm2AatViaDYuUYgjKnLyVyrH/HStuNkEvutHsnDzkqocdTeWMXoX4Xj9USWJ44jKlB2JE7LYU3Mxg9dz55qngkda6xY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=GbLBvCqH; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5B87xQ1S021763; Mon, 8 Dec 2025 17:16:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=e77aNzRcpfOdIx39c Kj7p6jnEbZCyc7Rf/QZ4cCnaZk=; b=GbLBvCqHgl5UQM0Z6v2wk4QXypO3CTCmM 3wL1gvBU6A0vNyHIiRroreTz5tJVZH4JR5yxomGhDaWE7tOYQ34Bj699SJ6kth0N 9rgVj3vfXwIv2xMfpZpfLppgCpQss3tH4RKL0WVFVey/r//w2BAg1nN/AX6npZ0V 2WRIjm1Hf39N+mS3ccsj562ZJtI5yRNEbG2cf5xuzvx4rnpQ0B/eFIBi5SwLVHBv FjMmkTNJHuASCEGb83/18vJ7DZA1F5frgbbQ/XXtanUESwaeWhCFT4+0ps8VtsXD W+vx/voGtgJ6RBJqCH5tRo5Yg8tyP/ggg/l+iw+NSrNhdVR/EwJGQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4avc7brwf4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:09 +0000 (GMT) Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5B8HAajH003291; Mon, 8 Dec 2025 17:16:09 GMT Received: from ppma23.wdc07v.mail.ibm.com (5d.69.3da9.ip4.static.sl-reverse.com [169.61.105.93]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4avc7brwey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:09 +0000 (GMT) Received: from pps.filterd (ppma23.wdc07v.mail.ibm.com [127.0.0.1]) by ppma23.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5B8FY7lT012812; Mon, 8 Dec 2025 17:16:07 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma23.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4aw0ajpp2m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:07 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5B8HG3t953281064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Dec 2025 17:16:03 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AA27B20043; Mon, 8 Dec 2025 17:16:03 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 521392004D; Mon, 8 Dec 2025 17:16:03 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.87.85.9]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 8 Dec 2025 17:16:03 +0000 (GMT) From: Jens Remus To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-s390@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Steven Rostedt Cc: Jens Remus , Heiko Carstens , Vasily Gorbik , Ilya Leoshkevich , Josh Poimboeuf , Masami Hiramatsu , Mathieu Desnoyers , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Linus Torvalds , Andrew Morton , Florian Weimer , Kees Cook , "Carlos O'Donell" , Sam James , Dylan Hatch Subject: [RFC PATCH v3 04/17] x86/unwind_user: Simplify unwind_user_word_size() Date: Mon, 8 Dec 2025 18:15:46 +0100 Message-ID: <20251208171559.2029709-5-jremus@linux.ibm.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251208171559.2029709-1-jremus@linux.ibm.com> References: <20251208171559.2029709-1-jremus@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: dViJuWBa4d1oueGWivO_K4JyBK6FHeeJ X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjA2MDAyMCBTYWx0ZWRfX4JhSPTgN0SMw FS2cMaJjmFXcqNg8/Bjhq2Xj+fnw/H0ShvHQsMNkS63oOoSZ3cn4HoZ8hxUDdqQrL4Uo4JnlslB SAIeKBpEICaKs4s5s8pTDFzhDC4pETZoDcHLVYIf7PgmKO0y3i3t2zntoYgaiJ6ObzXPakVg2sz ef2W4N8GhGnJwXItin7Qs6RlC5Pa2S9YuTevEiywsRNl7vBBUO6Mu5GBODIcdx/90uFD2VRsvsV i1oHhN49BQPn836U5hvHSeSHHaSxZt3w0qmNRqtX2vfDA7gaAjHvX5YrOp2xwAhUXfuxXbAd8M+ AELEv5SW1rtdiNkM+TaHK54yhfyNKzxooVWobjBsHgPSeHTha+lbCeysBfwJN+Lcyag0wCiIhMu Gas4ynI6K9CrlcwNHf3Yg8POyTBvug== X-Proofpoint-GUID: dKedLVKxgRZQI5PdQzGh_haMCrt-FvFD X-Authority-Analysis: v=2.4 cv=FpwIPmrq c=1 sm=1 tr=0 ts=693707d9 cx=c_pps a=3Bg1Hr4SwmMryq2xdFQyZA==:117 a=3Bg1Hr4SwmMryq2xdFQyZA==:17 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=Z4Rwk6OoAAAA:8 a=VnNF1IyMAAAA:8 a=UXUCOGqRO3hiuQW2F5cA:9 a=HkZW87K1Qel5hWWM3VKY:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-06_02,2025-12-04_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 bulkscore=0 spamscore=0 lowpriorityscore=0 suspectscore=0 malwarescore=0 phishscore=0 clxscore=1015 adultscore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2512060020 X-DKIM: signer='ibm.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 5 Get rid of superfluous ifdef and return explicit word size depending on 32-bit or 64-bit mode. Suggested-by: Linus Torvalds Signed-off-by: Jens Remus --- arch/x86/include/asm/unwind_user.h | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/x86/include/asm/unwind_user.h b/arch/x86/include/asm/unwind_user.h index 4d699e4954ed..2dfb5ef11e36 100644 --- a/arch/x86/include/asm/unwind_user.h +++ b/arch/x86/include/asm/unwind_user.h @@ -12,11 +12,7 @@ static inline int unwind_user_word_size(struct pt_regs *regs) /* We can't unwind VM86 stacks */ if (regs->flags & X86_VM_MASK) return 0; -#ifdef CONFIG_X86_64 - if (!user_64bit_mode(regs)) - return sizeof(int); -#endif - return sizeof(long); + return user_64bit_mode(regs) ? 8 : 4; } #endif /* CONFIG_UNWIND_USER */ -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id EBL4NU4IN2kTISwAYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 17:18:06 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 17:18:07 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSesA-0000000CiF2-1fsx for hi@josie.lol; Mon, 08 Dec 2025 17:18:06 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 1FD783036D90 for ; Mon, 8 Dec 2025 17:17:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D66B2314A6A; Mon, 8 Dec 2025 17:16:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="JIodgsqQ" X-Original-To: linux-s390@vger.kernel.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 82F112FBE11; Mon, 8 Dec 2025 17:16:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214200; cv=none; b=i0yauood1m6p5t5mIY5yvchWJkuw8Re5cmI4qffo94p0160YZ6lEciLBDnO+hysDOhkuFmQOKRGGcrXezexJx3+vuSV9kiYn4JPD5HffsJ+Z+4tZ/zuVimlwBrepN+/U0mMdzjSaw/DZC2IJLB0yuOiqqK84r9+WqQECxXyQTVg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214200; c=relaxed/simple; bh=n4UqXtWKP9aM7+of2a9zTKNpugsdsHjeuZZ9Y6vQt1g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ats3zMS/NbfaaCF7P4usWnJeRoSpkzXYm8NA45wNFrqiYVBMq5bwyb9LE08rnyPo6Jb0XMac1OUVqlfE0P93JZIGC7yVFs7YvAdoGLBKTHQFfhwcjYI/DRi1Itpxd9kDM0vS/P7O+8tGDjDzyCBdCQJc5KQ/Qla6SnqtTYHmUNE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=JIodgsqQ; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0353729.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5B87jU2o032400; Mon, 8 Dec 2025 17:16:10 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=YwkCBIDx+CdwD1PaP 1iGkMwFtK6nggvYnNMUdWID+FY=; b=JIodgsqQ5giB9xuBFH9zGASMVHgEwm1nM 01lhgp7nALV4lC1ZOAGksr2nSFNzu4z8oIG1MX8sSWnmPipggwTLOJGXqZO2I/JU 8fUfsovZNsJSQNtD/m5HCvDDtLf6pVXNqudYFiR0mnUWhyGFkNT3LTPiOe8Qh1pR xtx6RWvP6/ry7xKVfh07v+z0HPPSH/WC4FOSgtYqh5BRdQOTx8AoN0obker9q+gS sEkba3W2hBwcSMYNMGE9DmRqE8tMVA58aGwUVVhalSm7gPrG+xAqMiCWVWEN87U9 kefGqqaLh/X8v0mF99A4oQm222cRtfKAZnobckug9jQV+Z01vlOIg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4avc618x5h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:10 +0000 (GMT) Received: from m0353729.ppops.net (m0353729.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5B8H1lPv013244; Mon, 8 Dec 2025 17:16:09 GMT Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4avc618x58-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:09 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5B8G7IjH026799; Mon, 8 Dec 2025 17:16:08 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4aw1h0xfku-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:08 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5B8HG4cR60358938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Dec 2025 17:16:04 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 69F5020043; Mon, 8 Dec 2025 17:16:04 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 158AD2004D; Mon, 8 Dec 2025 17:16:04 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.87.85.9]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 8 Dec 2025 17:16:04 +0000 (GMT) From: Jens Remus To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-s390@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Steven Rostedt Cc: Jens Remus , Heiko Carstens , Vasily Gorbik , Ilya Leoshkevich , Josh Poimboeuf , Masami Hiramatsu , Mathieu Desnoyers , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Linus Torvalds , Andrew Morton , Florian Weimer , Kees Cook , "Carlos O'Donell" , Sam James , Dylan Hatch Subject: [RFC PATCH v3 06/17] s390/vdso: Avoid emitting DWARF CFI for non-vDSO Date: Mon, 8 Dec 2025 18:15:48 +0100 Message-ID: <20251208171559.2029709-7-jremus@linux.ibm.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251208171559.2029709-1-jremus@linux.ibm.com> References: <20251208171559.2029709-1-jremus@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjA2MDAyMCBTYWx0ZWRfX5jZeM+WTsfn3 +sHyJsDIzkJhxX+p7VsSQk+OkoKrvSlqkEd+oWE1rM6r+xqrqU+T3pCQPbiJZd7JcnW84j9idPJ maLMdn2xBHFZppX1gdzYnHzT1rO+vQbPs8bsspWOytwmEKnC+yF25txMLPioICoFHPx+VOpAB4H qNBB9qYzRX/1yYBDm8mMggGziFxS2KtWOPytlQ8zXZ/5Nz+hSIz7vHHAHKw78yDlPOqAD76WMam hLp4h2QqJ/BIk5iNVRY8H+yLiExPreMp0qdKJunf6au0ED6U8f/vZ2GMY8p5MYF9ZVFN45f/vTE tsY6P6X0E4TEnwbIfOwZq2TtpzlaaAMIrSeccN/m9AwnRxaUjFiiSg/9teXg8iime+wMNK2LXVm 2Kim3+HJ++mj6BGDGoCq3iprbLgv/w== X-Proofpoint-GUID: AtyoosCu-jjGI1nH9HptHZlond16_jBv X-Proofpoint-ORIG-GUID: 6lGGs0Rc-y0qYKZC9_9Tp_ni9O2crJcA X-Authority-Analysis: v=2.4 cv=O/U0fR9W c=1 sm=1 tr=0 ts=693707da cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=meVymXHHAAAA:8 a=VnNF1IyMAAAA:8 a=BeDKgDnIR9-QKG0Pbi4A:9 a=2JgSa4NbpEOStq-L5dxp:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-06_02,2025-12-04_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1015 phishscore=0 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2512060020 X-DKIM: signer='ibm.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 5 This replicates Josh's x86 commit TODO ("x86/asm: Avoid emitting DWARF CFI for non-VDSO") for s390. It also aligns asm/dwarf.h to x86 asm/dwarf2.h. It was decided years ago that .cfi_* annotations aren't maintainable in the kernel. For the kernel proper, ensure the CFI_* macros don't do anything. On the other hand the vDSO library *does* use them, so user space can unwind through it. Make sure these macros only work for vDSO. They aren't actually being used outside of vDSO anyway, so there's no functional change. Signed-off-by: Jens Remus --- Notes (jremus): Link to latest x86 patch: https://lore.kernel.org/all/20250425024022.477374378@goodmis.org/ arch/s390/include/asm/dwarf.h | 45 ++++++++++++++++++++++------------- 1 file changed, 29 insertions(+), 16 deletions(-) diff --git a/arch/s390/include/asm/dwarf.h b/arch/s390/include/asm/dwarf.h index df9f467910f7..6bcf37256feb 100644 --- a/arch/s390/include/asm/dwarf.h +++ b/arch/s390/include/asm/dwarf.h @@ -6,6 +6,18 @@ #warning "asm/dwarf.h should be only included in pure assembly files" #endif +.macro nocfi args:vararg +.endm + +#ifdef BUILD_VDSO + + /* + * For the vDSO, emit both runtime unwind information and debug + * symbols for the .dbg file. + */ + + .cfi_sections .eh_frame, .debug_frame + #define CFI_STARTPROC .cfi_startproc #define CFI_ENDPROC .cfi_endproc #define CFI_DEF_CFA_OFFSET .cfi_def_cfa_offset @@ -16,23 +28,24 @@ #ifdef CONFIG_AS_CFI_VAL_OFFSET #define CFI_VAL_OFFSET .cfi_val_offset #else -#define CFI_VAL_OFFSET # +#define CFI_VAL_OFFSET nocfi #endif -#ifndef BUILD_VDSO - /* - * Emit CFI data in .debug_frame sections and not in .eh_frame - * sections. The .eh_frame CFI is used for runtime unwind - * information that is not being used. Hence, vmlinux.lds.S - * can discard the .eh_frame sections. - */ - .cfi_sections .debug_frame -#else - /* - * For vDSO, emit CFI data in both, .eh_frame and .debug_frame - * sections. - */ - .cfi_sections .eh_frame, .debug_frame -#endif +#else /* !BUILD_VDSO */ + +/* + * On s390, these macros aren't used outside vDSO. As well they shouldn't be: + * they're fragile and very difficult to maintain. + */ + +#define CFI_STARTPROC nocfi +#define CFI_ENDPROC nocfi +#define CFI_DEF_CFA_OFFSET nocfi +#define CFI_ADJUST_CFA_OFFSET nocfi +#define CFI_RESTORE nocfi +#define CFI_REL_OFFSET nocfi +#define CFI_VAL_OFFSET nocfi + +#endif /* !BUILD_VDSO */ #endif /* _ASM_S390_DWARF_H */ -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id gJQtBIoIN2kJLysAYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 17:19:06 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 17:19:06 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSet7-0000000CkD0-2XvS for hi@josie.lol; Mon, 08 Dec 2025 17:19:06 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 16E983049905 for ; Mon, 8 Dec 2025 17:17:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6FDC4315D47; Mon, 8 Dec 2025 17:16:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="iN5C2CUu" X-Original-To: linux-s390@vger.kernel.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 D6EF322173A; Mon, 8 Dec 2025 17:16:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214204; cv=none; b=EVVvDg244sLFHVAEsKtkfgzeeTGqF20Yv6YGbZNqw9lYHPZ005IpAmGu2g4Y7V4F5v7AsvHG7glWVXhOPNdKPnVtMMiQPhRLeSM/qwCnY8rOkKGWFcVX5DCcBgWpR6xvCwIDfll6hjgSRTpMh+yvP1ZA0cXUGOYXD01c/fcHbvg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214204; c=relaxed/simple; bh=x6lKLDteU5GRau7fcOYtPWzN8ouuzSThMpuFxNobwyw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=ojt1ScXeAm/XHcpkvBZFD4tqh/ggB9JmpqASVZvf4lGPOn2taiRL2FxF+PfKnsE9lObRym/ZbMRRjFV3C+rDmLL5dCuuSTGZwK9oXJgi+vT1LQ8grEZShhAfwKljs0r3aPJEElNDyp7OIfk6XmZ3pLVQiJGHKkj0jujoflN1W0s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=iN5C2CUu; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5B88mlrZ019359; Mon, 8 Dec 2025 17:16:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to; s=pp1; bh=rdATdSrJh24c1RXMe3o/fHSkYXTV XUBW9p+883UrfWw=; b=iN5C2CUu+v730OD5hDRouOl20wYNn/SyhA4JENWTThBz urUrCF+jP3Ouowa6E6P+PkS3vvH7b0O56hlMmVwq+E8pZWynqzuAaBmo0i6BcWmb WVketeB06MyW5413J55julk0zGlzYrsbI18QNnWCgNPMjrMD+r7jwtSjsVbNTp+P wkGfvUFHbYBCZJRlkUFs+f1qi5J38MIcTFEdPCE9tH7jm8dtW3NV/lOuG6VnIET4 wKOzXNKnZ6ePGHQBwg7bdWMg7cAeRco0hzEGfpjY1MnUteQ5yjlb+QSOhJJwONOy nAhOhcZOrzpdRHcCzKO9i0bw7T9xpkzXn9+l3IBTvg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4avawv0k3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:07 +0000 (GMT) Received: from m0353725.ppops.net (m0353725.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5B8HG63T008601; Mon, 8 Dec 2025 17:16:07 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 4avawv0k3a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:06 +0000 (GMT) Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5B8EWkf3028147; Mon, 8 Dec 2025 17:16:06 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4avy6xpw8r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:06 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5B8HG2Sm53608736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Dec 2025 17:16:02 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2A7842004E; Mon, 8 Dec 2025 17:16:02 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BC46320043; Mon, 8 Dec 2025 17:16:01 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.87.85.9]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 8 Dec 2025 17:16:01 +0000 (GMT) From: Jens Remus To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-s390@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Steven Rostedt Cc: Jens Remus , Heiko Carstens , Vasily Gorbik , Ilya Leoshkevich , Josh Poimboeuf , Masami Hiramatsu , Mathieu Desnoyers , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Linus Torvalds , Andrew Morton , Florian Weimer , Kees Cook , "Carlos O'Donell" , Sam James , Dylan Hatch Subject: [RFC PATCH v3 00/17] s390: SFrame user space unwinding Date: Mon, 8 Dec 2025 18:15:42 +0100 Message-ID: <20251208171559.2029709-1-jremus@linux.ibm.com> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: rJxbQ8dgUbGc91eiuhbK16gz1jmF56Vs X-Proofpoint-ORIG-GUID: K6GvHPed4nMg4stO213Lvtzd2l3n1p7H X-Authority-Analysis: v=2.4 cv=aY9sXBot c=1 sm=1 tr=0 ts=693707d7 cx=c_pps a=5BHTudwdYE3Te8bg5FgnPg==:117 a=5BHTudwdYE3Te8bg5FgnPg==:17 a=IkcTkHD0fZMA:10 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=-dFlDAyDCAhLAYqPnkQA:9 a=QEXdDO2ut3YA:10 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjA2MDAwNyBTYWx0ZWRfXy1A5Enrcif3F oR50xCgSyZqcMJYNraJqfJFuyee81j3pDGbgT1qdM2ChVYDUqJVKVXWiql38FVaR6lHmxSkICNM jCyBz5taHSo47s5tb6/Hn5kkpL+i9oGyu86afw3Rxa0U6NGPLm9EFW0SJAAgZdj0HXNwrAgmmLO NAkGD0wIKKnkZ/wp8P5YMsmvag9XEn11Gd3jtd58Av1esR3SRX9zCPfF0DvgzxHxGeATNIY8FNk 3XUzC44io0hC0DfALA6UbDkUJQ6AiR0Ml+zlwuhF3eYCI86IiKRBltEDK6KeCj6RDBouoElHyul UrQSm5xs8fO9E6OQymyyTESwF1n5dPNRw7bwFG+CJVsa+RfYq4GGsoWfwT3QDcr92Q6mYj9Raky 8SELrmu1oVgK1fTOkPJwnSyBI+aTsA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-06_02,2025-12-04_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 clxscore=1015 phishscore=0 lowpriorityscore=0 bulkscore=0 adultscore=0 impostorscore=0 malwarescore=0 priorityscore=1501 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2512060007 X-DKIM: signer='ibm.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: perf.data] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 5 This RFC series adds s390 support for unwinding of user space using SFrame. It is based on Josh's, Steven's, and my work (see prerequisites below). The generic unwind user (sframe) frameworks are extended to enable support for a few s390-particularities (see patches 9-12), including unwinding of user space using back chain (see patches 15-17). The latter could be broken apart as a separate patch series. Changes in RFC v3: - Rebase on and include my unwind user cleanup series v4, which includes a simplification of unwind_user_word_size() on x86. (Linus) - Implement unwinding of user space using s390 back chain using unwind user fp instead of introducing a new unwind user backchain. (Josh) Changes in RFC v2: - Rebased on latest "unwind user" enhancements from Peter Zijlstra and my latest "unwind user sframe" series v12. - Incorporated RFC v1 review feedback. - No new config options (except for unwind user backchain). Motivation: On s390 unwinding using frame pointer (FP) is unsupported, because of lack of proper s390 64-bit (s390x) ABI specification and compiler support. The ABI does only specify a "preferred" FP register. Both GCC and Clang, regardless of compiler option -fno-omit-frame-pointer, setup the preferred FP register as late as possible, which usually is after static stack allocation, so that the CFA cannot be deduced from the FP without any further data, such as provided by DWARF CFI or SFrame. In theory there is a s390-specific alternative of unwinding using back chain (compiler option -mbackchain), but this has its own limitations. Ubuntu is currently the only distribution that that builds user space with back chain. As a consequence the Kernel stack tracer cannot unwind user space (except if it is built with back chain). Recording call graphs of user space using perf is limited to stack dump sampling (i.e. perf record --call-graph dwarf), which generates a fairly large amount of data and has limitations. Initial testing of recording call graphs using perf using the s390 support for SFrame provided by RFC v1 of this series shows that data size notably improves: perf record data size is greatly reduced (smaller perf.data): SFrame (--call-graph fp): # perf record -F 9999 --call-graph fp objdump -wdWF objdump [ perf record: Woken up 9 times to write data ] [ perf record: Captured and wrote 2.498 MB perf.data (10891 samples) ] Stack sampling (--call-graph dwarf) with a default stack size of 8192: # perf record -F 9999 --call-graph dwarf objdump -wdWF objdump [ perf record: Woken up 270 times to write data ] [ perf record: Captured and wrote 67.467 MB perf.data (8241 samples) ] Prerequirements: This RFC series applies on top of the latest unwind user sframe series "[PATCH v12 00/13] unwind_deferred: Implement sframe handling": https://lore.kernel.org/all/20251119132323.1281768-1-jremus@linux.ibm.com/ It depends on binutils 2.45 to build executables and libraries (e.g. vDSO) with SFrame on s390, including the latest SFrame V2 with PC-relative FDE encoding. Optionally a binutils mainline build is required for SFrame V2 with outermost frame indication. The unwind user sframe series depends on a Glibc patch from Josh, that adds support for the prctls introduced in the Kernel: https://lore.kernel.org/all/20250122023517.lmztuocecdjqzfhc@jpoimboe/ Note that Josh's Glibc patch needs to be adjusted for the updated prctl numbers from "[PATCH v12 13/13] unwind_user/sframe: Add prctl() interface for registering .sframe sections": https://lore.kernel.org/all/20251119132323.1281768-14-jremus@linux.ibm.com/ Overview: Patches 1-4 originate from my "[PATCH v4 0/3] unwind_user: Cleanups" series and can be ignored here (please review in the respective series): https://lore.kernel.org/all/20251208160352.1363040-1-jremus@linux.ibm.com/ Patch 5 aligns asm/dwarf.h to x86 asm/dwarf2.h. Patch 6 replicates Josh's x86 patch "x86/asm: Avoid emitting DWARF CFI for non-VDSO" for s390. Patch 7 changes the build of the vDSO on s390 to keep the function symbols for stack tracing purposes. Patch 8 replicates Josh's patch "x86/vdso: Enable sframe generation in VDSO" for s390. It enables generation of SFrame stack trace information (.sframe section) for the vDSO if the assembler supports it. Patches 9-12 enable Josh's generic unwind user (sframe) frameworks to support the following s390 particularities: - Patch 9 adds support for architectures that define their CFA as SP at callsite + offset. - Patch 10 adds support support for architectures that pass the return address (RA) in a register instead of on the stack and that do not necessarily save the RA on the stack (or in another register) in the topmost frame (e.g. in the prologue or in leaf functions). - Patch 11 adds support for architectures that save RA/FP in other registers instead of on the stack, e.g. in leaf functions. - Patch 12 adds support for architectures that store the CFA offset from CFA base register (e.g. SP or FP) in SFrame encoded. For instance on s390 the CFA offset is stored adjusted by -160 and then scaled down by 8 to enable and improve the use of signed 8-bit SFrame offsets (i.e. CFA, RA, and FP offset). Patch 13 introduces frame_pointer() in ptrace on s390, which is a prerequisite for enabling unwind user. Patch 14 adds support for unwinding of user space using SFrame on s390. It leverages the extensions of the generic unwind user (sframe) frameworks from patches 8-11. Patches 15-16 enable unwind user (fp) to support the following s390 back chain particularities: - Patch 15 introduces FP/RA location unknown, which enables s390 back chain unwinding, which cannot unwind FP. - Patch 16 enables sophisticated architecture-specific initialization of the FP frame, which enables s390 back chain unwinding to provide dynamic information. Patch 17 adds support for unwinding of user space using back chain on s390. Main reasons to support back chain on s390 are: - With Ubuntu there is a major distribution that builds user space with back chain. - Java JREs, such as OpenJDK, do maintain the back chain in jitted code. Limitations: Unwinding of user space using back chain cannot - by design - restore the FP. Therefore unwinding of subsequent frames using e.g. SFrame may fail, if the FP is the CFA base register. Thanks and regards, Jens Jens Remus (17): unwind_user: Enhance comments on get CFA, FP, and RA unwind_user/fp: Use dummies instead of ifdef x86/unwind_user: Guard unwind_user_word_size() by UNWIND_USER x86/unwind_user: Simplify unwind_user_word_size() s390: asm/dwarf.h should only be included in assembly files s390/vdso: Avoid emitting DWARF CFI for non-vDSO s390/vdso: Keep function symbols in vDSO s390/vdso: Enable SFrame generation in vDSO unwind_user: Enable archs that define CFA = SP_callsite + offset unwind_user: Enable archs that pass RA in a register unwind_user: Enable archs that save RA/FP in other registers unwind_user/sframe: Enable archs with encoded SFrame CFA offsets s390/ptrace: Provide frame_pointer() s390/unwind_user/sframe: Enable HAVE_UNWIND_USER_SFRAME unwind_user: Introduce FP/RA location unknown unwind_user/fp: Use arch-specific helper to initialize FP frame s390/unwind_user/fp: Enable back chain unwinding of user space arch/Kconfig | 3 + arch/s390/Kconfig | 2 + arch/s390/include/asm/dwarf.h | 53 ++++-- arch/s390/include/asm/ptrace.h | 18 +- arch/s390/include/asm/unwind_user.h | 183 +++++++++++++++++++++ arch/s390/include/asm/unwind_user_sframe.h | 33 ++++ arch/s390/kernel/vdso64/Makefile | 9 +- arch/s390/kernel/vdso64/vdso64.lds.S | 9 + arch/x86/include/asm/unwind_user.h | 66 ++++++-- include/asm-generic/Kbuild | 1 + include/asm-generic/unwind_user_sframe.h | 35 ++++ include/linux/unwind_user.h | 30 +++- include/linux/unwind_user_types.h | 20 ++- kernel/unwind/sframe.c | 13 +- kernel/unwind/sframe.h | 14 ++ kernel/unwind/user.c | 83 ++++++---- 16 files changed, 493 insertions(+), 79 deletions(-) create mode 100644 arch/s390/include/asm/unwind_user.h create mode 100644 arch/s390/include/asm/unwind_user_sframe.h create mode 100644 include/asm-generic/unwind_user_sframe.h -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id eOxjGbcIN2n4PCoAYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 17:19:51 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 17:19:51 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSetq-0000000ClaP-36Y5 for hi@josie.lol; Mon, 08 Dec 2025 17:19:51 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id DBA51304E07D for ; Mon, 8 Dec 2025 17:17:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2CE672DCBE3; Mon, 8 Dec 2025 17:16:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="GSlVmxsj" X-Original-To: linux-s390@vger.kernel.org Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (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 2E1953148A8; Mon, 8 Dec 2025 17:16:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214207; cv=none; b=DOfBKqQ9GMgO+UDAWnkkhZqa05pH/o/62fiysr9cgwCaZzCJ0SMq4OBOtHBxBGyE782jL1WbIf8r+MrktY0xxjVvxLCb/Y/EOPo/qyjeu2JBebRtNV1fIeGu9jqI21Ro4ITAbEVr8dUJ9Z9aL3Y2ypsDTSYZWxkwLYOE4xiALtQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214207; c=relaxed/simple; bh=yltrjhIGJ7HS+wjrruyRHfyMCbcnORydhV9U9I20LBo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NWyLbQvwStS9R1xtAPfUGm5D9JNl0QWeRslxLfUeBTg3JAR7QvguyFbRIGveE1pXU7auQnGVjnF/kgQUA97Ha/UMHLEnW0w15FDLqYD6RVcnd16FKti2+jh5Mk4CEjEv0jXUGRx6Mhb1Rm91EATLbrYMyw9IPU578KcCp2Kcezc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=GSlVmxsj; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5B8E18ll006746; Mon, 8 Dec 2025 17:16:12 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=nQgOZ+bDADUiR3Ynt G0xn8e9CinrTQX7CPDM9ldJA5k=; b=GSlVmxsj/rgXvkrk7DSMs/QhHcDEpY8kp /yY1gqCai9SAp24VPGVts/GpooswCrPtc+d/f4DI4qnV4gq3Nv0SKrendMnZdwJD IObrU/EVAKmAYCCh9Gqpdi6xbICRoCWGlq4N7Ww83cz8KNaODMXAcRNNEsdwpKUp vj4na1i+C7tDM9hB8Npqvrx2oXz3zISVZyyRa9N2I8F+Dwz9q7u4hJMFq4EPLw6l E47oI+ZqrpTTQUvoLD6U7v8Y1Ize35kwTM+zr3eR4XGq+3F1AZRzfYhfzMJsiBgZ xZgThc5b9co2WGM2Y62Rpyuju5/cryvuXEsQt6A6s1HYy3Wh13C4Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4av9wvgqd7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:11 +0000 (GMT) Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5B8GlVCQ011132; Mon, 8 Dec 2025 17:16:11 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4av9wvgqd5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:11 +0000 (GMT) Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5B8EsSTj008447; Mon, 8 Dec 2025 17:16:10 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4avytmpsqs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:10 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5B8HG6MG44827090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Dec 2025 17:16:06 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4D60B2004B; Mon, 8 Dec 2025 17:16:06 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E50392004E; Mon, 8 Dec 2025 17:16:05 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.87.85.9]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 8 Dec 2025 17:16:05 +0000 (GMT) From: Jens Remus To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-s390@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Steven Rostedt Cc: Jens Remus , Heiko Carstens , Vasily Gorbik , Ilya Leoshkevich , Josh Poimboeuf , Masami Hiramatsu , Mathieu Desnoyers , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Linus Torvalds , Andrew Morton , Florian Weimer , Kees Cook , "Carlos O'Donell" , Sam James , Dylan Hatch Subject: [RFC PATCH v3 11/17] unwind_user: Enable archs that save RA/FP in other registers Date: Mon, 8 Dec 2025 18:15:53 +0100 Message-ID: <20251208171559.2029709-12-jremus@linux.ibm.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251208171559.2029709-1-jremus@linux.ibm.com> References: <20251208171559.2029709-1-jremus@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: G-R65yOj-nr7pPW8wQTZm1ZlLMUaWRfP X-Proofpoint-ORIG-GUID: Fq24udxWE1_jpmfHWPegkv1A0HnkQCb2 X-Authority-Analysis: v=2.4 cv=AdS83nXG c=1 sm=1 tr=0 ts=693707db cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=VnNF1IyMAAAA:8 a=-jCn-aex0Ddyt886wV4A:9 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjA2MDAwMCBTYWx0ZWRfX7cZxRWCVYHJV vZ/zBA1FwVH5VrNrcTdZVYs0wGdJpnuFjj2TiIKH6xd9i0HfYiCTfo64n0AgRjjUB6b5NF0/u7X 6JvH85ANFDtJq5DvFKg8YJoHQwv6WIv2WDjAQvVReDwiidlopoQ13ZOUrVAl2MVXErLVwr58Of6 OVg4jB3E+4fK8RREYZBLmbLXQ4h/HSuehu8gi0VJ1wja1QxmDJQqWDqDSNkL28fhIZjJQS5SCWT Qw9JVf9oI7dgAirIkZwgJLDwtX5+nrQuv2MUrIh+2IDGlCHv/HPES1f+ju714sQ/plpKIBMCPRT QnuVXJZp9/yiwSoGi+cj9zNVtgWTTG/6MkrVWgsaPngtTCQRBti9RuWYMDoPcd22+wuyZgMT7mp nbgpVbUKaEnuIch/sFwdpbnXDxouNA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-06_02,2025-12-04_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 priorityscore=1501 spamscore=0 phishscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1015 malwarescore=0 impostorscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2512060000 X-DKIM: signer='ibm.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 5 Enable unwinding of user space for architectures, such as s390, that save the return address (RA) and/or frame pointer (FP) in other registers. This is only valid in the topmost frame, for instance when in a leaf function. Signed-off-by: Jens Remus --- Notes (jremus): Changes in RFC v3: - Rename UNWIND_USER_LOC_NONE to UNWIND_USER_LOC_RETAIN to better disambiguate from new UNWIND_USER_LOC_UNKNOWN to be introduced for for back chain unwinding on s390. Other naming options: IDENTITY, KEEP, PRESERVE, SAME, UNCHANGED. Changes in RFC v2: - Reword HAVE_UNWIND_USER_LOC_REG help text. - Rename struct unwind_user_reginfo field frame_off to offset. (Josh) - Move dummy unwind_user_get_reg() from asm-generic/unwind_user.h to linux/unwind_user.h, drop its function comment, warn once, return -EINVAL, and guard by !HAVE_UNWIND_USER_LOC_REG. (Josh) - Rename generic_sframe_set_frame_reginfo() to sframe_init_reginfo() and drop its function comment. (Josh) - Do not check FP/RA offset for zero for UNWIND_USER_LOC_STACK. (Josh) - Do not check for !IS_ENABLED(CONFIG_HAVE_UNWIND_USER_LOC_REG), as the dummy implementation of unwind_user_get_reg() returns -EINVAL. - Drop config option HAVE_UNWIND_USER_LOC_REG, as it is no longer of any value. - Keep checking for topmost for UNWIND_USER_LOC_REG. (Jens) - Explicitly preserve FP if UNWIND_USER_LOC_NONE and drop later test for frame->fp.loc != UNWIND_USER_LOC_NONE. (Josh) Would it make sense to rename UNWIND_USER_LOC_NONE to one of the following to clarify its meaning for the unwinder? - UNWIND_USER_LOC_UNCHANGED - UNWIND_USER_LOC_RETAIN - UNWIND_USER_LOC_PRESERVED - UNWIND_USER_LOC_IDENTITY arch/x86/include/asm/unwind_user.h | 21 +++++++++++--- include/asm-generic/unwind_user_sframe.h | 15 ++++++++++ include/linux/unwind_user.h | 9 ++++++ include/linux/unwind_user_types.h | 18 ++++++++++-- kernel/unwind/sframe.c | 4 +-- kernel/unwind/user.c | 37 +++++++++++++++++++----- 6 files changed, 89 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/unwind_user.h b/arch/x86/include/asm/unwind_user.h index d70ffd7bbdb7..2480d86a405e 100644 --- a/arch/x86/include/asm/unwind_user.h +++ b/arch/x86/include/asm/unwind_user.h @@ -22,16 +22,27 @@ static inline int unwind_user_word_size(struct pt_regs *regs) #define ARCH_INIT_USER_FP_FRAME(ws) \ .cfa_off = 2*(ws), \ .sp_off = 0, \ - .ra_off = -1*(ws), \ - .fp_off = -2*(ws), \ + .ra = { \ + .loc = UNWIND_USER_LOC_STACK,\ + .offset = -1*(ws), \ + }, \ + .fp = { \ + .loc = UNWIND_USER_LOC_STACK,\ + .offset = -2*(ws), \ + }, \ .use_fp = true, \ .outermost = false, #define ARCH_INIT_USER_FP_ENTRY_FRAME(ws) \ .cfa_off = 1*(ws), \ .sp_off = 0, \ - .ra_off = -1*(ws), \ - .fp_off = 0, \ + .ra = { \ + .loc = UNWIND_USER_LOC_STACK,\ + .offset = -1*(ws), \ + }, \ + .fp = { \ + .loc = UNWIND_USER_LOC_RETAIN,\ + }, \ .use_fp = false, \ .outermost = false, @@ -43,4 +54,6 @@ static inline bool unwind_user_at_function_start(struct pt_regs *regs) #endif /* CONFIG_HAVE_UNWIND_USER_FP */ +#include + #endif /* _ASM_X86_UNWIND_USER_H */ diff --git a/include/asm-generic/unwind_user_sframe.h b/include/asm-generic/unwind_user_sframe.h index 8c9ac47bc8bd..fd71d6b1916b 100644 --- a/include/asm-generic/unwind_user_sframe.h +++ b/include/asm-generic/unwind_user_sframe.h @@ -2,6 +2,7 @@ #ifndef _ASM_GENERIC_UNWIND_USER_SFRAME_H #define _ASM_GENERIC_UNWIND_USER_SFRAME_H +#include #include #ifndef SFRAME_SP_OFFSET @@ -9,4 +10,18 @@ #define SFRAME_SP_OFFSET 0 #endif +#ifndef sframe_init_reginfo +static inline void +sframe_init_reginfo(struct unwind_user_reginfo *reginfo, s32 offset) +{ + if (offset) { + reginfo->loc = UNWIND_USER_LOC_STACK; + reginfo->offset = offset; + } else { + reginfo->loc = UNWIND_USER_LOC_RETAIN; + } +} +#define sframe_init_reginfo sframe_init_reginfo +#endif + #endif /* _ASM_GENERIC_UNWIND_USER_SFRAME_H */ diff --git a/include/linux/unwind_user.h b/include/linux/unwind_user.h index bc2edae39955..61fd5c05d0f0 100644 --- a/include/linux/unwind_user.h +++ b/include/linux/unwind_user.h @@ -32,6 +32,15 @@ static inline int unwind_user_get_ra_reg(unsigned long *val) #define unwind_user_get_ra_reg unwind_user_get_ra_reg #endif +#ifndef unwind_user_get_reg +static inline int unwind_user_get_reg(unsigned long *val, int regnum) +{ + WARN_ON_ONCE(1); + return -EINVAL; +} +#define unwind_user_get_reg unwind_user_get_reg +#endif + int unwind_user(struct unwind_stacktrace *trace, unsigned int max_entries); #endif /* _LINUX_UNWIND_USER_H */ diff --git a/include/linux/unwind_user_types.h b/include/linux/unwind_user_types.h index 4656aa08a7db..4f78999a0750 100644 --- a/include/linux/unwind_user_types.h +++ b/include/linux/unwind_user_types.h @@ -27,11 +27,25 @@ struct unwind_stacktrace { unsigned long *entries; }; +enum unwind_user_loc { + UNWIND_USER_LOC_RETAIN, + UNWIND_USER_LOC_STACK, + UNWIND_USER_LOC_REG, +}; + +struct unwind_user_reginfo { + enum unwind_user_loc loc; + union { + s32 offset; + int regnum; + }; +}; + struct unwind_user_frame { s32 cfa_off; s32 sp_off; - s32 ra_off; - s32 fp_off; + struct unwind_user_reginfo ra; + struct unwind_user_reginfo fp; bool use_fp; bool outermost; }; diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c index 38b3577f5253..45cd7380ac38 100644 --- a/kernel/unwind/sframe.c +++ b/kernel/unwind/sframe.c @@ -307,8 +307,8 @@ static __always_inline int __find_fre(struct sframe_section *sec, frame->cfa_off = fre->cfa_off; frame->sp_off = SFRAME_SP_OFFSET; - frame->ra_off = fre->ra_off; - frame->fp_off = fre->fp_off; + sframe_init_reginfo(&frame->ra, fre->ra_off); + sframe_init_reginfo(&frame->fp, fre->fp_off); frame->use_fp = SFRAME_FRE_CFA_BASE_REG_ID(fre->info) == SFRAME_BASE_REG_FP; frame->outermost = fre->ra_undefined; diff --git a/kernel/unwind/user.c b/kernel/unwind/user.c index 58e1549cd9f4..45f82ed28fcb 100644 --- a/kernel/unwind/user.c +++ b/kernel/unwind/user.c @@ -62,22 +62,45 @@ static int unwind_user_next_common(struct unwind_user_state *state, return -EINVAL; /* Get the Return Address (RA) */ - if (frame->ra_off) { - if (get_user_word(&ra, cfa, frame->ra_off, state->ws)) - return -EINVAL; - } else { + switch (frame->ra.loc) { + case UNWIND_USER_LOC_RETAIN: if (!state->topmost || unwind_user_get_ra_reg(&ra)) return -EINVAL; + break; + case UNWIND_USER_LOC_STACK: + if (get_user_word(&ra, cfa, frame->ra.offset, state->ws)) + return -EINVAL; + break; + case UNWIND_USER_LOC_REG: + if (!state->topmost || unwind_user_get_reg(&ra, frame->ra.regnum)) + return -EINVAL; + break; + default: + WARN_ON_ONCE(1); + return -EINVAL; } /* Get the Frame Pointer (FP) */ - if (frame->fp_off && get_user_word(&fp, cfa, frame->fp_off, state->ws)) + switch (frame->fp.loc) { + case UNWIND_USER_LOC_RETAIN: + fp = state->fp; + break; + case UNWIND_USER_LOC_STACK: + if (get_user_word(&fp, cfa, frame->fp.offset, state->ws)) + return -EINVAL; + break; + case UNWIND_USER_LOC_REG: + if (!state->topmost || unwind_user_get_reg(&fp, frame->fp.regnum)) + return -EINVAL; + break; + default: + WARN_ON_ONCE(1); return -EINVAL; + } state->ip = ra; state->sp = sp; - if (frame->fp_off) - state->fp = fp; + state->fp = fp; state->topmost = false; return 0; } -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id UFSGDNUKN2l2AS8AYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 17:28:53 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 17:28:53 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSf2a-0000000D4O1-2F02 for hi@josie.lol; Mon, 08 Dec 2025 17:28:52 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id CC3FF3020C07 for ; Mon, 8 Dec 2025 17:27:58 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 72D8C31A54F; Mon, 8 Dec 2025 17:16:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="ZS84WJuv" X-Original-To: linux-s390@vger.kernel.org Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) (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 DDCB13161A5; Mon, 8 Dec 2025 17:16:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.156.1 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214215; cv=none; b=gvEqYWv7hux29Civ/HCT8HhZhejeXFjDrO9PQkGzfVIKkTK7L/E06libK7PyyIj7KORZMGXhHhbL6FpRYMTzd1ck4OSSSOFOWmMCB+8YgNl+NzapDD0AGxzpkA/MCUtvkXkHlCLU0yPFEEWjQ4GcCP6tIadSKrMMVxnJg1NNQ8k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765214215; c=relaxed/simple; bh=+PTAx+xk0uWM77FaXhFQt3ax5/oyP+squs7mk+HZo5w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iuevG9sHlQ7nCdsALab3vAtNgxigYVj99oRzFlmtxfnrFnuuwT5TmifXUv8giV073TN5pijpRKdNC4RfvODNrPFu+dTO48BM2JQezt5PH7wh5MdbH+V0iP8SA1wdYAhei6CQMKTFmkJX8lWfRbWlbXryMvM1UBtwCkQlTMXbyN8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=ZS84WJuv; arc=none smtp.client-ip=148.163.156.1 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 5B8E0o2Z002119; Mon, 8 Dec 2025 17:16:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=pp1; bh=ERKVCVG8jzqXJzGSx S764A/gXKRZvq6CU6QCd1pLJow=; b=ZS84WJuvxHGkAzwD1f+WQwWLd9XR+PZG5 d5bVQ+IJP7w/XPWU1jVYIctNqUr2hTgQLV1rkMjyZ+yer4QvfKkfqkfq7CPwxC1U L27F5H3RsKlfI4J8noUXM5u+xUVdGIk9ngDRcknXbazSkit25FjpeylgTCYIt2A8 2voXWh3i2l1/bIzS/EldmrI3E2Hqfd/wTHjxZzVDAsqa7mxpjqKkoC2gsnEi282c 7tLewXE6eQqV5FcqdsxwdKUHL7JlKF1yEYJL6TnICJI6suHFZTPT7MVFL3I7u6Fz LtEawg4wVq2yrweDLFXDNIDwBFafN0AMne6gqKaLp+GELt6walPIw== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4avc0jrwuk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:13 +0000 (GMT) Received: from m0360083.ppops.net (m0360083.ppops.net [127.0.0.1]) by pps.reinject (8.18.1.12/8.18.0.8) with ESMTP id 5B8H0pOj016147; Mon, 8 Dec 2025 17:16:12 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4avc0jrwud-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:12 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 5B8EPJHb030452; Mon, 8 Dec 2025 17:16:11 GMT Received: from smtprelay06.fra02v.mail.ibm.com ([9.218.2.230]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4avxtrxxsg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Dec 2025 17:16:11 +0000 Received: from smtpav07.fra02v.mail.ibm.com (smtpav07.fra02v.mail.ibm.com [10.20.54.106]) by smtprelay06.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 5B8HG7hu27328864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Dec 2025 17:16:07 GMT Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6F50F20040; Mon, 8 Dec 2025 17:16:07 +0000 (GMT) Received: from smtpav07.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1318D2004B; Mon, 8 Dec 2025 17:16:07 +0000 (GMT) Received: from tuxmaker.boeblingen.de.ibm.com (unknown [9.87.85.9]) by smtpav07.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 8 Dec 2025 17:16:07 +0000 (GMT) From: Jens Remus To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-s390@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org, Steven Rostedt Cc: Jens Remus , Heiko Carstens , Vasily Gorbik , Ilya Leoshkevich , Josh Poimboeuf , Masami Hiramatsu , Mathieu Desnoyers , Peter Zijlstra , Ingo Molnar , Jiri Olsa , Arnaldo Carvalho de Melo , Namhyung Kim , Thomas Gleixner , Andrii Nakryiko , Indu Bhagat , "Jose E. Marchesi" , Beau Belgrave , Linus Torvalds , Andrew Morton , Florian Weimer , Kees Cook , "Carlos O'Donell" , Sam James , Dylan Hatch Subject: [RFC PATCH v3 14/17] s390/unwind_user/sframe: Enable HAVE_UNWIND_USER_SFRAME Date: Mon, 8 Dec 2025 18:15:56 +0100 Message-ID: <20251208171559.2029709-15-jremus@linux.ibm.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251208171559.2029709-1-jremus@linux.ibm.com> References: <20251208171559.2029709-1-jremus@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Authority-Analysis: v=2.4 cv=Cf8FJbrl c=1 sm=1 tr=0 ts=693707dd cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=NEAV23lmAAAA:8 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=SgTjFYeX4wDDoTrxqN8A:9 X-Proofpoint-ORIG-GUID: 2ffayoUyB0-OeWRLb9-TG8hsPYrlY6PC X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjA2MDAxNiBTYWx0ZWRfX23xzFk2YT9gP kI5wsYAAgfKZPr+qrEaVN28O1pSXX80AWKK1wB7rj5eVAKO3p885ftLj+Q4M+nt9EtW4ImkUWIi 3DExCwhERzbnVQHv7nHJvU81EwirEhT78U5a5RpHiNcMJ7g6a9VeQcxdssgtudQoJISeKf/03A9 OK+ihIGT7ZJQ5dziKZyolpWUDN3fUwUeonF2EoPsxObabQkQ14yZ15lca3SzjOkql3yczletbe2 YJAZpgiqr/fW2VoJVq0Bdr+n25Nr3mNJA3EUeJ7e9bbheHOPa1xTyAlfuyAs9RFzmDzhc9oTUOK USp7voYr7pU7kxal1ikIDga1BOeZ/fjRQlEgnoo+uzELPNl9qXmtRPZI1uOFFdu4lLt2ePZgUIY sjFnmK+0G8N/VwQ2wNeO80WAMwXPnA== X-Proofpoint-GUID: w72dwIz2zjyYTJ5puLevut7RTloBJquv X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-06_02,2025-12-04_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 bulkscore=0 malwarescore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 spamscore=0 suspectscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2510240000 definitions=main-2512060016 X-DKIM: signer='ibm.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.5 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 5 Add s390 support for unwinding of user space using SFrame. This leverages the previous commits to address the following s390 particularities: - The CFA is defined as the value of the stack pointer (SP) at call site in the previous frame + 160. Therefore the SP unwinds as SP = CFA - 160. Therefore use a SP value offset from CFA of -160. - The return address (RA) is not saved on the stack at function entry. It is also not saved in the function prologue, when in leaf functions. Therefore the RA does not necessarily need to be unwound in the first unwinding step for the topmost frame. - The frame pointer (FP) and/or return address (RA) may be saved in other registers when in leaf functions. GCC effectively uses floating-point registers (FPR) for this purpose. Therefore DWARF register numbers may be encoded in the SFrame FP/RA offsets. - To make use of the signed 8-bit SFrame offset size and effectively reduce the .sframe section size the SFrame CFA offset values are encoded as (CFA - 160) / 8. This is because the lowest CFA offset value on s390 is by definition +160 (= value at function entry), which does not fit into a signed 8-bit SFrame offset. Therefore the CFA offset values are stored adjusted by -160. Additionally they are scaled by the s390-specific DWARF data scaling factor of 8. The s390x ELF ABI [1] guarantees that the CFA offset values are always aligned on an 8-byte boundary. Add s390-specific SFrame format definitions. Note that SFRAME_ABI_* (and thus SFRAME_ABI_S390_ENDIAN_BIG) is currently unused. Include after "sframe.h" to make those s390-specific definitions available to architecture-specific unwind user sframe code, particularly the s390-specific one. [1]: s390x ELF ABI, https://github.com/IBM/s390x-abi/releases Signed-off-by: Jens Remus --- Notes (jremus): Changes in RFC v3: - Adjust to rename of UNWIND_USER_LOC_NONE to UNWIND_USER_LOC_RETAIN. - Adjust s390-specific unwind_user_word_size() to changes in the x86-specific (see patch 4). Changes in RFC v2: - Provide unwind_user_word_size() to satisfy new unwind user need. Note that support for COMPAT has not been implemented as s390 support for COMPAT is expected to be removed with v6.19: https://lore.kernel.org/all/20251201102713.22472A5b-hca@linux.ibm.com/ - Adjust to changes in preceding patches in this series that enable support in unwind user (sframe) for s390 particularities. Alternatively the s390-specific definitions could also be added to the s390-specific unwind user sframe header. The current implementation follows Binutils approach to have all SFrame format definitions in one central header file. arch/s390/Kconfig | 1 + arch/s390/include/asm/unwind_user.h | 100 +++++++++++++++++++++ arch/s390/include/asm/unwind_user_sframe.h | 33 +++++++ kernel/unwind/sframe.c | 2 +- kernel/unwind/sframe.h | 14 +++ 5 files changed, 149 insertions(+), 1 deletion(-) create mode 100644 arch/s390/include/asm/unwind_user.h create mode 100644 arch/s390/include/asm/unwind_user_sframe.h diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index df22b10d9141..52d3f3b3e086 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -246,6 +246,7 @@ config S390 select HAVE_SETUP_PER_CPU_AREA select HAVE_SOFTIRQ_ON_OWN_STACK select HAVE_SYSCALL_TRACEPOINTS + select HAVE_UNWIND_USER_SFRAME select HAVE_VIRT_CPU_ACCOUNTING select HAVE_VIRT_CPU_ACCOUNTING_IDLE select HOTPLUG_SMT diff --git a/arch/s390/include/asm/unwind_user.h b/arch/s390/include/asm/unwind_user.h new file mode 100644 index 000000000000..3a95be1eb886 --- /dev/null +++ b/arch/s390/include/asm/unwind_user.h @@ -0,0 +1,100 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_S390_UNWIND_USER_H +#define _ASM_S390_UNWIND_USER_H + +#include +#include +#include + +#ifdef CONFIG_UNWIND_USER + +static inline int unwind_user_word_size(struct pt_regs *regs) +{ + return 8; +} + +static inline int arch_unwind_user_get_ra_reg(unsigned long *val) +{ + struct pt_regs *regs = task_pt_regs(current); + *val = regs->gprs[14]; + return 0; +} +#define unwind_user_get_ra_reg arch_unwind_user_get_ra_reg + +static inline int __s390_get_dwarf_fpr(unsigned long *val, int regnum) +{ + switch (regnum) { + case 16: + fpu_std(0, (freg_t *)val); + break; + case 17: + fpu_std(2, (freg_t *)val); + break; + case 18: + fpu_std(4, (freg_t *)val); + break; + case 19: + fpu_std(6, (freg_t *)val); + break; + case 20: + fpu_std(1, (freg_t *)val); + break; + case 21: + fpu_std(3, (freg_t *)val); + break; + case 22: + fpu_std(5, (freg_t *)val); + break; + case 23: + fpu_std(7, (freg_t *)val); + break; + case 24: + fpu_std(8, (freg_t *)val); + break; + case 25: + fpu_std(10, (freg_t *)val); + break; + case 26: + fpu_std(12, (freg_t *)val); + break; + case 27: + fpu_std(14, (freg_t *)val); + break; + case 28: + fpu_std(9, (freg_t *)val); + break; + case 29: + fpu_std(11, (freg_t *)val); + break; + case 30: + fpu_std(13, (freg_t *)val); + break; + case 31: + fpu_std(15, (freg_t *)val); + break; + default: + return -EINVAL; + } + + return 0; +} + +static inline int arch_unwind_user_get_reg(unsigned long *val, int regnum) +{ + if (0 <= regnum && regnum <= 15) { + struct pt_regs *regs = task_pt_regs(current); + *val = regs->gprs[regnum]; + return 0; + } else if (16 <= regnum && regnum <= 31) { + return __s390_get_dwarf_fpr(val, regnum); + } + + return -EINVAL; +} +#define unwind_user_get_reg arch_unwind_user_get_reg + +#endif /* CONFIG_UNWIND_USER */ + +#include + +#endif /* _ASM_S390_UNWIND_USER_H */ diff --git a/arch/s390/include/asm/unwind_user_sframe.h b/arch/s390/include/asm/unwind_user_sframe.h new file mode 100644 index 000000000000..af650596cb5d --- /dev/null +++ b/arch/s390/include/asm/unwind_user_sframe.h @@ -0,0 +1,33 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_S390_UNWIND_USER_SFRAME_H +#define _ASM_S390_UNWIND_USER_SFRAME_H + +#include +#include + +#define SFRAME_SP_OFFSET SFRAME_S390X_SP_VAL_OFFSET + +static inline s32 arch_sframe_cfa_offset_decode(s32 offset) +{ + return SFRAME_V2_S390X_CFA_OFFSET_DECODE(offset); +} +#define sframe_cfa_offset_decode arch_sframe_cfa_offset_decode + +static inline void +arch_sframe_init_reginfo(struct unwind_user_reginfo *reginfo, s32 offset) +{ + if (SFRAME_V2_S390X_OFFSET_IS_REGNUM(offset)) { + reginfo->loc = UNWIND_USER_LOC_REG; + reginfo->regnum = SFRAME_V2_S390X_OFFSET_DECODE_REGNUM(offset); + } else if (offset) { + reginfo->loc = UNWIND_USER_LOC_STACK; + reginfo->offset = offset; + } else { + reginfo->loc = UNWIND_USER_LOC_RETAIN; + } +} +#define sframe_init_reginfo arch_sframe_init_reginfo + +#include + +#endif /* _ASM_S390_UNWIND_USER_SFRAME_H */ diff --git a/kernel/unwind/sframe.c b/kernel/unwind/sframe.c index 92f770fc21f6..bd446d55b552 100644 --- a/kernel/unwind/sframe.c +++ b/kernel/unwind/sframe.c @@ -12,11 +12,11 @@ #include #include #include -#include #include #include "sframe.h" #include "sframe_debug.h" +#include struct sframe_fde_internal { unsigned long func_start_addr; diff --git a/kernel/unwind/sframe.h b/kernel/unwind/sframe.h index 69ce0d5b9694..c09f25fbaa2f 100644 --- a/kernel/unwind/sframe.h +++ b/kernel/unwind/sframe.h @@ -18,6 +18,7 @@ #define SFRAME_ABI_AARCH64_ENDIAN_BIG 1 #define SFRAME_ABI_AARCH64_ENDIAN_LITTLE 2 #define SFRAME_ABI_AMD64_ENDIAN_LITTLE 3 +#define SFRAME_ABI_S390X_ENDIAN_BIG 4 /* s390 64-bit (s390x) */ #define SFRAME_FDE_TYPE_PCINC 0 #define SFRAME_FDE_TYPE_PCMASK 1 @@ -69,4 +70,17 @@ struct sframe_fde { #define SFRAME_FRE_OFFSET_SIZE(data) ((data >> 5) & 0x3) #define SFRAME_FRE_MANGLED_RA_P(data) ((data >> 7) & 0x1) +/* s390 64-bit (s390x) */ + +#define SFRAME_S390X_SP_VAL_OFFSET (-160) + +#define SFRAME_S390X_CFA_OFFSET_ADJUSTMENT SFRAME_S390X_SP_VAL_OFFSET +#define SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR 8 +#define SFRAME_V2_S390X_CFA_OFFSET_DECODE(offset) \ + (((offset) * SFRAME_S390X_CFA_OFFSET_ALIGNMENT_FACTOR) \ + - SFRAME_S390X_CFA_OFFSET_ADJUSTMENT) + +#define SFRAME_V2_S390X_OFFSET_IS_REGNUM(offset) ((offset) & 1) +#define SFRAME_V2_S390X_OFFSET_DECODE_REGNUM(offset) ((offset) >> 1) + #endif /* _SFRAME_H */ -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id kOTKAWkvN2movT8AYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 20:04:57 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 20:04:57 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vShTc-00000000nKl-3GuA for hi@josie.lol; Mon, 08 Dec 2025 20:04:57 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id B71DF301FA4C for ; Mon, 8 Dec 2025 20:04:55 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B2A6C2FD1D5; Mon, 8 Dec 2025 20:04:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MeEIS0G7" X-Original-To: stable@vger.kernel.org Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D24AC238C2F for ; Mon, 8 Dec 2025 20:04:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765224294; cv=none; b=Pts/fNm9XvkhnremIL/W3SABkAJOLAFy2ijmatnXnwYLxwapNUQTIDKhIeLWEpHJzmmFZcbIv9EZ/zGcmFlPBmOsRF0dP5GUphQ0bCz5Ixj2eaiqk6fOPE03hAWztxybDseyL9vbGGHW15olBEJfM9CVGqBBXWikyMWn0oUnGa4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765224294; c=relaxed/simple; bh=skKjEfBaMU6Lqt5vjsIobNng9NkDUQtxDFU5ZUjwvRo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=SvwpyaI23Xl2k3Zlw/Hd1tRQM3n+AFsHG0GKS25pChvfZ0gXU+jaiVkBooZbAEOx1jbbGUruuqMC8tuwjSq7TvsBHcVhVtF/UptO4ibgMfzvFzr/S+TuQivG3rYvcqHy60K9piTe2vH9xGqGxz+fRllTxija6ik8gU1ZaNVQG78= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MeEIS0G7; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4779a637712so36193845e9.1 for ; Mon, 08 Dec 2025 12:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765224291; x=1765829091; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=d9WaSQQ0PkGqeHp9LL2kJRaAe2H4lpRnuEoZ98r23rw=; b=MeEIS0G7PiMgjbTOTLGE6XhhpJGtxjfb37lIXHx8l1yWXKyfcRu7DTqlNUR6T225Vk vOjbrWKOfZPeUSIr+mbYGZbRAUlCJUoo1SWWZHm2CjpAYUMXy/HDI1wK+3m5pfKqSzLZ kYmPGgsTku7Q8Yf3Lr2YOT9yhIE2pbqVzrpX+zjLlkt8Xw08+30/muL3qx8adXiTcpxv f9NYz7iIFI0CYwicFBCarscDQyM4CZ/Vk+DkRdygPDIKorAym6JtXna46bgjEyyudtHY I/u9EVhO+Q7o6mb6v2+LWmfw72JI95MLKyBag2tD/nZOWYWEK4Hs6R8MBTIwpdKBrPQL nxGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765224291; x=1765829091; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=d9WaSQQ0PkGqeHp9LL2kJRaAe2H4lpRnuEoZ98r23rw=; b=H04pGqy93Iw7f2E6pbzLfUrbITmZaXH8ZvZhlfZn2V2vR4j9N6uprKGo3ZX9CHiVmY LGvz6qnolFkgij/myNAQjYpaEZo1L1ci4adQ34SN/+TmVReUZAihS495fP96yzjymLyz sK0CZASU6N+8sGrhSiK1Kr86cd78RIQQOK+VHlvPDc5WfnE+aEgKJUPijSju44uoV2yC c0lR3+hxDVgSvNUK9byhhmhw80qGuW+LMYP+zr3EsR7rqJ3HYouqyYuIExM95d901yT0 BWFphrXzIZrOHyjk6F2aqEvsfm+mlgqlX4K33fCOr4gNkOj1lhID6+Ls94nd15kRxjbD ghKQ== X-Forwarded-Encrypted: i=1; AJvYcCX9lCyaQsBcBKkdPDtqc0E7IhHgINww79mMIucOVaMTLyU+VQu8RWRAkUTUSgbevsfG0CHUwII=@vger.kernel.org X-Gm-Message-State: AOJu0YxNgEkB85Bu01k7MBPz0SFrUNyOkPM2KEAsq+KqxVpHXaUcoE4l E0l+t2omt6VlZR05zfrszrlq0Yw0DjQB1NbHBh6leH3IYBNFIo3TE0hYYtILXw== X-Gm-Gg: ASbGncvU+TifgoN3/ErYGUadgP9nvD3yW8a83BAZ9+rRUWdXfUdQlnYPAEyIqdA2WX1 OsAgiewNAZIjqgZZ73NFBnpyLDSmDqKnvXLWck1PP5pbwXrCCSE4NGZGOA1Whcx8Rwu7tlCALfj n7DKlSkqmdBfooK5gVhVv1Em7l3it95v8uXnMfwC0GRju15g82HjR2eM/52hjOzRWYQYM4lct4k 6OF2lgzopcGJbPzt8x1wAp9MJe5TAtf5obfPSckHLRDvIIej4e77djH+t7+z3cAkfQK5OMjHOQm cxlyeJtMRKHuy91cucD6HuZ16fo5G6S8PNPIpHegOr+lNvZfK1vYcQBaK9vZE/5GLNyFJIeGbbL Mu/hZ/j7/7KZYt9iodXfzPe62+6MTRnrAwIdZeSN6L7IO7LsmwC1yP/PXdmfQ465BUB8HxzZxXh XmQ9FjevVSuBCrgDpiP+ctnsdGNyW1uzI+FyIwDNAXXVg5ip7a2pY= X-Google-Smtp-Source: AGHT+IELJ4QWyLI18G+CslWw8CT4fzH53HDJS5AGtq1akWXecKkPf5nz0AOnRqyw1ggDtLTR6UltQg== X-Received: by 2002:a05:600c:3b8b:b0:477:af07:dd17 with SMTP id 5b1f17b1804b1-47939e3897cmr134757755e9.24.1765224290994; Mon, 08 Dec 2025 12:04:50 -0800 (PST) Received: from Ansuel-XPS24 (93-34-88-81.ip49.fastwebnet.it. [93.34.88.81]) by smtp.googlemail.com with ESMTPSA id 5b1f17b1804b1-47a7d6eb1f1sm1906885e9.2.2025.12.08.12.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Dec 2025 12:04:50 -0800 (PST) From: Christian Marangi To: Jeff Johnson , Vasanthakumar Thiagarajan , "Rob Herring (Arm)" , linux-wireless@vger.kernel.org, ath11k@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Christian Marangi , stable@vger.kernel.org, =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= Subject: [net PATCH] wifi: ath11k: fix wrong usage of resource_size() causing firmware panic Date: Mon, 8 Dec 2025 21:04:32 +0100 Message-ID: <20251208200437.14199-1-ansuelsmth@gmail.com> X-Mailer: git-send-email 2.51.0 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='gmail.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [ansuelsmth[at]gmail.com] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 On converting to the of_reserved_mem_region_to_resource() helper with commit 900730dc4705 ("wifi: ath: Use of_reserved_mem_region_to_resource() for "memory-region"") a logic error was introduced in the ath11k_core_coldboot_cal_support() if condition. The original code checked for hremote_node presence and skipped ath11k_core_coldboot_cal_support() in the other switch case but now everything is driven entirely on the values of the resource struct. resource_size() (in this case) is wrongly assumed to return a size of zero if the passed resource struct is init to zero. This is not the case as a resource struct should be always init with correct values (or at best set the end value to -1 to signal it's not configured) (the return value of resource_size() for a resource struct with start and end set to zero is 1) On top of this, using resource_size() to check if a resource struct is initialized or not is generally wrong and other measure should be used instead. To better handle this, use the DEFINE_RES macro to initialize the resource struct and set the IORESOURCE_UNSET flag by default. Replace the resource_size() check with checking for the resource struct flags and check if it's IORESOURCE_UNSET. This change effectively restore the original logic and restore correct loading of the ath11k firmware (restoring correct functionality of Wi-Fi) Cc: stable@vger.kernel.org Fixes: 900730dc4705 ("wifi: ath: Use of_reserved_mem_region_to_resource() for "memory-region"") Link: https://lore.kernel.org/all/20251207215359.28895-1-ansuelsmth@gmail.com/T/#m990492684913c5a158ff0e5fc90697d8ad95351b Cc: Ilpo Järvinen Signed-off-by: Christian Marangi --- drivers/net/wireless/ath/ath11k/qmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/qmi.c b/drivers/net/wireless/ath/ath11k/qmi.c index ff6a97e328b8..afa663c00620 100644 --- a/drivers/net/wireless/ath/ath11k/qmi.c +++ b/drivers/net/wireless/ath/ath11k/qmi.c @@ -2039,8 +2039,8 @@ static int ath11k_qmi_alloc_target_mem_chunk(struct ath11k_base *ab) static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base *ab) { + struct resource res = DEFINE_RES(0, 0, IORESOURCE_UNSET); struct device *dev = ab->dev; - struct resource res = {}; u32 host_ddr_sz; int i, idx, ret; @@ -2086,7 +2086,7 @@ static int ath11k_qmi_assign_target_mem_chunk(struct ath11k_base *ab) } if (ath11k_core_coldboot_cal_support(ab)) { - if (resource_size(&res)) { + if (res.flags != IORESOURCE_UNSET) { ab->qmi.target_mem[idx].paddr = res.start + host_ddr_sz; ab->qmi.target_mem[idx].iaddr = -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 2AhQKepSN2mJkRMAYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 22:36:26 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 22:36:26 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSjqE-00000005mlA-18Fv for hi@josie.lol; Mon, 08 Dec 2025 22:36:26 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 33B1A3007285 for ; Mon, 8 Dec 2025 22:36:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6947A2641C6; Mon, 8 Dec 2025 22:36:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="e4nvfd6V" X-Original-To: stable@vger.kernel.org Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E22F3B8D63 for ; Mon, 8 Dec 2025 22:36:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765233384; cv=none; b=ANqrpZddtAbMf6w4kbwPP0u4pEYUTL94tv84DSnZiQdYRy08g4p77ravxrcVdeXPqUwjCNKsost8TkthMpejnl7HMBH25s7yqQh9DQl28WUYotjq6jxcgv8kgfqnXZEJ0aPvGMKMBNMO7y5Ov15c9rOucuzaJc/WejflyKCtaRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765233384; c=relaxed/simple; bh=Q2G/MZtVBoEaCJauZ/cHmYZaRZTZNUt7d4RLedJ+aMU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mZPr0028iE5Xi+0kFnqvG7eqqg1TSeccWWCy0rWLEuKH7I2Hpo/OubPn+ZwloE/r/cUXHA7j1Py2HqfEu5Kv7s5tF/hNWxiTkLbWiVDQtcqG+mBumRPq3AcRez/7kSuUjVbBRvWWCW8M8khBnG1X98dh5M6Lfl9ExnNamTJWxgM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=e4nvfd6V; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-4775ae77516so59627325e9.1 for ; Mon, 08 Dec 2025 14:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1765233381; x=1765838181; darn=vger.kernel.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=D4KD06lq2sAdPsV4RkTZMMEkkcHicyQ03NbVW7+GTqc=; b=e4nvfd6V20myoyx4sPbWfL/RXP1rQwdmAdq2qF8mYdpLIh62GRQVcC3qZmJsVNs0ZT uhfXlCn1Q/1vOm+PKY7kabAAXGhG/u6swFcnKnZMssTWtaAa0v9F+FzU8Uoxx5CNXi4x FhbUWb60nBjum44ZsVEysnD20tJVsotnFiEALa9rcDQaTIQc4IoPSevYFWwa1/3bKweT Wdb3djLiXPLqzDuZvPCHIlciRnDOPQ3eVcd8t58RNBjj1/1Yc8VJeluNEROlbRK9JVKM l9d6QJOrDkj4kanm7TJC7wrmIRWPbCg1n3eb9s8WOArCX7odCy1xAmK7v0dpM/Vri2iE 0UHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765233381; x=1765838181; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=D4KD06lq2sAdPsV4RkTZMMEkkcHicyQ03NbVW7+GTqc=; b=WX2C4by1V2xVM5U3/9ESrmbtoUkl4aOJEPeINhJXJ/AcHhVIo2vKQu9UKNa3zuSFOJ +f9K2qGhP9QoFrCWaK8VXekPffkihRNrISxRdmjRUVHgyQQXQ2g9AHB8FWFd/RYa2kpc iJOR9XQES8b0i1vmLxJzpuCu3yddKHfL2fJ6iwASA+yalgjxR4gdP/6bc608Ai8Po5nh eLuFi+S48UXhDDGgEI5D3s7gZjviVehuMIGQbr1lfm6NFaZP/5SNwAnWb/P6mU/no4LJ 8dfMTAXJOXr3Z1+gLDwN/nK7F86C2EMPFH580Y9KqVju8PdTI4WR6XE5EgC5cjcb42Do MCag== X-Forwarded-Encrypted: i=1; AJvYcCXRgUy2LMDJVezGSwmcP7El7XICe8hpUy8HS6xOVdnq2VgCTTVA51eThLdMjaGFLuwVV0/fIXE=@vger.kernel.org X-Gm-Message-State: AOJu0YzcJ9KPS8hl4h+2Xf5o1LSySjYDjUW4HJMNgWuvwF579LV5y/Uo vATihaL73en+aNCrA1VJpeexHid/X2ekEd4njt4RxvqLpYf2XO36BAim0x0eO2jI0N0dZJEruZ7 vI59nnRvG0xogzjSwN4WagCFtoIH8Cv47bqErYHOpJg== X-Gm-Gg: ASbGncurO05l0qFpxVWjAk7raN05fmbS5iXAsZKDxXjYnF9YmUUGsXVnIQgRBpBUeqh EkSe597AOp1fpRF4/cA6dvz9bG+3qMG5PRrszeSmv/H6HMjOwOMVzVK41RwQmLYfSTVcNdSherT oAC+Tv8TowVmzm50qG2QowdrUlh0EnCOhfEiFh19wm27Qs2N05h4cn59uan11c6BvE2Lth5jm0z 3rG6AIuPLbSL81ls4JbspZXhX+F5t+InyGknzybihcV931fcoJ9tVM1j2ZhnVafSrELeHc= X-Google-Smtp-Source: AGHT+IHdENdqQ5ZpfGKlDmPBmXNvBchycFRz1S91lwgqXoJLXzAP6AzIRd2MqCvVDm4uYekNJP736gqsi3Ttoiy1uEE= X-Received: by 2002:a05:6000:26ca:b0:3ff:17ac:a34b with SMTP id ffacd0b85a97d-42f89f7f743mr10799228f8f.42.1765233380524; Mon, 08 Dec 2025 14:36:20 -0800 (PST) Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251202-wip-obbardc-qcom-msm8096-clk-cpu-fix-downclock-v1-1-90208427e6b1@linaro.org> <8d769fb3-cd2a-492c-8aa3-064ebbc5eee4@oss.qualcomm.com> In-Reply-To: <8d769fb3-cd2a-492c-8aa3-064ebbc5eee4@oss.qualcomm.com> From: Christopher Obbard Date: Mon, 8 Dec 2025 22:36:09 +0000 X-Gm-Features: AQt7F2pyLxXm2GWb6gtwnpa1Ns2Gi_xPr5Pdfa1W2vBee9eceYgn1z1DZ-WxUWw Message-ID: Subject: Re: [PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb" To: Konrad Dybcio Cc: Bjorn Andersson , Michael Turquette , Stephen Boyd , Konrad Dybcio , Dmitry Baryshkov , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, Dmitry Baryshkov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-DKIM: signer='linaro.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 Hi Konrad, On Wed, 3 Dec 2025 at 10:52, Konrad Dybcio wrote: > > On 12/2/25 10:24 PM, Christopher Obbard wrote: > > This reverts commit b3b274bc9d3d7307308aeaf75f70731765ac999a. > > > > On the DragonBoard 820c (which uses APQ8096/MSM8996) this change causes > > the CPUs to downclock to roughly half speed under sustained load. The > > regression is visible both during boot and when running CPU stress > > workloads such as stress-ng: the CPUs initially ramp up to the expected > > frequency, then drop to a lower OPP even though the system is clearly > > CPU-bound. > > > > Bisecting points to this commit and reverting it restores the expected > > behaviour on the DragonBoard 820c - the CPUs track the cpufreq policy > > and run at full performance under load. > > > > The exact interaction with the ACD is not yet fully understood and we > > would like to keep ACD in use to avoid possible SoC reliability issues. > > Until we have a better fix that preserves ACD while avoiding this > > performance regression, revert the bisected patch to restore the > > previous behaviour. > > > > Fixes: b3b274bc9d3d ("clk: qcom: cpu-8996: simplify the cpu_clk_notifie= r_cb") > > Cc: stable@vger.kernel.org # v6.3+ > > Link: https://lore.kernel.org/linux-arm-msm/20230113120544.59320-8-dmit= ry.baryshkov@linaro.org/ > > Cc: Dmitry Baryshkov > > Signed-off-by: Christopher Obbard > > --- Apologies for the late response, I was in the process of setting some more msm8096 boards up again in my new workspace to test this properly. > It may be that your board really has a MSM/APQ8x96*SG* which is another > name for the PRO SKU, which happens to have a 2 times wider divider, try > > `cat /sys/bus/soc/devices/soc0/soc_id` I read the soc_id from both of the msm8096 boards I have: Open-Q=E2=84=A2 820 =C2=B5SOM Development Kit (APQ8096) ``` $ cat /sys/bus/soc/devices/soc0/soc_id 291 ``` (FWIW this board is not in mainline yet; but boots with a DT similar enough to the db820c. I have a patch in my upstream backlog enabling that board; watch this space) DragonBoard=E2=84=A2 820c (APQ8096) ``` $ cat /sys/bus/soc/devices/soc0/soc_id 291 ``` > see: > > https://lore.kernel.org/linux-arm-msm/20251111-db820c-pro-v1-0-6eece16c5c= 23@oss.qualcomm.com/ > > https://lore.kernel.org/linux-arm-msm/kXrAkKv7RZct22X0wivLWqOAiLKpFuDCAY1= KY_KSx649kn7BNmJ2IFFMrsYPAyDlcxIjbQCQ1PHb5KaNFawm9IGIXUbch-DI9OI_l73BAaM=3D= @protonmail.com/ Thanks for the pointers. Interesting, but it does look like my boards are msm8096 (and not the pro SKU). Can you confirm that at all from the soc_id above? Another bit of (hopefully useful) information is that the db820c boot firmware log sthe following, which is different to the logs I saw from the pro SKU (BUT the firmware could also be outdated?): ``` S - QC_IMAGE_VERSION_STRING=3DBOOT.XF.1.0-00301 S - IMAGE_VARIANT_STRING=3DM8996LAB S - OEM_IMAGE_VERSION_STRING=3Dcrm-ubuntu68 S - Boot Interface: UFS S - Secure Boot: Off S - Boot Config @ 0x00076044 =3D 0x000001c9 S - JTAG ID @ 0x000760f4 =3D 0x4003e0e1 S - OEM ID @ 0x000760f8 =3D 0x00000000 S - Serial Number @ 0x00074138 =3D 0x14d6d024 S - OEM Config Row 0 @ 0x00074188 =3D 0x0000000000000000 S - OEM Config Row 1 @ 0x00074190 =3D 0x0000000000000000 S - Feature Config Row 0 @ 0x000741a0 =3D 0x0050000010000100 S - Feature Config Row 1 @ 0x000741a8 =3D 0x00fff00001ffffff S - Core 0 Frequency, 1228 MHz B - 0 - PBL, Start B - 10414 - bootable_media_detect_entry, Start B - 50197 - bootable_media_detect_success, Start B - 50197 - elf_loader_entry, Start B - 51760 - auth_hash_seg_entry, Start B - 51863 - auth_hash_seg_exit, Start B - 85147 - elf_segs_hash_verify_entry, Start B - 87651 - PBL, End B - 89700 - SBL1, Start B - 185684 - usb: hs_phy_nondrive_start B - 186050 - usb: PLL lock success - 0x3 B - 189039 - usb: hs_phy_nondrive_finish B - 193156 - boot_flash_init, Start D - 30 - boot_flash_init, Delta B - 200263 - sbl1_ddr_set_default_params, Start D - 30 - sbl1_ddr_set_default_params, Delta B - 208254 - boot_config_data_table_init, Start D - 317169 - boot_config_data_table_init, Delta - (60 Bytes) B - 529968 - CDT Version:3,Platform ID:24,Major ID:1,Minor ID:0,Subtype:= 0 B - 534665 - Image Load, Start D - 22448 - PMIC Image Loaded, Delta - (37272 Bytes) B - 557143 - pm_device_init, Start B - 562908 - PON REASON:PM0:0x60 PM1:0x20 B - 599294 - PM_SET_VAL:Skip D - 40016 - pm_device_init, Delta B - 601216 - pm_driver_init, Start D - 2897 - pm_driver_init, Delta B - 607834 - pm_sbl_chg_init, Start D - 91 - pm_sbl_chg_init, Delta B - 614575 - vsense_init, Start D - 0 - vsense_init, Delta B - 624670 - Pre_DDR_clock_init, Start D - 396 - Pre_DDR_clock_init, Delta B - 628208 - ddr_initialize_device, Start B - 631899 - 8996 v3.x detected, Max frequency =3D 1.8 GHz B - 641537 - ddr_initialize_device, Delta B - 641567 - DDR ID, Rank 0, Rank 1, 0x6, 0x300, 0x300 B - 645410 - Basic DDR tests done B - 714157 - clock_init, Start D - 274 - clock_init, Delta B - 717543 - Image Load, Start D - 4331 - QSEE Dev Config Image Loaded, Delta - (46008 Bytes) B - 723002 - Image Load, Start D - 5307 - APDP Image Loaded, Delta - (0 Bytes) B - 731603 - usb: UFS Serial - a28415ce B - 735965 - usb: fedl, vbus_low B - 739594 - Image Load, Start D - 55449 - QSEE Image Loaded, Delta - (1640572 Bytes) B - 795043 - Image Load, Start D - 2043 - SEC Image Loaded, Delta - (4096 Bytes) B - 802607 - sbl1_efs_handle_cookies, Start D - 488 - sbl1_efs_handle_cookies, Delta B - 811117 - Image Load, Start D - 14365 - QHEE Image Loaded, Delta - (254184 Bytes) B - 825482 - Image Load, Start D - 14091 - RPM Image Loaded, Delta - (223900 Bytes) B - 840397 - Image Load, Start D - 3172 - STI Image Loaded, Delta - (0 Bytes) B - 847107 - Image Load, Start D - 34800 - APPSBL Image Loaded, Delta - (748620 Bytes) B - 881999 - SBL1, End D - 796569 - SBL1, Delta S - Flash Throughput, 94000 KB/s (2958928 Bytes, 31192 us) S - DDR Frequency, 1017 MHz Android Bootloader - UART_DM Initialized!!! [0] BUILD_VERSION=3D [0] BUILD_DATE=3D00:29:31 - Dec 4 2023 [0] welcome to lk ... ``` Cheers! Chris From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id +L5YCSVVN2mM2xAAYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 22:45:57 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 22:45:57 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSjzP-000000063n6-0KOJ for hi@josie.lol; Mon, 08 Dec 2025 22:45:57 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id 42C47300D554 for ; Mon, 8 Dec 2025 22:45:51 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 293CD2FBDF2; Mon, 8 Dec 2025 22:45:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b="KIPlUo3z" X-Original-To: io-uring@vger.kernel.org Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 526582BEC4E for ; Mon, 8 Dec 2025 22:45:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765233950; cv=none; b=KVqJGNtXyoyT0qRcCTNyy5VWnFvI/hgC+ZwFyuWC5qvIxV0gYqMcXVmyQ5Cq2N1hQZwgBN1dkaFNYhVb8YATnl7ptjrXsBBmq8FR0BKThMjZl1J1Yv7HMTt/EtOuEF/HK0bjJkVsF+qOtiw6NzHFyK10bEPo2l+wZNUV3hn8PFE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765233950; c=relaxed/simple; bh=VFeZzew3wgU3lnQXtHo0aCDQL4wEBDLOCuXv4A6jDIs=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=L3ReSARBMLh5qcvtI5cc7k3QEqVtyxVKTBhv4/g9I8lgnFinGGKZv+OpeZXecxUk08s4nr9fvmOAtIA3Nt2TqT4LTKwI38mU9DJqLXWE72d8uQT+PFnOPqBd0OtkBzZcg0xqpSW7dqEIpf8s40cFAczfPPITVTqSb9fMUSpsOvI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com; spf=fail smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=KIPlUo3z; arc=none smtp.client-ip=209.85.215.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=purestorage.com Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=purestorage.com Received: by mail-pg1-f170.google.com with SMTP id 41be03b00d2f7-bda175a2013so545442a12.3 for ; Mon, 08 Dec 2025 14:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1765233947; x=1765838747; darn=vger.kernel.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=saoX2yZ96AIA3oGqO7CACdTr6VxjaneFvI1/wcG9YMg=; b=KIPlUo3znV8lVLASmnKPusdQaLUIx+ANetX94CJghL/77jG2oLko1YgOeE+5wPPEOv zdv2RyJy5eCXPgrnU2ux1mRQKEmQmDjFWjeothyJKmxurJaGWpOHmW6O2Cw4HeP9Y7ll FaLxQMm5z6ENbl3EsNBtIOaYv1yb2K491fC0DvFZ12H/l53Uijxd2PPs9e6o7AAQPRJK JmTxjGUyEcr90+YXrbctc799J79lniHdLpXkvbeC+lVVQtnqd8FHjWyWWLKGlL2H407R PQ4dY/7/ri3sdMjUtPA2eBUFZPvRBBjH+h0YCZYW0MZKGBHr8wd350z0p1P3Izakjac4 MwYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765233947; x=1765838747; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=saoX2yZ96AIA3oGqO7CACdTr6VxjaneFvI1/wcG9YMg=; b=cIP+rQWddmpZv/qbm9wbNiE5k2WiiVTKUSbCz4kawZSRiywGX3SSKKYvdxwhXVBlko ceBY7usfLMPbM4r2ANfvSGycmlWtMnCIp5ke84jEPgjwX27DqK0/Lgp2nHjpp2q2ZKle HdmBav+mcMsLuKOmT4Y6B2v2xXQBlwk9lLgmcO2wbBA2LMZieVeTi7MXHrDcI8awG5Fv BWXqoqbtHqZJanvssg3gRJn5/Cqe+pb3jUC7kjcHIqdiOW9Wg33haKRoqfbq4trivTMJ 9L/MhlIlXehwHpxQUfDIdaF+arjf4t1p7MCMHYldB/YkQJP3w1IyQLoZ/PS+ZtL272eF WZuw== X-Forwarded-Encrypted: i=1; AJvYcCXDMWb9uVMzZfD1BWQKFQwaLHEBM0JAnt6Zd86dAZl7WZQs5m089w+asDZzaQxQhMAPNdyvjKuqZA==@vger.kernel.org X-Gm-Message-State: AOJu0Yy0m6sW0tAwCs59j8024T/Y2K6GsYJ7dTZLlaU09NnImttjfi+4 wy7ERVAxZlLUO7AGtaaNvVF8crH1lxbsiHmOrARP4UWF9D4tVxAR5ZTk6QyCu5vYiPVNJ9CfPwC /fQiN3/fMHeYNKCe/m/z13DQy5TJ1HiO0nZ4q+xabGQ== X-Gm-Gg: ASbGncv0cwoRCWQoqmeIzNNDchpclIpQYkk04OlsntcNnQ4H1lXBYnMdukcw3VJgviY Q8vjZV2NciNe8xUF84IJG+9e2OvtUGueCn618LHls7C80HRSbyitUN4AGP0PeOf6U0o9JjIHveq lBW4n19KzgNA2+nd8fpUtBN9pGLssrATZIiQi8tqTYlKjf6r4z31bEUUQ3dwDSoxMHjjtsXlixJ zhtRpeW2U3cOJM6+MddSBGm8gXpp4fdz+EK57GMpO5IPOi3a2WunC19XaJWfMmnJJ0V+Hwx X-Google-Smtp-Source: AGHT+IEH8vn0YkufwzP5KoioqcF+B+bfSkDJPKAiwQyXImDOUGGYU9z5zZ1EKUPSoOSNHlemuG0HXEO0nxWEW/DuCOY= X-Received: by 2002:a05:7022:4295:b0:11a:5cb2:24a0 with SMTP id a92af1059eb24-11f22ac22dcmr314098c88.1.1765233947177; Mon, 08 Dec 2025 14:45:47 -0800 (PST) Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251104162123.1086035-1-ming.lei@redhat.com> <20251104162123.1086035-4-ming.lei@redhat.com> <94f94f0e-7086-4f44-a658-9cb3b5496faf@samba.org> <05a37623-c78c-4a86-a9f3-c78ce133fa66@samba.org> In-Reply-To: From: Caleb Sander Mateos Date: Mon, 8 Dec 2025 14:45:35 -0800 X-Gm-Features: AQt7F2pSGWKWoB5ss4CT1dXU8m8wS_nB9lSMim5BYVLvyxvdvk7Knc4ySzLZnQg Message-ID: Subject: Re: [PATCH 3/5] io_uring: bpf: extend io_uring with bpf struct_ops To: Ming Lei Cc: Stefan Metzmacher , Jens Axboe , io-uring@vger.kernel.org, Akilesh Kailash , bpf@vger.kernel.org, Alexei Starovoitov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-DKIM: signer='purestorage.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: purestorage.com] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 On Thu, Nov 13, 2025 at 7:00=E2=80=AFPM Ming Lei wrot= e: > > On Thu, Nov 13, 2025 at 12:19:33PM +0100, Stefan Metzmacher wrote: > > Am 13.11.25 um 11:59 schrieb Ming Lei: > > > On Thu, Nov 13, 2025 at 11:32:56AM +0100, Stefan Metzmacher wrote: > > > > Hi Ming, > > > > > > > > > io_uring can be extended with bpf struct_ops in the following way= s: > > > > > > > > > > 1) add new io_uring operation from application > > > > > - one typical use case is for operating device zero-copy buffer, = which > > > > > belongs to kernel, and not visible or too expensive to export to > > > > > userspace, such as supporting copy data from this buffer to users= pace, > > > > > decompressing data to zero-copy buffer in Android case[1][2], or > > > > > checksum/decrypting. > > > > > > > > > > [1] https://lpc.events/event/18/contributions/1710/attachments/14= 40/3070/LPC2024_ublk_zero_copy.pdf > > > > > > > > > > 2) extend 64 byte SQE, since bpf map can be used to store IO data > > > > > conveniently > > > > > > > > > > 3) communicate in IO chain, since bpf map can be shared among IOs= , > > > > > when one bpf IO is completed, data can be written to IO chain wid= e > > > > > bpf map, then the following bpf IO can retrieve the data from thi= s bpf > > > > > map, this way is more flexible than io_uring built-in buffer > > > > > > > > > > 4) pretty handy to inject error for test purpose > > > > > > > > > > bpf struct_ops is one very handy way to attach bpf prog with kern= el, and > > > > > this patch simply wires existed io_uring operation callbacks with= added > > > > > uring bpf struct_ops, so application can define its own uring bpf > > > > > operations. > > > > > > > > This sounds useful to me. > > > > > > > > > Signed-off-by: Ming Lei > > > > > --- > > > > > include/uapi/linux/io_uring.h | 9 ++ > > > > > io_uring/bpf.c | 271 ++++++++++++++++++++++++++= +++++++- > > > > > io_uring/io_uring.c | 1 + > > > > > io_uring/io_uring.h | 3 +- > > > > > io_uring/uring_bpf.h | 30 ++++ > > > > > 5 files changed, 311 insertions(+), 3 deletions(-) > > > > > > > > > > diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/i= o_uring.h > > > > > index b8c49813b4e5..94d2050131ac 100644 > > > > > --- a/include/uapi/linux/io_uring.h > > > > > +++ b/include/uapi/linux/io_uring.h > > > > > @@ -74,6 +74,7 @@ struct io_uring_sqe { > > > > > __u32 install_fd_flags; > > > > > __u32 nop_flags; > > > > > __u32 pipe_flags; > > > > > + __u32 bpf_op_flags; > > > > > }; > > > > > __u64 user_data; /* data to be passed back at comp= letion time */ > > > > > /* pack this to avoid bogus arm OABI complaints */ > > > > > @@ -427,6 +428,13 @@ enum io_uring_op { > > > > > #define IORING_RECVSEND_BUNDLE (1U << 4) > > > > > #define IORING_SEND_VECTORIZED (1U << 5) > > > > > +/* > > > > > + * sqe->bpf_op_flags top 8bits is for storing bpf op > > > > > + * The other 24bits are used for bpf= prog > > > > > + */ > > > > > +#define IORING_BPF_OP_BITS (8) > > > > > +#define IORING_BPF_OP_SHIFT (24) > > > > > + > > > > > /* > > > > > * cqe.res for IORING_CQE_F_NOTIF if > > > > > * IORING_SEND_ZC_REPORT_USAGE was requested > > > > > @@ -631,6 +639,7 @@ struct io_uring_params { > > > > > #define IORING_FEAT_MIN_TIMEOUT (1U << 15) > > > > > #define IORING_FEAT_RW_ATTR (1U << 16) > > > > > #define IORING_FEAT_NO_IOWAIT (1U << 17) > > > > > +#define IORING_FEAT_BPF (1U << 18) > > > > > /* > > > > > * io_uring_register(2) opcodes and arguments > > > > > diff --git a/io_uring/bpf.c b/io_uring/bpf.c > > > > > index bb1e37d1e804..8227be6d5a10 100644 > > > > > --- a/io_uring/bpf.c > > > > > +++ b/io_uring/bpf.c > > > > > @@ -4,28 +4,95 @@ > > > > > #include > > > > > #include > > > > > #include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > #include "io_uring.h" > > > > > #include "uring_bpf.h" > > > > > +#define MAX_BPF_OPS_COUNT (1 << IORING_BPF_OP_BITS) > > > > > + > > > > > static DEFINE_MUTEX(uring_bpf_ctx_lock); > > > > > static LIST_HEAD(uring_bpf_ctx_list); > > > > > +DEFINE_STATIC_SRCU(uring_bpf_srcu); > > > > > +static struct uring_bpf_ops bpf_ops[MAX_BPF_OPS_COUNT]; > > > > > > > > This indicates to me that the whole system with all applications in= all namespaces > > > > need to coordinate in order to use these 256 ops? > > > > > > So far there is only 62 in-tree io_uring operation defined, I feel 25= 6 > > > should be enough. > > > > > > > I think in order to have something useful, this should be per > > > > struct io_ring_ctx and each application should be able to load > > > > its own bpf programs. > > > > > > per-ctx requirement looks reasonable, and it shouldn't be hard to > > > support. > > > > > > > > > > > Something that uses bpf_prog_get_type() based on a bpf_fd > > > > like SIOCKCMATTACH in net/kcm/kcmsock.c. > > > > > > I considered per-ctx prog before, one drawback is the prog can't be s= hared > > > among io_ring_ctx, which could waste memory. In my ublk case, there c= an be > > > lots of devices sharing same bpf prog. > > > > Can't the ublk instances coordinate and use the same bpf_fd? > > new instances could request it via a unix socket and SCM_RIGHTS > > from a long running loading process. On the other hand do they > > really want to share? > > struct_ops is typically registered once, used everywhere, such as > sched_ext and socket example. > > This patch follows this usage, so every io_uring application can access i= t like the > in-kernel operations. > > I can understand the requirement for per-io-ring-ctx struct_ops, which > won't cause conflict among different applications. > > For example, ublk/raid5, there are 100 such devices, each device is creat= ed in dedicated > process and uses its own io-uring, so 100 same struct_ops prog are regist= ered in memory. > Given struct_ops prog is registered as per-io-ring-ctx, it may not be sha= red by `bpf_fd`, IMO. I agree with Stefan that a global IORING_OP_BPF op to BPF program mapping will be difficult to coordinate between processes. For example, consider two different ublk server programs that each want to use a different BPF program. Ideally, each should be an independent program and not need to know the op ids used by the other. On the other hand, a multithreaded process may have multiple io_ring_ctxs and want to use the same IORING_OP_BPF ops with all of them. So a process-level mapping seems to make the most sense. And that's exactly the mapping level that we would get from using the BPF program file descriptor to specify the IORING_OP_BPF op. Additionally, as Stefan points out, the IORING_OP_BPF program could be shared with another process by sending the file descriptor using SCM_RIGHTS. And the file descriptor lookup overhead could be avoided in the I/O path using io_uring's existing support for registered files. Best, Caleb > > > > > I don't know much about bpf in details, so I'm wondering in your > > example from > > https://github.com/ming1/liburing/commit/625b69ddde15ad80e078c684ba166f= 49c1174fa4 > > > > Would memory_map be global in the whole system or would > > each loaded instance of the program have it's own instance of memory_ma= p? > > bpf map is global. > > At default, each loaded prog owns the map, but it may be exported for > others by pinning the map. > > It is easy to verify by writing test code in tools/testing/selftests/ > > But I am not an bpf expert... > > Thanks, > Ming > From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id AINWMKRbN2no+hcAYBR5ng (envelope-from ) for ; Mon, 08 Dec 2025 23:13:40 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Mon, 08 Dec 2025 23:13:40 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSkQF-00000006v28-3Rpx for hi@josie.lol; Mon, 08 Dec 2025 23:13:40 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id 2F1AB30092B4 for ; Mon, 8 Dec 2025 23:13:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 95CCE217F31; Mon, 8 Dec 2025 23:13:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="dZ5DMln0" X-Original-To: stable@vger.kernel.org Received: from mail-pf1-f170.google.com (mail-pf1-f170.google.com [209.85.210.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AEE7B2D5A14 for ; Mon, 8 Dec 2025 23:13:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765235614; cv=none; b=Rt3c81KUovIWjqgdRJ+AzGMHVj/qHqUl330DGsC67vAe2R09QZ1ZWojGoNB9PwUBi7yqivGBHdhZR83mUoVrgI8Y921y6LTH/SPghOKCREPq9l6EUDEaqvQwiz8KzNHHtdaTJSOQfGtwTnTSmZveaTWsrhIQcGAAwM1Vdvf9dpc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765235614; c=relaxed/simple; bh=sCuYg/i8Zn5qmYz6s1tkarVebpCmEojScJUUpBsYWWk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=qZyyyh/dv6A+oEQTBAptXWkRi6Yi19kkFRzldoZbDxV5QW7VDrLunvTy/37sS4d0iiP4HvCTucSuoJW6rZ3gd/mx3yxEVq+ror/anzh0DbGnvla35BIjHNnrSuNXJQx1VH+C+zS8q6tZL8k/gu410+SOQx0ZVTjWtdc4oM5I8JI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=dZ5DMln0; arc=none smtp.client-ip=209.85.210.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-f170.google.com with SMTP id d2e1a72fcca58-7b7828bf7bcso5739108b3a.2 for ; Mon, 08 Dec 2025 15:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765235612; x=1765840412; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=7cNkudiHBLvbO1BAbAlJ5UuS7KUF5P5v2oxjto4jk7E=; b=dZ5DMln0FLpqA0c99xH6JqFgXByVitX269oJzubAls1hWjf1Mx1Rn5NTIJ4Sj9YY5l 8eNYR9lVNBTiGxrS0KKkQPqMBi0ZRqQudAWtVzZt8P8TKrL1ymBXe3XqnhWRbPy5Y3Ad abg8OUnzDogRIj+tFDOGtUAYsCGM2FIiJ+4yzSbS4/aMiPuJuAiS4kkUUsZ2i10eZ5Dn TOW83pjIJbvtyRCDvg7hYcTnmD/QGHncUq9GlkrZkSkpXokKWTwZB+wV48Y2Zf0hMwv1 eJ1DWTxEK+kHUBmezvF2NHb7BOJpmyLDxLF8PiS5xUUhiG3j6zAV7NSX0qniIqv+d+p2 x8hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765235612; x=1765840412; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=7cNkudiHBLvbO1BAbAlJ5UuS7KUF5P5v2oxjto4jk7E=; b=BFOkIwQcsdblTIkNO9JUBxVbE9Td2S4Akmi0DVPrqPPsldDY3iJCJd3u4hvfQiYK1C ATxn/aLxs7IU4VmJ89t/Z3jIo4pGsXonxnwLyq3R5qw4LKXxCGT4Shbb9MrLE21wsEi2 N1cp2UskVSb4RI6XtAFWY0tHzrOP7ZJChroxzqE1r9zcgEGAGBPqJZGlrG/2TaWnj7eG HAX9AaJY43SbZcpqVCqioDsLVGlVeMxWYdxHFXFBkPx39dgBTPGFAIAR9ScaHc3zVBBs ZfKnwJNZXYXws80vrPhf687pkVeMZX5qVnPQmSBaIbNxtMBrsto8gLyvokATtq70XCVJ nWVA== X-Forwarded-Encrypted: i=1; AJvYcCVsSX07zfIxbnT7MO79CIc4R8noaYsHDJe7MBVPwWfHyghi6FiiiSBhGwnv9qquNVM1tzupUcA=@vger.kernel.org X-Gm-Message-State: AOJu0Yx7inCoAbIhU6owUlWn6JFuCuHblqeBs/E5dgce99x25amEnUtR 7oD4GLwFOZj/+kvMOdGhRf9fnlkuQd9L1F5wHL7yZZIcF22QZ++vCvZC X-Gm-Gg: ASbGncu9PgADXPSQNkGjmITuHWuizVFyLFUmwIbKih+ShLMS1H6WyLVhlMYt/8HITzj brNocs9TqQfu/FbFPmAhd1r1/2zuKw8LYm+ubhlGnlFrbYNR+OGcms9txCdHCNWICzCXxFZNfiy qCLKR3YiHFPrqZdwEy8h7ho4YCKC4oFyFNCGlEgN7e7bPfwgiQkyf/rjK0ci8hcuRmTilP+0sl7 2TqoVBAFWiyp0EXCQFBxuCXfc5thhzAuyh0rKk99Y9pSmZYkQVovz70EKPJ0rikUISwD/vcQR3w 8D66WY/UD2Ut7UbU+JgqvmqSozO/NOiHHREBoB2XvyVbQikcLrzPLT8ZLeldR5abtGSPEz5mJCX JbpEmHTvt08hKND7WTv8zF+pVQIRyIXSUCOvF9/EWZvTLuW4mc8XDBwNfYWdE4wn1nS5uEz5HYl Rn28nNZQaNjh4= X-Google-Smtp-Source: AGHT+IENI8piQgxp7BPJwYHC2wEim4PgmyRYNo8uvtRwTtLeTNSPYOAZs1mD+ZS6wM1lTT6oQ+n41Q== X-Received: by 2002:a05:6a20:7f81:b0:334:912f:acea with SMTP id adf61e73a8af0-366180175c0mr8791792637.59.1765235611666; Mon, 08 Dec 2025 15:13:31 -0800 (PST) Received: from archie.me ([210.87.74.117]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-bf6817397d0sm13136853a12.6.2025.12.08.15.13.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Dec 2025 15:13:31 -0800 (PST) Received: by archie.me (Postfix, from userid 1000) id 24242421DA23; Tue, 09 Dec 2025 06:13:28 +0700 (WIB) From: Bagas Sanjaya To: Linux Kernel Mailing List , Linux Documentation , Linux Kernel Tracing Cc: Steven Rostedt , Jonathan Corbet , Crystal Wood , Tomas Glozar , Greg Kroah-Hartman , Sasha Levin , Bagas Sanjaya , stable@vger.kernel.org, Gopi Krishna Menon , Randy Dunlap Subject: [PATCH 6.18.y] Documentation/rtla: rename common_xxx.rst files to common_xxx.txt Date: Tue, 9 Dec 2025 06:13:00 +0700 Message-ID: <20251208231300.9386-2-bagasdotme@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=13847; i=bagasdotme@gmail.com; h=from:subject; bh=4yDdjpvK5UYgmsBWh3Cf2nkLEypdnAasaE0SdB09688=; b=owGbwMvMwCX2bWenZ2ig32LG02pJDJnmUbOOc/556++80l3r8p+v1V8TJjjXxVxZW2dSazTJV WuNhMvzjlIWBjEuBlkxRZZJiXxNp3cZiVxoX+sIM4eVCWQIAxenAEwkUJ/hr/yTjQ9l2lYuU564 vXSt3o2tdbMn+53KSUkJ5djj+fPgvRiG/66HrewvnPjCd6W9WOjNxvSQ/3uj/u9M1+Vfbzvl9YR jb1kA X-Developer-Key: i=bagasdotme@gmail.com; a=openpgp; fpr=701B806FDCA5D3A58FFB8F7D7C276C64A5E44A1D Content-Transfer-Encoding: 8bit X-DKIM: signer='gmail.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: sphinx-doc.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [104.64.211.4 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [bagasdotme[at]gmail.com] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 From: Gopi Krishna Menon commit 96b546c241b11a97ba1247580208c554458e7866 upstream. Sphinx reports htmldocs errors: Documentation/tools/rtla/common_options.rst:58: ERROR: Undefined substitution referenced: "threshold". Documentation/tools/rtla/common_options.rst:88: ERROR: Undefined substitution referenced: "tool". Documentation/tools/rtla/common_options.rst:88: ERROR: Undefined substitution referenced: "thresharg". Documentation/tools/rtla/common_options.rst:88: ERROR: Undefined substitution referenced: "tracer". Documentation/tools/rtla/common_options.rst:92: ERROR: Undefined substitution referenced: "tracer". Documentation/tools/rtla/common_options.rst:98: ERROR: Undefined substitution referenced: "actionsperf". Documentation/tools/rtla/common_options.rst:113: ERROR: Undefined substitution referenced: "tool". common_*.rst files are snippets that are intended to be included by rtla docs (rtla*.rst). common_options.rst in particular contains substitutions which depend on other common_* includes, so building it independently as reST source results in above errors. Rename all common_*.rst files to common_*.txt to prevent Sphinx from building these snippets as standalone reST source and update all include references accordingly. Cc: stable@vger.kernel.org Link: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#substitutions Suggested-by: Tomas Glozar Suggested-by: Bagas Sanjaya Signed-off-by: Gopi Krishna Menon Reviewed-by: Tomas Glozar Fixes: 05b7e10687c6 ("tools/rtla: Add remaining support for osnoise actions") Reviewed-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20251008184522.13201-1-krishnagopi487@gmail.com [Bagas: massage commit message and apply trailers] Signed-off-by: Bagas Sanjaya Reviewed-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20251013092719.30780-2-bagasdotme@gmail.com> Signed-off-by: Bagas Sanjaya --- Note: The warnings were present in 6.18 cycle but unfortunately the original 96b546c241b11a97ba1247580208c554458e7866 got instead queued up for 6.19 merge window. .../{common_appendix.rst => common_appendix.txt} | 0 ...mmon_hist_options.rst => common_hist_options.txt} | 0 .../rtla/{common_options.rst => common_options.txt} | 0 ...escription.rst => common_osnoise_description.txt} | 0 ...snoise_options.rst => common_osnoise_options.txt} | 0 ...common_timerlat_aa.rst => common_timerlat_aa.txt} | 0 ...scription.rst => common_timerlat_description.txt} | 0 ...erlat_options.rst => common_timerlat_options.txt} | 0 ...common_top_options.rst => common_top_options.txt} | 0 Documentation/tools/rtla/rtla-hwnoise.rst | 8 ++++---- Documentation/tools/rtla/rtla-osnoise-hist.rst | 10 +++++----- Documentation/tools/rtla/rtla-osnoise-top.rst | 10 +++++----- Documentation/tools/rtla/rtla-osnoise.rst | 4 ++-- Documentation/tools/rtla/rtla-timerlat-hist.rst | 12 ++++++------ Documentation/tools/rtla/rtla-timerlat-top.rst | 12 ++++++------ Documentation/tools/rtla/rtla-timerlat.rst | 4 ++-- Documentation/tools/rtla/rtla.rst | 2 +- 17 files changed, 31 insertions(+), 31 deletions(-) rename Documentation/tools/rtla/{common_appendix.rst => common_appendix.txt} (100%) rename Documentation/tools/rtla/{common_hist_options.rst => common_hist_options.txt} (100%) rename Documentation/tools/rtla/{common_options.rst => common_options.txt} (100%) rename Documentation/tools/rtla/{common_osnoise_description.rst => common_osnoise_description.txt} (100%) rename Documentation/tools/rtla/{common_osnoise_options.rst => common_osnoise_options.txt} (100%) rename Documentation/tools/rtla/{common_timerlat_aa.rst => common_timerlat_aa.txt} (100%) rename Documentation/tools/rtla/{common_timerlat_description.rst => common_timerlat_description.txt} (100%) rename Documentation/tools/rtla/{common_timerlat_options.rst => common_timerlat_options.txt} (100%) rename Documentation/tools/rtla/{common_top_options.rst => common_top_options.txt} (100%) diff --git a/Documentation/tools/rtla/common_appendix.rst b/Documentation/tools/rtla/common_appendix.txt similarity index 100% rename from Documentation/tools/rtla/common_appendix.rst rename to Documentation/tools/rtla/common_appendix.txt diff --git a/Documentation/tools/rtla/common_hist_options.rst b/Documentation/tools/rtla/common_hist_options.txt similarity index 100% rename from Documentation/tools/rtla/common_hist_options.rst rename to Documentation/tools/rtla/common_hist_options.txt diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.txt similarity index 100% rename from Documentation/tools/rtla/common_options.rst rename to Documentation/tools/rtla/common_options.txt diff --git a/Documentation/tools/rtla/common_osnoise_description.rst b/Documentation/tools/rtla/common_osnoise_description.txt similarity index 100% rename from Documentation/tools/rtla/common_osnoise_description.rst rename to Documentation/tools/rtla/common_osnoise_description.txt diff --git a/Documentation/tools/rtla/common_osnoise_options.rst b/Documentation/tools/rtla/common_osnoise_options.txt similarity index 100% rename from Documentation/tools/rtla/common_osnoise_options.rst rename to Documentation/tools/rtla/common_osnoise_options.txt diff --git a/Documentation/tools/rtla/common_timerlat_aa.rst b/Documentation/tools/rtla/common_timerlat_aa.txt similarity index 100% rename from Documentation/tools/rtla/common_timerlat_aa.rst rename to Documentation/tools/rtla/common_timerlat_aa.txt diff --git a/Documentation/tools/rtla/common_timerlat_description.rst b/Documentation/tools/rtla/common_timerlat_description.txt similarity index 100% rename from Documentation/tools/rtla/common_timerlat_description.rst rename to Documentation/tools/rtla/common_timerlat_description.txt diff --git a/Documentation/tools/rtla/common_timerlat_options.rst b/Documentation/tools/rtla/common_timerlat_options.txt similarity index 100% rename from Documentation/tools/rtla/common_timerlat_options.rst rename to Documentation/tools/rtla/common_timerlat_options.txt diff --git a/Documentation/tools/rtla/common_top_options.rst b/Documentation/tools/rtla/common_top_options.txt similarity index 100% rename from Documentation/tools/rtla/common_top_options.rst rename to Documentation/tools/rtla/common_top_options.txt diff --git a/Documentation/tools/rtla/rtla-hwnoise.rst b/Documentation/tools/rtla/rtla-hwnoise.rst index 3a7163c02ac8e8..26512b15fe7ba5 100644 --- a/Documentation/tools/rtla/rtla-hwnoise.rst +++ b/Documentation/tools/rtla/rtla-hwnoise.rst @@ -29,11 +29,11 @@ collection of the tracer output. OPTIONS ======= -.. include:: common_osnoise_options.rst +.. include:: common_osnoise_options.txt -.. include:: common_top_options.rst +.. include:: common_top_options.txt -.. include:: common_options.rst +.. include:: common_options.txt EXAMPLE ======= @@ -106,4 +106,4 @@ AUTHOR ====== Written by Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt diff --git a/Documentation/tools/rtla/rtla-osnoise-hist.rst b/Documentation/tools/rtla/rtla-osnoise-hist.rst index 1fc60ef2610677..007521c865d97e 100644 --- a/Documentation/tools/rtla/rtla-osnoise-hist.rst +++ b/Documentation/tools/rtla/rtla-osnoise-hist.rst @@ -15,7 +15,7 @@ SYNOPSIS DESCRIPTION =========== -.. include:: common_osnoise_description.rst +.. include:: common_osnoise_description.txt The **rtla osnoise hist** tool collects all **osnoise:sample_threshold** occurrence in a histogram, displaying the results in a user-friendly way. @@ -24,11 +24,11 @@ collection of the tracer output. OPTIONS ======= -.. include:: common_osnoise_options.rst +.. include:: common_osnoise_options.txt -.. include:: common_hist_options.rst +.. include:: common_hist_options.txt -.. include:: common_options.rst +.. include:: common_options.txt EXAMPLE ======= @@ -65,4 +65,4 @@ AUTHOR ====== Written by Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt diff --git a/Documentation/tools/rtla/rtla-osnoise-top.rst b/Documentation/tools/rtla/rtla-osnoise-top.rst index b1cbd7bcd4aed2..6ccadae3894570 100644 --- a/Documentation/tools/rtla/rtla-osnoise-top.rst +++ b/Documentation/tools/rtla/rtla-osnoise-top.rst @@ -15,7 +15,7 @@ SYNOPSIS DESCRIPTION =========== -.. include:: common_osnoise_description.rst +.. include:: common_osnoise_description.txt **rtla osnoise top** collects the periodic summary from the *osnoise* tracer, including the counters of the occurrence of the interference source, @@ -26,11 +26,11 @@ collection of the tracer output. OPTIONS ======= -.. include:: common_osnoise_options.rst +.. include:: common_osnoise_options.txt -.. include:: common_top_options.rst +.. include:: common_top_options.txt -.. include:: common_options.rst +.. include:: common_options.txt EXAMPLE ======= @@ -60,4 +60,4 @@ AUTHOR ====== Written by Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt diff --git a/Documentation/tools/rtla/rtla-osnoise.rst b/Documentation/tools/rtla/rtla-osnoise.rst index c129b206ce3484..540d2bf6c15247 100644 --- a/Documentation/tools/rtla/rtla-osnoise.rst +++ b/Documentation/tools/rtla/rtla-osnoise.rst @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION =========== -.. include:: common_osnoise_description.rst +.. include:: common_osnoise_description.txt The *osnoise* tracer outputs information in two ways. It periodically prints a summary of the noise of the operating system, including the counters of @@ -56,4 +56,4 @@ AUTHOR ====== Written by Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt diff --git a/Documentation/tools/rtla/rtla-timerlat-hist.rst b/Documentation/tools/rtla/rtla-timerlat-hist.rst index 4923a362129bbd..f56fe546411bd4 100644 --- a/Documentation/tools/rtla/rtla-timerlat-hist.rst +++ b/Documentation/tools/rtla/rtla-timerlat-hist.rst @@ -16,7 +16,7 @@ SYNOPSIS DESCRIPTION =========== -.. include:: common_timerlat_description.rst +.. include:: common_timerlat_description.txt The **rtla timerlat hist** displays a histogram of each tracer event occurrence. This tool uses the periodic information, and the @@ -25,13 +25,13 @@ occurrence. This tool uses the periodic information, and the OPTIONS ======= -.. include:: common_timerlat_options.rst +.. include:: common_timerlat_options.txt -.. include:: common_hist_options.rst +.. include:: common_hist_options.txt -.. include:: common_options.rst +.. include:: common_options.txt -.. include:: common_timerlat_aa.rst +.. include:: common_timerlat_aa.txt EXAMPLE ======= @@ -110,4 +110,4 @@ AUTHOR ====== Written by Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst index 50968cdd2095a1..7dbe625d0c4243 100644 --- a/Documentation/tools/rtla/rtla-timerlat-top.rst +++ b/Documentation/tools/rtla/rtla-timerlat-top.rst @@ -16,7 +16,7 @@ SYNOPSIS DESCRIPTION =========== -.. include:: common_timerlat_description.rst +.. include:: common_timerlat_description.txt The **rtla timerlat top** displays a summary of the periodic output from the *timerlat* tracer. It also provides information for each @@ -26,13 +26,13 @@ seem with the option **-T**. OPTIONS ======= -.. include:: common_timerlat_options.rst +.. include:: common_timerlat_options.txt -.. include:: common_top_options.rst +.. include:: common_top_options.txt -.. include:: common_options.rst +.. include:: common_options.txt -.. include:: common_timerlat_aa.rst +.. include:: common_timerlat_aa.txt **--aa-only** *us* @@ -133,4 +133,4 @@ AUTHOR ------ Written by Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt diff --git a/Documentation/tools/rtla/rtla-timerlat.rst b/Documentation/tools/rtla/rtla-timerlat.rst index 20e2d259467fd0..ce9f57e038c37f 100644 --- a/Documentation/tools/rtla/rtla-timerlat.rst +++ b/Documentation/tools/rtla/rtla-timerlat.rst @@ -14,7 +14,7 @@ SYNOPSIS DESCRIPTION =========== -.. include:: common_timerlat_description.rst +.. include:: common_timerlat_description.txt The **rtla timerlat top** mode displays a summary of the periodic output from the *timerlat* tracer. The **rtla timerlat hist** mode displays @@ -51,4 +51,4 @@ AUTHOR ====== Written by Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt diff --git a/Documentation/tools/rtla/rtla.rst b/Documentation/tools/rtla/rtla.rst index fc0d233efcd5df..2a5fb7004ad448 100644 --- a/Documentation/tools/rtla/rtla.rst +++ b/Documentation/tools/rtla/rtla.rst @@ -45,4 +45,4 @@ AUTHOR ====== Daniel Bristot de Oliveira -.. include:: common_appendix.rst +.. include:: common_appendix.txt base-commit: a66aab4b0ed2ca786d5512e843f32d96942ff311 -- An old man doll... just what I always wanted! - Clara From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id GNJkGj9qN2miFB8AYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 00:15:59 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 00:15:59 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSlOZ-00000008uDc-0wXP for hi@josie.lol; Tue, 09 Dec 2025 00:15:59 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 27474301C672 for ; Tue, 9 Dec 2025 00:15:58 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F3AF31FF5E3; Tue, 9 Dec 2025 00:15:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MrpJLfsB" X-Original-To: io-uring@vger.kernel.org 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 CD64D1FE46D for ; Tue, 9 Dec 2025 00:15:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239356; cv=none; b=UCHDF+tNtdpL4lBw7rEl+vJpof5w3jGxBAz3dYqRLDvgSITcP472J4wuY7W18z2pK9C6R6pl/495gRLh1blNgNw3/Q8SMIBJDqbnO7WEKyFA7BObod3geutvQWi24GvNJRC7mNIdcnhF+3RVAjjAqZjRKMzG46yAWnnRfUgKX2E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239356; c=relaxed/simple; bh=MdJpGJNlipvkZoTc0Lc0qgxWfZ82022k+60eoBOiMcw=; h=Subject:From:In-Reply-To:References:Message-Id:Date:To:Cc; b=JTPpqj3X8z5qzAIICYJVXSTKZvaJ8nKc8pVjQhTnL0kv8J6F8sFQvW5W3oD+IzDhGYM/BduXi3wQt0z6e3ALjXf0SbF6TeRMpEoSyqrx6qdu8uHA/yG4oBY7HbHLHreKNi4P/I4c2XFzrmGld2OR3htVmG55/Dxzo1599ec1K+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MrpJLfsB; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD2DBC113D0; Tue, 9 Dec 2025 00:15:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765239356; bh=MdJpGJNlipvkZoTc0Lc0qgxWfZ82022k+60eoBOiMcw=; h=Subject:From:In-Reply-To:References:Date:To:Cc:From; b=MrpJLfsB22naBUikzr7wt8T/gZg9kU3MGw0bjR+6rXM2T9AdRUBOIBy753aBBGvzd ciac4K3/s8ETMcxKXj2r1K11eWabR7iMNS1h1X5B2+Sq2jJlcHJlxrQDr6vASCkKJW 9eKBte7qJG8FDb+uJujtP3AcefXH5qwd+1X21Xu2xDOJxyUb7UkwP1ZRlvhAYF16MM nZjFPzVF46wzW6rqQOar1YpzepmzfQGlBZaZepfnAmC90GUtNMXGT5AiOPdmHfcHxR 3QCY0vCx2rLnPfDAqOezh126leg6AHM0j5HtajyOr29+QnHLLIKSDkNWS9sgv5Ql5s j42ED6KluYUEg== Received: from [10.30.226.235] (localhost [IPv6:::1]) by aws-us-west-2-korg-oddjob-rhel9-1.codeaurora.org (Postfix) with ESMTP id 788923808200; Tue, 9 Dec 2025 00:12:53 +0000 (UTC) Subject: Re: [GIT PULL] Followup io_uring fixes for 6.19-rc1 From: pr-tracker-bot@kernel.org In-Reply-To: References: X-PR-Tracked-List-Id: X-PR-Tracked-Message-Id: X-PR-Tracked-Remote: https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git tags/io_uring-6.19-20251208 X-PR-Tracked-Commit-Id: 55d57b3bcc7efcab812a8179e2dc17d781302997 X-PR-Merge-Tree: torvalds/linux.git X-PR-Merge-Refname: refs/heads/master X-PR-Merge-Commit-Id: cfd4039213e7b5a828c5b78e1b5235cac91af53d Message-Id: <176523917201.3343091.17072612878039707484.pr-tracker-bot@kernel.org> Date: Tue, 09 Dec 2025 00:12:52 +0000 To: Jens Axboe Cc: Linus Torvalds , io-uring Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 The pull request you sent on Mon, 8 Dec 2025 13:31:06 -0700: > https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git tags/io_uring-6.19-20251208 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/cfd4039213e7b5a828c5b78e1b5235cac91af53d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id +MLqNmhqN2luax8AYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 00:16:40 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 00:16:41 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSlPE-00000008vPy-2EQO for hi@josie.lol; Tue, 09 Dec 2025 00:16:40 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 5B4303018EC5 for ; Tue, 9 Dec 2025 00:16:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D0E6E221290; Tue, 9 Dec 2025 00:16:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WUj2ROSN" X-Original-To: stable@vger.kernel.org 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 A00101A9B46; Tue, 9 Dec 2025 00:16:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239398; cv=none; b=ErI5MXTRn6+FVjnmc8big2KB8f1prDXRzzr0ZukkRZZ6o6LGyvomtuipHoGYBkGUzmylpLd0ikIaSL+BFYAfsMTmxBD3+5A+aCYvS/sWXYPZhomF4jCCVImNBEEaooIJ4ShhhXg5hUVr7QKTIar8+qX33PR6gwLb8XQ0YmI1CiU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239398; c=relaxed/simple; bh=wiRysEFUkuhH+VlDpC3sA3h+zQjzRcu4gDivr+e3HQs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iSuHo8oI7iT/iPOYmt15ydDV3HyWiGMAWx9WURJMnHBJfRUHTrY4lTypBIbW0jJ1PGKpSymd71iWgm+9dYEvFAOM2ouYyX3yMIPikz4bu7u7qoS0znLjAM8K+9+Qah5dBv1HVVjfI92QlU0/IgPZQk1XrUcZ2USDO1hokbyVcCg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WUj2ROSN; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3ED6C4CEF1; Tue, 9 Dec 2025 00:16:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765239398; bh=wiRysEFUkuhH+VlDpC3sA3h+zQjzRcu4gDivr+e3HQs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WUj2ROSNIFLuS5zziufvGbzRJ33rQ6Ko5lMvZWb4H9vZdGbDAhKBIn82hq7CLjVuL tAEUruA69S3eqq2lUhzJfw+6Fo1i5IlQ4INz7nIZIaNiiwJUjw41ABhHbE9GxZgQut hfv0+8ZiHu7tH2lmVQEEEnPXBaMtJKrHtIQBs9kN6HyLYaeR+OLjWSYYaDqcF9Qn1G 455nMlwAzqanpWBD1VX3+5WnZs7g9SVIOW/OKiArSxibDt8nvVDvQ0kRYj7Kt/wYrk atjfRtl719Yi2yddGcX2ccAL+5nZN/aHarzyeIkuVnVhSufmzHx4ZKX8N9BDfPKa1q lI1YfZs0PfNLg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Jakub Kicinski , David Ahern , Ido Schimmel , Sasha Levin , davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.6] ipv6: clean up routes when manually removing address with a lifetime Date: Mon, 8 Dec 2025 19:14:55 -0500 Message-ID: <20251209001610.611575-3-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251209001610.611575-1-sashal@kernel.org> References: <20251209001610.611575-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: rtnetlink.sh] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Jakub Kicinski [ Upstream commit c7dc5b5228822d2389e6e441f10169e460bcc67a ] When an IPv6 address with a finite lifetime (configured with valid_lft and preferred_lft) is manually deleted, the kernel does not clean up the associated prefix route. This results in orphaned routes (marked "proto kernel") remaining in the routing table even after their corresponding address has been deleted. This is particularly problematic on networks using combination of SLAAC and bridges. 1. Machine comes up and performs RA on eth0. 2. User creates a bridge - does an ip -6 addr flush dev eth0; - adds the eth0 under the bridge. 3. SLAAC happens on br0. Even tho the address has "moved" to br0 there will still be a route pointing to eth0, but eth0 is not usable for IP any more. Reviewed-by: David Ahern Reviewed-by: Ido Schimmel Link: https://patch.msgid.link/20251113031700.3736285-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: # Analysis of Commit: ipv6: clean up routes when manually removing address with a lifetime ## 1. COMMIT MESSAGE ANALYSIS **Subject:** Fixes route cleanup when IPv6 addresses with finite lifetimes are deleted manually **Key Problem Described:** - When an IPv6 address configured with `valid_lft` and `preferred_lft` is manually deleted, the kernel fails to clean up the associated prefix route - Results in orphaned routes (marked "proto kernel") remaining in the routing table - Particularly problematic with SLAAC + bridges (a real-world scenario) **Tags:** - `Reviewed-by: David Ahern` (network subsystem maintainer) - `Reviewed-by: Ido Schimmel` (networking contributor) - `Signed-off-by: Jakub Kicinski` (Linux networking maintainer) **Notable Missing Tags:** - No `Cc: stable@vger.kernel.org` - No `Fixes:` tag ## 2. CODE CHANGE ANALYSIS The core fix is extremely minimal - a single condition change in `net/ipv6/addrconf.c`: **Before:** ```c if (ifp->flags & IFA_F_PERMANENT && !(ifp->flags & IFA_F_NOPREFIXROUTE)) ``` **After:** ```c if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) ``` **Technical Mechanism:** - `IFA_F_PERMANENT` flag is set for addresses WITHOUT a finite lifetime - Addresses with `valid_lft`/`preferred_lft` set do NOT have `IFA_F_PERMANENT` - The old code only cleaned up prefix routes for permanent (infinite lifetime) addresses - Non-permanent addresses (those with lifetimes) would have their routes orphaned on manual deletion - The fix removes the overly-restrictive `IFA_F_PERMANENT` check, ensuring route cleanup for ALL addresses that don't have `IFA_F_NOPREFIXROUTE` **Root Cause:** Logic error - the condition was too restrictive, failing to clean up routes for addresses with finite lifetimes. ## 3. CLASSIFICATION - **Bug Fix:** Yes - fixes route leakage/orphaning - **New Feature:** No - corrects existing cleanup behavior - **Security:** No explicit security issue, but orphaned routes can cause routing problems ## 4. SCOPE AND RISK ASSESSMENT **Lines Changed:** - Core fix: 1 line modified (condition simplification) - Test: ~20 lines added to selftest **Risk Level: LOW** - The `check_cleanup_prefix_route()` and `cleanup_prefix_route()` functions already exist and are tested - The fix EXTENDS existing cleanup to more cases (non-permanent addresses) - No new code paths introduced, just removes an unnecessary condition - Well-reviewed by multiple networking maintainers ## 5. USER IMPACT **Affected Users:** - Anyone using IPv6 with finite address lifetimes (SLAAC, DHCPv6) - Users managing bridges with IPv6 addresses - Enterprise/data center environments with complex networking **Severity:** Medium - Orphaned routes can cause routing confusion and network connectivity issues - The SLAAC + bridge scenario is common in real-world deployments - Routes pointing to unusable interfaces cause operational problems ## 6. STABILITY INDICATORS **Positive:** - Three experienced networking maintainers involved (Kicinski, Ahern, Schimmel) - Includes selftest (`kci_test_addrlft_route_cleanup`) for regression testing - Simple, surgical change with clear intent ## 7. DEPENDENCY CHECK - Self-contained fix with no dependencies on other commits - The affected functions (`check_cleanup_prefix_route`, etc.) have existed for a long time - Should apply cleanly to recent stable kernels ## ASSESSMENT SUMMARY **Pros:** 1. Fixes a real, user-visible bug (orphaned routes) 2. Extremely minimal change (removes one condition) 3. Strong review from key networking maintainers 4. Low regression risk - extends existing behavior to more cases 5. Includes regression test 6. Addresses a practical scenario (SLAAC + bridges) **Cons/Considerations:** 1. No explicit `Cc: stable@vger.kernel.org` tag - maintainers didn't request backport 2. No `Fixes:` tag - unknown when bug was introduced (likely long- standing) 3. The bug has workarounds (routes eventually expire, or can be manually deleted) ## VERDICT This commit is a good candidate for stable backporting. It is: - **Obviously correct:** The `IFA_F_PERMANENT` check makes no logical sense for route cleanup - **Fixes a real bug:** Orphaned routes are a tangible problem affecting real users - **Small and contained:** Single condition change in one file - **Low risk:** Extends existing cleanup mechanism to more cases - **Well-tested:** Reviewed by maintainers and includes regression test The lack of stable tags is notable but not disqualifying. The fix is clearly beneficial and the risk is minimal. Stable tree users dealing with IPv6 address lifetimes and bridges would benefit from this fix. **YES** net/ipv6/addrconf.c | 2 +- tools/testing/selftests/net/rtnetlink.sh | 20 ++++++++++++++++++++ 2 files changed, 21 insertions(+), 1 deletion(-) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 40e9c336f6c55..b66217d1b2f82 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -1324,7 +1324,7 @@ static void ipv6_del_addr(struct inet6_ifaddr *ifp) __in6_ifa_put(ifp); } - if (ifp->flags & IFA_F_PERMANENT && !(ifp->flags & IFA_F_NOPREFIXROUTE)) + if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) action = check_cleanup_prefix_route(ifp, &expires); list_del_rcu(&ifp->if_list); diff --git a/tools/testing/selftests/net/rtnetlink.sh b/tools/testing/selftests/net/rtnetlink.sh index 163a084d525d5..248c2b91fe42b 100755 --- a/tools/testing/selftests/net/rtnetlink.sh +++ b/tools/testing/selftests/net/rtnetlink.sh @@ -8,6 +8,7 @@ ALL_TESTS=" kci_test_polrouting kci_test_route_get kci_test_addrlft + kci_test_addrlft_route_cleanup kci_test_promote_secondaries kci_test_tc kci_test_gre @@ -323,6 +324,25 @@ kci_test_addrlft() end_test "PASS: preferred_lft addresses have expired" } +kci_test_addrlft_route_cleanup() +{ + local ret=0 + local test_addr="2001:db8:99::1/64" + local test_prefix="2001:db8:99::/64" + + run_cmd ip -6 addr add $test_addr dev "$devdummy" valid_lft 300 preferred_lft 300 + run_cmd_grep "$test_prefix proto kernel" ip -6 route show dev "$devdummy" + run_cmd ip -6 addr del $test_addr dev "$devdummy" + run_cmd_grep_fail "$test_prefix" ip -6 route show dev "$devdummy" + + if [ $ret -ne 0 ]; then + end_test "FAIL: route not cleaned up when address with valid_lft deleted" + return 1 + fi + + end_test "PASS: route cleaned up when address with valid_lft deleted" +} + kci_test_promote_secondaries() { run_cmd ifconfig "$devdummy" -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id CGhVDfRsN2mPFB8AYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 00:27:32 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 00:27:32 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSlZj-00000009FnE-35gR for hi@josie.lol; Tue, 09 Dec 2025 00:27:32 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 6E6BE30216A6 for ; Tue, 9 Dec 2025 00:27:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D908E2FE07F; Tue, 9 Dec 2025 00:18:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tFMsJS3X" X-Original-To: stable@vger.kernel.org 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 B00E22FE07B; Tue, 9 Dec 2025 00:18:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239502; cv=none; b=ZjykluCb68Ja4v289XrnPniLDsFkqRWFgyMLwK2Z/NlsEWrfIPngzdPYa+khOIUDkt/pcmgHv08VAoNztiaDAJatGbIlNh6xWNRHBg0NkyTTF8fYlREGh2MUKGrRhYHSDoEY4YFixVF5yttRVwtlIVA4SN2bhAv7l9NYm59r8C4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239502; c=relaxed/simple; bh=19TLGicltIHZdV3evklZ7BqhPkkNRx+ucqkSBoq51Mg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SyehOHzXqi2fYQC1Syp4QfRC+VMR6bRdRedofOz0q/wH4slf5yhUfrsc8FTgz1Hx8snLruIEX0hlJEXzpaXZpdMtPAjrYsQmuSbCP6IIRbKvYUe9SRge/uYQx3LCHk6xw8vs5srFh5zgP+Wbc9DC/rvfyd1S6nNrF1BZV+5NYr0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tFMsJS3X; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11162C4CEF1; Tue, 9 Dec 2025 00:18:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765239502; bh=19TLGicltIHZdV3evklZ7BqhPkkNRx+ucqkSBoq51Mg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tFMsJS3XoGR9rWM5NkulMmn6SxIHTyxgu5/JhFyfEJ8jxbmWAuIhnDAKFa9wE/k29 Hadck4UrIp1KYfEcm0fq+YQVwxWZgB53E8X4d7LLqZJeROvYDW1/Oh2hZxCtZH21Tq kf89qL6acwfI61bkTSEZAK8kYoKoxnFF0xJI6qOz5wMUVECI1iGPYrXD6DP9dlYTv+ dBRtLB0PgPoBW7uTbZZ30h4sQJx94wDKPCSzhd5RXeF0LUHJWBuZlB4zYfivMU+7f1 20kdDEp4++Br+wiQRqV2Y/MD1tsqErnrICZEQsbXYc+GtQXvndcLlET2PGA8IDin7I 3p1muxASQAVmA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Qianchang Zhao , Zhitong Liu , Namjae Jeon , Steve French , Sasha Levin , smfrench@gmail.com, linux-cifs@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.6] ksmbd: vfs: fix race on m_flags in vfs_cache Date: Mon, 8 Dec 2025 19:15:35 -0500 Message-ID: <20251209001610.611575-43-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251209001610.611575-1-sashal@kernel.org> References: <20251209001610.611575-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Qianchang Zhao [ Upstream commit 991f8a79db99b14c48d20d2052c82d65b9186cad ] ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all. Examples: - ksmbd_query_inode_status() and __ksmbd_inode_close() use ci->m_lock when checking or updating m_flags. - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close() used to read and modify m_flags without ci->m_lock. This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use). Fix it by: - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock after dropping inode_hash_lock. - Adding ci->m_lock protection to all helpers that read or modify m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(), ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()). - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(), and moving the actual unlink/xattr removal outside the lock. This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour. Reported-by: Qianchang Zhao Reported-by: Zhitong Liu Signed-off-by: Qianchang Zhao Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Analysis: ksmbd: vfs: fix race on m_flags in vfs_cache ### 1. Commit Message Analysis **Bug Description**: The commit fixes a data race on `m_flags` field in ksmbd's VFS cache. Multiple functions access/modify this field with inconsistent locking - some use `ci->m_lock`, others don't. **Keywords**: "race", "data race", "fix" - clear bug fix language **Impact described**: "Delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use)" **Tags present**: - Two `Reported-by:` tags (Qianchang Zhao, Zhitong Liu) - indicates real users hit this bug - `Acked-by:` from Namjae Jeon (ksmbd maintainer) - `Signed-off-by:` from Steve French (SMB maintainer) **Tags missing**: No `Cc: stable@vger.kernel.org`, no `Fixes:` tag ### 2. Code Change Analysis The fix is straightforward and mechanical - it adds proper locking around all `m_flags` accesses: | Function | Change | |----------|--------| | `ksmbd_query_inode_status()` | Moved m_flags check outside inode_hash_lock, added `down_read(&ci->m_lock)` | | `ksmbd_inode_pending_delete()` | Added read lock around flag check | | `ksmbd_set_inode_pending_delete()` | Added write lock around flag modification | | `ksmbd_clear_inode_pending_delete()` | Added write lock around flag modification | | `ksmbd_fd_set_delete_on_close()` | Added write lock around flag modification | | `__ksmbd_inode_close()` | Restructured to hold lock only during flag check/modify, moves I/O (unlink, xattr removal) outside the lock | The pattern is consistent: acquire lock → read/modify flags → release lock → perform any I/O operations outside lock. ### 3. Classification **Bug type**: Concurrency bug (data race) - NOT a feature addition - NOT adding new APIs - NOT a cleanup or optimization - This is a correctness fix for a real race condition ### 4. Scope and Risk Assessment **Scope**: - Single file changed: `fs/smb/server/vfs_cache.c` - ~60 lines of changes - All changes are adding locking around existing operations **Risk**: LOW - Uses existing `ci->m_lock` rwsem that's already in the structure - No new locking primitives introduced - The restructuring in `__ksmbd_inode_close()` to move I/O outside the lock is actually safer (avoids holding lock during I/O) - Pattern is well-understood: protect shared data with locks ### 5. User Impact **Who is affected**: Users running ksmbd (in-kernel SMB3 server) with concurrent file access/deletion **Severity**: MEDIUM-HIGH - File deletion semantics are broken (files may not be deleted when they should be, or disappear unexpectedly) - This affects data integrity expectations - Any ksmbd deployment with multiple concurrent clients could hit this ### 6. Stability Indicators - Maintainer acks from both ksmbd maintainer (Namjae Jeon) and SMB maintainer (Steve French) - Two independent reporters suggest this is a known/reproducible issue ### 7. Dependencies Check The fix is self-contained: - Uses existing `ci->m_lock` (already present in `ksmbd_inode` structure) - Uses standard kernel locking APIs (`down_read/up_read`, `down_write/up_write`) - No dependency on other patches ### 8. Stable Tree Applicability ksmbd was added in Linux 5.15, so this applies to 5.15.y, 6.1.y, 6.6.y, and later stable trees. The code structure appears stable enough that this should apply cleanly. --- ## Summary **Should this be backported?** **YES** - This commit should be backported because: 1. **Fixes a real bug**: Data race causing incorrect file deletion behavior that users can actually hit 2. **User-visible impact**: Files not deleted when they should be (delete-on-close failing) or files disappearing unexpectedly 3. **Has real bug reports**: Two Reported-by tags indicate real users encountered this 4. **Small and contained**: Single file, straightforward addition of missing locking 5. **Low regression risk**: Adds locking around existing operations using existing infrastructure 6. **Maintainer approved**: Acked by ksmbd maintainer, signed off by SMB maintainer 7. **Correct fix**: The approach (unify locking around m_flags) is obviously correct The lack of explicit `Cc: stable` tag is not disqualifying - the nature of the bug (concurrency issue with data integrity implications) and the quality of the fix (mechanical addition of proper locking) make this appropriate stable material. **YES** fs/smb/server/vfs_cache.c | 88 +++++++++++++++++++++++++++------------ 1 file changed, 62 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/vfs_cache.c b/fs/smb/server/vfs_cache.c index dfed6fce89049..6ef116585af64 100644 --- a/fs/smb/server/vfs_cache.c +++ b/fs/smb/server/vfs_cache.c @@ -112,40 +112,62 @@ int ksmbd_query_inode_status(struct dentry *dentry) read_lock(&inode_hash_lock); ci = __ksmbd_inode_lookup(dentry); - if (ci) { - ret = KSMBD_INODE_STATUS_OK; - if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)) - ret = KSMBD_INODE_STATUS_PENDING_DELETE; - atomic_dec(&ci->m_count); - } read_unlock(&inode_hash_lock); + if (!ci) + return ret; + + down_read(&ci->m_lock); + if (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)) + ret = KSMBD_INODE_STATUS_PENDING_DELETE; + else + ret = KSMBD_INODE_STATUS_OK; + up_read(&ci->m_lock); + + atomic_dec(&ci->m_count); return ret; } bool ksmbd_inode_pending_delete(struct ksmbd_file *fp) { - return (fp->f_ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)); + struct ksmbd_inode *ci = fp->f_ci; + int ret; + + down_read(&ci->m_lock); + ret = (ci->m_flags & (S_DEL_PENDING | S_DEL_ON_CLS)); + up_read(&ci->m_lock); + + return ret; } void ksmbd_set_inode_pending_delete(struct ksmbd_file *fp) { - fp->f_ci->m_flags |= S_DEL_PENDING; + struct ksmbd_inode *ci = fp->f_ci; + + down_write(&ci->m_lock); + ci->m_flags |= S_DEL_PENDING; + up_write(&ci->m_lock); } void ksmbd_clear_inode_pending_delete(struct ksmbd_file *fp) { - fp->f_ci->m_flags &= ~S_DEL_PENDING; + struct ksmbd_inode *ci = fp->f_ci; + + down_write(&ci->m_lock); + ci->m_flags &= ~S_DEL_PENDING; + up_write(&ci->m_lock); } void ksmbd_fd_set_delete_on_close(struct ksmbd_file *fp, int file_info) { - if (ksmbd_stream_fd(fp)) { - fp->f_ci->m_flags |= S_DEL_ON_CLS_STREAM; - return; - } + struct ksmbd_inode *ci = fp->f_ci; - fp->f_ci->m_flags |= S_DEL_ON_CLS; + down_write(&ci->m_lock); + if (ksmbd_stream_fd(fp)) + ci->m_flags |= S_DEL_ON_CLS_STREAM; + else + ci->m_flags |= S_DEL_ON_CLS; + up_write(&ci->m_lock); } static void ksmbd_inode_hash(struct ksmbd_inode *ci) @@ -257,27 +279,41 @@ static void __ksmbd_inode_close(struct ksmbd_file *fp) struct file *filp; filp = fp->filp; - if (ksmbd_stream_fd(fp) && (ci->m_flags & S_DEL_ON_CLS_STREAM)) { - ci->m_flags &= ~S_DEL_ON_CLS_STREAM; - err = ksmbd_vfs_remove_xattr(file_mnt_idmap(filp), - &filp->f_path, - fp->stream.name, - true); - if (err) - pr_err("remove xattr failed : %s\n", - fp->stream.name); + + if (ksmbd_stream_fd(fp)) { + bool remove_stream_xattr = false; + + down_write(&ci->m_lock); + if (ci->m_flags & S_DEL_ON_CLS_STREAM) { + ci->m_flags &= ~S_DEL_ON_CLS_STREAM; + remove_stream_xattr = true; + } + up_write(&ci->m_lock); + + if (remove_stream_xattr) { + err = ksmbd_vfs_remove_xattr(file_mnt_idmap(filp), + &filp->f_path, + fp->stream.name, + true); + if (err) + pr_err("remove xattr failed : %s\n", + fp->stream.name); + } } if (atomic_dec_and_test(&ci->m_count)) { + bool do_unlink = false; + down_write(&ci->m_lock); if (ci->m_flags & (S_DEL_ON_CLS | S_DEL_PENDING)) { ci->m_flags &= ~(S_DEL_ON_CLS | S_DEL_PENDING); - up_write(&ci->m_lock); - ksmbd_vfs_unlink(filp); - down_write(&ci->m_lock); + do_unlink = true; } up_write(&ci->m_lock); + if (do_unlink) + ksmbd_vfs_unlink(filp); + ksmbd_inode_free(ci); } } -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id qFAbN/VsN2mhjiEAYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 00:27:33 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 00:27:34 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSlZl-00000009Fpr-2FRZ for hi@josie.lol; Tue, 09 Dec 2025 00:27:33 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 599C83026FBD for ; Tue, 9 Dec 2025 00:27:25 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EB0E92FF148; Tue, 9 Dec 2025 00:18:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dfog2eeo" X-Original-To: stable@vger.kernel.org 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 C29932FF144; Tue, 9 Dec 2025 00:18:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239506; cv=none; b=FQTMowrobBP95lhRcyCYB4v99r7PNaUDbrfG7Su+1MSdYbsfYuamt7tBFVpwGPQGhkVlD9DJqNivoUxJcaDmpdH8XcheSE1z3vplKyymiamluut8aa2+6jTo/sOsnMZ4tQNTKzmZS18RvbxgCMTdW374SCimTlZ4Gj5utvK2J4E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239506; c=relaxed/simple; bh=EufPrSd66MHCfd1hrq0mehvzOsgd2H5VurLuDRQXTLY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZRYBn8nplQhrpqAtiJ3STkHiJ4tgnInIjj7nUTJSxBzdvnaNVrkJYlY0nQk2QSc7e92QRRdlwwhvnivVN/fi/pJlhhhPkYJ4nnKiV8/A0bPkC4Bv7ujtZiQSycBbmv2VUCpzeCkBP36TeRuNJENJBjby1o8OtgQWmkswceDmSTQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dfog2eeo; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6781C113D0; Tue, 9 Dec 2025 00:18:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765239506; bh=EufPrSd66MHCfd1hrq0mehvzOsgd2H5VurLuDRQXTLY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dfog2eeozK2WKRx6xXtfXhffR8wdhEiSAYeT2NmI5qL/ZnRtnt7NCjx+2zT3mHjil Iwh/8eet2RJvj6LtkonSIhvETzr8E23Q57/y9UL9Of5jc6Iov4WlOC0ert1oGFEbto x6tcOJgM+kBWpoZqQFX7QjnibqeBS/Ba+rqcyK1LZKK4lXr6leKSI0uMg7GSbDDTlk qjn+D5K31p6WenRS5YA4cby+sajl89o9r67/54V/MlTlljI9gmQqCOeguJMizZOd7H jBZISK5WVmYNL8uVMogAjIzAp2bBpjH03sLvEDiN8oetNdbuQBtzwYCp8E7pTxBh6J 4yKlKhLyRDa2Q== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Grzegorz Nitka , Aleksandr Loktionov , Paul Menzel , Simon Horman , Rinitha S , Tony Nguyen , Sasha Levin , przemyslaw.kitszel@intel.com, intel-wired-lan@lists.osuosl.org Subject: [PATCH AUTOSEL 6.18-6.12] ice: Allow 100M speed for E825C SGMII device Date: Mon, 8 Dec 2025 19:15:37 -0500 Message-ID: <20251209001610.611575-45-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251209001610.611575-1-sashal@kernel.org> References: <20251209001610.611575-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Grzegorz Nitka [ Upstream commit ba2807b869a16d36b8bc76efa774fe433b3c45de ] Add E825C 10GbE SGMII device to the list of devices supporting 100Mbit link mode. Without that change, 100Mbit link mode is ignored in ethtool interface. This change was missed while adding the support for E825C devices family. Testing hints (please note, for previous version, 100baseT/Full entry was missing): [root@localhost]# ethtool eth3 Settings for eth3: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: None Advertised link modes: 100baseT/Full 1000baseT/Full 10000baseT/Full ... Signed-off-by: Grzegorz Nitka Reviewed-by: Aleksandr Loktionov Reviewed-by: Paul Menzel Reviewed-by: Simon Horman Tested-by: Rinitha S (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Now I have a complete understanding. Let me summarize my analysis: ## DETAILED ANALYSIS ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `ice: Allow 100M speed for E825C SGMII device` **Key phrases in commit message:** - "This change was missed while adding the support for E825C devices family" - This explicitly acknowledges this is a bug fix for a missed case when E825C was introduced - "Without that change, 100Mbit link mode is ignored in ethtool interface" - Describes the user-visible symptom **Missing tags:** - No `Fixes:` tag (should logically point to `f64e189442332` - "ice: introduce new E825C devices family") - No `Cc: stable@vger.kernel.org` tag **Tags present:** - Multiple `Reviewed-by:` tags (3 reviewers including Simon Horman) - `Tested-by:` tag from Intel QA ### 2. CODE CHANGE ANALYSIS The change is extremely minimal - adding a single line to a switch statement: ```c bool ice_is_100m_speed_supported(struct ice_hw *hw) { switch (hw->device_id) { case ICE_DEV_ID_E822C_SGMII: case ICE_DEV_ID_E822L_SGMII: case ICE_DEV_ID_E823L_1GBE: case ICE_DEV_ID_E823C_SGMII: + case ICE_DEV_ID_E825C_SGMII: // <-- NEW LINE ADDED return true; default: return false; } } ``` **Technical mechanism:** - The `ice_is_100m_speed_supported()` function is called by `ice_mask_min_supported_speeds()` in `ice_ethtool.c` - This function is used to determine which link speeds to report to ethtool as supported - When `ice_is_100m_speed_supported()` returns `false`, the code masks off 100Mbit phy types (`ICE_PHY_TYPE_LOW_100BASE_TX` and `ICE_PHY_TYPE_LOW_100M_SGMII`) - Without this fix, E825C SGMII devices (PCI ID 0x579F) cannot advertise or use 100Mbit mode via ethtool, even though the hardware supports it **Root cause:** When E825C support was added in commit `f64e189442332`, the developer forgot to also add `ICE_DEV_ID_E825C_SGMII` to the `ice_is_100m_speed_supported()` function. All other E8xx SGMII devices were already included. ### 3. CLASSIFICATION **Type:** Bug fix - Missing device ID in a capability function **Category analysis:** - ✅ **Device ID addition to existing driver** - This is adding a device ID to an existing whitelist function - ❌ Not a new feature - The 100M speed support exists, just missing one device - ❌ Not a security fix - ✅ Hardware capability fix - Enables correct hardware capability reporting ### 4. SCOPE AND RISK ASSESSMENT **Size:** 1 line added to 1 file **Risk level:** EXTREMELY LOW - The change adds a single `case` label to a switch statement - The function returns a boolean indicating device capability - No logic changes, no side effects, no behavior changes for any other device - The E825C_SGMII device ID (0x579F) already exists and is used in other places in the driver - Multiple reviewers including Simon Horman **Subsystem:** Intel ice network driver (mature, widely used, well- tested) ### 5. USER IMPACT **Who is affected:** - Users with Intel E825-C SGMII network devices (PCI ID 0x579F) - These are specific embedded/enterprise networking devices **Symptom without fix:** - `ethtool` shows 100Mbit as NOT supported when it should be - Users cannot force 100Mbit link mode even if needed - Misleading capability reporting in network management tools **Severity:** Medium-Low - Not a crash, security issue, or data corruption - Affects device functionality/usability - Users with this specific hardware are affected ### 6. STABILITY INDICATORS **Positive signals:** - `Reviewed-by: Simon Horman ` (well-known networking reviewer) - `Reviewed-by: Aleksandr Loktionov` (Intel) - `Reviewed-by: Paul Menzel` - `Tested-by: Rinitha S` (Intel QA) - Commit signed off by Intel maintainer Tony Nguyen ### 7. DEPENDENCY CHECK **Dependencies:** - Requires E825C device support (introduced in v6.9-rc1 via `f64e189442332`) - Requires `ice_is_100m_speed_supported()` function (introduced in v6.1-rc1 via `39ed02a4ba527`) **Stable tree applicability:** - v6.6.y: ❌ No E825C support, commit NOT applicable - v6.10.y: ✅ Has E825C support and `ice_is_100m_speed_supported()`, commit APPLICABLE - v6.11.y: ✅ APPLICABLE - v6.12.y: ✅ APPLICABLE ### 8. STABLE KERNEL RULES ASSESSMENT | Rule | Assessment | |------|------------| | Obviously correct and tested | ✅ Yes - trivial addition, well- reviewed, tested | | Fixes real bug that affects users | ✅ Yes - 100Mbit mode not available on E825C SGMII | | Important issue | ⚠️ Moderate - not critical but affects device usability | | Small and contained | ✅ Yes - 1 line change | | No new features | ✅ Yes - enables existing functionality | | No new APIs | ✅ Yes | | Applies cleanly | ✅ Should apply cleanly to v6.10+ | ### CONCERNS 1. **No explicit stable markers:** The commit lacks `Cc: stable@vger.kernel.org` and `Fixes:` tags, suggesting the developer/maintainer didn't explicitly request backport 2. **Only applies to kernels with E825C support:** This fix is ONLY meaningful for kernels v6.10+ that have E825C device support. Backporting to v6.6.y would be pointless since those kernels don't have E825C at all. 3. **Not a critical fix:** While it's a real bug, it's not a crash, security issue, or data corruption - it's a feature parity/usability issue. ### RECOMMENDATION This commit **SHOULD be backported** to stable kernels that have E825C support (v6.10+, v6.11+, v6.12+) for the following reasons: 1. **Clearly a bug fix:** The commit message explicitly states "This change was missed while adding the support for E825C devices family" 2. **Trivial and safe:** Single line addition to a capability whitelist - minimal risk 3. **Well-reviewed and tested:** Multiple reviewers and explicit testing 4. **Follows the device ID exception:** Adding device IDs to existing functions is a well-accepted stable practice 5. **Fixes real user issue:** Users with E825C SGMII hardware cannot configure 100Mbit mode The lack of explicit stable tags appears to be an oversight rather than a deliberate decision to not backport. The change is clearly in the category of "hardware quirks/device ID additions that enable proper hardware support." **YES** drivers/net/ethernet/intel/ice/ice_common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/intel/ice/ice_common.c b/drivers/net/ethernet/intel/ice/ice_common.c index 2532b6f82e971..449418cf06c20 100644 --- a/drivers/net/ethernet/intel/ice/ice_common.c +++ b/drivers/net/ethernet/intel/ice/ice_common.c @@ -3389,6 +3389,7 @@ bool ice_is_100m_speed_supported(struct ice_hw *hw) case ICE_DEV_ID_E822L_SGMII: case ICE_DEV_ID_E823L_1GBE: case ICE_DEV_ID_E823C_SGMII: + case ICE_DEV_ID_E825C_SGMII: return true; default: return false; -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 0H/BG/lsN2l5FB8AYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 00:27:37 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 00:27:37 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSlZp-00000009FwR-0Am2 for hi@josie.lol; Tue, 09 Dec 2025 00:27:37 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 4E2423025295 for ; Tue, 9 Dec 2025 00:27:27 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 228F0280339; Tue, 9 Dec 2025 00:17:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="apD7uGpH" X-Original-To: stable@vger.kernel.org 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 E8D5028000C; Tue, 9 Dec 2025 00:17:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239469; cv=none; b=Ec1orvT9TpEzFxZGiIXJSgey7pouy673IOT90fI7eQ9rXiWk4BYjsMy/evFJXe6T4sIVf1EJ3EPAdywfrX7bh9jyBzhakTtqvbhyFINaRRsE2aS0R9DFRAq8ekQUlvDeQCgxZdKskjyZe/R2FwBtpGAajljKEespyB4bow7XB28= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239469; c=relaxed/simple; bh=s/QEWSZlzMtdYQhFb4Tcru5e4lkOHkbEjgrWsByZkp0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=klDBTdry/7Z8Iwe1dnoHGCleWUKskETuHrJemwpkRR6oDgnmZjJdlOFpGO8EP0WeJFftDxAdCzRbpVFgyPmhEhZcsRPg7Gsj/fnzOUWbGaI1jIX/JxqP0m4TtGjdqmCcBu8Dg7gtTdKfGkgOE2beMMxWs5S2JT5bCPjlDBmt/jI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=apD7uGpH; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53262C4CEF1; Tue, 9 Dec 2025 00:17:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765239467; bh=s/QEWSZlzMtdYQhFb4Tcru5e4lkOHkbEjgrWsByZkp0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=apD7uGpHW2vh+ajGy7NpltPtgqS3TTz56uQzkva+hk10WMGobaWGp38c01U12Bl0S Q3vnZKgGKd7nlzB+k3Gj3kJiRBcz0uGF+sP9aUV25nIUZHKTzf4DCqQaHfXY+wyeyp 7Fc84AkoHF56+G52QVuAlcMyYuAV/6k7b3rcMJBENDEEnA0s4DrfhbQ8uXqEDUdWqQ rFt35mTU2/zAE2AMNIJ1irHtX7iAUscdHiYY3HeiSu4Yw59e2GVJENDR0XfnjC5ZUb mRaTyjQ8ZIgZUIIGefNlsRm65h790p2/zxkIqbQhMCUiJxPabDF7h7jhp7rijbSsS8 +jsoCN997lWMQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Aditya Garg , Haiyang Zhang , Jakub Kicinski , Sasha Levin , kys@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com, kotaranov@microsoft.com, leon@kernel.org, shradhagupta@linux.microsoft.com, mlevitsk@redhat.com, ernis@linux.microsoft.com, yury.norov@gmail.com, ssengar@linux.microsoft.com, dipayanroy@linux.microsoft.com, shirazsaleem@microsoft.com, linux-hyperv@vger.kernel.org, linux-rdma@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.12] net: mana: Drop TX skb on post_work_request failure and unmap resources Date: Mon, 8 Dec 2025 19:15:21 -0500 Message-ID: <20251209001610.611575-29-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251209001610.611575-1-sashal@kernel.org> References: <20251209001610.611575-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: msgid.link] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Aditya Garg [ Upstream commit 45120304e84171fd215c1b57b15b285446d15106 ] Drop TX packets when posting the work request fails and ensure DMA mappings are always cleaned up. Signed-off-by: Aditya Garg Reviewed-by: Haiyang Zhang Link: https://patch.msgid.link/1763464269-10431-3-git-send-email-gargaditya@linux.microsoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Looking at this commit, I need to analyze it for stable backporting suitability. ## Commit Analysis ### What the commit does: 1. **In `mana_en.c`**: When `mana_gd_post_work_request()` fails during TX: - Previously: returned `NETDEV_TX_BUSY` without cleaning up DMA mappings - Now: calls `mana_unmap_skb()` to clean up DMA mappings, then drops the packet properly 2. **In `gdma_main.c`**: Removes a noisy `dev_err` message for flow control failure 3. **In `mana.h`**: Exports `mana_unmap_skb()` function for use across files ### Bug Being Fixed Looking at the original error path: ```c if (err) { (void)skb_dequeue_tail(&txq->pending_skbs); netdev_warn(ndev, "Failed to post TX OOB: %d\n", err); err = NETDEV_TX_BUSY; goto tx_busy; // DMA mappings NOT unmapped! } ``` The original code has **two bugs**: 1. **DMA resource leak**: When `mana_gd_post_work_request()` fails, the DMA mappings set up earlier (via `mana_map_skb()`) are never freed 2. **Improper error handling**: Returns `NETDEV_TX_BUSY` which tells the network stack to retry, but the skb was already dequeued from `pending_skbs`, leading to inconsistent state ### Code Change Assessment The fix is straightforward and surgical: ```c if (err) { (void)skb_dequeue_tail(&txq->pending_skbs); mana_unmap_skb(skb, apc); // NEW: Clean up DMA mappings netdev_warn(ndev, "Failed to post TX OOB: %d\n", err); goto free_sgl_ptr; // Drop packet properly } ``` ### Stable Criteria Evaluation | Criterion | Assessment | |-----------|------------| | Fixes real bug | ✅ Yes - DMA resource leak and improper error handling | | Obviously correct | ✅ Yes - unmapping DMA on error is clearly correct | | Small and contained | ✅ Yes - only affects error path in MANA driver | | No new features | ✅ Yes - pure bug fix | | User impact | ✅ Medium-high - affects Azure VM users; leaks can cause long-term instability | ### Risk Assessment - **Low risk**: Changes only affect the TX error path - **Self-contained**: The `mana_unmap_skb()` function already exists, just made non-static - **No dependencies**: This commit is standalone - **Well-tested**: Has "Reviewed-by" tag from Microsoft maintainer ### Missing Signals - No `Cc: stable@vger.kernel.org` tag - No `Fixes:` tag However, this is clearly fixing a resource leak bug that has existed since the error path was written. Resource leaks in network drivers are exactly the kind of bugs stable trees should fix. ### User Impact The MANA driver is used in Microsoft Azure VMs. DMA mapping leaks: - Cause memory pressure over time - Can lead to allocation failures under sustained TX errors - May cause VM instability in production cloud environments This is a production-relevant bug affecting real cloud users. ### Conclusion This commit fixes a genuine resource leak bug in the MANA network driver. The fix is: - Small (adds one function call + declaration) - Surgical (only affects error path) - Obviously correct (unmapping DMA on error is mandatory) - Low risk (doesn't touch normal TX path) - Important for production Azure VM users The lack of stable/Fixes tags is unfortunate but doesn't diminish the clear bug-fix nature of this change. **YES** drivers/net/ethernet/microsoft/mana/gdma_main.c | 6 +----- drivers/net/ethernet/microsoft/mana/mana_en.c | 7 +++---- include/net/mana/mana.h | 1 + 3 files changed, 5 insertions(+), 9 deletions(-) diff --git a/drivers/net/ethernet/microsoft/mana/gdma_main.c b/drivers/net/ethernet/microsoft/mana/gdma_main.c index 43f034e180c41..7d232ac250958 100644 --- a/drivers/net/ethernet/microsoft/mana/gdma_main.c +++ b/drivers/net/ethernet/microsoft/mana/gdma_main.c @@ -1299,7 +1299,6 @@ int mana_gd_post_work_request(struct gdma_queue *wq, struct gdma_posted_wqe_info *wqe_info) { u32 client_oob_size = wqe_req->inline_oob_size; - struct gdma_context *gc; u32 sgl_data_size; u32 max_wqe_size; u32 wqe_size; @@ -1329,11 +1328,8 @@ int mana_gd_post_work_request(struct gdma_queue *wq, if (wqe_size > max_wqe_size) return -EINVAL; - if (wq->monitor_avl_buf && wqe_size > mana_gd_wq_avail_space(wq)) { - gc = wq->gdma_dev->gdma_context; - dev_err(gc->dev, "unsuccessful flow control!\n"); + if (wq->monitor_avl_buf && wqe_size > mana_gd_wq_avail_space(wq)) return -ENOSPC; - } if (wqe_info) wqe_info->wqe_size_in_bu = wqe_size / GDMA_WQE_BU_SIZE; diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c index 0142fd98392c2..6d37f39930453 100644 --- a/drivers/net/ethernet/microsoft/mana/mana_en.c +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c @@ -438,9 +438,9 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev) if (err) { (void)skb_dequeue_tail(&txq->pending_skbs); + mana_unmap_skb(skb, apc); netdev_warn(ndev, "Failed to post TX OOB: %d\n", err); - err = NETDEV_TX_BUSY; - goto tx_busy; + goto free_sgl_ptr; } err = NETDEV_TX_OK; @@ -460,7 +460,6 @@ netdev_tx_t mana_start_xmit(struct sk_buff *skb, struct net_device *ndev) tx_stats->bytes += len + ((num_gso_seg - 1) * gso_hs); u64_stats_update_end(&tx_stats->syncp); -tx_busy: if (netif_tx_queue_stopped(net_txq) && mana_can_tx(gdma_sq)) { netif_tx_wake_queue(net_txq); apc->eth_stats.wake_queue++; @@ -1606,7 +1605,7 @@ static int mana_move_wq_tail(struct gdma_queue *wq, u32 num_units) return 0; } -static void mana_unmap_skb(struct sk_buff *skb, struct mana_port_context *apc) +void mana_unmap_skb(struct sk_buff *skb, struct mana_port_context *apc) { struct mana_skb_head *ash = (struct mana_skb_head *)skb->head; struct gdma_context *gc = apc->ac->gdma_dev->gdma_context; diff --git a/include/net/mana/mana.h b/include/net/mana/mana.h index 0921485565c05..330e1bb088bb9 100644 --- a/include/net/mana/mana.h +++ b/include/net/mana/mana.h @@ -580,6 +580,7 @@ int mana_set_bw_clamp(struct mana_port_context *apc, u32 speed, void mana_query_phy_stats(struct mana_port_context *apc); int mana_pre_alloc_rxbufs(struct mana_port_context *apc, int mtu, int num_queues); void mana_pre_dealloc_rxbufs(struct mana_port_context *apc); +void mana_unmap_skb(struct sk_buff *skb, struct mana_port_context *apc); extern const struct ethtool_ops mana_ethtool_ops; extern struct dentry *mana_debugfs_root; -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id CBEZDwltN2mhjiEAYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 00:27:53 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 00:27:53 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSla4-00000009GOh-3JKj for hi@josie.lol; Tue, 09 Dec 2025 00:27:53 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id F1BD830252AC for ; Tue, 9 Dec 2025 00:27:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 8C3942C21F6; Tue, 9 Dec 2025 00:18:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nG3JJTL4" X-Original-To: stable@vger.kernel.org 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 62DDE2C21DB; Tue, 9 Dec 2025 00:18:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239481; cv=none; b=EdcMurZ9yu9RTUIr3lpVBjHiIOcq9UIncejAOm8l/N52OE4aoV6JHd7wN7IGF8+LVCtqEIQ9VAEpYEIS/D1wNVcmDabqvfIxpojZNuENgKrZJ5LkUZDfb6Y2fJ/t10Az52lp1QQSzDeXQjQi/uEz1nd1jC0vtwunXraRFJxfVr0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239481; c=relaxed/simple; bh=CSQMfTQPXZLjqMWRtHe8dfSMfidZ/+gtOgF3qxo6FzM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qqXnTmUt/Y1Rt7/RUE/RR/ZQp1fEW3TK7ANklI72nElvOOEnvE088ZIdHmS64mqrPsh9VTPeogmAT/QlXXJFpmSWfz8OIl2TZjD+x7CGLU+Gu3lAlj2sVI02+YGMIhizIQfDH+ND0HfiR0WXuAIGQZjEUuysUgdNSpKoVm/hUAU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nG3JJTL4; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C754C4CEF1; Tue, 9 Dec 2025 00:17:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765239480; bh=CSQMfTQPXZLjqMWRtHe8dfSMfidZ/+gtOgF3qxo6FzM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nG3JJTL4xmaZO/AhB6QrXH8lgOZG92QS8ZBLZhOatRqxvxGQQ0Lr7N84gbJnTqmKl t89np7AM387R5MGvHnTVP8dJxkX58yPJfN+HnU99Qnru1gCl+z2abTX3auC+Kt1tmi kGJB3LLndN+3n6A1MbZAoD30nBgqCNNAxorekWxldYhL0eP6lBqnqEuI0IuuWkvO64 fPmAwmeW8LyxAd5ryldv3LBczQtF9lxPN+OErw3X8gVxYez/Id/jwcUqCfnOMvg8K2 d7rvGl0jiLsgOSWxj4VFPsqujWuRMibNpAOg9yI8UpDLgf1WySReFPUibCTYy9acha r3rO5X7avEw3Q== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Hiroaki Yamamoto , Ping-Ke Shih , Sasha Levin , linux-wireless@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.17] wifi: rtw88: Add BUFFALO WI-U3-866DHP to the USB ID list Date: Mon, 8 Dec 2025 19:15:27 -0500 Message-ID: <20251209001610.611575-35-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251209001610.611575-1-sashal@kernel.org> References: <20251209001610.611575-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: msgid.link] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Hiroaki Yamamoto [ Upstream commit 8adb609f645b42148c14989066a971bbb5f3587e ] BUFFALO WI-U3-866DHP (0411:03d0) is based on rtl8812bu. I locally tested this patch with a retail sample and it worked fine. Signed-off-by: Hiroaki Yamamoto Acked-by: Ping-Ke Shih Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251031111641.33653-1-hrak1529@gmail.com Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Now I have a complete picture. Let me provide my thorough analysis: --- ## Comprehensive Analysis ### 1. COMMIT MESSAGE ANALYSIS **Subject:** `wifi: rtw88: Add BUFFALO WI-U3-866DHP to the USB ID list` **Body:** - States the device USB VID/PID: `0411:03d0` (BUFFALO is vendor 0x0411) - Claims the device is "based on rtl8812bu" (RTL8822B chipset) - Author tested with a retail sample and confirms it works **Tags:** - `Signed-off-by: Hiroaki Yamamoto` (author/contributor) - `Acked-by: Ping-Ke Shih` (Realtek driver maintainer) - `Signed-off-by: Ping-Ke Shih` (committed by maintainer) - **NO `Cc: stable@vger.kernel.org` tag** - **NO `Fixes:` tag** ### 2. CODE CHANGE ANALYSIS The commit is **extremely simple and surgical**: ```c + { USB_DEVICE_AND_INTERFACE_INFO(0x0411, 0x03d0, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /* BUFFALO WI-U3-866DHP */ ``` **What it does:** - Adds a single USB device ID entry to the `rtw_8822bu_id_table[]` array - Uses `USB_DEVICE_AND_INTERFACE_INFO()` macro with: - VID: `0x0411` (BUFFALO Inc.) - PID: `0x03d0` (WI-U3-866DHP specific) - Interface class/subclass/protocol: `0xff, 0xff, 0xff` (vendor- specific) - Associates with `rtw8822b_hw_spec` - the existing chip specification structure **Why it's correct:** - The pattern is identical to 34 other devices already in this table - The `rtw8822b_hw_spec` structure already supports this chipset - All device-specific handling is already implemented in the driver - No new code paths are introduced - only the USB subsystem can now recognize and bind this device ### 3. CLASSIFICATION **Category: NEW DEVICE ID ADDITION** This falls squarely into the "NEW DEVICE IDs" exception category that IS allowed in stable: - Adding USB VID/PID to an existing, working driver - One-line addition that enables hardware support - Device uses identical chip (RTL8822B) as many other supported devices - No new functionality, APIs, or driver changes This is NOT: - A new driver (driver already exists since v6.2) - A new feature - A bug fix (though users without support might consider it a bug) - A security fix - A quirk/workaround ### 4. SCOPE AND RISK ASSESSMENT **Lines changed:** 2 lines (one USB_DEVICE entry + comment) **Files touched:** 1 file (`rtw8822bu.c`) **Complexity:** Trivial - just data table addition **Subsystem:** WiFi/Realtek rtw88 driver - The rtw88 driver is mature (mainline since v5.2 for PCIe, v6.2 for USB) - USB support is well-tested with 34+ devices in the table **Risk of regression:** **EXTREMELY LOW** - The change only affects users who plug in this specific BUFFALO device - No existing functionality is modified - No code paths change for other devices - If the device ID is somehow wrong, worst case is the device doesn't work - Cannot break any existing hardware ### 5. USER IMPACT **Who is affected:** - Users with BUFFALO WI-U3-866DHP USB WiFi adapter - This appears to be a retail device from BUFFALO (Japanese networking company) - Without this patch, users would need to manually bind the device using sysfs or build custom kernels **Severity:** - Not a crash/security/data corruption issue - This is a hardware enablement issue - device simply won't be recognized - Users who buy this device expect it to work with Linux **Market context:** - BUFFALO is a major Japanese networking brand - The WI-U3-866DHP is a USB 3.0 802.11ac adapter - Similar to WI-U2-866DM (0411:03d1) which was added in b7f0cc647e522 ### 6. STABILITY INDICATORS **Positive signals:** - Acked by Ping-Ke Shih (Realtek maintainer) - Author claims personal testing with retail hardware - Follows exact same pattern as 34 other working device entries **Negative signals:** - No `Cc: stable@vger.kernel.org` tag - No external testing reports (Tested-by) - No Reviewed-by from other developers ### 7. DEPENDENCY CHECK **Dependencies:** None - This change only adds data to an array - No other commits required - No API changes needed **Stable tree compatibility:** - The rtw8822bu driver exists in stable kernels from v6.2 onwards - The file structure is compatible (USB ID table is at same location) - May require minor adjustment if backporting to older stable trees where some context lines differ due to fewer USB IDs in the table ### 8. COMPARISON WITH SIMILAR COMMITS Looking at recent USB ID additions to rtw88: | Commit | Description | Stable Tag? | Backported? | |--------|-------------|-------------|-------------| | `b8a62478f3b14` | Add missing VID/PIDs for 8811CU/8821CU | **YES** (`Cc: stable`) | YES (6.10+) | | `7b5ce65d90187` | 8821au additional devices | NO | NO | | `d4c4903508f9e` | Additional USB IDs for RTL8812BU | NO | NO | | `80c4668d024ff` | Mercusys MA30N, D-Link DWA-T185 | NO | NO | | `b7f0cc647e522` | BUFFALO WI-U2-866DM | NO | NO | | **This commit** | BUFFALO WI-U3-866DHP | NO | ? | The pattern shows that USB ID additions WITHOUT explicit stable tags are typically NOT backported, while those WITH the tag ARE backported. --- ## FINAL ASSESSMENT ### Arguments FOR backporting: 1. **Falls under "NEW DEVICE IDs" exception** - USB ID additions to existing drivers are explicitly allowed in stable 2. **Trivial change** - 2 lines of data, zero code changes 3. **Zero regression risk** - Only affects this specific device 4. **Enables real hardware** - Users with this device can use their hardware 5. **Well-tested pattern** - Identical to 34 other entries in the same driver 6. **Driver is mature** - rtw8822bu has been in mainline since v6.2 ### Arguments AGAINST backporting: 1. **No explicit stable tag** - The maintainer did NOT add `Cc: stable@vger.kernel.org` 2. **Not fixing a bug** - This is enablement, not a fix 3. **No Fixes: tag** - Not tied to any bug 4. **Precedent** - Similar commits without stable tags were not backported 5. **Maintainer choice** - If Ping-Ke Shih wanted it in stable, they would have added the tag ### Risk vs Benefit: - **Risk:** Essentially zero - worst case is the device doesn't work on one specific hardware configuration - **Benefit:** Moderate - enables hardware support for users with this specific BUFFALO adapter ### Decision Reasoning: While this commit is technically safe to backport (it's a trivial USB ID addition with no risk), the kernel's stable tree process respects maintainer intent. The absence of a `Cc: stable@vger.kernel.org` tag indicates the maintainer did not consider this critical enough for stable trees. Looking at the pattern of similar commits, those without stable tags are consistently not backported. Additionally, USB device ID additions for "new" hardware (devices that weren't recognized before) are generally seen as enablement rather than bug fixes. The stable kernel rules emphasize fixing bugs that affect users, not adding hardware support. The conservative approach for stable trees is to follow maintainer intent. If the maintainer wanted this in stable, they would have tagged it. **YES** drivers/net/wireless/realtek/rtw88/rtw8822bu.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw88/rtw8822bu.c b/drivers/net/wireless/realtek/rtw88/rtw8822bu.c index 44e28e583964c..2769b86ce1b2a 100644 --- a/drivers/net/wireless/realtek/rtw88/rtw8822bu.c +++ b/drivers/net/wireless/realtek/rtw88/rtw8822bu.c @@ -79,6 +79,8 @@ static const struct usb_device_id rtw_8822bu_id_table[] = { .driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /* D-Link DWA-T185 rev. A1 */ { USB_DEVICE_AND_INTERFACE_INFO(0x0411, 0x03d1, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /* BUFFALO WI-U2-866DM */ + { USB_DEVICE_AND_INTERFACE_INFO(0x0411, 0x03d0, 0xff, 0xff, 0xff), + .driver_info = (kernel_ulong_t)&(rtw8822b_hw_spec) }, /* BUFFALO WI-U3-866DHP */ {}, }; MODULE_DEVICE_TABLE(usb, rtw_8822bu_id_table); -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id GEEgGBVtN2mcjiEAYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 00:28:05 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 00:28:05 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSlaH-00000009Gp0-05FR for hi@josie.lol; Tue, 09 Dec 2025 00:28:05 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id 05C24302AAF6 for ; Tue, 9 Dec 2025 00:27:38 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A80FB2E4266; Tue, 9 Dec 2025 00:18:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kD9LfDi+" X-Original-To: stable@vger.kernel.org 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 7E28D2E370E; Tue, 9 Dec 2025 00:18:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239487; cv=none; b=L5GIVAXfutHJLBG3UDumvjeTJ4OXSTmVqxTZfiyN3h/28VS7k8PCkIjiyB8++bQSdULHKU9R8OrjScEPArM5Su5pjyrwqTOimwOxkaTUgrUBKxJLbsekdQHzwe0HUKOqrhdEdRBgrBRHqt9MiDFH1coVnizQltVqF289eKL2XFA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765239487; c=relaxed/simple; bh=1E52SU0XhxhmH0LjX9ze5vyc45B8H7RL6W44/GdTtww=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZcTpxttDv4fucfN4YCRedi3MJCG9RkAjFCw1+J1iDQZ1dyDBX02PDfovJ6S8Yt0AkdAr+7BT0MZCWeL/D0JrSReeD3EjJUu33HtNuqEALM9p8IDUrkp9aL9+P8M7oXaFX8/cRT+gLJBui/nub0kZHwW8EVS1krW2t+tt5DOMV9g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kD9LfDi+; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4AA4FC19421; Tue, 9 Dec 2025 00:18:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765239487; bh=1E52SU0XhxhmH0LjX9ze5vyc45B8H7RL6W44/GdTtww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kD9LfDi++dWHhMcJbPhseMz577o4fZIhMtmgbP8mi+NsYhCJLwViFJqj9hMoFLAPE n9xrz5tdFho8tCIU+e/d0KimIqaJWa9UDE9zHbg71tp7t8MTJgwsz2f7GvqsjI2BbI LCflxMFIQ18u/M/UNNY4efIeeuh9Jzqr9OSOqJnNA9p59nz72pMeq0EvBma9mW3ne4 PUiTHQHifr+rr8b5gEfgy7ellhS9X2Me6R6QvCHXlDUfL86AW6/Y+Y90kxukcfZutf RxnNJZC8bAN6mU3KyrRabmet120V4YFumoSDMyybvgooLvXhXrHyo1nAFnQKGX3Tf9 iRSHtwXLKhKIA== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Kuan-Chung Chen , Ping-Ke Shih , Sasha Levin , linux-wireless@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.1] wifi: rtw89: phy: fix out-of-bounds access in rtw89_phy_read_txpwr_limit() Date: Mon, 8 Dec 2025 19:15:30 -0500 Message-ID: <20251209001610.611575-38-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20251209001610.611575-1-sashal@kernel.org> References: <20251209001610.611575-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18 Content-Transfer-Encoding: 8bit X-DKIM: signer='kernel.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -1.2 (-) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (-1.2 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: msgid.link] -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: -11 From: Kuan-Chung Chen [ Upstream commit 1dd7e743dd37361c8c1ac89355a8da738e2b81fb ] Coverity reported a potential out-of-bounds access when 'bw' exceeds the valid range for the specified band. Add a helper `rtw89_bw_is_valid()` to check bandwidth validity for each band before accessing limit tables. Addresses-Coverity-ID: 1598844 ("Out-of-bounds access") Addresses-Coverity-ID: 1598896 ("Out-of-bounds access") Signed-off-by: Kuan-Chung Chen Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20251111022452.28093-6-pkshih@realtek.com Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: ## Analysis of Commit for Stable Backport ### 1. COMMIT MESSAGE ANALYSIS - **Subject:** Clearly indicates a bug fix - "fix out-of-bounds access" - **Bug Type:** Out-of-bounds array access (memory safety issue) - **Source:** Coverity static analysis (IDs 1598844, 1598896) - **No "Cc: stable@vger.kernel.org"** tag present - **No "Fixes:" tag** pointing to original buggy commit ### 2. CODE CHANGE ANALYSIS **The Bug:** The function `rtw89_phy_read_txpwr_limit()` uses the `bw` (bandwidth) parameter as an array index in expressions like: ```c da_lmt = (*rule_da_2ghz->lmt)[bw][ntx][rs][bf][regd][ch_idx]; lmt = (*rule_2ghz->lmt)[bw][ntx][rs][bf][regd][ch_idx]; ``` Different bands (2G, 5G, 6G) have different valid bandwidth ranges (`RTW89_2G_BW_NUM`, `RTW89_5G_BW_NUM`, `RTW89_6G_BW_NUM`). If `bw` exceeds the valid range for the specified band, an out-of-bounds array read occurs. **The Fix:** 1. Adds a new helper function `rtw89_phy_validate_txpwr_limit_bw()` that validates bandwidth against band-specific limits 2. Adds a validation check at the beginning of `rtw89_phy_read_txpwr_limit()` that returns 0 (safe default) if validation fails **Technical Correctness:** The fix is straightforward - validate input before using it as array index. This is a defensive programming pattern that prevents OOB access. ### 3. CLASSIFICATION - **Bug fix:** Yes - fixes memory safety bug (OOB read) - **Feature addition:** No - **Security relevant:** Potentially - OOB access can cause crashes, kernel panics, or information leaks ### 4. SCOPE AND RISK ASSESSMENT | Factor | Assessment | |--------|------------| | Lines changed | ~20 lines added | | Files touched | 1 file (phy.c) | | Complexity | Low - simple validation check | | Regression risk | Very low - only adds validation, no behavioral change for valid inputs | | Subsystem | rtw89 WiFi driver (Realtek 802.11ax) | The change is **small and surgical**. It only adds bounds checking and returns a safe default (0) for invalid inputs. Normal operation is completely unaffected. ### 5. USER IMPACT - **Affected users:** Users with Realtek rtw89 WiFi hardware - **Severity if triggered:** Kernel crash/oops or potential information leak - **Trigger conditions:** Invalid `bw` value exceeding band-specific limits - **Real-world likelihood:** Uncertain - could be triggered by malformed firmware/hardware responses or bugs elsewhere in the driver ### 6. STABILITY INDICATORS - Signed-off by Realtek engineers (maintainer-level confidence) - No explicit tested-by or reviewed-by tags visible - Has proper patch link for traceability ### 7. DEPENDENCY CHECK The fix uses existing constants (`RTW89_*_BW_NUM`) that should exist in any stable kernel with the rtw89 driver. The rtw89 driver was introduced in kernel 5.16, so this applies to 6.1.y, 6.6.y, and newer stable branches. ### DECISION RATIONALE **For backporting:** - Fixes a genuine memory safety bug (OOB array access) - Small, self-contained fix with minimal regression risk - Defensive in nature - only affects invalid input handling - OOB access bugs can have security implications **Against backporting:** - No explicit "Cc: stable" tag from maintainers - Coverity-found vs user-reported (no evidence of actual crashes in the wild) - No "Fixes:" tag to identify the original buggy commit **Verdict:** Despite the lack of explicit stable tags, this is a legitimate memory safety fix that: 1. Is obviously correct and small 2. Fixes a real bug (OOB access) 3. Has no risk of regression for valid code paths 4. Could prevent crashes or security issues The fix meets stable kernel criteria: it's a small, self-contained bug fix that addresses a real memory safety issue without changing normal behavior. Out-of-bounds access bugs are the type of issues stable trees should protect against. **YES** drivers/net/wireless/realtek/rtw89/phy.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c index ba7feadd75828..e8960fbcb72db 100644 --- a/drivers/net/wireless/realtek/rtw89/phy.c +++ b/drivers/net/wireless/realtek/rtw89/phy.c @@ -2339,6 +2339,21 @@ static u8 rtw89_channel_to_idx(struct rtw89_dev *rtwdev, u8 band, u8 channel) } } +static bool rtw89_phy_validate_txpwr_limit_bw(struct rtw89_dev *rtwdev, + u8 band, u8 bw) +{ + switch (band) { + case RTW89_BAND_2G: + return bw < RTW89_2G_BW_NUM; + case RTW89_BAND_5G: + return bw < RTW89_5G_BW_NUM; + case RTW89_BAND_6G: + return bw < RTW89_6G_BW_NUM; + default: + return false; + } +} + s8 rtw89_phy_read_txpwr_limit(struct rtw89_dev *rtwdev, u8 band, u8 bw, u8 ntx, u8 rs, u8 bf, u8 ch) { @@ -2363,6 +2378,11 @@ s8 rtw89_phy_read_txpwr_limit(struct rtw89_dev *rtwdev, u8 band, }; s8 cstr; + if (!rtw89_phy_validate_txpwr_limit_bw(rtwdev, band, bw)) { + rtw89_warn(rtwdev, "invalid band %u bandwidth %u\n", band, bw); + return 0; + } + switch (band) { case RTW89_BAND_2G: if (has_ant_gain) -- 2.51.0 From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id IHTJFZx3N2nyPiEAYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 01:13:00 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 01:13:00 +0000 Received: from tor.lore.kernel.org ([172.105.105.114]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSmHk-0000000AnOh-0IZ0 for hi@josie.lol; Tue, 09 Dec 2025 01:13:00 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by tor.lore.kernel.org (Postfix) with ESMTP id DEC793038774 for ; Tue, 9 Dec 2025 01:12:10 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9B74A26A1A4; Tue, 9 Dec 2025 01:12:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="pd6JSIMY" X-Original-To: stable@vger.kernel.org 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 5BE2C3B8D40; Tue, 9 Dec 2025 01:12:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765242730; cv=none; b=Or6LupqYZ3a7QDzoGFQvZ2JWmhwC+2q4T1H+R9KmAJHco+Iea46Whe9V6JZ0XXwDx+HX3jvRTDqNGlzLjFShG/xYt59A3ZDYOoicCeas1twaBPK1g/JL7Owk+qRFWmHHIaotEF3dMSXfcAVAJcrmaeMvlHxQPUiJoXc/lATV/7E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765242730; c=relaxed/simple; bh=tdPB2PgMe3mUkDXQiTbjYNJfDLYriS/A9ApOIexKkXc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=CleQO+KEeY6f3Sn5QsY1MzJk1fwH70ledW4M8GJP3QKSOY4XmKmS+bQV7ZT/B5199Iu0Wva4u4PjCVoZd02R5xp5Lr48TlAHQay339aOHpzJVn76RHVn92qohoL/JrpSPtI2B3mQzzOPbj16ksr3TDNSHFzjjjKdXWgnGopLhPs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=pd6JSIMY; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70DA3C4CEF1; Tue, 9 Dec 2025 01:12:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1765242729; bh=tdPB2PgMe3mUkDXQiTbjYNJfDLYriS/A9ApOIexKkXc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pd6JSIMYFMnskJxSUCN+xCQbB9d2BHLm4McvapDYGN03mSx0XzAQCAC+fKUpQ+7up E9YTpP2bwrE3vWqxOLt4ilYOf5nbXESIm5GHpImOXscbu9vpO8SI5RQwbT2GBMQA96 AUQvg5Q9fLDlsDiiRFrKegZ/ywzlkOMyd2ZdHW3c= Date: Tue, 9 Dec 2025 10:12:05 +0900 From: Greg KH To: Slavin Liu Cc: Steffen Klassert , stable@vger.kernel.org, Sabrina Dubroca , "netdev@vger.kernel.org" Subject: Re: [BUG] Missing backport for commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x") Message-ID: <2025120949-harddisk-condone-fd95@gregkh> References: <20251209010626.1080-1-slavin452@gmail.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20251209010626.1080-1-slavin452@gmail.com> X-DKIM: signer='linuxfoundation.org' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: linuxfoundation.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.105.105.114 listed in list.dnswl.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_HIGH DKIMwl.org - High trust sender SpamTally: Final spam score: 4 On Tue, Dec 09, 2025 at 09:06:26AM +0800, Slavin Liu wrote: > Thanks for the clarification. > > In that case, I would like to request backporting both of the following > commits to the LTS kernels to resolve the UAF issue: > > Commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x") > Commit 10deb6986484 ("xfrm: also call xfrm_state_delete_tunnel at destroy > time for states that were never added") > > Please consider queuing them up together. I have no context here :( Anyway, these commits are all queued up now. thanks, greg k-h From - Tue Dec 09 08:46:38 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id 4DuaIfukN2nIGjsAYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 04:26:35 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 04:26:35 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vSpJ4-0000000Gxfp-2VzD for hi@josie.lol; Tue, 09 Dec 2025 04:26:35 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with ESMTP id C3B063007A2D for ; Tue, 9 Dec 2025 04:26:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6473D2DC323; Tue, 9 Dec 2025 04:26:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b="FE2a4X8b" X-Original-To: stable@vger.kernel.org Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5438029D289 for ; Tue, 9 Dec 2025 04:26:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765254389; cv=none; b=SUkZDm4ArOkfy1z3lP/wSuu9GVUd9sgfRcFLNuFAvYGZBCpAoq7jFBFfheT1Jf7y1KW/NXgXY4kBNTl6yDdMNxw3T6ZsgvFm5uN73+Zz6Hh8lNGhhM3uTl5Ra8r5CcWOndiu4/fBhIv6zHUxQnyrLABdtKpAVhXB2ufqsnZPkg8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765254389; c=relaxed/simple; bh=+jXp364WAzM9xwWFBvHkY3DKUklTKUVYtX/u2Wc/OxM=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=QLSc5ii/3SbxX11Ol8bGQc1WX86HtiZTjZZFwASEBNc9Qz57Dz4zh+cxiqDCh0qXXwqt7kAnO4c0q02F6ja1RpZNIC7PWKSKxzdHnRISkR2tCVClHLD+8nB3yW3jSAoEQwEifQEja/+X8AzVOafoBujkLZMLY/Y9g5M8IyfVYc8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com; spf=pass smtp.mailfrom=sifive.com; dkim=pass (2048-bit key) header.d=sifive.com header.i=@sifive.com header.b=FE2a4X8b; arc=none smtp.client-ip=209.85.208.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-lj1-f177.google.com with SMTP id 38308e7fff4ca-37b999d0c81so39075581fa.2 for ; Mon, 08 Dec 2025 20:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1765254385; x=1765859185; darn=vger.kernel.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=QTHKBpK1r9/QXVkfGq5Zpqp+C9e4nuUAoI+dJvTTj8c=; b=FE2a4X8bpf3ZujUCxafspWlWGP6IBX9KUZmYzROHQTw/WapmCiSMOutlGnPv/5/Zmd nB8A75BuwUIWlPzz/4HMUb+cGjF8G3NtFPZ97o8Ujtc5UXzJ8ltyjoZ26H6xWdcImJpH txYJ0y//StgYMoxLoBLrlDTPK+WQeFYBUZyJ0YLRes/ePZCt25LpCJ0FAg2ZsKP8IZI6 8ZJLN5ed+8tqEOU3hJp1OMXMeuHitnvi052tVT/4dtRgrRU9yLQMnHTB6c9KvZQZ3aAw YHBpEW2ktaiYRiG694DVE0Yu4Se+gSiCj0GgHM239WHrrqToc3sVAS+jzZV6Q3etWXeo atig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765254385; x=1765859185; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=QTHKBpK1r9/QXVkfGq5Zpqp+C9e4nuUAoI+dJvTTj8c=; b=aJjL7Rt5859FZpGOwZ60PYGWE5Br4v5ptZPN1x9x3UR3lD1hua48NnCmMBkWBIPTFv qzpxxTdIQVLbhzYgyBrsr34yqCG6+TYEagCN1Kmt/D2k9UCBXz5R8GZbpA5ayKgdAoEU by6X2rIr0N6Vq4bYz2vnVAEt1nwywLTBFNrTVB4vMMY2Otnt/kVzOH6PQ6R/glwRTK9f a0DYMSLXhrrXsAu092lEvBIfX+LJny2LZ6j9WoO5rxF0MosHuvboCruKecq7+53qVdxH yQgzbCpcaHIw+JLHCJepOXcI1F028/YXqedUb9BhvbVAyZCKujpIEiR/U1fGtsb81E36 esqQ== X-Forwarded-Encrypted: i=1; AJvYcCXGUnLxKkwVHNQpF2jSet817LlzU5sf77lQEhxWiVOqqJyNFI+egg5A+HGV2IGEYwb4I9TeFL4=@vger.kernel.org X-Gm-Message-State: AOJu0YyXllsIODR9sPzxip9vSCn2VeJzKJhVrELON+qdWxqYEwV2wsIZ jfyPTQf8iD5ko0nTZNusnEjaiDB7LCKUU+rdxAgcqidzcxeVSSLaEsPRDzi/NAbwBlyv9Ypf9jf 7ZXEeXKmdum59qaIzfdbpSvlcehERPJO1M6HMIytdVg== X-Gm-Gg: ASbGncvGy/W4pMt1lc37AuXWhDd6/7oT+b/dklNwmgqEw65ABpzmLl/T/YHaQ2+Fh31 EStvAoGkb0YvhXdwxHnfqn1gh5FscFn+n5+4G3+GWEOznN4U5+6xOxjAHgGwIJhP9JZMK3pZbVB qR4iwtqY/wkLHERaeosoBY0yT03feLq1hZb3R2m1jEoG0dUoNisgdY4U7fW5C7jxwE5zbn097RB YVImNsTay/3xREezGSfueVxHF0PY4wbDRjIwKdM1N4M87/agw7MQ2PAc9r+KmT2ohDiJZFUGL8t ty8MhQnippVD/ydYQfEZs7wuDomULfve3FOMIA3t4bYRGlAjYRimb7a9rh8= X-Google-Smtp-Source: AGHT+IEuwzsJ4iV/hppl7a+6AO2kFJTb1s8y+TSbQtxey/3zGokRC7kaOoo9yRzyTlRYxagbo5MXAG+kmUtRs73p+UA= X-Received: by 2002:a05:651c:254c:20b0:37b:a981:102c with SMTP id 38308e7fff4ca-37ed200a5admr22604601fa.18.1765254385419; Mon, 08 Dec 2025 20:26:25 -0800 (PST) Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20251206213750.81474-1-ebiggers@kernel.org> In-Reply-To: <20251206213750.81474-1-ebiggers@kernel.org> From: Jerry Shih Date: Tue, 9 Dec 2025 12:26:13 +0800 X-Gm-Features: AQt7F2rTqXUuqCjvRaHnuo7-SDbJXdxT1X5i9wZAPz9F_2e7btemAb2GuvQSqHI Message-ID: Subject: Re: [PATCH] lib/crypto: riscv: Depend on RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS To: Eric Biggers Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, Ard Biesheuvel , "Jason A . Donenfeld" , Herbert Xu , Vivian Wang , "David S . Miller" , Palmer Dabbelt , Paul Walmsley , Alexandre Ghiti , "Martin K . Petersen" , Han Gao , linux-riscv@lists.infradead.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-DKIM: signer='sifive.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://mxroutedocs.com/directadmin/spamfilters/ --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: sifive.com] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [104.64.211.4 listed in list.dnswl.org] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 On Sun, Dec 7, 2025 at 5:39=E2=80=AFAM Eric Biggers w= rote: > > Replace the RISCV_ISA_V dependency of the RISC-V crypto code with > RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS, which implies RISCV_ISA_V as > well as vector unaligned accesses being efficient. > > This is necessary because this code assumes that vector unaligned > accesses are supported and are efficient. (It does so to avoid having > to use lots of extra vsetvli instructions to switch the element width > back and forth between 8 and either 32 or 64.) > > This was omitted from the code originally just because the RISC-V kernel > support for detecting this feature didn't exist yet. Support has now > been added, but it's fragmented into per-CPU runtime detection, a > command-line parameter, and a kconfig option. The kconfig option is the > only reasonable way to do it, though, so let's just rely on that. > > Fixes: eb24af5d7a05 ("crypto: riscv - add vector crypto accelerated AES-{= ECB,CBC,CTR,XTS}") > Fixes: bb54668837a0 ("crypto: riscv - add vector crypto accelerated ChaCh= a20") > Fixes: 600a3853dfa0 ("crypto: riscv - add vector crypto accelerated GHASH= ") > Fixes: 8c8e40470ffe ("crypto: riscv - add vector crypto accelerated SHA-{= 256,224}") > Fixes: b3415925a08b ("crypto: riscv - add vector crypto accelerated SHA-{= 512,384}") > Fixes: 563a5255afa2 ("crypto: riscv - add vector crypto accelerated SM3") > Fixes: b8d06352bbf3 ("crypto: riscv - add vector crypto accelerated SM4") > Cc: stable@vger.kernel.org > Signed-off-by: Eric Biggers > --- > arch/riscv/crypto/Kconfig | 12 ++++++++---- > lib/crypto/Kconfig | 9 ++++++--- > 2 files changed, 14 insertions(+), 7 deletions(-) > > diff --git a/arch/riscv/crypto/Kconfig b/arch/riscv/crypto/Kconfig > index a75d6325607b..14c5acb935e9 100644 > --- a/arch/riscv/crypto/Kconfig > +++ b/arch/riscv/crypto/Kconfig > @@ -2,11 +2,12 @@ > > menu "Accelerated Cryptographic Algorithms for CPU (riscv)" > > config CRYPTO_AES_RISCV64 > tristate "Ciphers: AES, modes: ECB, CBC, CTS, CTR, XTS" > - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO > + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ > + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS > select CRYPTO_ALGAPI > select CRYPTO_LIB_AES > select CRYPTO_SKCIPHER > help > Block cipher: AES cipher algorithms > @@ -18,21 +19,23 @@ config CRYPTO_AES_RISCV64 > - Zvkb vector crypto extension (CTR) > - Zvkg vector crypto extension (XTS) > > config CRYPTO_GHASH_RISCV64 > tristate "Hash functions: GHASH" > - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO > + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ > + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS > select CRYPTO_GCM > help > GCM GHASH function (NIST SP 800-38D) > > Architecture: riscv64 using: > - Zvkg vector crypto extension > > config CRYPTO_SM3_RISCV64 > tristate "Hash functions: SM3 (ShangMi 3)" > - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO > + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ > + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS > select CRYPTO_HASH > select CRYPTO_LIB_SM3 > help > SM3 (ShangMi 3) secure hash function (OSCCA GM/T 0004-2012) > > @@ -40,11 +43,12 @@ config CRYPTO_SM3_RISCV64 > - Zvksh vector crypto extension > - Zvkb vector crypto extension > > config CRYPTO_SM4_RISCV64 > tristate "Ciphers: SM4 (ShangMi 4)" > - depends on 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTOR_CRYPTO > + depends on 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ > + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS > select CRYPTO_ALGAPI > select CRYPTO_SM4 > help > SM4 block cipher algorithm (OSCCA GB/T 32907-2016, > ISO/IEC 18033-3:2010/Amd 1:2021) > diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig > index a3647352bff6..6871a41e5069 100644 > --- a/lib/crypto/Kconfig > +++ b/lib/crypto/Kconfig > @@ -59,11 +59,12 @@ config CRYPTO_LIB_CHACHA_ARCH > depends on CRYPTO_LIB_CHACHA && !UML && !KMSAN > default y if ARM > default y if ARM64 && KERNEL_MODE_NEON > default y if MIPS && CPU_MIPS32_R2 > default y if PPC64 && CPU_LITTLE_ENDIAN && VSX > - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTO= R_CRYPTO > + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ > + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS > default y if S390 > default y if X86_64 > > config CRYPTO_LIB_CURVE25519 > tristate > @@ -182,11 +183,12 @@ config CRYPTO_LIB_SHA256_ARCH > depends on CRYPTO_LIB_SHA256 && !UML > default y if ARM && !CPU_V7M > default y if ARM64 > default y if MIPS && CPU_CAVIUM_OCTEON > default y if PPC && SPE > - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTO= R_CRYPTO > + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ > + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS > default y if S390 > default y if SPARC64 > default y if X86_64 > > config CRYPTO_LIB_SHA512 > @@ -200,11 +202,12 @@ config CRYPTO_LIB_SHA512_ARCH > bool > depends on CRYPTO_LIB_SHA512 && !UML > default y if ARM && !CPU_V7M > default y if ARM64 > default y if MIPS && CPU_CAVIUM_OCTEON > - default y if RISCV && 64BIT && RISCV_ISA_V && TOOLCHAIN_HAS_VECTO= R_CRYPTO > + default y if RISCV && 64BIT && TOOLCHAIN_HAS_VECTOR_CRYPTO && \ > + RISCV_EFFICIENT_VECTOR_UNALIGNED_ACCESS > default y if S390 > default y if SPARC64 > default y if X86_64 > > config CRYPTO_LIB_SHA3 > > base-commit: 43dfc13ca972988e620a6edb72956981b75ab6b0 > -- > 2.52.0 > Reviewed-by: Jerry Shih Thanks, -Jerry From - Tue Dec 09 09:18:44 2025 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id gFEpCnDpN2ndoR8AYBR5ng (envelope-from ) for ; Tue, 09 Dec 2025 09:18:40 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Tue, 09 Dec 2025 09:18:40 +0000 Received: from sin.lore.kernel.org ([104.64.211.4]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vStrj-000000093EI-2BMt for hi@josie.lol; Tue, 09 Dec 2025 09:18:40 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sin.lore.kernel.org (Postfix) with E