[no subject]
From: Unknown
Date: Fri Jun 06 2025 - 13:02:36 EST
Thanks,
Xin
Return-Path: <linux-kernel+bounces-667777-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 4544541E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:12:32 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 468103AF909
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:12:10 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 80C07212B3D;
Fri, 30 May 2025 08:12:26 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="Oe4l7A7c"
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2079.outbound.protection.outlook.com [40.107.243.79])
(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 DAAB6201100
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:12:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.243.79
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748592745; cv=fail; b=isCWaAE7V4ns758yz0RzATKNqh6eeZN9AxaSHK1hYFZUGf6PWmYKZtM6tbmSpD56P5nj9dVse6hhy286gXInx7CvEo6T2hJkkgTaxnLdH//LpMOB5jvI5ZP/JeneSDsNFKeg2HA/xhf6TwotQspABlt/0nDZllNZU8rKNZxrBjs=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748592745; c=relaxed/simple;
bh=DTd+714fJWJiRgISYeK1AuN/RB3jw0ooOb+4Bn48yIE=;
h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=J1ihOfCe7OUr8e3ei4l1MLKPei+2Cq3Wg9IK0dv9+cNMPqxzBgAIR72/ITwKNMI9I4d3285x8gjtQmrYEGNculE5GmB8MXZGp+bRBEx2LimSZC/FJSQPoBvfZKA270pGpnV/O9Eo7yu3bVAoafyENuNHpMCgKkTCCYTq2oSDQTA=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=Oe4l7A7c; arc=fail smtp.client-ip=40.107.243.79
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com
Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=TJEsuY4msEaEG/lRCr+XoykbfOLP3IjkjE32lfvuIEzg9R81Axi5janJGc5o5TuTz1IcGXGC1R4iaEmPdsm9cl/mkx4cNzlKEir8UKI2fGDScxUfZhD5UABJED+SKlbZ0Y/HL2u0vLhTO//CHSzEIkirjJqxmyRItP4EDR3PdgOAzU0iOxehcyb/hKs9kaRrGcalTSMJG9nM/fiak0hc5KNfudIdUou2F1NisW5NPx+rbyWGMrj0fD/an4bFRIU8yXiOrnOx28UQilZ076Obb1xqcj2rFPuuUGq+oIaYOSvc0L5D4HjHoOhzrbjlBCuDIArbHk2Mlj+zpJjg4QWzMg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=M7o79EXIklUQPr/PXSd7dXNPTMm2nzV9TODg39nojr4=;
b=kKSZKIHHhyB4uSpVvI5RFtYLhNAetkYaUvEHQr39kH/GpIm1lHR0tpcOEwKe0VDJMapBOtldB2WMhiEs6mm8xz9sR946VKFC/vc5jF6OPiKZJSfr3q63YN6Hv4iGcijWhWsaJO00sXdW2+pNwFK9LdLEIL4hzhDL2gP3OR6vHuUAN1l/sDpYbsmugAlVu+cEMnQxk61bBwjB9GwIiTEyI1tf1FSAtRydViubg7wfcVS1ghB6jG4uNPFY44U8sVqa3OrnHCv5yC0qXSZa9hI4PRFSLazYVkHcHGso3iOtdjy4yDlYR1Jnvv7lQUqN0qz994G2Krr6R6qd2HD+uI2nlg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
165.204.84.17) smtp.rcpttodomain=vger.kernel.org smtp.mailfrom=amd.com;
dmarc=pass (p=quarantine sp=quarantine pct=100) action=none
header.from=amd.com; dkim=none (message not signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=M7o79EXIklUQPr/PXSd7dXNPTMm2nzV9TODg39nojr4=;
b=Oe4l7A7cJvx8HP9VQjhXOH/XUV5d0BoxuwZkJWwUStWRtbRgOJjxxZHHu0HKfi10Np7hfsDBW0eLsN8zWrZBhEK3xh3D9kZ9gB5wUv4y+LYr4SWXckzNW/Yr+Y/Z3+x6Cfd53Yg5Wa6qA2pOZYyvFeQpJTomfb7hrAUbUwyCGDU=
Received: from CH0PR03CA0041.namprd03.prod.outlook.com (2603:10b6:610:b3::16)
by MW5PR12MB5598.namprd12.prod.outlook.com (2603:10b6:303:193::11) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8722.30; Fri, 30 May
2025 08:12:20 +0000
Received: from DS2PEPF00003445.namprd04.prod.outlook.com
(2603:10b6:610:b3:cafe::b5) by CH0PR03CA0041.outlook.office365.com
(2603:10b6:610:b3::16) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Fri,
30 May 2025 08:12:19 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17)
smtp.mailfrom=amd.com; dkim=none (message not signed)
header.d=none;dmarc=pass action=none header.from=amd.com;
Received-SPF: Pass (protection.outlook.com: domain of amd.com designates
165.204.84.17 as permitted sender) receiver=protection.outlook.com;
client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C
Received: from SATLEXMB04.amd.com (165.204.84.17) by
DS2PEPF00003445.mail.protection.outlook.com (10.167.17.72) with Microsoft
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.20.8769.18 via Frontend Transport; Fri, 30 May 2025 08:12:19 +0000
Received: from dcsm-trdripper1.amd.com (10.180.168.240) by SATLEXMB04.amd.com
(10.181.40.145) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Fri, 30 May
2025 03:12:16 -0500
From: Akshay Gupta <akshay.gupta@xxxxxxx>
To: <linux-kernel@xxxxxxxxxxxxxxx>
CC: <gregkh@xxxxxxxxxxxxxxxxxxx>, <arnd@xxxxxxxx>, <Anand.Umarji@xxxxxxx>,
Akshay Gupta <akshay.gupta@xxxxxxx>, Dan Carpenter
<dan.carpenter@xxxxxxxxxx>, Naveen Krishna Chatradhi
<naveenkrishna.chatradhi@xxxxxxx>
Subject: [PATCH] misc: amd-sbi: Address issues reported in smatch
Date: Fri, 30 May 2025 13:41:58 +0530
Message-ID: <20250530081158.121137-1-akshay.gupta@xxxxxxx>
X-Mailer: git-send-email 2.34.1
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com
(10.181.40.145)
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DS2PEPF00003445:EE_|MW5PR12MB5598:EE_
X-MS-Office365-Filtering-Correlation-Id: ce30cc28-a833-44ee-840a-08dd9f51b2e5
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
BCL:0;ARA:13230040|82310400026|376014|36860700013|1800799024|13003099007;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?IQRnzEsgL2/mI1fv6K0LRfRbDL4WCwJB3oWg+I55mqA1GWVnGMQQkj8/WTsG?=
=?us-ascii?Q?7J6+pC0qfcwJFxcIWPSZUNM7N8Nz7gE0ljxACDGxIxVOUphFk209aAeCSrh0?=
=?us-ascii?Q?ZSXTHdAaWjW2MEFPTO0l2vmHwsEDUBwjyTHFQFa2vzyIWx7qEYrXUi5oDNcp?=
=?us-ascii?Q?EoydXqR7yIZdvlRIGyhveZsH9T6ZOrbweXjweddj+eeR0Al3ystE07DyF+r1?=
=?us-ascii?Q?25x+oiOoMrZTl+GEmTxJzmizIhMkpVtoOL12nsa8QP+ODDUw6BavPu4DVhkp?=
=?us-ascii?Q?7LeMsW6K90eDpcHD1aDlTagbDtvk4SHAK9V6Uikpad4wSMlEc7IuqQUuxW43?=
=?us-ascii?Q?WtU00gpJkSkYaoE/BAe1CPUWoHQ4+6sYc2uenGUwt2gESaSE/ex37OwzJtN+?=
=?us-ascii?Q?IIwXuBP0lykPWT1CyMxi7ad8INqoOwjtNmj88wO9BCGcehzJIj/BfobGlJVI?=
=?us-ascii?Q?jJ2A8jxlfcJq/46UKT0gbtxZWmxsTMdK31mbrSujzgu23M3vwSYZ3ZqosCv9?=
=?us-ascii?Q?/2URUFg2VR6IePv/xyfmNhVj7E98mJ28GB+ylc8GcbTfJlRV0FOULQuMV8sv?=
=?us-ascii?Q?Um0twGR1wgsAR5gaOQMBbNYLEVN+G9GSBPSXvWfm2prE5CfNddafD8y8Ykt6?=
=?us-ascii?Q?66SpwOqEmsMIxNgBGRTeKJRlSCT6iRJ0d8OWsFC10kO4MuxGmVmMgzgB759M?=
=?us-ascii?Q?DkpxYGjR5kEuN3ok4vefPnw2b9bELGf5rz4rOIgRnZE0CfhER0dOu8dR0mx4?=
=?us-ascii?Q?bWVBoLO9oNen6Vo2xCkuh4Xr4U5grm3qTh5bxLOydmSlEnPJq037Yl9QbRhN?=
=?us-ascii?Q?0fNvKD9IySv4K5cL6sLtlJ1rv5R1vJyAneeZCSsE+qDP8nsEcKI6HsAseRNq?=
=?us-ascii?Q?kM6pTj6/4z5AXbxaThTA+Oku2KGIN9PofFO9cqJirGBwFwe3ybAJp22EDkDx?=
=?us-ascii?Q?TdyrQQvCMLxHhxG5tJLFXrpteVTcfVGEvHYfxAa2fB2qmI7ly8BOZEqfpltf?=
=?us-ascii?Q?/2HfmfJFaRcJ3N84Hxa2xX1dcfsaw9nluM3zDVPR/OMAzfEo4WXTX3j6Zka9?=
=?us-ascii?Q?ri9Kc+v/HA3T/vZg0oH8hMVt7SmfxOBMjQr7mN+ROsoO1QFhewXiTcuTW45k?=
=?us-ascii?Q?ygt7RqHpIUYYe5cTuP0GAqXsxVwNG+vu92ua+5dS+tf6AY7qD1mSNiDBvCAN?=
=?us-ascii?Q?EtmgUz7S9luEfS91cwhiuNJ81/XzdM2fhKZ1485Ytr5EVdrvgX7rVdl5iy43?=
=?us-ascii?Q?9fj+JJnBs4nHElfItr9kJCvAtfx7rbGo53nIFbhji7o1WJs5nDRQ06gctu9a?=
=?us-ascii?Q?vIj42xvGx+i8AdnEcAA4iqlEiCgMcsNTSSS/QM4YTdHWxKKAER2ptwbFrTZT?=
=?us-ascii?Q?gB5oQJ7uqeOCPcFF/BGtnJHmQpMa3rrZJ9lLFbE4d3FjfAKx8d81MhoNGLlJ?=
=?us-ascii?Q?SYi72CuJT5rCs5+QtWez1/otmE22pddmvAHuGXBk7FN7PXEg1/JNJb5CEWL7?=
=?us-ascii?Q?8cGJjwgvYkee6UCLkZ2S3bd/eZyPiEE2ehSO20/maVNoV8CDaIlhOC2Xtw?=
=?us-ascii?Q?=3D=3D?=
X-Forefront-Antispam-Report:
CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(82310400026)(376014)(36860700013)(1800799024)(13003099007);DIR:OUT;SFP:1101;
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:12:19.8237
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ce30cc28-a833-44ee-840a-08dd9f51b2e5
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com]
X-MS-Exchange-CrossTenant-AuthSource:
DS2PEPF00003445.namprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR12MB5598
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Smatch warnings are reported for below commit,
Commit bb13a84ed6b7 ("misc: amd-sbi: Add support for CPUID protocol")
from Apr 28, 2025 (linux-next), leads to the following Smatch static
checker warning:
drivers/misc/amd-sbi/rmi-core.c:132 rmi_cpuid_read() warn: bitwise OR is zero '0xffffffff00000000 & 0xffff'
drivers/misc/amd-sbi/rmi-core.c:132 rmi_cpuid_read() warn: potential integer overflow from user 'msg->cpu_in_out << 32'
drivers/misc/amd-sbi/rmi-core.c:213 rmi_mca_msr_read() warn: bitwise OR is zero '0xffffffff00000000 & 0xffff'
drivers/misc/amd-sbi/rmi-core.c:213 rmi_mca_msr_read() warn: potential integer overflow from user 'msg->mcamsr_in_out << 32'
drivers/misc/amd-sbi/rmi-core.c:376 apml_rmi_reg_xfer() warn: maybe return -EFAULT instead of the bytes remaining?
drivers/misc/amd-sbi/rmi-core.c:394 apml_mailbox_xfer() warn: maybe return -EFAULT instead of the bytes remaining?
drivers/misc/amd-sbi/rmi-core.c:411 apml_cpuid_xfer() warn: maybe return -EFAULT instead of the bytes remaining?
drivers/misc/amd-sbi/rmi-core.c:428 apml_mcamsr_xfer() warn: maybe return -EFAULT instead of the bytes remaining?
copy_to/from_user() returns number of bytes, not copied.
In case data not copied, return "-EFAULT".
CPUID thread data from input is available at byte 4 & 5, this
patch fixes to copy the user data correctly in the argument.
Reported-by: Dan Carpenter <dan.carpenter@xxxxxxxxxx>
Closes: https://lore.kernel.org/all/aDVyO8ByVsceybk9@stanley.mountain/
Reviewed-by: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@xxxxxxx>
Signed-off-by: Akshay Gupta <akshay.gupta@xxxxxxx>
---
This patch is created on top of linux-next
drivers/misc/amd-sbi/rmi-core.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/amd-sbi/rmi-core.c b/drivers/misc/amd-sbi/rmi-core.c
index b653a21a909e..9048517c088c 100644
--- a/drivers/misc/amd-sbi/rmi-core.c
+++ b/drivers/misc/amd-sbi/rmi-core.c
@@ -42,7 +42,6 @@
#define RD_MCA_CMD 0x86
/* CPUID MCAMSR mask & index */
-#define CPUID_MCA_THRD_MASK GENMASK(15, 0)
#define CPUID_MCA_THRD_INDEX 32
#define CPUID_MCA_FUNC_MASK GENMASK(31, 0)
#define CPUID_EXT_FUNC_INDEX 56
@@ -129,7 +128,7 @@ static int rmi_cpuid_read(struct sbrmi_data *data,
goto exit_unlock;
}
- thread = msg->cpu_in_out << CPUID_MCA_THRD_INDEX & CPUID_MCA_THRD_MASK;
+ thread = msg->cpu_in_out >> CPUID_MCA_THRD_INDEX;
/* Thread > 127, Thread128 CS register, 1'b1 needs to be set to 1 */
if (thread > 127) {
@@ -210,7 +209,7 @@ static int rmi_mca_msr_read(struct sbrmi_data *data,
goto exit_unlock;
}
- thread = msg->mcamsr_in_out << CPUID_MCA_THRD_INDEX & CPUID_MCA_THRD_MASK;
+ thread = msg->mcamsr_in_out >> CPUID_MCA_THRD_INDEX;
/* Thread > 127, Thread128 CS register, 1'b1 needs to be set to 1 */
if (thread > 127) {
@@ -373,7 +372,8 @@ static int apml_rmi_reg_xfer(struct sbrmi_data *data,
mutex_unlock(&data->lock);
if (msg.rflag && !ret)
- return copy_to_user(arg, &msg, sizeof(struct apml_reg_xfer_msg));
+ if (copy_to_user(arg, &msg, sizeof(struct apml_reg_xfer_msg)))
+ return -EFAULT;
return ret;
}
@@ -391,7 +391,9 @@ static int apml_mailbox_xfer(struct sbrmi_data *data, struct apml_mbox_msg __use
if (ret && ret != -EPROTOTYPE)
return ret;
- return copy_to_user(arg, &msg, sizeof(struct apml_mbox_msg));
+ if (copy_to_user(arg, &msg, sizeof(struct apml_mbox_msg)))
+ return -EFAULT;
+ return ret;
}
static int apml_cpuid_xfer(struct sbrmi_data *data, struct apml_cpuid_msg __user *arg)
@@ -408,7 +410,9 @@ static int apml_cpuid_xfer(struct sbrmi_data *data, struct apml_cpuid_msg __user
if (ret && ret != -EPROTOTYPE)
return ret;
- return copy_to_user(arg, &msg, sizeof(struct apml_cpuid_msg));
+ if (copy_to_user(arg, &msg, sizeof(struct apml_cpuid_msg)))
+ return -EFAULT;
+ return ret;
}
static int apml_mcamsr_xfer(struct sbrmi_data *data, struct apml_mcamsr_msg __user *arg)
@@ -425,7 +429,9 @@ static int apml_mcamsr_xfer(struct sbrmi_data *data, struct apml_mcamsr_msg __us
if (ret && ret != -EPROTOTYPE)
return ret;
- return copy_to_user(arg, &msg, sizeof(struct apml_mcamsr_msg));
+ if (copy_to_user(arg, &msg, sizeof(struct apml_mcamsr_msg)))
+ return -EFAULT;
+ return ret;
}
static long sbrmi_ioctl(struct file *fp, unsigned int cmd, unsigned long arg)
--
2.34.1
Return-Path: <linux-kernel+bounces-667778-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 8F95641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:14:18 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id B24BF4E0B0E
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:14:19 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id F1BF121516E;
Fri, 30 May 2025 08:14:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="TF/07tm3"
Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200])
(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 A5E88201100;
Fri, 30 May 2025 08:14:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.200
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748592851; cv=none; b=amfpKGJoJL2xKGDRb/2spl7UKIPOw/fojDsBdsHE9dz9d4GAIPuiqH4JBugUFxwIAk5Z09SD0H6u05WIK+LdDdrCIN+A1b3I56dvzEwccQyftfrqigzYa1IFCMbhR7Rq9pAlUiHJ9RWioCVAE7NJ39RHwsA+oTIPRz8xSkTy50I=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748592851; c=relaxed/simple;
bh=9gfz7FNlnlPQa0RX08i9oh06Ar+H+M5d397F0opYhK4=;
h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
MIME-Version:Content-Type; b=twKEOWE+F2GxLhwsxCfeii6OEjayz9c3lMC2A0mai/OJ86VIP6SRox9R4mCpMH/uGDUVNgxDlfg5ZmsfuP8gSYDtI5bZGUVnCmjPqCilhzGEyPB0DWfBRYlzPIautQb9Ujqk5mbSbvWJDmjVaM7zgcRRW9zQb1gfsz3hQTfZrCw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=TF/07tm3; arc=none smtp.client-ip=217.70.183.200
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com
Received: by mail.gandi.net (Postfix) with ESMTPSA id 6FA944320D;
Fri, 30 May 2025 08:13:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1;
t=1748592841;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=1bix+Ruw+wPci3KYFlUL37xO5WCvyArPLnYLDXh61UA=;
b=TF/07tm3Brkat4LBtqhni0OfExGBjdhEdkjh8dL5vNB4CG16F12er25ZpchuTGcYpAhF9T
Sj4OTP1v89rd+DAnEO9a2T0nRmwEcx82QY8QKEG9X/xXPNR4E2BdyeHw1fpMVcNOE6it7t
sKd/jH53FUNsivo04UgnC3f8SGrJnpFNhES7xzD3DtR/zOT4QhF1hRW6xeAGe5bbvxwwo6
ijWPVCH8L7L9JthgwB1siIX/7c0fEFyrdVWTQMtNLtoHQ23IdLBOHKbpc5Mw/g043mBaVV
4NcryO6nCvgrSjFi/cs7wvCQPBhrmYzJV7uzYf+sj8J+fOow1vjCLb02rV3k2A==
From: Romain Gantois <romain.gantois@xxxxxxxxxxx>
To: Wolfram Sang <wsa@xxxxxxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
Cc: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>,
Hans Verkuil <hverkuil@xxxxxxxxx>, Jai Luthra <jai.luthra@xxxxxxxxxxxxxxxx>,
Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>,
Linux Next Mailing List <linux-next@xxxxxxxxxxxxxxx>,
Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>,
Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx>,
Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx>
Subject: Re: linux-next: manual merge of the v4l-dvb tree with the i2c tree
Date: Fri, 30 May 2025 10:13:58 +0200
Message-ID: <3352024.aeNJFYEL58@fw-rgant>
In-Reply-To: <20250529124929.5217c6d9@xxxxxxxxxxxxxxxx>
References:
<20250428104905.2b54643f@xxxxxxxxxxxxxxxx>
<20250428113052.38cf10da@xxxxxxxxxxxxxxxx>
<20250529124929.5217c6d9@xxxxxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3358454.44csPzL39Z";
micalg="pgp-sha512"; protocol="application/pgp-signature"
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvkeehtdculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfgggtsehgtderredttdejnecuhfhrohhmpeftohhmrghinhcuifgrnhhtohhishcuoehrohhmrghinhdrghgrnhhtohhishessghoohhtlhhinhdrtghomheqnecuggftrfgrthhtvghrnhephfdvleekvefgieejtdduieehfeffjefhleegudeuhfelteduiedukedtieehlefgnecuffhomhgrihhnpegsohhothhlihhnrdgtohhmnecukfhppeeltddrkeelrdduieefrdduvdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledtrdekledrudeifedruddvjedphhgvlhhopehffidqrhhgrghnthdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhomhgrihhnrdhgrghnthhoihhssegsohhothhlihhnrdgtohhmpdhnsggprhgtphhtthhopedutddprhgtphhtthhopeifshgrsehthhgvqdgurhgvrghmshdruggvpdhrtghpthhtohepshhfrhestggrnhgsrdgruhhughdrohhrghdrrghupdhrtghpthhtohepmhgthhgvhhgrsgeskhgvrhhnvghlrdhorhhgpdhrtghpthhtohephhhvvghrkhhuihhlseigshegrghllhdrnhhlpdhrtghpt
hhtohepjhgrihdrlhhuthhhrhgrsehiuggvrghsohhnsghorghrugdrtghomhdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihhnuhigqdhnvgigthesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehsrghkrghrihdrrghilhhusheslhhinhhugidrihhnthgvlhdrtghomh
X-GND-Sasl: romain.gantois@xxxxxxxxxxx
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
--nextPart3358454.44csPzL39Z
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Romain Gantois <romain.gantois@xxxxxxxxxxx>
Date: Fri, 30 May 2025 10:13:58 +0200
Message-ID: <3352024.aeNJFYEL58@fw-rgant>
In-Reply-To: <20250529124929.5217c6d9@xxxxxxxxxxxxxxxx>
MIME-Version: 1.0
Hi Stephen,
On Thursday, 29 May 2025 04:49:29 CEST Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 28 Apr 2025 11:30:52 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
wrote:
> > On Mon, 28 Apr 2025 11:22:00 +1000 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
wrote:
> > > On Mon, 28 Apr 2025 10:49:05 +1000 Stephen Rothwell
<sfr@xxxxxxxxxxxxxxxx> wrote:
> > > > Today's linux-next merge of the v4l-dvb tree got a conflict in:
> > > > drivers/media/i2c/ds90ub960.c
> > > >
> > > > between commits:
> > > > 3ec29d51b546 ("media: i2c: ds90ub960: Protect alias_use_mask with a
> > > > mutex")
> > > > 818bd489f137 ("i2c: use client addresses directly in ATR interface")
> > > >
> > > > from the i2c tree and commits:
> > > > 24868501a744 ("media: i2c: ds90ub9xx: Add err parameter to
> > > > read/write funcs") 2ca499384e98 ("media: i2c: ds90ub960: Add RX
> > > > port iteration support")> > >
> > > > from the v4l-dvb tree.
> > > >
> > > > I fixed it up (see below) and can carry the fix as necessary. This
> > > > is now fixed as far as linux-next is concerned, but any non trivial
> > > > conflicts should be mentioned to your upstream maintainer when your
> > > > tree
> > > > is submitted for merging. You may also want to consider cooperating
> > > > with the maintainer of the conflicting tree to minimise any
> > > > particularly
> > > > complex conflicts.
> > >
> > > The actual resolution is below ...
> >
> > I hit the wrong key :-( Resolution below.
>
> This is now a conflict between the i2c tree and Linus' tree.
Below is the resolution I came up with.
Thanks,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
diff --cc drivers/media/i2c/ds90ub960.c
index ed9ace1a54766,94b20ba6cb86f..54c2546551451
--- a/drivers/media/i2c/ds90ub960.c
+++ b/drivers/media/i2c/ds90ub960.c
@@@ -1271,10 -1056,11 +1274,12 @@@ static int ub960_atr_attach_addr(struc
struct ub960_rxport *rxport = priv->rxports[chan_id];
struct device *dev = &priv->client->dev;
unsigned int reg_idx;
+ int ret = 0;
- for (reg_idx = 0; reg_idx < ARRAY_SIZE(rxport->aliased_clients);
reg_idx++) {
- if (!rxport->aliased_clients[reg_idx])
+ guard(mutex)(&rxport->aliased_addrs_lock);
+
+ for (reg_idx = 0; reg_idx < ARRAY_SIZE(rxport->aliased_addrs);
reg_idx++) {
+ if (!rxport->aliased_addrs[reg_idx])
break;
}
@@@ -1283,18 -1069,15 +1288,18 @@@
return -EADDRNOTAVAIL;
}
- rxport->aliased_clients[reg_idx] = client;
+ rxport->aliased_addrs[reg_idx] = addr;
ub960_rxport_write(priv, chan_id, UB960_RR_SLAVE_ID(reg_idx),
- client->addr << 1, &ret);
- addr << 1);
++ addr << 1, &ret);
ub960_rxport_write(priv, chan_id, UB960_RR_SLAVE_ALIAS(reg_idx),
- alias << 1);
+ alias << 1, &ret);
+
+ if (ret)
+ return ret;
dev_dbg(dev, "rx%u: client 0x%02x assigned alias 0x%02x at slot %u\n",
- rxport->nport, client->addr, alias, reg_idx);
+ rxport->nport, addr, alias, reg_idx);
return 0;
}
@@@ -1306,10 -1089,11 +1311,12 @@@ static void ub960_atr_detach_addr(struc
struct ub960_rxport *rxport = priv->rxports[chan_id];
struct device *dev = &priv->client->dev;
unsigned int reg_idx;
+ int ret;
- for (reg_idx = 0; reg_idx < ARRAY_SIZE(rxport->aliased_clients);
reg_idx++) {
- if (rxport->aliased_clients[reg_idx] == client)
+ guard(mutex)(&rxport->aliased_addrs_lock);
+
+ for (reg_idx = 0; reg_idx < ARRAY_SIZE(rxport->aliased_addrs);
reg_idx++) {
+ if (rxport->aliased_addrs[reg_idx] == addr)
break;
}
@@@ -1319,18 -1103,12 +1326,18 @@@
return;
}
- rxport->aliased_clients[reg_idx] = NULL;
+ rxport->aliased_addrs[reg_idx] = 0;
- ub960_rxport_write(priv, chan_id, UB960_RR_SLAVE_ALIAS(reg_idx), 0);
+ ret = ub960_rxport_write(priv, chan_id, UB960_RR_SLAVE_ALIAS(reg_idx),
+ 0, NULL);
+ if (ret) {
+ dev_err(dev, "rx%u: unable to fully unmap client 0x%02x:
%d\n",
+ rxport->nport, client->addr, ret);
+ return;
+ }
dev_dbg(dev, "rx%u: client 0x%02x released at slot %u\n", rxport-
>nport,
- client->addr, reg_idx);
+ addr, reg_idx);
}
static const struct i2c_atr_ops ub960_atr_ops = {
@@@ -4370,12 -3231,21 +4376,14 @@@ static void ub960_txport_free_ports(str
static void ub960_rxport_free_ports(struct ub960_data *priv)
{
- unsigned int nport;
-
- for (nport = 0; nport < priv->hw_data->num_rxports; nport++) {
- struct ub960_rxport *rxport = priv->rxports[nport];
-
- if (!rxport)
- continue;
-
- fwnode_handle_put(rxport->source.ep_fwnode);
- fwnode_handle_put(rxport->ser.fwnode);
+ for_each_active_rxport(priv, it) {
+ fwnode_handle_put(it.rxport->source.ep_fwnode);
+ fwnode_handle_put(it.rxport->ser.fwnode);
+ mutex_destroy(&rxport->aliased_addrs_lock);
+
- kfree(rxport);
- priv->rxports[nport] = NULL;
+ kfree(it.rxport);
+ priv->rxports[it.nport] = NULL;
}
}
--nextPart3358454.44csPzL39Z
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEYFZBShRwOvLlRRy+3R9U/FLj284FAmg5aMYACgkQ3R9U/FLj
284oJQ//TbMI7doophWpEFkBg7MGGXW09i7W/r923E3m0ot9mMk+0yOaqSlj9jm3
3oiMIP0MH0cN8GUzWJq53qIINJ2DkyDD6LAoiFZajSilF+mSKqRtxuAt6iVSXJjE
XNh41qrU4jN3LhedOYuDP5NaDHsZ9SyEuSCppSrrigjI1Uslefm9ocKcPoAcbHpn
ybDLXMXT9yLaGCt232X4wSO+xOelahWqHICZTPdnQZ9lRQ4wI5KpQ9VJOvsLfNd+
3ZWfBr3Ny8uW8hS9RB70bCFR2cFc0rRlZjE1BEVuEB8axkMwNaRNeu+aYO+s4JKO
EWt0CT5Qg3hbUxzqEGUzLDaixXgtP+dzIbTXebTf3OqDaZwGdecIxIMmuLp3MJMN
NTF88Mm3FMifcZgmTLwJ3BO98BvbE/xzBvWH0pOxVY9wM0xESkkcTkNuibPwbIE0
gOzFc7pKo7xoIyzIfx6sR5lbPL59w+fnkS+N1rJIVNIczX7ma3CUqMN7jSCTEh4b
TJHmjgAscrKP7rQatuRpZRZUGHoSaKlw+o8BCk32PmDrofv0a8EnVudXHGPLuadt
9e8+lxJ4VGgM/eXz2LCsnPOp38oVCinO+zfR7vMnw2PgBGb4s/Ntja3OD6qi099a
4kGpx7fkWajtCSHRJsNCBgUMDboU4+uG3R0JzrD7mJ6lGAIf1vQ=
=/BQv
-----END PGP SIGNATURE-----
--nextPart3358454.44csPzL39Z--
Return-Path: <linux-kernel+bounces-667779-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 1ABCD41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:19:52 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id BFEA31BA4A2A
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:20:04 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 94AB3211A05;
Fri, 30 May 2025 08:19:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="GCHrJGfM";
dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="2nchBfLO";
dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="NoubhwMO";
dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="bQmANJWM"
Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130])
(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 0711320E021
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:19:40 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593183; cv=none; b=GJrvO60BNalkdh96z2I3YnFjzMgt2Rc5tD382U5+5HtHyTRkE7g+IPmBkK83JkdIp+zKr416uCz7CWbpDIoa9zLLAmmEkpU+0jC28SAVymZHQaRgUFg8juLKVFXf1ICcnI0V285uVlcuF0ACiHwtkbmgRVIhrASQxGEjIIl7RZY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593183; c=relaxed/simple;
bh=6jH5/IL8ffkIQd0Vg5++x+rxmjnm2YUzs0Ud+NSLgoo=;
h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:
Content-Disposition; b=sRHnntaSZQV5FZg6tz72xTqZJAnkdY5MAw0gvtEBy1pkJ+oJzDtSjbtgsN7CuRBOZ3tseYgjqXTsv1zg10NUZnj4nw2/CUPlaSj4qe6Yf8Mnx9IxhsGx/oUG/LlcvT5IV4r/M2AWdzAfZ3tdXLetr8/SGO1ZW2QPCFCKTMKsBYQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz; spf=pass smtp.mailfrom=suse.cz; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=GCHrJGfM; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=2nchBfLO; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=NoubhwMO; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=bQmANJWM; arc=none smtp.client-ip=195.135.223.130
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.cz
Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by smtp-out1.suse.de (Postfix) with ESMTPS id D8F57218B1;
Fri, 30 May 2025 08:19:38 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
t=1748593179; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=KFI5NHJKY/0el5JaAfXoAK3KyJ42W3kIxArkoFHkeyE=;
b=GCHrJGfMBcoba5SHUiu8a5s9oGfxjILqRURdB4ap7+OUl8fjZ52bAm4kpy2tfyMHpOSkX9
52H6A9IqNdeJbw4NMHYMVD+8g7wjC+84w8COfwqDvDBPD9kwVre+YDMnHaRcNjkS1fCp9J
mCSqsn9bpTi7eUC+Usxb1RvKGe1zB2U=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
s=susede2_ed25519; t=1748593179;
h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=KFI5NHJKY/0el5JaAfXoAK3KyJ42W3kIxArkoFHkeyE=;
b=2nchBfLOjVdog81OpQvtjBnJjvN5xR9TRkGm7wYWna+qpuvSSf31FjwpUAYCrpJetliSmP
KBCPBrFPeAczNoDA==
Authentication-Results: smtp-out1.suse.de;
dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=NoubhwMO;
dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=bQmANJWM
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa;
t=1748593178; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=KFI5NHJKY/0el5JaAfXoAK3KyJ42W3kIxArkoFHkeyE=;
b=NoubhwMO2TfdQeZpMEESj8K6Sf+PFUmPcp0HeMyXRP4wGlokS/7A5TFMCOv1lRrU/0NURd
pEicoF+iGOGCkjwSEvlW5AubJ2p3gC6hY5+GBTlBHiEayCW9najtwLPFV9BLdmeJJwM+km
8/sL3DnGfQ2TSDqJplkD/f6QVgLn1QY=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz;
s=susede2_ed25519; t=1748593178;
h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=KFI5NHJKY/0el5JaAfXoAK3KyJ42W3kIxArkoFHkeyE=;
b=bQmANJWMwKsynlEa9sgLwX/C8may7pWQTpXTg8rVDLN/QfhuBUvg4y+ot5v5Ux3X/uWgEk
DwcDZuELuHBTQJAg==
Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
(No client certificate requested)
by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id C6EC913889;
Fri, 30 May 2025 08:19:38 +0000 (UTC)
Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167])
by imap1.dmz-prg2.suse.org with ESMTPSA
id 2SQ8MBpqOWihXQAAD6G6ig
(envelope-from <chrubis@xxxxxxx>); Fri, 30 May 2025 08:19:38 +0000
Date: Fri, 30 May 2025 10:20:08 +0200
From: Cyril Hrubis <chrubis@xxxxxxx>
To: ltp@xxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
libc-alpha@xxxxxxxxxxxxxx,
valgrind-developers@xxxxxxxxxxxxxxxxxxxxx
Cc: lwn@xxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, torvalds@xxxxxxxxxxxxxxxxxxxx
Subject: [ANNOUNCE] The Linux Test Project has been released for MAY 2025
Message-ID: <aDlqOKWSZTzGqrsN@xxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Spamd-Result: default: False [-4.51 / 50.00];
BAYES_HAM(-3.00)[100.00%];
NEURAL_HAM_LONG(-1.00)[-1.000];
R_DKIM_ALLOW(-0.20)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];
NEURAL_HAM_SHORT(-0.20)[-1.000];
MIME_GOOD(-0.10)[text/plain];
MX_GOOD(-0.01)[];
DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,imap1.dmz-prg2.suse.org:rdns];
ARC_NA(0.00)[];
MISSING_XM_UA(0.00)[];
RCVD_VIA_SMTP_AUTH(0.00)[];
MIME_TRACE(0.00)[0:+];
RCPT_COUNT_SEVEN(0.00)[7];
RCVD_TLS_ALL(0.00)[];
SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from];
FROM_EQ_ENVFROM(0.00)[];
FROM_HAS_DN(0.00)[];
FUZZY_BLOCKED(0.00)[rspamd.com];
RCVD_COUNT_TWO(0.00)[2];
TO_MATCH_ENVRCPT_ALL(0.00)[];
TO_DN_NONE(0.00)[];
DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519];
DKIM_TRACE(0.00)[suse.cz:+]
X-Spam-Level:
X-Rspamd-Queue-Id: D8F57218B1
X-Rspamd-Action: no action
X-Rspamd-Server: rspamd1.dmz-prg2.suse.org
X-Spam-Score: -4.51
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Good news everyone,
the Linux Test Project test suite stable release for *May 2025* has been
released.
Since the last release 282 patches by 33 authors were merged.
Patch review is what most of the projects struggle with and LTP is no
different. If you can spare some effort helping with the patch review is more
than welcomed.
NOTABLE CHANGES
===============
* New tests
- kvm_vmx01 test for emulated VMREAD/VMWRITE instructions
- kvm_vmx02 test for Intel VMX virtualized APIC
- flock07 test for EINTR error
- move_mount03 test for mount beneath top mount
- fanotify24 test for FAN_PRE_ACCESS and FAN_DENY_ERRNO
- unshare03 check for EMFILE when unsharing fd would hit the limits
- fcntl40 test fcntl F_CREATED_QUERY
- ioctl_fiemap01 functionality test for fiemap ioctl()
- unshare04 tests that unshare(CLONE_NEWNS) unshares CWD
- mmap22 test for new MAP_DROPPABLE flag
* Increased coverage
- fanotify13 test case for FAN_DELETE_SELF
- fanotify05 test reporting overflow event with FAN_REPORT_FD_ERROR
- fanotify21 test reporting event with RDWR fd on RO mount
- fanotify21 test reporting fd open errors with FAN_REPORT_FD_ERROR
- flock02 test for EWOULDBLOCK errno
- fchownat03 more tests for invalid inputs
- fanotify14 test invalid init flags with permission and pre-content events
- fanotify03 test cases for permission events on children
- pause01 tests now for more signals not just EINTR
- setrlimit06 test resource limit64 for process
* Removed tests
- The test_controllers.sh is now disabled when v2 hierarchy is present
- A few old and broken tests were removed from test_controllers.sh
* kirk was updated to version 2.1 see the release notes at:
https://github.com/linux-test-project/kirk/releases
* New test catalogue generated from test metadata is live at:
https://linux-test-project.readthedocs.io/en/latest/users/test_catalog.html
* We have a new metadata extractor for a shell and first test that is parsed:
https://linux-test-project.readthedocs.io/en/latest/users/test_catalog.html#vma05-sh
* A few tests have been fixed not to be miscompiled by gcc-15
- we had problems with changes in structure zero initializations where
suddenly anonymous unions were not zero initialized anymore
- and also with optimzer changes that now remove malloc() + free() pairs
if the memmory is no touched between the calls
* The tst_brk() behavior has finally been clarified and fixed, for details see
LTP commit a1f82704c28d ("lib/tst_test.c: Fix tst_brk() handling").
* New library test now have reproducible output that leaves out data that
change between runs from the output, it's enabled with setting env variable
LTP_REPRODUCIBLE_OUTPUT=1
* Our github CI is now connected to patchwork and runs LTP
compilation tests for patches:
https://patchwork.ozlabs.org/project/ltp/list/
* The LTP_SINGLE_FS_TYPE now honors test specific filesystem skiplists and thus
can be used for general testing. There is new variable
TST_FORCE_SINGLE_FS_TYPE that ignores skiplists and is supposed to be used
for test development (which was previously the case for LTP_SINGLE_FS_TYPE).
* The ipc runtest file that cointained only pipeio test was merged into
syscalls runtest file
* The horrible mess in testcases/kernel/mem/lib/ library was untangled into
smaller pieces
* 43 testcases were converted to the new test library
+ The usual amount of fixes and cleanups
NOTABLE CHANGES IN IMA TESTS
============================
brought to you by Petr Vorel
* Add support to load predefined example IMA policy with LTP_IMA_LOAD_POLICY=1
environment variable.
This allows to run tests which are otherwise skipped due required policy not
being loaded. SUT should be rebooted after each IMA tests (unless
CONFIG_IMA_WRITE_POLICY=y` the policy can be written only once or policies
can influence each other).
* Added additional ToMToU and open-writer violation tests (new in kernel v6.14)
* IMA: Allow to disable LSM warnings and use it for IMA (avoid misleading warnings)
+ Add some example IMA policies
DOWNLOAD AND LINKS
==================
The latest version of the test-suite contains 3000+ tests for the Linux
and can be downloaded at:
https://github.com/linux-test-project/ltp/releases/tag/20250530
The project pages as well as GIT repository are hosted on GitHub:
https://github.com/linux-test-project/ltp
If you ever wondered how to write a LTP testcase, don't miss our developer
documentation at:
https://linux-test-project.readthedocs.io/en/latest/developers/test_case_tutorial.html
And our library API documentation at:
https://linux-test-project.readthedocs.io/en/latest/developers/api_c_tests.html
Patches, new tests, bugs, comments or questions should go to to our mailing
list at ltp@xxxxxxxxxxxxxx.
CREDITS
=======
Many thanks to the people contributing to this release:
git shortlog -s -e -n 20250130..
80 Petr Vorel <pvorel@xxxxxxx>
25 Cyril Hrubis <chrubis@xxxxxxx>
24 Ricardo B. Marlière <rbm@xxxxxxxx>
22 Martin Doucha <mdoucha@xxxxxxx>
21 Andrea Cervesato <andrea.cervesato@xxxxxxxx>
17 Ma Xinjian via ltp <ltp@xxxxxxxxxxxxxx>
14 Li Wang <liwang@xxxxxxxxxx>
13 Amir Goldstein <amir73il@xxxxxxxxx>
11 Xinjian Ma (Fujitsu) <maxj.fnst@xxxxxxxxxxx>
10 Jan Stancek <jstancek@xxxxxxxxxx>
10 Wei Gao <wegao@xxxxxxxx>
5 Mimi Zohar <zohar@xxxxxxxxxxxxx>
4 Shiyang Ruan <ruansy.fnst@xxxxxxxxxxx>
3 Avinesh Kumar <akumar@xxxxxxx>
3 Jeff Moyer <jmoyer@xxxxxxxxxx>
2 Edward Liaw <edliaw@xxxxxxxxxx>
2 lufei <lufei@xxxxxxxxxxxxx>
1 Ajay Kaher <ajay.kaher@xxxxxxxxxxxx>
1 Binh Hoang <htb511@xxxxxxxxx>
1 Dan Carpenter <dan.carpenter@xxxxxxxxxx>
1 Jan Polensky <japo@xxxxxxxxxxxxx>
1 Jin Guojie <guojie.jin@xxxxxxxxx>
1 John Morin <John.Morin@xxxxxxxxx>
1 Li Xiaosong <rj45usb@xxxxxxx>
1 Luiz Capitulino <luizcap@xxxxxxxxxx>
1 Ross Burton <ross.burton@xxxxxxx>
1 Siddhesh Poyarekar <siddhesh@xxxxxxxxxx>
1 Stuart R. Anderson <anderson@xxxxxxxxxxxx>
1 T.J. Mercier <tjmercier@xxxxxxxxxx>
1 Xiao Liang <xiliang@xxxxxxxxxx>
1 Zhao Mengmeng <zhaomengmeng@xxxxxxxxxx>
1 dy455990 <dy455990@xxxxxxxxxxxxxxx>
1 wangxuewen <wangxuewen@xxxxxxxxxx>
And also thanks to patch reviewers:
git log 20250130.. | grep -Ei '(reviewed|acked)-by:' | sed 's/.*by: //' | sort | uniq -c | sort -n -r
108 Petr Vorel <pvorel@xxxxxxx>
71 Andrea Cervesato <andrea.cervesato@xxxxxxxx>
62 Cyril Hrubis <chrubis@xxxxxxx>
53 Li Wang <liwang@xxxxxxxxxx>
11 Mimi Zohar <zohar@xxxxxxxxxxxxx>
9 Martin Doucha <mdoucha@xxxxxxx>
7 Jan Stancek <jstancek@xxxxxxxxxx>
7 Ricardo B. Marlière <ricardo@xxxxxxxxxxxx>
6 Jan Kara <jack@xxxxxxx>
5 Avinesh Kumar <akumar@xxxxxxx>
--
Cyril Hrubis
chrubis@xxxxxxx
Return-Path: <linux-kernel+bounces-667780-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id C0DBF41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:20:38 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 251471BA4565
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:20:52 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 4838F2135DD;
Fri, 30 May 2025 08:20:32 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id A5F7C1DE884
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:20:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593231; cv=none; b=IFB5f1HfG/y1vg66grdOh1lMn++u1Bd1zZ9sUgX1wJOQElNKbL9V52KlT9G5NS04aJftXB03Q2QEpyFNLXzIacgwKVLHtjZwRuZ3HTvH7HJmtcM9oKCRGo7pfirNGilTd5vfeL38E2UIaokWHokFtcEvaxkajyGuwmkX21NFYaI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593231; c=relaxed/simple;
bh=cb9ZM8+asV8O9lyMUSgIdJT/Pxowzq9mQ6RFl/e6SGo=;
h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=F1XtEFF5aYZgfGSgOGQdsTbVdyEf/1h83o/VNorlFNPpgVygQjzKzCquxipsSsVgcsYYhSvqtZe0CKDyljrQMhHKSW8UOl0ZsDIRmJFOcrz7IZuvR4KjOEMhBMLjQQHbUkxrevDPr63MHNk1cBCEl0GLJMyuNYxXsPujATrHOw0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 57A0516F8;
Fri, 30 May 2025 01:20:12 -0700 (PDT)
Received: from MacBook-Pro.blr.arm.com (unknown [10.164.18.49])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 1D82D3F694;
Fri, 30 May 2025 01:20:24 -0700 (PDT)
From: Dev Jain <dev.jain@xxxxxxx>
To: catalin.marinas@xxxxxxx,
will@xxxxxxxxxx
Cc: anshuman.khandual@xxxxxxx,
quic_zhenhuah@xxxxxxxxxxx,
ryan.roberts@xxxxxxx,
kevin.brodsky@xxxxxxx,
yangyicong@xxxxxxxxxxxxx,
joey.gouly@xxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
Dev Jain <dev.jain@xxxxxxx>
Subject: [PATCH] arm64: Enable vmalloc-huge with ptdump
Date: Fri, 30 May 2025 13:50:21 +0530
Message-Id: <20250530082021.18182-1-dev.jain@xxxxxxx>
X-Mailer: git-send-email 2.39.3 (Apple Git-146)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
arm64 disables vmalloc-huge when kernel page table dumping is enabled,
because an intermediate table may be removed, potentially causing the
ptdump code to dereference an invalid address. We want to be able to
analyze block vs page mappings for kernel mappings with ptdump, so to
enable vmalloc-huge with ptdump, synchronize between page table removal in
pmd_free_pte_page()/pud_free_pmd_page() and ptdump pagetable walking. We
use mmap_read_lock and not write lock because we don't need to synchronize
between two different vm_structs; two vmalloc objects running this same
code path will point to different page tables, hence there is no race.
Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
---
arch/arm64/include/asm/vmalloc.h | 6 ++----
arch/arm64/mm/mmu.c | 7 +++++++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
index 38fafffe699f..28b7173d8693 100644
--- a/arch/arm64/include/asm/vmalloc.h
+++ b/arch/arm64/include/asm/vmalloc.h
@@ -12,15 +12,13 @@ static inline bool arch_vmap_pud_supported(pgprot_t prot)
/*
* SW table walks can't handle removal of intermediate entries.
*/
- return pud_sect_supported() &&
- !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
+ return pud_sect_supported();
}
#define arch_vmap_pmd_supported arch_vmap_pmd_supported
static inline bool arch_vmap_pmd_supported(pgprot_t prot)
{
- /* See arch_vmap_pud_supported() */
- return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
+ return true;
}
#endif
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index ea6695d53fb9..798cebd9e147 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1261,7 +1261,11 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
}
table = pte_offset_kernel(pmdp, addr);
+
+ /* Synchronize against ptdump_walk_pgd() */
+ mmap_read_lock(&init_mm);
pmd_clear(pmdp);
+ mmap_read_unlock(&init_mm);
__flush_tlb_kernel_pgtable(addr);
pte_free_kernel(NULL, table);
return 1;
@@ -1289,7 +1293,10 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
pmd_free_pte_page(pmdp, next);
} while (pmdp++, next += PMD_SIZE, next != end);
+ /* Synchronize against ptdump_walk_pgd() */
+ mmap_read_lock(&init_mm);
pud_clear(pudp);
+ mmap_read_unlock(&init_mm);
__flush_tlb_kernel_pgtable(addr);
pmd_free(NULL, table);
return 1;
--
2.30.2
Return-Path: <linux-kernel+bounces-667781-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 7455C41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:20:59 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 3B9B29E3EFE
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:20:38 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 0D88D8834;
Fri, 30 May 2025 08:20:52 +0000 (UTC)
Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191])
(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 336042116F5;
Fri, 30 May 2025 08:20:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.191
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593251; cv=none; b=BL4YFlNLjpdz2+c5YDGAv1ciTU4l/5yUJUsU+rt/6JaEQgoh6MjjaOwxVz8nQ2Gqx1U77+FOwqA+AIneGgqOn9AJkOXZ0qhhmskY+9YZ2IHdXgElXxqgUCNsz//6U1jkNmlGJD0Ph61iPWr4VwDgkz2SchLojAR9InWfBmgf0D0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593251; c=relaxed/simple;
bh=Ucz1ygW9HG1Og2peBspr33vdjTpvWXFaRtJTMZFth+M=;
h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:
In-Reply-To:Content-Type; b=ROCqcKzM3jRKvLEmBmrDZS+h5g5YFuYsbaqOEkH6LrotzMsCT5d+4KdqxjzRrOlIY3bHCoEuFmM5X0W6hMFoeu3qYIyVmrT1ZqkWiZgP2kzpjV3laimwEKuRcFZ2QodAhMjNFiegVBaOYIlt2CkQ5OkRBlNZmjpy0XB3wCOYDR0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.191
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com
Received: from mail.maildlp.com (unknown [172.19.88.214])
by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4b7x3y0mjpz23jTN;
Fri, 30 May 2025 16:19:42 +0800 (CST)
Received: from kwepemg500008.china.huawei.com (unknown [7.202.181.45])
by mail.maildlp.com (Postfix) with ESMTPS id 77A591A016C;
Fri, 30 May 2025 16:20:45 +0800 (CST)
Received: from [127.0.0.1] (10.174.177.71) by kwepemg500008.china.huawei.com
(7.202.181.45) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 30 May
2025 16:20:44 +0800
Message-ID: <d5d840c5-d030-48de-84df-3891f498cfc7@xxxxxxxxxx>
Date: Fri, 30 May 2025 16:20:44 +0800
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/4] ext4: add ext4_try_lock_group() to skip busy groups
To: Ojaswin Mujoo <ojaswin@xxxxxxxxxxxxx>
CC: <linux-ext4@xxxxxxxxxxxxxxx>, <tytso@xxxxxxx>, <adilger.kernel@xxxxxxxxx>,
<jack@xxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <yi.zhang@xxxxxxxxxx>,
<yangerkun@xxxxxxxxxx>, <libaokun@xxxxxxxxxxxxxxx>, Baokun Li
<libaokun1@xxxxxxxxxx>
References: <20250523085821.1329392-1-libaokun@xxxxxxxxxxxxxxx>
<20250523085821.1329392-2-libaokun@xxxxxxxxxxxxxxx>
<aDcmRdOrWatcBJWc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Language: en-US
From: Baokun Li <libaokun1@xxxxxxxxxx>
In-Reply-To: <aDcmRdOrWatcBJWc@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To
kwepemg500008.china.huawei.com (7.202.181.45)
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 2025/5/28 23:05, Ojaswin Mujoo wrote:
> On Fri, May 23, 2025 at 04:58:18PM +0800, libaokun@xxxxxxxxxxxxxxx wrote:
>> From: Baokun Li <libaokun1@xxxxxxxxxx>
>>
>> When ext4 allocates blocks, we used to just go through the block groups
>> one by one to find a good one. But when there are tons of block groups
>> (like hundreds of thousands or even millions) and not many have free space
>> (meaning they're mostly full), it takes a really long time to check them
>> all, and performance gets bad. So, we added the "mb_optimize_scan" mount
>> option (which is on by default now). It keeps track of some group lists,
>> so when we need a free block, we can just grab a likely group from the
>> right list. This saves time and makes block allocation much faster.
>>
>> But when multiple processes or containers are doing similar things, like
>> constantly allocating 8k blocks, they all try to use the same block group
>> in the same list. Even just two processes doing this can cut the IOPS in
>> half. For example, one container might do 300,000 IOPS, but if you run two
>> at the same time, the total is only 150,000.
>>
>> Since we can already look at block groups in a non-linear way, the first
>> and last groups in the same list are basically the same for finding a block
>> right now. Therefore, add an ext4_try_lock_group() helper function to skip
>> the current group when it is locked by another process, thereby avoiding
>> contention with other processes. This helps ext4 make better use of having
>> multiple block groups.
>>
>> Also, to make sure we don't skip all the groups that have free space
>> when allocating blocks, we won't try to skip busy groups anymore when
>> ac_criteria is CR_ANY_FREE.
>>
>> Performance test data follows:
>>
>> CPU: HUAWEI Kunpeng 920
>> Memory: 480GB
>> Disk: 480GB SSD SATA 3.2
>> Test: Running will-it-scale/fallocate2 on 64 CPU-bound containers.
>> Observation: Average fallocate operations per container per second.
>>
>> base patched
>> mb_optimize_scan=0 3588 6755 (+88.2%)
>> mb_optimize_scan=1 3588 4302 (+19.8%)
> The patch looks mostly good. Same observations about mb_optimize_scan=1
> improving less. We can continue this discussion in my reply to the cover
> letter. That being said, I have some minor suggestions:
Thanks for the review!
>
>> Signed-off-by: Baokun Li <libaokun1@xxxxxxxxxx>
>> ---
>> fs/ext4/ext4.h | 23 ++++++++++++++---------
>> fs/ext4/mballoc.c | 14 +++++++++++---
>> 2 files changed, 25 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
>> index 5a20e9cd7184..9c665a620a46 100644
>> --- a/fs/ext4/ext4.h
>> +++ b/fs/ext4/ext4.h
>> @@ -3494,23 +3494,28 @@ static inline int ext4_fs_is_busy(struct ext4_sb_info *sbi)
>> return (atomic_read(&sbi->s_lock_busy) > EXT4_CONTENTION_THRESHOLD);
>> }
>>
>> +static inline bool ext4_try_lock_group(struct super_block *sb, ext4_group_t group)
>> +{
>> + if (!spin_trylock(ext4_group_lock_ptr(sb, group)))
>> + return false;
>> + /*
>> + * We're able to grab the lock right away, so drop the lock
>> + * contention counter.
>> + */
>> + atomic_add_unless(&EXT4_SB(sb)->s_lock_busy, -1, 0);
>> + return true;
>> +}
>> +
>> static inline void ext4_lock_group(struct super_block *sb, ext4_group_t group)
>> {
>> - spinlock_t *lock = ext4_group_lock_ptr(sb, group);
>> - if (spin_trylock(lock))
>> - /*
>> - * We're able to grab the lock right away, so drop the
>> - * lock contention counter.
>> - */
>> - atomic_add_unless(&EXT4_SB(sb)->s_lock_busy, -1, 0);
>> - else {
>> + if (!ext4_try_lock_group(sb, group)) {
>> /*
>> * The lock is busy, so bump the contention counter,
>> * and then wait on the spin lock.
>> */
>> atomic_add_unless(&EXT4_SB(sb)->s_lock_busy, 1,
>> EXT4_MAX_CONTENTION);
>> - spin_lock(lock);
>> + spin_lock(ext4_group_lock_ptr(sb, group));
>> }
>> }
>>
>> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
>> index 1e98c5be4e0a..5c13d9f8a1cc 100644
>> --- a/fs/ext4/mballoc.c
>> +++ b/fs/ext4/mballoc.c
>> @@ -896,7 +896,8 @@ static void ext4_mb_choose_next_group_p2_aligned(struct ext4_allocation_context
>> bb_largest_free_order_node) {
>> if (sbi->s_mb_stats)
>> atomic64_inc(&sbi->s_bal_cX_groups_considered[CR_POWER2_ALIGNED]);
>> - if (likely(ext4_mb_good_group(ac, iter->bb_group, CR_POWER2_ALIGNED))) {
>> + if (likely(ext4_mb_good_group(ac, iter->bb_group, CR_POWER2_ALIGNED)) &&
>> + !spin_is_locked(ext4_group_lock_ptr(ac->ac_sb, iter->bb_group))) {
> Maybe reversing the && order to be (!spin_is_locked() && ext4_mb_good_group()) would be better?
Yeah.
>> *group = iter->bb_group;
>> ac->ac_flags |= EXT4_MB_CR_POWER2_ALIGNED_OPTIMIZED;
>> read_unlock(&sbi->s_mb_largest_free_orders_locks[i]);
>> @@ -932,7 +933,8 @@ ext4_mb_find_good_group_avg_frag_lists(struct ext4_allocation_context *ac, int o
>> list_for_each_entry(iter, frag_list, bb_avg_fragment_size_node) {
>> if (sbi->s_mb_stats)
>> atomic64_inc(&sbi->s_bal_cX_groups_considered[cr]);
>> - if (likely(ext4_mb_good_group(ac, iter->bb_group, cr))) {
>> + if (likely(ext4_mb_good_group(ac, iter->bb_group, cr)) &&
>> + !spin_is_locked(ext4_group_lock_ptr(ac->ac_sb, iter->bb_group))) {
> same as above
Okay.
>
>> grp = iter;
>> break;
>> }
>> @@ -2911,7 +2913,13 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
>> if (err)
>> goto out;
>>
>> - ext4_lock_group(sb, group);
>> + /* skip busy group */
>> + if (cr >= CR_ANY_FREE) {
>> + ext4_lock_group(sb, group);
>> + } else if (!ext4_try_lock_group(sb, group)) {
>> + ext4_mb_unload_buddy(&e4b);
>> + continue;
>> + }
> This in itself looks good. I am just thinking that now that we are
> deciding to skip locked groups, in the code above this one, shall we do
> something like:
>
>
> if (spin_is_locked(group_lock))
> continue;
>
> err = ext4_mb_load_buddy(sb, group, &e4b);
> if (err)
> goto out;
>
> /* skip busy group */
> if (cr >= CR_ANY_FREE) {
> ext4_lock_group(sb, group);
> } else if (!ext4_try_lock_group(sb, group)) {
> ext4_mb_unload_buddy(&e4b);
> continue;
> }
>
> With this we can even avoid loading the folio as well.
I previously assumed that for busy groups, the buddy was already loaded,
so reloading it would incur minimal overhead. However, I was mistaken.
After implementing a change, the proportion of time spent in
ext4_mb_load_buddy() decreased from 3.6% to 1.7%, resulting in
approximately a 2% performance improvement.
Thank you for your suggestionï¼?
I will prevent unnecessary buddy loading in the next version.
Cheers,
Baokun
Return-Path: <linux-kernel+bounces-667782-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 1FF5B41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:24:41 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id E15527A7D36
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:23:21 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id DA176217736;
Fri, 30 May 2025 08:24:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b="b9kke78v"
Received: from SEYPR02CU001.outbound.protection.outlook.com (mail-koreacentralazon11013053.outbound.protection.outlook.com [40.107.44.53])
(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 E3EB120FAB6;
Fri, 30 May 2025 08:24:26 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.44.53
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593468; cv=fail; b=NlDSLHQR+Iacrz3umb7JiSOFFGPspkKJA06JsNIyXJViRu4MJ2sWacvbobt3CxcNn5RFvQmrrC8g/M0f1/TtG+vROMTsCRi/8nIqS9NwMfj7kniyPntQKfShm+E1EBan85pheDqDtF0IjrYWolRamgJ8BrugCLuLdcj/cpJPMKc=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593468; c=relaxed/simple;
bh=DZBWRnuZiDq7Ka3MlJjIqcdnIQ7jmn7as8qqMEcxrEg=;
h=From:To:Cc:Subject:Date:Message-Id:Content-Type:MIME-Version; b=Cy/f+7r+wPZH73dFmTaB4ojjDXuDP6xlzAH+zYj/ZTFFmICjQONRfPLoYd7ICq2g2I+cpGBNMtXaL7cbazVc2Yt5NB0RrmrmV+VCERRiaIjxeK74UciYfsVtEdu4N1uYa8gVX0WLKfhjnrsKhedfRK7NyTFMgDdY0s53Q5G253s=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com; spf=pass smtp.mailfrom=vivo.com; dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b=b9kke78v; arc=fail smtp.client-ip=40.107.44.53
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=vivo.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=pJ7dVph7sBEXj+ItbljTxiHoYWmGAXw4ZZ1G2ykKMFNZMxOr6mwrN+spj2JFVs5FRsDA0VLO7/3LccpuRqFPw3TANIHj34qgS7oD0oqFLIs0bcBB02hFnAoloTSmNRtpVd3V4qFQanF6luXFkoS+do3fSnb7d1kb+GkTKDGfZV9F26P+NKm1NrxySYNNlAmU+CAMFMY5BzSh6HolmQsIfELFXPM9GzsflCgbVmKAy+W29urmgYwmBwMB92Ntm1CZRNB5jrw5/LmEuZrN4RpR51M/b4HdIaN26Y4V4v7IcbWCUutaJQDx8sjCttV1dAnZW2mXU0MrNErya9sp2YoYhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=awdbzXu7cp52Km851VprayeyS8sIHNgi53PtXmowiHY=;
b=qdTgVQnzYq086hv1cRpmEAEpzZSUscqp5yYcR7Aa28RdU+8di0hQnC2LvckpKSSyEMqDf9iOc++A382T5fR8nWNTwsHNj3S/1Pw1Ghwe6LfxaRW66N9O0cE4f1qURhTPLnNHMUGhM6MpGlZpuO1YpdqTWgKmRKT6tS9lxMjQ260RHMVSFjuslj6DkVY2Fe+VZODrsCJzwwk5t3DJ/gB8XEd8xJho61dhUy0vq5bfDw1uDQkypdYZp+3sfRBNQEvX5CDgXkKdErilt3FFlYZIHGZAOYO0xfahtASOclNwczczDLK5Y3R4K8EGIcTnnIW6FLJxJbA1a73WoejwrImhDw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com;
dkim=pass header.d=vivo.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=awdbzXu7cp52Km851VprayeyS8sIHNgi53PtXmowiHY=;
b=b9kke78vptyEyCC4ovrKHxqml9ECVkOpT7Ghlj0lyFlnnMasgqcvqxSyFdnyiaglD+u70xsaG3RJyzmd5NAVErAhnJNgQuiBjxLW+iGAazD2nNPFeo3nMld/TVRwGnO0gSiJs+xoIOahLJVf3Ev1eAwIkORIx9wpPiE5nzf/um7seP/8kiiKxH5e1ahv3wN4QyHBbe9JhHueed2xKaeAyVfxRkt8kvFMowc5k5lbjBvprq9l6Spj7+k/bsdeCfrPChJogdBn0W0WaQqX93XicMbVAvijSe7V8MuMXoAZ6AANkdc1yJRTRMBVosxubFe19QC2IA1jI1GZgcZwEAHZow==
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=vivo.com;
Received: from SEZPR06MB5269.apcprd06.prod.outlook.com (2603:1096:101:78::6)
by KUZPR06MB8028.apcprd06.prod.outlook.com (2603:1096:d10:49::11) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Fri, 30 May
2025 08:24:22 +0000
Received: from SEZPR06MB5269.apcprd06.prod.outlook.com
([fe80::8c74:6703:81f7:9535]) by SEZPR06MB5269.apcprd06.prod.outlook.com
([fe80::8c74:6703:81f7:9535%5]) with mapi id 15.20.8769.022; Fri, 30 May 2025
08:24:22 +0000
From: Yangtao Li <frank.li@xxxxxxxx>
To: xiubli@xxxxxxxxxx,
idryomov@xxxxxxxxx
Cc: ceph-devel@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
Yangtao Li <frank.li@xxxxxxxx>
Subject: [PATCH] ceph: correct superblock flags
Date: Fri, 30 May 2025 02:44:58 -0600
Message-Id: <20250530084459.2434286-1-frank.li@xxxxxxxx>
X-Mailer: git-send-email 2.34.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: SI2PR01CA0033.apcprd01.prod.exchangelabs.com
(2603:1096:4:192::23) To SEZPR06MB5269.apcprd06.prod.outlook.com
(2603:1096:101:78::6)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SEZPR06MB5269:EE_|KUZPR06MB8028:EE_
X-MS-Office365-Filtering-Correlation-Id: beff9f43-6085-442e-6603-08dd9f536146
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
BCL:0;ARA:13230040|366016|52116014|376014|1800799024|38350700014;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?U/1fyNZm4tNLS8LO2hvrzuYqeJelyoh3j5rOiaegGMuR8SFXLv35OToA+HcZ?=
=?us-ascii?Q?FtOOsrd03h7+UnNIfy6I3f9LQ5VBEUwr33k4TZFLjY+/MQwdYkdBGm1A8bFZ?=
=?us-ascii?Q?2mPqFyK7h55E9mOvFdooEkM6KmCjxg2HHjXc5dFWEmyEGw//D/qYfS+1Dc1P?=
=?us-ascii?Q?y+wT/293tID1unoHpTbAp56Gi3s54d0IQKeqUg8RHGXRkgwsks2DecZ2mjzO?=
=?us-ascii?Q?eFBgy22Brr6qHVStC2/AHybWoj2keWAs571iF9qulU7lGYneFa5MVefOLKJ6?=
=?us-ascii?Q?tGE5OmC12+NX3/T138Nper4RhY3fD7OsoJgvpCyjaZq6yAvAZqyTD2Mc3qLO?=
=?us-ascii?Q?6MKgp/ZKHjdNRDEdJiZoCHm3wxvup2FopdXFr/4o0VzPXAJpHkYd4W4LhpXI?=
=?us-ascii?Q?E/7McX5oMuT+PrLWp/tM9tHdd11g67jD9rci2Gnea8psfRXRLl+BSePRisHZ?=
=?us-ascii?Q?80nulnjJIT9EUoD7okaH0eGdsJUjsjSgjxJn0ZHxiw3n8etqcClSyQC19ROK?=
=?us-ascii?Q?syqkPbyUDkw8irUfKwV+NQotED4dBueMU6JOn46N6VwUIadmUzGhtIgsGzsb?=
=?us-ascii?Q?8uFrqIPBHjSXNhRf59DobgnVfVHbQuhF2uQgRYVPUwPuDh4ipUPkbYFdFlpr?=
=?us-ascii?Q?E6u33Pa+tWw/BOoeYDPo+MmfwrpJdINDu3MNFbGiHz61RDO6vLobXFQi0y50?=
=?us-ascii?Q?grFmAozpyIQGdFF+9ggzh4b27QqKv5zb67bYskOB3FtpWhaE2UDieobVvOPW?=
=?us-ascii?Q?Pid7Dg1AYOtZ4MGYOsW2XPsfAz2W4ZVtlH9cvvdU645Vf3hXKWQMMOL/xJE7?=
=?us-ascii?Q?e72fcxmRlSKyLeV0OB+72AGngKZqBxupHD+OsZm0dA+/i9G0zRer/CpNkwyW?=
=?us-ascii?Q?uad8g7jTFuSKg5vCHLffQU13VjzKLEYiL1MHl/CaCz9VgCLu4LI8xfbCq4MX?=
=?us-ascii?Q?aebIfkmfm9vwLRpH1gvUAQYk7Z+V8lDEJDYyN2wAcs8Tc8+vxZOhWKb1sBHj?=
=?us-ascii?Q?AVZY6IvTlnb53YZR76HYLCQV/Y5f3VpqYD1luENkgpS7JWWOvqNHc4+c5Ub8?=
=?us-ascii?Q?PAr1/CbZtGCNf0pNEMCkZkI6SgOPVKxZP74hwJqXJnqDEwNdo/8hvoyoTNzE?=
=?us-ascii?Q?vXEPbGkryehF3gjFdgRhd8p1cThCli1I5N0SEZvmCjDmzEPs/5W+p+UhD4tL?=
=?us-ascii?Q?kkE2uQPXrIh9fHVq1O1vSSjd2Wf8E7qY4/ogeqQgk2M7liR3Ogin7BV4Oaof?=
=?us-ascii?Q?4MmkvCsRO/Ih9H2lFU+RJKekoUo5HalEvegJ1sNg5ojHVSTKPstkOApfWs44?=
=?us-ascii?Q?lSqKK2jyE7xpsnwZ6JoDDCKKuWeIwtk9yDGxVu7sOpF4PMAYwIhIukVaAUEO?=
=?us-ascii?Q?74kGahhJN5Ptyn349NKAHWkIlmIhnUEtKNfzJa8BjHqZbYwA1Fr4MVSObu6/?=
=?us-ascii?Q?dTw2n2xcg7uedh8kUNN7AAJiK2nbwsQWoGkC6PYf5fSwCpsii4NekQ=3D=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SEZPR06MB5269.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(52116014)(376014)(1800799024)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?us-ascii?Q?mxWNwe9vf/ZSUOPWnMiYOVnhGO46Z8n8bYBF6I0YY1IF8TsviUbIsnMzoo6p?=
=?us-ascii?Q?AMQmhpGOdvJGySoxvM/ddvK5GsZHremwlRHcA5w5sVHWXfCq5mUbSFWgbxqn?=
=?us-ascii?Q?ZbDyLHm6/rWsuJfIB+d5H/YjsVWpfjpciedMfwC5O21WW+MzxbykIuU4jb+4?=
=?us-ascii?Q?CM4HRFEbUaC4jrDP9uiSqFzf2L1j5awiK0d07jDG4xN+z6x2FNgfoXRB9utc?=
=?us-ascii?Q?qRj3U6Zq+HN5/I/D3jEclXqdSiPDwr6rAfoeI/ogZB/xPVdm3uGGEczGEpbh?=
=?us-ascii?Q?qyYXUxSqhul0hxAFhYsBqJvdpEBBR/EesUXe553S5hCxug+958aPcM1SPwi2?=
=?us-ascii?Q?KeeODyM0iZMZPc3bsffPr75kkgBSQgbNgPY+xu9StB11NKIZ2UrcykkoUm+E?=
=?us-ascii?Q?bFGGYpyCru1f89lGiVoSpnW+D265DmvDfxSNkeDe7z4Wy1DCnqin2mE/JZJ1?=
=?us-ascii?Q?Zt3PN564Yikp01KK1xvfHkpJB7xAv/eUYk72bhkBIb7G77LWPdgTgk4jBEV7?=
=?us-ascii?Q?mLy4tCxtOVtcDg0l4bk6cqzvEXgTN9qvFmeDYHIAKsTlbgZRDid+XsQOFtMu?=
=?us-ascii?Q?/L3BikaICF6sF8ZzCubagTAoMDZ3zE8oBxad8DR1AGXEeUKCNNg3yPcgxQHf?=
=?us-ascii?Q?nAJrRRpmi4HDRrUvsGVL4q4wh6xt85lOAq0Vi6My1c23bWPV8h6ObXsb+ASN?=
=?us-ascii?Q?80S1d2B13wxMgjk08VfLylzSxoeqk0sSlXpXX2UHUplh1KrEW/EDA7ARB7iS?=
=?us-ascii?Q?zQ4lIJ2EecPJVOvNvN8tJYfzCrl70vKuHailOYq3NCONT0bpi4jrZsSwb7a1?=
=?us-ascii?Q?IJWnsJeugXXulivX0ZbZuCu16aZAGlbVkQAs3ENgkDr/e+vhPjGD1B7pXs0A?=
=?us-ascii?Q?aQps6OIEDNTGyIvZz3dijKneSFYW+UElLrW6xp7+En8+UzEtruzCIUvQakwU?=
=?us-ascii?Q?N5KrdJ4oDcRtymXq7QQl9V6d2RO807usGqBuqmZwvs2pC60WcctfNXBC1nTy?=
=?us-ascii?Q?WWRR09ccP6zEi9PvPQpe7rPMb6GPvJEyhNy2nZoQ2mVzKIPFxmBSnjCoik9h?=
=?us-ascii?Q?6y7xgue48srDkw2zN5I2X6FyNUNSGrZNq2sln9pGvK2778GGWvJZ2Kxx512C?=
=?us-ascii?Q?0aVmlXfykJ4f1lLtt6/Txo0DyVIdt9qpz6hMtJd99eX8WjcC0p/4/6hvUxYE?=
=?us-ascii?Q?vawkruFgxWUDFR6w4QqHrsNq4uy0HAabjs5mY9FpYil/7i4Yn7yw2CqgNwsx?=
=?us-ascii?Q?r2ODNkyTm5w/pPq/GZJ4sczL5vzUh+HohxKMOZ+sw4S4+INUHinT0/xKSWGp?=
=?us-ascii?Q?mONPRA9d+o00mlnCiolyz4AnWqUncv2igQTcRPxv7wbbqVw4xxF9UrHSJ7yi?=
=?us-ascii?Q?qrjJqg3Cx1DGJtFEIy/9zy74SrJXCMvN0unrfm46iuuB7uX0d7DhgBMzQkqU?=
=?us-ascii?Q?7Ab6Y99XDcNGsQrJo3oG7kJjx/KJXSeu1u/XIKTR7t1TkNGxxTKkx7pWznQ7?=
=?us-ascii?Q?VL5ExIQHTKbh+MNUlhC5hFlvgq/IzqmDuJzCyQrouGXpyYqDsTWrbfCth4NV?=
=?us-ascii?Q?fS44BZmnrVNbbigmtGl2K4xfvvBiAzaI9dGAVHn2?=
X-OriginatorOrg: vivo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: beff9f43-6085-442e-6603-08dd9f536146
X-MS-Exchange-CrossTenant-AuthSource: SEZPR06MB5269.apcprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:24:22.2049
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Jp/FMDN5HQpEpANzg58pmBmsROsl2F8Z2oGd76OPWzy0TEVD0gfmv7q7CataPMLuSW0xT9k1KGbNzd1fOnupBQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KUZPR06MB8028
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
SB_NOATIME includes SB_NODIRATIME as a subset. Therefore,
setting SB_NOATIME is sufficient to disable atime updates
for all files and directories.
Signed-off-by: Yangtao Li <frank.li@xxxxxxxx>
---
fs/ceph/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/super.c b/fs/ceph/super.c
index f3951253e393..7c9e4987adf4 100644
--- a/fs/ceph/super.c
+++ b/fs/ceph/super.c
@@ -1226,7 +1226,7 @@ static int ceph_set_super(struct super_block *s, struct fs_context *fc)
s->s_time_gran = 1;
s->s_time_min = 0;
s->s_time_max = U32_MAX;
- s->s_flags |= SB_NODIRATIME | SB_NOATIME;
+ s->s_flags |= SB_NOATIME;
ceph_fscrypt_set_ops(s);
--
2.48.1
Return-Path: <linux-kernel+bounces-667783-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 6E92741E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:25:52 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 3AF5D9E5415
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:25:31 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 51E6B21771F;
Fri, 30 May 2025 08:25:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b="jUiJ8ohO"
Received: from SEYPR02CU001.outbound.protection.outlook.com (mail-koreacentralazon11013002.outbound.protection.outlook.com [40.107.44.2])
(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 AD3C81EE017;
Fri, 30 May 2025 08:25:43 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.44.2
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593545; cv=fail; b=cYunKIzYJMqp4i3Y2a6aj4zJ+oHJIwF/rQ8AO3P+J9/dN3EjpDWJbUPwgcjhAABPc85Ykmo9VWJcghSno8qNjngzpLb8fIsItNRvOIG2rR6fIOxGHcUQu1/bFydqbiWCFp36CTJxwWKcsQF21Sagg4Iv5f1fbrdkUNuN6POsoWI=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593545; c=relaxed/simple;
bh=T51YxWJMznErqnHLXoIHSfN/3ulV5VMWAA7afKtrhQ0=;
h=From:To:Cc:Subject:Date:Message-Id:Content-Type:MIME-Version; b=fcx5HF7IZU7eB58byeziYulf0kl7cUAMgNSJ7DbfPvuU9r4Mw9fRlAQg+lAelTmF/gTe3WOlMcjuy3Vt4XfBrstjbDFv/DfEI9Z0cYxec2q0OK5vu+5HDVsicaKf+jtikI4i1v1WuJs6Uvm1DWI6AkVj3GP7tpTJM7GWi2aTVls=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com; spf=pass smtp.mailfrom=vivo.com; dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b=jUiJ8ohO; arc=fail smtp.client-ip=40.107.44.2
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=vivo.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=HwhjVW7WuN3j5aDPDnyVg9/++NQOwUXdjB4ZYBbe61SEJaL1iRw5AC/Cut16lJOz+HOEhlpnG+3QQq1CbIPHT2r8p2VasWAwejmQFQpAgN3Bw4XOl6/gIB31Prmj7GClfVUoHMOSMYmx87l8br312/17KvI8pUtWkmpAHLQy/YCrnbnM9QGQLSDD4HoGPI6vB2SKv//8VuDFe2F4NgA9KDwQSPTizoWVzK3uNnxzKzl+4UeFkkgIQ6HQdWpL4z6uMWnDtmJu4n2hy5IldHYFKPYTlkpCB6IE0bvTgyCuFp+kVtUN+W+IT0doW5CTXmv6Izp3e3sw4BYa1mxiCWpTBQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=6hfukbyTFJWXVuRlGdE5TTxZG9+HqUKqFJawSu5aeC0=;
b=WesDChpQaaWsQuMGzxwrc9w+vk/+PdQRtqiLIfkUmWHb4UupH+YNU9CMUlYudO84whjcddLAqRdgucSvw7Co2htRCjSScw0KOi9NSAAMxm9DPTknqQCMGVg9nzmfnGfndANU9bhFWVSuU2+AarCFJuB4mfYZxX8/9YKTYsM5kx3xiUAOoiPvw6kX00bdt6e6mUVOuh0xAAzUAPA7P4FhCINu3NTxmF96nlXfrlHcLkBZkIomRkbl1RD5dxIiMS/tnFceLwvYwFvihl97cw3b9/tbZTMvop9PRDIFlvrBPXZ9CuqmH+ylqf10pk90RKXxMScFi3eUJ5GkwWRuOdft5A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com;
dkim=pass header.d=vivo.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=6hfukbyTFJWXVuRlGdE5TTxZG9+HqUKqFJawSu5aeC0=;
b=jUiJ8ohOl8vWvE5q1qlyQXceaJYdGDFoO3ZfwgLRJL3OIkYk9g+rl1O5JApPWtmsHppiqThHLZ/qc8ztPmdsGSy40LKR74nI7rEbE5KoDaY2tOtF9YBTMNJ8AJoLD5yy6C9z40Z2/xOlikWKGFlZl93mv8UZv3DWjrzuMiRVY//XSd8npHIwYYm4xS/GKir3MgrIprxeyKUhof9TP2hfLiY2l0d/ltH1DV/VoKHZ/3L00cXjqJQEYxOuJu78P59dmMAket64G2zI6TMV7HGE17GF5aQOp1E+nrSawwZa0MRDNApsLrrBuwOj78ZDJ7Took0TvkgkXgX8cKOnvvk+Nw==
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=vivo.com;
Received: from SEZPR06MB5269.apcprd06.prod.outlook.com (2603:1096:101:78::6)
by KUZPR06MB8028.apcprd06.prod.outlook.com (2603:1096:d10:49::11) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Fri, 30 May
2025 08:25:41 +0000
Received: from SEZPR06MB5269.apcprd06.prod.outlook.com
([fe80::8c74:6703:81f7:9535]) by SEZPR06MB5269.apcprd06.prod.outlook.com
([fe80::8c74:6703:81f7:9535%5]) with mapi id 15.20.8769.022; Fri, 30 May 2025
08:25:41 +0000
From: Yangtao Li <frank.li@xxxxxxxx>
To: sfrench@xxxxxxxxx,
pc@xxxxxxxxxxxxx,
ronniesahlberg@xxxxxxxxx,
sprasad@xxxxxxxxxxxxx,
tom@xxxxxxxxxx,
bharathsm@xxxxxxxxxxxxx
Cc: linux-cifs@xxxxxxxxxxxxxxx,
samba-technical@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
Yangtao Li <frank.li@xxxxxxxx>
Subject: [PATCH] cifs: correct superblock flags
Date: Fri, 30 May 2025 02:46:14 -0600
Message-Id: <20250530084614.2434467-1-frank.li@xxxxxxxx>
X-Mailer: git-send-email 2.34.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: SG2PR02CA0034.apcprd02.prod.outlook.com
(2603:1096:3:18::22) To SEZPR06MB5269.apcprd06.prod.outlook.com
(2603:1096:101:78::6)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SEZPR06MB5269:EE_|KUZPR06MB8028:EE_
X-MS-Office365-Filtering-Correlation-Id: 3df599bb-3ef9-4b6d-2afc-08dd9f539033
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
BCL:0;ARA:13230040|366016|52116014|376014|1800799024|38350700014;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?yqf/IpsU+s1tBq6rV1VGSO8cCMeecVvSvAF3FF1P1LYoo7ytNwVdG0nETAWh?=
=?us-ascii?Q?oPv1Fonq1yync28hWyMPugstbXW+3o32br3rnD6mc62XDYx2iiMkZaqhBdlU?=
=?us-ascii?Q?dywgqfRx0mmizjm33ZWQu6b6pz7j0cw4KaLQBPmiSurok/gMHpcoLqIz6OuP?=
=?us-ascii?Q?X1JJ5y2niwAUfTC1gEHIXm6IAZt7ApbDJaWCt8sm30lhOyBYitJvdH1q39mV?=
=?us-ascii?Q?1HToYYJmxp+MnT8pVIKO1HVYJsM72q2Fm8mzLXgnwEwULRW4kif0GIGHG9fE?=
=?us-ascii?Q?G4oi8gTUokLWFifoNeX9XbeWxX/8KsvfxgjAd7ji/vmpJSbQvheJ4ctcBXOr?=
=?us-ascii?Q?ODJk/3XGxDcnTGVUWFJhJVqlm9Lnkge3msI+Rj8pxK4ptmT5KjoAEBDYB0m1?=
=?us-ascii?Q?5UnSOwqq0lu+C5dqw1kfcB8aWmFBJpYCYPqDM+qDborYs3tr5qgBjYpGTshN?=
=?us-ascii?Q?94zuS2LmTxtZ5pND2nkxInlgd0AeZLLtWPDlkTWLH0aoRGsPpak1VJ9FgQ6T?=
=?us-ascii?Q?QERBZW2N9OL8FXGIHsHATm9p94Bs5HNfgfbSVcpgLMPhGFjQs4lhRtN1UbTs?=
=?us-ascii?Q?bz7IO1yPof0wVub8Qp+fwC7WooyNvvDqDIGctqHtPUJQ8teY0OGHNdWT6EeL?=
=?us-ascii?Q?o8pT9m967cz+9F2cQ/lkSRua3vDj87Zl164tHImGSq+4HSSDCxbO3P89Lotl?=
=?us-ascii?Q?heQ9Wxz9fl6mBoK4VoiOMYc7BW5UfqsuFVb8C3OU2Y7xYSRGbNXzfG6BSCYq?=
=?us-ascii?Q?KcH2iFz+Hnmj+mQMHmfdkXHKHaaXNnPUWLCVnqyo0KUZS5PbuTC9iQIWlc3Z?=
=?us-ascii?Q?WJGepe2gmMZWCY4jyGIu4Kc/XIfURomhTiVWKrAJvRSa+OiuPdGl9uUcWkFz?=
=?us-ascii?Q?n46g1xGDUAGyF8kjknGYoVTIjMoWH6H6ptUTTw87L3THLv6GyntaNY8KfIcc?=
=?us-ascii?Q?QMyx0yV7IXuiiW7u2ZKDDdPx7dqBfqy2FyyxVdiPah3HI9mtDLb2XOu5uXGU?=
=?us-ascii?Q?VOWjIGRLN+mUvjTjOindBQEsMW7AB+Z/7nIt5Mc4TUSq2SDh2LMhDYRM9Wxe?=
=?us-ascii?Q?NFBipbihlJrTYE+s4ycpoaj7yWq6FhtJBVVa4uGXuFFDyktIzZlP1z1731jG?=
=?us-ascii?Q?DPW1fpmAjsyIuet5Wk3b1YFj3T3MvONBzB2w+d+1T7ggh66W4SDUsuXNJNZS?=
=?us-ascii?Q?Ow69eHlPG0ZOL8smNJ9f8Z30NxcbueX4eDCixeBhugSkDzBDvdCOyWt6NDJc?=
=?us-ascii?Q?/cyhNIKY/r6TivkmuJLDlcxhHnf2igxnlN4TTmyNyPEzbQH0R6XSc1J4JMfQ?=
=?us-ascii?Q?JCGcBMRbxUY/D5iI/NP4LyAvRx+vs+7KBy8852yBJOWzfhdb3RU/kEk9Q6Q6?=
=?us-ascii?Q?0qxQv09meZ9vOOHm0lCyKmnQuHXMkNJtV2krsfliJNwXw32ZcQXfX2zHAeOg?=
=?us-ascii?Q?KmCXUJF+7WR64ZjhBO9r7Tndq9nIbsHiU55NZAoLUyvUFzeo9TL2uA=3D=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SEZPR06MB5269.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(52116014)(376014)(1800799024)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?us-ascii?Q?SR1wCGhTCGXhTW4KTB7HfNhcM7OdTgJxIJv9MH3Xluu4dcPofoaYoENSmw5A?=
=?us-ascii?Q?oSE1Ax3dkitRfyrdbMhQjm/kd4zD9NQIozjJPCrQMvZ4xZYMVeyhDt5jCbba?=
=?us-ascii?Q?ZPRQAb95OVLBa/ol1hbdVXyRHKsrh6c60NRqfXodK5AFzsauIdJJZMkDf9mH?=
=?us-ascii?Q?isOYNyL42nN+LctsPeysbdrZdxfh90sJ26yAZJhDb3Sr1vxpEGLuklVNr29b?=
=?us-ascii?Q?rYZ/y1t0sh27l4BgRvAYefcGwZ6b/AEeNTq+AJAvpMWr3VGmw7mD27y/ijQX?=
=?us-ascii?Q?m8Xzz5WFPtd52vOQAleivxTUpHsbEErw7zhy8vUypfcaUu6oQ245Q7rWptcA?=
=?us-ascii?Q?65X+KY9Z8GcXMcr83//4z7a/XXHpKq+TVOFspJW4/pirnpkEOnIsTiI71bUT?=
=?us-ascii?Q?WPeoxgnLQsfItSJBLnEixvm8fw++Bc+IZgKoRgUPnZJgXX1nvR1RLjDSG+NK?=
=?us-ascii?Q?efdMwjg8XJB7Hx+eKDwnIK1hK8Kj65cyqSw7en2tLSUBJwmYNTNDR71pNlu7?=
=?us-ascii?Q?Ql9soAR1WQawrGITwp3TboubeOf2QkkYxj4t3bzUQbeD3cJKtlp1jwtQsw2u?=
=?us-ascii?Q?FSS1MSLqmD/aB20uAWOsge3nE7iUyA3B12a7GrfJU44jVjf/MYef8ZyzPwNF?=
=?us-ascii?Q?BE/H40AtF3r+rMFYqU5tJFqoJu9HLO/l4c6DHl6Y3D9QVALqNgzrnGxeLuQu?=
=?us-ascii?Q?SMCN+KZX7LV42LjpBuAy/CQX1VGjazM2t/879wBHkt0MI4YWI76JazOW6xdp?=
=?us-ascii?Q?l96MdgcP+/uV7+M8SfzqOAzyAdg6NOhm/+um0mqDm1w3aVQASg55HUY5+Bbt?=
=?us-ascii?Q?gWzDHQNhkcogaJ497g20+99FRTGowMcwnVZfXd8jvQ5kuBH32mq9qg/OkUEZ?=
=?us-ascii?Q?oqGnVnWISPxb8IXbfqMdnfynUgbOyfPq0pHujevPNjwnFB70Gykr2jmdahYc?=
=?us-ascii?Q?ol5wdW06ZGZuiRTJP9RcNDos92M04FgSlZ4UnIAyzKLa/aSRsdwDRsWpWUv0?=
=?us-ascii?Q?bF/NtDs+V+KX0pZLBMO3+u8VeKALInF4iD+f2tUn4kAhlk/PdepSTLQhcAgC?=
=?us-ascii?Q?UHNA/LzBUg5tp/sG6OffXAxC1b35IagG5Ucr0MJh0iwIvrfIx6pB4jsCpftW?=
=?us-ascii?Q?sCJ6X1TBvnBY9eKb3dS4kLoHRsQW2LzaesDpQlj6gVRgQe3m2E/kdXiCU8wn?=
=?us-ascii?Q?t30fvUOD9c6oWwSIZgBUGJlVZuqiC4XbXv2HgRWwtvKj4ZfV9e9MzzuMNJCH?=
=?us-ascii?Q?3qv/I6uhXIdzNbwaJKi/qMtBFTgK/w+GnVYYJR+clL7ODfY8u7uEV1F3daKq?=
=?us-ascii?Q?u8lKjUKVv4khsk6bAFmYtxa0SUeVITP6Z6lmgiwBZfuKm/kWpPzW73sK04D8?=
=?us-ascii?Q?EGDXDZaIlnQnfUREB0h7oLagNqWwwhF8YTpHtLe6A2OmLY8xiJEm5N95yNUK?=
=?us-ascii?Q?jjdjquaS9/N+ZSg1ymW5vZt7UGFoV0XdUr5+2BIx9tNNlxUrHlwtOVVzyfLg?=
=?us-ascii?Q?/sV55p2VoKsTjQyAzlIAKXNkYnLJAYaF/LPKCucnxIf4yMAklmSLz0MNFB6o?=
=?us-ascii?Q?UdvDNFv+j2pEOOvpcCmOhwbmbbS73tfutrg8Ghwr?=
X-OriginatorOrg: vivo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3df599bb-3ef9-4b6d-2afc-08dd9f539033
X-MS-Exchange-CrossTenant-AuthSource: SEZPR06MB5269.apcprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:25:40.9189
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: eTFFaeMiYP6AiT1dhS5nAp/uQ/ujKrA135D1zQhtMcWuOzYxBK6E8xsfAymFwtwFidhQ38eQHLPmRWGRgktXUA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KUZPR06MB8028
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
SB_NOATIME includes SB_NODIRATIME as a subset. Therefore,
setting SB_NOATIME is sufficient to disable atime updates
for all files and directories.
Signed-off-by: Yangtao Li <frank.li@xxxxxxxx>
---
fs/smb/client/cifsfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/smb/client/cifsfs.c b/fs/smb/client/cifsfs.c
index a08c42363ffc..b4bc15ea33bf 100644
--- a/fs/smb/client/cifsfs.c
+++ b/fs/smb/client/cifsfs.c
@@ -996,7 +996,7 @@ cifs_smb3_do_mount(struct file_system_type *fs_type,
mnt_data.flags = flags;
/* BB should we make this contingent on mount parm? */
- flags |= SB_NODIRATIME | SB_NOATIME;
+ flags |= SB_NOATIME;
sb = sget(fs_type, cifs_match_super, cifs_set_super, flags, &mnt_data);
if (IS_ERR(sb)) {
--
2.48.1
Return-Path: <linux-kernel+bounces-667784-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id EF0CA41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:26:29 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 63E7D1BA59ED
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:26:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id A70F8217659;
Fri, 30 May 2025 08:26:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b="DqHFuOoF"
Received: from TYPPR03CU001.outbound.protection.outlook.com (mail-japaneastazon11012069.outbound.protection.outlook.com [52.101.126.69])
(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 3D4C31EE017
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:26:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.126.69
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593580; cv=fail; b=JWXGa2PjVLeLTdfdVVa2CTbpTJUxAn8cMTBhbwpxDthHqIJctdMvZxzzygz2Wa85bDZ9JD/2ghY1myjHLhneKJOpSHne44Ib+bzOqNe98js51HQJMRHQY3fLZqra3Yl7OggGO5q4UC2QxF8IFvf25x9gCiTTejRWksLuOnh1D2c=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593580; c=relaxed/simple;
bh=9f4rCakj9b8yasks0C2JOuge6XVzx+tZPEscfOTCRX8=;
h=From:To:Cc:Subject:Date:Message-Id:Content-Type:MIME-Version; b=PMQnEqdJfkrZwBqu6f0Un21zkVErmpEHpfCjmMaK9RZeCOTOdaUu4Ww22b6DtkY8hmTpmHcGGplRO893qztmy8sUHMSx081/UfglDKSjmO5BylShpnaISgYgOnFKZhKxLPhHauaNLq4dAuzR1zpiPJN+66w3MFSuJglCw/3hv7Q=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com; spf=pass smtp.mailfrom=vivo.com; dkim=pass (2048-bit key) header.d=vivo.com header.i=@vivo.com header.b=DqHFuOoF; arc=fail smtp.client-ip=52.101.126.69
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=vivo.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=vivo.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=ZtosSpT+BsnNYbWV3C6TQYdI3yM+SvVEUvmhivmnTxe842bmXe3c00vZK6gFxhc3wRfux1S0QKzOZtNkGvKrQudX9oalGXOlSwpMVw7OC19UZ1o7I6/tqoOGi6W/QAfp2ssi0VkawJU9la4z1R5JZeIM3Aq0Xfl5RfwnBEOQOYUcNmLeR5Q6PdBAikbunpWrMncYmME5/RBzw2UEjHEZ63FOQ2KzyYeyBLYQ48lCVP+dC8hkiprv+GOi61TtPpzKi5RUxfu7t+/SE/EXd54tiv74PeIOHD5t1Am1kYe3bwUE8KACdKtydp9WjTWLAnkdiY0R1ET4GBfjfyutemOSbw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=pVQd4dM5rx3tVO7diiJbTp0Vx8DOhrY4j4psPouzaDo=;
b=RClR/LMBx9dXw/Zn2JdJnIc9pWTPyxst2/PKZhJreRxGavLO4NA89HA4EJW7WROzKDr1sO0Gg1EQwmmZO1QESZsJIrxdbzeDc5H6pKPFvaZ69m4UENxzU9Mr3aNAQzniMpXI69ebTaZurgJxhCj2wbbD4aqu92ZWHWbhdMgOysSx4+eKZrPCUJSuY86va7tWjuGWXXMg/6FkIO3TbjVRtdRQXFJwW1BRS1sYwzTOR5eV0ntDUj4E3NhihK8KqH4rL4p6ySxxNMN6Zh1BoOjL64ytPfrgSYJ2MtRb+dYfEytURLKB8jUUj9uDoJs0wHVPaqoi0LTMlaeuvfZzV1lf+A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com;
dkim=pass header.d=vivo.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=pVQd4dM5rx3tVO7diiJbTp0Vx8DOhrY4j4psPouzaDo=;
b=DqHFuOoFdEX125n0taKcbnFrRINRJzdOfubvN5icJvVMcaK1Q0Z4lpre87zOCfQhdxpJ7u/5u2ROhwPzeNI6cIyrIYu6CMRYBq7jgUHFHP07nMPiIOFrTLhLNYVITpM4JqcvdpCiCiqHzJjWueKH8RSlX4SWAFjoBYCnDC4+rXh3ge7GfM8K5vyx8AqlkW5r7y4vFxOdlCE5OBWdP2RH4jey/yJlpkl1pw16LyM3xOIpq2uFnARrlAgaYe0FO2mMPb5/aD4blY+qWRjO4n0yIBb/DM5GMEdrV+TSW3c9eQ/xTM3KAJLqDsRGmhbKHKJyGX0ROenO2/8kNxcDR2louQ==
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=vivo.com;
Received: from SEZPR06MB5269.apcprd06.prod.outlook.com (2603:1096:101:78::6)
by SEZPR06MB5605.apcprd06.prod.outlook.com (2603:1096:101:c9::8) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Fri, 30 May
2025 08:26:11 +0000
Received: from SEZPR06MB5269.apcprd06.prod.outlook.com
([fe80::8c74:6703:81f7:9535]) by SEZPR06MB5269.apcprd06.prod.outlook.com
([fe80::8c74:6703:81f7:9535%5]) with mapi id 15.20.8769.022; Fri, 30 May 2025
08:26:11 +0000
From: Yangtao Li <frank.li@xxxxxxxx>
To: hirofumi@xxxxxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx,
Yangtao Li <frank.li@xxxxxxxx>
Subject: [PATCH] fat: correct superblock flags
Date: Fri, 30 May 2025 02:46:48 -0600
Message-Id: <20250530084648.2434569-1-frank.li@xxxxxxxx>
X-Mailer: git-send-email 2.34.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: SG2P153CA0044.APCP153.PROD.OUTLOOK.COM (2603:1096:4:c6::13)
To SEZPR06MB5269.apcprd06.prod.outlook.com (2603:1096:101:78::6)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SEZPR06MB5269:EE_|SEZPR06MB5605:EE_
X-MS-Office365-Filtering-Correlation-Id: 40461977-8e21-43aa-857b-08dd9f53a23c
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
BCL:0;ARA:13230040|366016|376014|52116014|1800799024|38350700014;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?GD3vnzUNEo0j5XTyDKjIDsbsIbtEi+Xkj2j6SOEZKGu16tusaEu17i/5Qnv2?=
=?us-ascii?Q?46fUWWstGi7aDFrRLyCws3gH71DCFqCe+zHMo2h3A6Rn2lI6aSBMu0HC3HR7?=
=?us-ascii?Q?EyuTusEKngIm6+I4bAI3KN0shILzDn2HZV4uyYD57UU9EFm4QhYamC8+9zRW?=
=?us-ascii?Q?ORjLL+gzOEK6xnC5zECRjX32doaiE9AfEG754TWFgaBybEzEaUjSAdSha3BZ?=
=?us-ascii?Q?eIvN7e9xNKBsvCmZ0B4cyjC2vKE9NQgM3Aq5oE+NbND+jXlu46cA8gJY+mHQ?=
=?us-ascii?Q?uDRgr1Mk6sH+GjcJ7s4BpgSlzIiCU6z3J3bcmKrZ5l2SwRPmfNa007xrhcvt?=
=?us-ascii?Q?Bvdn8JJqHIJa1T/lJfYGHN5TMNLmPXOqtyDMfIBOi4/dKrA5jiqfR1lmHM2G?=
=?us-ascii?Q?A15x199HHwAujGBe7s9yuhDOK4+Ei/2sGwdr3soGShIfaMFsONO1ycfYqfR+?=
=?us-ascii?Q?N9MZyTDwu0s7oZ9C/UJtxdL2HLV/aCpKlMP/w9T36jlaX9vD3o5G7BLT73bo?=
=?us-ascii?Q?Iwn00EeP7t8dTMX2B5XsbapbuB+2zA+p9CMVu5Q/OOELPkngXgJYnJMmNTPS?=
=?us-ascii?Q?Yfe4i9Wmc2fOrc+lKCRGi6k/k4e0W1/75AcnNqqWw4cuMIG3vR3lLulfqbuC?=
=?us-ascii?Q?zlcpDhp7XaMu5nVfDu5bzwWywXIiJreUQ5oHQVzntQ1DvwDbBP1Z79ErQxkY?=
=?us-ascii?Q?KEucatCWoezXRTLXRWhiqkQn8Hz95FFeN6yhLHWIVm99h7tLtcrVl8eW/VvZ?=
=?us-ascii?Q?Hs/JUyYKF4Y/bRWsSQ6TSr+Z9iPM2mxBbrpzBJjoNqT5GxhdEIVbgWJEifuB?=
=?us-ascii?Q?SKB7Flegxr499ETBpFHe6tjlerihJQZV/sTI84oBTg4It/JwiA3MTxgoeIMF?=
=?us-ascii?Q?OjjLbuqV2Pmyjj/ms2LPqsYZIZFROdbUnffFW8gW3GuITHMNhGHHhnByMge8?=
=?us-ascii?Q?xipRVku23ZzFWWqkF2W/qr4m/ZvWpR/IfXDcjQlpuL0kbWYcRILIk3gQWP+h?=
=?us-ascii?Q?M4XC08WLQoxlzClmtg9awmyQ7iobV1FFhu5gDJ8dDpeudGPmFY/xRAq/bb7z?=
=?us-ascii?Q?iLj2cHAOzIAsJt8slMtGmU6xrotf46ZHGxNS6qQUue/h0z+ZmGL89fDR/M9s?=
=?us-ascii?Q?4Y2hse/zpGx84LIqapf+GT9c9TlF1IohXH0KS0ogfiYbMHsqcsJiZ2928OnE?=
=?us-ascii?Q?Wi1k+9e+WpPzCSWIL/WU0QinUxkgg7Gg9v/ugLGBdUJcE0VGPrpKZ/G4kOKO?=
=?us-ascii?Q?qfIxtALhF7cxVWyjh29TcrkdqutwZcDS9FZG/tBdMYJrmrix8jzq8m0K/d3J?=
=?us-ascii?Q?iX9ofPYuLthbYMDx/4/GREcdnAoNpTrVYPlKswMwoUvHLlBytz3bzTPiCyJ3?=
=?us-ascii?Q?ymmnrD2pd2AYb550bpkY4UHY9mu368Bd62Cib935ouMdKzDvRgtQzKabOzRv?=
=?us-ascii?Q?KeND0sGZL9pf+q5nY4UeEnJMhuj7/frxoJzrUQk03fKa648rpv6AUg=3D=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SEZPR06MB5269.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(52116014)(1800799024)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?us-ascii?Q?INoSYI4RoggaAztRxrSr7p7HHPxWnOCTqDhjPo4mvJUeoASNDCjvGAIRrlO0?=
=?us-ascii?Q?9KHGl2bTFhjGZTOHvT7XZ0vwnje3RRvkvKpznqLMQjCDkYnBYDgeh3bZzy0O?=
=?us-ascii?Q?bpnJwp7OGYk9vKSawYcIvZVXDM6byRP0Onln6mBIkX310oGMdzBDAaTew3V+?=
=?us-ascii?Q?tjF0qhGh4tWnU33B3RWsxCrJdsICGbo3EX/S/l2faBK9ez1Z5TUZQssKbJ59?=
=?us-ascii?Q?vnEwpLwpCFITrTJtKIjBbxf9RzIg+qDKMLTULNsAQa8Ll1iBaH7d1s+X+KYq?=
=?us-ascii?Q?igQKe9hh7KpXruD83eW3DlvNoU0p87m+nKbksOVyNgpMs09sB0+eIvanBE0N?=
=?us-ascii?Q?rVL+4UXXTGkr+8kOxVeXnseom/Xhn1F6izyL1b3iQcny8MhiiHrs8dADA3zf?=
=?us-ascii?Q?bXbBvPYEM/wDG887eeU17Iorq4TzcqAZKv6zcMgjQruzgAAt6TYWge7+PsYb?=
=?us-ascii?Q?dTUvzeFwTmqRcsW9IBtFGunPBzcmHH7sGFgrlbzITQ2MnVUbeHSmhFg7DjO2?=
=?us-ascii?Q?s0radDs2nfb/sPaBOimz7v/CtzNoLgMmbc7LXrFAoA0XpK90bQ+JmIsbwxEP?=
=?us-ascii?Q?h1RAUS0aahNuyXxMHDaQWMcPqoNNRbEDrnyvbcrILPTcBuXRYC0Zg+k2ihRg?=
=?us-ascii?Q?Wwjd3F9vi2tyjGG873BsPgDfwa5LjAiNePQPgWXoKzxcp/cjeAn2ZRBDtdLk?=
=?us-ascii?Q?IddO6DBEW02A/c1ogMWMx31mE4pE6w+S9hPHzoZZVZt21HgX8Fxs6qhggJFA?=
=?us-ascii?Q?vlc161lId4qlzH5mAuzufVsr1yOqGa2e4LCay6KLOSTASnCkU2AwDbGHZAvg?=
=?us-ascii?Q?/vZtQwvyLyVxKcuSxjdTegmt7VnxKa8rRQAfxEHKRudibGvrTtujLfJzYQQd?=
=?us-ascii?Q?cQ3/ImGsBrced2KQ6bd8GIVXyJeSxAe1+suxVngT7tAte0w2SiXE2iiAzf5E?=
=?us-ascii?Q?/qA+wU8BwxKz32ULn3JSE4mkGFnEQApd6QnNzGA86xRXhsa+Z92ECAEMhyje?=
=?us-ascii?Q?yVdSloIVqhAvJxDQ820GgIUrgNsqkfHwYUkBn4o89jFM9cZzmzVHHcoF9hD7?=
=?us-ascii?Q?n06TCNIuHf12A45nx6HrgP0sHGrXEDkV4vw6mi+GoMnFNjTfvWP6R/SABpFh?=
=?us-ascii?Q?QjvWxaICgHQC4uTZHC2WyUJ9TAkPxxBx8g6MLle9mXDut6/tWBp2756XqUn/?=
=?us-ascii?Q?QjyFicvvmcI6Y5XxhZ7pTpfb2Ydg/4yogXORh7wuPUFxRRTIELm7CGHIPXY6?=
=?us-ascii?Q?JFtNLG38hHyGfDDZXfkNC3mZ84lvwp/bpkO77ZylGC8llXXWxunB3AO+COr1?=
=?us-ascii?Q?J2V2en/HKHmcfpaCNS+Fyu9h8VXqMFyYTK50gJw1chL/axpY6fHOIoD9QhqR?=
=?us-ascii?Q?MQZkl7cWN7yrYpUbHHhQAa1YVVpancZ/30kRGajvjtGXzgqK5c0nm+McPCp4?=
=?us-ascii?Q?hFG8PJV+hhUOVGgzUr+oXgjpJnF64m9uULwdcGp4DNn7IbcDMgvErfzWhsfm?=
=?us-ascii?Q?oLjnwrEKZPytthh3v5g06cbLXGkhdrse5C4+ybpcql8AbZlAL2v3YZ7jdWB3?=
=?us-ascii?Q?KqvpHNcXII+rqXf9DgnGdY/aXWhfRaAf3b6nj7Nk?=
X-OriginatorOrg: vivo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 40461977-8e21-43aa-857b-08dd9f53a23c
X-MS-Exchange-CrossTenant-AuthSource: SEZPR06MB5269.apcprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:26:11.1978
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: HwyivR4fZMjjhNQ2s4K9ack/O3M7CpsfxWTCSTP58DIp8TqhjXUs+KXdGJhUnzPlqI60SNGw/iS88Q7qHlbgwQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZPR06MB5605
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
SB_NOATIME includes SB_NODIRATIME as a subset. Therefore,
setting SB_NOATIME is sufficient to disable atime updates
for all files and directories.
Signed-off-by: Yangtao Li <frank.li@xxxxxxxx>
---
fs/fat/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 3852bb66358c..5da96c37386d 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
@@ -807,7 +807,7 @@ int fat_reconfigure(struct fs_context *fc)
bool new_rdonly;
struct super_block *sb = fc->root->d_sb;
struct msdos_sb_info *sbi = MSDOS_SB(sb);
- fc->sb_flags |= SB_NODIRATIME | (sbi->options.isvfat ? 0 : SB_NOATIME);
+ fc->sb_flags |= sbi->options.isvfat ? SB_NODIRATIME : SB_NOATIME;
sync_filesystem(sb);
--
2.48.1
Return-Path: <linux-kernel+bounces-667785-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id E44A341E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:27:25 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 0E1254A7220
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:27:27 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8CE7B217659;
Fri, 30 May 2025 08:27:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="eqRiW8a3"
Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179])
(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 4CFCF1EE017
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:27:18 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.179
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593639; cv=none; b=HYbQVc82t1P2urUntizbSE83YVzKCqS6Qo0vTCygAgSuNT1MyKZwvnxu6ooUdgVhiu47ZbsWyxKcUK+y54nwT8DeQo26SyFgNkfuYHG+wn0BE9L9mPtUC+uZEC76+nra1avU/zOaHDkHARToYReyXaGqJ/HPBOUPhXL2F/wYITA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593639; c=relaxed/simple;
bh=vRrRzjvalC4b5vsqPDE18UuRNxy3sXp/LnYLU8RtL7E=;
h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
To:Cc:Content-Type; b=Mj0ct9dckImup277CQyr3UL13YKgnk491jf6mI30+mjcbjDsBcPL8fdsdf6K6yhd1aiZz55BCmqO2lnOc5s7nQx2rGAHlyQOV5pcpLVoHvgRCKu202ImpTJKC73+u7d8kobHAKV3eIVS8CcnVct2X6rdVcI/K47iAdQsuYuvgnw=
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=eqRiW8a3; arc=none smtp.client-ip=209.85.128.179
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-yw1-f179.google.com with SMTP id 00721157ae682-70e78e04e48so14249697b3.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:27:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1748593637; x=1749198437; 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=oYOli4oTQ0MFkGdltVUUX/1x4FeeDlNH5ixoZJpfc0Y=;
b=eqRiW8a3/dfUqAkOBk61G9ThYudPPGEAMbmEKWzTYVgPsUbyhV7tK793o3hwSoU85y
x4KrvebM6QN+G1ucZHrJWdJZIrww16MPhVdpx6YP3Sf1VSy8dFjd5Fa+L0xDAAcXDa6P
FOE7hQAG0Xdqzi3xK9lhGbrHDK+RyWSM4RVJW2WFHSotyU8EIgSPMAqWSYV8V4c3hXYC
I+IAPxKDG0af1aQkAzu2n4Io5FCBskkBI3gXRERzhSwORX985e7X6jQ9Y5h/8FDkrvkL
IZoJOZ5Zwk9qN1Rm6MLmSkQsrrX7TZC80zIk2ciFf0fI7mBNZYnVaksUNmek4ZmuQwwN
Hc0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748593637; x=1749198437;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=oYOli4oTQ0MFkGdltVUUX/1x4FeeDlNH5ixoZJpfc0Y=;
b=ZS1hTH72FaIPweWxjMcBahGH89jL/IHS4ax3gQgX+F8s4+ypiJ/BCCfEWzRTJsVdgI
JOBjHX5SOj5tpSSB/hUjOOKlHvEIY+TO2KyFgFXIgMcCMDU6LxPzot9uYnkBFo5el6i6
BCOobQskWwWCFgSj9q0I0sb/yHt7gWwnyXp8z72MGft5W7hA15F2RXcKaZ651Ey/H/iG
zgBmSS3Hgqs0h3zM2TvHtRrYOJ8WIWNOJYdWzxo+UmSPv9y138dEVTKj6Cru1u4EyZC5
kTfHKi8R2Njy/VhWBzjKSsBbdD0ATjexyiiz8xTGkhlKxiRFLHBdeysL3a9ZCdTVayzd
THnw==
X-Gm-Message-State: AOJu0YzrYtsf6f65/yUwVqNK6pFTNpkXFTcGmqR/pxWjthf82InbOcRs
k3FMrvYS5LACeqUWx55Lyh3c/KwLj9H52WBWY6ThpikouMD2VeGWq1JRt7dXjD9DqAeMDj6A/q6
MH759RNDqSy+x4wrpeprcJSMMJIrT7mU=
X-Gm-Gg: ASbGncvgA4hmkOunOhzEIDDSIJPlSXaKaL2V6Ot6Z6y0DFB5y51HALbdLQBnzvkwbM+
AmU4wwdPNsdbrCusSehMioZU3DkJP7HEs8Nhq2BEsgQ0k8VHQRqQewFzMG9x9MQDwDsnb1DpRKa
CNg2BV8i8LnkfQmtLJpW5jfNtO9OV3jm4=
X-Google-Smtp-Source: AGHT+IFsqOwz2hH/6SkMcb4g5Yt5gM++f/aIIg84Ru4n0ZJdf4J+GaGTDN2HUDMjHnisBhrlGkZG3VMjpTsxTu67sqE=
X-Received: by 2002:a05:690c:ed4:b0:70e:2168:7330 with SMTP id
00721157ae682-70f97ebe21cmr35975617b3.19.1748593637073; Fri, 30 May 2025
01:27:17 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
References: <20250530034713.4165309-1-dregan@xxxxxxxxxxxx>
In-Reply-To: <20250530034713.4165309-1-dregan@xxxxxxxxxxxx>
From: Jonas Gorski <jonas.gorski@xxxxxxxxx>
Date: Fri, 30 May 2025 10:27:05 +0200
X-Gm-Features: AX0GCFu20_wlEHN11fGmhScteajc3WuMgALK6hLnwRgWbt4ITw7IMg-Z42znGps
Message-ID: <CAOiHx=nzNZiOiBKUVqpTA5S8uY+ZNdPpLpEQGGDN9jP2-4Lj8Q@xxxxxxxxxxxxxx>
Subject: Re: [PATCH] mtd: nand: brcmnand: fix mtd corrected bits stat
To: David Regan <dregan@xxxxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-mtd@xxxxxxxxxxxxxxxxxxx,
bcm-kernel-feedback-list@xxxxxxxxxxxx, william.zhang@xxxxxxxxxxxx,
anand.gore@xxxxxxxxxxxx, florian.fainelli@xxxxxxxxxxxx,
kamal.dasu@xxxxxxxxxxxx, dan.beygelman@xxxxxxxxxxxx,
Miquel Raynal <miquel.raynal@xxxxxxxxxxx>, =?UTF-8?B?w4FsdmFybyBGZXJuw6FuZGV6IFJvamFz?= <noltari@xxxxxxxxx>,
rafal@xxxxxxxxxx, computersforpeace@xxxxxxxxx, frieder.schrempf@xxxxxxxxxx,
vigneshr@xxxxxx, richard@xxxxxx, bbrezillon@xxxxxxxxxx, kdasu.kdev@xxxxxxxxx,
jaimeliao.tw@xxxxxxxxx, kilobyte@xxxxxxxxxx, dgcbueu@xxxxxxxxx,
dregan@xxxxxxxx
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hi,
On Fri, May 30, 2025 at 5:48=E2=80=AFAM David Regan <dregan@xxxxxxxxxxxx> w=
rote:
>
> Currently we attempt to get the amount of flipped bits from a hardware
> location which is reset on every subpage. Instead obtain total flipped
> bits stat from hardware accumulator. In addition identify the correct
> maximum subpage corrected bits.
>
> Signed-off-by: David Regan <dregan@xxxxxxxxxxxx>
> Reviewed-by: William Zhang <william.zhang@xxxxxxxxxxxx>
> Reviewed-by: Kamal Dasu <kamal.dasu@xxxxxxxxxxxx>
> ---
> drivers/mtd/nand/raw/brcmnand/brcmnand.c | 48 ++++++++++++++++++------
> 1 file changed, 37 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nand/=
raw/brcmnand/brcmnand.c
> index 62bdda3be92f..43ab4aedda55 100644
> --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
> @@ -361,6 +361,7 @@ enum brcmnand_reg {
> BRCMNAND_CORR_COUNT,
> BRCMNAND_CORR_EXT_ADDR,
> BRCMNAND_CORR_ADDR,
> + BRCMNAND_READ_ERROR_COUNT,
> BRCMNAND_UNCORR_EXT_ADDR,
> BRCMNAND_UNCORR_ADDR,
> BRCMNAND_SEMAPHORE,
> @@ -389,6 +390,7 @@ static const u16 brcmnand_regs_v21[] =3D {
> [BRCMNAND_CORR_THRESHOLD_EXT] =3D 0,
> [BRCMNAND_UNCORR_COUNT] =3D 0,
> [BRCMNAND_CORR_COUNT] =3D 0,
> + [BRCMNAND_READ_ERROR_COUNT] =3D 0,
> [BRCMNAND_CORR_EXT_ADDR] =3D 0x60,
> [BRCMNAND_CORR_ADDR] =3D 0x64,
> [BRCMNAND_UNCORR_EXT_ADDR] =3D 0x68,
> @@ -419,6 +421,7 @@ static const u16 brcmnand_regs_v33[] =3D {
> [BRCMNAND_CORR_THRESHOLD_EXT] =3D 0,
> [BRCMNAND_UNCORR_COUNT] =3D 0,
> [BRCMNAND_CORR_COUNT] =3D 0,
> + [BRCMNAND_READ_ERROR_COUNT] =3D 0,
> [BRCMNAND_CORR_EXT_ADDR] =3D 0x70,
> [BRCMNAND_CORR_ADDR] =3D 0x74,
> [BRCMNAND_UNCORR_EXT_ADDR] =3D 0x78,
> @@ -449,6 +452,7 @@ static const u16 brcmnand_regs_v50[] =3D {
> [BRCMNAND_CORR_THRESHOLD_EXT] =3D 0,
> [BRCMNAND_UNCORR_COUNT] =3D 0,
> [BRCMNAND_CORR_COUNT] =3D 0,
> + [BRCMNAND_READ_ERROR_COUNT] =3D 0,
I see this register in BCM63268's NAND controller at 0x80, which is a
v4.x one, so I'm surprised v5.0 doesn't have it. Or does it not work
there? I don't know if v3.3 also has it or if using this on v4.x would
require a separate brcmnand_regs entry.
Can't really comment on the remaining changes.
Regards,
Jonas
Return-Path: <linux-kernel+bounces-667786-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 0F4DA41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:28:23 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id D81807B21B3
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:27:03 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id E070D21767D;
Fri, 30 May 2025 08:28:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="f88FU4Lw"
Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50])
(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 B49921E833F
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:28:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593694; cv=none; b=oG6uUG81H5XTe4dSe1fR0KKl5yRHN/z2NFOtkKyh3XyWPyA8SL9ze8jUf1wijdjGVSTpTWAtNYIwuK/XOmyGC/sm0i9Q7bYg08JF0pUzXtbIZS+LQKuoThjoYgE1f/2utT880lAHufrQwWC/sbacjmYC/hJ4zVpZ+sc3700tgMQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593694; c=relaxed/simple;
bh=fmJb1Vge/hV+b9FDVR4QT1MmeFZnpkrgLzRxdbhhX+c=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=iaj2Cgy1JC02Ukd/zAa8/e/M6HlRQ8GE6rfiqH4pU4xqqbmaLCysif8LXoMPnBZU5sX+wf2GELW6yHDIw/rSdBlAcxbusk6lZ6Qm8JuPnRYu8MizwXPZPC0ABpKNRQesY0WUyAKHXBmSvmOGiCKpEg+30VWF1qPmhFRC8X4UUlQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=f88FU4Lw; arc=none smtp.client-ip=209.85.221.50
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com
Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-3a3798794d3so1490546f8f.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:28:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=suse.com; s=google; t=1748593689; x=1749198489; darn=vger.kernel.org;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
bh=+KfoeGtydTUpyMLEw3lr9UQ8n4o3PGMI0cTKplyap2g=;
b=f88FU4Lwp761A7x7tJ3K9+IQ8VeNJnGUpmWkDivwZmH7r9gm2AdxqNYYLvEJ4aOW92
aWcp+2h96h9JHYhzI7ssvv/qGNwDmUl/ylI+NJ4mpocr84AW8GFUUfyVEH5Y3PIHAT0R
RyEnda5E9oiqf+TWMLXBT2w8iq1F5YmNlCJMM9ylSq21CwdJHjt30PQHYtlCBSjZyozp
0QKdeBfVMiMrDDpeRLtu9xQWvLA8lauVqdAj3v3OkoAvaJdyYlClT74LEDVtXtgS48sC
iPAomtjz4EC3i7y8++AZE20qI2tGZ7WGWnhcUm9ZUbByf3jzPOiS3Bk2GVf5bPACOe0w
n6bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748593689; x=1749198489;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=+KfoeGtydTUpyMLEw3lr9UQ8n4o3PGMI0cTKplyap2g=;
b=hj/sZJKdjLKy2+ehsQLxphx/evx6iNInUpLNYzMf88MK4SMf/BKO+GFuaYdfuhjbR5
4diClzjd466mk0yMcw+UtPwk7EJB1xxaf+p/LRQRd963IFBuZfp+k4S50p4yBrLsxqRh
LHI+qBtcBQ/uZjh6/8SzwHUnuxjoPwve8QVNjqVnE3vz6KJK//JMVSe1eRFlsa3mul9L
aAXImaOuc/Aoqqes8QBiLEFfaT9allY53T/SxYYHN2grKJDm24unSUu8gByPXo1paVnH
j9dHQIdGsvrxQm0ugW3PopJFaxAHabRtm3JL6INT86OPDdsFEeojvBVHnSdg4QaGgIUA
kr7w==
X-Forwarded-Encrypted: i=1; AJvYcCVjzWq6GtuLZgs97gXFlTRtzJoN3pQfJbElhY1yPBqslwR21rn5nWmCe75IEGstjfs/j0nreS1bzN/xwyU=@vger.kernel.org
X-Gm-Message-State: AOJu0Yz24jqIAAcsfduXyiBfk3sFFSwIYbrWuno+n8+75RQJbYlvNoaj
W54KAJoWnLT7RvyGm1cxEWocYftYWJj5Vmh8/biI1JCUjr69KZ3HIQ+GgY67KomvR9k=
X-Gm-Gg: ASbGncu9g64orFAgnDhWq+EdVXoss8nbRIvnVf2/U7bxnxiAmbqA3+yhSDXMu50eXBW
DRhSVCvg9HEKNyl7vbWleJOEQzdHUiSkVMaQbwskhYqfVzB+7pRXumglwVKg9ukQZIhf49lIeVF
XM92MWGafiMHywlWQGttQIRNFTNESs7n0x8HAKs1r0BlV21sF9BzBsgf87RVH02A0tK8DQRBT3b
isJO7s1e+EjcCy7+Zs3sTNOAUHe0t923E+jGg6JcfdnzTVjv4a9ewODRd/wdTPRYt3hxwT3OqSN
RfGlNwugWvOQTKpnFSGkBkQcwU9vwbwONWW3fy+raWDA7oM7kCh8ppXlMWOsQ3Y/J8nfAcsBq1I
=
X-Google-Smtp-Source: AGHT+IH/hoDLzGQW3Ae82uMnYvImx0K/Ml7TX7h0dog4n2USqtNGdiSnfxDJz88krhbw1SEsk2vu0A==
X-Received: by 2002:a05:6000:1a8f:b0:3a4:ee3f:e9a6 with SMTP id ffacd0b85a97d-3a4f7ab1641mr1698397f8f.54.1748593688757;
Fri, 30 May 2025 01:28:08 -0700 (PDT)
Received: from localhost (109-81-89-112.rct.o2.cz. [109.81.89.112])
by smtp.gmail.com with UTF8SMTPSA id ffacd0b85a97d-3a4efe6d0dbsm4093471f8f.40.2025.05.30.01.28.08
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 30 May 2025 01:28:08 -0700 (PDT)
Date: Fri, 30 May 2025 10:28:07 +0200
From: Michal Hocko <mhocko@xxxxxxxx>
To: David Hildenbrand <david@xxxxxxxxxx>
Cc: Baoquan He <bhe@xxxxxxxxxx>, Donald Dutile <ddutile@xxxxxxxxxx>,
Jiri Bohac <jbohac@xxxxxxx>, Vivek Goyal <vgoyal@xxxxxxxxxx>,
Dave Young <dyoung@xxxxxxxxxx>, kexec@xxxxxxxxxxxxxxxxxxx,
Philipp Rudo <prudo@xxxxxxxxxx>, Pingfan Liu <piliu@xxxxxxxxxx>,
Tao Liu <ltao@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
David Hildenbrand <dhildenb@xxxxxxxxxx>
Subject: Re: [PATCH v2 0/5] kdump: crashkernel reservation from CMA
Message-ID: <aDlsF5tAcUxo4VgT@tiehlicka>
References: <Z7dc9Cd8KX3b_brB@xxxxxxxxxxxxx>
<04904e86-5b5f-4aa1-a120-428dac119189@xxxxxxxxxx>
<427fec88-2a74-471e-aeb6-a108ca8c4336@xxxxxxxxxx>
<Z8Z/gnbtiXT9QAZr@MiWiFi-R3L-srv>
<e9c5c247-85fb-43f1-9aa8-47d62321f37b@xxxxxxxxxx>
<aDgQ0lbt1h5v0lgE@tiehlicka>
<a1a5af90-bc8a-448a-81fa-485624d592f3@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a1a5af90-bc8a-448a-81fa-485624d592f3@xxxxxxxxxx>
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri 30-05-25 10:06:52, David Hildenbrand wrote:
> On 29.05.25 09:46, Michal Hocko wrote:
> > On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
> > [...]
> > > I think we just have to be careful to document it properly -- especially the
> > > shortcomings and that this feature might become a problem in the future.
> > > Movable user-space page tables getting placed on CMA memory would probably
> > > not be a problem if we don't care about ... user-space data either way.
> >
> > I think makedumpfile could refuse to capture a dump if userspace memory
> > is requested to enforce this.
>
> Yeah, it will be tricky once we support placing other memory on CMA regions.
> E.g., there was the discussion of making some slab allocations movable.
>
> But probably, in such a configuration, we would later simply refuse to
> active CMA kdump.
Or we can make the kdump CMA region more special and only allow
GFP_HIGHUSER_MOVABLE allocations from that. Anyaway I think we should
deal with this once we get there.
> > > The whole "Direct I/O takes max 1s" part is a bit shaky. Maybe it could be
> > > configurable how long to wait? 10s is certainly "safer".
> >
> > Quite honestly we will never know and rather than making this
> > configurable I would go with reasonably large. Couple of seconds
> > certainly do not matter for the kdump situations but I would go as far
> > as minutes.
>
> I recall that somebody raised that kdump downtime might be problematic
> (might affect service downtime?).
>
> So I would just add a kconfig option with a default of 10s.
kconfig option usually doesn't really work for distro kernels. I am
personally not really keen on having a tuning knob because there is a
risk of cargo cult based tuning we have seen in other areas. That might
make it hard to remove the knob later on. Fundamentally we should have 2
situations though. Either we know that the HW is sane and then we
shouldn't really need any sleep or the HW might misbehave and then we
need to wait _some_ time. If our initial guess is incorrect then we can
always increase it and we would learn about that through bug reports.
All that being said I would go with an additional parameter to the
kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
otherwise. That would make the optimized behavior opt in, we do not need
to support all sorts of timeouts and also learn if this is not
sufficient.
Makes sense?
--
Michal Hocko
SUSE Labs
Return-Path: <linux-kernel+bounces-667787-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id EA56941E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:29:37 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id C62CD3B9EFA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:29:13 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id C320B217736;
Fri, 30 May 2025 08:29:29 +0000 (UTC)
Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7])
(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 C5876211A05
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:29:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593769; cv=none; b=VxodrlteZbCitiSnxUyE6Mt9J6CxgUj/z8sZYaIgDYKt/y7dUWQ7BAERbitU4xEb0RspQBf3HZxwe2/boZ/oRrrj2M5CuZ/W4BMCGi9WCp5HxOVJ69d476Mqw3OsA5lvvsT6/W3aO/0NlCznJaZjEINQSRsjRJyelmZIVZp7KDA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593769; c=relaxed/simple;
bh=zsu+yDkMEzb2harqD8aE1FdD6Jqia+PNCFH57/7eA3U=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=KiewlVIlW3rattXMoqqswLatj4yoIDJy3wTnVm1Ehg/AkusA1Zo57wUrYQ4pIaGXRepBzjIwMAL94qKhq9Dcw+HjsdGgknHVDG9DCjmtOMYfzOie8L7jZsaM2ZeBvSJX5fTyir8e3XzYvp7KBLBXOytv3YUfByGq4SVRfUCN2nk=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de
Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2])
by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKv71-00076R-2j; Fri, 30 May 2025 10:29:11 +0200
Received: from pty.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::c5])
by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKv70-000wlp-2I;
Fri, 30 May 2025 10:29:10 +0200
Received: from mfe by pty.whiteo.stw.pengutronix.de with local (Exim 4.96)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKv70-000oiP-1q;
Fri, 30 May 2025 10:29:10 +0200
Date: Fri, 30 May 2025 10:29:10 +0200
From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
To: Shengjiu Wang <shengjiu.wang@xxxxxxxxx>
Cc: Shengjiu Wang <shengjiu.wang@xxxxxxx>, robh@xxxxxxxxxx,
krzk+dt@xxxxxxxxxx, conor+dt@xxxxxxxxxx, shawnguo@xxxxxxxxxx,
s.hauer@xxxxxxxxxxxxxx, kernel@xxxxxxxxxxxxxx, festevam@xxxxxxxxx,
devicetree@xxxxxxxxxxxxxxx, imx@xxxxxxxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
carlos.song@xxxxxxx
Subject: Re: [PATCH v2 4/6] arm64: dts: imx943-evk: add sound-wm8962 support
Message-ID: <20250530082910.o5jg7s5ckbm6knms@xxxxxxxxxxxxxx>
References: <20250528015837.488376-1-shengjiu.wang@xxxxxxx>
<20250528015837.488376-5-shengjiu.wang@xxxxxxx>
<20250528083704.ne6wyoj6vcmy7azq@xxxxxxxxxxxxxx>
<CAA+D8AMDbenx8scnBZdABAxF8MaYsBRzxXZjgGhMRbCJ-1wwcw@xxxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAA+D8AMDbenx8scnBZdABAxF8MaYsBRzxXZjgGhMRbCJ-1wwcw@xxxxxxxxxxxxxx>
X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2
X-SA-Exim-Mail-From: mfe@xxxxxxxxxxxxxx
X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false
X-PTX-Original-Recipient: linux-kernel@xxxxxxxxxxxxxxx
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 25-05-30, Shengjiu Wang wrote:
> On Wed, May 28, 2025 at 4:37â?¯PM Marco Felsch <m.felsch@xxxxxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> > On 25-05-28, Shengjiu Wang wrote:
> > > Add WM8962 codec connected to SAI1 interface.
> > >
> > > Signed-off-by: Shengjiu Wang <shengjiu.wang@xxxxxxx>
> > > Reviewed-by: Frank Li <Frank.Li@xxxxxxx>
> > > ---
> > > arch/arm64/boot/dts/freescale/imx943-evk.dts | 79 ++++++++++++++++++++
> > > 1 file changed, 79 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> > > index ff6e9ac5477f..da08aaa95904 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
> > > +++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> > > @@ -36,6 +36,15 @@ reg_usdhc2_vmmc: regulator-usdhc2 {
> > > enable-active-high;
> > > };
> > >
> > > + reg_audio_pwr: regulator-wm8962-pwr {
> > > + compatible = "regulator-fixed";
> > > + regulator-max-microvolt = <3300000>;
> > > + regulator-min-microvolt = <3300000>;
> > > + regulator-name = "audio-pwr";
> > > + gpio = <&pcal6416_i2c3_u171 12 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > + };
> > > +
> > > reserved-memory {
> > > ranges;
> > > #address-cells = <2>;
> > > @@ -50,6 +59,21 @@ linux,cma {
> > > };
> > > };
> > >
> > > + sound-wm8962 {
> > > + compatible = "fsl,imx-audio-wm8962";
> >
> > Out of curiosity did you considered making use of "audio-graph-card2"?
> >
> > The "fsl,imx-audio-wm8962" seems like a pretty simple sound card which
> > could be added via the "audio-graph-card2" as well. Don't get me wrong,
> > it's not wrong what you're doing here but making use of the generic
> > sound card would be nice because it's very common to just copy'n'paste
> > the audio integration from the corresponding evk.dts file.
>
> Thanks for the suggestion.
>
> WM8962 has a function .set_pll(), which hasn't been supported in
> audio-graph-card2. so we still use fsl,imx-audio-wm8962.
Thanks for the explanation.
Regards,
Marco
Return-Path: <linux-kernel+bounces-667788-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 2872141E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:29:49 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id A45517A3518
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:28:28 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 32E2D219313;
Fri, 30 May 2025 08:29:32 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="qlqUo963";
dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="qlqUo963"
Received: from AM0PR02CU008.outbound.protection.outlook.com (mail-westeuropeazon11013034.outbound.protection.outlook.com [52.101.72.34])
(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 6FC47213E65
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:29:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.72.34
ARC-Seal:i=3; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593771; cv=fail; b=VEASZDvjuU7oAK0KR9iEQLuadeZ43IGtRJoW6H4369lsAsASbu5Xlp2a2BOzj5urihzJ3vux96tRhD8HnUysKtD1ml1Hpe3HJwB8dXZ616nCjWKWnMQx729D4RzTdHZXsxM1DCGjQGvMQZssE54CsTBrxLlwyH3jBGXECU0w8nA=
ARC-Message-Signature:i=3; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593771; c=relaxed/simple;
bh=I1lxv7JYTRde3LlIIYp9mSWyh/1PL/W7pe7QOxGdR2g=;
h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:
Content-Type:MIME-Version; b=faZGjUg1hALnLrSMfyFz2uJ02rYYuUGFI1Ynnk7VpB77LZ1biqAD2nn1D2MRM0S7Vz5GWWdPeF89wCzhxLeAWs25iuB8TzvuZ7qkE2HMIGdGCMKy6l+tJ1hM2J5pDfFL2KnV2c+DBDcPT+rViOaY978l2rM9kwZDQzm2CVIfp6I=
ARC-Authentication-Results:i=3; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=qlqUo963; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=qlqUo963; arc=fail smtp.client-ip=52.101.72.34
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
b=LnsX5hoGjLLd3EBSdNt1/5noqjWCTT+bEPIDErjJ4v2qYFLlwH+kun9h9PRDDu949UT0mPntdpKK2nz2g5gGrSc9UAaha74wsa8gVcHEtL6frV8/GiVzYNTnrTGVwid6b7vVKphe2wfDre30gHsRl2muUJ7bsTRADnVo4GHJAHoarYfE2O0tUTJL344gBtxRgCOgr3rp4TGS7y4z9dgARCaCM3Lqg2I8Jvea3sanZUIKyxNqP4zcy+kxZROQUiMUz4pK0lc0cGHhGMNhSHikUwPypjaYsIsbf+Fh9ervFGWc3Z2dybksxCeCOrYaCx8eibTNMYVBrX+khX6oywS/wg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=9yeugcOlSAfRUVawGznYjSgv0FXKDheLeQggq4EOYTo=;
b=Cn861EaiolX7PBAriT/TR3po5WBLwBRS7k92QQg1xXWEI8mpaZhQRTdREMexr1OPdjAa/FJ9iusYAyv/pF5V/v7uY00s095F9u/OfwB9bSPvYNhYW2fTGl4dqX+FKbaIJ0Gbot4k2F1DUvwcfQrQvj7TjOnM19ufDhF+IiHICD5iz/gtTgnHzYhTAmYCrpveiK73AjC7WGezLkZ850V5Aasn3CEqHwvXH1MWFuFFZNLYzjxndlcIqxGkG+eR/uNoQMpob+H9DN11GM1E1kET56z8PIe65oCtVeKew+Pc1HoR0UCHXTwkERSayagHRkQC8HHtk/LzqrsJ6L+c8E1hCw==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass
(p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
(signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=9yeugcOlSAfRUVawGznYjSgv0FXKDheLeQggq4EOYTo=;
b=qlqUo963BBsTwQNxdIIoQsSnDP6RMyb/rf0GJq6YmSOv+iqAa7VK0gfGwNaEneHkD1HtPV5XZsJjZqLtNwnLlJlH2e2Nl1bMq7BBaTOwnR5tiYAk2OzcqstHuL/lN4rZeiGrZ8J8f0NQ9blKf8b6OEEmLuSlJNy7Aw5x8KcVxnw=
Received: from JNAP275CA0001.ZAFP275.PROD.OUTLOOK.COM (2603:1086:0:4c::6) by
PAWPR08MB10282.eurprd08.prod.outlook.com (2603:10a6:102:35c::19) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.30; Fri, 30 May
2025 08:29:23 +0000
Received: from AM3PEPF0000A79B.eurprd04.prod.outlook.com
(2603:1086:0:4c:cafe::1f) by JNAP275CA0001.outlook.office365.com
(2603:1086:0:4c::6) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Fri,
30 May 2025 08:29:21 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
smtp.mailfrom=arm.com; dkim=pass (signature was verified)
header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
4.158.2.129 as permitted sender) receiver=protection.outlook.com;
client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
AM3PEPF0000A79B.mail.protection.outlook.com (10.167.16.106) with Microsoft
SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
via Frontend Transport; Fri, 30 May 2025 08:29:21 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=J5JeJESBfXgrRbjPBsIOKzWMDqLQM9MqPyr816KaxJ/3DfwG+sQLOB2qXXBrnjgxSthzJfy09GdTCd0QnAuexKUpkIFMfRp1LSxDu1fcIx9tIAKzycB0U5nMacXgbHFciIaXQPwdsrULam8evCQmQ+15YKUFCJg5/ZiVMOtfrgP8DevDCixdbv4MUaFq3WCTcIJVD4D5ohmVQioT43jvQMGQ3RW+PNolwv1SSgW/NSgMHDo4nfdVRzwAGuuPVNvBJOnxz5927MC/hjb+UW55XVrnxr6WbcRuysLB1ikNyMq7QgJON9vSXpMF9zCOP92XChdj2HbNYYNj+DM/DAl3iQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=9yeugcOlSAfRUVawGznYjSgv0FXKDheLeQggq4EOYTo=;
b=DK/CEzchsC19KGKUDaKNSWuQc6t/VNZwYi/rYJR9cqtCfRO90kp3pbz7mOH5ltlTGOxyWcBENhhnMte4EwV81dIAU3dWZwyCxDP/+Ur7BmUgV24wuZXq2OQzEOhwcozQ4PND769S9I7vgO+xv3ZnVmJLbgyeYo5HAon5+6kpfE8ihybF/0ZKA1/rfu8R8x/dOHArlxpxiHaxwKpMHphgGxZkn+5Prver/Mw7OqoqsLH4sjuaIZjdrU0ZD7j+qReP1/oqAphZ+h3ojx2vPTLJmgwzxQqiR2FvZFhbGmDezfT2+zKUDq1PhvCHBeIlkGkeEwLtMbB1zRKSt3xyfZ7LjA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=9yeugcOlSAfRUVawGznYjSgv0FXKDheLeQggq4EOYTo=;
b=qlqUo963BBsTwQNxdIIoQsSnDP6RMyb/rf0GJq6YmSOv+iqAa7VK0gfGwNaEneHkD1HtPV5XZsJjZqLtNwnLlJlH2e2Nl1bMq7BBaTOwnR5tiYAk2OzcqstHuL/lN4rZeiGrZ8J8f0NQ9blKf8b6OEEmLuSlJNy7Aw5x8KcVxnw=
Authentication-Results-Original: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=arm.com;
Received: from AM9PR08MB7120.eurprd08.prod.outlook.com (2603:10a6:20b:3dc::22)
by PA4PR08MB5965.eurprd08.prod.outlook.com (2603:10a6:102:f3::19) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Fri, 30 May
2025 08:28:47 +0000
Received: from AM9PR08MB7120.eurprd08.prod.outlook.com
([fe80::2933:29aa:2693:d12e]) by AM9PR08MB7120.eurprd08.prod.outlook.com
([fe80::2933:29aa:2693:d12e%2]) with mapi id 15.20.8769.025; Fri, 30 May 2025
08:28:47 +0000
Message-ID: <6e21b6da-cdb7-48ce-96e3-e00fa52345a4@xxxxxxx>
Date: Fri, 30 May 2025 13:58:42 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: Enable vmalloc-huge with ptdump
To: catalin.marinas@xxxxxxx, will@xxxxxxxxxx
Cc: anshuman.khandual@xxxxxxx, quic_zhenhuah@xxxxxxxxxxx,
ryan.roberts@xxxxxxx, kevin.brodsky@xxxxxxx, yangyicong@xxxxxxxxxxxxx,
joey.gouly@xxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, david@xxxxxxxxxx
References: <20250530082021.18182-1-dev.jain@xxxxxxx>
Content-Language: en-US
From: Dev Jain <dev.jain@xxxxxxx>
In-Reply-To: <20250530082021.18182-1-dev.jain@xxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: MA1PR01CA0181.INDPRD01.PROD.OUTLOOK.COM
(2603:1096:a01:d::19) To AM9PR08MB7120.eurprd08.prod.outlook.com
(2603:10a6:20b:3dc::22)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
AM9PR08MB7120:EE_|PA4PR08MB5965:EE_|AM3PEPF0000A79B:EE_|PAWPR08MB10282:EE_
X-MS-Office365-Filtering-Correlation-Id: 12d2056d-6bde-4238-b8a8-08dd9f541397
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|366016|376014|1800799024;
X-Microsoft-Antispam-Message-Info-Original:
=?utf-8?B?OXQwZ2d1N1pjeGJPazlNM294SXFPaDhQTmJpeHd6UjZoTVRUdlhtZDBzQ0c0?=
=?utf-8?B?WHFxakV4SWVRSHl5czNMSk0wb09KN21icTBLV3Z1SzRrUGdYZUFic1YyNjd4?=
=?utf-8?B?STNPM2hHMG0vQUlYbGpKQmdCd3kxQmlPZU9mWU1LMjRkS1ZrWkpCWC8rL1Jx?=
=?utf-8?B?MUJ2dFp0aUN3dHJpY1l0ZkJPNzllUFBlSHBaWUE2MjhPM2I0aGdsZVNOL1dN?=
=?utf-8?B?L1FPYXM0NGtYS1BMUUZycmw2SEh5TGpXcWFBRVFlY2o0MG1TMmtiU3BQdmZ6?=
=?utf-8?B?eVVjRUprOGlKS0FjY0NBMmtHdzhydVFqVlZHUVlFYUQ2RnFtaUxFdnhsbkxG?=
=?utf-8?B?NDl4S3VpaSsrdGlQYlAvSU1iZmpCajBNNXpiOGQxdTBCTUxBbmp4cFNTZnIx?=
=?utf-8?B?a0N5cHNXL0E2V2FaWXRjMXMxenNUbHQvRmVZK0JYRDFiY2wyY3ZjNkhHQVFP?=
=?utf-8?B?eFB6N1dqVHVRdWFsS09YWHEvYXRWTHBpZ0pPYzRFRmh4SzhGclhoczc5SXdp?=
=?utf-8?B?SlNoVDFFQy96Ly9zVEZBdXUvMGxRRlh5TnZhZHJoOHpqc2tUSk51S3FRbzFC?=
=?utf-8?B?MUQrRlFqQkx3d29XcENlQXBLSXpZa0NjQW5IZklOcnAvR1lURVBCWElFUU9U?=
=?utf-8?B?elR2K0w4cVJXZmFmM2kvYjZSUHJjdGNNRjNrMkVDT0x2VVVYNFV0ZTlXVVpJ?=
=?utf-8?B?UTNzdlgzTzBYblVINkxFZVNvQjR5Q0lCZHJjakpraUswK1F4eFU4cjJqcTVW?=
=?utf-8?B?MmpweGN3OG43NFRRUW1HVHlVK0t5Y2p4dUtDUmlua1Q4WnZydzJtZUJjSXJk?=
=?utf-8?B?NTQ0MXl6T1ZmcmtSbDhrOUZERUZhMVRwcWt5eW9OaUhHaVJucDgrTnRFTWNJ?=
=?utf-8?B?YSs2NzRDQXlPSllCaDJxa1FGVjBTVjc2M1R5SzVOWU0yWTkwc1hYc05ybkF2?=
=?utf-8?B?YUNaRk9rZS9mS3lkT0RLS1VyK0dTK0xnUWk0aWlJWUdjbEd0RFZFT1dQcmZl?=
=?utf-8?B?ZDhCRHFkSHI5VGEwYkl0YlF6MXBuVTh2UEgvOHFPeWdqdEkvV0N3Mk03ODFU?=
=?utf-8?B?bTNuTzFJNnJ3L2JRRkhBYURnNnNPNmk3eDFReVAxWiszRHpPNjdXeTJIUkNz?=
=?utf-8?B?OHg3S2JEbDJoN01lTzFybUV2Q1N3NUdmTURNNmNkR1FLNHRlVktHa0h2SlNY?=
=?utf-8?B?Um1wQ0FmSkhCdFBqWGFZSlZkNGJsVmZVMnI3RlJtbWUvMVROR1U3ZHNnOEFL?=
=?utf-8?B?dzI0dnN3T01samJ5WWZwR1hSQjgrR3NUbnRXY3QxWEJ6RlNrM3lqSmIwUXNI?=
=?utf-8?B?NHQydmZjbXdsR3lQOTI5SXRKdTRnU3BNd0ExZ3pScFVOOGE4NVpoOG5PQmNJ?=
=?utf-8?B?MVhTWUNDQ1VjOXRRenVXZVFmSU9zMXJmSHJneEwxVzhTS2JxR2hxTGpjZDNr?=
=?utf-8?B?MlVjakRnUFZZOGFxbzBiR1RwVjZuaUpEeHBGMjJCV29NaUMrcThFYStrK1FQ?=
=?utf-8?B?ZFp4LzE5bFpKcE9PRmo0U0dRTFVYUy8vYnVuQXUrR3lJZ0xoM3hOVUtGZFB4?=
=?utf-8?B?TDhyR3dHYWJvdDRSSEcvSEVzRFdRV1dWKzFNYnlUOU5VWkpKL2RQZ2FlRk1F?=
=?utf-8?B?OGdkUXFuemZMS1FjS3VQUStmc1hybzlWa3JtZVN3N3UyN0xRV1BRUCtwdnl6?=
=?utf-8?B?QTJsY1Q4cDRsRWhSQTFBK2puaEJSV1ZMVm02bmdySVRLREczRTZWaERrN3Zy?=
=?utf-8?B?V2pGTm1GVUE2a2IwUExpSWdYaEtMTlJoenZUWnNueHVSRTZiU3RQMTRrekNj?=
=?utf-8?B?ZHRxZnJFR2owWitPNjJCZ0l1WUhiRzdiZTJMd0swK3RyRFJXVlRNUVRNa0tF?=
=?utf-8?B?NVlvcTJzeHo3YzI4SGE4U3NydjVPblppS2JsL3RpMGlnMDF4M0lhVlczRmY5?=
=?utf-8?Q?TKHk3ryMprc=3D?=
X-Forefront-Antispam-Report-Untrusted:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR08MB7120.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(376014)(1800799024);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB5965
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
AM3PEPF0000A79B.eurprd04.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
9b38c661-d3c9-4dec-0ade-08dd9f53ff9f
X-Microsoft-Antispam:
BCL:0;ARA:13230040|14060799003|82310400026|1800799024|376014|35042699022|36860700013;
X-Microsoft-Antispam-Message-Info:
=?utf-8?B?YzE0c3R6eG1oV1pYMWdMNEJCckZaWkhGT1pxbnFmQ05mWXh4bmlSRjI4aFor?=
=?utf-8?B?QzRVYzc0UDVON294RkpXMytNQ0grSHJnRnJsMVlUa1h2ZmVwOEtKQUlWVzNT?=
=?utf-8?B?SGVDVGRzVW5UbUhpM3JIbUdlbHJTbHpjOXFpZ2V6NElnVG90REcycnhOQkJM?=
=?utf-8?B?REpTOU5BREpXL1Z5ZUNEM3lGNjZaQlhXaDhHbjVIanErdnRKNkhEOFY2cThi?=
=?utf-8?B?bkkvendKSDZ3ZnBLT0dkcHFWK3NiVjVZSG4xRWpUamk3QXVBQzdCR2xIUnRK?=
=?utf-8?B?VUtyelFLaXh0NHJ4RkhiZVFreW1LVDJzck9pdUxZRzdPZ0tMMHZHNUVFWWZj?=
=?utf-8?B?V0NtMzVxZkFUeElQMGxISFozRHpLV0k2OUhFbGRrb2FHZDVBWk1SRmhRdVhp?=
=?utf-8?B?T0pnL3JPRnNuN2lpZEFuc1VnVUR2bG9lTEYyOC8ybEt1b2lsUXNZTEhDbjBl?=
=?utf-8?B?amFIS1dneG4xcytGK3BtZUl3c3hsbnU2QktRRWlFVkRkZHNwa1VaejA0ck14?=
=?utf-8?B?cnlidkJmQ0Y3S3BXS3lFdlJSREFPMzAwYWtTMkwvMmZKT04rUnVwUGpTMUk0?=
=?utf-8?B?Wk9jdVRTY0ZNRmVlRnFVWmpLQ24rU2VkNnplNXFoc3V6QjFKYlpnTHVNK2d4?=
=?utf-8?B?K05JTXdmclAwazI0dlFSNGx1c1B1aEIyZzhjRmQ5elQ4Y2lwWGh6RzBOaXpQ?=
=?utf-8?B?Qzc2VHBRbVNEa2dPOEZIVVEzRi9WZVpaaGl1cGg5alc2OHZ6TjdCVERQeTdt?=
=?utf-8?B?WE5HWUxVWHN2elYrc0VYOXVBWW91SlNuM1VvelNpbVJwbDhDbENpdDM4VENX?=
=?utf-8?B?cnRWZmFrY0dRTDJ4SWZlUGJOZTdXSTRtUElzUGlUS1lMUTFKNFZDZHlFSTJv?=
=?utf-8?B?NUc0cjA2M1kwcTBWL2NPVzdNMmtDenNvNVlDbE0wK0Vzd0hlUXZ0YUlqbmtv?=
=?utf-8?B?R0FDbHBUaFVqY2NOR1R5dC9pR2RrTGJnZnNKWmx3czFJS2pzL1ZwUHVrQlk5?=
=?utf-8?B?OXN3b2wrL3lzZmpqSCswaS9KNkpYOG52Wk51OXF4MTRqS1NRWjRWbEVKMU5z?=
=?utf-8?B?TjJUQTBKSlpiVml5WEtObmFDOWVGTHpGc08yeEwzSlF6L3hxV0xQSFpKZ1Za?=
=?utf-8?B?N1p5TTcwTk9RZUNhTGJBMG4vWG5sTThGRmhqVW5BbFdLMWtKZkpIa0YydGxq?=
=?utf-8?B?czQ1bjhTTlo5L09QWEtaSlhDSlJCc3cwYWdNQ2hRWTVVajdFQ3UrUzFkM053?=
=?utf-8?B?QVRuQmNFdkI2MC8xbjdLZnM4YUg2Q3M2SVJ2dEJ4c0JPb1lpUGZDRzhBNHYv?=
=?utf-8?B?ektPOGE1MU0wZWhzbVhCYUVWN1haeHFLSUd4dkViUnlIdzhJVkgyZExNU1JU?=
=?utf-8?B?SXNkQkVZR1ZXb0ppSFJvWnpjQkpNZ2xRRjk4V3ZvdnBaSjRnL29QaXpnY0dB?=
=?utf-8?B?MTU0eXNPWG5nYTYrK0FKNGx1NldjK29MMEdtWVNSTGVxOTRabXBNeWx4cU1r?=
=?utf-8?B?QzB4RWRSektOOHloSERuNmRaVDdCRnJGN1ZpTHVIcGRHdDh5dTNmaFFYVzRY?=
=?utf-8?B?ZmZDcjlZblNuaXlFd3BtcnlnWU5YdmFhbmVRNkdGWktJbWhteXAvME9XSUdl?=
=?utf-8?B?V2tsVXM3Z3hSM3FHSytBNk5iNDdxQ0o4a0dNczRZbklab3hzZkVqc0d1YUtC?=
=?utf-8?B?Z1BuQklJQU4rejFhUXhyRHIwWHdmR3Y5elBEUWNObm5tMVNlSktrZytFb2R0?=
=?utf-8?B?WjN4RjRjUFh6cFJDaFM2YVNld1hZWmFoSnBwMHNSYTIrbnpUcnJVc3QyeUhi?=
=?utf-8?B?djVyUTdyVmxxUHpJeldtcnVEQ2hJWWNtaFEyZUF4aEJWTFJqRCtocXU4Y1Vn?=
=?utf-8?B?emd5OWtsNDRqNjJ1RkJoUzJvT3F6UG8yZ3NsSUFZN0pGVU0xVlpBb1NCK3A5?=
=?utf-8?B?L1IwbmdEUmVyY3F4dFgrNDhYaVNMbFQrRG03Tm9JeU5GMGh3ZkdLVHRPRmtC?=
=?utf-8?B?NzdXYWlIMXBZSmkxdjZ2MTlIWGVBZWhGU3BLemdIY0dha29xWWlzVzdQdEww?=
=?utf-8?Q?zECFm+?=
X-Forefront-Antispam-Report:
CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(14060799003)(82310400026)(1800799024)(376014)(35042699022)(36860700013);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:29:21.0342
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 12d2056d-6bde-4238-b8a8-08dd9f541397
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
AM3PEPF0000A79B.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAWPR08MB10282
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30/05/25 1:50 pm, Dev Jain wrote:
> arm64 disables vmalloc-huge when kernel page table dumping is enabled,
> because an intermediate table may be removed, potentially causing the
> ptdump code to dereference an invalid address. We want to be able to
> analyze block vs page mappings for kernel mappings with ptdump, so to
> enable vmalloc-huge with ptdump, synchronize between page table removal in
> pmd_free_pte_page()/pud_free_pmd_page() and ptdump pagetable walking. We
> use mmap_read_lock and not write lock because we don't need to synchronize
> between two different vm_structs; two vmalloc objects running this same
> code path will point to different page tables, hence there is no race.
I mean, there *is* a race, but there is no problem :)
>
> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
> ---
> arch/arm64/include/asm/vmalloc.h | 6 ++----
> arch/arm64/mm/mmu.c | 7 +++++++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
> index 38fafffe699f..28b7173d8693 100644
> --- a/arch/arm64/include/asm/vmalloc.h
> +++ b/arch/arm64/include/asm/vmalloc.h
> @@ -12,15 +12,13 @@ static inline bool arch_vmap_pud_supported(pgprot_t prot)
> /*
> * SW table walks can't handle removal of intermediate entries.
> */
> - return pud_sect_supported() &&
> - !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
> + return pud_sect_supported();
> }
>
> #define arch_vmap_pmd_supported arch_vmap_pmd_supported
> static inline bool arch_vmap_pmd_supported(pgprot_t prot)
> {
> - /* See arch_vmap_pud_supported() */
> - return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
> + return true;
> }
>
> #endif
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ea6695d53fb9..798cebd9e147 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1261,7 +1261,11 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
> }
>
> table = pte_offset_kernel(pmdp, addr);
> +
> + /* Synchronize against ptdump_walk_pgd() */
> + mmap_read_lock(&init_mm);
> pmd_clear(pmdp);
> + mmap_read_unlock(&init_mm);
> __flush_tlb_kernel_pgtable(addr);
> pte_free_kernel(NULL, table);
> return 1;
> @@ -1289,7 +1293,10 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
> pmd_free_pte_page(pmdp, next);
> } while (pmdp++, next += PMD_SIZE, next != end);
>
> + /* Synchronize against ptdump_walk_pgd() */
> + mmap_read_lock(&init_mm);
> pud_clear(pudp);
> + mmap_read_unlock(&init_mm);
> __flush_tlb_kernel_pgtable(addr);
> pmd_free(NULL, table);
> return 1;
Return-Path: <linux-kernel+bounces-667789-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 2B3F541E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:30:31 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 71A1717DF11
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:30:32 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 4E2AF211710;
Fri, 30 May 2025 08:30:26 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=fail reason="signature verification failed" (2048-bit key) header.d=hmeau.com header.i=@hmeau.com header.b="M35habH1"
Received: from abb.hmeau.com (abb.hmeau.com [144.6.53.87])
(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 808A31D9A49
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:30:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=144.6.53.87
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593825; cv=none; b=tPtRm0Mmye2AVDcOVx+hzmkFMpXgdNsxZ28gjAsWZ+ZGSqHUKZ2gOwnoVgcNOi4M6qAtHM9kWTCyqrseAdlmbsna+kQfl7t+SO1WZZhG7XZ/ut75HnQken07gUzXXCV6xnWUW+105SxYpdrvb+BdKVaue2g/qrnr8Iq8IqwtUxQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593825; c=relaxed/simple;
bh=uMvsKY9QEjvjwd7DFYGmn8OEokhLWAsX8TBQZAs4xdw=;
h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:
Content-Disposition; b=d/3wuz+T/pQ6r7Prwn6LHuX2xyf9M56Vuf8F4fDKgdQId/eSWb+KCiTlsPBzB67Fja8PTeUM7eRY4rjo4ljk+p335AToJEOWg1m9/NtWSxiC0/cMnvwA7qjEC9F20Z93Pb5N1KX2DFeDr/qV0Xx95GenTOuGJ61vw39Xsb19P7s=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au; spf=pass smtp.mailfrom=gondor.apana.org.au; dkim=pass (2048-bit key) header.d=hmeau.com header.i=@hmeau.com header.b=M35habH1; arc=none smtp.client-ip=144.6.53.87
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gondor.apana.org.au
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hmeau.com;
s=formenos; h=Content-Type:MIME-Version:Message-ID:Subject:Cc:To:From:Date:
Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=ls5MxaQepdo75i1874VZ8q0kWhIBVLloFn5NFQ+OlgA=; b=M35habH17koqH6T88PnFN9kRZ0
MGZvi5QaNzB22SaHZ5mBAUawPgO3ZlhsMAl7+UgnWSD85VKYCTi7MNEXcMA0/HRYukkGn+WNvXhsE
oi079+hTHAZuoiYLd5TDY2V405SpZUU2IUXAYeEFcysZSwjcUqkAw1ZDcwlC9splmw4UeHCOBrTO1
n+J9vfLDvlR4RNrriFue2AGQLQBOHuGb3pI9lOgegp7Nvb/Omly6Ui7oF3Tk6mdIGQGx0dqFus/z3
OksHFTkUc+cvyJ+rmR7QBv+bXsAKQfI30sOLxI2tVKsvshPpe2tG8VnH+PLCKqNzdt8pUgmrAgWOM
HQGTixBg==;
Received: from loth.rohan.me.apana.org.au ([192.168.167.2])
by formenos.hmeau.com with smtp (Exim 4.96 #2 (Debian))
id 1uKv7z-009joo-16;
Fri, 30 May 2025 16:30:12 +0800
Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Fri, 30 May 2025 16:30:11 +0800
Date: Fri, 30 May 2025 16:30:11 +0800
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
To: Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>,
Anna-Maria Behnsen <anna-maria@xxxxxxxxxxxxx>,
Frederic Weisbecker <frederic@xxxxxxxxxx>,
Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Andrei Vagin <avagin@xxxxxxxxx>, Dmitry Safonov <dima@xxxxxxxxxx>
Subject: [PATCH] time_namespace.h: Add struct seq_file forward declaration
Message-ID: <aDlskzKIAULMlwPj@xxxxxxxxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Add forward declaration of struct seq_file before using it in
function prototype.
Fixes: 04a8682a71be ("fs/proc: Introduce /proc/pid/timens_offsets")
Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
diff --git a/include/linux/time_namespace.h b/include/linux/time_namespace.h
index 0b8b32bf0655..bb2c52f4fc94 100644
--- a/include/linux/time_namespace.h
+++ b/include/linux/time_namespace.h
@@ -12,6 +12,7 @@
struct user_namespace;
extern struct user_namespace init_user_ns;
+struct seq_file;
struct vm_area_struct;
struct timens_offsets {
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Return-Path: <linux-kernel+bounces-667790-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9185441E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:30:59 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 655A67A81D2
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:29:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 5E27221772B;
Fri, 30 May 2025 08:30:52 +0000 (UTC)
Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7])
(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 5D7062116F4
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:30:50 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748593851; cv=none; b=kPVKS0+ekuQXrXUpZ7h+j54NuOgtEgAW+qGJ52w9KPUI3ZqQR0Z42nbLH/AGIEo42XwFsHBhrqZPiF3Y9fRvpprC8JTSOY4dPHqjd6ftA86t//aoT5p/vn+sMMuiNvH8bsYB8DzSL5czonpa70uHHogCB5cDnuGbYU0yuAppa2E=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748593851; c=relaxed/simple;
bh=64qScj2fNxS5xRxlTh1u81AIS0+t+p7HGyYWKUysbyY=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=S5NpQn6m88Qar1NLJm8jEuuFbP+oEg1Qty/l1wJZGuA5Mrd+jueqGonvcj8P4nVIoHIX5xwaBD2C1i5OPNHuAZS/XpbPmSmbQs+ISS27OnEiYsCAp9/STzJqd4XV2OxUX0KioXyHq+ZgMjlOILq/GXM6DZ/nkk/gYr13PhpKsag=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de
Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2])
by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKv8M-0007q5-27; Fri, 30 May 2025 10:30:34 +0200
Received: from pty.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::c5])
by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKv8K-000wm3-3C;
Fri, 30 May 2025 10:30:33 +0200
Received: from mfe by pty.whiteo.stw.pengutronix.de with local (Exim 4.96)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKv8K-000oiq-2n;
Fri, 30 May 2025 10:30:32 +0200
Date: Fri, 30 May 2025 10:30:32 +0200
From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
To: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
Cc: Luis Chamberlain <mcgrof@xxxxxxxxxx>,
Russ Weight <russ.weight@xxxxxxxxx>,
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>,
"Rafael J. Wysocki" <rafael@xxxxxxxxxx>,
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>,
Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>,
Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>,
Kamel Bouhara <kamel.bouhara@xxxxxxxxxxx>,
Marco Felsch <kernel@xxxxxxxxxxxxxx>,
Henrik Rydberg <rydberg@xxxxxxxxxxx>,
Danilo Krummrich <dakr@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
devicetree@xxxxxxxxxxxxxxx, linux-input@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v2 2/4] dt-bindings: vendor-prefixes: Add TouchNetix AS
Message-ID: <20250530083032.lszndbodo2tgixu6@xxxxxxxxxxxxxx>
References: <20250529-v6-10-topic-touchscreen-axiom-v2-0-a5edb105a600@xxxxxxxxxxxxxx>
<20250529-v6-10-topic-touchscreen-axiom-v2-2-a5edb105a600@xxxxxxxxxxxxxx>
<1e5bd735-3eb5-40da-9e4d-12aa364e1cb3@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1e5bd735-3eb5-40da-9e4d-12aa364e1cb3@xxxxxxxxxx>
X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2
X-SA-Exim-Mail-From: mfe@xxxxxxxxxxxxxx
X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false
X-PTX-Original-Recipient: linux-kernel@xxxxxxxxxxxxxxx
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 25-05-29, Krzysztof Kozlowski wrote:
> On 29/05/2025 00:08, Marco Felsch wrote:
> > From: Kamel Bouhara <kamel.bouhara@xxxxxxxxxxx>
> >
> > Add vendor prefix for TouchNetix AS (https://www.touchnetix.com/products/).
> >
> > Signed-off-by: Kamel Bouhara <kamel.bouhara@xxxxxxxxxxx>
> > Signed-off-by: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
> > ---
> > Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> How v16 became v2 is still confusing:
>
> https://lore.kernel.org/all/20240703142520.207066-2-kamel.bouhara@xxxxxxxxxxx/
As explained within the v1, I started from a fresh v1 due to the
complete rework.
Regards,
Marco
Return-Path: <linux-kernel+bounces-667791-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 065EF41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:33:31 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id CBCA11BA06D5
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:33:44 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id DCD372185BC;
Fri, 30 May 2025 08:33:24 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="e7EOwHE/"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
(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 10FF72116F4
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:33:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594003; cv=none; b=gKt6zBr3HTpGECpAwuRaf8Sim5Mw0pg+7ARgEggPyJ7QJhkSaTtqZc7rFy7DcOo8USYxiHSfNAXlY7wBCBZyX6FKaRyELLgehTKKi0cailNMUHsSV7cylU4bjS5p2guhcyKENY05+Cy/URIxZJQ0U/gQOWqW2TleHz7hR/11i4I=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594003; c=relaxed/simple;
bh=vQBaYMlKWN8JmoqRvx19u6asWfbiXRcDQomdkOK7UzM=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=dzu/xTXtF6ZWbPtoXOeXhjtoIHLm27zMXrJkIu1jWdQb3fStD8qn1OlklQk6xjWKC3Z+dVCWHP37uCg9x3/AalcFIvy82HVT5Y3ZQusHc5gNyRTg+vK8r/cPnB3iYbwp/aacfz/OM2zG/OaLO9wzfahpdqIMxjih6cRd91pIJRU=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=e7EOwHE/; arc=none smtp.client-ip=170.10.133.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748594000;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=KXrmciw8fw3IVBDeiE8IPSrAAHDX+SY7wQ0MY8GKbnM=;
b=e7EOwHE/45MMJTDiL5gd9vqi+FtaQszq/wNWJxeZxQ+77RRDkCkU396sL0TvNx5v/6M8b8
iQ6dem2Hbs5U/CjDyQEh2AeC2rNjF1zTjCp+LmEATvXp7/yr86VB0Wu6GKgMHquroBf1O8
IffNKwrn9qJIQ74iXNqN0qXjEfvIlLE=
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
[209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-204-by8XyKquOta_bLItEDorag-1; Fri, 30 May 2025 04:33:19 -0400
X-MC-Unique: by8XyKquOta_bLItEDorag-1
X-Mimecast-MFC-AGG-ID: by8XyKquOta_bLItEDorag_1748593998
Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-450d021b9b1so5904365e9.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:33:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748593998; x=1749198798;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=KXrmciw8fw3IVBDeiE8IPSrAAHDX+SY7wQ0MY8GKbnM=;
b=AS7b+Q7SWtfzSVohJDtulNOA3INagV1L1Avs0bKM9hh2rS6SxBjZGOvSttAxCb31jW
4ZmdsLZZBPTjQO7sntgYQ4adprbZojd3Lp2BD8l7D7hactUUFQKZlnjLW8pZwcKTW58r
nvxVklEASpKQ20JoHZ5dMwpbwTuMgU1h2pi5cO9lMXr4LKQtTxY0UxurXTAKMbsR+raO
qbbk9kN6H16EZu87l7bXoZl6Uvntni7lmrXfKmx+mxYMaiz0CisRpjplL/KjJaCh1aqF
5MzFJgvUzJG56uOLkDDHAj6gAdyJnwvb7yBLVar8OA8aDxZpd1iCKZ05EU/gdD7tZU18
xaEw==
X-Forwarded-Encrypted: i=1; AJvYcCV7HCoGbZIunLuiT6kkcYdjBsEreeThcZTF4jpjYl3DMB8O4+JKiCPgMJj4K/E9cf+bNlYxNf9ZQu9ZOdU=@vger.kernel.org
X-Gm-Message-State: AOJu0YyMFL4F+H0QMPi1jksU1xfPbzKEQ++5wHpA+6VGSeKqLWp1cpbT
U9BWxeB5K7UGeJxO+gSdDUSMXkF8mMZZdZp25CYV8dxQhRKZzDOKXkskxzSc0PRe27u7YVw5fRH
82KFVqN+Ktfs9iMIvHTZ4rXHaaE6KRPBlclmpWO10PIk8KillI/1/IVE8GXvX2wdgow==
X-Gm-Gg: ASbGncu0ghyjOsWebXyuykdVuK0rcjKeq73hWbxyVyi+bvgX0cxvrYxIJrls21esY3s
a+KawPSaWWYvyvvCHuF17UWwCucHFX2sMLXNA9telUAP2TtIJYv0d6Yp5yVfwVAq3LOpWnQY7B0
soSqn3TMptjS72Et8BiMfnxnmlu8NulM9BBgXNox3UIXM7UI4z/n4T7QGJsrQCwk1E4Jnzdpgjp
hp+jcziIWsgInwEEQDdfjAAblFlkTQ4pJhDOpNYy/8M78RpYKfPHjNw4mffjSKv8HPSld3+wc1v
qFOmjgDtiNvv22EGebG0JMwbSeyITYhCPv2lKHpKV0R+R4CkwwHbHChlI0DY0Oi66TCfeqNQ0tb
KcccPPJRVMAN1Gz1jimY6MxDImLphHXk9ad7C8AE=
X-Received: by 2002:a05:600c:8509:b0:43c:e467:d6ce with SMTP id 5b1f17b1804b1-450d64c313cmr24746715e9.4.1748593998068;
Fri, 30 May 2025 01:33:18 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHVcr8PZ5QbPXx9wYXWNy5yUlTGaH5PzQJYlbqrT8pMQ5rU+6cBIGsOcxKenkA6npxlPlPeIg==
X-Received: by 2002:a05:600c:8509:b0:43c:e467:d6ce with SMTP id 5b1f17b1804b1-450d64c313cmr24746415e9.4.1748593997547;
Fri, 30 May 2025 01:33:17 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f009fdbasm4086329f8f.85.2025.05.30.01.33.16
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:33:17 -0700 (PDT)
Message-ID: <ccf359b0-8baa-4209-b2c3-75e3813ca804@xxxxxxxxxx>
Date: Fri, 30 May 2025 10:33:16 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when
expanding vma during mremap
To: Pu Lehui <pulehui@xxxxxxxxxxxxxxx>, Oleg Nesterov <oleg@xxxxxxxxxx>
Cc: lorenzo.stoakes@xxxxxxxxxx, mhiramat@xxxxxxxxxx, peterz@xxxxxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx, vbabka@xxxxxxx,
jannh@xxxxxxxxxx, pfalcato@xxxxxxx, linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, pulehui@xxxxxxxxxx
References: <20250521092503.3116340-1-pulehui@xxxxxxxxxxxxxxx>
<62b5ccf5-f1cd-43c2-b0bc-f542f40c5bdf@xxxxxxxxxx>
<afe53868-5542-47d6-8005-71c1b3bec840@xxxxxxxxxxxxxxx>
<13c5fe73-9e11-4465-b401-fc96a22dc5d1@xxxxxxxxxx>
<4cbc1e43-ea46-44de-9e2b-1c62dcd2b6d5@xxxxxxxxxxxxxxx>
<20250526154850.GA4156@xxxxxxxxxx>
<06bd94c0-fefe-4bdc-8483-2d9b6703c3d6@xxxxxxxxxx>
<57533126-eb30-4b56-bc4d-2f27514ae5ad@xxxxxxxxxxxxxxx>
<cba0155e-d2b9-41fa-bc51-f3738ae73cff@xxxxxxxxxx>
<956124be-c73c-4023-9edd-25372f3f865a@xxxxxxxxxxxxxxx>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <956124be-c73c-4023-9edd-25372f3f865a@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 29.05.25 18:07, Pu Lehui wrote:
>
> On 2025/5/28 17:03, David Hildenbrand wrote:
>> On 27.05.25 15:38, Pu Lehui wrote:
>>> Hi David,
>>>
>>> On 2025/5/27 2:46, David Hildenbrand wrote:
>>>> On 26.05.25 17:48, Oleg Nesterov wrote:
>>>>> Hi Lehui,
>>>>>
>>>>> As I said, I don't understand mm/, so can't comment, but...
>>>>>
>>>>> On 05/26, Pu Lehui wrote:
>>>>>>
>>>>>> To make things simpler, perhaps we could try post-processing, that is:
>>>>>>
>>>>>> diff --git a/mm/mremap.c b/mm/mremap.c
>>>>>> index 83e359754961..46a757fd26dc 100644
>>>>>> --- a/mm/mremap.c
>>>>>> +++ b/mm/mremap.c
>>>>>> @@ -240,6 +240,11 @@ static int move_ptes(struct
>>>>>> pagetable_move_control
>>>>>> *pmc,
>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (pte_none(ptep_get(old_pte)))
>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>>>>>>
>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â /* skip move pte when expanded range has uprobe */
>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (unlikely(pte_present(*new_pte) &&
>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â vma_has_uprobes(pmc->new, new_addr,
>>>>>> new_addr +
>>>>>> PAGE_SIZE)))
>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>>>>>> +
>>>>>
>>>>> I was thinking about
>>>>>
>>>>> Â Â Â Â Â WARN_ON(!pte_none(*new_pte))
>>>>>
>>>>> at the start of the main loop.
>>>>>
>>>>> Obviously not to fix the problem, but rather to make it more explicit.
>>>>
>>>> Yeah, WARN_ON_ONCE().
>>>>
>>>> We really should fix the code to not install uprobes into the area we
>>>> are moving.
>>> Alright, so let's try this direction.
>>>
>>>>
>>>> Likely, the correct fix will be to pass the range as well to
>>>> uprobe_mmap(), and passing that range to build_probe_list().
>>>
>>> It will be great. But IIUC, the range we expand to is already included
>>> when entering uprobe_mmap and also build_probe_list.
>>
>> Right, you'd have to communicate that information through all layers
>> (expanded range).
>>
>> As an alternative, maybe we can really call handle_vma_uprobe() after
>> moving the pages.
>
> Hi David,
>
> Not sure if this is possible, but I think it would be appropriate to not
> handle this uprobe_mmap at the source, and maybe we should make it clear
> that new_pte must be NULL when move_ptes, otherwise it should be an
> exception?
Yeah, we should ay least document that if we find any non-none pte in
the range we are moving to, we have a big problem.
I think the main issue is that vma_complete() calls uprobe_mmap() before
moving the page tables over.
If we could defer the uprobe_mmap() call, we might be good.
The entry point is copy_vma_and_data(), where we call copy_vma() before
move_page_tables().
copy_vma() should trigger the uprobe_mmap() through vma_merge_new_range().
I wonder if there might be a clean way to move the uprobe_mmap() out of
vma_complete(). (or at least specify to skip it because it will be done
manually).
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667792-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 41DB141E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:33:58 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 7D02A7A246D
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:32:39 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 75B0121931E;
Fri, 30 May 2025 08:33:45 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=gmx.net header.i=wahrenst@xxxxxxx header.b="CqdzUzG7"
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21])
(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 40F5721578F;
Fri, 30 May 2025 08:33:40 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=212.227.17.21
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594024; cv=none; b=uri4HlC8foAnoaY/7EXATuwxe98fkC5PK82+xZ0f8qWefX7A1le5BH7raG3+IOO8d7dLSCpIa3tQETIZpKFu2uM1Up9aUg3cGFDlpW0Q3nzpQE6J4uKDrLQkSpRTNpAcBwTYvSM+jLunbuW8KVRczAkt3Tl91Q7CpjNMC41Oyr8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594024; c=relaxed/simple;
bh=lKLqZSSked+vdkCWaAgIsLAmGzJ6HjOLpIP3Jr7GRF0=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=o83jnbkqjC8Pxp3QBBlBRBt5zfMUCHB9gIxq6BLjZWDCd9MGgke6dfe21MMBw7gsA52/RSEHiADaaZhHKfsnaDLDVtSVZxIqG2Ib6r+Umv+VhgEw1T8bQvrWNGVwoXySrd1X5bHcG1Y6x39/uC56jlxMWUDk4uRRI05AHHiGJZk=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.net; spf=pass smtp.mailfrom=gmx.net; dkim=pass (2048-bit key) header.d=gmx.net header.i=wahrenst@xxxxxxx header.b=CqdzUzG7; arc=none smtp.client-ip=212.227.17.21
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gmx.net
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmx.net
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net;
s=s31663417; t=1748594010; x=1749198810; i=wahrenst@xxxxxxx;
bh=2/p2El0dWEgypg+Jj8YhT/c1tRaeZcl4lGb7TDH06KY=;
h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc:
References:From:In-Reply-To:Content-Type:
Content-Transfer-Encoding:cc:content-transfer-encoding:
content-type:date:from:message-id:mime-version:reply-to:subject:
to;
b=CqdzUzG7cteFLc3309P1Csiv80NJjzX9rfHi9e9nvFLlpmYm1WLyvHlQ37QX8eCT
/RZFnIiI6Cz1Zp1EP6DeGLx3QcjD85290vcQtXk4J6iOHRuaTis1hstX78NN1CKZG
tPT4MdM26nTvruDr/8Am9A39FwNQ2ijuZadP+kVTrT3Qf9nazj/ml/IVoTypxqJGT
9YJdYbT/qCnYYGzNXDssYQXEzlLw1pRmsI1R+yKlKPmTshUwt7Aal4NQ6nP9iy4ql
QQ3dpWuXHigfFuC+K9WKelEtJ7CwLy/dkZanoWKt9QiuxP6Ff85Sr8Byps3BUXKFI
3EE2+DyHm2c9FearvQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.1.104] ([91.41.216.208]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1MKsj7-1ub3v50UJx-00Rwqx; Fri, 30
May 2025 10:33:30 +0200
Message-ID: <047fb49e-1ca8-43a6-b122-0d6fa9a61c74@xxxxxxx>
Date: Fri, 30 May 2025 10:33:28 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 1/1] dt-bindings: net: convert qca,qca7000.txt yaml format
To: Frank Li <Frank.Li@xxxxxxx>, Andrew Lunn <andrew+netdev@xxxxxxx>,
"David S. Miller" <davem@xxxxxxxxxxxxx>, Eric Dumazet <edumazet@xxxxxxxxxx>,
Jakub Kicinski <kuba@xxxxxxxxxx>, Paolo Abeni <pabeni@xxxxxxxxxx>,
Rob Herring <robh@xxxxxxxxxx>, Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>,
"open list:NETWORKING DRIVERS" <netdev@xxxxxxxxxxxxxxx>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@xxxxxxxxxxxxxxx>, open list <linux-kernel@xxxxxxxxxxxxxxx>
Cc: imx@xxxxxxxxxxxxxxx
References: <20250529191727.789915-1-Frank.Li@xxxxxxx>
Content-Language: en-US
From: Stefan Wahren <wahrenst@xxxxxxx>
Autocrypt: addr=wahrenst@xxxxxxx; keydata=
xjMEZ1dOJBYJKwYBBAHaRw8BAQdA7H2MMG3q8FV7kAPko5vOAeaa4UA1I0hMgga1j5iYTTvN
IFN0ZWZhbiBXYWhyZW4gPHdhaHJlbnN0QGdteC5uZXQ+wo8EExYIADcWIQT3FXg+ApsOhPDN
NNFuwvLLwiAwigUCZ1dOJAUJB4TOAAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJEG7C8svCIDCK
JQ4BAP4Y9uuHAxbAhHSQf6UZ+hl5BDznsZVBJvH8cZe2dSZ6AQCNgoc1Lxw1tvPscuC1Jd1C
TZomrGfQI47OiiJ3vGktBc44BGdXTiQSCisGAQQBl1UBBQEBB0B5M0B2E2XxySUQhU6emMYx
f5QR/BrEK0hs3bLT6Hb9WgMBCAfCfgQYFggAJhYhBPcVeD4Cmw6E8M000W7C8svCIDCKBQJn
V04kBQkHhM4AAhsMAAoJEG7C8svCIDCKJxoA/i+kqD5bphZEucrJHw77ujnOQbiKY2rLb0pE
aHMQoiECAQDVbj827W1Yai/0XEABIr8Ci6a+/qZ8Vz6MZzL5GJosAA==
In-Reply-To: <20250529191727.789915-1-Frank.Li@xxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:isti/zcoHy0BEPlRv23mXJO9AD6oexaCEeq77RC7QWT+4jf8EII
XErB8E55qPRLDnleeDzx7sG70eOhbf8l5z9dZVPBZBNskaFb31/hqXg/NwTAXfeHGFyV7gX
Iy3DNfhycz/As7Hfnb7byZru2eRVw7DFpWn6WBQNWlVSTtExGsEWY0jbaBcaoURifbWdkKM
6fO8/ZktLeaHPHmAHrPVw==
UI-OutboundReport: notjunk:1;M01:P0:HdZVyM2zHok=;AO9swPmz1nmw6FhCXNGHJV28Nxs
nzg1YKrZSrDZZHfEDd/CHN2Ybq7mldYg8D0WqVnsACT7DsSv63LVCTePIOStl0uHzikzOxsx+
yftm6Mlg5MD+LWY4TlEqpUbRYJJQGFnzJhG13YWyUwi5joKpy9fDOyi+ByboxKj/7fV+4lrRk
45+rMlrzBi23NSRhH6bhkDIml6cks4QJvz51btwu782sRlrycrmr6UIupWtFEXYWi/78CMwLx
bG//dTze/Wbtbs7KcqGXeNpv4ntfr5s+/WMsPahdalqRPmggfGEgdyfi7VOwSbnueapinLLS/
aBHuFJx0VfyGIVtzfDMFCjcI+VsQ4ANhX7bsip64v9fzHkoGwTqSxNPr5vs88DOkguhX9jeKk
eXXGWC+rDDCezyu1ZGC5YnDxouHmA2k89gbROuFpXid5iRIrfekn2ZHluRpKwvpm84XNy2XRR
fnlZagmvQzmH8LrrU0JmALDmmAWcNJ1q7Rp4dsu30/kk52mgVoJPxQfQlCn0I7c43pHf0TKo4
puOoWU0jf6UDAv3ldeCUyMzhmnpkjNud58dnHK8d8x+DXfbyUQskH4stTyo3efMSZ3LbbEpZd
4ZkrvSbQEAKCkYXmZQPKefzVARC7n2z+qEVF94hg8omvqPa4f0YEz5Uy0aZxqbSN/D3CF2m84
nhEhmVhuAyeTALPvabJcm0TySd+WHhJ0lxnwbHve9CAjUetzsXSriOuZjQtzpIxcclkdGcUqS
MQWNxUQMyEaWwAK/i3BqGVEPuiHs0qLCqoxPqDOO4vSyD5tWGErRsyvBSCJ0eFHd8xqzeAc8L
ulqkv+TUQvP09S1PHg/0R7xPWUwOXN+o8h+QnYBxTE6AFG+KgH8+3rGkJfxc+/IuwU2H7CJY9
iZuHe9tISI75H9zj981lgcufotpMtwzoddzW5/ODq6oaDM2SWbq5RENVLHsWhCbjT9bTAT2Yn
PzZerWj1uK6HdKG4BwgV4tI3e8D4Rcsayfse8Rk4Vo0Pv0T6pCyVJezCo4YFIXvac6EaNk48k
SVyjSiq5CsYKErbC6haMRMrcsfBNUsJ+5f4x1gIC39stHVr7eL+i8WNXbDSt4MUmW1TnZvBot
MfoP99dLjOV4DqdKJ6+Ddk08QZNcFDXeNLeViBHJ5IF0EOliCD5E3Qo61/aK72k51fYkKh1FD
7QcCpl2+z9sHBpWiru12gb2oszrEh3C2UHVCTVIOrp0EAfEBzRPC+N1TERUpXPIhe7/15vdeM
4ZEZ9WLMBZrXFFzZEWhz7rUMUIrlZhuzCCNniuIQk1RT6w9btiNCmQnSLKhCulQYVrYhQ9F3H
BzFO0OEWihfQvOOR5GsfGOB5VbByOOC8GYYXm0wPTvKiykoZqVS+O+66yiPI4PC+SpQKe1WtA
zfezaFQKNYVfsthEp4yQfWRuJ75FIrayq3eAPOBGI+bSxGDbnqk/YuR/2u3pVQnvCjmzktYid
KPNNwPaENVOQDnQVMjorFJsBiamLBEqCxGh6UbTebOntef58yBIYSi4OgQpYvgrVWEH5leZTK
rFJfias5QkanYO6zh2tkVWbTyU6lSJ+DN3SCCk5m19LUL7WKzWIylDyBmXLUzb+YHy20Ej3M6
79ZbA9FxWNe9vS48tpex5ljZRIdd8tXqIMidOF4cqyTU4IzXZLHPcQ0+Ar3mSa0IhmyZzkpYe
vfXeaUG4rA5ACygq9hgCrp9J2wNMXjVh4Tcnmz0sN1jp2Fl0fcgUPYqyPQixPnML6BhcQYTOR
cM77ZSBB4q8JW5isiRadhi98zuQIpKpmPq+y6S+GUoFzpwdvCXLz0McXj3XTAAZhC1tj8RFRh
SBZ+YJjH89naFAHETMtBRpSi+l+woDKXWI1H3e+Hv9WGTp/ZdF6djEKiToM4y9saveEl0GPrV
4AE+iviamYC2+7Q4CCQDPWoHccHNwlB1k2B6N/er96bs5B6Bf3qTVTkLFH1No1GmZFolVofl1
/nNdxRcQN2TKSqa4IKx5RFdrEDNY05qtoCfr0CH2SGzux6VLzxCVVOgz27+KhcvBc3sQn0bxh
/cvRZtBCtMFeDC3gIMC9ZcoFhhkRtGwGLrbN3A5CWv5OuwUz9pIk03NKvgvm9qyzA+KolltFs
L7ZH/SyTrTkiM1hRDFphwkk5L6yvAI7y3tKp3uQ5KP8rxNVWAf2oyRbvFG/jHg0OpapYMZS0n
CIwa2Er3PxqaqG1MhotmD6VoY4lDgnxblm8/LXLI4N+I72+OxT8FdhRgmMSGdRUWeYFo3pxaC
xHQN85kYLjnaMWoRldA1Ns/oHvry3esO4g9M9CaGnqZB8sDpZPQNnGC1F6/jz4O6AeW0NnRyk
tskYgQrE+aKMCOog4DUcx3XEMptL9Ef9bkl8FpelpNTh8Q3BbDLYULTafzirJ/tZrTqaAcPtT
Fb0l+/vguC1zXsydcHtBXwWCIPBfGt1lkzIYSMhChTGLvD6DJE7t53CWfxYU/8ynMk8i+yGvr
nJjusETCESlOIH1uTt6b8J1f4frfrJb52sHXIMDKkiHyGBU/ey3miYUQc9kZtVHTCggUj48Ud
L6Bbd++coMtOe0L+wEdTwp70QhA3F2gFDUlUWe75ilQKSp6lx0h+ZsVVWF9MIkdZzvbuhNZgF
58T06qcYbH7uJPsKEyMCS8s5kiEgw2jMoAWKOob9LJVky8UgwM1+XQGMnhe/dYs+4t4oBBb0l
nSC7Z3CTEdAnNpBViiOaxGxTybrhhpZisXeQak6h/GEeOFI4haWy8iLe9DVqUDWrzg6TZpRsC
xMRzeMwC+zAIj+4KJasb6V7+igx1QGjI2BD8ZHITB74gPCie/tdP3yVydXihLImg5HuaD8IQx
v28/5mVgCBA1pNodtBVqsnRtFeFwmf3/KZe2RUetUSYHpOFFoZALryjsApTvdPjHyugNupKdZ
xEwhZOeJR+UQYZu9XUA/HKx3ycJ//WjdHyX+5QT/TlTEp7K3s/Y4t7nIWqzRhCjP34JDw/LgL
REwlntU6ZKSJJVZrmZwsyBgsQcghBAvsU8S4sLuF9U80EXIPcH6lmXvAHJ04uAiVpSiiyCk6j
68rE7VhFnRU3IYmeCsTC5TYj0Q+kqkjjftwXhqGMflee0T3NRjLITycbc4rqZlPYnSLyF1Gcr
D2pq2GGkZLb+rfPN8mlHxfwLSwbwqJ/hCP+9v1PL6guvDDA33HpDQKGf2e8pu082GLyhgU58F
29YbzB4oJtlftOnQ8QAZzHwYnhfY25lIenAtOcui3TuHjyaEXjNqY1q619adjFShifWJ8n31o
chOCjeLY7j1X175RNxZUO5DC0VeEfYArmybgPRrYM7bwvbvRmh8Bi8/TUErbJ9fctngWddcEf
T1CYeJG
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hi Frank,
thanks for this patch.
Am 29.05.25 um 21:17 schrieb Frank Li:
> Convert qca,qca7000.txt yaml format.
>
> Additional changes:
> - add refs: spi-peripheral-props.yaml, serial-peripheral-props.yaml and
> ethernet-controller.yaml.
> - simple spi and uart node name.
> - use low case for mac address in examples.
>
> Signed-off-by: Frank Li <Frank.Li@xxxxxxx>
> ---
> .../devicetree/bindings/net/qca,qca7000.txt | 87 -------------------
> .../devicetree/bindings/net/qca,qca7000.yaml | 86 ++++++++++++++++++
> MAINTAINERS | 2 +-
> 3 files changed, 87 insertions(+), 88 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/net/qca,qca7000.t=
xt
> create mode 100644 Documentation/devicetree/bindings/net/qca,qca7000.y=
aml
>
> diff --git a/Documentation/devicetree/bindings/net/qca,qca7000.txt b/Doc=
umentation/devicetree/bindings/net/qca,qca7000.txt
> deleted file mode 100644
> index 8f5ae0b84eec2..0000000000000
> --- a/Documentation/devicetree/bindings/net/qca,qca7000.txt
> +++ /dev/null
> @@ -1,87 +0,0 @@
> -* Qualcomm QCA7000
> -
> -The QCA7000 is a serial-to-powerline bridge with a host interface which=
could
> -be configured either as SPI or UART slave. This configuration is done b=
y
> -the QCA7000 firmware.
> -
> -(a) Ethernet over SPI
> -
> -In order to use the QCA7000 as SPI device it must be defined as a child=
of a
> -SPI master in the device tree.
> -
> -Required properties:
> -- compatible : Should be "qca,qca7000"
> -- reg : Should specify the SPI chip select
> -- interrupts : The first cell should specify the index of the sourc=
e
> - interrupt and the second cell should specify the trigger
> - type as rising edge
> -- spi-cpha : Must be set
> -- spi-cpol : Must be set
> -
> -Optional properties:
> -- spi-max-frequency : Maximum frequency of the SPI bus the chip can ope=
rate at.
> - Numbers smaller than 1000000 or greater than 16000000
> - are invalid. Missing the property will set the SPI
> - frequency to 8000000 Hertz.
> -- qca,legacy-mode : Set the SPI data transfer of the QCA7000 to legac=
y mode.
> - In this mode the SPI master must toggle the chip select
> - between each data word. In burst mode these gaps aren't
> - necessary, which is faster. This setting depends on how
> - the QCA7000 is setup via GPIO pin strapping. If the
> - property is missing the driver defaults to burst mode.
> -
> -The MAC address will be determined using the optional properties
> -defined in ethernet.txt.
> -
> -SPI Example:
> -
> -/* Freescale i.MX28 SPI master*/
> -ssp2: spi@80014000 {
> - #address-cells =3D <1>;
> - #size-cells =3D <0>;
> - compatible =3D "fsl,imx28-spi";
> - pinctrl-names =3D "default";
> - pinctrl-0 =3D <&spi2_pins_a>;
> -
> - qca7000: ethernet@0 {
> - compatible =3D "qca,qca7000";
> - reg =3D <0x0>;
> - interrupt-parent =3D <&gpio3>; /* GPIO Bank 3 */
> - interrupts =3D <25 0x1>; /* Index: 25, rising edge */
> - spi-cpha; /* SPI mode: CPHA=3D1 */
> - spi-cpol; /* SPI mode: CPOL=3D1 */
> - spi-max-frequency =3D <8000000>; /* freq: 8 MHz */
> - local-mac-address =3D [ A0 B0 C0 D0 E0 F0 ];
> - };
> -};
> -
> -(b) Ethernet over UART
> -
> -In order to use the QCA7000 as UART slave it must be defined as a child=
of a
> -UART master in the device tree. It is possible to preconfigure the UART
> -settings of the QCA7000 firmware, but it's not possible to change them =
during
> -runtime.
> -
> -Required properties:
> -- compatible : Should be "qca,qca7000"
> -
> -Optional properties:
> -- local-mac-address : see ./ethernet.txt
> -- current-speed : current baud rate of QCA7000 which defaults to 11=
5200
> - if absent, see also ../serial/serial.yaml
> -
> -UART Example:
> -
> -/* Freescale i.MX28 UART */
> -auart0: serial@8006a000 {
> - compatible =3D "fsl,imx28-auart", "fsl,imx23-auart";
> - reg =3D <0x8006a000 0x2000>;
> - pinctrl-names =3D "default";
> - pinctrl-0 =3D <&auart0_2pins_a>;
> -
> - qca7000: ethernet {
> - compatible =3D "qca,qca7000";
> - local-mac-address =3D [ A0 B0 C0 D0 E0 F0 ];
> - current-speed =3D <38400>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/net/qca,qca7000.yaml b/Do=
cumentation/devicetree/bindings/net/qca,qca7000.yaml
> new file mode 100644
> index 0000000000000..348b8e9af975b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/qca,qca7000.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/qca,qca7000.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm QCA7000
> +
> +maintainers:
> + - Frank Li <Frank.Li@xxxxxxx>
> +
> +description: |
> + The QCA7000 is a serial-to-powerline bridge with a host interface whi=
ch could
> + be configured either as SPI or UART slave. This configuration is done=
by
> + the QCA7000 firmware.
> +
> + (a) Ethernet over SPI
> +
> + In order to use the QCA7000 as SPI device it must be defined as a chi=
ld of a
> + SPI master in the device tree.
Could you please add the dropped "(b) Ethernet over UART" description here=
?
> +
> +properties:
> + compatible:
> + const: qca,qca7000
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + spi-cpha: true
> +
> + spi-cpol: true
In case of a SPI setup these properties should be required.=20
Unfortunately i'm not sure how to enforce this. Maybe depending on the=20
presence of "reg"?
Regards
> +
> + spi-max-frequency:
> + default: 8000000
> + maximum: 16000000
> + minimum: 1000000
> +
> + qca,legacy-mode:
> + $ref: /schemas/types.yaml#/definitions/flag
> + description:
> + Set the SPI data transfer of the QCA7000 to legacy mode.
> + In this mode the SPI master must toggle the chip select
> + between each data word. In burst mode these gaps aren't
> + necessary, which is faster. This setting depends on how
> + the QCA7000 is setup via GPIO pin strapping. If the
> + property is missing the driver defaults to burst mode.
> +
> + current-speed:
> + default: 115200
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> + - $ref: /schemas/serial/serial-peripheral-props.yaml#
> + - $ref: ethernet-controller.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + spi {
> + #address-cells =3D <1>;
> + #size-cells =3D <0>;
> +
> + ethernet@0 {
> + compatible =3D "qca,qca7000";
> + reg =3D <0x0>;
> + interrupt-parent =3D <&gpio3>; /* GPIO Bank 3 */
> + interrupts =3D <25 0x1>; /* Index: 25, rising ed=
ge */
> + spi-cpha; /* SPI mode: CPHA=3D1 */
> + spi-cpol; /* SPI mode: CPOL=3D1 */
> + spi-max-frequency =3D <8000000>; /* freq: 8 MHz */
> + local-mac-address =3D [ a0 b0 c0 d0 e0 f0 ];
> + };
> + };
> +
> + - |
> + serial {
> + ethernet {
> + compatible =3D "qca,qca7000";
> + local-mac-address =3D [ a0 b0 c0 d0 e0 f0 ];
> + current-speed =3D <38400>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7761b5ef87674..c163c80688c23 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -20295,7 +20295,7 @@ QUALCOMM ATHEROS QCA7K ETHERNET DRIVER
> M: Stefan Wahren <wahrenst@xxxxxxx>
> L: netdev@xxxxxxxxxxxxxxx
> S: Maintained
> -F: Documentation/devicetree/bindings/net/qca,qca7000.txt
> +F: Documentation/devicetree/bindings/net/qca,qca7000.yaml
> F: drivers/net/ethernet/qualcomm/qca*
> =20
> QUALCOMM BAM-DMUX WWAN NETWORK DRIVER
Return-Path: <linux-kernel+bounces-667793-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 8E2F041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:35:09 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 715D29E6706
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:34:48 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8715821884A;
Fri, 30 May 2025 08:35:03 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="lclV61rN"
Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131])
(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 82B621FF603;
Fri, 30 May 2025 08:35:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594102; cv=none; b=AbgguDoY/euv/SK5LejxVRBiVdTHP4NdhPzN3/dY1YSoGMtENndPZ0iCO8dCP91RBh0kVR/0YLA8D1Xtnf+2nt72dJ06YdOdUazFPTMR4Azw3A5/Z7wVEpMdE8TwrTgS4pGe11jHDkuOcB4Dt3/G+Rx9J8TbqPLYtrc1Pfm30FM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594102; c=relaxed/simple;
bh=AaGwn0lqTXVzgZuVYGhlOtM5wFa9rQwalRqSWVUegjU=;
h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:
In-Reply-To:Content-Type; b=pI73b8QlxX3nQ+lykdvQXv/vqc06Y+AN/V2V2mFkbrB41j+xUi9w06GCiQDEm/XQV/IbK3SzderQyfL6npKS7HzStDKY8/x5pX5dEnjIzfX4P95SauM6Cr5hRItb8VM3AoMFTw3e3sMfnwWmLy62Euh1Mq9aW0exbkTysFY6cvI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=quicinc.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=lclV61rN; arc=none smtp.client-ip=205.220.180.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=quicinc.com
Received: from pps.filterd (m0279868.ppops.net [127.0.0.1])
by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U0MkDv004882;
Fri, 30 May 2025 08:34:56 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
cc:content-transfer-encoding:content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to; s=qcppdkim1; bh=
JBePT4VRk3EWdmQVSBKgWOtJvtAe3EhswTDKYw+kqxE=; b=lclV61rNIwmA5C8C
O5y/PpBzPQDHFWipMOdv6pV58DEcAEz7iB+RsZn1AxLX6dbg8h3u934DB+x37C0P
DYYykUv12bfLm5iDSHE+9gGRYo26kwSfQOSwCTYWOnj6p1cTmwy/LpcsDtw88gNy
O6UMddlkZFccscvAA7J7trqnbKroySoIVdbytkyHjGkWtcl5i/Lyi2fz6Ra35nkJ
GwNhyoh4m8MOoaW+6nQ6JKuuzrVpexaGbcqgwwzgp0yovaw63FuIqF7sUhqh2VSr
o61CAYXwjIZ0s+n22MWbhLJh/sATYU60niMRoyWSBcyqmnTiY9JDSMZj+ds3KGpb
hyEKmg==
Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20])
by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 46u5ek869h-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 08:34:55 +0000 (GMT)
Received: from nalasex01b.na.qualcomm.com (nalasex01b.na.qualcomm.com [10.47.209.197])
by NALASPPMTA01.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTPS id 54U8Ys2A001683
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 08:34:54 GMT
Received: from [10.253.39.138] (10.80.80.8) by nalasex01b.na.qualcomm.com
(10.47.209.197) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.9; Fri, 30 May
2025 01:34:51 -0700
Message-ID: <25361fe1-988d-41cc-a5f0-76773e41531a@xxxxxxxxxxx>
Date: Fri, 30 May 2025 16:34:49 +0800
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v1] tty: serdev: serdev-ttyport: Fix use-after-free in
ttyport_close() due to uninitialized serport->tty
To: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
CC: Rob Herring <robh@xxxxxxxxxx>, Jiri Slaby <jirislaby@xxxxxxxxxx>,
<linux-serial@xxxxxxxxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>,
<liulzhao@xxxxxxxxxxxxxxxx>, <quic_chejiang@xxxxxxxxxxx>,
<zaiyongc@xxxxxxxxxxxxxxxx>, <quic_zijuhu@xxxxxxxxxxx>,
<quic_mohamull@xxxxxxxxxxx>,
Panicker Harish <quic_pharish@xxxxxxxxxxx>
References: <20250430111617.1151390-1-quic_cxin@xxxxxxxxxxx>
<2025043022-rumbling-guy-26fb@gregkh>
<d388b471-482b-48ba-a504-694529535362@xxxxxxxxxxx>
<2025050851-splatter-thesaurus-f54e@gregkh>
<38bf94e1-ebed-4d03-8ea0-4040009e8d31@xxxxxxxxxxx>
<8e171057-b3c3-4808-b49e-f04ffd310b31@xxxxxxxxxxx>
<2025052926-net-economist-a016@gregkh>
<2025052957-jawless-superhero-09be@gregkh>
Content-Language: en-US
From: Xin Chen <quic_cxin@xxxxxxxxxxx>
In-Reply-To: <2025052957-jawless-superhero-09be@gregkh>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To
nalasex01b.na.qualcomm.com (10.47.209.197)
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Authority-Analysis: v=2.4 cv=GIgIEvNK c=1 sm=1 tr=0 ts=68396daf cx=c_pps
a=ouPCqIW2jiPt+lZRy3xVPw==:117 a=ouPCqIW2jiPt+lZRy3xVPw==:17
a=GEpy-HfZoHoA:10 a=IkcTkHD0fZMA:10 a=dt9VzEwgFbYA:10
a=G5QaITAZWq_18pxbImEA:9 a=QEXdDO2ut3YA:10
X-Proofpoint-ORIG-GUID: fLQyRINiNWSmn0E8-3kLiQ4WKZnQtxcj
X-Proofpoint-GUID: fLQyRINiNWSmn0E8-3kLiQ4WKZnQtxcj
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA3MSBTYWx0ZWRfX5FPdIg3r9eT4
I8e51Ei/Q2U+ihmE3s9jTMjZDVl7zo0XbvrVA8kDhSgrTvmDbXXA8uTZEpeQq83rrTEIU4wvLMz
sRBmVLw2G1BO1nQH01OqLC61+JYuuT7RJU8Cx02LrlARGU4k//0J0GZd3J5PhR95xk4YkBUHTGk
cR8QX3/RzmlK+mD2ktnVXEwBX3v+iQrKOdEsP6C558nYhbLERIgiJqAdxqD7SD3T7X6Nqdz9Q7z
L5DHjTuoOIDrsRXxvO6aTYFvpgubqK+OFOe99pPA9/VK3W+Al5Pu45FO93HszOuxEzt017hCktJ
jzHNtome3BKnOug6Mbkmn9Wv8Kh8N1CoHq2WuEjLHG4XdF41PdeOW0TSdJUpAUN+Y4B21aS46N0
h3NeFE08ybMd6+dEWDiiAKYQt8VV7V/3GIN2OKjbJH0V0c0kc8fbr0dXnx+JPEihnZ5ym1bS
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_03,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
impostorscore=0 malwarescore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0
adultscore=0 priorityscore=1501 mlxscore=0 phishscore=0 spamscore=0
suspectscore=0 mlxlogscore=999 classifier=spam authscore=0 authtc=n/a authcc=
route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505160000
definitions=main-2505300071
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 5/29/2025 5:41 PM, Greg Kroah-Hartman wrote:
> On Thu, May 29, 2025 at 11:07:25AM +0200, Greg Kroah-Hartman wrote:
>> On Fri, May 23, 2025 at 10:52:27AM +0800, Xin Chen wrote:
>>>
>>>
>>> On 5/14/2025 5:14 PM, Xin Chen wrote:
>>>>
>>>>
>>>> On 5/8/2025 5:41 PM, Greg Kroah-Hartman wrote:
>>>>> On Thu, May 08, 2025 at 05:29:18PM +0800, Xin Chen wrote:
>>>>>>
>>>>>> On 4/30/2025 7:40 PM, Greg Kroah-Hartman wrote:
>>>>>>> On Wed, Apr 30, 2025 at 07:16:17PM +0800, Xin Chen wrote:
>>>>>>>> When ttyport_open() fails to initialize a tty device, serport->tty is not
>>>>>>>> --- a/drivers/tty/serdev/serdev-ttyport.c
>>>>>>>> +++ b/drivers/tty/serdev/serdev-ttyport.c
>>>>>>>> @@ -88,6 +88,10 @@ static void ttyport_write_flush(struct serdev_controller *ctrl)
>>>>>>>> {
>>>>>>>> struct serport *serport = serdev_controller_get_drvdata(ctrl);
>>>>>>>> struct tty_struct *tty = serport->tty;
>>>>>>>> + if (!tty) {
>>>>>>>> + dev_err(&ctrl->dev, "tty is null\n");
>>>>>>>> + return;
>>>>>>>> + }
>>>>>>>
>>>>>>> What prevents tty from going NULL right after you just checked this?
>>>>>>
>>>>>> First sorry for reply so late for I have a long statutory holidays.
>>>>>> Maybe I don't get your point. From my side, there is nothing to prevent it.
>>>>>> Check here is to avoid code go on if tty is NULL.
>>>>>
>>>>> Yes, but the problem is, serport->tty could change to be NULL right
>>>>> after you check it, so you have not removed the real race that can
>>>>> happen here. There is no lock, so by adding this check you are only
>>>>> reducing the risk of the problem happening, not actually fixing the
>>>>> issue so that it will never happen.
>>>>>
>>>>> Please fix it so that this can never happen.
>>>>>
>>>>
>>>> Actually I have never thought the race condition issue since the crash I met is
>>>> not caused by race condition. It's caused due to Bluetooth driver call
>>>> ttyport_close() after ttyport_open() failed. This two action happen one after
>>>> another in one thread and it seems impossible to have race condition. And with
>>>> my fix the crash doesn't happen again in several test of same case.
>>>>
>>>> Let me introduce the complete process for you:
>>>> 1) hci_dev_open_sync()->
>>>> hci_dev_init_sync()->hci_dev_setup_sync()->hdev->setup()(hci_uart_setup)->qca_setup(),
>>>> here in qca_setup(), qca_read_soc_version() fails and goto out, then calls
>>>> serdev_device_close() to close tty normally. And then call serdev_device_open()
>>>> to retry.
>
> Wait, what? Why is qca_read_soc_version() failing?
Actually I have not root cause why qca_read_soc_version() fails of
__hci_cmd_sync_ev(). It may be relative to FW issue.
> Why are you retrying multiple times until either you run out of attempts?
This is a retry mechanism. I find the reason in the change commit message
"Currently driver only retries to download FW if FW downloading
is failed. Sometimes observed command timeout for version request
command, if this happen on some platforms during boot time, then
a reboot is needed to turn ON BT. Instead to avoid a reboot, now
extended retry logic for version request command too."
> Why are you closing the port and then opening it again right away?
This is a retry mechanism as above said. Do you mean there should be a gap
between close and open? The change owner maybe don't think about this issue.
> What close/open pair seems totally unnecessary, why do that at all?
>
> If I read that function qca_setup(), it can NEVER detect if a failure
> really happened (i.e. if it does run out of retries, you just plow on
> and keep going and keep on registering things and THEN return an error
> for some reason.
>
> In other words, the error handling in qca_setup() is very suspect, why
> not fix all of that up first?
>
qca_read_soc_version() in qca_setup() can detect whether the hci_dev is set up
successfully. If if fails then a failure happens.
You mean I should fix why qca_read_soc_version() fails?
Thanks,
Xin
Return-Path: <linux-kernel+bounces-667794-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id B4EE841E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:35:38 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 82D8C7A72FB
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:34:20 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8B03B21884A;
Fri, 30 May 2025 08:35:31 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=fail reason="signature verification failed" (2048-bit key) header.d=hmeau.com header.i=@hmeau.com header.b="lpyPeTnx"
Received: from abb.hmeau.com (abb.hmeau.com [144.6.53.87])
(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 B463D125D6
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:35:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=144.6.53.87
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594130; cv=none; b=IjsjWcK3QyEO1bt1EjI1xubdxojDScXwGlJfh/CzfHDtqmCMiyYxhliUgtM5pQU5Qzg+jEpqQqPHx5knCNTsNO9DGyBwVo/OY2H/iesSUyR9fxpFXpwtInFOVVT0Fs41bDBL8hMDS09IbG7SrT6scWAUNf3LPGVJXhwuRfGLZuo=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594130; c=relaxed/simple;
bh=4KdAo0bEfcZ8DM0J1XVHpDDzo2h/HuuqXmEyM1HpkP8=;
h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:
Content-Disposition; b=jbHafGexP2yL9FD9yobvUij/uDGHDdRoC0HA7Vy0hm2GBBA0f8/lx2wb9qdeRrmi+oYJ8Mi6lkjjSkhAINsl0YQLIeRI5ygu/R3onl7QQ3nOytsC68rqT+a28r2FftQN8pzt8FtatwSOAeZMu3L+dJofiBC/hWPx9Gx0WZOGl3I=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au; spf=pass smtp.mailfrom=gondor.apana.org.au; dkim=pass (2048-bit key) header.d=hmeau.com header.i=@hmeau.com header.b=lpyPeTnx; arc=none smtp.client-ip=144.6.53.87
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gondor.apana.org.au
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hmeau.com;
s=formenos; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date:
Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description:
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=a0g8maZiyFV8M5hvMuQoZRHFaiaoS/f9wuQgazFPmrE=; b=lpyPeTnxxA6ahbesj/p8kraTmA
PEel3rqWgpQmZSh3WGvw/xjGYrkOZpiKAKTQHpYQN1E4QTbxv0Q9/vPJ7561r6yKVsaH8amCLJvmn
KM2+KnMuYIMrsgVOQwa3PbCtPlWNGfFEEK7p3ByD0JaPz4fOa5vrLRDGizRe1JZnoOwk7wecYtbNu
3mP2Adh2iZ8/q/yvfFBSeIWNOqiJcha92YlK7lfmkPSCsNlEsB3YzNygRAN7Z/h9cUB/7UCJwVoNc
iFohjJ/sbbT52OecxenCcHjVj1Xnq/AXzOGenZP+ZLBPFPytYIHFYbGZrA6lwQefoeT1wCqo7RcfE
G1KOjHng==;
Received: from loth.rohan.me.apana.org.au ([192.168.167.2])
by formenos.hmeau.com with smtp (Exim 4.96 #2 (Debian))
id 1uKvD1-009jum-0G;
Fri, 30 May 2025 16:35:24 +0800
Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Fri, 30 May 2025 16:35:23 +0800
Date: Fri, 30 May 2025 16:35:23 +0800
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
To: Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>,
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>,
"Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Subject: [PATCH] userns: Add forward declaration of struct seq_file in
user_namespace.h
Message-ID: <aDlty06JvlGwTfKk@xxxxxxxxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Add forward declaration of struct seq_file before using it in
function prototype.
Fixes: 9cc46516ddf4 ("userns: Add a knob to disable setgroups on a per user namespace basis")
Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index a0bb6d012137..5c7aa940b1aa 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -16,6 +16,8 @@
#define UID_GID_MAP_MAX_BASE_EXTENTS 5
#define UID_GID_MAP_MAX_EXTENTS 340
+struct seq_file;
+
struct uid_gid_extent {
u32 first;
u32 lower_first;
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Return-Path: <linux-kernel+bounces-667795-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 1E0A041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:35:53 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id B0DD01BA5F22
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:36:03 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id EE59C21931C;
Fri, 30 May 2025 08:35:34 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="aYM3JQng"
Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54])
(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 6DC7D2192EF
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:35:32 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594134; cv=none; b=knv4sXELcWDQD5nKQsUVmsLQTXUFvVytCBWa0tDgzOBUbBBGnXQxH6h0HQFm3+b3Ke4lZEItvgrWTECrhAudhV0/g15mGT7ZQ9NfAWQs6pQ91iurJmIn3xf6N4yjTUkJo0AEv8E8VLSQ2x18AhRtfEQwR6kJqXgwfkg4UH+jj/A=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594134; c=relaxed/simple;
bh=h33LQrSnZ+i8qVEFwmpF+DBn7mv4bG9TT0CnxcqbDcg=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=QbUrAuDRpEBoTrgVJu+gQKAi43YrrUDL90zIUv97tIXsBWfPD04VU3f3kaH3fM0wNfk+Jrh7CDUcVzXvd6B1qJCHA/eF7l32zp1wkcFiass8pAweerkgRgjGoGSvJdCrQVW6cp+0uQbUQsTKpipDTuiNAjJQhOJsEPoMNN6M2mk=
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=aYM3JQng; arc=none smtp.client-ip=209.85.128.54
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-f54.google.com with SMTP id 5b1f17b1804b1-43cf257158fso13176645e9.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:35:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1748594131; x=1749198931; darn=vger.kernel.org;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:from:to:cc:subject:date:message-id:reply-to;
bh=YLQbWS2tM1c5F0xZTSwzJwZIihpwvcGvimBEFrvn6y4=;
b=aYM3JQng0blGw3SmaQI5JmljMBday+4uJAlvvlTqIlSYT851VrQDqpofaGRYsEmrTk
92HsXvbpqk5Q/t+TvX1rT5lNNxLwnPPmFIp/BHhDqf1Oi44ZGVaJUXTrTpI/FitO+Qmy
K1PYALKE1wwn6Gk8bxvCOPxDUEp/fsM2AIOd0rPzbpvvGIetIHA0WMIK/DmLkNTZQCkg
YyPg30fFCD4ZPA+eSDK2BV0ZopWlDhwohe4FhV7av+AZMq391q2U5+y6b/oqoYqA9Et3
H/42pOp05GjQ4e9CUixM4tIGuRObzCAuXxnPj7qAQHrLnUTzdnEEUoy2j3qSnXsYMDmG
7YDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748594131; x=1749198931;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=YLQbWS2tM1c5F0xZTSwzJwZIihpwvcGvimBEFrvn6y4=;
b=DzZtDXsnFVBcL+ymTq3tIILLqYI2uUjNACeyKwjvtRtCbpIrI+sAfKgAjN2fN+Y/5l
y1rbg4BawI15Pgv0sehRZC1VVv/38O9gzxCCjN11HBllXROaRGiql8qy8W2iFFOEL/52
HkMB0WIr6MyPmVhFYF1xP/La60EWgJOytKxJ+CYKrTYJrtJwyjZrDfmf8aQHJNJqZmsx
x34Dj044Yt8AbYyxtVzVGodJQyHGEsHpmi4v700W6ql5KbJhNV8hev7nQkZIb6pEyBcY
X/STpmhEq+TkMvg02fgNK0wbYsTkJqJJQSbauPicRhSlnoq7tN3QuEd+c9WqbJ9vxTFh
BvPQ==
X-Forwarded-Encrypted: i=1; AJvYcCXb+KQUZ/dUW+lo52me/VDier0K4Dv/hw2Ti5vBoXFcnxalU1lskZdbbvXnN0Gl7iWGPUV+Cn3RO+gmnoE=@vger.kernel.org
X-Gm-Message-State: AOJu0YzkXQ3qPB91A099e5JV9hXNFj7CWMzsgpG7rZ3W0YkTEdldYkLy
8tmWSk0mFV9P0Q1fxpkuYhCbzEl0zPodoD9PlLx402Pkby8z20U4nIM6gRfAOD9rGmw=
X-Gm-Gg: ASbGncsrmokpBQ32tP9+pXB1UrmkVVUJPWcr85P2UMkmVUG7G5ZzwKvXN8RSN5len52
aGrLF6Ivj/mMhykfRQqAwaSoeTLvsscW7AYc5kmxg2WhGhirl3hMMGiY9VoNB+6wjFRJ1SDHKQS
Riuzg/UZwNiq1Lv7c/Yuq0x6sy5iZu9YmAMNaSw5CExTxVcN25WsAOnXOqb2dDrtavP9I4iWuCy
iSM1b7DD7V9ZBaiSgkxplOxA0IWu59Hrd28Eaw31Gu2PA9V665PN6navVFKk6a8CA3+rejkUQG1
Db2+UsKolz4M6nBKPbR7oq8/epD0sUkenRZJlOOfkoJWs8+rjDQ3DVLqXYL8Q05/fXQ1NbiVq8y
6vN7RZF8lLpnsjVoZ
X-Google-Smtp-Source: AGHT+IHehfnKYCHEwgQg2UA1/7tKSJAulXBmZ2VniP+tL7uxdRKGux7eY9b2KcvJXyj56PkW8C6bfA==
X-Received: by 2002:a05:600c:45d0:b0:43d:26e3:f2f6 with SMTP id 5b1f17b1804b1-450d882b456mr9757105e9.5.1748594130712;
Fri, 30 May 2025 01:35:30 -0700 (PDT)
Received: from [192.168.0.35] (188-141-3-146.dynamic.upc.ie. [188.141.3.146])
by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fb80e9sm11450035e9.27.2025.05.30.01.35.29
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:35:30 -0700 (PDT)
Message-ID: <e8f3386b-de5b-447f-af7d-5f521662ba31@xxxxxxxxxx>
Date: Fri, 30 May 2025 09:35:28 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 7/8] usb: typec: ucsi_glink: Add UCSI quirk for
X1E80100 platform
To: fenglin.wu@xxxxxxxxxxxxxxxx, Sebastian Reichel <sre@xxxxxxxxxx>,
Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>, Conor Dooley
<conor+dt@xxxxxxxxxx>, Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>,
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: Subbaraman Narayanamurthy <subbaraman.narayanamurthy@xxxxxxxxxxxxxxxx>,
David Collins <david.collins@xxxxxxxxxxxxxxxx>, linux-pm@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, linux-arm-msm@xxxxxxxxxxxxxxx,
kernel@xxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
linux-usb@xxxxxxxxxxxxxxx
References: <20250530-qcom_battmgr_update-v2-0-9e377193a656@xxxxxxxxxxxxxxxx>
<grJaz_699sNeLfZ0Kp0u8e13em1Y1VWTlH3dSqSpQE_mHdD7iVKUwHkrvjZ74i3nDzn9c5_Hwg-8IAW40N1iPA==@protonmail.internalid>
<20250530-qcom_battmgr_update-v2-7-9e377193a656@xxxxxxxxxxxxxxxx>
Content-Language: en-US
From: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
In-Reply-To: <20250530-qcom_battmgr_update-v2-7-9e377193a656@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30/05/2025 08:35, Fenglin Wu via B4 Relay wrote:
> From: Fenglin Wu <fenglin.wu@xxxxxxxxxxxxxxxx>
>
> Currently, the Qualcomm X1E80100 is treated as a fallback of SM8550
> in pmic-glink support. However, the battmgr driver, which uses the
> same pmic-glink compatible strings, has implemented charge control
> functionality differently between SM8550 and X1E80100. As a result,
> X1E80100 is no longer a fallback of SM8550 in pmic-glink support.
>
> Therefore, add match data for X1E80100 separately in ucsi_glink driver
> but keep the UCSI quirk the same as SM8550.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@xxxxxxxxxxxxxxxx>
Small suggestion for your commit log.
Call out _which_ commit makes that change.
---
bod
Return-Path: <linux-kernel+bounces-667796-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 3E30241E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:39:54 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id D688017D5AA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:39:54 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id C52232185BC;
Fri, 30 May 2025 08:39:48 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="fEmDc43C"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
(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 A922638B
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:39:45 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594387; cv=none; b=eUnJWRI+GNgvxZ6If5gDagurUeggpKWewYRMGu/ZRbaC7MuuyaK5v7gsK8Bk5uBjJa0EtWhVmQRpuT8Tc+2+LDhYzjOassnKaHTvCfY5RAcuH9I6EF7tstGVau5GSn/9/SG8p2+SIqn/5LexzjFsJ2SPPvOoQshOQqvJicUMkSs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594387; c=relaxed/simple;
bh=kOYiuJU7KnqqvHk9yJXocj5CuJTq0t89rYQYbk4he44=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=slmMjBbY29EcOfXkeNmxXldIIKDCGxvz+yDaVpJENGWCBFBrZRJGdQYLa/FLsQQRgFI0T5YoaMDd9QnP0tbXD2TF4XQlJMzD2HEK8gNvmq3qLJgoVY3BrQAcnuKwbhtWM31yCazuV3Sez39N+e0PE5Ogx9aawe8y2iYlfpUZq7Y=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=fEmDc43C; arc=none smtp.client-ip=170.10.133.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748594384;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=LYjEslniOeni4abE+UsHa0UZTcNVVAzwzXeh5mikH2Y=;
b=fEmDc43CWJeyJgwux7rQuZTTZ0s9Aap7M9hf1hK2fOiYHtfhvAFNbSvzTn7Od2/ahFc90m
REy8CI49pFFrPRcpxHuMepICki4VZGFTorjaDUAc8eWdADhc9mh+Bf2HNmDeXmRMrN63Qz
VXlhk0n7kzIdckJx5f2a/6Yyvb8P/y4=
Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com
[209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-50-io0KTozpM3Cc9BXJdZ6eSg-1; Fri, 30 May 2025 04:39:42 -0400
X-MC-Unique: io0KTozpM3Cc9BXJdZ6eSg-1
X-Mimecast-MFC-AGG-ID: io0KTozpM3Cc9BXJdZ6eSg_1748594381
Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-441c122fa56so9459595e9.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:39:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748594381; x=1749199181;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=LYjEslniOeni4abE+UsHa0UZTcNVVAzwzXeh5mikH2Y=;
b=CZWUHBtvShaRF2XrhD8jyED3RV9IBK7JiSQY4INMiVG71X/kIW13AmGxUJHXB6nDnu
4fW+uxtW/LkiY2DKw3C3+Poa6FKcNPDaMXcmSUG6+0JynUwugKeGADbCC98sOdkjXXS8
pwku4fakITZTcelvn1CWdGlUoTNn3SOTGfKUwtPzNNZNur2v+imqq3KyfwHHX6j9jvMc
2ZrPFT7YIBOBXiHdxAq+wkvyi94vLd3JcqpumkbrQh+/xjbjj2S4aXVcb5Ivwwv7SRv5
kb7+voSuC0zaYYOaILmdU2SSjY6GoUanAxbx7JBixTrtP4jeTIi8i0KzoP3OCdIYKpZM
Lphw==
X-Forwarded-Encrypted: i=1; AJvYcCWg86XHPD1sUa7bQM13kYc7IUICEyLswHcak3SEIxC1AQp7g0ZYc0DgXxX+5qYaSvjbdk/fUdD4gj/lfBU=@vger.kernel.org
X-Gm-Message-State: AOJu0YyHaSc8qxbeUr5aiRBZw1HvpH6J+FeCNC+NwNwLvhZTyu/gPlmM
YRoQ7qdt//YdFNweAK1tqI8zeYiXif5dIvGXbItu5HKYTqAqJXx+r4upKmpj4VCSmhH90A+5Prn
ZhJDceuSr8ryu155J+jbF3TyURfDS0ol31INRJfjAzcYkqVcWlbUhUOcS0XtRCpud6A==
X-Gm-Gg: ASbGncu0w6tERuYRqNBaWd7i63IYZVP+vAVi3MJ+iVBvNYxZ4xCtEO3PA7xUbJuPOgu
QEKTA5TrP8jPforXYwDYNwCfX8D0DSEbg9SC7qbursF1aFs9a3CR3R10mF4fg1QJB3Biv5gqfSm
pV3tjw/fI12lBRGjDU1HCuxXy/dpht/zP6C8lEd0FCJdkrnlRKDlYsQWHx8TLTXbIaisO403qSI
wvdke25/9Siv6fvtHnX6gVoD3CE4glNDLPtS0emZFhvCtQemPaMtMSpeMXk5Sjin9e35thneKSl
MSHwnW22bcGoaQn9EGy/tN61yabCgXb6Mirzk4kAeTGOlAUqZvYSG1WBs4ohqj+k3HVC7wK1Fvt
GigPDB32ozwU8EpHcnaMkr0pI4u8+m0UaZvoP+zTr0G4I/IBETQ==
X-Received: by 2002:a05:600c:5248:b0:43d:ac5:11ed with SMTP id 5b1f17b1804b1-450d654fd80mr23207635e9.24.1748594381473;
Fri, 30 May 2025 01:39:41 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFLznW91MGwFXiEUDCSFpEg0/1xmiD0avrK6gzN2jVg47uZp4IbwOpwG2qxrhw1ng6HInkPNw==
X-Received: by 2002:a05:600c:5248:b0:43d:ac5:11ed with SMTP id 5b1f17b1804b1-450d654fd80mr23207475e9.24.1748594381061;
Fri, 30 May 2025 01:39:41 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe73f22sm4155072f8f.43.2025.05.30.01.39.40
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:39:40 -0700 (PDT)
Message-ID: <e0f7fc1e-2227-4c6b-985a-34a697a52679@xxxxxxxxxx>
Date: Fri, 30 May 2025 10:39:39 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/5] kdump: crashkernel reservation from CMA
To: Michal Hocko <mhocko@xxxxxxxx>
Cc: Baoquan He <bhe@xxxxxxxxxx>, Donald Dutile <ddutile@xxxxxxxxxx>,
Jiri Bohac <jbohac@xxxxxxx>, Vivek Goyal <vgoyal@xxxxxxxxxx>,
Dave Young <dyoung@xxxxxxxxxx>, kexec@xxxxxxxxxxxxxxxxxxx,
Philipp Rudo <prudo@xxxxxxxxxx>, Pingfan Liu <piliu@xxxxxxxxxx>,
Tao Liu <ltao@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
David Hildenbrand <dhildenb@xxxxxxxxxx>
References: <Z7dc9Cd8KX3b_brB@xxxxxxxxxxxxx>
<04904e86-5b5f-4aa1-a120-428dac119189@xxxxxxxxxx>
<427fec88-2a74-471e-aeb6-a108ca8c4336@xxxxxxxxxx>
<Z8Z/gnbtiXT9QAZr@MiWiFi-R3L-srv>
<e9c5c247-85fb-43f1-9aa8-47d62321f37b@xxxxxxxxxx>
<aDgQ0lbt1h5v0lgE@tiehlicka>
<a1a5af90-bc8a-448a-81fa-485624d592f3@xxxxxxxxxx>
<aDlsF5tAcUxo4VgT@tiehlicka>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <aDlsF5tAcUxo4VgT@tiehlicka>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 10:28, Michal Hocko wrote:
> On Fri 30-05-25 10:06:52, David Hildenbrand wrote:
>> On 29.05.25 09:46, Michal Hocko wrote:
>>> On Wed 28-05-25 23:01:04, David Hildenbrand wrote:
>>> [...]
>>>> I think we just have to be careful to document it properly -- especially the
>>>> shortcomings and that this feature might become a problem in the future.
>>>> Movable user-space page tables getting placed on CMA memory would probably
>>>> not be a problem if we don't care about ... user-space data either way.
>>>
>>> I think makedumpfile could refuse to capture a dump if userspace memory
>>> is requested to enforce this.
>>
>> Yeah, it will be tricky once we support placing other memory on CMA regions.
>> E.g., there was the discussion of making some slab allocations movable.
>>
>> But probably, in such a configuration, we would later simply refuse to
>> active CMA kdump.
>
> Or we can make the kdump CMA region more special and only allow
> GFP_HIGHUSER_MOVABLE allocations from that. Anyaway I think we should
> deal with this once we get there.
Might be doable. When migrating (e.g., compacting) pages we'd have to
make sure to also not migrate these pages into the CMA regions. Might be
a bit more tricky, but likely solvable.
>
>>>> The whole "Direct I/O takes max 1s" part is a bit shaky. Maybe it could be
>>>> configurable how long to wait? 10s is certainly "safer".
>>>
>>> Quite honestly we will never know and rather than making this
>>> configurable I would go with reasonably large. Couple of seconds
>>> certainly do not matter for the kdump situations but I would go as far
>>> as minutes.
>>
>> I recall that somebody raised that kdump downtime might be problematic
>> (might affect service downtime?).
>>
>> So I would just add a kconfig option with a default of 10s.
>
> kconfig option usually doesn't really work for distro kernels. I am
> personally not really keen on having a tuning knob because there is a
> risk of cargo cult based tuning we have seen in other areas. That might
> make it hard to remove the knob later on. Fundamentally we should have 2
> situations though. Either we know that the HW is sane and then we
> shouldn't really need any sleep or the HW might misbehave and then we
> need to wait _some_ time. If our initial guess is incorrect then we can
> always increase it and we would learn about that through bug reports.
kconfigs are usually much easier to alter/remove than other tunables in
my experience.
But yeah, it would have to go for the setting that works for all
supported hw (iow, conservative timeout).
>
> All that being said I would go with an additional parameter to the
> kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
> otherwise. That would make the optimized behavior opt in, we do not need
> to support all sorts of timeouts and also learn if this is not
> sufficient.
>
> Makes sense?
Just so I understand correctly, you mean extending the "crashkernel="
option with a boolean parameter? If set, e.g., wait 1s, otherwise magic
number 10?
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667797-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 5E57F41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:40:21 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id A9CDD17E481
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:40:22 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id AC7FC2192F8;
Fri, 30 May 2025 08:40:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=fail reason="signature verification failed" (2048-bit key) header.d=hmeau.com header.i=@hmeau.com header.b="kqBQFSvG"
Received: from abb.hmeau.com (abb.hmeau.com [144.6.53.87])
(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 503D921882B;
Fri, 30 May 2025 08:40:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=144.6.53.87
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594414; cv=none; b=kRMKyPU3rQ/sBPLaUG7NmF/uv2MGH0IP0ok8Y+gMgCneEi2qlE0MGzZE2XIZVx6UQDYnnBflA337BzqcJAcYf6zQozKIs9W8MexbPP4yLDcxGNQ4hmIRMD1NG1KDvMK+vi4w15phAyuw1uLHwETJtgrsc+5Y33Xn51IrOs7rBm0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594414; c=relaxed/simple;
bh=pyziCTH2diLk7jYaNaKaBd5SlO0DPjcx6Z2KW/GpnDk=;
h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:
Content-Disposition; b=lGEQJC9mMWeEq2u8qwwHNKzuhE57cW4koftrSr3rEMWaSMpD+haNYUwLHlYUes2j0Xb3m3muzK53+FIk6KxR2NAn4P0an9KFJCXLw3l74jTgdALHnSb0jxxEqT/WLK6J6EeqMyZf2lXmjvjNvkEGovjZsebTCQU09ESiU/dlqsA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au; spf=pass smtp.mailfrom=gondor.apana.org.au; dkim=pass (2048-bit key) header.d=hmeau.com header.i=@hmeau.com header.b=kqBQFSvG; arc=none smtp.client-ip=144.6.53.87
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=gondor.apana.org.au
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gondor.apana.org.au
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hmeau.com;
s=formenos; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date:
Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description:
Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:
In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=49GMHY4OeLfk5bMG6QeyscjCUBw8doMpODBe1qStcRk=; b=kqBQFSvGPsJn8LEtC9minAmpVA
azao16RPeaJBiJCrLQFIl0edFlDbhpKN6Dng0rjoWPcYHR6fLLDcLZDQ8SlMVWTXJLVP2poXz884B
+MixYgn5YQO0l3+HfxWk2FpSqM8EMrhGTWJ8BX9hZVmSnI5PlxXf8hPEP+wQKCP/7/YElGSDNyt21
AjZGfQaqeIJd9e/ytqRaN4G568hb3H2bBod9eKKZjO7yq0hBHWQW7wmjdngwP8oGvoA2mXgORSgZA
BCFl3UvnpMZdYfIKOlWycav1vmF8EEtcKKSMg1YCYCR00rPHaP6fxkXO9OBaqiIoQ/53dwQb3QBVp
B2V7deSA==;
Received: from loth.rohan.me.apana.org.au ([192.168.167.2])
by formenos.hmeau.com with smtp (Exim 4.96 #2 (Debian))
id 1uKvHZ-009jxI-0c;
Fri, 30 May 2025 16:40:06 +0800
Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Fri, 30 May 2025 16:40:05 +0800
Date: Fri, 30 May 2025 16:40:05 +0800
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
To: Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>,
Sumit Semwal <sumit.semwal@xxxxxxxxxx>,
Christian =?iso-8859-1?Q?K=F6nig?= <christian.koenig@xxxxxxx>,
linux-media@xxxxxxxxxxxxxxx, dri-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [PATCH] dma-buf: Add forward declaration of struct seq_file in
dma-fence.h
Message-ID: <aDlu5TGyA1WuMsvw@xxxxxxxxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Add forward declaration of struct seq_file before using it in
function prototype.
Fixes: a25efb3863d0 ("dma-buf: add dma_fence_describe and dma_resv_describe v2")
Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index e7ad819962e3..b751ae49d007 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -26,6 +26,7 @@
struct dma_fence;
struct dma_fence_ops;
struct dma_fence_cb;
+struct seq_file;
/**
* struct dma_fence - software synchronization primitive
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Return-Path: <linux-kernel+bounces-667798-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 8CDB641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:40:57 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 6F5531BA602B
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:41:10 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 9A63C218EA2;
Fri, 30 May 2025 08:40:49 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 334981FF603
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:40:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594449; cv=none; b=eWEhYIXZJTHF6aNbznQbVYk5YavSHCsfaIGuv89YuZrwC9FzaEwOFMxmNHh2ZN59IFO5qHnhUyMlWHJzELObvyoxEweEaLItw4JalClWqQ6nK1Xz+aQFbUuQpEeNbUXM2SATrix9FJK3l7Sghey7HFy3CKSRYQ6b5OGQa+f00I0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594449; c=relaxed/simple;
bh=yqSYWnaz4K1L61xS82ibxXVtPfkABdKiw6/rRUtJEuk=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=nU3/zjRZevOxeCqrakZPM8k7d9oBWjceMmqsSMoun5YYCE+Xfx1qdvv3XBKJlrDzsRE8/LsFF9sJHH3/daB7aPMkZP7cmoxGiVLWV//4C6Bj64bjPanFTYDDq7LDzHkxcM4wSdqQ7dACayEFSyeFLE+USnWUcsg/ijDDZXY5yj0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EEFB21691;
Fri, 30 May 2025 01:40:29 -0700 (PDT)
Received: from [10.57.95.14] (unknown [10.57.95.14])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ABF6D3F694;
Fri, 30 May 2025 01:40:44 -0700 (PDT)
Message-ID: <d2b63b97-232e-4d2e-816b-71fd5b0ffcfa@xxxxxxx>
Date: Fri, 30 May 2025 09:40:42 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: Enable vmalloc-huge with ptdump
Content-Language: en-GB
To: Dev Jain <dev.jain@xxxxxxx>, catalin.marinas@xxxxxxx, will@xxxxxxxxxx
Cc: anshuman.khandual@xxxxxxx, quic_zhenhuah@xxxxxxxxxxx,
kevin.brodsky@xxxxxxx, yangyicong@xxxxxxxxxxxxx, joey.gouly@xxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
david@xxxxxxxxxx
References: <20250530082021.18182-1-dev.jain@xxxxxxx>
From: Ryan Roberts <ryan.roberts@xxxxxxx>
In-Reply-To: <20250530082021.18182-1-dev.jain@xxxxxxx>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30/05/2025 09:20, Dev Jain wrote:
> arm64 disables vmalloc-huge when kernel page table dumping is enabled,
> because an intermediate table may be removed, potentially causing the
> ptdump code to dereference an invalid address. We want to be able to
> analyze block vs page mappings for kernel mappings with ptdump, so to
> enable vmalloc-huge with ptdump, synchronize between page table removal in
> pmd_free_pte_page()/pud_free_pmd_page() and ptdump pagetable walking. We
> use mmap_read_lock and not write lock because we don't need to synchronize
> between two different vm_structs; two vmalloc objects running this same
> code path will point to different page tables, hence there is no race.
>
> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
> ---
> arch/arm64/include/asm/vmalloc.h | 6 ++----
> arch/arm64/mm/mmu.c | 7 +++++++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
> index 38fafffe699f..28b7173d8693 100644
> --- a/arch/arm64/include/asm/vmalloc.h
> +++ b/arch/arm64/include/asm/vmalloc.h
> @@ -12,15 +12,13 @@ static inline bool arch_vmap_pud_supported(pgprot_t prot)
> /*
> * SW table walks can't handle removal of intermediate entries.
> */
> - return pud_sect_supported() &&
> - !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
> + return pud_sect_supported();
> }
>
> #define arch_vmap_pmd_supported arch_vmap_pmd_supported
> static inline bool arch_vmap_pmd_supported(pgprot_t prot)
> {
> - /* See arch_vmap_pud_supported() */
> - return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
> + return true;
> }
>
> #endif
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index ea6695d53fb9..798cebd9e147 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1261,7 +1261,11 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
> }
>
> table = pte_offset_kernel(pmdp, addr);
> +
> + /* Synchronize against ptdump_walk_pgd() */
> + mmap_read_lock(&init_mm);
> pmd_clear(pmdp);
> + mmap_read_unlock(&init_mm);
So this works because ptdump_walk_pgd() takes the write_lock (which is mutually
exclusive with any read_lock holders) for the duration of the table walk, so it
will either consistently see the pgtables before or after this removal. It will
never disappear during the walk, correct?
I guess there is a risk of this showing up as contention with other init_mm
write_lock holders. But I expect that pmd_free_pte_page()/pud_free_pmd_page()
are called sufficiently rarely that the risk is very small. Let's fix any perf
problem if/when we see it.
> __flush_tlb_kernel_pgtable(addr);
And the tlbi doesn't need to be serialized because there is no security issue.
The walker can be trusted to only dereference memory that it sees as it walks
the pgtable (obviously).
> pte_free_kernel(NULL, table);
> return 1;
> @@ -1289,7 +1293,10 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
> pmd_free_pte_page(pmdp, next);
> } while (pmdp++, next += PMD_SIZE, next != end);
>
> + /* Synchronize against ptdump_walk_pgd() */
> + mmap_read_lock(&init_mm);
> pud_clear(pudp);
> + mmap_read_unlock(&init_mm);
Hmm, so pud_free_pmd_page() is now going to cause us to acquire and release the
(upto) lock 513 times (for a 4K kernel). I wonder if there is an argument for
clearing the pud first (under the lock), then the pmds can all be cleared
without a lock, since the walker won't be able to see the pmds once the pud is
cleared.
Thanks,
Ryan
> __flush_tlb_kernel_pgtable(addr);
> pmd_free(NULL, table);
> return 1;
Return-Path: <linux-kernel+bounces-667799-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id BE22141E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:42:13 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 724443B335D
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:41:52 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 3F2F2218EA2;
Fri, 30 May 2025 08:42:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="iMGC0Txz";
dkim=fail reason="signature verification failed" (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="MGjsmIX2"
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32])
(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 4A64C1FF603
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:42:04 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.165.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594526; cv=fail; b=c1OTlRWcq9ObtXbG//6ZjTNvy7CTM3Dp6uX/jAOPY2eYlP/pVwXf0BmWxkdgngfLbvjiVk6UDozGCJSlQnNNxlR8Ke+wEkHIzTKI3fLbQggRZJaX41PL+NoIPUuS8FLL7IaZwLS6iKFUNwOqyd7fTY4MGrufAZcto+W5TamvCQA=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594526; c=relaxed/simple;
bh=vpJiNatHwpjEQgzQt1l75ddokeMV29pQXE5uTT2DJ84=;
h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
Content-Disposition:In-Reply-To:MIME-Version; b=jL/YJb4RSqcFFS20Q9HalF7nX84EPXK7EqWVBfHBQ8TK5Y0eZMjFB5suBE7yTwRyHc2DV427KxoyEsS74HR++o9YtPzhaYnCGPwb64k3aePmziesXYTV+w3pQyfHOjYkEe95XurmtJFEtTtldngdo3QkZnvq/Bbzk58/7nRDU6o=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=iMGC0Txz; dkim=fail (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=MGjsmIX2 reason="signature verification failed"; arc=fail smtp.client-ip=205.220.165.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Received: from pps.filterd (m0333521.ppops.net [127.0.0.1])
by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U6tvl5021244;
Fri, 30 May 2025 08:41:36 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
:content-transfer-encoding:content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to; s=
corp-2025-04-25; bh=XjrGy+K3ld3cJXAbnJJh+2ny4f0kzmjPP+9iZ5RsptY=; b=
iMGC0TxzYFYemdgTpO6q2bZ0ViZ2qIeU82dpaTvUmCRHBaokQQwkt8CeA3uzNnz/
r5rbmA3Hun18zmNzIQoBPQVMe0weU6VRridfgXb77bkH4zBGptGH+VvEjeSKnT3G
tcKFqPqhCP0Wwtc8AvxM38Gra2VG/TH09fADPc67g7fIas28vjXNKb65kgaF9kcR
h+kzhZ1Bf/nEw4F839JHdpJEchwdhAr0kaaWRpRq27SRVpmkNdvcFQMHEbVBhumi
/YrnfesEPRSH4FqFqz8Yv+W3oBqi+ObYt8v2JpniZuocDp/tQoJIt7Qj0W6YnSDO
ysw5md3t11uT+uHlKZk+ew==
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46v33n1uaa-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 08:41:35 +0000 (GMT)
Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 54U8XZVF025675;
Fri, 30 May 2025 08:41:34 GMT
Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12on2043.outbound.protection.outlook.com [40.107.237.43])
by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 46u4jk98tc-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 08:41:34 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=kwJNKewyNcoGnR4LRwXkmJD8nE0YRkM+sKurnDL6SL2l8EJ0X6GMlU+ryQ3/1k4vpoozrwTUCtriwYKhIDvYnfY2eklmLaQrstnZAr5v2FiO5XEzsSoPxtaplmL6F1SEwDs6XAVTDMOpSAmGNrRj1+Cso7CnrHN8aWsphD4X6v64nCxFz8QcxfXKpD4cjtPb1qn6baYGJBJOlMYqd18qGrduJ8IuoyPhgHNNNGvNbHIVGVIWNc3LLtDFnCUhUmDVYs/ZcbjfXVrhn1Z2s0rwL6nynlL4KoOErFDpXXFHuk11CyJPmP4UWhrwqytmhv6v1q2XTpaGdEd+zGga4TNaYw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=eHo/GMSJOhHaA3KnM7Cr+xF8G3tJVTJ/+2W3K7CM4QY=;
b=U5lgmIl2EuOrrzbTqS01h3sUZpc7PcJUGBi6iWPoiMyqW32mZwhM/xVS3vTascSqFWkVX+C3wepi+i9Lu+7ed71TSxFOVVhR8Zj4BUWljZ7U+3DU9yraRleDlCqCftGSW6BIPg81HgQUmTcxfn+ccrNixjCUayj83ImPa8T0fIEaiOON7yPmVizpePULNZZDQRFeJxBqKAM7RdJxA8aGvG0AnlGy4kRSEsjhYUJKYSHn0QrdlDdHLqdBKE2WD6MPCwzyJuW4ZYI9ij/ZZaMSXhZ/20fE35x+Es9IfauYWJKElP2bGosN4sTLTs1lF4OAoQE6MWeTx4IWUsomCThhbQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=eHo/GMSJOhHaA3KnM7Cr+xF8G3tJVTJ/+2W3K7CM4QY=;
b=MGjsmIX206jTVD9/IYSdFlsI2JJoh9YSyL+VveKYbsldyZ/NHxP4xYcJFJG+ZS9Z48puqmOcvG4T2khXR1AKkpIpLhcjj9PCM8QSAxagwsQN52q9pUlTd76RD4Fb/waiHV7mXZKc39PatyXWZHLTrjlZ0OEtFEqtokn0Qu0JTak=
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
by LV3PR10MB8155.namprd10.prod.outlook.com (2603:10b6:408:28f::9) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Fri, 30 May
2025 08:41:31 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.8746.030; Fri, 30 May 2025
08:41:31 +0000
Date: Fri, 30 May 2025 09:41:28 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
To: David Hildenbrand <david@xxxxxxxxxx>
Cc: Pu Lehui <pulehui@xxxxxxxxxxxxxxx>, Oleg Nesterov <oleg@xxxxxxxxxx>,
mhiramat@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, Liam.Howlett@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx, vbabka@xxxxxxx, jannh@xxxxxxxxxx,
pfalcato@xxxxxxx, linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
pulehui@xxxxxxxxxx
Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when
expanding vma during mremap
Message-ID: <b2dd29b0-aa12-4cb7-9c05-d3a998f7b0da@lucifer.local>
References: <62b5ccf5-f1cd-43c2-b0bc-f542f40c5bdf@xxxxxxxxxx>
<afe53868-5542-47d6-8005-71c1b3bec840@xxxxxxxxxxxxxxx>
<13c5fe73-9e11-4465-b401-fc96a22dc5d1@xxxxxxxxxx>
<4cbc1e43-ea46-44de-9e2b-1c62dcd2b6d5@xxxxxxxxxxxxxxx>
<20250526154850.GA4156@xxxxxxxxxx>
<06bd94c0-fefe-4bdc-8483-2d9b6703c3d6@xxxxxxxxxx>
<57533126-eb30-4b56-bc4d-2f27514ae5ad@xxxxxxxxxxxxxxx>
<cba0155e-d2b9-41fa-bc51-f3738ae73cff@xxxxxxxxxx>
<956124be-c73c-4023-9edd-25372f3f865a@xxxxxxxxxxxxxxx>
<ccf359b0-8baa-4209-b2c3-75e3813ca804@xxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ccf359b0-8baa-4209-b2c3-75e3813ca804@xxxxxxxxxx>
X-ClientProxiedBy: LO4P123CA0073.GBRP123.PROD.OUTLOOK.COM
(2603:10a6:600:190::6) To DM4PR10MB8218.namprd10.prod.outlook.com
(2603:10b6:8:1cc::16)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|LV3PR10MB8155:EE_
X-MS-Office365-Filtering-Correlation-Id: f2fc1e5c-9f32-474f-3a4f-08dd9f55c6d7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014;
X-Microsoft-Antispam-Message-Info:
=?iso-8859-1?Q?qOsB14R4hdFLnuFzBC6sr4D6cQdA4GDT6d2NC9gY8dUzTLJY6axuc4a3w4?=
=?iso-8859-1?Q?X1w44wXDx7Os3lJBkdxrLw6N+XRyKYL57nazAzE8/B2FeBWA5U4K05kyHy?=
=?iso-8859-1?Q?7ekUjiRZr3EpBTe1r0yOUhlwxfKvkFlGKlOQkzsm4a8lqHVHdqL2rPp93J?=
=?iso-8859-1?Q?EgX1qQQZt/D7T8Si8HUXwvYNSrqZxnxQ9g4dfrcyFpG52NXdd0NsA7Y9fK?=
=?iso-8859-1?Q?61NZ2oW76nxLQXnAOdiJ+0ve/ZJR0y69Oa8wNkiPYKqPHOaZZuqDDNrXCn?=
=?iso-8859-1?Q?ef6AUXIUhYbxdKyU7idcN6pGUBNpXVYGPp52KZlmz0K1gTP3+ftOJWLz1l?=
=?iso-8859-1?Q?nF0CN/6GHJDh4yKK8+A0AEa6tGOBUPPYsCFiyZS0LUdX3UTQE34MkAuS57?=
=?iso-8859-1?Q?9zzkZ9TzUIlUVpQXRrsdsudIV3i2icELncwNXrvIYN1w+npvMUAq5Bb7iF?=
=?iso-8859-1?Q?W0KogJEDp60ym2WpSd8sp0Jda5mqq7E2C5uzJwyLKMaz26t4eLBufdBI8w?=
=?iso-8859-1?Q?1TIbmlPL4w4amldBvOhGENiaU0ZAStEvhf2CLlJw9Q1/1Jwdk1CFAENDFt?=
=?iso-8859-1?Q?0jx9EKOloDJh3XbZodx/yP6OGui9lWWCGcOpta9vOp2lZQ48MqY5NsfLj5?=
=?iso-8859-1?Q?NBb6l5S2OENiJpSnNpEUBh4SqyGOZtnV1W+HnsYxi4sKaqxN76EscHXLNf?=
=?iso-8859-1?Q?Zh3x9VJhAsI3qATm2NkB5YwPy4Ovksui423ChsiIeZBeC2aiFadYJCjJQw?=
=?iso-8859-1?Q?hBJjF1rQlmsV+qhm/lqSFFgm8dgIyvPEHXqky4ESaMTeehd2C1a/ovsjXR?=
=?iso-8859-1?Q?TT8ugNi3SJdV/5BgGj/Lji41oyp5uuz3RmTnSRTiMRv/iUXgdrf5IYi9Ez?=
=?iso-8859-1?Q?TnpAZhT0nd8Axx0TISr93AYShxQ0A3VKn36epx4lAJzvzlh1EAs7AP0Sk2?=
=?iso-8859-1?Q?zQ4EII10rLgdVQ4DyABm7oCLBmHO9Jf4LbaoXggPefkNtO5pl4evAQmLaE?=
=?iso-8859-1?Q?HRRTbKBfebdsseHXdBLcpU+45EB5B8VW6Rihx25wJcf0SOwd0RlIE5Duk2?=
=?iso-8859-1?Q?G84sEZPIlsF4SFGAx1K1k0GQnWf+YbipnfYRRxaKd5rGrXiX+MCN6/qKex?=
=?iso-8859-1?Q?X7duVvavweYrQm5O8SKU/g7115uyYnVxpYU6i4EkdaIm3TJLIXC3mwJX3d?=
=?iso-8859-1?Q?5u/H14M9e2/rRkJKrfbUJd+1bySCl5/weEH1vvDY9Bu73qbHjjWgx+zcpe?=
=?iso-8859-1?Q?Ar87qlc5t5WusZoQW4rGy+vuNJcnG8UHDukQSJNrpg4K5aMl010QPNO+gg?=
=?iso-8859-1?Q?LUqFBnZ4+J2dyjDoCkEza5Kyy9dlIyL64k8QDQCvaNAYhID/Zf0nrQen6b?=
=?iso-8859-1?Q?yQ2bpShAdbhWRh/87qjJ5k7aUbtn5+Hvh/rItQ1pd/ZD/OD1d6hPFj68yP?=
=?iso-8859-1?Q?kAIGkiUNqHh6c/iugd82ttWl3sD99uqtjMbfsJYG0PKlvIZB0RjpwLJ0wY?=
=?iso-8859-1?Q?k=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?iso-8859-1?Q?sc92CFAfMjco2WAI8PNy9VpjDHpvNlBaZLpxuuD/I5+0wmdR/bf3UnUWtK?=
=?iso-8859-1?Q?LmQ9wagHMZ//k3AVHnL5I6wbxTDB2q1YyFwrFZ5tyFa5ltXHrwECsNqSvU?=
=?iso-8859-1?Q?CmlUPYrHAyGK1L9lEWdDGrNT0aOnNTHcTBzANxpw6spwSglfH84CrvYlwn?=
=?iso-8859-1?Q?IaoTLMa0Tn/R7FN7cFu+MnMn8rbQL4AY/epagy03rliQWfv8BwOmhProX8?=
=?iso-8859-1?Q?f62zcp4sYco9RZwqyQyQcGD4ZuZuxqx4o/e3E41wIjrgce0EbzijJw/1W9?=
=?iso-8859-1?Q?dANZ6OviaVV3vDn1PrwWm3pVKjhZqX2gueP5/aqlPHD2heDfO5ydNmGxHA?=
=?iso-8859-1?Q?UmQHBkwkYILHjB6t3iR1gg1ILoZ4oqxK2tKwUe3PqrcRKVzNVsTt02joln?=
=?iso-8859-1?Q?qBBLo5N+doahsr75SZoizO6uRA6TBKWdYp+BE5QEZKBiUTo+5ufHoSH7t2?=
=?iso-8859-1?Q?A2VH3jyfHR1CC4bLHUMo3jNN9r2z9/pZb5HAldr3iTjk1MnhyeYNGGp7GR?=
=?iso-8859-1?Q?GwP+Ptxb210JzXkcSed61DH7S024TMFFQz86KrSbq+iwPXNpyzQQxDfQ5+?=
=?iso-8859-1?Q?LsVPJ2fa7nXROUhGufHzirBtzwMV8CeaL3DWXozCHIztGElVpqHXNn7qQU?=
=?iso-8859-1?Q?YDPrJPx+VtDhpMFa2U8gHIZH9zgZLZTSDcXIXoPb9KVdkYXYikgj8baemP?=
=?iso-8859-1?Q?yJ9e9LTsmIGBlQYALisLBpX9D4uGHgVMDqZo5P7CEqK4QM5qUAocwubqq5?=
=?iso-8859-1?Q?Sga8H0YIrSUWpFBGjVWNl+whtM35VDpsLOX4s3T6PtVG8Li4P4qMkyLIqo?=
=?iso-8859-1?Q?Z6eVCovy3gl05LQngLl0qSf6zRndPPxVb7yst0XnDTUXfciIIbWFapyNRv?=
=?iso-8859-1?Q?p88R6bZWd3lnihoGL8zNv25ZvBpI1KEq0x3j0t2CtGKISNbXyj47/tK5un?=
=?iso-8859-1?Q?oETU/m4cbht/mYPC57rgzDYV2OrQH03Ihbu44tFNiDRZ1c4S6FRaTJsyKn?=
=?iso-8859-1?Q?M7SALgbausfBbZ5bEERXvF3AJybXx3cpjZe9tfUxmBeHtcsFmf77hJgOsj?=
=?iso-8859-1?Q?p6/YaIiwqfX3pOcL2nBiTagNic/qsglb/MQ9Pzsw8NSataSGU+RWQCmTQ4?=
=?iso-8859-1?Q?ZXJfy/RAmiHTrFlKQVfWBXeBfdIMdNEEKvlK/0XVCIxjqK1i/j97msBlRT?=
=?iso-8859-1?Q?9LqaqVUxZUmHaTJJHTzABtf7LMs2YCBg4XSOcybP5teXTWzOn0a8QGS5Ua?=
=?iso-8859-1?Q?cMxCElkwA2F2jJcYdPlqal0JOJfuYq2Mn8DSlTcXe+oALWz+YsoWW4IqWQ?=
=?iso-8859-1?Q?p42vZUmOfGAKabsWUN/NQL/xYoaOtyVsPXDLmDjp8C62Il+EfBmQmHeiFI?=
=?iso-8859-1?Q?VR/42hHo/3XAsEfHhKBkbuSbdnIYXbqsl/KvKZ9CkSSQvEpithIzc4Juw/?=
=?iso-8859-1?Q?5YIJlnb998x//BWJakorv9xO2mvbdeDDTkDh182pXv2Xmd86PGGl7wzlZX?=
=?iso-8859-1?Q?d9Z8vlFvhUNUKzLZAVuBecaDjgn1jsqUBo7St2MHMwj8wK7JtT7UJvOPd0?=
=?iso-8859-1?Q?SxMMWp+tDTZ3Ihz8aNxS/35wA18q6BqkLkaeUr85QYDQ19YhocQ7V0TIu3?=
=?iso-8859-1?Q?/KXINtnuCzpd2zMByCsFkhfsrWZtaUJEanRDwSeBPfuv7fYWS0uZkmqQ?=
=?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
Lqh2+3iWhzNujORIjMY0/ABT4daDCmMWQ6e36j7rb7o9vsX5JCzClESJHZcYbJGhQXr+fBJO6/mv/8rpp0H56dsRpdv4fVxDxBzyV5EKeVkoVNocu5WOK5gEf54Y4JAJzk+0nkCm/1KbD1fPyPZs5WeVawHyHT4ghwC0nhz0N+YlTGedEueXegKq7de0ijHxAXtahZosKlv2bjDVQj45sMowKbJYbWZPVdpRn0IVITddEZRHcu+F245AbBMXS3mNsNnuJPjaQEoTfRveuG7sdl/ahVUvDYNw85tu+qVF8PRY2MN9UgiC8QMBpXPv89AoxVD/L1HetHr94swdJcF/hrvuHix0kNRQvjX5mmJxU1Npqne+oqOE6BUOqFH2lsfje8v1IU8yn7pOqj0L/ogKbj5ipyCJrWnWC1L5HXkc3kRb30+AQdn7UrjXyBnS/tIr8MY8JrGBdUZY5+3EYh8uy9Vxcz+qjnE8Cs+Oh03wbwF+UmSKKauMBdROyDmrU6P5O2T1r9ICAISTfmiLwOGWqtgZA8by586dcVQ0yyXsL4LRfeNRQpUBfzmz/Zxlx6M2CxF1Dga9lp63ZqRACAMcim7Mod7fGv/V3psDAcx4t/Y=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f2fc1e5c-9f32-474f-3a4f-08dd9f55c6d7
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:41:31.4251
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: YeCn6qrVhVbDQ9yveC6sqVU3ZE2J/7ym5kZXkPeYi72KO7JkLKwXYpXz8CFBKXRB4qYRqSVQ/GElpBIoKeiBpIQEa4V24Mw9W1XaTggUalc=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR10MB8155
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_03,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 phishscore=0
adultscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
definitions=main-2505300072
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA3MiBTYWx0ZWRfXwsqo9XDsF2Ui 0fKjvUZpJk8AuWcOtHc5pPa/y2dRxcNXWTfHQeaNzsowHtAMYTxs5Y/KlQsqTzm+xJLfW2SGLvT ZKc2wzygSCFSLYePvdHJ6+wX30QRtf7mFwTnPsHO9nI58KVct5zl8NTeXQ5c8jQlouh6lR3VBH1
u6d2Pq+nA+uuFWtRb7VcRP0THJgU7lqM7IiEGLwXyxIjMSGnyJtD+ryc+pJGLg4iG4vSLoPqpVo p7ylShnzi6l6YobuR2W0PAJW2xlxDMWAiHnPytWZ7RCmLHNzUakuqp85x3/woXuh8aeAgkIoFN1 wivmvRMFn0IjpxxYD0Mxo6a1Xxku7LAruWgh/U+M68eOSVCFZyuAUUKYF8a8xM7iQZVDwC4Fniq
JdNbCLOSBoLhTuSlT1XgXMqZoHRJxGHaJSSV0A6T6mXHRyzqGSfD4OczEVwXq3gyXdINkhj6
X-Proofpoint-GUID: RI9xJiI80gG73zRsuev3e2PwZfbUiJS7
X-Authority-Analysis: v=2.4 cv=aO/wqa9m c=1 sm=1 tr=0 ts=68396f3f b=1 cx=c_pps a=qoll8+KPOyaMroiJ2sR5sw==:117 a=qoll8+KPOyaMroiJ2sR5sw==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=8nJEP1OIZ-IA:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=m4nWpse8auxlaRyR1JsA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10 cc=ntf awl=host:13207
X-Proofpoint-ORIG-GUID: RI9xJiI80gG73zRsuev3e2PwZfbUiJS7
X-Spam-Status: No, score=-3.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 10:33:16AM +0200, David Hildenbrand wrote:
> On 29.05.25 18:07, Pu Lehui wrote:
> >
> > On 2025/5/28 17:03, David Hildenbrand wrote:
> > > On 27.05.25 15:38, Pu Lehui wrote:
> > > > Hi David,
> > > >
> > > > On 2025/5/27 2:46, David Hildenbrand wrote:
> > > > > On 26.05.25 17:48, Oleg Nesterov wrote:
> > > > > > Hi Lehui,
> > > > > >
> > > > > > As I said, I don't understand mm/, so can't comment, but...
> > > > > >
> > > > > > On 05/26, Pu Lehui wrote:
> > > > > > >
> > > > > > > To make things simpler, perhaps we could try post-processing, that is:
> > > > > > >
> > > > > > > diff --git a/mm/mremap.c b/mm/mremap.c
> > > > > > > index 83e359754961..46a757fd26dc 100644
> > > > > > > --- a/mm/mremap.c
> > > > > > > +++ b/mm/mremap.c
> > > > > > > @@ -240,6 +240,11 @@ static int move_ptes(struct
> > > > > > > pagetable_move_control
> > > > > > > *pmc,
> > > > > > > if (pte_none(ptep_get(old_pte)))
> > > > > > > continue;
> > > > > > >
> > > > > > > + /* skip move pte when expanded range has uprobe */
> > > > > > > + if (unlikely(pte_present(*new_pte) &&
> > > > > > > + vma_has_uprobes(pmc->new, new_addr,
> > > > > > > new_addr +
> > > > > > > PAGE_SIZE)))
> > > > > > > + continue;
> > > > > > > +
> > > > > >
> > > > > > I was thinking about
> > > > > >
> > > > > > WARN_ON(!pte_none(*new_pte))
> > > > > >
> > > > > > at the start of the main loop.
> > > > > >
> > > > > > Obviously not to fix the problem, but rather to make it more explicit.
> > > > >
> > > > > Yeah, WARN_ON_ONCE().
> > > > >
> > > > > We really should fix the code to not install uprobes into the area we
> > > > > are moving.
> > > > Alright, so let's try this direction.
> > > >
> > > > >
> > > > > Likely, the correct fix will be to pass the range as well to
> > > > > uprobe_mmap(), and passing that range to build_probe_list().
> > > >
> > > > It will be great. But IIUC, the range we expand to is already included
> > > > when entering uprobe_mmap and also build_probe_list.
> > >
> > > Right, you'd have to communicate that information through all layers
> > > (expanded range).
> > >
> > > As an alternative, maybe we can really call handle_vma_uprobe() after
> > > moving the pages.
> >
> > Hi David,
> >
> > Not sure if this is possible, but I think it would be appropriate to not
> > handle this uprobe_mmap at the source, and maybe we should make it clear
> > that new_pte must be NULL when move_ptes, otherwise it should be an
> > exception?
>
> Yeah, we should ay least document that if we find any non-none pte in the
> range we are moving to, we have a big problem.
>
> I think the main issue is that vma_complete() calls uprobe_mmap() before
> moving the page tables over.
Well vma_complete() is not _normally_ invoked before moving page tables,
it's mremap that's making things strange :)
That's why I think my suggested approach of specifically indicating that we
want different behaviour for mremap is a reasonable one here, as it special
cases things for this case.
However...
>
> If we could defer the uprobe_mmap() call, we might be good.
>
> The entry point is copy_vma_and_data(), where we call copy_vma() before
> move_page_tables().
>
> copy_vma() should trigger the uprobe_mmap() through vma_merge_new_range().
>
> I wonder if there might be a clean way to move the uprobe_mmap() out of
> vma_complete(). (or at least specify to skip it because it will be done
> manually).
...I would also love to see some means of not having to invoke
uprobe_mmap() in the VMA code, but I mean _at all_.
But that leads into my desire to not do:
if (blah blah)
some_specific_hardcoded_case();
I wish we had a better means of hooking stuff like this.
However I don't think currently we can reasonably do so, as in all other
merge cases we _do_ want to invoke it.
So I'm kinda not in favour of moving things around just to suit mremap
here.
>
> --
> Cheers,
>
> David / dhildenb
>
Overall I'd suggest the proposed approach is what we need to fix this _in
the short term_ but am obviously happy to see proposals to make uprobe
stuff less 'hacked in' :)
Return-Path: <linux-kernel+bounces-667800-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 0023641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:44:52 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id A28903B3439
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:44:31 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 0B5431F5425;
Fri, 30 May 2025 08:44:45 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KegqXLb3"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124])
(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 3C90221578F
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:44:41 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594684; cv=none; b=AjaKtUPWNKJjlF3HZF9aWgO/Gag78E7Yr5l/lpEyGS0TOIDnrZ+zY/EQOd9MbB4L6IGgOL6MEu7wWAJDpwsAAN29SY5GfQ/dfDHQxk8ZabTo5MXDExTOJLZSngD94Wy2NTsOBT4ahyK/+eDHvdO0sUkeRMsgjpylaKkiH/wMBJA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594684; c=relaxed/simple;
bh=+inx4YX7P11q+gVVxzr9vdPZCaXWtbFLqOTGNf3L8A8=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=GWXAin6ivYUeTXQOPOsbTbxIG7lOhtM2bCfCNFN61Jp4RwGouzMqQsPMIDkVnfyxqmMCBjRcQ5aUC1F7oPcVXjYVqk6DcG6b7BONnISJLx5019mdhGHUlqglkAJ+0jUrTigkmPqTYT/4uB1+ckFeDr6WKJLLXaTndnp5YEdzRJA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KegqXLb3; arc=none smtp.client-ip=170.10.129.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748594681;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=rf7ekt8VnRvnpxfQITfqFspKdTksrMp/VZM9tAi2xbI=;
b=KegqXLb3VG26fNHa4i29WHXgnaHLUG5uYiWN6ZAPAmlkXWwJL+ZNc5CGjZm17ewJZB4pVv
KZQEuJ7Xy7kv65mAd+4BpabR/3NiXgFduzvvNXnronOBjpY/tqsdy3X4oVxSTSh0oaah7u
jU9I/8ILlzEX3pllG4Jo+4WUfoIQk0U=
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
[209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-223-m1LAx0cHN4-fnoLW3ie2lA-1; Fri, 30 May 2025 04:44:39 -0400
X-MC-Unique: m1LAx0cHN4-fnoLW3ie2lA-1
X-Mimecast-MFC-AGG-ID: m1LAx0cHN4-fnoLW3ie2lA_1748594679
Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-450d244bfabso10825885e9.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:44:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748594678; x=1749199478;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=rf7ekt8VnRvnpxfQITfqFspKdTksrMp/VZM9tAi2xbI=;
b=aShJg/bHJB4IOBhH1fFeG8Uzadlj0uuJk3xpWW/w1HLiT8TqPa8RaH+pKDLRuw3hUv
fb03QBPc9eeDzTD+qwENxXJrGuRGBOsIbewvycF0HOeOA7JH01xZAlo4ZavifaUCM/7i
/nUU7BS4AesFpC7jfxalbTd5GW7xcZZzNUYBJnZ++vSn8uhXibLE5cY+0z/potSUkQK3
0J9QZI5zR6M51dxFpRodf7rBocx5kWpI4wWu1MPmQyXKqiMFehQw8FpDxOl69tSXCB1T
sD3f/cqfKRfcHtULOphm4fxbluXzJkUqef5dbr12b7Q7/VfJIdYk1VV3lxZkkjyCeUNy
sGsA==
X-Forwarded-Encrypted: i=1; AJvYcCUFncAXGeN4gHEhWk21xV8msQD/NGQNbn5uTESH1iT+DlbesIgtTgkldJ9Dl4lSswMxlh4tTsHw3kSL1G8=@vger.kernel.org
X-Gm-Message-State: AOJu0YyWAKSVdDri0HN4IoM0M1zxWZMtFhYm7m9NfGY9jHk0gVvPKoFx
wR/bHajJnYXXMrf7avubj8IyLCHb2UBSI2Bw0j2app6zRtCr/jMAYjdHiAeLhtyr0ze6LTruRyF
fzpVyTHlNEK6PPDylhp62LJBpxIEudRGXy9T82kcBNRKzBKVaAS92mn35syDdNZA1MQ==
X-Gm-Gg: ASbGncvj2uuchCD0JcW6Kwmv0V3qQDf+QI3d8UFb9IlhNkcgdzeJst3BeAY6UnPJnkP
VWAn5z2ELOPpi7iuVTYKD57/n3qlMJvQVcS1Wd9cWFZAiv3suovie/ZVOuju/r5k0m5oOB7elfH
RWNh956doWZmr/qcBR9hSXsciBjWhYhOlIGLXImFK+Drnt25BtMafcNIKixyBPqlEfrlTfg/EBh
clk9uK3nj3dCkTfWKW0tw0OOIV3a4z1a5pnyieOUYVQdrcpnnHnkqcnXqedJ/FO+ZTxm7asypPD
0rEg+t0v8HCblNN5tn3d+3e7v+luF0n0eP5mCiGxBQ5gr9+0I2Nz43vf4WJqsGAO4dK88tBmYzF
i4c5iPv5F9ZAyuCYuppy3PYaWdNMzrwIc/+lOzpE=
X-Received: by 2002:a05:6000:220b:b0:3a4:e706:530c with SMTP id ffacd0b85a97d-3a4f7aad050mr1548767f8f.48.1748594678618;
Fri, 30 May 2025 01:44:38 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHIkKMFr+MevLcEJ8ZP1NLcyzoARn0tQT37zO+7jYywL42mXmcgqbYEYi127MxJvgq+J5nnZA==
X-Received: by 2002:a05:6000:220b:b0:3a4:e706:530c with SMTP id ffacd0b85a97d-3a4f7aad050mr1548751f8f.48.1748594678231;
Fri, 30 May 2025 01:44:38 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d8006952sm11532685e9.32.2025.05.30.01.44.36
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:44:37 -0700 (PDT)
Message-ID: <f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
Date: Fri, 30 May 2025 10:44:36 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
To: Ryan Roberts <ryan.roberts@xxxxxxx>,
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 10:04, Ryan Roberts wrote:
> On 29/05/2025 09:23, Baolin Wang wrote:
>> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
>> the system-wide anon/shmem THP sysfs settings, which means that even though
>> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
>> attempt to collapse into a anon/shmem THP. This violates the rule we have
>> agreed upon: never means never. This patch set will address this issue.
>
> This is a drive-by comment from me without having the previous context, but...
>
> Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
> user-initiated, synchonous request to use huge pages for a range of memory.
> There is nothing *transparent* about it, it just happens to be implemented using
> the same logic that THP uses.
>
> I always thought this was a deliberate design decision.
If the admin said "never", then why should a user be able to overwrite that?
The design decision I recall is that if VM_NOHUGEPAGE is set, we'll
ignore that. Because that was set by the app itself (MADV_NOHUEPAGE).
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667801-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 5BCCC41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:45:33 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 540E93B3825
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:45:12 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 434D621C182;
Fri, 30 May 2025 08:45:24 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="NUyr/C87"
Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2064.outbound.protection.outlook.com [40.107.101.64])
(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 AA4F0202981;
Fri, 30 May 2025 08:45:21 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.101.64
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594723; cv=fail; b=swenskiMn5jLrK5pciZIPKwYPEFuh7/D1p8NYZ5GE3beEx9L4jygStwe0ZBBKSb3+jJ4xb9n3SIjDTH2cNMd8KJzmP3Bk/2HrAT2fYUMHcwTDy8mXEwCJ0pG/QnSSd8QS8B/O3bf2OR1Ubu6RmVXPnOfl5NKysvZwbG5v5GRYto=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594723; c=relaxed/simple;
bh=gvSwIdKhxUfX0QsllPkgAKUbeM2UvYlJJLE9XARdlAk=;
h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:
Content-Type:MIME-Version; b=nkrP2OXWpQGBwkJNZjQcOWuY/nBtx6VFKClJji9ycSeN/lCGeFaoVpetCFNm9VDdkY78vmHEjJPKIfazDh4u+92khApHZIL/eGp2blhLyY86vt6tRgWIXV/dPj+dy2pDwmQj9K/GUxet28Vy5LGnUrNp22HwORTMqamhXA1mg0s=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=NUyr/C87; arc=fail smtp.client-ip=40.107.101.64
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com
Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=G65CawLKlkmTAWs4ATPRuktivlLtj6UIXy7rGJ1eWNBfi1u7YPLZ6NpOBg7PtKjux095x/2w/6iQPoUwD8EDg1YXvjFK9eT3XctsyTeFPwctcSW8EsjFS0obPtYnDayHJZZIqMOJ5I7IgZ6BIlCPEmHTL4tAQlvozgMiMt6WHIdr5KJwjZ+efiaZmltoKVoyT96oSVBK2n10TGjxg1KmGpIeDcPKheMO2Y0Sn20LOSMzSpwsYdOvaXuswndTy85bfFiUPz+JwMVY7ogYMSdxnJ70eULgZoC5hYRwNVynoKvsfoWsgAIybSTfg8qWLsJsGAD2TqMQedzWwuYOHwU9vQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=PMP7gSJSsWqHr1SBIYZPTVQ/6RbTbRWAcWpitNSmsIQ=;
b=uT1bg+cxOEadHOOonlS0Qgaqyn/atXL/rOez94sOiveCGx9K4Hb94JPJ2kRuZN0pxsrwDGzNLrCTsvIGZLrPbSPwRcqCfPLkrPcR1XMoX4F0uPFtBK8auIV8tiHffseylYqukwe+dLlURWmf2c5gbsv6piLmAFbVnO8LgZWvphjM6lZA8cy7VSz7zVEQNuMDZKoPMaYIgwCsv31+uT64SVbkKluPEdT4rCK6PmQTGhSAZCJxbw9iLC2+V3bd9QdUqsezf6aVIo4TPdCvT+FUwRMmuOpAsQ7GPeNdwdMmZYijE/QGx12G6Mdy2QNLgHZG8PIKe5GpJxZ2GNTZ7L3cpw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=PMP7gSJSsWqHr1SBIYZPTVQ/6RbTbRWAcWpitNSmsIQ=;
b=NUyr/C871gFE0aK10Di/yrataN5P3Al7IoZjBthOYP9ubgF+xcDExbTr/jgSdKC5N7fuxS9Nbe1vaMhq4RmDap2v7YxcH5Y/FDstnBX0pWsoyhaNjfsOB3m19c+uxb5bCiqL1w77gKvjRIQGo3vVSBqoaUYE7Vvi463ixUH/rxw=
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=amd.com;
Received: from CH3PR12MB8658.namprd12.prod.outlook.com (2603:10b6:610:175::8)
by SA3PR12MB9131.namprd12.prod.outlook.com (2603:10b6:806:395::15) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.31; Fri, 30 May
2025 08:45:19 +0000
Received: from CH3PR12MB8658.namprd12.prod.outlook.com
([fe80::d5cc:cc84:5e00:2f42]) by CH3PR12MB8658.namprd12.prod.outlook.com
([fe80::d5cc:cc84:5e00:2f42%7]) with mapi id 15.20.8769.022; Fri, 30 May 2025
08:45:19 +0000
Message-ID: <fbe816ac-8fe2-430e-aa68-15737da98ec5@xxxxxxx>
Date: Fri, 30 May 2025 14:15:08 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 08/13] sched/wait: Add a waitqueue helper for fully
exclusive priority waiters
To: Sean Christopherson <seanjc@xxxxxxxxxx>,
"K. Y. Srinivasan" <kys@xxxxxxxxxxxxx>,
Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>, Wei Liu <wei.liu@xxxxxxxxxx>,
Dexuan Cui <decui@xxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>,
Stefano Stabellini <sstabellini@xxxxxxxxxx>,
Paolo Bonzini <pbonzini@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>,
Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Juri Lelli <juri.lelli@xxxxxxxxxx>,
Vincent Guittot <vincent.guittot@xxxxxxxxxx>, Shuah Khan <shuah@xxxxxxxxxx>,
Marc Zyngier <maz@xxxxxxxxxx>, Oliver Upton <oliver.upton@xxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-hyperv@xxxxxxxxxxxxxxx,
xen-devel@xxxxxxxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx,
linux-kselftest@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
kvmarm@xxxxxxxxxxxxxxx, David Matlack <dmatlack@xxxxxxxxxx>
References: <20250522235223.3178519-1-seanjc@xxxxxxxxxx>
<20250522235223.3178519-9-seanjc@xxxxxxxxxx>
Content-Language: en-US
From: K Prateek Nayak <kprateek.nayak@xxxxxxx>
In-Reply-To: <20250522235223.3178519-9-seanjc@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: BMXPR01CA0078.INDPRD01.PROD.OUTLOOK.COM
(2603:1096:b00:54::18) To CH3PR12MB8658.namprd12.prod.outlook.com
(2603:10b6:610:175::8)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PR12MB8658:EE_|SA3PR12MB9131:EE_
X-MS-Office365-Filtering-Correlation-Id: 56852ec3-8af5-467f-d3cf-08dd9f564e76
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
BCL:0;ARA:13230040|1800799024|7416014|376014|366016|921020|7053199007;
X-Microsoft-Antispam-Message-Info:
=?utf-8?B?czMzbnZMVzJMaW9pRHBmRUU0QnN5Nm5XcWFSS0pFeDVDcWZjbSsvbGhURUlO?=
=?utf-8?B?RWdySEI2UUpOMS92RzNRU1lVU1JxOW9GcDh2anZsUWo4SE0vQ3NUMWUwR0da?=
=?utf-8?B?dXRvYWFyZ1cvMDJ1VUpqR2NSSFd0TmlHZlA0TW5renhqUlU3Q1ZBb24raUQ2?=
=?utf-8?B?NnFBRWQ4cEFQYVFNdnp4STVBZ2Y0MnUyRVJCaG9zOFFPVlMrN3FhNjhZU2s4?=
=?utf-8?B?ZGpQdkFlRzhVdnY1R2poMlBqODR1Z0RxbXJrQjFvVUIrQXpPWDJTN3pUNVVv?=
=?utf-8?B?UjBNRXcrS0tXY2VDdS9GcnJxZGV5MExuS2RRT1ZCVHhPckkwT2QvRHlIalJ5?=
=?utf-8?B?SG1EdmFyUkNrT1FOMytmN1kyY3QwWXJvbXZ3cE5tYTNWWkY0dHdUc1dRaFRI?=
=?utf-8?B?VmlIZzZLRitCWFVOOXp3akIvd29CZnZHazFxMENOSm1yUWtsb1hIdWVKVjlo?=
=?utf-8?B?TFp5U0lMVFFsOXdVMWNHRDVlSkJxTFhRR2M4VUxzWjJXb3pvTkJmY2h5NFVl?=
=?utf-8?B?eUZtT2twaXhOVW5CeUpTT1pXbXo2dUFHa0VRcWxsc1RCSHlBYXcxWVh1QmtC?=
=?utf-8?B?blEvbVlrUjdRYWVsdnV1L3hWdzZ3bTJRdGgwYitwRHlQS2htK1hSK1BONFNm?=
=?utf-8?B?VEoxaXRmVFZBSEswdjJEYnppaS9hZFRnUFppU3lWMDNGRVB4TUE0N2dQMWVj?=
=?utf-8?B?NzJGaFpMaXAxWUVkL2p0a0NtLzFFc3o4SGFzK09vUlpVMElFUGx0eURUcjZW?=
=?utf-8?B?a0ZuMXRTRUJ0aEEvYUJhMnpld0xEbmZSdGpRQVZWR0JuNUZkUkUxUVRBWUhK?=
=?utf-8?B?NUtSMkdIV285OVdjMjAxUit1c2NydkJkcTlPUjBPYndZTkh1cHFMWjFRcFcr?=
=?utf-8?B?V1JmR2l1QWF0WGkva2U1K0ZLQlBpelpLYU1NYlBoVzJ1VERGbzhhOEpPTFVn?=
=?utf-8?B?ZFV5eDcwcWh2Y1VxRDZqc0ROZDEzWEJNWUREc3hSME5PMkdDRjVHdzdjZGRl?=
=?utf-8?B?Rk1TNGFhbm1BZGloK1FNbld3RUFBcHNjTjFEeXZhZithb1NxTlpxK1hCUTJR?=
=?utf-8?B?YUR3OXh6MHFjazZCZURoRzljNjliajBzQnpDL0NydFpVR2l4aS9VUmZGNEg4?=
=?utf-8?B?b3I0b1hWS3lSL0RYYUlVMHZHMERNbGl0VFNiVHhSSjFqVmtOMS9pbDI4TlpP?=
=?utf-8?B?YTJpQ2tlQVAxSlFGV2diYjVPQW5JK2JrNFlCQWQxa0VwMVZWOWtZT000TzBx?=
=?utf-8?B?YkYra0RiZndsTVVodWQyTjBrVFBxVUkwd016bVlUYzkxQ29RSW9mV3pTdDRX?=
=?utf-8?B?WVVnczJWRE96OU1XVW9tVzdVYTNuRDk4Tjc4eCt2emdVT2k0bkdzL3pwZisz?=
=?utf-8?B?MUhTeWdqYStqTERPaU1zaVI3ZXNLZEJHd05PSGtzZzllYnFqS2Z3QU5sMnBl?=
=?utf-8?B?ZEorSnpTbzVqaWVxSWM0bkQxSWRza1hvVWtuM04vUHlXNk81Szl4cFY3Y3lj?=
=?utf-8?B?RlhVNm9PNDZYSE5PMzJzMS96QXFKeXhrR3hNS3ltMHhIMi90eG9FTUVZUG5T?=
=?utf-8?B?VUNWRTVudlFZakJGOXRhdzIwYmw0ejVkTjN3NyttYS9Bc0hDMW5QU2x6VGQ3?=
=?utf-8?B?Zlc2TGtJdmVGK3VPYmJtc3N2Y2VXS3dFekJCd3hhK0JQQ05jS2hoL28vYU5i?=
=?utf-8?B?dVp6MUw1L3dwRDdQSlJmT3F2YzJ2STZZc05PaFNRYWV0WHEwOWNVSkRVWGdJ?=
=?utf-8?B?SmNERHhkdzlQQVZWQkVTaitYZmYzRFVkeE15ZWJOQWkyeHNSSDhCZGNCbHJr?=
=?utf-8?B?QmxhMHJVUnM2Tkx1bWtOWFBlcDdWMkYvTXZVTFZBZ2I0S0RPdlppSXlUR1d3?=
=?utf-8?B?VkFZZ2dVblk3cENHSFlMc21aWmEwSWJTTzZwbVFwS09yWEMwV3U2N1kxY3gv?=
=?utf-8?B?WFc4czJuT0hzaWswMWpTRkVWRFl5b01ZYUJOQTJvUDJOa1FPemsreXk2Zm5O?=
=?utf-8?B?aFJIQm5aVk1BPT0=?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB8658.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(921020)(7053199007);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?utf-8?B?OFFLTUJhT0ZBbWhyV1UwWHRPWTZMY0RIb0IveWlPR2hKWmxINDNtbCtoZk9t?=
=?utf-8?B?Wm91c280bTdtL2M2bnNtc1JhRURxd3FpSDVPU2ZuMUJPM254QlJxOUIwSEVj?=
=?utf-8?B?amlIRDhPWHlRUTJQSnRkOWZac2FqS3VXNGJuUE1tcXRHejk3MlUwUSttL1ZP?=
=?utf-8?B?a2FPbG9CZTRLaDFLUXNDN2FBNWk1UXdkbWZRUEdYenFYSnA1c0VQNkNTbllX?=
=?utf-8?B?SktldDdFeGc1QVdzeXA0TzZ6clI3L1VXSGpZdjZQVHdJTHpUQjNKMUhsRVRo?=
=?utf-8?B?SE54V0twRzRSOFJ1Z1VpVlYxdDI2L0FOcVFvMXVHbTlhK081MlVRenZkNFYy?=
=?utf-8?B?MHVuNWhzdzVPN0YrVERBMlFZUDErN2xoaGEzcGh3Uko5UGc0RUMreW1uN0F3?=
=?utf-8?B?MFdjR25adUt0R2U2OTJrM3ZtSVpNSzRTMWJCTzliazFtT0V0KzNXOWZkRHlz?=
=?utf-8?B?WTNjUlNqT2lsRGVwcEg5Q29MVDcxY3R4bFg3cG1ZZnI3VGNmeUI1WHd4Nk5F?=
=?utf-8?B?YWY0bWY3RndYMmw3SDFtbTJlbURhWU1aOEQ3eWpqM2VMVVExMEh1RmlHT0JH?=
=?utf-8?B?QlU3ekFhaHpxNm5RTkJmdDZVY1pUNTJDb3dZUkRvdkhpYnZzd0lmRE9Tc1ph?=
=?utf-8?B?VTJyUnE5YlcwTmVQM1l1L0NzUFU3aGd6R3N3Y1RiSGxKL0djVzVvT29pdVF5?=
=?utf-8?B?aFA1RldBMmdBUWg2MmVkdDN3aG0vN2Zzc1hMeWxJUlhWLzdCNlZGTTdmZWh0?=
=?utf-8?B?WnF4MmFXS0NyOUhtUWl1SUVySEdVWEZtZHUvOFcvMk9wSDV2UE9YYlJGWDFk?=
=?utf-8?B?Y29kaUtYVnlUSmd1NEF4KzZvbExRWU4ycUVDZXdMeWIvUTVKNE5QcXRwSUYv?=
=?utf-8?B?Z1hhTHV1eTB2Z0hHVlk4clgwYkwzR3RJL2xkdE1GQ1NMdTF1T011OTR2ekJT?=
=?utf-8?B?K0U3MEQwNWhIc0ZRdHhJT2dwMC9SdlpaV21zakpDU3lScmZJWWJYYTgwYWxY?=
=?utf-8?B?RmJXeHhHNXJCVWtyWW12UWswWW45VTVQSkRQTTBZV3ptTXlmMnc1SHNYOURv?=
=?utf-8?B?MjJrekFOT2pKSlZPK0h5d3F5Unh1aERrc1RIZzFzSVpDeWtTaGJxVGV4d2Ji?=
=?utf-8?B?MDVPbTVNTE5TUUFMSHlpaWtJdTdMMlRPQnNJMXA5VGJZVUlxRExCZmhCZGFU?=
=?utf-8?B?TDVVZncyWGlzVXlkbDJ4VUNMSUpBMTMva1BMTEdTOEgraWRLQ1lLcWpMb052?=
=?utf-8?B?MnNkUFRiU1BHOEoxU2FCendTMDFOcWVaemF5U2RoYjMwMThhUnZ1QjBIdUdC?=
=?utf-8?B?NE1yOHUzL2loVUpoN24zMjJyeDRwR0xWTisxaERrZHczak5Ja01lckRlUnFt?=
=?utf-8?B?Skh3OFM5ODRURWI4YlcvOXJjZy9oRjdFR1dxNmY3OHJSa05wUWhsRHJPQTZ6?=
=?utf-8?B?RXFRSHYzNGV6bW8vbFlaQlArS1pFenJUdWc4QmhlSllmdU50R2QvVDE2Mnl3?=
=?utf-8?B?RzR6ZDhLNXl6dXdkbWNGME9Sb0wvWE83LzlVRmRtRC85b1FQY2VKK29mWGFa?=
=?utf-8?B?SXQwSjNrZmVEbVpIS3F1T0pmYWNDbmJoNGUrQmZSbm5sMjEwU0crN24wQzBK?=
=?utf-8?B?TGxQWktGVTlOQURpdEh0Um5iWWJvUi9Ud2tYVEVmanc3KzJaVVhqMFBxTS9Q?=
=?utf-8?B?QW1RYlBvbk1lV1pzMEY2UHhnSlRrUUk3cklYNjBnUlFEZXNzUExwRXYwNGdB?=
=?utf-8?B?cy93QWYrdlBzd3VBZWJkUXBMcGhtS3d3c3kzYlRpZDVldytXNllMRkM3dngv?=
=?utf-8?B?bE5Hb0l5V3Q3S0pyLzNENnBqUkEyemlqLytUdjRDbWVYazQ2RlJlRmRYdlFi?=
=?utf-8?B?clFPMkNSbHNKbTVYNWZ0eTFkQ2htZEw5L1lmTURsNzhOVlJJMUdoT1pVcjB0?=
=?utf-8?B?cUFhTWtoUGcwY0FPZEQxT3F1ZWVCNnE5bHl6eXdQbHdtd2M3Ukx3YW9mNGZH?=
=?utf-8?B?d0tQU3RhZ3AycDRMRWp0cmFwK1JXWFpZUlhJSURBM0pEQTV2Q2JoKzRqYTdZ?=
=?utf-8?B?ZVdEM09yOVhHNnlaVEx4MjNkK0ZMM1pSdnRUVVNia0cyaW0vSVlLMVNia1dO?=
=?utf-8?Q?vH5FtqQfxQ9V8Ov0mSYkhqVy6?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 56852ec3-8af5-467f-d3cf-08dd9f564e76
X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8658.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:45:19.2735
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: N6n2535z9vp3dMWkFTucuYD+obMnbYTuQ9MZFLHZeIIwDp6qO9dfg2n0euE1pQuMpyqqdvIwY5EZpIJrUzT/2w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9131
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hello Sean,
On 5/23/2025 5:22 AM, Sean Christopherson wrote:
> Add a waitqueue helper to add a priority waiter that requires exclusive
> wakeups, i.e. that requires that it be the _only_ priority waiter. The
> API will be used by KVM to ensure that at most one of KVM's irqfds is
> bound to a single eventfd (across the entire kernel).
>
> Open code the helper instead of using __add_wait_queue() so that the
> common path doesn't need to "handle" impossible failures.
>
> Cc: K Prateek Nayak <kprateek.nayak@xxxxxxx>
Feel free to include:
Reviewed-by: K Prateek Nayak <kprateek.nayak@xxxxxxx>
--
Thanks and Regards,
Prateek
> Signed-off-by: Sean Christopherson <seanjc@xxxxxxxxxx>
> ---
> include/linux/wait.h | 2 ++
> kernel/sched/wait.c | 18 ++++++++++++++++++
> 2 files changed, 20 insertions(+)
> [..snip..]
Return-Path: <linux-kernel+bounces-667802-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 3A5E541E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:45:47 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 95B461BA6AB1
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:46:00 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 685CC21ADA2;
Fri, 30 May 2025 08:45:33 +0000 (UTC)
Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7])
(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 97F5120E6E3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:45:31 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594733; cv=none; b=PzEPxWnxVbYzpNIxZfBcDIuYMFn3mNLBnuUrfXuuFfXXIts/3+dFKF7LVbCm4+mFOnWZskv4hv/5qG5cAkFwnKQJM2wM2Cbdb3sDGZsyfd0qo7B10Ev1g5z1Zz6+6bJ4gJm0uU8AcN6fICXNunXP+QgO1HQuYmQNw9ng2lcziiE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594733; c=relaxed/simple;
bh=JhBOgQKJ+gaH4GCJNHE7uDE6a7wv2txMpliHbTgHazs=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=aWI/sIDto31oq135F//LvcoeJVVJUx/JCVLhiY2UB3oQ+gsipgee2UvTz9ydKUQRVkxO+PM52COpfG3Dc5c223ShgZrR2xo4Wb6RcW2x6sjLbTln0GA+e0hwSgJULAHUK1i19iRnqi73niqfGCMy8TW//tgGiZzJhvBdWIIFP1U=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de
Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2])
by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKvMb-0006SK-Jl; Fri, 30 May 2025 10:45:17 +0200
Received: from pty.whiteo.stw.pengutronix.de ([2a0a:edc0:2:b01:1d::c5])
by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKvMa-000wrU-2X;
Fri, 30 May 2025 10:45:16 +0200
Received: from mfe by pty.whiteo.stw.pengutronix.de with local (Exim 4.96)
(envelope-from <mfe@xxxxxxxxxxxxxx>)
id 1uKvMa-000ooT-26;
Fri, 30 May 2025 10:45:16 +0200
Date: Fri, 30 May 2025 10:45:16 +0200
From: Marco Felsch <m.felsch@xxxxxxxxxxxxxx>
To: Krzysztof Kozlowski <krzk@xxxxxxxxxx>
Cc: Luis Chamberlain <mcgrof@xxxxxxxxxx>,
Russ Weight <russ.weight@xxxxxxxxx>,
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>,
"Rafael J. Wysocki" <rafael@xxxxxxxxxx>,
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>,
Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>,
Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>,
Kamel Bouhara <kamel.bouhara@xxxxxxxxxxx>,
Marco Felsch <kernel@xxxxxxxxxxxxxx>,
Henrik Rydberg <rydberg@xxxxxxxxxxx>,
Danilo Krummrich <dakr@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
devicetree@xxxxxxxxxxxxxxx, linux-input@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v2 3/4] dt-bindings: input: Add TouchNetix axiom
touchscreen
Message-ID: <20250530084516.ee2kre7kmdd6uikv@xxxxxxxxxxxxxx>
References: <20250529-v6-10-topic-touchscreen-axiom-v2-0-a5edb105a600@xxxxxxxxxxxxxx>
<20250529-v6-10-topic-touchscreen-axiom-v2-3-a5edb105a600@xxxxxxxxxxxxxx>
<119eba0a-2c81-4232-8b20-acc0a0eea969@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <119eba0a-2c81-4232-8b20-acc0a0eea969@xxxxxxxxxx>
X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2
X-SA-Exim-Mail-From: mfe@xxxxxxxxxxxxxx
X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false
X-PTX-Original-Recipient: linux-kernel@xxxxxxxxxxxxxxx
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 25-05-29, Krzysztof Kozlowski wrote:
> On 29/05/2025 00:08, Marco Felsch wrote:
> > +maintainers:
> > + - Marco Felsch <kernel@xxxxxxxxxxxxxx>
> > +
> > +allOf:
> > + - $ref: /schemas/input/touchscreen/touchscreen.yaml#
> > + - $ref: /schemas/input/input.yaml#
> > +
> > +properties:
> > + compatible:
> > + const: touchnetix,ax54a
> > +
> > + reg:
> > + enum: [ 0x66, 0x67 ]
>
> Isn't this the same address? You just added the write bit.
No the i2c addresses are always the 7-bit i2c-addresses without the R/W
bit.
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + reset-gpios:
> > + maxItems: 1
> > +
> > + panel: true
>
> So that was the reason of dropping tag?
> https://lore.kernel.org/lkml/821ce1d4-bc15-4764-bbe0-315c57e8536e@xxxxxxxxxx/
>
> Anyway, drop the property. Redundant.
Why is this redundant? The touchscreen.yaml defines it but I need to
request it? At least I understood it that way and all other users of
this property do it same way. Same is true for all the touchscreen-*
properties definied in touchscreen.yaml.
Regards,
Marco
Return-Path: <linux-kernel+bounces-667803-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9769841E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:49:01 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 2E81F7A52C6
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:47:42 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 92F9C21C19F;
Fri, 30 May 2025 08:48:50 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="dBIc9dNc";
dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="kmUaVODS"
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32])
(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 CC6551465B4;
Fri, 30 May 2025 08:48:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.165.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594929; cv=fail; b=u1z1s7NCiE1zyOUsdOowl97Zlw4Kq2Xr2Qn9YTtXtv40wQmVRV+iMCTgQho8Z6QurOcWZOUvuQoRB5QIJqlJ8nNicJTvG9eu4jlnUkkmsMzPBRj5lKYUb8R11gKBLL9fsNt59bq1yhIYxQ7dwpbkT7IBxBx+0phmnlxcgyoos00=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594929; c=relaxed/simple;
bh=CcTHdJzngZudm+8G+EcSor134pCxSA0b5jqeQ6VcOuY=;
h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
Content-Disposition:In-Reply-To:MIME-Version; b=IW9s55aiEi3y+AUhjLXIURX8rR1wNJ0v5cRk+k5O0sUN5DWJcVdWZZzxALWj9gB42nrU2woMFim7s1Ho4c7QWpiKZHqFsG4rzBABAt2/kpTW7E0LYHjGFuSeoMqOhhWnetuEpoZk9DvF/WkcxlYsUdF1YXm+jnPtq01WCgyf46A=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=dBIc9dNc; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=kmUaVODS; arc=fail smtp.client-ip=205.220.165.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U6twgY012746;
Fri, 30 May 2025 08:48:32 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
:content-type:date:from:in-reply-to:message-id:mime-version
:references:subject:to; s=corp-2025-04-25; bh=wzX3rAejxWdXAJt/Gt
lgwESc10+BkW7X9/wJm7J11gc=; b=dBIc9dNcvoI1ylIc1yezzx1Vv5CzFcITaw
a+g3tR5K9XeZB1XmjD0vP5z6/o/iQ5oWOCIhwWSkLeuN6v1Qb+leA9MImCUlgwv3
aeAH2e8Cb0xvZscyoZLXSHhpHQ05svhD9IPTO69mpMWoxYyGzpinPreSJus2IDBc
dyir0aTpfqGH0fjaQVVW/VvYLGtcJRrTEdeuzwtT40SnaLnhzq19jKuA4l5WZxtR
axSCBR39HqO8apaPX/B/kTti/N6LqMQdLofBEZjjh6rU4TIkQbWCKO/xNEbZvk4j
SxsawuE+Ld1pMiqh718vH2Ib3fYrybCkZSKxKodJdk5cTkvj3/Fw==
Received: from iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta01.appoci.oracle.com [130.35.100.223])
by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46v3pd9kwu-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 08:48:31 +0000 (GMT)
Received: from pps.filterd (iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 54U7t532019300;
Fri, 30 May 2025 08:48:30 GMT
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10on2053.outbound.protection.outlook.com [40.107.94.53])
by iadpaimrmta01.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 46u4jd1gxf-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 08:48:30 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=bJJrD1ycHrSXzIYangXUMu8PYU8aswK4yUfmg9NOuPSmwdBBNlUbmbtVdnMXbClAdy72dpp+YtRyStf7gCyGoGRjtgNbdpD+r3i0lgiI3hwlkMKvLBC7AxyUAzLVVmaMbsUYeVImWdcABa+OoDwwhapfHlKLFaGSfuKfx89Mj3x7hL7UFSim3LphO7rKV5wrBEK0d1CPW1zken70Qnynq2Zs77ECWRPF7b+OZ3Y3JuGGoOrixx1TcT1kUFbmA4371ydkaQKAy3MsJf0tgvNaJmqJAM+jQ9lwAElA4K6LaYqKf493/REsKrTjf4ASN4LjoyTBUsQ7nJljn+sGSO4PMw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=wzX3rAejxWdXAJt/GtlgwESc10+BkW7X9/wJm7J11gc=;
b=VTR4rZuDh6FZteCFo6AKgVVL07n/oqtcszg7JH0J9o2kTncp1zEQ2aFEB8vrVljUJgmWMRx55ZaimwqItcodiHu7+p0oFuu0xP6q/Du54kzgx6dJqM64oiaPk6cwra5GkxoXTDZwnDghyZU5HtrEsnrJ3e69vyVjPaENIfISu/cjv8ES2Cc8OzQy/wlVY4ciApsm/1viftZQExTsslvOcmhZP56ZMXCNFIXeagp94VDasq+pdEIMEKBvvMnNyseXiJ2Y6P1qjYHciVqMy6XGqvTDNa6SpI0X0WRPiIKTRRSgjkSV8qqH6GSmGgmbi7tqtO6O/qRmY9Pf/5A4Aua4Lw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=wzX3rAejxWdXAJt/GtlgwESc10+BkW7X9/wJm7J11gc=;
b=kmUaVODSlprVMYd/xKGtXM3tLv7qHh0SYXEmbRhnnSHTrIGNZ94UqB8yqOu+T/FQLkCAlY5Cuap7nopKRdvU/dMNSJuUytF5nSxHDOIIrQhsp1qvVm0tks5NLS6pcxmWfYSiOy+2XsZlucCLytpp/5FKjxX8Sj+lq3w/KFU9uAE=
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
by LV3PR10MB8155.namprd10.prod.outlook.com (2603:10b6:408:28f::9) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.31; Fri, 30 May
2025 08:48:01 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.8746.030; Fri, 30 May 2025
08:48:01 +0000
Date: Fri, 30 May 2025 09:47:58 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
To: David Hildenbrand <david@xxxxxxxxxx>
Cc: Ryan Roberts <ryan.roberts@xxxxxxx>,
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
Message-ID: <ade3bdb7-7103-4ecd-bce2-7768a0d729ef@lucifer.local>
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
<f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
X-ClientProxiedBy: LO2P123CA0087.GBRP123.PROD.OUTLOOK.COM
(2603:10a6:600:138::20) To DM4PR10MB8218.namprd10.prod.outlook.com
(2603:10b6:8:1cc::16)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|LV3PR10MB8155:EE_
X-MS-Office365-Filtering-Correlation-Id: a15a77ae-bc3c-4ef3-9db9-08dd9f56af1f
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?hqQpWQACXFwLXAbxGumElFmwmrcanZ2v3SmXo4xhdpHYCnUqv1REsnxCptgy?=
=?us-ascii?Q?2DUadV41eV+rrdJWu5sFYUs2VfQpsgN1Q6WNn8vtLUt/P4ftAVyk4YSt41gU?=
=?us-ascii?Q?mfNhiFDZqx5h1TKffkCjZ4Z7uz6SNB1gTN6u4xwCOJbpr0f17b5RdI3SOt8I?=
=?us-ascii?Q?A8cMkBNm+fZbpGJaWUciJM6NQJs0ZstajRz4q8GdK3YbCy8FxQYRrJXgUjfI?=
=?us-ascii?Q?JBiZcmXKygO6BGv42GG3GAmgZqaVlzG7U1MgcWK06gKoZbIbYlAw6OMk879h?=
=?us-ascii?Q?eVjz6aw0CtfMDH7bv07rDv7DUKcXmwgJ/F+pfcnBcxilwQHzKqv5siNdJqoN?=
=?us-ascii?Q?VdaIVWcrVj6pMTrG2fIISCGjA4OeU96n7bSHbKeAqY1ulcalPuxe/PRR0SMZ?=
=?us-ascii?Q?lQtoTqA8OhStKsWa0nAg+XVUuzPVQbjt0wdcXQREcLUChCRU8tWsONrYLF/P?=
=?us-ascii?Q?pA8HaVZG/Ww8ot6g4jIRt55Pnvh5HNi11GmsNnGFwGYkNPUqiR+zww3Y7/QS?=
=?us-ascii?Q?o//KGNiKcBiFsKPef0b/8aSQhZqQtFm2XORjV755mW4aCKp01H5MpC1YuhCn?=
=?us-ascii?Q?YumIyszNO/krf3R0bhLJz8mMOsv+6v+zbw2XKusqdjZ13QI75Od5XnyJlYsP?=
=?us-ascii?Q?Al8akU2R7G1AR+iO2o9EAUAT8i4oRLOP68wtTR/t4smManryAD053nvszvw0?=
=?us-ascii?Q?FSSlV9t52kHGRrYsF9ksc08w3zKQO73+7KXHLhWwAa8DgPwzttwE6bgn4yoz?=
=?us-ascii?Q?1hWdlHTiINpf3TKGS/SFQXVahXaOLiu/iZCViL2/l+5tOh1/HcWoiZPoj1C2?=
=?us-ascii?Q?eTbU91StQ+laYwaaX8ZCk8zW3HRlmZ5rNk/Zc2t4KndCSfDCzhon4FCKhZHj?=
=?us-ascii?Q?dl8qHcsGh8+SD10xraqYgfERi1j3DbWPlCgES+b6Kfi1XulbwhjlUye4T3nn?=
=?us-ascii?Q?aQWS2qGD/RdUD8m+z7JbMnu+eOF5CLFU89YXPmYDmqOCNgJUU+XBTIf+JhvB?=
=?us-ascii?Q?Uqg78iRQxmvMnD0mVhODg+fdFtPsBwBlhmbDcWOEeZEyxnxXM7qD75/BGDG3?=
=?us-ascii?Q?JelWh7FLS0b0Ha+ITeCaXdcxN5c0O1PJvoGaBYdUQWjWT8ad2YhSspgkExF+?=
=?us-ascii?Q?Lnf/RbMFlS+sClGXNrRC8pPq8qGhu95eSPSQS/h9wGO2gNRoduiDl2A9l/4x?=
=?us-ascii?Q?dmfJ0WA09mG2cx+cda5MEydfUpRQwEqbYaDnAN3W5JS9NN9bX75Q684n3tql?=
=?us-ascii?Q?1RhySFBKreEhcIhu08jADPA0m9A98+UDR/dGwiCDvFU666GQ/GT+KhZdjxrj?=
=?us-ascii?Q?3LRHPjMGi2TDhKIi3vpWGGLTJE4Znq9/T/+EsLzjQhcdyfD59hB7vWhNveTr?=
=?us-ascii?Q?LmKON+Gc4npMEtb0S3Oj0kV1DjdBxfD0cS6WEgH7dyRPFu9FKZgmQp202/Yx?=
=?us-ascii?Q?nqLr9YvLKv4=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?us-ascii?Q?VMEULcTzJ2T1z3oUAM9/OGuPELAvPHFANBIGk3nPJb1hpc5ilwIlD4Yv7ILY?=
=?us-ascii?Q?5IBQBEIEiwlKaN/ElI6/48DfztIA7+fluL3H9zynJ+ENGCezDi5XPdoTmp53?=
=?us-ascii?Q?4SiER3mtoPVT2fEQ4+T1MnG4ielgymqraQ103byxfHu4QjrVMfVa7N9VoNlI?=
=?us-ascii?Q?ktEAomg5Qjapivb2cjGzq3j/v+il1jSJrnlhv7jnWJh+MlIElKxUjer5pZ/Y?=
=?us-ascii?Q?T8JovBhBrcJIckTEFszpmxqXJjNF3/9LviY+QRDRJNg2jiDFsumUXcWoLpvD?=
=?us-ascii?Q?zpq/ZVufWFC9ItG09e9ooGka3lGTzKdKJ5mk/qrVyzZT6jE5/XihLr16VJJy?=
=?us-ascii?Q?VmUY1vJ6r3jq1vqoYMQLPAMKdifaIBE9b9+raKWGprtBw2m/sC68gsDEylzA?=
=?us-ascii?Q?ZL+YrW1ZehraEkwzb1Du4/nz8y4Lswm/le8iNZmdoS6bDXJXd67lwNCFOFfS?=
=?us-ascii?Q?sbtA03BFNAUA518a10qjQv6b9/E6xetWdL5uc10bfAOlBONi8meGicOwPKVI?=
=?us-ascii?Q?NlFk9xG3ntyTpuI9VQHA3/fFFf5TRGPe8Iy1wOjAlEyUr210/LpQIVTPPk5R?=
=?us-ascii?Q?7pOiqLcvSLsue1W7i6NErFrrNiNWg1Cd+uyONYVtkI3EN9NuJ4zzCWQVcVGg?=
=?us-ascii?Q?VVs5lDgcGzcX9BdrhYUEDGuT2IP5DEc+lquuCSQcPVX1g+kdJtbloOO14Pu7?=
=?us-ascii?Q?tjl0So/uXGU9Pbj5nBeN+loORzBz92SMiiLBS9ltS773FOxR7qoEPDWGvtTe?=
=?us-ascii?Q?AaN8erPLxVLvilUl5fZ4NKrhps2Xpw9F1GDb+tWIlHP/p+0Nj3/Hj/OOdDTJ?=
=?us-ascii?Q?h7btH5R1xUAiEj49OW3RUcuOA7u2B5jFSjSi8Qy2684z1J9iDUY/4a7iFgkA?=
=?us-ascii?Q?ldvuyI/i+j8FlILx/3MYBEO+gqxJjNwSsSXHwB4hMGpbK20NMCBoGfDjvKbL?=
=?us-ascii?Q?cqqnaZGs5diW5xVQ5pSBzmrBrWPOPQWPYNmGVIOtMU10yJ4poxAdlpzcFen0?=
=?us-ascii?Q?lKlIt72+8jRyix1siu8vfNQhqY/qvBtc8PoxtVwLKtS0RHUluyoowC+eCfCo?=
=?us-ascii?Q?T0sCZN1U9kJGXwrf4oRmL/UIr0/9/0tmdtwHmEzcm0adfdCf2e9YGiQq++VJ?=
=?us-ascii?Q?hnMpylra4AlmBtGR5VZ0Y/Q+pn2ZHMsCd/S5LQ45Co99gZGICqpHDKktYv9S?=
=?us-ascii?Q?TX0+HhAaWtT8i8Kg0uCkXsapc2k3nJ+hBnJ/jAbZzo1PUv58SGAXJat2fHmH?=
=?us-ascii?Q?CadnBwasXwLGuhucA/JWC9UrucVw5IrwpQn+GJq3OOxpaOk4icaJGXVHunpY?=
=?us-ascii?Q?wMAP2Wn6p8nf3en4ZiM1Z1NNv0x05XyIhpH3r9Cg7PWHWFeZyn5TU3u4h1Fc?=
=?us-ascii?Q?2Aax7hs3CsqmizrEyNiiC5rUdM6k74N8azAa8PohPnsDUQ7zOqrdrDg6PP4N?=
=?us-ascii?Q?90UYvLAhW9ZgiE0CCV+79k/8dq7zL63Fwe6SeWszlfZ+6c3D0O4FTFopjgCC?=
=?us-ascii?Q?tuYmvFjhH/x8e5mfBE/QHVqQYanEIz8ZUsDG/O1TeLsc1/Cw4BA13/tFwMhh?=
=?us-ascii?Q?eujPQVtVpXnf5vc1VtMxRcCRYax5qID9LSMyuQVkrYO6/YQywAlyBkb+dReo?=
=?us-ascii?Q?ag=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
q0tYpU3IMKRhr0/Cf+TvOdc5YmBp/QxnMi13YCzTPepcsp2RIaBtN61PzNXZa5VbLWNEhY+PdPStNRwn2hF18Pv15tunabBIzTY4DstQBSR2t4x9HHtvlD1u/jCX6RLrr/jiaC4QAQPHO4FCvk6x4zFQDQ70+YlVlc/rEuogBwv/CY9ZtoKAhVgHEvP8irBhaTExyhCxNWmMClXmZDHN21+JkreqwbHsY/pXETa8+KeeM8X7pCtQ3Eu2pBBKgqOkFldFVmH4K2VdyBGIFuAUj+kcyckzIKQrxw0f03hpy2uYoVNMzi1iaviTehSMlI2LviCtsBbocuVlZPgYrlqTrTPXLlp+YBgREa7NrKhc1DJJFiL9rhDFtI+a6yQa04i9O+Zu7K/Dt4wB7/+q6KMQhCj4IFF7yPIHjdVZgzRN5yHGcIZGrFSorTH69xV1oUO29tFW17vLxjsWKu8Mim3YjGXvx83bbbIJwOLE3ScUfVJUCQgepqj7Pq+ZlgyUE0eDLbcyoMF1Ez+YCOfQSQ1lPA//Lxryr+vB+7o35X4ng0Zh5MlawvsZC1c+GDFUE3ij1PbRN33OqPNH6BlMc9UrXEEvPb0Gq3SxPxwyU1ItUBM=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a15a77ae-bc3c-4ef3-9db9-08dd9f56af1f
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:48:01.1293
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: VFJSZQEik3xvcjwBHikipqiZD+Tbi/dBmGanHQgdu/YzZQ9eNNDyJmDPtKoh4437rnTqwbgExjUgXQIy1bcLgh7242WbhglL2HFvb5jhdcs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV3PR10MB8155
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_03,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 spamscore=0
suspectscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 mlxscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
definitions=main-2505300074
X-Proofpoint-ORIG-GUID: B6tmW15nf-H9HYPOYQQugNxxAc3B93xC
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA3NCBTYWx0ZWRfX6Ssq+DhRwHvx SjgkVr6NE1pFunCmbWkUfwUOrbzJPa6B0C5mvUzUgX6fysowl/xW5ikMrnSOseehnBb9mAPKZkY qcSzVFzZPRyYkAA+mMl5RYy9HWMAn4XrSKtTa6dJi/EE2I9vwFx7cSR6AhpQvbk91SO6Gya4in2
2Ogjtg/gZcWyFzocpHMHaAhhNaChabQSM87MMdGwcLriRIm4SHocKOCaxmSfzULFHS1Ep1DnDsi XxvtCEf87Dp+e5IL40m9sHB3P+SL+FE9wkN05vgxGridNTdqqIeTsSMUWOHbi9u4uZV8sYh1rkD 5xFjJSn4BtUZAYVbyu0M/YHyDJphr83P+PnWSZ3a5wABoGzVE2T5u23tNPs0rEqMW5bfUhTarOf
Mb/qqWDYxKH6wLQzrhAZXFX8LY9F6LwQFoXHTekI8SghtpJ7WtcmYRzKGuy0JZcND7N9PVAU
X-Authority-Analysis: v=2.4 cv=UZNRSLSN c=1 sm=1 tr=0 ts=683970df b=1 cx=c_pps a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=CFYDfzxikTNwhxn6LM8A:9 a=CjuIK1q_8ugA:10 cc=ntf awl=host:13206
X-Proofpoint-GUID: B6tmW15nf-H9HYPOYQQugNxxAc3B93xC
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 10:44:36AM +0200, David Hildenbrand wrote:
> On 30.05.25 10:04, Ryan Roberts wrote:
> > On 29/05/2025 09:23, Baolin Wang wrote:
> > > As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
> > > the system-wide anon/shmem THP sysfs settings, which means that even though
> > > we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
> > > attempt to collapse into a anon/shmem THP. This violates the rule we have
> > > agreed upon: never means never. This patch set will address this issue.
> >
> > This is a drive-by comment from me without having the previous context, but...
> >
> > Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
> > user-initiated, synchonous request to use huge pages for a range of memory.
> > There is nothing *transparent* about it, it just happens to be implemented using
> > the same logic that THP uses.
> >
> > I always thought this was a deliberate design decision.
>
> If the admin said "never", then why should a user be able to overwrite that?
>
> The design decision I recall is that if VM_NOHUGEPAGE is set, we'll ignore
> that. Because that was set by the app itself (MADV_NOHUEPAGE).
>
I'm with David on this one.
I think it's principal of least surprise - to me 'never' is pretty
emphatic, and keep in mind the other choices are 'always' and... 'madvise'
:) which explicitly is 'hey only do this if madvise tells you to'.
I'd be rather surprised if I hadn't set madvise and a user uses madvise to
in some fashion override the never.
I mean I think we all agree this interface is to use a technical term -
crap - and we need something a lot more fine-grained and smart, but I think
given the situation we're in we should make it at least as least surprising
as possible.
> --
> Cheers,
>
> David / dhildenb
>
Return-Path: <linux-kernel+bounces-667804-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id D9BFE41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:49:32 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id B45CFA22DB2
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:49:11 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id A70FA21B199;
Fri, 30 May 2025 08:49:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="O8lt1ubD"
Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178])
(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 940401465B4
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:49:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.178
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594966; cv=none; b=IM4wOYHA6Twkca8Gtdhahw9hdNLi1Uap0lqoHi47XhxZQK4xlbpfYjRxX37C0eDGLrBQ7DVwdj0D3u0YJ7HeccSPypcWR+zt3Ei+gQ8StyhTXZXirs/2icmXrVOoaJixDLLuBRcT6PmzjcxnM/tRXWNEC40fUJie9Pl77oEdG6s=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594966; c=relaxed/simple;
bh=ucBbvM/c14wBbCHaDiYuMaPpRPHVVsNj1AuM5Oh2SlM=;
h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
To:Cc:Content-Type; b=HaAWf8aEO/q9NFRuM7V+XvK3tziA1MkOaghOSZum/3yQ+yrJ6vuKP54VjYIVw3eXccVIBynbdh0iMYjQjLWoD1t58w3A1MmuRMCaiPhCt5ImtkyEqH1JbGzUKucMfNNj3UCjtvDi+UCqPBn057U+i/ss4GRhr/OTB4T1PShdC7s=
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=O8lt1ubD; arc=none smtp.client-ip=209.85.208.178
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-lj1-f178.google.com with SMTP id 38308e7fff4ca-3105ef2a071so20853691fa.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:49:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1748594961; x=1749199761; 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=0bMp2GwF28M9nCY+1eTbEjES5I4QV1m653ObPpjGH6k=;
b=O8lt1ubD25zSY8rO9b2tZ5I6NbgupwUJlrqSMmCDy6vsF7PwyQ0tWO/yoKrhrwSf00
nqQlUHKniqN0mow2dL70fSWzwVJwxOJAwCiycmH/ldfZwtKaRgB8Ay+xHzuMRrIWrjfu
Wj7uS+U70rqcbouSVIsOO7dhdMp5O+uOfsGIbThp/HHbcBAp0TRX6aRFbE6n2W5cbtAn
tcr+8ehvMBdoYjSX1Dk9gSYh27WSfCpJtHyh+l4EWk2JK4YdnqkZ6JsywlSsmAwCHzzw
CejRxvB7qoM3GBbQ9PHWhOggnpc3vCOjNjG4vxpvjcTi56tMEOcJyJARo9BEpTRHevp0
1I+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748594961; x=1749199761;
h=content-transfer-encoding:cc:to:subject:message-id:date:from
:in-reply-to:references:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=0bMp2GwF28M9nCY+1eTbEjES5I4QV1m653ObPpjGH6k=;
b=cF4oAls2TITTsCc3ktakjDmnn00/MPyE8QyV+UwPFB6RUO6QAf8gEN0b5rm5CWzKtH
iFTGXIK5TUqdslVISCNhHtDKbEU5R1lvcY7W8w+FfuuRc+kiw7AOyb7qoFkZdY0dUPna
YyIhXxf5OLrx7XgZD0kDYIu4XyIyGuX7gTmaYhWn25KN6nJOQmmhu+avHofnF1QrJZZB
OuOrJXzYMQ/P+IKNVv/DKo9wvoUFIVCQY/rgHGor/gw54C5Rw2Sviwt2aAFytmZ1HQUn
9/dvtukSRYpLQssXYpbp8YsZYw/BHDitG5DDO1KHxpeWsahjyWyyVGSiIhfzBOWgZcEz
j/Sg==
X-Forwarded-Encrypted: i=1; AJvYcCU4OPiehntmMEYXgTjWhSlQO6kuH4O/aCIXtzReG0FLk8a3Dpq9QvnYHLTfJeog6UeclmPUH2/mfXdd1QU=@vger.kernel.org
X-Gm-Message-State: AOJu0Ywt1jFGjr0TJsErC7jyBtRa8MW7E8EStB3pReR0ct25SE8qnOCJ
vMjm5vizlNQDwjjhmUrtk2gM2heGD56MGqELx2BjaMDJzC0PHgxOfEkHofVRwFL826pgUjY1ecE
sG7ybzp13EMk+EI/DYyjCTEloMoVxbtM=
X-Gm-Gg: ASbGnctyggUh8qtRiQ7bU+uAuVJnzTah2PFR/9lryfszoc8oUwR++2rOzfEqxFcf9VU
L1EjeMwjGEDwLL295D1tLsazNDYo2kNs27UYPak1HrnF/GG5v5CXUn9ncwloUjPGsZ8HfRNPgdE
Eus+iLQ9Nw0gb45mjI3E/FN+C3OOA8O0Ej
X-Google-Smtp-Source: AGHT+IHMUXxJ5vi0k1dwPqrpUyBi/SiUwVU9oHPtwN20lM6itfJnJo4i1TQfWd7HOIDyiJ+JF7GIMuHU7woIp38mUlo=
X-Received: by 2002:a05:651c:b09:b0:32a:62a2:f72b with SMTP id
38308e7fff4ca-32a906cf1f8mr3745591fa.14.1748594960833; Fri, 30 May 2025
01:49:20 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
References: <20250514201729.48420-6-ryncsn@xxxxxxxxx> <20250519043847.1806-1-21cnbao@xxxxxxxxx>
<CAMgjq7BpfueOn9ms8apRX-6dF8rZGtbC=MuZzSD7hbZxtw=Kdg@xxxxxxxxxxxxxx>
<CAGsJ_4wC5_YSMLNoY5q4hUsZTpD+YPHSBtzCAdWRFH65EJA_iw@xxxxxxxxxxxxxx>
<CAMgjq7AO__8TFE8ibwQswWmmf4tTGg2NBEJp0aEn32vN+Dy8uw@xxxxxxxxxxxxxx>
<CAGsJ_4z1cJfOCcpZDt4EuHK7+SON1r0ptRJNv1h=cDv+eOcdSQ@xxxxxxxxxxxxxx>
<CAMgjq7CJ4_9bB=46TVzByFRuOwxNs4da=sN==x8cc++YsV+ETQ@xxxxxxxxxxxxxx>
<CAGsJ_4wo6u1WSXdzj8RUUDNdk5_YCfLV_mcJtvhiv2UonXw+nw@xxxxxxxxxxxxxx>
<CAMgjq7Bc0-eXZ8G=bN8bo2NG1ndtPmCUvxCi0bdM+HdqmOjaPQ@xxxxxxxxxxxxxx>
<CAGsJ_4ymRwXhQdzabstHhkK0OM0JEWtvR3tjeyQppm7sKZ8FUw@xxxxxxxxxxxxxx> <CAMgjq7B1K=6OOrK2OUZ0-tqCzi+EJt+2_K97TPGoSt=9+JwP7Q@xxxxxxxxxxxxxx>
In-Reply-To: <CAMgjq7B1K=6OOrK2OUZ0-tqCzi+EJt+2_K97TPGoSt=9+JwP7Q@xxxxxxxxxxxxxx>
From: Kairui Song <ryncsn@xxxxxxxxx>
Date: Fri, 30 May 2025 16:49:02 +0800
X-Gm-Features: AX0GCFundRkueUSS1m8MxSja_2c1kn5vAhBJf6EhcMcXxkYjJcXnH5ar5KUJuQQ
Message-ID: <CAMgjq7CTbSeNq7HEzZP6raK_6ngC6HAzt46ZSBu0f2RQftZUBQ@xxxxxxxxxxxxxx>
Subject: Re: [PATCH 05/28] mm, swap: sanitize swap cache lookup convention
To: Barry Song <21cnbao@xxxxxxxxx>
Cc: akpm@xxxxxxxxxxxxxxxxxxxx, Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>,
Baoquan He <bhe@xxxxxxxxxx>, Chris Li <chrisl@xxxxxxxxxx>, David Hildenbrand <david@xxxxxxxxxx>,
Johannes Weiner <hannes@xxxxxxxxxxx>, Hugh Dickins <hughd@xxxxxxxxxx>,
Kalesh Singh <kaleshsingh@xxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>,
linux-mm <linux-mm@xxxxxxxxx>, Nhat Pham <nphamcs@xxxxxxxxx>,
Ryan Roberts <ryan.roberts@xxxxxxx>, Kemeng Shi <shikemeng@xxxxxxxxxxxxxxx>,
Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, Matthew Wilcox <willy@xxxxxxxxxxxxx>,
"Huang, Ying" <ying.huang@xxxxxxxxxxxxxxxxx>, Yosry Ahmed <yosryahmed@xxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED,
DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SORTED_RECIPS,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no
version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Tue, May 27, 2025 at 11:11=E2=80=AFPM Kairui Song <ryncsn@xxxxxxxxx> wro=
te:
>
> On Tue, May 27, 2025 at 3:59=E2=80=AFPM Barry Song <21cnbao@xxxxxxxxx> wr=
ote:
> >
> > On Sat, May 24, 2025 at 8:01=E2=80=AFAM Kairui Song <ryncsn@xxxxxxxxx> =
wrote:
> > >
> > > On Fri, May 23, 2025 at 10:30=E2=80=AFAM Barry Song <21cnbao@xxxxxxxx=
m> wrote:
> > > >
> > > > On Wed, May 21, 2025 at 2:45=E2=80=AFPM Kairui Song <ryncsn@gmail.c=
om> wrote:
> > > > >
> > > > > Barry Song <21cnbao@xxxxxxxxx> =E4=BA=8E 2025=E5=B9=B45=E6=9C=882=
1=E6=97=A5=E5=91=A8=E4=B8=89 06:33=E5=86=99=E9=81=93=EF=BC=9A
> > > > > > Let me run test case [1] to check whether this ever happens. I =
guess I need to
> > > > > > hack kernel a bit to always add folio to swapcache even for SYN=
C IO.
> > > > >
> > > > > That will cause quite a performance regression I think. Good thin=
g is,
> > > > > that's exactly the problem this series is solving by dropping the=
SYNC
> > > > > IO swapin path and never bypassing the swap cache, while improvin=
g the
> > > > > performance, eliminating things like this. One more reason to jus=
tify
> > > > > the approach :)
> > >
> > > Hi Barry,
> > >
> > > >
> > > > I attempted to reproduce the scenario where a folio is added to the=
swapcache
> > > > after filemap_get_folio() returns NULL but before move_swap_pte()
> > > > moves the swap PTE
> > > > using non-synchronized I/O. Technically, this seems possible; howev=
er,
> > > > I was unable
> > > > to reproduce it, likely because the time window between swapin_read=
ahead and
> > > > taking the page table lock within do_swap_page() is too short.
> > >
> > > Thank you so much for trying this!
> > >
> > > I have been trying to reproduce it too, and so far I didn't observe
> > > any crash or warn. I added following debug code:
> > >
> > > static __always_inline
> > > bool validate_dst_vma(struct vm_area_struct *dst_vma, unsigned long =
dst_end)
> > > @@ -1163,6 +1167,7 @@ static int move_pages_pte(struct mm_struct *mm,
> > > pmd_t *dst_pmd, pmd_t *src_pmd,
> > > pmd_t dummy_pmdval;
> > > pmd_t dst_pmdval;
> > > struct folio *src_folio =3D NULL;
> > > + struct folio *tmp_folio =3D NULL;
> > > struct anon_vma *src_anon_vma =3D NULL;
> > > struct mmu_notifier_range range;
> > > int err =3D 0;
> > > @@ -1391,6 +1396,15 @@ static int move_pages_pte(struct mm_struct *mm=
,
> > > pmd_t *dst_pmd, pmd_t *src_pmd,
> > > if (!src_folio)
> > > folio =3D filemap_get_folio(swap_address_spac=
e(entry),
> > > swap_cache_index(entry));
> > > + udelay(get_random_u32_below(1000));
> > > + tmp_folio =3D filemap_get_folio(swap_address_space(en=
try),
> > > + swap_cache_index(entry));
> > > + if (!IS_ERR_OR_NULL(tmp_folio)) {
> > > + if (!IS_ERR_OR_NULL(folio) && tmp_folio !=3D =
folio) {
> > > + pr_err("UFFDIO_MOVE: UNSTABLE folio
> > > %lx (%lx) -> %lx (%lx)\n", folio, folio->swap.val, tmp_folio,
> > > tmp_folio->swap.val);
> > > + }
> > > + folio_put(tmp_folio);
> > > + }
> > > if (!IS_ERR_OR_NULL(folio)) {
> > > if (folio_test_large(folio)) {
> > > err =3D -EBUSY;
> > > @@ -1413,6 +1427,8 @@ static int move_pages_pte(struct mm_struct *mm,
> > > pmd_t *dst_pmd, pmd_t *src_pmd,
> > > err =3D move_swap_pte(mm, dst_vma, dst_addr, src_addr=
,
> > > dst_pte, src_pte,
> > > orig_dst_pte, orig_src_pte, dst_pmd, =
dst_pmdval,
> > > dst_ptl, src_ptl, src_folio);
> > > + if (tmp_folio !=3D folio && !err)
> > > + pr_err("UFFDIO_MOVE: UNSTABLE folio passed
> > > check: %lx -> %lx\n", folio, tmp_folio);
> > > }
> > >
> > > And I saw these two prints are getting triggered like this (not a rea=
l
> > > issue though, just help to understand the problem)
> > > ...
> > > [ 3127.632791] UFFDIO_MOVE: UNSTABLE folio fffffdffc334cd00 (0) ->
> > > fffffdffc7ccac80 (51)
> > > [ 3172.033269] UFFDIO_MOVE: UNSTABLE folio fffffdffc343bb40 (0) ->
> > > fffffdffc3435e00 (3b)
> > > [ 3194.425213] UFFDIO_MOVE: UNSTABLE folio fffffdffc7d481c0 (0) ->
> > > fffffdffc34ab8c0 (76)
> > > [ 3194.991318] UFFDIO_MOVE: UNSTABLE folio fffffdffc34f95c0 (0) ->
> > > fffffdffc34ab8c0 (6d)
> > > [ 3203.467212] UFFDIO_MOVE: UNSTABLE folio fffffdffc34b13c0 (0) ->
> > > fffffdffc34eda80 (32)
> > > [ 3206.217820] UFFDIO_MOVE: UNSTABLE folio fffffdffc7d297c0 (0) ->
> > > fffffdffc38cedc0 (b)
> > > [ 3214.913039] UFFDIO_MOVE: UNSTABLE folio passed check: 0 -> fffffdf=
fc34db140
> > > [ 3217.066972] UFFDIO_MOVE: UNSTABLE folio fffffdffc342b5c0 (0) ->
> > > fffffdffc3465cc0 (21)
> > > ...
> > >
> > > The "UFFDIO_MOVE: UNSTABLE folio fffffdffc3435180 (0) ->
> > > fffffdffc3853540 (53)" worries me at first. On first look it seems th=
e
> > > folio is indeed freed completely from the swap cache after the first
> > > lookup, so another swapout can reuse the entry. But as you mentioned
> > > __remove_mapping won't release a folio if the refcount check fails, s=
o
> > > they must be freed by folio_free_swap or __try_to_reclaim_swap, there
> > > are many places that can happen. But these two helpers won't free a
> > > folio from swap cache if its swap count is not zero. And the folio
> > > will either be swapped out (swap count non zero), or mapped (freeing
> > > it is fine, PTE is non_swap, and another swapout will still use the
> > > same folio).
> > >
> > > So after more investigation and dumping the pages, it's actually the
> > > second lookup (tmp_folio) seeing the entry being reused by another
> > > page table entry, after the first folio is swapped back and released.
> > > So the page table check below will always fail just fine.
> > >
> > > But this also proves the first look up can see a completely irrelevan=
t
> > > folio too: If the src folio is swapped out, but got swapped back and
> > > freed, then another folio B shortly got added to swap cache reuse the
> > > src folio's old swap entry, then the folio B got seen by the look up
> > > here and get freed from swap cache, then src folio got swapped out
> > > again also reusing the same entry, then we have a problem as PTE seem=
s
> > > untouched indeed but we grabbed a wrong folio. Seems possible if I'm
> > > not wrong:
> > >
> > > Something like this:
> > > CPU1 CPU2
> > > move_pages_pte
> > > entry =3D pte_to_swp_entry(orig_src_pte);
> > > | Got Swap Entry S1 from src_pte
> > > ...
> > > <swapin src_pte, using folio A>
> >
> > I=E2=80=99m assuming you mean `<swapin src_pte, using folio B>`, since =
I=E2=80=99m not
> > sure where folio B comes from in the statement `<someone else tried to
> > swap out folio B>`.
> >
> > If that assumption is correct, and folio A is still in the swapcache,
> > how could someone swap in folio B without hitting folio A? That would
> > suggest folio A must have been removed from the swapcache earlier=E2=80=
=94right?
> >
> > > <free folio A from swap cache freein=
g S1>
> > > <someone else try swap out folio B >
>
> Sorry my bad, I think I made people think folio B is related to
> src_pte at this point. What I actually mean is that: Another random
> folio B, unrelated to src_pte, could got swapped out, and using the
> swap entry S1.
>
> > > <put folio B to swap cache using S1 =
>
> > > ...
> > > folio =3D swap_cache_get_folio(S1)
> > > | Got folio B here !!!
> > > move_swap_pte
> > > <free folio B from swap cache>
> > > | Holding a reference doesn't pin =
the cache
> > > | as we have demonstrated
> > > <Swapout folio A also using S1>
> > > double_pt_lock
> > > is_pte_pages_stable
> > > | Passed because of S1 is reused
> > > folio_move_anon_rmap(...)
> > > | Moved invalid folio B here !!!
> > >
> > > But this is extremely hard to reproduce though, even if doing it
> > > deliberately...
> > >
> > > So I think a "folio_swap_contains" or equivalent check here is a good
> > > thing to have, to make it more robust and easier to understand. The
> > > checking after locking a folio has very tiny overhead and can
> > > definitely ensure the folio's swap entry is valid and stable.
> > >
> > > The "UFFDIO_MOVE: UNSTABLE folio passed check: 0 -> fffffdffc385fb00"
> > > here might seem problematic, but it's still not a real problem. That'=
s
> > > the case where the swapin in src region happens after the lookup, and
> > > before the PTE lock. It will pass the PTE check without moving the
> > > folio. But the folio is guaranteed to be a completely new folio here
> > > because the folio can't be added back to the page table without
> > > holding the PTE lock, and if that happens the following PTE check her=
e
> > > will fail.
> > >
> > > So I think we should patch the current kernel only adding a
> > > "folio_swap_contains" equivalent check here, and maybe more comments,
> > > how do you think?
> >
> > The description appears to have some inconsistencies.
> > Would you mind rephrasing it?
>
> Yeah, let's ignore the "UFFDIO_MOVE: UNSTABLE folio passed check: 0 ->
> fffffdffc385fb00" part first, as both you and me have come into a
> conclusion that "filemap_get_folio() returns NULL before
> move_swap_pte, but a folio was added to swap cache" is OK, and this
> output only proves that happens.
>
> So the problematic race is:
>
> Here move_pages_pte is moving src_pte to dst_pte, and it begins with
> src_pte =3D=3D swap entry S1, and S1 isn't cached.
>
> CPU1 CPU2
> move_pages_pte()
> entry =3D pte_to_swp_entry(orig_src_pte);
> | src_pte is absent, and got entry =3D=3D S1
> ... < Somehow interrupted> ...
> <swapin src_pte, using folio A>
> | folio A is just a new allocated foli=
o
> | for resolving the swap in fault.
> <free folio A from swap cache freeing S1=
>
> | swap in fault is resolved, src_pte
> | now points to folio A, so folio A
> | can get freed just fine.
> | And now S1 is free to be used
> | by anyone.
> <someone else try swap out another folio=
B >
> | Folio B is a completely unrelated
> | folio swapped out by random process.
> | (has nothing to do with src_pte)
> | But S1 is freed so it may use S1
> | as its swap entry.
> <put folio B to swap cache with index S1=
>
> ...
> folio =3D filemap_get_folio(S1)
> | The lookup is using S1, so it
> | got folio B here !!!
> ... < Somehow interrupted> ...
> <free folio B from swap cache>
> | Folio B could fail to be swapped out
> | or got swapped in again, so it can
> | be freed by folio_free_swap or
> | swap cache reclaim.
> | CPU1 is holding a reference but it
> | doesn't pin the swap cache folio
> | as I have demonstrated with the
> | test C program previously.
> | New S1 is free to be used again.
> <Swapout src_pte again using S1>
> | No thing blocks this from happening
> | The swapout is still using folio A,
> | and src_pte =3D=3D S1.
> folio_trylock(folio)
> move_swap_pte
> double_pt_lock
> is_pte_pages_stable
> | Passed because of S1 is reused so src_pte =3D=3D S1.
> folio_move_anon_rmap(...)
> | Moved invalid folio B here !!!
>
> It's a long and complex one, I don't think it's practically possible
> to happen in reality but in theory doable, once in a million maybe...
> Still we have to fix it, or did I got anything wrong here?
Hi Barry,
I managed to reproduce this issue, by hacking the kernel a bit (Only
adding only delay to increase the race window, and adding a WARN to
indicate the problem)
1. Applying following patch for kernel:
=3D=3D=3D
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index bc473ad21202..1d710adf9839 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -15,6 +15,7 @@
#include <linux/mmu_notifier.h>
#include <linux/hugetlb.h>
#include <linux/shmem_fs.h>
+#include <linux/delay.h>
#include <asm/tlbflush.h>
#include <asm/tlb.h>
#include "internal.h"
@@ -1100,6 +1101,10 @@ static int move_swap_pte(struct mm_struct *mm,
struct vm_area_struct *dst_vma,
* occur and hit the swapcache after moving the PTE.
*/
if (src_folio) {
+ if (WARN_ON(src_folio->swap.val !=3D
pte_to_swp_entry(orig_src_pte).val))
+ pr_err("Moving folio %lx (folio->swap =3D %lx),
orig_src_pte =3D %lx\n",
+ (unsigned long)src_folio, src_folio->swap.va=
l,
+ pte_to_swp_entry(orig_src_pte).val);
folio_move_anon_rmap(src_folio, dst_vma);
src_folio->index =3D linear_page_index(dst_vma, dst_addr);
}
@@ -1388,9 +1393,13 @@ static int move_pages_pte(struct mm_struct *mm,
pmd_t *dst_pmd, pmd_t *src_pmd,
* folios in the swapcache. This issue needs to be resolved
* separately to allow proper handling.
*/
+ pr_err("DEBUG: Will do the lookup using entry %lx,
wait 3s...\n", entry.val);
+ mdelay(1000 * 3);
if (!src_folio)
folio =3D filemap_get_folio(swap_address_space(entr=
y),
swap_cache_index(entry));
+ pr_err("DEBUG: Got folio value %lx, wait 3s...\n",
(unsigned long)folio);
+ mdelay(1000 * 3);
if (!IS_ERR_OR_NULL(folio)) {
if (folio_test_large(folio)) {
err =3D -EBUSY;
2. Save following program in userspace (didn't bother with error check
for simpler code):
=3D=3D=3D
#define _GNU_SOURCE
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <sys/syscall.h>
#include <linux/userfaultfd.h>
#include <fcntl.h>
#include <pthread.h>
#include <unistd.h>
#include <poll.h>
#include <errno.h>
#define PAGE_SIZE 4096
/* Need to consume all slots so define the swap device size here */
#define SWAP_DEVICE_SIZE (PAGE_SIZE * 1024 - 1)
char *src, *race, *dst, *place_holder;
int uffd;
void read_in(char *p) {
/* This test program initials memory with 0xAA to bypass zeromap */
while (*((volatile char*)p) !=3D 0xAA);
}
void *reader_thread(void *arg) {
/* Test requires kernel to wait upon uffd move */
read_in(dst);
return NULL;
}
void *fault_handler_thread(void *arg) {
int ret;
struct uffd_msg msg;
struct uffdio_move move;
struct pollfd pollfd =3D { .fd =3D uffd, .events =3D POLLIN };
pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
while (1) {
poll(&pollfd, 1, -1);
read(uffd, &msg, sizeof(msg));
move.src =3D (unsigned long)src + (msg.arg.pagefault.address -
(unsigned long)dst);
move.dst =3D msg.arg.pagefault.address & ~(PAGE_SIZE - 1);
move.len =3D PAGE_SIZE;
move.mode =3D 0;
ioctl(uffd, UFFDIO_MOVE, &move);
}
return NULL;
}
int main() {
pthread_t fault_handler_thr, reader_thr;
struct uffdio_api uffdio_api =3D { .api =3D UFFD_API, .features =3D 0 }=
;
struct uffdio_register uffdio_register;
src =3D mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
dst =3D mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE |
MAP_ANONYMOUS, -1, 0);
memset(src, 0xAA, PAGE_SIZE);
madvise(src, PAGE_SIZE, MADV_PAGEOUT);
/* Consume all slots on swap device left only one entry (S1) */
place_holder =3D mmap(NULL, SWAP_DEVICE_SIZE - 1, PROT_READ |
PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
memset(place_holder, 0xAA, SWAP_DEVICE_SIZE - 1);
madvise(place_holder, SWAP_DEVICE_SIZE - 1, MADV_PAGEOUT);
/* Setup uffd handler and dst reader */
uffd =3D syscall(SYS_userfaultfd, O_CLOEXEC | O_NONBLOCK);
ioctl(uffd, UFFDIO_API, &uffdio_api);
uffdio_register.range.start =3D (unsigned long)dst;
uffdio_register.range.len =3D PAGE_SIZE;
uffdio_register.mode =3D UFFDIO_REGISTER_MODE_MISSING;
ioctl(uffd, UFFDIO_REGISTER, &uffdio_register);
pthread_create(&fault_handler_thr, NULL, fault_handler_thread, NULL);
pthread_create(&reader_thr, NULL, reader_thread, NULL);
/* Wait for UFFDIO to start */
sleep(1);
/* Release src folio (A) from swap, freeing the entry S1 */
read_in(src);
/* Swapout another race folio (B) using S1 */
race =3D mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED |
MAP_ANONYMOUS, -1, 0);
memset(race, 0xAA, PAGE_SIZE);
madvise(race, PAGE_SIZE, MADV_PAGEOUT);
/* Wait for UFFDIO swap lookup to see the race folio (B) */
sleep(3);
/* Free the race folio (B) from swap */
read_in(race);
/* And swap out src folio (A) again, using S1 */
madvise(src, PAGE_SIZE, MADV_PAGEOUT);
/* Kernel should have moved a wrong folio by now */
pthread_join(reader_thr, NULL);
pthread_cancel(fault_handler_thr);
pthread_join(fault_handler_thr, NULL);
munmap(race, PAGE_SIZE);
munmap(src, PAGE_SIZE);
munmap(dst, PAGE_SIZE);
close(uffd);
return 0;
}
3. Run the test with (ensure no other swap device is mounted and
current dir is on a block device):
=3D=3D=3D
dd if=3D/dev/zero of=3Dswap.img bs=3D1M count=3D1; mkswap swap.img; swapon
swap.img; gcc test-uffd.c && ./a.out
Then we get the WARN:
[ 348.200587] ------------[ cut here ]------------
[ 348.200599] WARNING: CPU: 7 PID: 1856 at mm/userfaultfd.c:1104
move_pages_pte+0xdb8/0x11a0
[ 348.207544] Modules linked in: loop
[ 348.209401] CPU: 7 UID: 0 PID: 1856 Comm: a.out Kdump: loaded Not
tainted 6.15.0-rc6ptch-00381-g99f00d7c6c6f-dirty #304
PREEMPT(voluntary)
[ 348.214579] Hardware name: QEMU QEMU Virtual Machine, BIOS
edk2-stable202408-prebuilt.qemu.org 08/13/2024
[ 348.218656] pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=
=3D--)
[ 348.222013] pc : move_pages_pte+0xdb8/0x11a0
[ 348.224062] lr : move_pages_pte+0x928/0x11a0
[ 348.225881] sp : ffff800088b2b8f0
[ 348.227360] x29: ffff800088b2b970 x28: 0000000000000000 x27: 0000ffffbc9=
20000
[ 348.230228] x26: fffffdffc335e4a8 x25: 0000000000000001 x24: fffffdffc3e=
4dd40
[ 348.233159] x23: 080000010d792403 x22: ffff0000cd792900 x21: ffff0000c5a=
6d2c0
[ 348.236339] x20: fffffdffc335e4a8 x19: 0000000000001004 x18: 00000000000=
00006
[ 348.239269] x17: 0000ffffbc920000 x16: 0000ffffbc922fff x15: 00000000000=
00003
[ 348.242703] x14: ffff8000812c3b68 x13: 0000000000000003 x12: 00000000000=
00003
[ 348.245947] x11: 0000000000000000 x10: ffff800081e4feb8 x9 : 00000000000=
00001
[ 348.249284] x8 : 0000000000000000 x7 : 6f696c6f6620746f x6 : 47203a47554=
24544
[ 348.252071] x5 : ffff8000815789e3 x4 : ffff8000815789e5 x3 : 00000000000=
00000
[ 348.255358] x2 : ffff0001fed2aef0 x1 : 0000000000000000 x0 : fffffdffc33=
5e4a8
[ 348.258134] Call trace:
[ 348.259468] move_pages_pte+0xdb8/0x11a0 (P)
[ 348.261348] move_pages+0x3c0/0x738
[ 348.262987] userfaultfd_ioctl+0x3d8/0x1f98
[ 348.264916] __arm64_sys_ioctl+0x88/0xd0
[ 348.266779] invoke_syscall+0x64/0xec
[ 348.268347] el0_svc_common+0xa8/0xd8
[ 348.269967] do_el0_svc+0x1c/0x28
[ 348.271711] el0_svc+0x40/0xe0
[ 348.273345] el0t_64_sync_handler+0x78/0x108
[ 348.274821] el0t_64_sync+0x19c/0x1a0
[ 348.276117] ---[ end trace 0000000000000000 ]---
[ 348.278638] Moving folio fffffdffc3e4dd40 (folio->swap =3D 0), orig_src_=
pte =3D 1
That's the new added WARN, but the test program also hung with D
forever, and with errors with other tests like:
[ 406.893936] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0
type:MM_ANONPAGES val:-1
[ 406.894071] BUG: Bad rss-counter state mm:ffff0000c5a9ddc0
type:MM_SHMEMPAGES val:1
Because the kernel just moved the wrong folio, so unmap takes forever
looking for the missing folio, and counting went wrong too.
So this race is real. It's extremely unlikely to happen because it
requires multiple collisions of multiple tiny race windows, however
it's not impossible.
I'll post a fix very soon.
Return-Path: <linux-kernel+bounces-667805-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 09F1841E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:49:47 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id A69CE7AA140
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:48:28 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 652EC21CFF6;
Fri, 30 May 2025 08:49:30 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b="dmlo2vsq"
Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2076.outbound.protection.outlook.com [40.107.102.76])
(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 EDB3921B90B;
Fri, 30 May 2025 08:49:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.102.76
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748594969; cv=fail; b=XipynjscRIj/4ejBZSpj9WYORuHuWv3/UJGc2mIRf2CEWze/qYV6U60bH+GR8l4+fukvj+XanI1CxBiFdiaZvfeYr3B6ucGdhfpEigrX3Du4gRotX3MKOIJK9wtfHLs0UpmmOZD3aNv5mEtdpJERpKRChgzCM7CB16ClfmfF270=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748594969; c=relaxed/simple;
bh=5llxRuECByZJwQ/dd+tYGTgRWJwIGgk2RYukAhzNmmw=;
h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:
Content-Type:MIME-Version; b=OO8aFsGpmFqzkTn/ajsT6ptOrsv77oaAFxo/KPDxMY4QVy5OGA8pu2hOsOZ1zmgsimy0uEZB5Z4goR1SJGNLnS/lh6XJHdGNsz2jOpJ149boovZR0oVCqMns8zArQY/maAqSBjR/DAoTA+IQ5f7/Tzuw98v7RknXFrL3L299ze8=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com; spf=fail smtp.mailfrom=amd.com; dkim=pass (1024-bit key) header.d=amd.com header.i=@amd.com header.b=dmlo2vsq; arc=fail smtp.client-ip=40.107.102.76
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=amd.com
Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=amd.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=NTxY4pKi0PXCG9Z80FXAElglz+qjmwVw4GeV7mY5QduQHyQ6E1lJMsy4hhBHtVOD25twEWjOgOpxKlpmCuqCOmMUVNRc1DRCAq2I/I8U1X/PjVk98yO7U7iCIgFQX4y8kg/noIFCPR0cLg7JXzbX1GFkg5sVCljbKr1xYSNhMjV8wAZSg0sCYcqiCc206Iw0j4jemM5CiXF8JgbNa+AmqIelTfpIbqmMIOYrITCMEIOfXUgO3yXybhZCg/FW1/JDSCN2Ls9hcMl6NQsmoGu/2HlW05wSu6Uhj2/vyaWMkceAvoAgugqESCeTV57jwn1KWvWYSyEVUM/JwMmHF5TaOQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=G6CORtijIU0rbtjzNzihjEFoP6F4ecd6+LLcqcA8XXE=;
b=lPmhb46x5k7lv07lelREonM9Bh0svJUTs+02sdqSymdFTk0weOvGwn6q4KDNXCs3WgQNf+dOMdtvTyg85sTnLfIRJIJ5hOmHtaiFs+nm9sWYMKQ220bTGYiNydHtXulyd9sV16JdrMXzu2nEMk8Rae/n+Nyq3PpbYpX88x6pQ/IMlIXa3VBr47xm0Opc4HW14Eo4qq0pEEZ6VO70UmALer71SONfKtZM8Sn0SSZvzrxhpGA4KNU7wd79tY6AoKscnwK+/HctK3kqpElQTxVP9IdKMw2/a2Wf9Y1NWz1ePWTbzDMT/XM5LU3ffCLTy5zhGdJv3YvtBiEXVUu6mR+hHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass
header.d=amd.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=G6CORtijIU0rbtjzNzihjEFoP6F4ecd6+LLcqcA8XXE=;
b=dmlo2vsqXOP+USkEaGTdcqUN7QwsjdwvbXCQ453ssXk3hySwXimAGQWkfX4PNEew5qrtkbPNil1G1o3YIRSLh03sXdvwHQXahRMePyscf84K/2geuD1LL7uG4qCqINLvVS9b1C/mH1+SrX3PLuhgGMSWuw35B8/1YLwscd0GO+4=
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=amd.com;
Received: from CH3PR12MB8658.namprd12.prod.outlook.com (2603:10b6:610:175::8)
by SA3PR12MB9131.namprd12.prod.outlook.com (2603:10b6:806:395::15) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.31; Fri, 30 May
2025 08:49:25 +0000
Received: from CH3PR12MB8658.namprd12.prod.outlook.com
([fe80::d5cc:cc84:5e00:2f42]) by CH3PR12MB8658.namprd12.prod.outlook.com
([fe80::d5cc:cc84:5e00:2f42%7]) with mapi id 15.20.8769.022; Fri, 30 May 2025
08:49:25 +0000
Message-ID: <64902e02-0808-4e0b-94a4-c1a57441a8ee@xxxxxxx>
Date: Fri, 30 May 2025 14:19:13 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 00/13] KVM: Make irqfd registration globally unique
To: Sean Christopherson <seanjc@xxxxxxxxxx>,
"K. Y. Srinivasan" <kys@xxxxxxxxxxxxx>,
Haiyang Zhang <haiyangz@xxxxxxxxxxxxx>, Wei Liu <wei.liu@xxxxxxxxxx>,
Dexuan Cui <decui@xxxxxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>,
Stefano Stabellini <sstabellini@xxxxxxxxxx>,
Paolo Bonzini <pbonzini@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>,
Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Juri Lelli <juri.lelli@xxxxxxxxxx>,
Vincent Guittot <vincent.guittot@xxxxxxxxxx>, Shuah Khan <shuah@xxxxxxxxxx>,
Marc Zyngier <maz@xxxxxxxxxx>, Oliver Upton <oliver.upton@xxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-hyperv@xxxxxxxxxxxxxxx,
xen-devel@xxxxxxxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx,
linux-kselftest@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
kvmarm@xxxxxxxxxxxxxxx, David Matlack <dmatlack@xxxxxxxxxx>
References: <20250522235223.3178519-1-seanjc@xxxxxxxxxx>
Content-Language: en-US
From: K Prateek Nayak <kprateek.nayak@xxxxxxx>
In-Reply-To: <20250522235223.3178519-1-seanjc@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: PN4PR01CA0089.INDPRD01.PROD.OUTLOOK.COM
(2603:1096:c01:2ae::7) To CH3PR12MB8658.namprd12.prod.outlook.com
(2603:10b6:610:175::8)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH3PR12MB8658:EE_|SA3PR12MB9131:EE_
X-MS-Office365-Filtering-Correlation-Id: 6a6bf19a-9db7-46db-9d5e-08dd9f56e0ea
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
BCL:0;ARA:13230040|1800799024|7416014|376014|366016|921020;
X-Microsoft-Antispam-Message-Info:
=?utf-8?B?MW5YZGluMENXUCtWc2RYL0JCTklkUFRnWDlhMGVCaU1PQjJjVWpyMGJxKzAr?=
=?utf-8?B?MW91VElxUzQ5dXdkYjVVWHY4TmR2OExhR1ZFU01PQ2lVTGNma2p1TmRiRGJy?=
=?utf-8?B?ZjNUYncyZmkya3RPTmd2YXlBZWZvSmRvRGhMMFJoaXpFTDcrVEVpeitpclhw?=
=?utf-8?B?SnZOZitvdzgzbXoyQTlWUjZReldiWXNDbk1FTXUyaHVlQUZWcUUxbzN1R2hn?=
=?utf-8?B?Y092ZFREVkllZnhrTVQyMzE0Y3kvWlRNcWF0aHJudXkxNUVRZjBwRDZvVDEx?=
=?utf-8?B?dms2bWZoU2ZOWisvK0VmL0kyZHFyNjkwV08rcGVMdHVuaTljYnZiYyszdWV1?=
=?utf-8?B?U2FUVWZPN0k5bmRSNHhhZGdsYXkyTUlRT1VYSzJMTmUwTkZ5c05uNHNTbzls?=
=?utf-8?B?MW5pY0RneDhSNUNaWkl4c0FGMzBjbVVMVmkvKzA4VE5RdFhKL1lUYzlvNUhN?=
=?utf-8?B?Ulg1RFFJbHhOaWNpUEhLbDVpVmp3T25tUWFKdUlTS1AzTWhIald6VDYyMnRp?=
=?utf-8?B?dzJQTk5jSVJ3bi9XZ2Z4cEkwYUp2Qm9UcFNuN2RrY1o5ZWczdkhiWk9MdzhZ?=
=?utf-8?B?T1pXc0plQjFiKzNDZU9KRVp1STIvb0tzdVZLQjRVTzg0TlYzaDNaZ2dLK1Za?=
=?utf-8?B?aVJ2THpNVml2MjZsSERyNHA0UFhyTmZmMEFYbHFpM3EvZTBRTXYvZnVkL05Y?=
=?utf-8?B?RW50MEsxWUFDckovR0R5NEZJdXJrZXJabWpGZnRvdFg5cmR6aFBaN2pnNU1T?=
=?utf-8?B?aHo3dmdRQklVVGhqQXZVNWNxdTZsbEppaTdvOFhDSHZ6eE9wUnpVblNMakdC?=
=?utf-8?B?K0JwOU5wZkdnVXRsVnMwNzBIam1YTXFWZUF2NEtyckhjQ3I0K1VOQ0RwNUZW?=
=?utf-8?B?amFXRzRHUC81QXZvZTdMeE8zeGhrMWkrbmpjR281VldkMHJzWEdYT1g5OUc2?=
=?utf-8?B?TUxDeDdJK0UvWit4YnNBMUdPdW5ua0JvS3VsQmxaYS9MVkNsd2lqZCtuNWt4?=
=?utf-8?B?OXltY2ZvM3ZPbVhLRFhabW5RYS9DT3NyaERIRS8xUFBWL284T1ZYeWFLWTQ4?=
=?utf-8?B?bVhHU0lPQXhzdjB4T1ZOOVdZOGR6R2gzV0p6ZVpHZ29IU2pjMElIeDlwWmdH?=
=?utf-8?B?QjFaUTkrdG1SNGMwK1VPaHRlcThHbCtLYXdQWmFkUmlyUGxRemVVWjdQYzM2?=
=?utf-8?B?Q2pZY1M0VDhFb0pSb0VVTlBLTjdHVjJ4YzFrRDdEeDB6M0ljQWc0cXlYTzc0?=
=?utf-8?B?ZThjaVE2TGtYeVEwc0pMOTVGa000R3orRm9nbzVZdkdzOEoyWUdmVmx2UTIz?=
=?utf-8?B?TER3bSs2ODQvRnhEam5BRFNEU05ZZzEzQmdvdmQ1bzlWVlFEWTk0WTZ4SjBJ?=
=?utf-8?B?Zk85OUt3dC9KVXVmaDl1Y0g5TnRaQXdST1IveW96TU9iMU5uM2tMQ1RPMzJE?=
=?utf-8?B?STBXS2pJT3JueGNzSENOdjcxOUtqcXVPYjR1aDN1Z1A1bDEzeGdWK3k0cGtY?=
=?utf-8?B?KzVvU0t6KzZYdzMxSSs0eVZGRWpKTTYrTDlKWUNmZzJMd3Q0eW0zNmh0NGUx?=
=?utf-8?B?cERERnJtYzlYaUVIcWUxRW4vbDNQZjd6SVJ2RkY3WWZnQUdkTmRXeUhPNHJH?=
=?utf-8?B?bTRxeWdreHlCWjlWcksrSjRObWJVN1hQM0lYN2dCSnJtVXNGZ3NZVXJITVdq?=
=?utf-8?B?czJRNG5qcmp5a3k1bnNRVU5XRkkzdUVEVXZtWTVNajhQOXF0a2RtQW9PTVJw?=
=?utf-8?B?eUFzeXVjN2QwVzRNWTF3clZVK0pZZTZmWjk3amJDTGlVU3BmVTZMeVdmbEZz?=
=?utf-8?B?RnhOdGlTZm1NMThsTjFUS1kyTFprcVF0Slp4K3BXNDFNOHJQUk1yS2FCa0oy?=
=?utf-8?B?OGN5Rzl0Qkw0YjFlL3AraTMxK1ZjY1BnTzZZajJIQjFQWk1ha3hiNitHeXJF?=
=?utf-8?B?a1BVTStodlQ2Y1p0N0lWakcwcjRsR3R5SjNEZ21ZTFB0WnFnQkhjQUJVYXc5?=
=?utf-8?B?NjNGeDRtcVNRPT0=?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:CH3PR12MB8658.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(921020);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?utf-8?B?bSsrQ3ZVWlB3cTVTR3R5ZXpmK21tVmJ4U0lBNTdQYTlRaUR5di9GSm5ySmJO?=
=?utf-8?B?WkhaZnZnUS82TTRuRTcrN1lTcGxiUjk1VzBIc2JzaFBUM1lTSThxcU02NmN3?=
=?utf-8?B?endkSDQwNXBUMzBaMjE4ZXc3YnZlMWN6Ym5UMlcwOVlHUE0vK2lSQW0zUlR4?=
=?utf-8?B?RDA3Vnk1RzErMHNkck1va3l4NVRHSmdMMmNpUFVpRFk2bis5R0RrSWc5VEEw?=
=?utf-8?B?bWJXTGpmQVdCUkhBL1BvZ3BnU0pMaFpDTSs1N0lOOVM4OW1PQzV6NWRaUXBY?=
=?utf-8?B?RnZaSzZKaXpsa1Z0ZGVwa3ZteW9QeTN1bmEweVRseXpVZzZTV0hlVkNvbDZM?=
=?utf-8?B?MHA1ZWt0ellhUzBNTlFHRStmMHkwS2s5dmNlZFgyVG5TaUkxYzZtOG4xOHR0?=
=?utf-8?B?UXBBcHhsSXRLT1NQUkFFWElkVWRzZUNHS1h4WExrbk1KTi9yTVBFUUNWdnk4?=
=?utf-8?B?UEJDZG1TVWxsTFIxSFJiUTBlUFEwckZLcm9sMEZhNGdEdG9TdTlJbFMyQVRI?=
=?utf-8?B?T2hYMmNMSk9kalVUaTN1RDNZcm55TGNRNTFQb3BsWUNnMDZqbUhyNERqSHJ3?=
=?utf-8?B?NnY3K1RXcFY3R0lhcHRobnBWYWVvcm5lOWNQNDV4R285cFlRN1RrNzRRWm96?=
=?utf-8?B?dnJlelBGeExBdUJqcXBmNStodzkzMHArdjJ0ZHRhN2xMMjk5OTNqVVZYZC9V?=
=?utf-8?B?a3BzNXFvZUE4YnRmTzhvb3BHb01SVGZ1bjVoRUVXRmtudHhiK0NodkI1c1hh?=
=?utf-8?B?MXY4empWbEVKelBmR3lXMkFxZ09HSXlxc29DK3QxWFNWbzczOENJbW1nN2JR?=
=?utf-8?B?ODA4RVkxUE5QNm9KeFpQSTFtVXk0VXpiUk42RmpEejN2U1FYbXlVdkhXZWFK?=
=?utf-8?B?NGN4S1BTc2hWb1RodmtjT1J2TDlHMDI3M3doOTdaNkVURkg3bGRGckcwa1VM?=
=?utf-8?B?bGhDT2h6RnpsNnA4OW1HcHl5bW5KSEpBbkFranEwZk1ISTkybDk4QVpQYjBT?=
=?utf-8?B?TlUvQkowM3ZUQU8xZEVXWG1yTlVycVFKaVE3VEF4NDFiQzdGbTdnTWJlNWRS?=
=?utf-8?B?OUoxVWdBQi9pcE80L3QxQlVORG5yMjdUdTc2TWkyWVZMUEJWYVRrbnlWQWlO?=
=?utf-8?B?RmU4Q2FOR0dBUU5VSEs5RHZ6WTUwN1JUYlN6VXlWR2FGOEtQV3RRUXNMT09J?=
=?utf-8?B?a0htTHZZblk0dlVISVh0OUlEWnhLNFQ3eittTzVTaEM2NDZ2N2dVUjI1SFY2?=
=?utf-8?B?WEQxZExUcmp2SEJHVFlrQTdTUTdIcnlQQTlYU3UrNjAxTlJBRzhkdVdMV3NC?=
=?utf-8?B?aGtEZExpc0Y5a2pBeWxTUWlkSFQ0Tlp6dWJsYW0xWE8vMHVYM3haRnlGZ3p5?=
=?utf-8?B?V09YVlhqd3h4RUV5dFhuazQzVFMzWWVCV1FTbmZJVGNXaG9LUkwyWXRYdjRx?=
=?utf-8?B?NkJoamRBUkJYTEhGT0d2bXM1S05xUnJPQUdESlNSa2w1aWh1SGxvOGxkT0Fx?=
=?utf-8?B?a0prS0tsN2xrTjFOQXB3QmM0ZnE2dkdBWEVUdEM2cUZVcy96RjdWOGpUVU5U?=
=?utf-8?B?UCtwTUZOQVBQWnZockhOZVlHMkNSTjU2Y1pNU1dZREViWGdQemNXR21ud3I5?=
=?utf-8?B?WjR3OXZTWWh1TGNzUHRacmxhcmQ0UVczbU0zWU5FQ2cySGVnREZIMFdrd2Zs?=
=?utf-8?B?bVY4SDNQRFBvSWxGZWp0UnA2NFBaM3VtMGt0NStsMDFadVVhemx5N2Z6eXc5?=
=?utf-8?B?eWR5dHZrUjB2bkk3V0I1YXpMT3p4SjFVYWFGNDdWbTBjdnlvSUxkWVZ5bWhu?=
=?utf-8?B?ZzNBYjd6WVBXbVFQT0p3anNQM0hYWExSRzAyRCtxcUt4OFBWZGRWaUZHRFE5?=
=?utf-8?B?TVcrQi9UV0JNV0JWeS95TkxiUWFjM202R05hUzBLVS9WdzdUanpOa1JoRnhQ?=
=?utf-8?B?UFNMVlZodXlnaGN0Qmp6YnBMUkFQUzFvL3RkcUJoc1dpczFhUSsrQyt6MG83?=
=?utf-8?B?RExubkxnZXkyTitQVW95OElTOVo5TExRYWwyUS9oRUNqTy9VU2pOYnpKMVdn?=
=?utf-8?B?dnNTTkhVVTRWTEFQbURNQkRERjlzTUw3OWJpcXNqTkpJTC95QVl4YlpYK3dU?=
=?utf-8?Q?9dn6+JucxyO3C4WozczQYgfko?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6a6bf19a-9db7-46db-9d5e-08dd9f56e0ea
X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB8658.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 08:49:24.9920
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vqI1Dn0cGj2uuzh7d8h6/mpPYxVhKsf//t3lftjpILfrQz/TVmQvn/3J/tl+VXOb9lRLfgpyfRloQjdRJ8eHNg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR12MB9131
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hello Sean,
On 5/23/2025 5:22 AM, Sean Christopherson wrote:
> Non-KVM folks,
>
> I am hoping to route this through the KVM tree (6.17 or later), as the non-KVM
> changes should be glorified nops. Please holler if you object to that idea.
I've tested this series with the selftests and also ran KVM unit test
on top of the specified base and didn't see anything unexpected. Feel
free to include:
Tested-by: K Prateek Nayak <kprateek.nayak@xxxxxxx>
--
Thanks and Regards,
Prateek
Return-Path: <linux-kernel+bounces-667806-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 38C6F41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:50:41 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id D38747B044D
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:49:22 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id BF60221B9D6;
Fri, 30 May 2025 08:50:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="TVJayZrJ"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124])
(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 10B68218ACA
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:50:30 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595032; cv=none; b=OjtFqvwlCsKcFV8FiDKY+YdfYyzGBG6/nhB2DYahS3tPXuqxxflAu8PkA92IPPzJcJcZUUclZ2wHTMb7xrVNKM2Dlbd1hZyLkpNloxWD+srWNsiP7h1OGMUd23LbKZ2HYu4RTJDhpkzaFXV8HPs43epf2h0Qv8Ymz3hWDaGODMU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595032; c=relaxed/simple;
bh=Tbqc8hLPMrW47kJKXZ3VaiSdYPfB1sAgTwJs14fpnqE=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=mFng6WHzhj8X4EnStgcUvdsL1rEw5f10htm9G9DyrqloYn8bZYO/Q5FfLasXattPFglcmymMDPut5rhZ6gFiCYG810dYyBd8rmII3o3Lhs97rk1RGsU5Xqyi5M+VSoq2yNqBW+NVlAmp+/sBWk830XPTY/Dl+s4aV+S6xP/wyS4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=TVJayZrJ; arc=none smtp.client-ip=170.10.129.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748595029;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=L0+8r+h5VJZKyWcv1fSQdLPCY66hBJlKTv4UFpyXBK8=;
b=TVJayZrJod8uBz5QqvTSaAl50R3znbbEsqdRT3Ti/Q+bpVBuhrigkAJkuO4f/e4oEe1NXw
GNbIIDJcPCyal5Emfp+Qjq6mlTpyAxHkRR016EgSKWkeslRx2+Or96MjyXkyW0hAH+3Gst
vEsVCwvzVExHmSJ8D3yaZMojHcNoaBE=
Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com
[209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-35-X66WavRWM3eyLXXSNbY0tQ-1; Fri, 30 May 2025 04:50:28 -0400
X-MC-Unique: X66WavRWM3eyLXXSNbY0tQ-1
X-Mimecast-MFC-AGG-ID: X66WavRWM3eyLXXSNbY0tQ_1748595027
Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3a367b3bc13so749389f8f.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:50:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748595027; x=1749199827;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=L0+8r+h5VJZKyWcv1fSQdLPCY66hBJlKTv4UFpyXBK8=;
b=hKfsCqFDh5+NMcFbPbxK5u6rsvmyQRBzdqwNozTjvGUCQofe7IHq8ea4YErsDPEYh4
iy50NVnXlZXtzdWhleTt2n8AkC7BUEj/MW4NKfEC8iFueQVB+ErMtRXhBKMGJ6mdAkOE
dWQhquBHbWojzVo+8ww54h296BYaKU2xVfOyRfWSL+nnH5KKW/lDdWyn0p77b65su5wA
6t8yMzZCmQZmszopacPO5H73LgMVTeCztiar3UGAry4TuMkNr+zbVJ5ihvGXys3zhDFA
irUoQ26LKYb80JFtbrFAbYXQpsi13UX8XbhCQ6UCPmmkswRnWenJo2GMlF2xsoSPK8+3
vrCg==
X-Forwarded-Encrypted: i=1; AJvYcCVWuV8oQCt8rWrUu754WwqW85mu8AXd4Sh5gvJmUoSvyi47iOlE08Knp+bGJCVJlcm73jt++bOKKAQlH1E=@vger.kernel.org
X-Gm-Message-State: AOJu0YwazO8WK/Ndo5hzfENwjPcN2LaMUFBc70YnjdgQlWpcZXbcbuGD
KW+n3DjEgyS/g/GyhwYVMtjPy0wZeuAV159wKrqhChdpr0zGqVNAMJin7I6wkiMrUXtvN73WiNk
6BZpCm+Dlb8Ugz9tf81OvceHrs7Bp8thI9wj+igDWVZWud2J6+OLrvtUBPPj7xSFlgg==
X-Gm-Gg: ASbGnct6hm/SLajjKdv++j3WUZwsGBASgyrL66NmPOP1qIpRvtANUTrFypMqVHWQQ+E
FINiPEezEDA/pT9g9MqQe2GxpsnYPUKJLQElRMB3bgHINmDJ8NFFuHRqV7dbq412VZc8lQwyeSf
oaqh8qsDSoE6OdPHcPM6ZhUafHMz+WIOQ3lH1pMV3bPyLJevisIVcF5CM7qCWJ/er98b22ajKfw
BO0p8V2Xay+AG2/ByB7hTTnTyNYoQuQjBW5LZcuxioRCsh80SWaSV2cWI+/0MliRHEw69rmIDvN
i3QR1YooOEGVkQ0Nw6CifvnblgLyKj/AXJbbA9f2BHORAa/owIRh5ZFI5grmWOOrMjdUoGaFVip
b5GXs7BJFilLcewL5cNjM+fbqisBBA9TLsibKTMg=
X-Received: by 2002:a05:6000:3112:b0:3a4:bac3:2792 with SMTP id ffacd0b85a97d-3a4f7a3dc11mr1778328f8f.4.1748595027201;
Fri, 30 May 2025 01:50:27 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFHn1gr3Osd9HyyalCFGtczxVvHmWzyW6PptnSQ10SjPGM6h42L5/AfeMh2GjoihBYKi6RlQw==
X-Received: by 2002:a05:6000:3112:b0:3a4:bac3:2792 with SMTP id ffacd0b85a97d-3a4f7a3dc11mr1778304f8f.4.1748595026810;
Fri, 30 May 2025 01:50:26 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fc2725sm11823505e9.37.2025.05.30.01.50.25
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:50:26 -0700 (PDT)
Message-ID: <172df994-7f24-4fbb-876c-4fab22937177@xxxxxxxxxx>
Date: Fri, 30 May 2025 10:50:25 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when
expanding vma during mremap
To: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
Cc: Pu Lehui <pulehui@xxxxxxxxxxxxxxx>, Oleg Nesterov <oleg@xxxxxxxxxx>,
mhiramat@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, Liam.Howlett@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx, vbabka@xxxxxxx, jannh@xxxxxxxxxx,
pfalcato@xxxxxxx, linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
pulehui@xxxxxxxxxx
References: <62b5ccf5-f1cd-43c2-b0bc-f542f40c5bdf@xxxxxxxxxx>
<afe53868-5542-47d6-8005-71c1b3bec840@xxxxxxxxxxxxxxx>
<13c5fe73-9e11-4465-b401-fc96a22dc5d1@xxxxxxxxxx>
<4cbc1e43-ea46-44de-9e2b-1c62dcd2b6d5@xxxxxxxxxxxxxxx>
<20250526154850.GA4156@xxxxxxxxxx>
<06bd94c0-fefe-4bdc-8483-2d9b6703c3d6@xxxxxxxxxx>
<57533126-eb30-4b56-bc4d-2f27514ae5ad@xxxxxxxxxxxxxxx>
<cba0155e-d2b9-41fa-bc51-f3738ae73cff@xxxxxxxxxx>
<956124be-c73c-4023-9edd-25372f3f865a@xxxxxxxxxxxxxxx>
<ccf359b0-8baa-4209-b2c3-75e3813ca804@xxxxxxxxxx>
<b2dd29b0-aa12-4cb7-9c05-d3a998f7b0da@lucifer.local>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <b2dd29b0-aa12-4cb7-9c05-d3a998f7b0da@lucifer.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 10:41, Lorenzo Stoakes wrote:
> On Fri, May 30, 2025 at 10:33:16AM +0200, David Hildenbrand wrote:
>> On 29.05.25 18:07, Pu Lehui wrote:
>>>
>>> On 2025/5/28 17:03, David Hildenbrand wrote:
>>>> On 27.05.25 15:38, Pu Lehui wrote:
>>>>> Hi David,
>>>>>
>>>>> On 2025/5/27 2:46, David Hildenbrand wrote:
>>>>>> On 26.05.25 17:48, Oleg Nesterov wrote:
>>>>>>> Hi Lehui,
>>>>>>>
>>>>>>> As I said, I don't understand mm/, so can't comment, but...
>>>>>>>
>>>>>>> On 05/26, Pu Lehui wrote:
>>>>>>>>
>>>>>>>> To make things simpler, perhaps we could try post-processing, that is:
>>>>>>>>
>>>>>>>> diff --git a/mm/mremap.c b/mm/mremap.c
>>>>>>>> index 83e359754961..46a757fd26dc 100644
>>>>>>>> --- a/mm/mremap.c
>>>>>>>> +++ b/mm/mremap.c
>>>>>>>> @@ -240,6 +240,11 @@ static int move_ptes(struct
>>>>>>>> pagetable_move_control
>>>>>>>> *pmc,
>>>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (pte_none(ptep_get(old_pte)))
>>>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>>>>>>>>
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â /* skip move pte when expanded range has uprobe */
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (unlikely(pte_present(*new_pte) &&
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â vma_has_uprobes(pmc->new, new_addr,
>>>>>>>> new_addr +
>>>>>>>> PAGE_SIZE)))
>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>>>>>>>> +
>>>>>>>
>>>>>>> I was thinking about
>>>>>>>
>>>>>>> Â Â Â Â Â WARN_ON(!pte_none(*new_pte))
>>>>>>>
>>>>>>> at the start of the main loop.
>>>>>>>
>>>>>>> Obviously not to fix the problem, but rather to make it more explicit.
>>>>>>
>>>>>> Yeah, WARN_ON_ONCE().
>>>>>>
>>>>>> We really should fix the code to not install uprobes into the area we
>>>>>> are moving.
>>>>> Alright, so let's try this direction.
>>>>>
>>>>>>
>>>>>> Likely, the correct fix will be to pass the range as well to
>>>>>> uprobe_mmap(), and passing that range to build_probe_list().
>>>>>
>>>>> It will be great. But IIUC, the range we expand to is already included
>>>>> when entering uprobe_mmap and also build_probe_list.
>>>>
>>>> Right, you'd have to communicate that information through all layers
>>>> (expanded range).
>>>>
>>>> As an alternative, maybe we can really call handle_vma_uprobe() after
>>>> moving the pages.
>>>
>>> Hi David,
>>>
>>> Not sure if this is possible, but I think it would be appropriate to not
>>> handle this uprobe_mmap at the source, and maybe we should make it clear
>>> that new_pte must be NULL when move_ptes, otherwise it should be an
>>> exception?
>>
>> Yeah, we should ay least document that if we find any non-none pte in the
>> range we are moving to, we have a big problem.
>>
>> I think the main issue is that vma_complete() calls uprobe_mmap() before
>> moving the page tables over.
>
> Well vma_complete() is not _normally_ invoked before moving page tables,
> it's mremap that's making things strange :)
>
> That's why I think my suggested approach of specifically indicating that we
> want different behaviour for mremap is a reasonable one here, as it special
> cases things for this case.
>
> However...
>
>>
>> If we could defer the uprobe_mmap() call, we might be good.
>>
>> The entry point is copy_vma_and_data(), where we call copy_vma() before
>> move_page_tables().
>>
>> copy_vma() should trigger the uprobe_mmap() through vma_merge_new_range().
>>
>> I wonder if there might be a clean way to move the uprobe_mmap() out of
>> vma_complete(). (or at least specify to skip it because it will be done
>> manually).
>
> ...I would also love to see some means of not having to invoke
> uprobe_mmap() in the VMA code, but I mean _at all_.
>
> But that leads into my desire to not do:
>
> if (blah blah)
> some_specific_hardcoded_case();
>
> I wish we had a better means of hooking stuff like this.
>
> However I don't think currently we can reasonably do so, as in all other
> merge cases we _do_ want to invoke it.
"all other" -- not so sure.
Why would we invoke uprobe when merging VMAs after mprotect, mremap,
madvise, ordinary mremap where we are not mapping anything new but just
... merging VMAs?
Really, we need to invoke uprobe only when adding new VMAs or extending
existing VMAs -- mapping new file ranges some way.
Or am I missing something important?
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667807-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 7FAC641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:50:59 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 281787B2417
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:49:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id AE09C21C9FE;
Fri, 30 May 2025 08:50:52 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Q1xJJHJY"
Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12])
(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 160C9219A6B
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:50:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.12
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595051; cv=none; b=ppK5eepM/Pmylk7DR/A/FD3uANA7p+iRGck5gmO3pPelz5a79oJih/L0YVtyr3gng8ntbIClJfT1XXKb+aEIyrDfAGP25z9yHcZiFZ3o2zSJuiO0TdCoKsAt2EalS9XGzhZcMpvrkmpNOMB99nCBbM3A0UHNUjSQzvZUt56SMA4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595051; c=relaxed/simple;
bh=VYBwXeuVPw8aB9t9e43QtCFwc/yGv5YEZT/pxnp07Jw=;
h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type:
Content-Disposition; b=t9TuhX9Wh5ha8aSUKunMOcY5c6HKVrVWFA14ku8mDG5KiSuVj+meRBthwlPZgwNMa2wfrImwjpKwaXmaeorwrIT/+vkgyEmE/xVJyX32wF5j+htNMPFF445C/fZgVHjRayfkFQ/6b4ZtK14+O7vmnyPFu7tyTyy9qJ/wQEKx/Js=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Q1xJJHJY; arc=none smtp.client-ip=192.198.163.12
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=intel.com; i=@intel.com; q=dns/txt; s=Intel;
t=1748595050; x=1780131050;
h=date:from:to:cc:subject:message-id:mime-version;
bh=VYBwXeuVPw8aB9t9e43QtCFwc/yGv5YEZT/pxnp07Jw=;
b=Q1xJJHJYvtTSwZyzzB+xP+LtWVHmfyxsgnX4PStPaRAWMWcIkiPoQLuF
DUeLoKFyw9Rx/5LcNdi2w9yxL+lK9EH40ke3C76theDW6bQjt8EuNONaJ
jLzhAfljA32p0yjeEhN2rTYfs4OCuJo2Ilox4V/mRdYbf7ZQv4/53jxyf
RxGKomAxHRvbrVXkQpcuLxnRJxU8DWCy+3PkYgPn+OTjEWV3117klVasg
x1HKZV8oJ7zg9qbbQ1wtzTp5fhr/JdsRHb/vO3RYQYUhLbdTVhBw2l4+2
1FQE0kJxUh6XwVvem6V56FJ96O2suVHpDSnHi/Gw2QINahkbpK3Cv7rkh
Q==;
X-CSE-ConnectionGUID: 2/d3bNdIQEGyMP82KaWaSA==
X-CSE-MsgGUID: QkttEe+PSa2+sNFshL4wXQ==
X-IronPort-AV: E=McAfee;i="6700,10204,11448"; a="54475670"
X-IronPort-AV: E=Sophos;i="6.16,195,1744095600";
d="scan'208";a="54475670"
Received: from orviesa005.jf.intel.com ([10.64.159.145])
by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 May 2025 01:50:49 -0700
X-CSE-ConnectionGUID: 7zpkjX6tQhimcGbwYW22Dw==
X-CSE-MsgGUID: r4BO/+T9S42/VjQeGT8p3Q==
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="6.16,195,1744095600";
d="scan'208";a="149089613"
Received: from igk-lkp-server01.igk.intel.com (HELO b69e6467d450) ([10.211.3.150])
by orviesa005.jf.intel.com with ESMTP; 30 May 2025 01:50:48 -0700
Received: from kbuild by b69e6467d450 with local (Exim 4.96)
(envelope-from <lkp@xxxxxxxxx>)
id 1uKvRt-0000rS-2k;
Fri, 30 May 2025 08:50:45 +0000
Date: Fri, 30 May 2025 16:50:02 +0800
From: kernel test robot <lkp@xxxxxxxxx>
To: "Darrick J. Wong" <djwong@xxxxxxxxxx>
Cc: oe-kbuild-all@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
Christoph Hellwig <hch@xxxxxx>
Subject: include/linux/build_bug.h:78:41: error: static assertion failed:
"XFS: sizeof(struct xfs_attr_sf_entry) is wrong, expected 3"
Message-ID: <202505301636.6Ud1Yddh-lkp@xxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head: f66bc387efbee59978e076ce9bf123ac353b389c
commit: 13877bc79d81354c53e91f3c86ac0f7bafe3ba7b xfs: port ondisk structure checks from xfs/122 to the kernel
date: 7 months ago
config: arm-randconfig-2002-20250530 (https://download.01.org/0day-ci/archive/20250530/202505301636.6Ud1Yddh-lkp@xxxxxxxxx/config)
compiler: arm-linux-gnueabi-gcc (GCC) 7.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250530/202505301636.6Ud1Yddh-lkp@xxxxxxxxx/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@xxxxxxxxx>
| Closes: https://lore.kernel.org/oe-kbuild-all/202505301636.6Ud1Yddh-lkp@xxxxxxxxx/
All errors (new ones prefixed by >>):
In file included from include/linux/bitfield.h:10:0,
from include/linux/fortify-string.h:5,
from include/linux/string.h:390,
from include/linux/uuid.h:11,
from fs/xfs/xfs_linux.h:10,
from fs/xfs/xfs.h:26,
from fs/xfs/xfs_super.c:7:
fs/xfs/libxfs/xfs_ondisk.h: In function 'xfs_check_ondisk_structs':
>> include/linux/build_bug.h:78:41: error: static assertion failed: "XFS: sizeof(struct xfs_attr_sf_entry) is wrong, expected 3"
#define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
^
include/linux/build_bug.h:77:34: note: in expansion of macro '__static_assert'
#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
^~~~~~~~~~~~~~~
fs/xfs/libxfs/xfs_ondisk.h:10:2: note: in expansion of macro 'static_assert'
static_assert(sizeof(structname) == (size), \
^~~~~~~~~~~~~
fs/xfs/libxfs/xfs_ondisk.h:133:2: note: in expansion of macro 'XFS_CHECK_STRUCT_SIZE'
XFS_CHECK_STRUCT_SIZE(struct xfs_attr_sf_entry, 3);
^~~~~~~~~~~~~~~~~~~~~
>> include/linux/build_bug.h:78:41: error: static assertion failed: "XFS: sizeof(struct xfs_dir2_data_unused) is wrong, expected 6"
#define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
^
include/linux/build_bug.h:77:34: note: in expansion of macro '__static_assert'
#define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
^~~~~~~~~~~~~~~
fs/xfs/libxfs/xfs_ondisk.h:10:2: note: in expansion of macro 'static_assert'
static_assert(sizeof(structname) == (size), \
^~~~~~~~~~~~~
fs/xfs/libxfs/xfs_ondisk.h:136:2: note: in expansion of macro 'XFS_CHECK_STRUCT_SIZE'
XFS_CHECK_STRUCT_SIZE(struct xfs_dir2_data_unused, 6);
^~~~~~~~~~~~~~~~~~~~~
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS
Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n]
Selected by [m]:
- DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=m] && DRM_XE [=m] && DRM_XE [=m]=m [=m]
vim +78 include/linux/build_bug.h
bc6245e5efd70c Ian Abbott 2017-07-10 60
6bab69c65013be Rasmus Villemoes 2019-03-07 61 /**
6bab69c65013be Rasmus Villemoes 2019-03-07 62 * static_assert - check integer constant expression at build time
6bab69c65013be Rasmus Villemoes 2019-03-07 63 *
6bab69c65013be Rasmus Villemoes 2019-03-07 64 * static_assert() is a wrapper for the C11 _Static_assert, with a
6bab69c65013be Rasmus Villemoes 2019-03-07 65 * little macro magic to make the message optional (defaulting to the
6bab69c65013be Rasmus Villemoes 2019-03-07 66 * stringification of the tested expression).
6bab69c65013be Rasmus Villemoes 2019-03-07 67 *
6bab69c65013be Rasmus Villemoes 2019-03-07 68 * Contrary to BUILD_BUG_ON(), static_assert() can be used at global
6bab69c65013be Rasmus Villemoes 2019-03-07 69 * scope, but requires the expression to be an integer constant
6bab69c65013be Rasmus Villemoes 2019-03-07 70 * expression (i.e., it is not enough that __builtin_constant_p() is
6bab69c65013be Rasmus Villemoes 2019-03-07 71 * true for expr).
6bab69c65013be Rasmus Villemoes 2019-03-07 72 *
6bab69c65013be Rasmus Villemoes 2019-03-07 73 * Also note that BUILD_BUG_ON() fails the build if the condition is
6bab69c65013be Rasmus Villemoes 2019-03-07 74 * true, while static_assert() fails the build if the expression is
6bab69c65013be Rasmus Villemoes 2019-03-07 75 * false.
6bab69c65013be Rasmus Villemoes 2019-03-07 76 */
6bab69c65013be Rasmus Villemoes 2019-03-07 77 #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr)
6bab69c65013be Rasmus Villemoes 2019-03-07 @78 #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
6bab69c65013be Rasmus Villemoes 2019-03-07 79
07a368b3f55a79 Maxim Levitsky 2022-10-25 80
:::::: The code at line 78 was first introduced by commit
:::::: 6bab69c65013bed5fce9f101a64a84d0385b3946 build_bug.h: add wrapper for _Static_assert
:::::: TO: Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
:::::: CC: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Return-Path: <linux-kernel+bounces-667808-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 69E8A41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:53:02 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 3FFA6A23448
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:52:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 11A0021CA04;
Fri, 30 May 2025 08:52:54 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="CnJhLiHF"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
(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 8950F218ACA
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:52:51 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595173; cv=none; b=O7mCidti9KTWLX7r0jbMUD/1WTLR/5s8aAgAzFY1jHMmiDCJi76ml7e8TGDrYd8QDDPRzxjlcsF7lln2KVWUbixHTKWHft++bY34rvcPGJbVU+Igq6hk6VjCwqnNHCMxH2fw+NS+Sa/JoZMHtLif/dOB363xc0ySV/aBVCvkeoU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595173; c=relaxed/simple;
bh=tpdB7ZLl0UrgoAlMjYpi/+PImq3CiQZ8aEO4FTpWivY=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=q+tDI3PT1VebIOhv153hXWN/FkeBp+fnClcIFSTGOn5fRq3+lSQplnLqh738pgMNuoBkkVDxF8KAmivZyNFGDBfGgKOdxe09hbK6RwYinyU/I1Ia+dlxCP/TqioLLzLR7/wHY3dDYytuRJ1mJYp8PXWvbaSgUb4DYCnZhFmxhbA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=CnJhLiHF; arc=none smtp.client-ip=170.10.133.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748595170;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=RivONRZmKtb6PAY6opK1Hx8XQmxD64BeDivEpsAjyjY=;
b=CnJhLiHFYflyEJd+BzNJ14uURikdfKGsHLfavEE8/UGhh36czP48O5Yu0r5vV55ibSVO6m
EbJK6HslT5hz/PBkOxSva3VgHWrP0T8WwdHwIThL/8reNvYQInsQwRPRv095KvRC41cg35
gghkUBVFPENEpjL4bnZkAy+fH3scwuk=
Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com
[209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-260-tR9q6HzuMPWuMShlowdssA-1; Fri, 30 May 2025 04:52:48 -0400
X-MC-Unique: tR9q6HzuMPWuMShlowdssA-1
X-Mimecast-MFC-AGG-ID: tR9q6HzuMPWuMShlowdssA_1748595168
Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-450d64026baso4162705e9.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:52:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748595168; x=1749199968;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=RivONRZmKtb6PAY6opK1Hx8XQmxD64BeDivEpsAjyjY=;
b=ACsqYg8zrAHC7Z6GbZzBB6cB/OhW74t6FdYIq3KMj4FXNH9uv13i+3HoLgwLR+fWlb
NLLNzFGEnt1VXlXip9yi9d9uE6SGrhxbH87RsnAPIB84cIg6WdvImXy5Q7+K75uHPk1D
uoGqmBJsQujx8ry/gZAhx+LafZzd2Ruq0u2QlWGR7/FZN0VstJhejVjgF6jlZOAsX6Eu
BiG9qzn5TOhx72tO73RcX44NuDdAoSyueyvL67o16DzsH5zow1ERuZ4qmGMPWUR/V2ZG
iwEUI1S8c926HhXAIh07WyWQCq3Qj8iRaN/tdBqSmif8qTfpEJP4O3NV/sLDn/JuR6F6
XTng==
X-Forwarded-Encrypted: i=1; AJvYcCWsHC57a6lPBWgQu8xKF/KU8nZWm4K2Zd5Hvwr7eHmQNc1kTIy1n5k9Ypx8nuYetYI2W4YZDGOllOpdnz0=@vger.kernel.org
X-Gm-Message-State: AOJu0YwFh3NybmVkJ3sThc14g/8RMEsBGFxN0mL2iqDGdGbH7WLMQ9bQ
DdJ/YioHAC1vHa8nFXEKYugL4/H+ya+r2vc6CBMJYzrJsPf9h5hjzhRsOpZ+S13OD7bCxIrdv/C
HHeqWwkjqVk0ls/l9jOB0w7smusZZ3uaVwUVviFjKl+IdbpQpPcMh72Y3Y03EGvi4aw==
X-Gm-Gg: ASbGncuZ3djCTSHaUHzKVnZ3CFWNKV2XlPKJ93Ge7LW80S70HmIShf3suatG0iSkT+2
+/brxY5MQkuqLBM/qK42PzQHwTgn2gd/5lwpG+s79KZ+kxD0g02xjxVd08haRY/7U1Wl1ra/zas
dq/nSt7iDsQYY7d1CsOm/OzSP7nRF+KkpRpxWNEaKd2BUHe2ObkHvvZ7eJ7hyx0YDIjpbbszm6K
LPvC1JGXyO7kJTP06FBlHeB7oqgosqGI5djhlZmXtib7uacCFoabG1fpkSvnI9L/p7AbJJar46p
H7FqF5pQRoC3GoL8prOyaeK30iLSX+VtkRgwycNKOtfIfw5JJZ0nVPBVbba+9xVVQ9kbOXQ9645
Pcj3LhzjgpF0Ly6yrROUrq+//Cc4GPLs+maGVFvY=
X-Received: by 2002:a05:600c:6286:b0:43d:fa58:700e with SMTP id 5b1f17b1804b1-450d6575664mr21159905e9.33.1748595167727;
Fri, 30 May 2025 01:52:47 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFNUcZukq/uatUBDvfuZ25brMX/E4xbirUMnKjhUU3zzKOX10Q2xDv4lEjZQMcq3GuaUcnUNQ==
X-Received: by 2002:a05:600c:6286:b0:43d:fa58:700e with SMTP id 5b1f17b1804b1-450d6575664mr21159655e9.33.1748595167391;
Fri, 30 May 2025 01:52:47 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe5b96fsm4168233f8f.8.2025.05.30.01.52.46
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:52:46 -0700 (PDT)
Message-ID: <9c920642-228b-4eb0-920a-269473ea824e@xxxxxxxxxx>
Date: Fri, 30 May 2025 10:52:45 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
To: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
Cc: Ryan Roberts <ryan.roberts@xxxxxxx>,
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
<f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
<ade3bdb7-7103-4ecd-bce2-7768a0d729ef@lucifer.local>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <ade3bdb7-7103-4ecd-bce2-7768a0d729ef@lucifer.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 10:47, Lorenzo Stoakes wrote:
> On Fri, May 30, 2025 at 10:44:36AM +0200, David Hildenbrand wrote:
>> On 30.05.25 10:04, Ryan Roberts wrote:
>>> On 29/05/2025 09:23, Baolin Wang wrote:
>>>> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
>>>> the system-wide anon/shmem THP sysfs settings, which means that even though
>>>> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
>>>> attempt to collapse into a anon/shmem THP. This violates the rule we have
>>>> agreed upon: never means never. This patch set will address this issue.
>>>
>>> This is a drive-by comment from me without having the previous context, but...
>>>
>>> Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
>>> user-initiated, synchonous request to use huge pages for a range of memory.
>>> There is nothing *transparent* about it, it just happens to be implemented using
>>> the same logic that THP uses.
>>>
>>> I always thought this was a deliberate design decision.
>>
>> If the admin said "never", then why should a user be able to overwrite that?
>>
>> The design decision I recall is that if VM_NOHUGEPAGE is set, we'll ignore
>> that. Because that was set by the app itself (MADV_NOHUEPAGE).
>>
>
> I'm with David on this one.
>
> I think it's principal of least surprise - to me 'never' is pretty
> emphatic, and keep in mind the other choices are 'always' and... 'madvise'
> :) which explicitly is 'hey only do this if madvise tells you to'.
>
> I'd be rather surprised if I hadn't set madvise and a user uses madvise to
> in some fashion override the never.
>
> I mean I think we all agree this interface is to use a technical term -
> crap - and we need something a lot more fine-grained and smart, but I think
> given the situation we're in we should make it at least as least surprising
> as possible.
Yes. If you configure "never" you are supposed to suffer, consistently.
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667809-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 14B0A41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:54:13 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 19CB2A234D5
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:53:52 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id A655921CC64;
Fri, 30 May 2025 08:54:01 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ITvpNzTN"
Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173])
(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 0EA2921ADA2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:53:57 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.173
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595240; cv=none; b=eCU3bFt4c1LtWk38E2+lm6PpL7bu47RZtd/fBSbesMuf6tgxyzQJHMKGYifbKwF/feDIxZrDTK8nOHgg2GHhr8VPF2vP6ZjQUazhNIJkn4YacDAlBLYm5jMBU6yJexxTGA4sUFZQ1SZuntsCriFI0tIpRyp2xmUA35P1t29Gino=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595240; c=relaxed/simple;
bh=trVd84a33ivYKAJg9TE37WT5ARtue713nOBQM6WgbLs=;
h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
To:Cc:Content-Type; b=QV7/+Zu57VP4Aa+EYEtOeXeBq19lRHLbzGvQizpzUgHkliiM9XyQK8zw4lwi+r8L0g8cFWv9TGKBXVU2Ko2W6mlhl+1GSohgXbt71mozf8jA8jHuBonaMpiLr63xbD1xJgxdgoZzo3EMa46Q9UHSlzvwIuK2YIhRlzGgFv5X2qw=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=ITvpNzTN; arc=none smtp.client-ip=209.85.160.173
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com
Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-4774611d40bso197201cf.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:53:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20230601; t=1748595237; x=1749200037; darn=vger.kernel.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=z8u647ndNYzdA27OG8TNeuQiC3z4GVpVKrED4QXwYPU=;
b=ITvpNzTN8/Q4CtxRafoLinx+/KF6kS8u02MT2vw16dhtJpjjS1iQ39KS9+1TLfpul5
E/KbvmaDazMOkC68YhavXUDeK4m8LWKO5AH0NUQ5DDZ1kchh0k6wauZtImivv++jTsem
OYn7bGQAM0E4MN832r16WaIWdUtV8ubXNRJ97tjIKl4jzHBo91wF9E3Xf+TeGfunaWjI
ALGBP7OEoC3Hl8+0jMVX4+V1zMuRzBerablzATIcP4Te0piRx3Qe3WNbqIHWm1iOWoLE
n8x/w/0sM5XFe0xl3FAwC1+CPVrNO34jPaPz+urfaCxB+GJBrGJf+5ZHoSoQ6CWBD7uh
iolA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748595237; x=1749200037;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=z8u647ndNYzdA27OG8TNeuQiC3z4GVpVKrED4QXwYPU=;
b=RNuPbs/Xzm5QmQipE2KAvJTNZsIwjpTz8nNmnDze4oWw3vAn7x5jEPPBKPWQGRyTL8
gSCSCxywJUg4BkRks3zV1jsWUSBLIAj+3z55q3D3KsU8WP7edYH3dWj3tcjlyl/IivyR
KHINGa1GTUHduSQVwgedHFYaY0+rAo+yvq4qgx7QUXyfu34bUpxSc7AdeLiL3bEKEx/+
kVB0mMm8//WXFQKKmW4s/aFcbF4MafvIH8Yjpmmzphemh9zuk8fxovcDfvwUgtwqhk+O
d0uiv7Yu2zLQ7Ux6xnH5U2A2rvwbQN2ycKY1d9ssFLuMEX/9q0+YIvsrHbup9EObkUcI
2K1w==
X-Forwarded-Encrypted: i=1; AJvYcCXxdsTFF1FX0yeeMMl23GqGQKavhUdfYzPO23X54vyCixYprB0faLId81klhrtf+CcybPh9/2MVqYEQ0r8=@vger.kernel.org
X-Gm-Message-State: AOJu0YxKjHv2/WpvUe2LFUGshhNLXz2hhy6j02QZLNpc0PvmeKkk5KyI
5wy6CXDQby68krl4mbNZoKX0zIEwaUwWMWvptoNMOA0OJ376pgi32ocF+CyF+vh7nkQ/J5CP2TV
z+rAH/4Dt2w6tNVjOZVyiGxeuqC6OYARspYDpXPWs
X-Gm-Gg: ASbGncu3kKSHb1jNPnKRCT7irUKhQtHdZ77WPOx8+2HQQaaGy+hYFAJbahakSQoYtmE
mItiGnHikcLVngSMo/nI2jUxls5M+IFB8S/OhFwntAdOxF/T2dBYzCIz/GK9fUxEuTAPaSaNjlK
YMXf0VUr042B2uINnxVqWPCokflGzb3rA1nDSPHNF8NnM=
X-Google-Smtp-Source: AGHT+IFLqefnLn1v8keLkqAr4fPJAQHT//B+kwFb1ekkisV3CdeatG99dSsPZYAGw8By1B8I2vAaTr2y3/hbj85CkGA=
X-Received: by 2002:a05:622a:1a97:b0:494:b4dd:befd with SMTP id
d75a77b69052e-4a441022360mr2905721cf.8.1748595236277; Fri, 30 May 2025
01:53:56 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
References: <cover.1747264138.git.ackerleytng@xxxxxxxxxx> <b784326e9ccae6a08388f1bf39db70a2204bdc51.1747264138.git.ackerleytng@xxxxxxxxxx>
<aDU3eL7qQYrXkE3T@xxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <aDU3eL7qQYrXkE3T@xxxxxxxxxxxxxxxxxxxxxxxxx>
From: Fuad Tabba <tabba@xxxxxxxxxx>
Date: Fri, 30 May 2025 09:53:19 +0100
X-Gm-Features: AX0GCFtqJXvp3p__kKdA5QDGvH461bYPNLmsSSbQFbO1K64Y28pB97ucjguB0DU
Message-ID: <CA+EHjTxgO4LmdYY83a+uzBshvFf8EcJzY58Rovvz=pZgyO2yow@xxxxxxxxxxxxxx>
Subject: Re: [RFC PATCH v2 02/51] KVM: guest_memfd: Introduce and use
shareability to guard faulting
To: Yan Zhao <yan.y.zhao@xxxxxxxxx>
Cc: Ackerley Tng <ackerleytng@xxxxxxxxxx>, kvm@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx, linux-fsdevel@xxxxxxxxxxxxxxx,
aik@xxxxxxx, ajones@xxxxxxxxxxxxxxxx, akpm@xxxxxxxxxxxxxxxxxxxx,
amoorthy@xxxxxxxxxx, anthony.yznaga@xxxxxxxxxx, anup@xxxxxxxxxxxxxx,
aou@xxxxxxxxxxxxxxxxx, bfoster@xxxxxxxxxx, binbin.wu@xxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx, catalin.marinas@xxxxxxx, chao.p.peng@xxxxxxxxx,
chenhuacai@xxxxxxxxxx, dave.hansen@xxxxxxxxx, david@xxxxxxxxxx,
dmatlack@xxxxxxxxxx, dwmw@xxxxxxxxxxxx, erdemaktas@xxxxxxxxxx,
fan.du@xxxxxxxxx, fvdl@xxxxxxxxxx, graf@xxxxxxxxxx, haibo1.xu@xxxxxxxxx,
hch@xxxxxxxxxxxxx, hughd@xxxxxxxxxx, ira.weiny@xxxxxxxxx,
isaku.yamahata@xxxxxxxxx, jack@xxxxxxx, james.morse@xxxxxxx,
jarkko@xxxxxxxxxx, jgg@xxxxxxxx, jgowans@xxxxxxxxxx, jhubbard@xxxxxxxxxx,
jroedel@xxxxxxx, jthoughton@xxxxxxxxxx, jun.miao@xxxxxxxxx,
kai.huang@xxxxxxxxx, keirf@xxxxxxxxxx, kent.overstreet@xxxxxxxxx,
kirill.shutemov@xxxxxxxxx, liam.merwick@xxxxxxxxxx,
maciej.wieczor-retman@xxxxxxxxx, mail@xxxxxxxxxxxxxxxxxxxxx, maz@xxxxxxxxxx,
mic@xxxxxxxxxxx, michael.roth@xxxxxxx, mpe@xxxxxxxxxxxxxx,
muchun.song@xxxxxxxxx, nikunj@xxxxxxx, nsaenz@xxxxxxxxx,
oliver.upton@xxxxxxxxx, palmer@xxxxxxxxxxx, pankaj.gupta@xxxxxxx,
paul.walmsley@xxxxxxxxxx, pbonzini@xxxxxxxxxx, pdurrant@xxxxxxxxxxxx,
peterx@xxxxxxxxxx, pgonda@xxxxxxxxxx, pvorel@xxxxxxx, qperret@xxxxxxxxxx,
quic_cvanscha@xxxxxxxxxxx, quic_eberman@xxxxxxxxxxx,
quic_mnalajal@xxxxxxxxxxx, quic_pderrin@xxxxxxxxxxx, quic_pheragu@xxxxxxxxxxx,
quic_svaddagi@xxxxxxxxxxx, quic_tsoni@xxxxxxxxxxx, richard.weiyang@xxxxxxxxx,
rick.p.edgecombe@xxxxxxxxx, rientjes@xxxxxxxxxx, roypat@xxxxxxxxxxxx,
rppt@xxxxxxxxxx, seanjc@xxxxxxxxxx, shuah@xxxxxxxxxx, steven.price@xxxxxxx,
steven.sistare@xxxxxxxxxx, suzuki.poulose@xxxxxxx, thomas.lendacky@xxxxxxx,
usama.arif@xxxxxxxxxxxxx, vannapurve@xxxxxxxxxx, vbabka@xxxxxxx,
viro@xxxxxxxxxxxxxxxxxx, vkuznets@xxxxxxxxxx, wei.w.wang@xxxxxxxxx,
will@xxxxxxxxxx, willy@xxxxxxxxxxxxx, xiaoyao.li@xxxxxxxxx,
yilun.xu@xxxxxxxxx, yuzenghui@xxxxxxxxxx, zhiquan1.li@xxxxxxxxx
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-11.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hi,
.. snip..
> I noticed that in [1], the kvm_gmem_mmap() does not check the range.
> So, the WARN() here can be hit when userspace mmap() an area larger than the
> inode size and accesses the out of band HVA.
>
> Maybe limit the mmap() range?
>
> @@ -1609,6 +1620,10 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma)
> if (!kvm_gmem_supports_shared(file_inode(file)))
> return -ENODEV;
>
> + if (vma->vm_end - vma->vm_start + (vma->vm_pgoff << PAGE_SHIFT) > i_size_read(file_inode(file)))
> + return -EINVAL;
> +
> if ((vma->vm_flags & (VM_SHARED | VM_MAYSHARE)) !=
> (VM_SHARED | VM_MAYSHARE)) {
> return -EINVAL;
>
> [1] https://lore.kernel.org/all/20250513163438.3942405-8-tabba@xxxxxxxxxx/
I don't think we want to do that for a couple of reasons. We catch
such invalid accesses on faulting, and, by analogy, afaikt, neither
secretmem nor memfd perform a similar check on mmap (nor do
memory-mapped files in general).
There are also valid reasons why a user would want to deliberately
mmap more memory than the backing store, knowing that it's only going
to fault what it's going to use, e.g., alignment.
Cheers,
/fuad
> > + return xa_to_value(entry);
> > +}
> > +
> > +static struct folio *kvm_gmem_get_shared_folio(struct inode *inode, pgoff_t index)
> > +{
> > + if (kvm_gmem_shareability_get(inode, index) != SHAREABILITY_ALL)
> > + return ERR_PTR(-EACCES);
> > +
> > + return kvm_gmem_get_folio(inode, index);
> > +}
> > +
> > +#else
> > +
> > +static int kvm_gmem_shareability_setup(struct maple_tree *mt, loff_t size, u64 flags)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline struct folio *kvm_gmem_get_shared_folio(struct inode *inode, pgoff_t index)
> > +{
> > + WARN_ONCE("Unexpected call to get shared folio.")
> > + return NULL;
> > +}
> > +
> > +#endif /* CONFIG_KVM_GMEM_SHARED_MEM */
> > +
> > static int __kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slot,
> > pgoff_t index, struct folio *folio)
> > {
> > @@ -333,7 +404,7 @@ static vm_fault_t kvm_gmem_fault_shared(struct vm_fault *vmf)
> >
> > filemap_invalidate_lock_shared(inode->i_mapping);
> >
> > - folio = kvm_gmem_get_folio(inode, vmf->pgoff);
> > + folio = kvm_gmem_get_shared_folio(inode, vmf->pgoff);
> > if (IS_ERR(folio)) {
> > int err = PTR_ERR(folio);
> >
> > @@ -420,8 +491,33 @@ static struct file_operations kvm_gmem_fops = {
> > .fallocate = kvm_gmem_fallocate,
> > };
> >
> > +static void kvm_gmem_free_inode(struct inode *inode)
> > +{
> > + struct kvm_gmem_inode_private *private = kvm_gmem_private(inode);
> > +
> > + kfree(private);
> > +
> > + free_inode_nonrcu(inode);
> > +}
> > +
> > +static void kvm_gmem_destroy_inode(struct inode *inode)
> > +{
> > + struct kvm_gmem_inode_private *private = kvm_gmem_private(inode);
> > +
> > +#ifdef CONFIG_KVM_GMEM_SHARED_MEM
> > + /*
> > + * mtree_destroy() can't be used within rcu callback, hence can't be
> > + * done in ->free_inode().
> > + */
> > + if (private)
> > + mtree_destroy(&private->shareability);
> > +#endif
> > +}
> > +
> > static const struct super_operations kvm_gmem_super_operations = {
> > .statfs = simple_statfs,
> > + .destroy_inode = kvm_gmem_destroy_inode,
> > + .free_inode = kvm_gmem_free_inode,
> > };
> >
> > static int kvm_gmem_init_fs_context(struct fs_context *fc)
> > @@ -549,12 +645,26 @@ static const struct inode_operations kvm_gmem_iops = {
> > static struct inode *kvm_gmem_inode_make_secure_inode(const char *name,
> > loff_t size, u64 flags)
> > {
> > + struct kvm_gmem_inode_private *private;
> > struct inode *inode;
> > + int err;
> >
> > inode = alloc_anon_secure_inode(kvm_gmem_mnt->mnt_sb, name);
> > if (IS_ERR(inode))
> > return inode;
> >
> > + err = -ENOMEM;
> > + private = kzalloc(sizeof(*private), GFP_KERNEL);
> > + if (!private)
> > + goto out;
> > +
> > + mt_init(&private->shareability);
> Wrap the mt_init() inside "#ifdef CONFIG_KVM_GMEM_SHARED_MEM" ?
>
> > + inode->i_mapping->i_private_data = private;
> > +
> > + err = kvm_gmem_shareability_setup(private, size, flags);
> > + if (err)
> > + goto out;
> > +
> > inode->i_private = (void *)(unsigned long)flags;
> > inode->i_op = &kvm_gmem_iops;
> > inode->i_mapping->a_ops = &kvm_gmem_aops;
> > @@ -566,6 +676,11 @@ static struct inode *kvm_gmem_inode_make_secure_inode(const char *name,
> > WARN_ON_ONCE(!mapping_unevictable(inode->i_mapping));
> >
> > return inode;
> > +
> > +out:
> > + iput(inode);
> > +
> > + return ERR_PTR(err);
> > }
> >
> > static struct file *kvm_gmem_inode_create_getfile(void *priv, loff_t size,
> > @@ -654,6 +769,9 @@ int kvm_gmem_create(struct kvm *kvm, struct kvm_create_guest_memfd *args)
> > if (kvm_arch_vm_supports_gmem_shared_mem(kvm))
> > valid_flags |= GUEST_MEMFD_FLAG_SUPPORT_SHARED;
> >
> > + if (flags & GUEST_MEMFD_FLAG_SUPPORT_SHARED)
> > + valid_flags |= GUEST_MEMFD_FLAG_INIT_PRIVATE;
> > +
> > if (flags & ~valid_flags)
> > return -EINVAL;
> >
> > @@ -842,6 +960,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> > if (!file)
> > return -EFAULT;
> >
> > + filemap_invalidate_lock_shared(file_inode(file)->i_mapping);
> > +
> > folio = __kvm_gmem_get_pfn(file, slot, index, pfn, &is_prepared, max_order);
> > if (IS_ERR(folio)) {
> > r = PTR_ERR(folio);
> > @@ -857,8 +977,8 @@ int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> > *page = folio_file_page(folio, index);
> > else
> > folio_put(folio);
> > -
> > out:
> > + filemap_invalidate_unlock_shared(file_inode(file)->i_mapping);
> > fput(file);
> > return r;
> > }
> > --
> > 2.49.0.1045.g170613ef41-goog
> >
> >
Return-Path: <linux-kernel+bounces-667810-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 913CF41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:56:26 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 80164A2352E
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:56:05 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 5119A21C182;
Fri, 30 May 2025 08:56:20 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="x/ONuqt7"
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42])
(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 456E0218ACA
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:56:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595379; cv=none; b=Fexb4m3Mh3igwEssLNxA5Kce8Jht+QOCHilfN3JqV8aAU07NFczC/HFnhgF2oBvJLgbcOCd2T7Jss8RGc/qWJElsSb1pOi5iilxoBcNfWoMNopsj0YAbV7lZHkh0rDgffhKdq9A/lEM+30gk5mKdCYWQp2hFV/Y9wKbEcnUnrdc=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595379; c=relaxed/simple;
bh=UWE2jdlEzI9YD+Dg6NIoCE8U1hSoBC3xQFtAghveJv4=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=G0saVSxlla8jaEHi1POgADSdDHC1HRh+9EtxC7uXfGi2xbolu3KJaQUFSwpuI/FClZsynog1MRhDlN4K3CqDOwcpFevae70h+kFker6FsgzbUgpwhrJI09476/gFfn0pdMotA1n3XRkVUU8R4GILlPF6A+IFHZjtzvE2i5JiYRk=
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=x/ONuqt7; arc=none smtp.client-ip=209.85.221.42
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-wr1-f42.google.com with SMTP id ffacd0b85a97d-3a36f26584bso988639f8f.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 01:56:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1748595375; x=1749200175; darn=vger.kernel.org;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:from:to:cc:subject:date:message-id:reply-to;
bh=sSnECUFkt1/JvJRDNh/81S1RiOSnxf9TGj9i5tAOdx8=;
b=x/ONuqt7Fj2rWWivm6D3uMSQdssDP6CWdUEEvRsnxY7iO6r1O5rZCLPXUo2K3e3+dz
p+cd11CNgXYJ5y/04LEfJWQOayt4JlYiTIhSeUjd8qSPfkGZHRuy+93Y9D0rkF0/1yCa
AgsBlE3twDA/+C6qyFVr0+9zc6r6RP+MztYFdA+1sIBlVJNr/NoX/SNtjVzodiKkZGRI
N+VIVpchr+Heh7bHLgqiqBfl77B+bIx2/4cmuB6hIQ099ODqmWslonr5xMxBRThK2XG2
2qBMGPUBCVS7q7Fv/oTKvwhFXDBKyIRKK+6gJLmiG0NiCH3rbBFKNc3feKx80GfvCgB/
tkbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748595375; x=1749200175;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=sSnECUFkt1/JvJRDNh/81S1RiOSnxf9TGj9i5tAOdx8=;
b=u9ODKCmeKaAnYDhYN6zTwrZXsLZUPMhhVIv8pOG051RmDJBZLH1rNErS1KhBHwI3wC
0+4hLCQrLbiA7TNvWfUTBpiDh4z6sMx8tIM3NwkqwRDZjAC+flm79I9WGrTTJGBwGrG4
fEmB12ibNT3ihEBtyz4uSGqW4rSmuh+C7D/WyX/Z2qZYE7btJkKIY0kQyPmwSqmNMbmC
q8wuwla0ffpOK85QBwGIObxdrL4rLzXgm708NzTWEM4l62htQRbvQwgm12cfXhv9s/yR
YmuUuSVVKtgkXw62a+vFTpkxNyFNPkpRlNFGq6Aug+cIxpC068fUHMLKRAmBQA5hE/XB
cCxg==
X-Forwarded-Encrypted: i=1; AJvYcCXsIFiGVRFaZcYB18Ne3sk1acPreuXKM/cwCflq0L2Cnq3W3LfSNocWZKHcVAdg65LVi8KDwHB+A0Y4GlY=@vger.kernel.org
X-Gm-Message-State: AOJu0YxQJ9mCOCxZXnb+pozfVGe4JWkvVgbUZyEbINOoFI142ObVU29N
nBrNUAWR+BnqHzCBFg2qlMMi77caRQHeNWxtxggSjczne58hiFuVkijT2Lm+UkJQKOk=
X-Gm-Gg: ASbGnctYJ/cQkp5O3B/JJjTZZDYUpV04qm2+C1jEred6D69kenKj2GY3cX0oRCUAwKo
elNTzQrKBvXnLJc9hI/qnx6kDlZqGEoAs4Es/X/cMDeNtN1w6Z+4uHDCsMd2muCY35ChcWSOCBb
TqGxZIYT1NBlwvmHOzqMqLq9eJpfHxJfsTMQU7WydZF2Fqh1H0yuydwGXMo+LAjFewGZCGFl1oH
VsZ9d5DdOU9uJbcOQUMVVXf0K/WrNyp7TA4tAfJ1YFaZhREvtKQlknktYy9OUD25VGAM5SglsZY
Qw70wtPVkK/JR016HusBtE/lSnfbdWUBAAluLw8/rtpvR5RRhmuRlUY/OWNHi6q6c6Zy4arzK3s
gS+Vx8mf0shCztnQP
X-Google-Smtp-Source: AGHT+IEdTEPwz3I3fiIOCvTUuIwyDXev7/ivsylgXDu6Xsiav4J6EpqE94XmbzdMFCw668axV924fg==
X-Received: by 2002:a05:6000:1a8a:b0:3a4:dfc2:b9e1 with SMTP id ffacd0b85a97d-3a4f89a7e71mr1193613f8f.2.1748595375484;
Fri, 30 May 2025 01:56:15 -0700 (PDT)
Received: from [192.168.0.35] (188-141-3-146.dynamic.upc.ie. [188.141.3.146])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f00a0a96sm4271388f8f.96.2025.05.30.01.56.14
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:56:15 -0700 (PDT)
Message-ID: <68c54d56-3e44-4f43-8bd6-f6b7fa1f379b@xxxxxxxxxx>
Date: Fri, 30 May 2025 09:56:13 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/2] mtd: nand: qpic_common: prevent out of bounds
access of BAM arrays
To: Gabor Juhos <j4g8y7@xxxxxxxxx>, Mark Brown <broonie@xxxxxxxxxx>,
Md Sadre Alam <quic_mdalam@xxxxxxxxxxx>,
Varadarajan Narayanan <quic_varada@xxxxxxxxxxx>,
Sricharan Ramabadhran <quic_srichara@xxxxxxxxxxx>,
Miquel Raynal <miquel.raynal@xxxxxxxxxxx>,
Richard Weinberger <richard@xxxxxx>, Vignesh Raghavendra <vigneshr@xxxxxx>
Cc: linux-spi@xxxxxxxxxxxxxxx, linux-mtd@xxxxxxxxxxxxxxxxxxx,
linux-arm-msm@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
Lakshmi Sowjanya D <quic_laksd@xxxxxxxxxxx>
References: <20250529-qpic-snand-avoid-mem-corruption-v2-0-2f0d13afc7d2@xxxxxxxxx>
<KuueBg3qliXMt9QN9kV_5_on2xJV-BEWZAsktO_Ce-Fq1iBAPCFypbYUVZxlV4LjF0AUZG57KqiXZZ3uefQrXw==@protonmail.internalid>
<20250529-qpic-snand-avoid-mem-corruption-v2-2-2f0d13afc7d2@xxxxxxxxx>
Content-Language: en-US
From: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
In-Reply-To: <20250529-qpic-snand-avoid-mem-corruption-v2-2-2f0d13afc7d2@xxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 29/05/2025 18:25, Gabor Juhos wrote:
> The common QPIC code does not do any boundary checking when it handles
> the command elements and scatter gater list arrays of a BAM transaction,
> thus it allows to access out of bounds elements in those.
>
> Although it is the responsibility of the given driver to allocate enough
> space for all possible BAM transaction variations, however there can be
> mistakes in the driver code which can lead to hidden memory corruption
> issues which are hard to debug.
>
> This kind of problem has been observed during testing the 'spi-qpic-snand'
> driver. Although the driver has been fixed with a preceding patch, but it
> still makes sense to reduce the chance of having such errors again later.
>
> In order to prevent such errors, change the qcom_alloc_bam_transaction()
> function to store the number of elements of the arrays in the
> 'bam_transaction' strucutre during allocation. Also, add sanity checks to
> the qcom_prep_bam_dma_desc_{cmd,data}() functions to avoid using out of
> bounds indices for the arrays.
>
> Tested-by: Lakshmi Sowjanya D <quic_laksd@xxxxxxxxxxx> # on SDX75
> Signed-off-by: Gabor Juhos <j4g8y7@xxxxxxxxx>
> ---
> Changes in v2:
> - remove the inline qcom_err_bam_array_full() function and print the error
> messages directly from the respective functions instead
> - add 'Tested-by' tag from Lakshmi Sowjanya D, and remove the
> "Tested with the 'spi-qpic-snand' driver only." line from the
> commit message as SDX75 uses the qcom_nandc driver
> - move the note about of the preferred merging order into the cover letter
> ---
> drivers/mtd/nand/qpic_common.c | 30 ++++++++++++++++++++++++++----
> include/linux/mtd/nand-qpic-common.h | 8 ++++++++
> 2 files changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/nand/qpic_common.c b/drivers/mtd/nand/qpic_common.c
> index e0ed25b5afea9b289b767cd3d9c2d7572ed52008..30f17d959300cc7448d0c2e9e2516c52655494f0 100644
> --- a/drivers/mtd/nand/qpic_common.c
> +++ b/drivers/mtd/nand/qpic_common.c
> @@ -57,14 +57,15 @@ qcom_alloc_bam_transaction(struct qcom_nand_controller *nandc)
> bam_txn_buf += sizeof(*bam_txn);
>
> bam_txn->bam_ce = bam_txn_buf;
> - bam_txn_buf +=
> - sizeof(*bam_txn->bam_ce) * QPIC_PER_CW_CMD_ELEMENTS * num_cw;
> + bam_txn->bam_ce_nitems = QPIC_PER_CW_CMD_ELEMENTS * num_cw;
> + bam_txn_buf += sizeof(*bam_txn->bam_ce) * bam_txn->bam_ce_nitems;
>
> bam_txn->cmd_sgl = bam_txn_buf;
> - bam_txn_buf +=
> - sizeof(*bam_txn->cmd_sgl) * QPIC_PER_CW_CMD_SGL * num_cw;
> + bam_txn->cmd_sgl_nitems = QPIC_PER_CW_CMD_SGL * num_cw;
> + bam_txn_buf += sizeof(*bam_txn->cmd_sgl) * bam_txn->cmd_sgl_nitems;
>
> bam_txn->data_sgl = bam_txn_buf;
> + bam_txn->data_sgl_nitems = QPIC_PER_CW_DATA_SGL * num_cw;
>
> init_completion(&bam_txn->txn_done);
>
> @@ -237,6 +238,11 @@ int qcom_prep_bam_dma_desc_cmd(struct qcom_nand_controller *nandc, bool read,
> struct bam_cmd_element *bam_ce_buffer;
> struct bam_transaction *bam_txn = nandc->bam_txn;
>
> + if (bam_txn->bam_ce_pos + size > bam_txn->bam_ce_nitems) {
> + dev_err(nandc->dev, "BAM %s array is full\n", "CE");
> + return -EINVAL;
> + }
> +
> bam_ce_buffer = &bam_txn->bam_ce[bam_txn->bam_ce_pos];
>
> /* fill the command desc */
> @@ -258,6 +264,12 @@ int qcom_prep_bam_dma_desc_cmd(struct qcom_nand_controller *nandc, bool read,
>
> /* use the separate sgl after this command */
> if (flags & NAND_BAM_NEXT_SGL) {
> + if (bam_txn->cmd_sgl_pos >= bam_txn->cmd_sgl_nitems) {
> + dev_err(nandc->dev, "BAM %s array is full\n",
> + "CMD sgl");
> + return -EINVAL;
> + }
> +
> bam_ce_buffer = &bam_txn->bam_ce[bam_txn->bam_ce_start];
> bam_ce_size = (bam_txn->bam_ce_pos -
> bam_txn->bam_ce_start) *
> @@ -297,10 +309,20 @@ int qcom_prep_bam_dma_desc_data(struct qcom_nand_controller *nandc, bool read,
> struct bam_transaction *bam_txn = nandc->bam_txn;
>
> if (read) {
> + if (bam_txn->rx_sgl_pos >= bam_txn->data_sgl_nitems) {
> + dev_err(nandc->dev, "BAM %s array is full\n", "RX sgl");
> + return -EINVAL;
> + }
> +
> sg_set_buf(&bam_txn->data_sgl[bam_txn->rx_sgl_pos],
> vaddr, size);
> bam_txn->rx_sgl_pos++;
> } else {
> + if (bam_txn->tx_sgl_pos >= bam_txn->data_sgl_nitems) {
> + dev_err(nandc->dev, "BAM %s array is full\n", "TX sgl");
> + return -EINVAL;
> + }
> +
> sg_set_buf(&bam_txn->data_sgl[bam_txn->tx_sgl_pos],
> vaddr, size);
> bam_txn->tx_sgl_pos++;
> diff --git a/include/linux/mtd/nand-qpic-common.h b/include/linux/mtd/nand-qpic-common.h
> index cd7172e6c1bbffeee0363a14044980a72ea17723..3ca4073a496b8fd2a99112a9caefd3f110260568 100644
> --- a/include/linux/mtd/nand-qpic-common.h
> +++ b/include/linux/mtd/nand-qpic-common.h
> @@ -240,6 +240,9 @@
> * @last_data_desc - last DMA desc in data channel (tx/rx).
> * @last_cmd_desc - last DMA desc in command channel.
> * @txn_done - completion for NAND transfer.
> + * @bam_ce_nitems - the number of elements in the @bam_ce array
> + * @cmd_sgl_nitems - the number of elements in the @cmd_sgl array
> + * @data_sgl_nitems - the number of elements in the @data_sgl array
> * @bam_ce_pos - the index in bam_ce which is available for next sgl
> * @bam_ce_start - the index in bam_ce which marks the start position ce
> * for current sgl. It will be used for size calculation
> @@ -258,6 +261,11 @@ struct bam_transaction {
> struct dma_async_tx_descriptor *last_data_desc;
> struct dma_async_tx_descriptor *last_cmd_desc;
> struct completion txn_done;
> +
> + unsigned int bam_ce_nitems;
> + unsigned int cmd_sgl_nitems;
> + unsigned int data_sgl_nitems;
> +
> struct_group(bam_positions,
> u32 bam_ce_pos;
> u32 bam_ce_start;
>
> --
> 2.49.0
>
>
This one doesn't apply to -next
deckard
{~/Development/worktree/reviews/linux-next-25-05-30-daily-reviews}±(linux-next-25-05-30-daily-reviews);
greetings, earthling [1.052Mb]$ â?? b4 shazam
20250529-qpic-snand-avoid-mem-corruption-v2-0-2f0d13afc7d2@gm
Grabbing thread from
lore.kernel.org/all/20250529-qpic-snand-avoid-mem-corruption-v2-0-2f0d13afc7d2@xxxxxxxxx/t.mbox.gz
Checking for newer revisions
Grabbing search results from lore.kernel.org
Analyzing 3 messages in the thread
Analyzing 12 code-review messages
Checking attestation on all messages, may take a moment...
---
â?? [PATCH v2 1/2] spi: spi-qpic-snand: reallocate BAM transactions
â?? [PATCH v2 2/2] mtd: nand: qpic_common: prevent out of bounds access
of BAM arrays
---
â?? Signed: DKIM/gmail.com
---
Total patches: 2
---
Base: using specified base-commit b00d6864a4c948529dc6ddd2df76bf175bf27c63
Applying: spi: spi-qpic-snand: reallocate BAM transactions
Applying: mtd: nand: qpic_common: prevent out of bounds access of BAM arrays
Patch failed at 0002 mtd: nand: qpic_common: prevent out of bounds
access of BAM arrays
error: patch failed: drivers/mtd/nand/qpic_common.c:237
error: drivers/mtd/nand/qpic_common.c: patch does not apply
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am
--abort".
hint: Disable this message with "git config set advice.mergeConflict false"
deckard
{~/Development/worktree/reviews/linux-next-25-05-30-daily-reviews}±(linux-next-25-05-30-daily-reviews);
greetings, earthling [1.052Mb]$ â?? git-log-graph
* 4ae57ce867d8f - (HEAD -> linux-next-25-05-30-daily-reviews) spi:
spi-qpic-snand: reallocate BAM transactions (8 seconds ago)
Return-Path: <linux-kernel+bounces-667811-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id A845941E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 04:59:55 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id A4BCD7A55A9
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 08:58:36 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id EF84B21C9FE;
Fri, 30 May 2025 08:59:45 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 0F9D11D9663;
Fri, 30 May 2025 08:59:43 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595585; cv=none; b=TnDEbHb2TC9OCw0ICxj3km0LldfPJ3lzYy9LgnHBVpp+zhucMiTCa9EiODiskSJ87kvlrsY83PUz05xgpuEWmv1s+BMnKN64m5tnn7zU1FHMdKjaHfRCUXxE4EBkvAE9zOye1ZKqczFMWGj0gh6H4HI8mT4aO+9QdgHQTv6KSy8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595585; c=relaxed/simple;
bh=RaQLPUUg+ZvY1aIfMu6PF0lA/P8xLcjONkdn20WRZpw=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=FyFFOE6/a9/C3nLHM4GzDRhthkWLKkRsY068/2EQVbQ3P192Tlxy9pNjN3+CgpkKToiDQkOSih6uMA1aR/vjxELPcQ38OoAoh79ahQKy41KL0yNr+J1KTVlUJ6epSqKnZO4q9hNA1HJei75+yWjnDKIJvD7DBm5/oR+92Fz+IWQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EBDC616F2;
Fri, 30 May 2025 01:59:26 -0700 (PDT)
Received: from [10.57.95.14] (unknown [10.57.95.14])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8351C3F5A1;
Fri, 30 May 2025 01:59:41 -0700 (PDT)
Message-ID: <9b1bac6c-fd9f-4dc1-8c94-c4da0cbb9e7f@xxxxxxx>
Date: Fri, 30 May 2025 09:59:39 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
Content-Language: en-GB
To: David Hildenbrand <david@xxxxxxxxxx>,
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
<f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
From: Ryan Roberts <ryan.roberts@xxxxxxx>
In-Reply-To: <f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30/05/2025 09:44, David Hildenbrand wrote:
> On 30.05.25 10:04, Ryan Roberts wrote:
>> On 29/05/2025 09:23, Baolin Wang wrote:
>>> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
>>> the system-wide anon/shmem THP sysfs settings, which means that even though
>>> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
>>> attempt to collapse into a anon/shmem THP. This violates the rule we have
>>> agreed upon: never means never. This patch set will address this issue.
>>
>> This is a drive-by comment from me without having the previous context, but...
>>
>> Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
>> user-initiated, synchonous request to use huge pages for a range of memory.
>> There is nothing *transparent* about it, it just happens to be implemented using
>> the same logic that THP uses.
>>
>> I always thought this was a deliberate design decision.
>
> If the admin said "never", then why should a user be able to overwrite that?
Well my interpretation would be that the admin is saying never *transparently*
give anyone any hugepages; on balance it does more harm than good for my
workloads. The toggle is called transparent_hugepage/enabled, after all.
Whereas MADV_COLLAPSE is deliberately applied to a specific region at an
opportune moment in time, presumably because the user knows that the region
*will* benefit and because that point in the execution is not sensitive to latency.
I see them as logically separate.
>
> The design decision I recall is that if VM_NOHUGEPAGE is set, we'll ignore that.
> Because that was set by the app itself (MADV_NOHUEPAGE).
Hmm, ok. My instinct would have been the opposite; MADV_NOHUGEPAGE means "I
don't want the risk of latency spikes and memory bloat that THP can cause". Not
"ignore my explicit requests to MADV_COLLAPSE".
But if that descision was already taken and that's the current behavior then I
agree we have an inconsistency with respect to the sysfs control.
Perhaps we should be guided by real world usage - AIUI there is a cloud that
disables THP at system level today (Google?). Is there any concern that there
are workloads in such environments that are using MADV_COLLAPSE today that would
then see a performance drop?
Return-Path: <linux-kernel+bounces-667812-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id C2DED41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:00:46 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 776E1A24CF3
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:00:24 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 7959E221F0F;
Fri, 30 May 2025 09:00:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jt5gQHGa"
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 7AC1C1F03D4;
Fri, 30 May 2025 09:00:09 +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=1748595609; cv=none; b=E0qged8domkxOVCveQtHkybv0CAj5IGiSBMxbKH4Nx9NzEUITpDj0SXPZkqd7Wg8bKy77m9R7b40HQn6QynOcJfPiDAUg+rH7AgwmPXsKJlYlWljg21vCFLjgCA8E0N6gpNXVs2WSSbquNlzmwyUkdBcwcfXegcrJVHxNlZ5qOA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595609; c=relaxed/simple;
bh=lo6cRx9o+drjhg7VDcWUgYxFCl5gvqd6ftI3ofIqaGo=;
h=From:Subject:Date:Message-Id:MIME-Version:Content-Type:To:Cc; b=m6i7vQTjk8iZNoJPdaMtvVktNqj/A37ldYyX+bDSfq2OdCgsJL89cHEtBSIVtyTfeIHvANVKcT8vUhGs8R0kC1NeI9XuQRxw97j4IkWmUwUm/C1jQM3Dbk24/YXaN8HKXaZziHUixznvIXtfmBo1E6AQcJ2NIc+rS8syQGFXUic=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jt5gQHGa; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPS id E7B6EC4CEE9;
Fri, 30 May 2025 09:00:08 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748595609;
bh=lo6cRx9o+drjhg7VDcWUgYxFCl5gvqd6ftI3ofIqaGo=;
h=From:Subject:Date:To:Cc:Reply-To:From;
b=jt5gQHGaXBbQi/9RGf3H/STesPZDyri1NAA5cXOsHHIrrrqahpQWG3HtkPBnSU7M9
1+5VhX1UJPknpwWMGYRCe6jKoeCq73J3CGZZfkcAJa2z3yffp58GK1pb225RU6lsJH
2sb20xI3uo0eILgJQiMoBg+J3w/7AZ0I5DcE012pgRwg6fJXLIkPU6gLORin5pvaot
57LRvVYfrNLXqBhpmtYfN6KwPNPnb94W4pwS7tZsfmy0YAS9b3ixnmepS3lCQ+U7dl
M3Alo09OfUHcf98ZlXZXEKO5sH5FPkiL3CqlrAGN/PG24S97nQtWiV6zU/1Dz3JJLj
lg6zHmhKLDzuA==
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1])
by smtp.lore.kernel.org (Postfix) with ESMTP id DAFE0C5B552;
Fri, 30 May 2025 09:00:08 +0000 (UTC)
From: Vincent Knecht via B4 Relay <devnull+vincent.knecht.mailoo.org@xxxxxxxxxx>
Subject: [PATCH v3 0/4] CAMSS support for MSM8939
Date: Fri, 30 May 2025 11:00:03 +0200
Message-Id: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-B4-Tracking: v=1; b=H4sIAJNzOWgC/2XNTQ7CIBCG4as0rMUAdWhx5T2MC+SnncQWA4bUN
L27tHGh6fL9knlmJslFdImcq5lElzFhGEvUh4qYXo+do2hLE8EEMOANNXpIibZTrWi+o6eqAe+
h5YqrlpSrZ3Qep0283kr3mF4hvrcHma/r1xJsZ2VOGdVcGCsZk9qry6DxEcIxxI6sWBa/AOwBU
QBpawsGtD+B/AOWZfkA7xH++vAAAAA=
X-Change-ID: 20250517-camss-8x39-vbif-975ff5819198
To: Robert Foss <rfoss@xxxxxxxxxx>, Todor Tomov <todor.too@xxxxxxxxx>,
Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>,
Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>, Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-media@xxxxxxxxxxxxxxx,
linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
=?utf-8?q?Andr=C3=A9_Apitzsch?= <git@xxxxxxxxxxx>,
phone-devel@xxxxxxxxxxxxxxx, ~postmarketos/upstreaming@xxxxxxxxxxx,
Vincent Knecht <vincent.knecht@xxxxxxxxxx>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1748595607; l=3197;
i=vincent.knecht@xxxxxxxxxx; s=20250414; h=from:subject:message-id;
bh=lo6cRx9o+drjhg7VDcWUgYxFCl5gvqd6ftI3ofIqaGo=;
b=2X3nAXxC8dgDav+pjFV0VCY7vdzHiuDugWFeHPbY2DgmfB9LSI8gdoKUNb3qsZVgFxqhKThwg
U6UJ6gCc4WvDHphyHfTrmcYpV0wYiyI/4yNqtGFbleHytxoqh3jlTfs
X-Developer-Key: i=vincent.knecht@xxxxxxxxxx; a=ed25519;
pk=MFCVQkhL3+d3NHDzNPWpyZ4isxJvT+QTqValj5gSkm4=
X-Endpoint-Received: by B4 Relay for vincent.knecht@xxxxxxxxxx/20250414
with auth_id=377
X-Original-From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Reply-To: vincent.knecht@xxxxxxxxxx
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
This series adds CAMSS support for MSM8939.
It's mostly identical to MSM8916, except for some clocks
and an additional CSI.
To fix black stripes across sensor output, and garbage in
CSID TPG output, 2 VFE VBIF register settings are needed.
So the 1st patch adds helper functions to do just that.
Patch 1: adds helper for VFE VBIF settings
Patch 2: adds CAMSS_8x39 version in CAMSS driver
Patch 3: documents qcom,msm8939-camss DT bindings
Patch 4: adds camss and cci in msm8939.dtsi
Signed-off-by: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
---
Changes in v3:
- Patch 1:
- Use braces around multiline (Bryan)
- Rename vfe_vbif_reg_write to vfe_vbif_write_reg (Bryan)
- Get rid of switch block on CAMSS version (Bryan)
- Patch 2:
- Get rid of switch block on CAMSS version (Bryan)
- Patch 3: no change
- Patch 4: no change
- Tried to get rid of CCI camss_ahb but this resulted in device
freeze+reboot (Konrad)
- Link to v2: https://lore.kernel.org/r/20250525-camss-8x39-vbif-v2-0-6d3d5c5af456@xxxxxxxxxx
Changes in v2:
- Patch 1:
- Fix devm_platform_ioremap_resource_byname line to not end with
opening parenthesis (media-ci/1-checkpatch)
- Move camss-vfe-4-1.c handling of VBIF previously in patch 2 here
(Dmitry)
- Patch 2:
- Declare regulators in PHY entries, not CSID ones (Bryan)
- Patch 3: (bindings)
- Fix bindings checks for new errors (Rob)
- Fix properties ordering, code-style and example (Krzysztof)
- Sort reg-names, clock-names and interrupt-names alphanumerically (Bryan)
- Patch 4: (dtsi)
- Move #address/#size cells before status (Konrad)
- Aligned CCI with msm8916, thus removing ispif_ahb mention (Konrad)
If "camss_ahb should be unnecessary", it's still required by qcom,i2c-cci.yaml
- Link to v1: https://lore.kernel.org/r/20250520-camss-8x39-vbif-v1-0-a12cd6006af9@xxxxxxxxxx
---
Vincent Knecht (4):
media: qcom: camss: vfe: Add VBIF setting support
media: qcom: camss: Add support for MSM8939
media: dt-bindings: Add qcom,msm8939-camss
arm64: dts: qcom: msm8939: Add camss and cci
.../bindings/media/qcom,msm8939-camss.yaml | 253 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi | 4 +
arch/arm64/boot/dts/qcom/msm8939.dtsi | 146 ++++++++++++
drivers/media/platform/qcom/camss/Makefile | 1 +
drivers/media/platform/qcom/camss/camss-csiphy.c | 1 +
drivers/media/platform/qcom/camss/camss-ispif.c | 8 +-
drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 12 +
drivers/media/platform/qcom/camss/camss-vfe-vbif.c | 31 +++
drivers/media/platform/qcom/camss/camss-vfe-vbif.h | 19 ++
drivers/media/platform/qcom/camss/camss-vfe.c | 10 +
drivers/media/platform/qcom/camss/camss-vfe.h | 3 +
drivers/media/platform/qcom/camss/camss.c | 157 +++++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
13 files changed, 644 insertions(+), 2 deletions(-)
---
base-commit: 8566fc3b96539e3235909d6bdda198e1282beaed
change-id: 20250517-camss-8x39-vbif-975ff5819198
Best regards,
--
Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Return-Path: <linux-kernel+bounces-667813-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id BF88F41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:00:49 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 749E0A24DB6
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:00:27 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8F923221F32;
Fri, 30 May 2025 09:00:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Sjf1okOU"
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 7AC7921859A;
Fri, 30 May 2025 09:00:09 +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=1748595609; cv=none; b=aFBObrBkVN4S1YFWc5nilGCku0oHhGm0IhlcQ+00K5uPqxefcolt9WDDq5MofL9CXEyhggMOTsk7uJFlC/rVenTIJH12Mw+OxqK3OH1FkaDDsjA3uwGZDvSvWwCx8dSxzrmN6QVhyEs/NAxgwDrlibo5vxFsvwnbi0xubTIfsfo=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595609; c=relaxed/simple;
bh=iEvbOuzqN5R0DIK0mtzXnwU4mwyKC2zLReYlN5bVtG8=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
In-Reply-To:To:Cc; b=Ed7+Vvr0kaSXAyIjL7hudw2niuckfjH6/cETd7AebHwW952u33DtmKG31b9/WsNdTbzs9DES80SPvT+ZeG0CNzvR/vtQ6j+H8WNR1Dxdyrk3UMNWW7quo6YzjKEE93COiqxphUb507kwI0rSbHYxoKbzxi1CUHqvTZrqqtao4Bs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Sjf1okOU; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPS id 094FFC4CEEE;
Fri, 30 May 2025 09:00:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748595609;
bh=iEvbOuzqN5R0DIK0mtzXnwU4mwyKC2zLReYlN5bVtG8=;
h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
b=Sjf1okOUJLHuro7SEBg5TWcj9xi7g+MpviBpYg2oys4Xf8QXJzY5LmXyvrJafTcOe
+u3W1JfPXKgjcVcnm59+GZz6nmsGYdN7+UUz2OsACWeRKfgsU8sUk7vewyuvOtJnbe
OaQHQuLEuE74STw0HVHMjMiscAPwT9A4vK3V+UxJjllCSL0OQVnEabk0UanM/2uSke
ntntoMmuH/gsqLsA3D+34ou02ZfUaSQCh0lcpV+ocNxISC+HydXso+t1NHxQVM3weG
LSwJttSoXnWHSTIlGYcVECUCIL/QhjM0emvZd0gx3UhV45DYUDLybz0BhlmI92XILN
SNplZFVAoav9w==
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1])
by smtp.lore.kernel.org (Postfix) with ESMTP id EA7DDC5B549;
Fri, 30 May 2025 09:00:08 +0000 (UTC)
From: Vincent Knecht via B4 Relay <devnull+vincent.knecht.mailoo.org@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:00:04 +0200
Subject: [PATCH v3 1/4] media: qcom: camss: vfe: Add VBIF setting support
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250530-camss-8x39-vbif-v3-1-fc91d15bb5d6@xxxxxxxxxx>
References: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
In-Reply-To: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
To: Robert Foss <rfoss@xxxxxxxxxx>, Todor Tomov <todor.too@xxxxxxxxx>,
Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>,
Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>, Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-media@xxxxxxxxxxxxxxx,
linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
=?utf-8?q?Andr=C3=A9_Apitzsch?= <git@xxxxxxxxxxx>,
phone-devel@xxxxxxxxxxxxxxx, ~postmarketos/upstreaming@xxxxxxxxxxx,
Vincent Knecht <vincent.knecht@xxxxxxxxxx>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1748595607; l=5634;
i=vincent.knecht@xxxxxxxxxx; s=20250414; h=from:subject:message-id;
bh=FckotRXI72qsx6HUw4Bx86ZqjuCyq9lSzLkzhgpF+uQ=;
b=Z/2dmfEt4MoORyEJWkUC17FbHs1Y4yvUDLRvV3GMnued+Plhr+2TMX7gmmCC9nnB3PcIHaXyM
0R+VfRppUtnDo2iTo8J/LPIZAU2nHO9knNaGq2jdKl8s8zTyHAN4EEa
X-Developer-Key: i=vincent.knecht@xxxxxxxxxx; a=ed25519;
pk=MFCVQkhL3+d3NHDzNPWpyZ4isxJvT+QTqValj5gSkm4=
X-Endpoint-Received: by B4 Relay for vincent.knecht@xxxxxxxxxx/20250414
with auth_id=377
X-Original-From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Reply-To: vincent.knecht@xxxxxxxxxx
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Some devices need writing values to VFE VBIF registers.
Add helper functions to do this.
Signed-off-by: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 12 +++++++++++
drivers/media/platform/qcom/camss/camss-vfe-vbif.c | 25 ++++++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe-vbif.h | 19 ++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 9 ++++++++
drivers/media/platform/qcom/camss/camss-vfe.h | 3 +++
6 files changed, 69 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index d26a9c24a430a831e0d865db4d96142da5276653..4c66d29ae505ae5adc717ae98f77fb736a6e15b9 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -21,6 +21,7 @@ qcom-camss-objs += \
camss-vfe-680.o \
camss-vfe-780.o \
camss-vfe-gen1.o \
+ camss-vfe-vbif.o \
camss-vfe.o \
camss-video.o \
camss-format.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
index 901677293d971cf761944a660ef719af38203f22..9cf1ccdb2fe7ca9bf89b746af836e1035b457a8f 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -15,6 +15,7 @@
#include "camss.h"
#include "camss-vfe.h"
#include "camss-vfe-gen1.h"
+#include "camss-vfe-vbif.h"
#define VFE_0_HW_VERSION 0x000
@@ -733,6 +734,7 @@ static void vfe_set_qos(struct vfe_device *vfe)
{
u32 val = VFE_0_BUS_BDG_QOS_CFG_0_CFG;
u32 val7 = VFE_0_BUS_BDG_QOS_CFG_7_CFG;
+ int ret;
writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_0);
writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_1);
@@ -742,6 +744,16 @@ static void vfe_set_qos(struct vfe_device *vfe)
writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_5);
writel_relaxed(val, vfe->base + VFE_0_BUS_BDG_QOS_CFG_6);
writel_relaxed(val7, vfe->base + VFE_0_BUS_BDG_QOS_CFG_7);
+
+ /* SoC-specific VBIF settings */
+ if (vfe->res->has_vbif) {
+ ret = vfe_vbif_apply_settings(vfe);
+ if (ret < 0) {
+ dev_err_ratelimited(vfe->camss->dev,
+ "VFE: VBIF error %d\n",
+ ret);
+ }
+ }
}
static void vfe_set_ds(struct vfe_device *vfe)
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-vbif.c b/drivers/media/platform/qcom/camss/camss-vfe-vbif.c
new file mode 100644
index 0000000000000000000000000000000000000000..691335f231a6001e6c535431a18b2e21ddc832c9
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-vbif.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * camss-vfe-vbif.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE VBIF Module
+ *
+ * Copyright (c) 2025, The Linux Foundation. All rights reserved.
+ *
+ */
+
+#include <linux/io.h>
+
+#include "camss.h"
+#include "camss-vfe.h"
+#include "camss-vfe-vbif.h"
+
+void vfe_vbif_write_reg(struct vfe_device *vfe, u32 reg, u32 val)
+{
+ writel_relaxed(val, vfe->vbif_base + reg);
+}
+
+int vfe_vbif_apply_settings(struct vfe_device *vfe)
+{
+ return 0;
+}
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-vbif.h b/drivers/media/platform/qcom/camss/camss-vfe-vbif.h
new file mode 100644
index 0000000000000000000000000000000000000000..502db629e961f67723b14a7c8c9ca973fe4c267c
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-vbif.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * camss-vfe-vbif.h
+ *
+ * Qualcomm MSM Camera Subsystem - VFE VBIF Module
+ *
+ * Copyright (c) 2025, The Linux Foundation. All rights reserved.
+ *
+ */
+#ifndef QC_MSM_CAMSS_VFE_VBIF_H
+#define QC_MSM_CAMSS_VFE_VBIF_H
+
+#include "camss-vfe.h"
+
+void vfe_vbif_write_reg(struct vfe_device *vfe, u32 reg, u32 val);
+
+int vfe_vbif_apply_settings(struct vfe_device *vfe);
+
+#endif /* QC_MSM_CAMSS_VFE_VBIF_H */
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 4bca6c3abaff9b898ea879674a3ff8f3592d3139..3138562d399444c5cf2ae96bf16b75b85ff5c5ca 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -1807,6 +1807,15 @@ int msm_vfe_subdev_init(struct camss *camss, struct vfe_device *vfe,
return PTR_ERR(vfe->base);
}
+ if (vfe->res->has_vbif) {
+ vfe->vbif_base = devm_platform_ioremap_resource_byname(pdev,
+ vfe->res->vbif_name);
+ if (IS_ERR(vfe->vbif_base)) {
+ dev_err(dev, "could not map vbif memory\n");
+ return PTR_ERR(vfe->vbif_base);
+ }
+ }
+
/* Interrupt */
ret = platform_get_irq_byname(pdev, res->interrupt[0]);
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index a23f666be7531e0366c73faea44ed245e7a8e30f..614e932c33da78e02e0800ce6534af7b14822f83 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -136,6 +136,8 @@ struct vfe_subdev_resources {
u8 line_num;
bool has_pd;
char *pd_name;
+ bool has_vbif;
+ char *vbif_name;
const struct vfe_hw_ops *hw_ops;
const struct camss_formats *formats_rdi;
const struct camss_formats *formats_pix;
@@ -145,6 +147,7 @@ struct vfe_device {
struct camss *camss;
u8 id;
void __iomem *base;
+ void __iomem *vbif_base;
u32 irq;
char irq_name[30];
struct camss_clock *clock;
--
2.49.0
Return-Path: <linux-kernel+bounces-667816-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 4BF0741E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:00:53 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 7A25E4E30C9
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:00:54 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id DD9A22222CC;
Fri, 30 May 2025 09:00:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rCBDujFw"
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 C4C6821D5AA;
Fri, 30 May 2025 09:00:09 +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=1748595609; cv=none; b=Qiv/hv6vdtAAMSF8HgeUO1+GrJ1Trss6yJf2Z4MCibbjTSSqR86HYiEtPBTuJ+JxMjtS9uvmSx+BCEC07LQOvfj3E7CQWO+L2k8e+TwPWH07pXSXBeMO4Q/aWDgsLbbxIVl0zztymqIURrmZf4VLPhEK7dpaYBt0kFDo8aDopU4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595609; c=relaxed/simple;
bh=xfa1GFv94euoBmf+fvs/VYYsw3L+ReTgBg+jQpKo9H8=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
In-Reply-To:To:Cc; b=SJYZhLaL+ya0GCLLQo5Hl1GccSinQxPAsBGI6uY9ZPTzkzrmJ/NkoJogoMuPAg3X8Ys+8YhMVoyonihILe073xyyekkak6EDdVZotBJcur++BX9gES2JXaQFew/4zVoECVIRVCyPUuF2xgg7snQJydMiZDuwd9juqYxXgCKbTpI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rCBDujFw; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPS id 3BC21C4CEFC;
Fri, 30 May 2025 09:00:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748595609;
bh=xfa1GFv94euoBmf+fvs/VYYsw3L+ReTgBg+jQpKo9H8=;
h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
b=rCBDujFw8z6RsUNapzwhReR04ccB53DOGbnmQVKQiAsQanTQt/GBPQ/+wIyDObB2u
jfuzk5sz/iLT7gKe4Olfbs7daSqmVrF0vYBb1kNN5zu4fVUyk6wuuc3jjntIWnRW18
gPXHFBkCCeKaNAeGpKH8nqcQtGKVrpRJSyk7LNIe2qbaQWeCKBvB8mxTm0tJboVA3w
I8t8mRfpJI7RsKopRFI1agMwypV0VBKRXe1njQkWbt5B79vegK4YJQxEithh1HZDQK
2Hiedp1nEgPwBu3RzCl/ArAb4C7DMZt2ap74rc2vGiY5jR2/Rbh/mMx8n6rwfTMxR0
br5RoY/6MWwEQ==
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1])
by smtp.lore.kernel.org (Postfix) with ESMTP id 2CB16C5B549;
Fri, 30 May 2025 09:00:09 +0000 (UTC)
From: Vincent Knecht via B4 Relay <devnull+vincent.knecht.mailoo.org@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:00:07 +0200
Subject: [PATCH v3 4/4] arm64: dts: qcom: msm8939: Add camss and cci
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250530-camss-8x39-vbif-v3-4-fc91d15bb5d6@xxxxxxxxxx>
References: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
In-Reply-To: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
To: Robert Foss <rfoss@xxxxxxxxxx>, Todor Tomov <todor.too@xxxxxxxxx>,
Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>,
Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>, Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-media@xxxxxxxxxxxxxxx,
linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
=?utf-8?q?Andr=C3=A9_Apitzsch?= <git@xxxxxxxxxxx>,
phone-devel@xxxxxxxxxxxxxxx, ~postmarketos/upstreaming@xxxxxxxxxxx,
Vincent Knecht <vincent.knecht@xxxxxxxxxx>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1748595607; l=5427;
i=vincent.knecht@xxxxxxxxxx; s=20250414; h=from:subject:message-id;
bh=3AXxGKiiFPkzccexXUftpqL5zw7vJ6WvoTGCbe02/GY=;
b=Sp/sG4/rr4ZLXVlrpVisinb+PnxHYy9BY/0/GWSRVE1dIA+2mVKzBGJUB8gYsKkOa6qeYBnUR
1J8kKnT9idCDM14y1N4WCg6yFCl2sqcsejpq3CnD8krLRDns7tlhhJz
X-Developer-Key: i=vincent.knecht@xxxxxxxxxx; a=ed25519;
pk=MFCVQkhL3+d3NHDzNPWpyZ4isxJvT+QTqValj5gSkm4=
X-Endpoint-Received: by B4 Relay for vincent.knecht@xxxxxxxxxx/20250414
with auth_id=377
X-Original-From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Reply-To: vincent.knecht@xxxxxxxxxx
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Add the camera subsystem and CCI used to interface with cameras on the
Snapdragon 615.
Signed-off-by: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi | 4 +
arch/arm64/boot/dts/qcom/msm8939.dtsi | 146 +++++++++++++++++++++++++++
2 files changed, 150 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi
index adb96cd8d643e5fde1ac95c0fc3c9c3c3efb07e8..659d127b1bc3570d137ca986e4eacf600c183e5e 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939-pm8916.dtsi
@@ -11,6 +11,10 @@
#include "msm8939.dtsi"
#include "pm8916.dtsi"
+&camss {
+ vdda-supply = <&pm8916_l2>;
+};
+
&mdss_dsi0 {
vdda-supply = <&pm8916_l2>;
vddio-supply = <&pm8916_l6>;
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 68b92fdb996c26e7a1aadedf0f52e1afca85c4ab..082542b54d96adaed3e6b49bc3682005ea018a72 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -1434,6 +1434,145 @@ mdss_dsi1_phy: phy@1aa0300 {
};
};
+ camss: isp@1b08000 {
+ compatible = "qcom,msm8939-camss";
+ reg = <0x01b08000 0x100>,
+ <0x01b08400 0x100>,
+ <0x01b08800 0x100>,
+ <0x01b0ac00 0x200>,
+ <0x01b00030 0x4>,
+ <0x01b0b000 0x200>,
+ <0x01b00038 0x4>,
+ <0x01b00020 0x10>,
+ <0x01b0a000 0x500>,
+ <0x01b10000 0x1000>,
+ <0x01b40000 0x200>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy0_clk_mux",
+ "csiphy1",
+ "csiphy1_clk_mux",
+ "csi_clk_mux",
+ "ispif",
+ "vfe0",
+ "vfe0_vbif";
+
+ clocks = <&gcc GCC_CAMSS_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0_CLK>,
+ <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI0PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI0RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI1_CLK>,
+ <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI1PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI1RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI2_CLK>,
+ <&gcc GCC_CAMSS_CSI2_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI2PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI2PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI2RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
+ <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
+ <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE0_CLK>,
+ <&gcc GCC_CAMSS_VFE_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE_AXI_CLK>;
+ clock-names = "ahb",
+ "csi0",
+ "csi0_ahb",
+ "csi0_phy",
+ "csi0_pix",
+ "csi0_rdi",
+ "csi1",
+ "csi1_ahb",
+ "csi1_phy",
+ "csi1_pix",
+ "csi1_rdi",
+ "csi2",
+ "csi2_ahb",
+ "csi2_phy",
+ "csi2_pix",
+ "csi2_rdi",
+ "csiphy0_timer",
+ "csiphy1_timer",
+ "csi_vfe0",
+ "ispif_ahb",
+ "top_ahb",
+ "vfe0",
+ "vfe_ahb",
+ "vfe_axi";
+
+ interrupts = <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "ispif",
+ "vfe0";
+
+ iommus = <&apps_iommu 3>;
+
+ power-domains = <&gcc VFE_GDSC>;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ cci: cci@1b0c000 {
+ compatible = "qcom,msm8916-cci", "qcom,msm8226-cci";
+ reg = <0x01b0c000 0x1000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_CCI_AHB_CLK>,
+ <&gcc GCC_CAMSS_CCI_CLK>,
+ <&gcc GCC_CAMSS_AHB_CLK>;
+ clock-names = "camss_top_ahb",
+ "cci_ahb",
+ "cci",
+ "camss_ahb";
+ assigned-clocks = <&gcc GCC_CAMSS_CCI_AHB_CLK>,
+ <&gcc GCC_CAMSS_CCI_CLK>;
+ assigned-clock-rates = <80000000>,
+ <19200000>;
+ pinctrl-0 = <&cci0_default>;
+ pinctrl-names = "default";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ cci_i2c0: i2c-bus@0 {
+ reg = <0>;
+ clock-frequency = <400000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
gpu: gpu@1c00000 {
compatible = "qcom,adreno-405.0", "qcom,adreno";
reg = <0x01c00000 0x10000>;
@@ -1498,6 +1637,13 @@ apps_iommu: iommu@1ef0000 {
#iommu-cells = <1>;
qcom,iommu-secure-id = <17>;
+ /* vfe */
+ iommu-ctx@3000 {
+ compatible = "qcom,msm-iommu-v1-sec";
+ reg = <0x3000 0x1000>;
+ interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
/* mdp_0: */
iommu-ctx@4000 {
compatible = "qcom,msm-iommu-v1-ns";
--
2.49.0
Return-Path: <linux-kernel+bounces-667815-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 6FEB641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:00:54 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 34ABF1BC2B4D
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:01:07 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id D24592222C7;
Fri, 30 May 2025 09:00:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="niQjjdTx"
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 8C57321C9FE;
Fri, 30 May 2025 09:00:09 +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=1748595609; cv=none; b=bTpeTmiZ7YRZ3cWJfOpIVld2sikiVrhy3QNhhT5X9F9DuOS68Hjl4brI/lkuCugWtHqgDBD5OtasuSjmDZzl/LAJY+he2YzV23s5SICh8OLHPiETUxGd7uM4BaJ0de2qZwU6my5DbJ0Pxch2mD5Tg6zitpDCso2/TWsjcMdhj54=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595609; c=relaxed/simple;
bh=P5YZHYMBuxGN/if7ZMeIgF/uu9PRs4ZqEW+UoS5c1Sc=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
In-Reply-To:To:Cc; b=Np00YapQONCTNZeiAwJSGnzmxSvEnQ4GnU0Ulz7ua+IaLBWz+FsvtN//2EuVvakXg0zzkRJRx/0UvjUF+urJt5xYbF2rm07wrVrT8n02WgxuxjzpDdhDKDiXUASwxQamXg0NaiGFix8SBUb0OAvIaObH24zUq4z9ox5I2xxHO0w=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=niQjjdTx; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPS id 2CA6AC4CEF6;
Fri, 30 May 2025 09:00:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748595609;
bh=P5YZHYMBuxGN/if7ZMeIgF/uu9PRs4ZqEW+UoS5c1Sc=;
h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
b=niQjjdTxOtlqynmet7Yh7L5ahjtrbmAUdn7Up/1+KGzDe9WbXy4yocILKvoS1YSOD
g/rCS6KozfixzgW6h81iNg9NtbGHxAHNOBMpwM7m1GOKhlV47JtM7HIjnHbiCYP05S
zk73BWLne2Rzma7Gk02d91lk5LnAKVKPyWUIRI6rV7DJYk1TWD+Gp7WdWjLENRV1M4
D0m2pXJm+C7CpFcszseuji6AMOdweaJMdYnjjgAkZGRHNQqcZU/XVkVVoFjv16PCij
hOmGYdKH8Flz/I/SVIibnBVLgXTZq3xBBk//xokOXwVITHLcYoiZl0cm4CD8UXV8Ob
2/6mlpDgFa4Cw==
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1])
by smtp.lore.kernel.org (Postfix) with ESMTP id 1D036C5B552;
Fri, 30 May 2025 09:00:09 +0000 (UTC)
From: Vincent Knecht via B4 Relay <devnull+vincent.knecht.mailoo.org@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:00:06 +0200
Subject: [PATCH v3 3/4] media: dt-bindings: Add qcom,msm8939-camss
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250530-camss-8x39-vbif-v3-3-fc91d15bb5d6@xxxxxxxxxx>
References: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
In-Reply-To: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
To: Robert Foss <rfoss@xxxxxxxxxx>, Todor Tomov <todor.too@xxxxxxxxx>,
Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>,
Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>, Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-media@xxxxxxxxxxxxxxx,
linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
=?utf-8?q?Andr=C3=A9_Apitzsch?= <git@xxxxxxxxxxx>,
phone-devel@xxxxxxxxxxxxxxx, ~postmarketos/upstreaming@xxxxxxxxxxx,
Vincent Knecht <vincent.knecht@xxxxxxxxxx>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1748595607; l=7806;
i=vincent.knecht@xxxxxxxxxx; s=20250414; h=from:subject:message-id;
bh=/SQ0WMJnRjbAm7ftCb3NRJ3E8Q5yUCv/67szqvZfAPI=;
b=mV6jDUrtm1jvOtThb8KnPV+73oJzYc4CY2wVIly2iFiO4ePiiEvZKYe2Q5+n/UoSzH4g/CUwd
NelPM4x5GvICGxrlsXf8tc0pRucF556JIOG2CKtsthWIThgORaq65Md
X-Developer-Key: i=vincent.knecht@xxxxxxxxxx; a=ed25519;
pk=MFCVQkhL3+d3NHDzNPWpyZ4isxJvT+QTqValj5gSkm4=
X-Endpoint-Received: by B4 Relay for vincent.knecht@xxxxxxxxxx/20250414
with auth_id=377
X-Original-From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Reply-To: vincent.knecht@xxxxxxxxxx
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Add bindings for qcom,msm8939-camss in order to support the camera
subsystem for MSM8939.
Signed-off-by: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
---
.../bindings/media/qcom,msm8939-camss.yaml | 253 +++++++++++++++++++++
1 file changed, 253 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..592b847433d7a788d8c1635129dd408cb0112073
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml
@@ -0,0 +1,253 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,msm8939-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm MSM8939 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Vincent Knecht <vincent.knecht@xxxxxxxxxx>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms
+
+properties:
+ compatible:
+ const: qcom,msm8939-camss
+
+ reg:
+ maxItems: 11
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy0_clk_mux
+ - const: csiphy1
+ - const: csiphy1_clk_mux
+ - const: csi_clk_mux
+ - const: ispif
+ - const: vfe0
+ - const: vfe0_vbif
+
+ clocks:
+ maxItems: 24
+
+ clock-names:
+ items:
+ - const: ahb
+ - const: csi0
+ - const: csi0_ahb
+ - const: csi0_phy
+ - const: csi0_pix
+ - const: csi0_rdi
+ - const: csi1
+ - const: csi1_ahb
+ - const: csi1_phy
+ - const: csi1_pix
+ - const: csi1_rdi
+ - const: csi2
+ - const: csi2_ahb
+ - const: csi2_phy
+ - const: csi2_pix
+ - const: csi2_rdi
+ - const: csiphy0_timer
+ - const: csiphy1_timer
+ - const: csi_vfe0
+ - const: ispif_ahb
+ - const: top_ahb
+ - const: vfe0
+ - const: vfe_ahb
+ - const: vfe_axi
+
+ interrupts:
+ maxItems: 7
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csiphy0
+ - const: csiphy1
+ - const: ispif
+ - const: vfe0
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: VFE GDSC - Video Front End, Global Distributed Switch Controller.
+
+ vdda-supply:
+ description:
+ Definition of the regulator used as analog power supply.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ patternProperties:
+ "^port@[0-1]$":
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ bus-type:
+ enum:
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
+ required:
+ - data-lanes
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - vdda-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/qcom,gcc-msm8939.h>
+
+ isp@1b08000 {
+ compatible = "qcom,msm8939-camss";
+
+ reg = <0x01b08000 0x100>,
+ <0x01b08400 0x100>,
+ <0x01b08800 0x100>,
+ <0x01b0ac00 0x200>,
+ <0x01b00030 0x4>,
+ <0x01b0b000 0x200>,
+ <0x01b00038 0x4>,
+ <0x01b00020 0x10>,
+ <0x01b0a000 0x500>,
+ <0x01b10000 0x1000>,
+ <0x01b40000 0x200>;
+
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy0_clk_mux",
+ "csiphy1",
+ "csiphy1_clk_mux",
+ "csi_clk_mux",
+ "ispif",
+ "vfe0",
+ "vfe0_vbif";
+
+ clocks = <&gcc GCC_CAMSS_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0_CLK>,
+ <&gcc GCC_CAMSS_CSI0_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI0PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI0RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI1_CLK>,
+ <&gcc GCC_CAMSS_CSI1_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI1PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI1RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI2_CLK>,
+ <&gcc GCC_CAMSS_CSI2_AHB_CLK>,
+ <&gcc GCC_CAMSS_CSI2PHY_CLK>,
+ <&gcc GCC_CAMSS_CSI2PIX_CLK>,
+ <&gcc GCC_CAMSS_CSI2RDI_CLK>,
+ <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>,
+ <&gcc GCC_CAMSS_CSI_VFE0_CLK>,
+ <&gcc GCC_CAMSS_ISPIF_AHB_CLK>,
+ <&gcc GCC_CAMSS_TOP_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE0_CLK>,
+ <&gcc GCC_CAMSS_VFE_AHB_CLK>,
+ <&gcc GCC_CAMSS_VFE_AXI_CLK>;
+
+ clock-names = "ahb",
+ "csi0",
+ "csi0_ahb",
+ "csi0_phy",
+ "csi0_pix",
+ "csi0_rdi",
+ "csi1",
+ "csi1_ahb",
+ "csi1_phy",
+ "csi1_pix",
+ "csi1_rdi",
+ "csi2",
+ "csi2_ahb",
+ "csi2_phy",
+ "csi2_pix",
+ "csi2_rdi",
+ "csiphy0_timer",
+ "csiphy1_timer",
+ "csi_vfe0",
+ "ispif_ahb",
+ "top_ahb",
+ "vfe0",
+ "vfe_ahb",
+ "vfe_axi";
+
+ interrupts = <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>,
+ <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csiphy0",
+ "csiphy1",
+ "ispif",
+ "vfe0";
+
+ iommus = <&apps_iommu 3>;
+
+ power-domains = <&gcc VFE_GDSC>;
+
+ vdda-supply = <®_2v8>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ csiphy1_ep: endpoint {
+ clock-lanes = <1>;
+ data-lanes = <0 2>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
--
2.49.0
Return-Path: <linux-kernel+bounces-667814-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 41D0441E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:00:56 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 0BE55A24BDC
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:00:33 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id E6E73222565;
Fri, 30 May 2025 09:00:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GUzT7r3t"
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 8C5D021CA0F;
Fri, 30 May 2025 09:00:09 +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=1748595609; cv=none; b=g4vAycCZmc0A5Fjs8s/RUnIGwbNrQq+1sHEAaDP7KJTFLRY8/DYol+C0yIYsl+4NuOfD59oS8wlIMOXvKw7V26+eQ5EZnN8Pz9ISdKR+tMTLmjfH5rMVDQpkcUrMr53JwO4y1RUaxj8+Pc96xPJ9UR0CzFvoZWlPJHH+Ww5So6Q=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595609; c=relaxed/simple;
bh=8yVJxt1ye0n/lgFCRs4dy/J58+6JitY+rGXRj+sr/6c=;
h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References:
In-Reply-To:To:Cc; b=W9/wuMhNKbHIZtPjVm7Cv4jwS54udyyacuBy3JJ4Mqoku+OUURC5BbKL9fOGclkF/uTy0tstIeA6e4Ugg7EaiQ++ThQGAS9FhLNUp2leCFbq36mb91+pQptWiDrQAPy820YFDCQbweTC1MjvMzT5KnF3kr1AYMBcy9moI4hl9eQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GUzT7r3t; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPS id 19031C4CEF1;
Fri, 30 May 2025 09:00:09 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748595609;
bh=8yVJxt1ye0n/lgFCRs4dy/J58+6JitY+rGXRj+sr/6c=;
h=From:Date:Subject:References:In-Reply-To:To:Cc:Reply-To:From;
b=GUzT7r3t0m9DQP8KCjPDILg67MqPckfN5OqA8OyH9EltEFnLIhiIuDtr0ZXSKkl0z
++6L8bm82dnshEJdAbup2jKb+628AquUGpy9tMxDpK+GuDY8YwQcn9JKMdzlquEVBN
kjLfazEsuwBwiZDip0l3LkP8l4CvqbSr5gWayaKcEM/gebCkmK05fY8X8cM+wTTzZX
ItAD7Dc1VVPAXn8ORe6KAyb6lsqMXZ7Y+vBzHSApRxTfp+deJithIxP31EBzQIsGxW
gP9pDq4+AUHg9Yo6wPM742sG6nqw2FeWsuhmhEsA4/mj5UZWbbDxjXZ3855XwW19rw
/tULHK15JXt1A==
Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1])
by smtp.lore.kernel.org (Postfix) with ESMTP id 08D2BC5B555;
Fri, 30 May 2025 09:00:09 +0000 (UTC)
From: Vincent Knecht via B4 Relay <devnull+vincent.knecht.mailoo.org@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:00:05 +0200
Subject: [PATCH v3 2/4] media: qcom: camss: Add support for MSM8939
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <20250530-camss-8x39-vbif-v3-2-fc91d15bb5d6@xxxxxxxxxx>
References: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
In-Reply-To: <20250530-camss-8x39-vbif-v3-0-fc91d15bb5d6@xxxxxxxxxx>
To: Robert Foss <rfoss@xxxxxxxxxx>, Todor Tomov <todor.too@xxxxxxxxx>,
Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>,
Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>, Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>
Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-media@xxxxxxxxxxxxxxx,
linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
=?utf-8?q?Andr=C3=A9_Apitzsch?= <git@xxxxxxxxxxx>,
phone-devel@xxxxxxxxxxxxxxx, ~postmarketos/upstreaming@xxxxxxxxxxx,
Vincent Knecht <vincent.knecht@xxxxxxxxxx>
X-Mailer: b4 0.14.2
X-Developer-Signature: v=1; a=ed25519-sha256; t=1748595607; l=10562;
i=vincent.knecht@xxxxxxxxxx; s=20250414; h=from:subject:message-id;
bh=NqyfO2EtBVKNziHKtRkVtB1jogx4ePsKb5OdQhuL/MU=;
b=Mhoi9VyTThf9Y9AVR2D9zAK3b54NboQvjvFiDhURaGtMietxYmmV1AuA8bz5cb4g7bxb/q3vH
r1ajVn3/t04CiQ42Q3X6y8Znw2oPrBoV3kOM0C1WDbwz+fN+rRigg2Y
X-Developer-Key: i=vincent.knecht@xxxxxxxxxx; a=ed25519;
pk=MFCVQkhL3+d3NHDzNPWpyZ4isxJvT+QTqValj5gSkm4=
X-Endpoint-Received: by B4 Relay for vincent.knecht@xxxxxxxxxx/20250414
with auth_id=377
X-Original-From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
Reply-To: vincent.knecht@xxxxxxxxxx
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
From: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
The camera subsystem for the MSM8939 is the same as MSM8916 except with
3 CSID instead of 2, and some higher clock rates.
As a quirk, this SoC needs writing values to 2 VFE VBIF registers
(see downstream msm8939-camera.dtsi vbif-{regs,settings} properties).
This fixes black stripes across sensor and garbage in CSID TPG outputs.
Add support for the MSM8939 camera subsystem.
Signed-off-by: Vincent Knecht <vincent.knecht@xxxxxxxxxx>
---
drivers/media/platform/qcom/camss/camss-csiphy.c | 1 +
drivers/media/platform/qcom/camss/camss-ispif.c | 8 +-
drivers/media/platform/qcom/camss/camss-vfe-vbif.c | 6 +
drivers/media/platform/qcom/camss/camss-vfe.c | 1 +
drivers/media/platform/qcom/camss/camss.c | 157 +++++++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
6 files changed, 172 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index c622efcc92ff3781d7fc3ace0253c2d64c91e847..6311fc2975aa1345e430a477c8a6476f1d7e5663 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -605,6 +605,7 @@ int msm_csiphy_subdev_init(struct camss *camss,
return PTR_ERR(csiphy->base);
if (camss->res->version == CAMSS_8x16 ||
+ camss->res->version == CAMSS_8x39 ||
camss->res->version == CAMSS_8x53 ||
camss->res->version == CAMSS_8x96) {
csiphy->base_clk_mux =
diff --git a/drivers/media/platform/qcom/camss/camss-ispif.c b/drivers/media/platform/qcom/camss/camss-ispif.c
index 2dc585c6123dd248a5bacd9c7a88cb5375644311..aaf3caa42d33dcb641651e7f5bc0c2a564d85bfa 100644
--- a/drivers/media/platform/qcom/camss/camss-ispif.c
+++ b/drivers/media/platform/qcom/camss/camss-ispif.c
@@ -1112,6 +1112,8 @@ int msm_ispif_subdev_init(struct camss *camss,
/* Number of ISPIF lines - same as number of CSID hardware modules */
if (camss->res->version == CAMSS_8x16)
ispif->line_num = 2;
+ else if (camss->res->version == CAMSS_8x39)
+ ispif->line_num = 3;
else if (camss->res->version == CAMSS_8x96 ||
camss->res->version == CAMSS_8x53 ||
camss->res->version == CAMSS_660)
@@ -1128,7 +1130,8 @@ int msm_ispif_subdev_init(struct camss *camss,
ispif->line[i].ispif = ispif;
ispif->line[i].id = i;
- if (camss->res->version == CAMSS_8x16) {
+ if (camss->res->version == CAMSS_8x16 ||
+ camss->res->version == CAMSS_8x39) {
ispif->line[i].formats = ispif_formats_8x16;
ispif->line[i].nformats =
ARRAY_SIZE(ispif_formats_8x16);
@@ -1162,7 +1165,8 @@ int msm_ispif_subdev_init(struct camss *camss,
ispif->irq = ret;
snprintf(ispif->irq_name, sizeof(ispif->irq_name), "%s_%s",
dev_name(dev), MSM_ISPIF_NAME);
- if (camss->res->version == CAMSS_8x16)
+ if (camss->res->version == CAMSS_8x16 ||
+ camss->res->version == CAMSS_8x39)
ret = devm_request_irq(dev, ispif->irq, ispif_isr_8x16,
IRQF_TRIGGER_RISING, ispif->irq_name, ispif);
else if (camss->res->version == CAMSS_8x96 ||
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-vbif.c b/drivers/media/platform/qcom/camss/camss-vfe-vbif.c
index 691335f231a6001e6c535431a18b2e21ddc832c9..911f8da02f1fbb500ab9564978e2b0dddf93e84e 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-vbif.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-vbif.c
@@ -14,6 +14,9 @@
#include "camss-vfe.h"
#include "camss-vfe-vbif.h"
+#define VBIF_FIXED_SORT_EN 0x30
+#define VBIF_FIXED_SORT_SEL0 0x34
+
void vfe_vbif_write_reg(struct vfe_device *vfe, u32 reg, u32 val)
{
writel_relaxed(val, vfe->vbif_base + reg);
@@ -21,5 +24,8 @@ void vfe_vbif_write_reg(struct vfe_device *vfe, u32 reg, u32 val)
int vfe_vbif_apply_settings(struct vfe_device *vfe)
{
+ vfe_vbif_write_reg(vfe, VBIF_FIXED_SORT_EN, 0xfff);
+ vfe_vbif_write_reg(vfe, VBIF_FIXED_SORT_SEL0, 0x555000);
+
return 0;
}
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 3138562d399444c5cf2ae96bf16b75b85ff5c5ca..ac3a9579e3e6910eee8c1ec11c4fff6e1bc94443 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -290,6 +290,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
switch (vfe->camss->res->version) {
case CAMSS_8x16:
+ case CAMSS_8x39:
case CAMSS_8x53:
switch (sink_code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 06f42875702f02f9d8d83d06ddaa972eacb593f8..6a68876a00a8d6eaf3ef55e8fde0d266f567879a 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -154,6 +154,149 @@ static const struct camss_subdev_resources vfe_res_8x16[] = {
}
};
+static const struct camss_subdev_resources csiphy_res_8x39[] = {
+ /* CSIPHY0 */
+ {
+ .regulators = { "vdda" },
+ .clock = { "top_ahb", "ispif_ahb", "ahb", "csiphy0_timer" },
+ .clock_rate = { { 0 },
+ { 40000000, 80000000 },
+ { 0 },
+ { 100000000, 200000000 } },
+ .reg = { "csiphy0", "csiphy0_clk_mux" },
+ .interrupt = { "csiphy0" },
+ .csiphy = {
+ .id = 0,
+ .hw_ops = &csiphy_ops_2ph_1_0,
+ .formats = &csiphy_formats_8x16
+ }
+ },
+
+ /* CSIPHY1 */
+ {
+ .regulators = { "vdda" },
+ .clock = { "top_ahb", "ispif_ahb", "ahb", "csiphy1_timer" },
+ .clock_rate = { { 0 },
+ { 40000000, 80000000 },
+ { 0 },
+ { 100000000, 200000000 } },
+ .reg = { "csiphy1", "csiphy1_clk_mux" },
+ .interrupt = { "csiphy1" },
+ .csiphy = {
+ .id = 1,
+ .hw_ops = &csiphy_ops_2ph_1_0,
+ .formats = &csiphy_formats_8x16
+ }
+ }
+};
+
+static const struct camss_subdev_resources csid_res_8x39[] = {
+ /* CSID0 */
+ {
+ .regulators = {},
+ .clock = { "top_ahb", "ispif_ahb", "csi0_ahb", "ahb",
+ "csi0", "csi0_phy", "csi0_pix", "csi0_rdi" },
+ .clock_rate = { { 0 },
+ { 40000000, 80000000 },
+ { 0 },
+ { 0 },
+ { 100000000, 200000000 },
+ { 0 },
+ { 0 },
+ { 0 } },
+ .reg = { "csid0" },
+ .interrupt = { "csid0" },
+ .csid = {
+ .hw_ops = &csid_ops_4_1,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .formats = &csid_formats_4_1
+ }
+ },
+
+ /* CSID1 */
+ {
+ .regulators = {},
+ .clock = { "top_ahb", "ispif_ahb", "csi1_ahb", "ahb",
+ "csi1", "csi1_phy", "csi1_pix", "csi1_rdi" },
+ .clock_rate = { { 0 },
+ { 40000000, 80000000 },
+ { 0 },
+ { 0 },
+ { 100000000, 200000000 },
+ { 0 },
+ { 0 },
+ { 0 } },
+ .reg = { "csid1" },
+ .interrupt = { "csid1" },
+ .csid = {
+ .hw_ops = &csid_ops_4_1,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .formats = &csid_formats_4_1
+ }
+ },
+
+ /* CSID2 */
+ {
+ .regulators = {},
+ .clock = { "top_ahb", "ispif_ahb", "csi2_ahb", "ahb",
+ "csi2", "csi2_phy", "csi2_pix", "csi2_rdi" },
+ .clock_rate = { { 0 },
+ { 40000000, 80000000 },
+ { 0 },
+ { 0 },
+ { 100000000, 200000000 },
+ { 0 },
+ { 0 },
+ { 0 } },
+ .reg = { "csid2" },
+ .interrupt = { "csid2" },
+ .csid = {
+ .hw_ops = &csid_ops_4_1,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .formats = &csid_formats_4_1
+ }
+ },
+};
+
+static const struct camss_subdev_resources ispif_res_8x39 = {
+ /* ISPIF */
+ .clock = { "top_ahb", "ispif_ahb", "ahb",
+ "csi0", "csi0_pix", "csi0_rdi",
+ "csi1", "csi1_pix", "csi1_rdi",
+ "csi2", "csi2_pix", "csi2_rdi" },
+ .clock_for_reset = { "vfe0", "csi_vfe0" },
+ .reg = { "ispif", "csi_clk_mux" },
+ .interrupt = { "ispif" },
+};
+
+static const struct camss_subdev_resources vfe_res_8x39[] = {
+ /* VFE0 */
+ {
+ .regulators = {},
+ .clock = { "top_ahb", "ispif_ahb", "vfe0", "csi_vfe0",
+ "vfe_ahb", "vfe_axi", "ahb" },
+ .clock_rate = { { 0 },
+ { 40000000, 80000000 },
+ { 50000000, 80000000, 100000000, 160000000,
+ 177780000, 200000000, 266670000, 320000000,
+ 400000000, 465000000, 480000000, 600000000 },
+ { 0 },
+ { 0 },
+ { 0 },
+ { 0 } },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .vfe = {
+ .line_num = 3,
+ .has_vbif = true,
+ .vbif_name = "vfe0_vbif",
+ .hw_ops = &vfe_ops_4_1,
+ .formats_rdi = &vfe_formats_rdi_8x16,
+ .formats_pix = &vfe_formats_pix_8x16
+ }
+ }
+};
+
static const struct camss_subdev_resources csid_res_8x53[] = {
/* CSID0 */
{
@@ -3585,6 +3728,7 @@ static int camss_probe(struct platform_device *pdev)
return -ENOMEM;
if (camss->res->version == CAMSS_8x16 ||
+ camss->res->version == CAMSS_8x39 ||
camss->res->version == CAMSS_8x53 ||
camss->res->version == CAMSS_8x96) {
camss->ispif = devm_kcalloc(dev, 1, sizeof(*camss->ispif), GFP_KERNEL);
@@ -3727,6 +3871,18 @@ static const struct camss_resources msm8916_resources = {
.link_entities = camss_link_entities
};
+static const struct camss_resources msm8939_resources = {
+ .version = CAMSS_8x39,
+ .csiphy_res = csiphy_res_8x39,
+ .csid_res = csid_res_8x39,
+ .ispif_res = &ispif_res_8x39,
+ .vfe_res = vfe_res_8x39,
+ .csiphy_num = ARRAY_SIZE(csiphy_res_8x39),
+ .csid_num = ARRAY_SIZE(csid_res_8x39),
+ .vfe_num = ARRAY_SIZE(vfe_res_8x39),
+ .link_entities = camss_link_entities
+};
+
static const struct camss_resources msm8953_resources = {
.version = CAMSS_8x53,
.icc_res = icc_res_8x53,
@@ -3863,6 +4019,7 @@ static const struct camss_resources x1e80100_resources = {
static const struct of_device_id camss_dt_match[] = {
{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
+ { .compatible = "qcom,msm8939-camss", .data = &msm8939_resources },
{ .compatible = "qcom,msm8953-camss", .data = &msm8953_resources },
{ .compatible = "qcom,msm8996-camss", .data = &msm8996_resources },
{ .compatible = "qcom,sc7280-camss", .data = &sc7280_resources },
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 63c0afee154a02194820016ccf554620d6521c8b..be11cf3af478627fa48827e70d5f0673939e1e63 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -80,6 +80,7 @@ enum camss_version {
CAMSS_660,
CAMSS_7280,
CAMSS_8x16,
+ CAMSS_8x39,
CAMSS_8x53,
CAMSS_8x96,
CAMSS_8250,
--
2.49.0
Return-Path: <linux-kernel+bounces-667817-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 2985E41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:01:36 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 851561BC301C
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:01:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id A173921D3E9;
Fri, 30 May 2025 09:00:43 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="XK76938Q"
Received: from casper.infradead.org (casper.infradead.org [90.155.50.34])
(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 4670C2185BC
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:00:41 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595643; cv=none; b=SP9/Lk85bCYhBJTaDrBCetx6qSIAGboyouoLPGuEXM2jEdVuaBqlcyf3JjAlLEGPdMoZdTWElsffIrz4smVMisurMQ9guh6nSSMY33a3VfbXVxQm4Z4LviGbQ1WeyzYq5VKIZRH2J451JtDAAEGF+QDkeSlVRMA/Pazye2sy3FA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595643; c=relaxed/simple;
bh=LKTjIRMzHXn5Zw0J4fAUckDi/Sev3/I4ZHV38WVIG/c=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=TGgzH7m1SJvmo1v9dNzC7vdkj4WC9O571wvYOXNBlbyZ/7t3xT0Nbn0uJSt8LpMO/FXy2+vdiY7xQb4C9nR/W/XBWkJb5kWDpX/B0x/cNkRHPx2RSsY58zp23BYzk1Llv0a9fCR+T+wEQX19uWWUWzfvxCwwr2VJ2BrLMkT34zM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=XK76938Q; arc=none smtp.client-ip=90.155.50.34
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org
Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
Content-Transfer-Encoding:Content-ID:Content-Description;
bh=0gdKVbBS+SWFxzq/DgDZxsQ+C2It/mTqNQOkQQfp0rU=; b=XK76938Qy1bxmx/KD2zaULIKYA
JQFsKd1ixMvCZmmlkLRrg9AuLtaXiUf7ZvUXEUh/OWVK/w2mVLlB8zVGXVEZM7oQZOf38aGaLH2ct
gXQF1yUPlUsACOCt9fm+yJHO89BUUBKIVmRDojHAAFbca0PqYXgbJ31UHAM+mBfYlAeWAAg6vFSKL
iuNszF1JVaHQaPL6j6VmxTzV8lVA0cIZLD88XNWQKXbUkNHItV0tUT7aNbudJzA4f/AUX549GL3WD
2BidplAvMNYPSe/RYgurNvz4l2t0Dd3VSIaHtWFXYn5IPUx6CxC22xmyTEQzRI401vL38Apyc9Vb8
g1PCPpag==;
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net)
by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
id 1uKvbN-0000000Fe0o-2NHi;
Fri, 30 May 2025 09:00:33 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
id CA9C030066A; Fri, 30 May 2025 11:00:32 +0200 (CEST)
Date: Fri, 30 May 2025 11:00:32 +0200
From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
To: Beata Michalska <beata.michalska@xxxxxxx>
Cc: mingo@xxxxxxxxxx, juri.lelli@xxxxxxxxxx, vincent.guittot@xxxxxxxxxx,
dietmar.eggemann@xxxxxxx, rostedt@xxxxxxxxxxx, bsegall@xxxxxxxxxx,
mgorman@xxxxxxx, vschneid@xxxxxxxxxx, clm@xxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [RFC][PATCH 0/5] sched: Try and address some recent-ish
regressions
Message-ID: <20250530090032.GA21197@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20250520094538.086709102@xxxxxxxxxxxxx>
<20250528195944.GB19261@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
<aDg0jp4DiPTGnmq5@xxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aDg0jp4DiPTGnmq5@xxxxxxx>
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Thu, May 29, 2025 at 12:18:54PM +0200, Beata Michalska wrote:
> On Wed, May 28, 2025 at 09:59:44PM +0200, Peter Zijlstra wrote:
> > On Tue, May 20, 2025 at 11:45:38AM +0200, Peter Zijlstra wrote:
> >
> > > Anyway, the patches are stable (finally!, I hope, knock on wood) but in a
> > > somewhat rough state. At the very least the last patch is missing ttwu_stat(),
> > > still need to figure out how to account it ;-)
> > >
> > > Chris, I'm hoping your machine will agree with these numbers; it hasn't been
> > > straight sailing in that regard.
> >
> > Anybody? -- If no comments I'll just stick them in sched/core or so.
> >
> Hi Peter,
>
> I've tried out your series on top of 6.15 on an Ampere Altra Mt Jade
> dual-socket (160-core) system, which enables SCHED_CLUSTER (2-core MC domains).
Ah, that's a radically different system than what we set out with. Good
to get some feedback on that indeed.
> Sharing preliminary test results of 50 runs per setup as, so far, the data
> show quite a bit of run-to-run variability - not sure how useful those will be.
Yeah, I had some of that on the Skylake system, I had to disable turbo
for the numbers to become stable enough to say anything much.
> At this point without any deep dive, which is probably needed and hopefully
> will come later on.
>
>
> Results for average rps (60s) sorted based on P90
>
> CFG | min | max | stdev | 90th
> ----+------------+------------+------------+-----------
> 1 | 704577.50 | 942665.67 | 46439.49 | 891272.09
> 2 | 647163.57 | 815392.65 | 35559.98 | 783884.00
> 3 | 658665.75 | 859520.32 | 50257.35 | 832174.80
> 4 | 656313.48 | 877223.85 | 47871.43 | 837693.28
> 5 | 630419.62 | 842170.47 | 47267.52 | 815911.81
>
> Legend:
> #1 : kernel 6.9
> #2 : kernel 6.15
> #3 : kernel 6.15 patched def (TTWU_QUEUE_ON_CPU + NO_TTWU_QUEUE_DEFAULT)
> #4 : kernel 6.15 patched + TTWU_QUEUE_ON_CPU + TTWU_QUEUE_DEFAULT
> #5 : kernel 6.15 patched + NO_TTWU_QUEUE_ON_CPU + NO_TTWU_QUEUE_DEFAULT
Right, minor improvement. At least its not making it worse :-)
The new toy is TTWU_QUEUE_DELAYED, and yeah, I did notice that disabling
TTWU_QUEUE_ON_CPU was a bad idea.
Return-Path: <linux-kernel+bounces-667818-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 1A2D041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:01:47 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 1F81A4E3310
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:01:48 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 7CE57220F2F;
Fri, 30 May 2025 09:00:52 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="ctSgh+iR"
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 A115F21D5B3;
Fri, 30 May 2025 09:00:51 +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=1748595651; cv=none; b=rYIePvZM7IUsjyhmrsRAa28kBz6d8RrjABuqyZ2VcAVqZjf8dSg3Zzqosw4FA4B9w+aWcj9uKErjokWJBOnFj8RZgdx+HvVZ292NtF0pjW8FX16SAbb4/b7Rq7uFKAoPn62aEKHT26y6Q/bvdr1ga1DnbnP7i8jwb725gJdz8QI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595651; c=relaxed/simple;
bh=gNIbx1N9UqqVUej1ctL6a3XA1FWPgsPdOnRM+BgoZi8=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=CH4ToLeF22esUuQow1jcFXYrUmrhzDP3XYMJYeNzoWXZ9cLdaHfXn9pQcRGn/diNLxbIgnCY921JAW7rQNES7uU8B8JVlsLNLmzKZm8+9osMPOZfGZV5gUwWZRz6uTdgrOA9jzT4vP/N+v/NhkFPFUD9fOwVAQAZQZhVXTDtL98=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=ctSgh+iR; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 89F68C4CEE9;
Fri, 30 May 2025 09:00:50 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
s=korg; t=1748595651;
bh=gNIbx1N9UqqVUej1ctL6a3XA1FWPgsPdOnRM+BgoZi8=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=ctSgh+iRBTE0Y46oJJpPc80V1gnDTrbvbXOzn92/BCBveHrTWnWihWl/dUiZNcfDJ
E7woVkfr6xJaBP7/dFRNI4rwarqEw3l/xygMcNazwNX61PMmCknsS+i0TCI2nnZ20P
sF2J3I+X89jk3CFk8tdIQmVcAtZsnzOkhV+xS+BE=
Date: Fri, 30 May 2025 11:00:47 +0200
From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
To: Alexandre Courbot <acourbot@xxxxxxxxxx>
Cc: Danilo Krummrich <dakr@xxxxxxxxxx>, Timur Tabi <timur@xxxxxxxxxx>,
John Hubbard <jhubbard@xxxxxxxxxx>, Miguel Ojeda <ojeda@xxxxxxxxxx>,
Alex Gaynor <alex.gaynor@xxxxxxxxx>,
Boqun Feng <boqun.feng@xxxxxxxxx>, Gary Guo <gary@xxxxxxxxxxx>,
=?iso-8859-1?Q?Bj=F6rn?= Roy Baron <bjorn3_gh@xxxxxxxxxxxxxx>,
Benno Lossin <benno.lossin@xxxxxxxxx>,
Andreas Hindborg <a.hindborg@xxxxxxxxxx>,
Alice Ryhl <aliceryhl@xxxxxxxxxx>, Trevor Gross <tmgross@xxxxxxxxx>,
linux-kernel@xxxxxxxxxxxxxxx, rust-for-linux@xxxxxxxxxxxxxxx
Subject: Re: [PATCH] rust: add basic ELF sections parser
Message-ID: <2025053007-playtime-french-c2fa@gregkh>
References: <D9XMAV4ERYK7.39TLQBLYTX3TU@xxxxxxxxxx>
<aCc_PSOPkLWTcTru@pollux>
<D9XNS413TVXB.3SWWJE4JGEN8B@xxxxxxxxxx>
<CAOZdJXW+PoFgxH+wPEum-kYvRmSRd8c4kaxvbNAq5dfZJiXapA@xxxxxxxxxxxxxx>
<D9Y0VJKOAQAY.2GJSAZ5II54VV@xxxxxxxxxx>
<DA8G3G918FS4.X8D7PQMT4TGB@xxxxxxxxxx>
<2025052932-pyramid-unvisited-68f7@gregkh>
<DA935OIFBM1H.3CMSHQ46LLG4P@xxxxxxxxxx>
<2025053058-siding-emperor-d8fd@gregkh>
<DA9AS88BCFX2.FET64FP3J2WO@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DA9AS88BCFX2.FET64FP3J2WO@xxxxxxxxxx>
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 03:56:37PM +0900, Alexandre Courbot wrote:
> On Fri May 30, 2025 at 3:21 PM JST, Greg KH wrote:
> > On Fri, May 30, 2025 at 09:58:02AM +0900, Alexandre Courbot wrote:
> >> > But for now, doing it in generic code, that all systems end up loading,
> >> > yet very very very few would ever actually use makes no sense. And
> >> > adding it to a driver also doesn't make sense as you can define your
> >> > user/kernel api now, it's not set in stone at all given that there is no
> >> > existing code merged.
> >>
> >> Eschewing this from the driver would require duplicating the GSP
> >> firmware (a healthy 26MB compressed binary) in linux-firmware to provide
> >> both ELF and non-ELF versions of the same code, and also store the other
> >> ELF sections as their own files. I expect this to be a hard sell for
> >> linux-firmware.
> >
> > Why would the linux-firmware people care about the size of firmware
> > blobs being given to them? That's the whole reason for their existance,
> > to put them in one place instead of having to download them from random
> > locations on the internet, or to have them in the kernel tree itself.
> >
> > It's already 300MB or so for the whole project, what's 26MB more?
>
> Roughtly 1/10th of the current total size as avoidable overhead. ^_^;
It's just storage on a disk, that's not an issue. Storage sizes just
increased by more than that in the days we've taken on this email
thread :)
Return-Path: <linux-kernel+bounces-667819-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 7017C41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:01:59 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id BC8FF4E33C8
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:02:00 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 553E21DF72C;
Fri, 30 May 2025 09:01:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="Avn/4MnJ"
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 7D25A219A6B;
Fri, 30 May 2025 09:01:36 +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=1748595696; cv=none; b=C+aoq78/Y3tzqBjU6lgYa5EJOtNq62uRX1rZMqj0hs7xMEtJ/QnqqWJ6HaD1bUk+xXHR9VHmgXeYQcwrTC0VqMjWclF1vrGWRAaYfFdc2ZA2jj6reAQwqMrbJf2wmejraV/Q7TLmr0dGO7ymqJ+ZIzkIlOq8jDQ8tvuw7y96i9M=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595696; c=relaxed/simple;
bh=n2ZjVd2alcKnIdJEGexsGHL5f/SaS0tA+GdWnik0AJA=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=spM6PmS0UMvboPv9YH9GIC2CsJ5VkNl3m5mQzLQNUs/y2ojF18x3I+2hdk3CH/UnvZYTDx5DLfCOfMyqH9eGMyc7Lrtpg4TKOKpgClcZJz2bnBvJ5lU6rQt9rvtZ/af6flcQvyENqgbJfiiBtSfV0wmpsB614Fx1P1DzXoL3rhs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=Avn/4MnJ; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 798A3C4CEE9;
Fri, 30 May 2025 09:01:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org;
s=korg; t=1748595696;
bh=n2ZjVd2alcKnIdJEGexsGHL5f/SaS0tA+GdWnik0AJA=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=Avn/4MnJETTZAVpGapLc++uqRuOHnjEy1YQwrhob1PttsF3wn9f2O5mhPJryZ+mEp
qAwuh7CMsn8cip9NyyLxi7TaBdjk0GoRJWzW7giwrZ3g9GZPLwDuWE6wura//uQ5pw
p8jQl8bcZJLMYM002Hl8GEIRr0mh8FcTMDpFrZg4=
Date: Fri, 30 May 2025 11:01:33 +0200
From: Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx>
To: Alexandre Courbot <acourbot@xxxxxxxxxx>
Cc: Danilo Krummrich <dakr@xxxxxxxxxx>, Timur Tabi <timur@xxxxxxxxxx>,
John Hubbard <jhubbard@xxxxxxxxxx>, Miguel Ojeda <ojeda@xxxxxxxxxx>,
Alex Gaynor <alex.gaynor@xxxxxxxxx>,
Boqun Feng <boqun.feng@xxxxxxxxx>, Gary Guo <gary@xxxxxxxxxxx>,
=?iso-8859-1?Q?Bj=F6rn?= Roy Baron <bjorn3_gh@xxxxxxxxxxxxxx>,
Benno Lossin <benno.lossin@xxxxxxxxx>,
Andreas Hindborg <a.hindborg@xxxxxxxxxx>,
Alice Ryhl <aliceryhl@xxxxxxxxxx>, Trevor Gross <tmgross@xxxxxxxxx>,
linux-kernel@xxxxxxxxxxxxxxx, rust-for-linux@xxxxxxxxxxxxxxx
Subject: Re: [PATCH] rust: add basic ELF sections parser
Message-ID: <2025053050-maggot-landfall-d5eb@gregkh>
References: <D9XMAV4ERYK7.39TLQBLYTX3TU@xxxxxxxxxx>
<aCc_PSOPkLWTcTru@pollux>
<D9XNS413TVXB.3SWWJE4JGEN8B@xxxxxxxxxx>
<CAOZdJXW+PoFgxH+wPEum-kYvRmSRd8c4kaxvbNAq5dfZJiXapA@xxxxxxxxxxxxxx>
<D9Y0VJKOAQAY.2GJSAZ5II54VV@xxxxxxxxxx>
<DA8G3G918FS4.X8D7PQMT4TGB@xxxxxxxxxx>
<2025052932-pyramid-unvisited-68f7@gregkh>
<DA935OIFBM1H.3CMSHQ46LLG4P@xxxxxxxxxx>
<2025053047-theology-unsaid-d6ac@gregkh>
<DA9AU3OBT29Z.3CX827C91I3IH@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DA9AU3OBT29Z.3CX827C91I3IH@xxxxxxxxxx>
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 03:59:03PM +0900, Alexandre Courbot wrote:
> On Fri May 30, 2025 at 3:22 PM JST, Greg KH wrote:
> > On Fri, May 30, 2025 at 09:58:02AM +0900, Alexandre Courbot wrote:
> >> However, Nova also supports a couple of older chip generations that use
> >> the same GSP firmware - it is for these that the ELF unpacking must
> >> occur in the kernel. IIUC this has to do with the capabilities of the
> >> microcontroller that ultimately does the loading (more capable RISC-V on
> >> Hopper+ vs. older and more limited Falcon).
> >
> > Why specifically does the kernel have to get involved here? What
> > requires it to do it that userspace can not?
>
> I don't know of a user-space tool that is readily available and could
> perform such extraction of the ELF content upon kernel request. Is there
> anything like this?
libelf provides you with the needed tools for this.
And you didn't answer my question.
Return-Path: <linux-kernel+bounces-667820-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 92E8741E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:04:44 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 550503A962C
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:04:23 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 9790A21C19B;
Fri, 30 May 2025 09:04:39 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 9DB551DF72C
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:04:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595879; cv=none; b=pqYZSe1jrTiefpC0Py8dW2pdzPz0lg6pIr1pgvrsdpkUZCsRPUzugtDuDkg9XEaK6mMRb/ZXSno26Ak3VSyNOYBQygStGd9+7J/boOcWVRz+/FGDlTO0cRpOD5nqIPL92MMCLwhfyrUTKEJNyxaOgSwLVf1spcWp9RH9iBP5tR0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595879; c=relaxed/simple;
bh=lisLegOy+6lXxdxDg5/m1b7CL468MwUWemew7FNpzIQ=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=WtQyhlUBkuVXXdn3PINgkbelfkQp5gAKJnAqWN+l/N5oTPCPC7ty/a/eTc6T72Cyj2j1iRNV3qap0TspvxWRD//jUv2MTCjkSC5lAZ/Um6xZI7Du6JFvhjYWv0io07gt/ZspoqUrBHvocUxUszD9AGx9kBJFwS7f3olqIdcfozQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 919E116F8;
Fri, 30 May 2025 02:04:20 -0700 (PDT)
Received: from MacBook-Pro.blr.arm.com (unknown [10.164.18.49])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id F3C603F5A1;
Fri, 30 May 2025 02:04:31 -0700 (PDT)
From: Dev Jain <dev.jain@xxxxxxx>
To: akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
catalin.marinas@xxxxxxx,
will@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
suzuki.poulose@xxxxxxx,
steven.price@xxxxxxx,
gshan@xxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
Dev Jain <dev.jain@xxxxxxx>
Subject: [PATCH 1/3] mm: Allow pagewalk without locks
Date: Fri, 30 May 2025 14:34:05 +0530
Message-Id: <20250530090407.19237-2-dev.jain@xxxxxxx>
X-Mailer: git-send-email 2.39.3 (Apple Git-146)
In-Reply-To: <20250530090407.19237-1-dev.jain@xxxxxxx>
References: <20250530090407.19237-1-dev.jain@xxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
It is noted at [1] that KFENCE can manipulate kernel pgtable entries during
softirqs. It does this by calling set_memory_valid() -> __change_memory_common().
This being a non-sleepable context, we cannot take the init_mm mmap lock.
Therefore, add PGWALK_NOLOCK to enable walk_page_range_novma() usage without
locks.
[1] https://lore.kernel.org/linux-arm-kernel/89d0ad18-4772-4d8f-ae8a-7c48d26a927e@xxxxxxx/
Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
---
include/linux/pagewalk.h | 2 ++
mm/pagewalk.c | 12 ++++++++----
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
index 9700a29f8afb..9bc8853ed3de 100644
--- a/include/linux/pagewalk.h
+++ b/include/linux/pagewalk.h
@@ -14,6 +14,8 @@ enum page_walk_lock {
PGWALK_WRLOCK = 1,
/* vma is expected to be already write-locked during the walk */
PGWALK_WRLOCK_VERIFY = 2,
+ /* no lock is needed */
+ PGWALK_NOLOCK = 3,
};
/**
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index e478777c86e1..9657cf4664b2 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -440,6 +440,8 @@ static inline void process_vma_walk_lock(struct vm_area_struct *vma,
case PGWALK_RDLOCK:
/* PGWALK_RDLOCK is handled by process_mm_walk_lock */
break;
+ default:
+ break;
}
#endif
}
@@ -640,10 +642,12 @@ int walk_page_range_novma(struct mm_struct *mm, unsigned long start,
* specified address range from being freed. The caller should take
* other actions to prevent this race.
*/
- if (mm == &init_mm)
- mmap_assert_locked(walk.mm);
- else
- mmap_assert_write_locked(walk.mm);
+ if (ops->walk_lock != PGWALK_NOLOCK) {
+ if (mm == &init_mm)
+ mmap_assert_locked(walk.mm);
+ else
+ mmap_assert_write_locked(walk.mm);
+ }
return walk_pgd_range(start, end, &walk);
}
--
2.30.2
Return-Path: <linux-kernel+bounces-667821-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 7C55C41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:04:52 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id DFD0F3A9359
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:04:30 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 71D2221D5B3;
Fri, 30 May 2025 09:04:40 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 9DBC61EA7C8
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:04:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595880; cv=none; b=ptmSV55szqoFmnsDZRF5LjvrkW09xxEGSUa6/2T9QsNv9gZ6nBXUgmL7S7vEhgYjK7oUcDn+iNorGJ1amCp2oC8NWK0Xuh4uxOqU6H1fuiGqA/8TIr13zsa9KSI+tLLiFeuvqlCzzSOj+yq2EwdBNS6y74QGRgljxUgwaPmb6Tw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595880; c=relaxed/simple;
bh=yOFcaTxur21zbSiID2EWQvG4SWrWx29LLjAgy8jkHkU=;
h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=sVL4vfgP3XJ6Gqtz8WVFi5lTUs5/L2wCmjljwi3Hyk52/g7s21jPdpsEVxxDfdbkdsV3MJXCtklDKJqMtlYjsAMcXOYBwJxWZi5IM42zkpzscDejmnLRnj9jZeqhf5zP6fZktLqrV2wf8tVnMrmNoXYbCB0x6477AR8z3VQrtGY=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 27EB116F2;
Fri, 30 May 2025 02:04:15 -0700 (PDT)
Received: from MacBook-Pro.blr.arm.com (unknown [10.164.18.49])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5CF463F5A1;
Fri, 30 May 2025 02:04:26 -0700 (PDT)
From: Dev Jain <dev.jain@xxxxxxx>
To: akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
catalin.marinas@xxxxxxx,
will@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
suzuki.poulose@xxxxxxx,
steven.price@xxxxxxx,
gshan@xxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
Dev Jain <dev.jain@xxxxxxx>
Subject: [PATCH 0/3] Enable huge-vmalloc permission change
Date: Fri, 30 May 2025 14:34:04 +0530
Message-Id: <20250530090407.19237-1-dev.jain@xxxxxxx>
X-Mailer: git-send-email 2.39.3 (Apple Git-146)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
This series paves the path to enable huge mappings in vmalloc space by
default on arm64. For this we must ensure that we can handle any permission
games on vmalloc space. Currently, __change_memory_common() uses
apply_to_page_range() which does not support changing permissions for
leaf mappings. We attempt to move away from this by using walk_page_range_novma(),
similar to what riscv does right now; however, it is the responsibility
of the caller to ensure that we do not pass a range, or split the range
covering a partial leaf mapping.
This series is tied with Yang Shi's attempt [1] at using huge mappings
in the linear mapping in case the system supports BBML2, in which case
we will be able to split the linear mapping if needed without break-before-make.
Thus, Yang's series, IIUC, will be one such user of my series; suppose we
are changing permissions on a range of the linear map backed by PMD-hugepages,
then the sequence of operations should look like the following:
split_range(start, (start + HPAGE_PMD_SIZE) & ~HPAGE_PMD_MASK);
split_range(end & ~HPAGE_PMD_MASK, end);
__change_memory_common(start, end);
However, this series can be used independently of Yang's; since currently
permission games are being played only on pte mappings (due to apply_to_page_range
not supporting otherwise), this series provides the mechanism for enabling
huge mappings for various kernel mappings like linear map and vmalloc.
[1] https://lore.kernel.org/all/20250304222018.615808-1-yang@xxxxxxxxxxxxxxxxxxxxxx/
Dev Jain (3):
mm: Allow pagewalk without locks
arm64: pageattr: Use walk_page_range_novma() to change memory
permissions
mm/pagewalk: Add pre/post_pte_table callback for lazy MMU on arm64
arch/arm64/mm/pageattr.c | 81 +++++++++++++++++++++++++++++++++++++---
include/linux/pagewalk.h | 4 ++
mm/pagewalk.c | 18 +++++++--
3 files changed, 94 insertions(+), 9 deletions(-)
--
2.30.2
Return-Path: <linux-kernel+bounces-667822-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 7FFD241E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:05:06 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id A40673BCB9B
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:04:42 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8D27721C19B;
Fri, 30 May 2025 09:04:45 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 5C7571EA7C8
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:04:43 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595885; cv=none; b=GZsGN48hHRZIk6y6gdnl2KSIWqvK8ieUbpfHINT4gAedHWPj1upibNvyN8hdG4jkBUiqyMiQC/UKMuJKOxs/GfyFVDQmGfPRv0I9S0R3TWvmumuUpjBiVirbWNAfLiGit6pMt1KoEeuFAohT7PQoI0B32x14tCj02tLJs1GlWCU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595885; c=relaxed/simple;
bh=6i4rPvsVO9h/V46TCoPoAC/yg8N1XCm+jf/47OrvZJI=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=fZA6xd7okBsBH76+aznHVjPtSM8EZ2g/WmIJVlxuzeI7F0IL1MEGic2pFCnNVUDS9QpciTeFIwiuBFIKtSVCfLGUQBYyuNLNlgO2AuYKntNf/M0bMcwUL04/5c2g5Xf312XmlEWrkdJxf9n86KTNmKl2/yLKX2YDoDMC0V89170=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3CDAC16F2;
Fri, 30 May 2025 02:04:26 -0700 (PDT)
Received: from MacBook-Pro.blr.arm.com (unknown [10.164.18.49])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 9ED583F5A1;
Fri, 30 May 2025 02:04:37 -0700 (PDT)
From: Dev Jain <dev.jain@xxxxxxx>
To: akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
catalin.marinas@xxxxxxx,
will@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
suzuki.poulose@xxxxxxx,
steven.price@xxxxxxx,
gshan@xxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
Dev Jain <dev.jain@xxxxxxx>
Subject: [PATCH 2/3] arm64: pageattr: Use walk_page_range_novma() to change memory permissions
Date: Fri, 30 May 2025 14:34:06 +0530
Message-Id: <20250530090407.19237-3-dev.jain@xxxxxxx>
X-Mailer: git-send-email 2.39.3 (Apple Git-146)
In-Reply-To: <20250530090407.19237-1-dev.jain@xxxxxxx>
References: <20250530090407.19237-1-dev.jain@xxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Move away from apply_to_page_range(), which does not honour leaf mappings,
to walk_page_range_novma(). The callbacks emit a warning and return EINVAL
if a partial range is detected.
Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
---
arch/arm64/mm/pageattr.c | 69 +++++++++++++++++++++++++++++++++++++---
1 file changed, 64 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 39fd1f7ff02a..a5c829c64969 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -8,6 +8,7 @@
#include <linux/mem_encrypt.h>
#include <linux/sched.h>
#include <linux/vmalloc.h>
+#include <linux/pagewalk.h>
#include <asm/cacheflush.h>
#include <asm/pgtable-prot.h>
@@ -20,6 +21,67 @@ struct page_change_data {
pgprot_t clear_mask;
};
+static pteval_t set_pageattr_masks(unsigned long val, struct mm_walk *walk)
+{
+ struct page_change_data *masks = walk->private;
+ unsigned long new_val = val;
+
+ new_val &= ~(pgprot_val(masks->clear_mask));
+ new_val |= (pgprot_val(masks->set_mask));
+
+ return new_val;
+}
+
+static int pageattr_pud_entry(pud_t *pud, unsigned long addr,
+ unsigned long next, struct mm_walk *walk)
+{
+ pud_t val = pudp_get(pud);
+
+ if (pud_leaf(val)) {
+ if (WARN_ON_ONCE((next - addr) != PUD_SIZE))
+ return -EINVAL;
+ val = __pud(set_pageattr_masks(pud_val(val), walk));
+ set_pud(pud, val);
+ walk->action = ACTION_CONTINUE;
+ }
+
+ return 0;
+}
+
+static int pageattr_pmd_entry(pmd_t *pmd, unsigned long addr,
+ unsigned long next, struct mm_walk *walk)
+{
+ pmd_t val = pmdp_get(pmd);
+
+ if (pmd_leaf(val)) {
+ if (WARN_ON_ONCE((next - addr) != PMD_SIZE))
+ return -EINVAL;
+ val = __pmd(set_pageattr_masks(pmd_val(val), walk));
+ set_pmd(pmd, val);
+ walk->action = ACTION_CONTINUE;
+ }
+
+ return 0;
+}
+
+static int pageattr_pte_entry(pte_t *pte, unsigned long addr,
+ unsigned long next, struct mm_walk *walk)
+{
+ pte_t val = ptep_get(pte);
+
+ val = __pte(set_pageattr_masks(pte_val(val), walk));
+ set_pte(pte, val);
+
+ return 0;
+}
+
+static const struct mm_walk_ops pageattr_ops = {
+ .pud_entry = pageattr_pud_entry,
+ .pmd_entry = pageattr_pmd_entry,
+ .pte_entry = pageattr_pte_entry,
+ .walk_lock = PGWALK_NOLOCK,
+};
+
bool rodata_full __ro_after_init = IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED);
bool can_set_direct_map(void)
@@ -49,9 +111,6 @@ static int change_page_range(pte_t *ptep, unsigned long addr, void *data)
return 0;
}
-/*
- * This function assumes that the range is mapped with PAGE_SIZE pages.
- */
static int __change_memory_common(unsigned long start, unsigned long size,
pgprot_t set_mask, pgprot_t clear_mask)
{
@@ -61,8 +120,8 @@ static int __change_memory_common(unsigned long start, unsigned long size,
data.set_mask = set_mask;
data.clear_mask = clear_mask;
- ret = apply_to_page_range(&init_mm, start, size, change_page_range,
- &data);
+ ret = walk_page_range_novma(&init_mm, start, start + size,
+ &pageattr_ops, NULL, &data);
/*
* If the memory is being made valid without changing any other bits
--
2.30.2
Return-Path: <linux-kernel+bounces-667823-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9D44841E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:05:15 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 11C497A7727
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:03:57 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id BDF8821D3DC;
Fri, 30 May 2025 09:04:50 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id F33291EA7C8
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:04:48 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595890; cv=none; b=F6Ydh1Vuss7g6UQqzqmhEFLNOgvcviuu49B8V84eCI3u4aUCDhkNuloDgMLsQRict9WlafcdNKUSvNn2OB6Fea6ngj1z6/wBg37aCzeV711OUmFvBiWXJxKTRHu2MiXboxLA1XuW49DKOnE8pyazxZ5jjzpIYkxfrypVE85mVPk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595890; c=relaxed/simple;
bh=WgIs+0mJhsMumzatCo5VihW3PL80BvxaPeuR0E/W8JE=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=ndYJ9jrvooKxJ4Yp4v2dhqla+LvHInliFeoDRQZsh1MqvonZ2O9RZ+CeW33s3Rsw8pncmHYqcIuB+g5UTiieuxtyi0AG1m+kCK8vOhNJLP5o5/1F5+4gM/lgdy+8ZYZHAlCRNTRhBiXDOBkB2YeBIgYtf1oikIkHbDKZ1sWYVqo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DBC9516F2;
Fri, 30 May 2025 02:04:31 -0700 (PDT)
Received: from MacBook-Pro.blr.arm.com (unknown [10.164.18.49])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4A0CF3F5A1;
Fri, 30 May 2025 02:04:43 -0700 (PDT)
From: Dev Jain <dev.jain@xxxxxxx>
To: akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
catalin.marinas@xxxxxxx,
will@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
suzuki.poulose@xxxxxxx,
steven.price@xxxxxxx,
gshan@xxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
Dev Jain <dev.jain@xxxxxxx>
Subject: [PATCH 3/3] mm/pagewalk: Add pre/post_pte_table callback for lazy MMU on arm64
Date: Fri, 30 May 2025 14:34:07 +0530
Message-Id: <20250530090407.19237-4-dev.jain@xxxxxxx>
X-Mailer: git-send-email 2.39.3 (Apple Git-146)
In-Reply-To: <20250530090407.19237-1-dev.jain@xxxxxxx>
References: <20250530090407.19237-1-dev.jain@xxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
arm64 implements lazy_mmu_mode to allow deferral and batching of barriers
when updating kernel PTEs, which provides a nice performance boost. arm64
currently uses apply_to_page_range() to modify kernel PTE permissions,
which runs inside lazy_mmu_mode. So to prevent a performance regression,
let's add hooks to walk_page_range_novma() to allow continued use of
lazy_mmu_mode.
Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
---
Credits to Ryan for the patch description.
arch/arm64/mm/pageattr.c | 12 ++++++++++++
include/linux/pagewalk.h | 2 ++
mm/pagewalk.c | 6 ++++++
3 files changed, 20 insertions(+)
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index a5c829c64969..9163324b12a0 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -75,11 +75,23 @@ static int pageattr_pte_entry(pte_t *pte, unsigned long addr,
return 0;
}
+static void pte_lazy_mmu_enter(void)
+{
+ arch_enter_lazy_mmu_mode();
+}
+
+static void pte_lazy_mmu_leave(void)
+{
+ arch_leave_lazy_mmu_mode();
+}
+
static const struct mm_walk_ops pageattr_ops = {
.pud_entry = pageattr_pud_entry,
.pmd_entry = pageattr_pmd_entry,
.pte_entry = pageattr_pte_entry,
.walk_lock = PGWALK_NOLOCK,
+ .pre_pte_table = pte_lazy_mmu_enter,
+ .post_pte_table = pte_lazy_mmu_leave,
};
bool rodata_full __ro_after_init = IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED);
diff --git a/include/linux/pagewalk.h b/include/linux/pagewalk.h
index 9bc8853ed3de..2157d345974c 100644
--- a/include/linux/pagewalk.h
+++ b/include/linux/pagewalk.h
@@ -88,6 +88,8 @@ struct mm_walk_ops {
int (*pre_vma)(unsigned long start, unsigned long end,
struct mm_walk *walk);
void (*post_vma)(struct mm_walk *walk);
+ void (*pre_pte_table)(void);
+ void (*post_pte_table)(void);
int (*install_pte)(unsigned long addr, unsigned long next,
pte_t *ptep, struct mm_walk *walk);
enum page_walk_lock walk_lock;
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index 9657cf4664b2..a441f5cbbc45 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -33,6 +33,9 @@ static int walk_pte_range_inner(pte_t *pte, unsigned long addr,
const struct mm_walk_ops *ops = walk->ops;
int err = 0;
+ if (walk->ops->pre_pte_table)
+ walk->ops->pre_pte_table();
+
for (;;) {
if (ops->install_pte && pte_none(ptep_get(pte))) {
pte_t new_pte;
@@ -56,6 +59,9 @@ static int walk_pte_range_inner(pte_t *pte, unsigned long addr,
addr += PAGE_SIZE;
pte++;
}
+
+ if (walk->ops->post_pte_table)
+ walk->ops->post_pte_table();
return err;
}
--
2.30.2
Return-Path: <linux-kernel+bounces-667824-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 305DE41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:06:29 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 15ABB1BC37D1
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:06:42 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 77D0321CFE0;
Fri, 30 May 2025 09:06:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=fail reason="signature verification failed" (2048-bit key) header.d=bit-philosophy.net header.i=@bit-philosophy.net header.b="pN5urq9Y"
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.55])
(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 8188221C19B
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:06:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=194.63.252.55
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748595981; cv=none; b=lpkVnH/vFQoygixp6RsLQC1LXxe0h86wSSLnXLK1K1xvyn+k7rQC0ISjibZOBYWwKSruK2gNNQGOrUBfYVomlYyBQXsMAm0ERrPWGKt0j9OK7SQI07htqePVERRPv8wTXVcX7FbYGyIJG6F89lyOWGbenGbhi6pgTV5IwlYfTWM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748595981; c=relaxed/simple;
bh=bxQMzxNhia+6ZXQDuN6obyd0azK05G5bLOSYlyomuSo=;
h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type; b=WJfpEFxuCPx+c4q8ktkbM8eNQ8xRxHozFcpXkUseew+L0cvs438Nri/gQ37J6kJkt2nbYoV1bkk81px7WZunnaNDfJvVVIOYMv8ivoAJTQ6wJDT4BLeqJ4cKDuLP6SBKmgPH7VbV7lv6YOZEeS1lyEthb4zEuVQ6YFlLTTtc+iA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bit-philosophy.net; spf=pass smtp.mailfrom=bit-philosophy.net; dkim=pass (2048-bit key) header.d=bit-philosophy.net header.i=@bit-philosophy.net header.b=pN5urq9Y; arc=none smtp.client-ip=194.63.252.55
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bit-philosophy.net
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bit-philosophy.net
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=bit-philosophy.net; s=ds202411; h=Content-Transfer-Encoding:Content-Type:
Subject:From:To:MIME-Version:Date:Message-ID:From:Sender:Reply-To:Subject:
Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
bh=e5XPgjVWWMJIYR8N9QzQ5DcnNAdQRMECJP8Vjil3Mm4=; b=pN5urq9YXjiR7iDjM4cCgcNAVx
mFwkCS/qbCjhCn3Y/QVjrF2aZG2AFOb0ULm+AfLJz93kMJuygliQk9dMYrrpjPO10QzWJM+a61JmH
lr0UJQGCpESTETU37nD5PDEzW0YjFqb/aZZN4OCrcXX2KQHywmt2rT0XgnMwP2lSHwho9QOL14QBe
rQsBWVfEsWpBzyNALpsBbS9Gg3rTcLGT55jDwMumPSt+xc9hDH41npVVAg7uleWVaSG7SIPZLp4zR
E5CZGpftAiJOUlls2MgoVWygZGNk9wAbXpmfDg0HNiif2e8hIB41aX65qqxRWeZrSuhMIzSLIImwL
opKUygEw==;
Received: from smtp
by smtp.domeneshop.no with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.95)
id 1uKuH2-00Elno-Sz
for linux-kernel@xxxxxxxxxxxxxxx;
Fri, 30 May 2025 09:35:28 +0200
Message-ID: <1b80772e-6308-4bb7-9112-4be6a43d9b3f@xxxxxxxxxxxxxxxxxx>
Date: Fri, 30 May 2025 09:35:29 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: linux-kernel@xxxxxxxxxxxxxxx
From: =?UTF-8?Q?Ywe_C=C3=A6rlyn?= <budi@xxxxxxxxxxxxxxxxxx>
Subject: A Note On Wayland (was Fair Pay Philosophy, Low Jitter)
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
A note on Wayland. It seems to be X, through "Satan".
That seems to be a bit of a problem, that some think a thing like that
is needed.
I rather prefer a 1:1 reality naming. The background philosophy I do,
supports that.
X is actually that, symbolcorrect.
"Ya" also changes naming, for instance Bitstream OS, would be "Mandrake
OS", there.
Here one needs to take a philosophical standpoint.
My research is at: https://bit-philosophy.net/
(with full support for Obes and all relevant science, instead of Lamb
Churches.)
Light!,
Ywe Cærlyn,
Budi (iMAM)
Bitstream OS.
Return-Path: <linux-kernel+bounces-667825-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id B944541E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:07:26 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 8B7557AE121
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:06:08 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 154F721CC64;
Fri, 30 May 2025 09:07:18 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 4390113A244;
Fri, 30 May 2025 09:07:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596037; cv=none; b=FIfEnRUZ/ZNszRGrouF3gR3Ktv/sokYwZrEbdTJBJz0EeifzsRK7lVm6o1iKezItWyBp1gGpCV8fGZWco5cJvps3RO1we1h4oaohc8iBlGrnLKN7+j5wkx0PR0DAtX0yqIX9hQRCbEamq+2nItDl/qBkZi5g++xH0temu3eaPP4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596037; c=relaxed/simple;
bh=iViSuV0R+rv+QTUVkg89jRMRkjWH+ao1h5/HuE8kknI=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=ednUkCryZrhHxj7Qc9gyWS3buzvPa/6ioQs07MXASkP7ZyvY8X/8jnMJTii98a2bF3uEcocoBUZZGS53by/p3k+stjZz0OaQYPzETKIvkF4aVFsH74BzKWL4lHzDUe1fES9Q0I3U6AqsK0JEtvNetNAa4dtV6DmO+JgfOojkFp0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2882016F2;
Fri, 30 May 2025 02:06:58 -0700 (PDT)
Received: from [10.57.95.14] (unknown [10.57.95.14])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BFAAD3F5A1;
Fri, 30 May 2025 02:07:12 -0700 (PDT)
Message-ID: <00999fc3-3a4a-4ee5-8021-81c73253fe7f@xxxxxxx>
Date: Fri, 30 May 2025 10:07:11 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
Content-Language: en-GB
To: David Hildenbrand <david@xxxxxxxxxx>,
Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
Cc: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
<f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
<ade3bdb7-7103-4ecd-bce2-7768a0d729ef@lucifer.local>
<9c920642-228b-4eb0-920a-269473ea824e@xxxxxxxxxx>
From: Ryan Roberts <ryan.roberts@xxxxxxx>
In-Reply-To: <9c920642-228b-4eb0-920a-269473ea824e@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30/05/2025 09:52, David Hildenbrand wrote:
> On 30.05.25 10:47, Lorenzo Stoakes wrote:
>> On Fri, May 30, 2025 at 10:44:36AM +0200, David Hildenbrand wrote:
>>> On 30.05.25 10:04, Ryan Roberts wrote:
>>>> On 29/05/2025 09:23, Baolin Wang wrote:
>>>>> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
>>>>> the system-wide anon/shmem THP sysfs settings, which means that even though
>>>>> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
>>>>> attempt to collapse into a anon/shmem THP. This violates the rule we have
>>>>> agreed upon: never means never. This patch set will address this issue.
>>>>
>>>> This is a drive-by comment from me without having the previous context, but...
>>>>
>>>> Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
>>>> user-initiated, synchonous request to use huge pages for a range of memory.
>>>> There is nothing *transparent* about it, it just happens to be implemented
>>>> using
>>>> the same logic that THP uses.
>>>>
>>>> I always thought this was a deliberate design decision.
>>>
>>> If the admin said "never", then why should a user be able to overwrite that?
>>>
>>> The design decision I recall is that if VM_NOHUGEPAGE is set, we'll ignore
>>> that. Because that was set by the app itself (MADV_NOHUEPAGE).
>>>
>>
>> I'm with David on this one.
>>
>> I think it's principal of least surprise - to me 'never' is pretty
>> emphatic, and keep in mind the other choices are 'always' and... 'madvise'
>> :) which explicitly is 'hey only do this if madvise tells you to'.
I think it's a bit reductive to suggest that enabled=madvise means all madvise
calls though. I don't think anyone would suggest MADV_DONTNEED should be ignored
if enabled=never. MADV_COLLAPSE just happens to be implemented on top of the THP
logic. But it's a different feature in my view.
>>
>> I'd be rather surprised if I hadn't set madvise and a user uses madvise to
>> in some fashion override the never.
>>
>> I mean I think we all agree this interface is to use a technical term -
>> crap - and we need something a lot more fine-grained and smart,
Yes agreed there!
>> but I think
>> given the situation we're in we should make it at least as least surprising
>> as possible.
>
> Yes. If you configure "never" you are supposed to suffer, consistently.
>
OK fair enough. Just giving my 2 cents.
Return-Path: <linux-kernel+bounces-667826-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 2046441E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:07:37 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id C019F7B0D4E
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:06:18 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8FA4621ABB2;
Fri, 30 May 2025 09:07:30 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 7EE3F13A244
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:07:28 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596050; cv=none; b=cLEYfclYVuapPg2zHA+EawxZVX4FRkkqTaDuwpGB2nNHXskZXyfG/pR59zc7S9KBK1PZr15lqeknsEOlJlsehl05yQENnJgTQE98n2/9MP5RQYuKeiypI5D72jcnpPb4Bh2hFdOxl0SNqzwJth6chapYSlA3GTH3XM2PJjgWccU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596050; c=relaxed/simple;
bh=GuRI26xNCcNPO1aRKK1gzVgzkDvatC1ZjerHF3sx7CU=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=ljGtLbQLANdAQeKSGbslfM4SjyB2611Fy0Syi7qQRwbLsxeZ+EJm9wC77shOOJHXnepfzk44BnwztXNFtj1F8qZqINGW2LSExl++PKhBW1dAhd3gbVkhZ/2+On/kzWjb8NIaZdlG507tSiPagT3iv+XSwwPcROvfOFwKsNr6eWs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 63F6F16F2;
Fri, 30 May 2025 02:07:11 -0700 (PDT)
Received: from [10.164.18.46] (a077893.blr.arm.com [10.164.18.46])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5AC7B3F5A1;
Fri, 30 May 2025 02:07:24 -0700 (PDT)
Message-ID: <9b605943-cac0-447f-9cd0-286a45a937c4@xxxxxxx>
Date: Fri, 30 May 2025 14:37:20 +0530
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: Enable vmalloc-huge with ptdump
To: Ryan Roberts <ryan.roberts@xxxxxxx>, Dev Jain <dev.jain@xxxxxxx>,
catalin.marinas@xxxxxxx, will@xxxxxxxxxx
Cc: quic_zhenhuah@xxxxxxxxxxx, kevin.brodsky@xxxxxxx,
yangyicong@xxxxxxxxxxxxx, joey.gouly@xxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
david@xxxxxxxxxx
References: <20250530082021.18182-1-dev.jain@xxxxxxx>
<d2b63b97-232e-4d2e-816b-71fd5b0ffcfa@xxxxxxx>
Content-Language: en-US
From: Anshuman Khandual <anshuman.khandual@xxxxxxx>
In-Reply-To: <d2b63b97-232e-4d2e-816b-71fd5b0ffcfa@xxxxxxx>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 5/30/25 14:10, Ryan Roberts wrote:
> On 30/05/2025 09:20, Dev Jain wrote:
>> arm64 disables vmalloc-huge when kernel page table dumping is enabled,
>> because an intermediate table may be removed, potentially causing the
>> ptdump code to dereference an invalid address. We want to be able to
>> analyze block vs page mappings for kernel mappings with ptdump, so to
>> enable vmalloc-huge with ptdump, synchronize between page table removal in
>> pmd_free_pte_page()/pud_free_pmd_page() and ptdump pagetable walking. We
>> use mmap_read_lock and not write lock because we don't need to synchronize
>> between two different vm_structs; two vmalloc objects running this same
>> code path will point to different page tables, hence there is no race.
>>
>> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
>> ---
>> arch/arm64/include/asm/vmalloc.h | 6 ++----
>> arch/arm64/mm/mmu.c | 7 +++++++
>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
>> index 38fafffe699f..28b7173d8693 100644
>> --- a/arch/arm64/include/asm/vmalloc.h
>> +++ b/arch/arm64/include/asm/vmalloc.h
>> @@ -12,15 +12,13 @@ static inline bool arch_vmap_pud_supported(pgprot_t prot)
>> /*
>> * SW table walks can't handle removal of intermediate entries.
>> */
>> - return pud_sect_supported() &&
>> - !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
>> + return pud_sect_supported();
>> }
>>
>> #define arch_vmap_pmd_supported arch_vmap_pmd_supported
>> static inline bool arch_vmap_pmd_supported(pgprot_t prot)
>> {
>> - /* See arch_vmap_pud_supported() */
>> - return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
>> + return true;
>> }
>>
>> #endif
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index ea6695d53fb9..798cebd9e147 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1261,7 +1261,11 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
>> }
>>
>> table = pte_offset_kernel(pmdp, addr);
>> +
>> + /* Synchronize against ptdump_walk_pgd() */
>> + mmap_read_lock(&init_mm);
>> pmd_clear(pmdp);
>> + mmap_read_unlock(&init_mm);
>
> So this works because ptdump_walk_pgd() takes the write_lock (which is mutually
> exclusive with any read_lock holders) for the duration of the table walk, so it
> will either consistently see the pgtables before or after this removal. It will
> never disappear during the walk, correct?
Agreed.
>
> I guess there is a risk of this showing up as contention with other init_mm
> write_lock holders. But I expect that pmd_free_pte_page()/pud_free_pmd_page()
> are called sufficiently rarely that the risk is very small. Let's fix any perf
> problem if/when we see it.
Checking against CONFIG_PTDUMP_DEBUGFS being enabled is simple enough without much
cost. So why not make this conditional only for scenarios, where this read lock is
really required. Something like
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1293,11 +1293,15 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
pmd_free_pte_page(pmdp, next);
} while (pmdp++, next += PMD_SIZE, next != end);
- /* Synchronize against ptdump_walk_pgd() */
- mmap_read_lock(&init_mm);
- pud_clear(pudp);
- mmap_read_unlock(&init_mm);
__flush_tlb_kernel_pgtable(addr);
+ if (IS_ENABLED(CONFIG_PTDUMP_DEBUGFS)) {
+ /* Synchronize against ptdump_walk_pgd() */
+ mmap_read_lock(&init_mm);
+ pud_clear(pudp);
+ mmap_read_unlock(&init_mm);
+ } else {
+ pud_clear(pudp);
+ }
pmd_free(NULL, table);
return 1;
}
>
>> __flush_tlb_kernel_pgtable(addr);
>
> And the tlbi doesn't need to be serialized because there is no security issue.
> The walker can be trusted to only dereference memory that it sees as it walks
> the pgtable (obviously).
Agreed.
>
>> pte_free_kernel(NULL, table);
>> return 1;
>> @@ -1289,7 +1293,10 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
>> pmd_free_pte_page(pmdp, next);
>> } while (pmdp++, next += PMD_SIZE, next != end);
>>
>> + /* Synchronize against ptdump_walk_pgd() */
>> + mmap_read_lock(&init_mm);
>> pud_clear(pudp);
>> + mmap_read_unlock(&init_mm);
>
> Hmm, so pud_free_pmd_page() is now going to cause us to acquire and release the
> (upto) lock 513 times (for a 4K kernel). I wonder if there is an argument for
> clearing the pud first (under the lock), then the pmds can all be cleared
> without a lock, since the walker won't be able to see the pmds once the pud is
> cleared.
Makes sense if pud_free_pmd_page() would have been the only caller but seems like
vmap_try_huge_pmd() calls pmd_free_pte_page() directly as well.
>
> Thanks,
> Ryan
>
>> __flush_tlb_kernel_pgtable(addr);
>> pmd_free(NULL, table);
>> return 1;
>
Return-Path: <linux-kernel+bounces-667827-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 8B18F41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:07:48 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 73D7BA236A0
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:07:23 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id F1C2C21B192;
Fri, 30 May 2025 09:07:40 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="bfGIKTkI"
Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54])
(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 B319C1EB5D8
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:07:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596060; cv=none; b=HVWGgFRu5CLVtIURio40Uiz23+qgx2NTYQwiHCIBsiulxGGsC/hwpfKVhktiVWiW0+YT15a3AHD9c3XIBmRVxviZ4h0yBhRdBK6CSoyZlBvaLQJffFxHhlCMUIsHBsiDxrec7Tc/HBzOJm61v6oHCO5TX4mmlobL8ucppR2TJ4Q=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596060; c=relaxed/simple;
bh=h+TkNw1WSw5h2ie4iNPmD4FUqfKlAYlww7F89EL7Zj8=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=pE+gbp6NcYWMYBqSGkRWlH02VeMaP1UbyG3l/OvNqV1AsEY7XF5tzndph+CefFiPtHIkm2vQry2pLvrlxcqfgIvNiJqh6nDXo6DfCWskF+9r1py4nbkT8VtBbF9F5P/nHyBcQ7yFxOzphIWq+t9jIbnOXqQWRmRtpq8TlURqA0c=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=bfGIKTkI; arc=none smtp.client-ip=209.85.128.54
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com
Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4508287895dso16088895e9.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:07:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=suse.com; s=google; t=1748596056; x=1749200856; darn=vger.kernel.org;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
bh=TBoLdDgTszvKcfmqb+9eLVb2IyFbtgcQV42UVzWvyCE=;
b=bfGIKTkIbHwJ+9159+XtKHc/+B8CbqncqsKUB0RdiW/swP7j1VTEDyd1s65kS5HzbF
W7FSgVKOGrG05f75afqWkX8Fduc42BFl5Rs9V7+Bp7wHqNEB8fEHLRh8uZASjawhOOef
xLkPL4Tv2he21nYyZR0k8nNbQeGPiqiaNnwd+8t2QJAxSkN9C3V/ApVSs0OuyFjnOHym
8WkvNzGb1o5lvGvcVX5BI4ckg6s5TQl3+BMe5mOdirqxbNWDxasa9+b3bP5TfnU0VM8J
MMlhPyQbCMLprSI/24iYsfZMurk8REyXTC9aCc/MVH5c+EsQvzW51h+ZGllWFAxG64Mb
eYkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748596056; x=1749200856;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=TBoLdDgTszvKcfmqb+9eLVb2IyFbtgcQV42UVzWvyCE=;
b=kbra0hL/OCX88URHcxPTyaK9MQ9asiMcAqlzxZnc7m18JRCJBZUv3LNib7KoBnaCDm
5bhsjtMVUZCkN8KmYvBF+q/L00kuV1ZiXCyhxiBDEtSViKiUdmM0L5CFHC1T/rTMUZbO
SJjNszbvGwbeLFerOcT/MPI3xnTeWzf9iW2SHqXYLqJv51zGTsMosslf2bTCPeJ2ipt7
SznT7RgyzkZ7ig2PsnZdGfX0QyGi/9E8xMP13g9moy0iOQnjqaZp4VP49vNUxr03PF4O
pI1wz3amltNuWE3cPFKf8re3nq94//BLFyYmm7hrqKIIuaVfw4vTcMIYKyXu+X8Gg5zC
3QOw==
X-Forwarded-Encrypted: i=1; AJvYcCUd56A8fkxhCpVefZdtL+WYj4O1gLKblmqvUX4wu1g0B0JrcDTuWM4rlROT81HAqhXCWei3L6cyGS0kY6E=@vger.kernel.org
X-Gm-Message-State: AOJu0YypjMNVs93U0q0FIzqJHIJy7/GszR7ht7W1KbV2Gs25+HjuPWA8
weSs9ItLsp6MB19d/iU0+Jl+0Ro/Dj6Cl0tBOT2n0ETjJierFNGVd9XBU4Wgj593R0U=
X-Gm-Gg: ASbGncukCeO9WP66NVRdJbLzwmYU6H4RNNv+NGpOEVxbbfrJielcKyznSLk3WP8HTzV
lK0oViMlNH8X59HPz/gqKCjTLHArYw/5UwhSCn36qhKuyay67CBBOvzESahIoSFX/x+CgnkwcoC
6oNlJWE04jC3BwQAPXhse+iCWZOVizqMFxUkASnXlAAriemvpVjVi3oyPsf8y7yJlPsvlYQxd8V
DlTgoyfFx2f/RS3Dll/aGV8mT2YF53hVycOXT9gBqN/3eoXz//QDvlID2k3Ln5q3a5AkxYatRMH
NubEofJCk9t39/ibhJJFlXYA8Xx9RgwxwPcZOJxmBF+twFRqw3y/BfUs84C/x3/fvakK245pUcE
inADWmBgfTQ==
X-Google-Smtp-Source: AGHT+IEqyiCNMlturDlCUFIxx4iLoEZ93zytjOhgqluhNHe7ssc/aGQOO2bx+VoGalmOEoFz61oKqg==
X-Received: by 2002:a05:600c:34cd:b0:450:c9e3:91fe with SMTP id 5b1f17b1804b1-450d69abea4mr18955185e9.0.1748596055760;
Fri, 30 May 2025 02:07:35 -0700 (PDT)
Received: from localhost (109-81-89-112.rct.o2.cz. [109.81.89.112])
by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-450d7f1b0a4sm12546965e9.0.2025.05.30.02.07.35
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 30 May 2025 02:07:35 -0700 (PDT)
Date: Fri, 30 May 2025 11:07:34 +0200
From: Michal Hocko <mhocko@xxxxxxxx>
To: David Hildenbrand <david@xxxxxxxxxx>
Cc: Baoquan He <bhe@xxxxxxxxxx>, Donald Dutile <ddutile@xxxxxxxxxx>,
Jiri Bohac <jbohac@xxxxxxx>, Vivek Goyal <vgoyal@xxxxxxxxxx>,
Dave Young <dyoung@xxxxxxxxxx>, kexec@xxxxxxxxxxxxxxxxxxx,
Philipp Rudo <prudo@xxxxxxxxxx>, Pingfan Liu <piliu@xxxxxxxxxx>,
Tao Liu <ltao@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
David Hildenbrand <dhildenb@xxxxxxxxxx>
Subject: Re: [PATCH v2 0/5] kdump: crashkernel reservation from CMA
Message-ID: <aDl1ViMpK_6q_z06@tiehlicka>
References: <Z7dc9Cd8KX3b_brB@xxxxxxxxxxxxx>
<04904e86-5b5f-4aa1-a120-428dac119189@xxxxxxxxxx>
<427fec88-2a74-471e-aeb6-a108ca8c4336@xxxxxxxxxx>
<Z8Z/gnbtiXT9QAZr@MiWiFi-R3L-srv>
<e9c5c247-85fb-43f1-9aa8-47d62321f37b@xxxxxxxxxx>
<aDgQ0lbt1h5v0lgE@tiehlicka>
<a1a5af90-bc8a-448a-81fa-485624d592f3@xxxxxxxxxx>
<aDlsF5tAcUxo4VgT@tiehlicka>
<e0f7fc1e-2227-4c6b-985a-34a697a52679@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e0f7fc1e-2227-4c6b-985a-34a697a52679@xxxxxxxxxx>
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
> On 30.05.25 10:28, Michal Hocko wrote:
[...]
> > All that being said I would go with an additional parameter to the
> > kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
> > otherwise. That would make the optimized behavior opt in, we do not need
> > to support all sorts of timeouts and also learn if this is not
> > sufficient.
> >
> > Makes sense?
>
> Just so I understand correctly, you mean extending the "crashkernel=" option
> with a boolean parameter? If set, e.g., wait 1s, otherwise magic number 10?
crashkernel=1G,cma,cma_sane_dma # no wait on transition
crashkernel=1G,cma # wait on transition with e.g. 10s timeout
--
Michal Hocko
SUSE Labs
Return-Path: <linux-kernel+bounces-667828-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 277EF41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:09:06 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id C4193165D98
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:09:06 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 19ABD21D5B3;
Fri, 30 May 2025 09:08:55 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="ZB1U/Pdf"
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196])
(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 420D91EB5D8;
Fri, 30 May 2025 09:08:50 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.196
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596134; cv=none; b=U9XQdV9YYkAgBBWSWwV/f25KFGrKgMHyo3oZQF5oA7HVrTEFS79SW2swJKSYGbaCV0rI3ADubUsaN+lrSa23dNNgEAaVFPntMEfFmp2wQM6z7kxCtLpwaGFHIRpZjzzS5su5S7eMpJ+M7LDzU1/VdGL/olGBTBOC0B9ElRYiRUE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596134; c=relaxed/simple;
bh=kyXdt8s0xKz4LjroE2u3gSZ0qK9QnI9kcAdnHQnzJj8=;
h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
MIME-Version:Content-Type; b=UpT09/elycHJ4rE5KgttTEhX+isDEivw5H1K+MZFqg7K+ISSIKJVGQdu/DHdZfqhgCcHaLxXM8mbkqCYo94qYBHZGnuLnVOWshCk1PWgXRNzF831Xbfh9HaNrsSR9RK5ds3gJrmi5WrUf9OQuZVXOQl8WFNF6e+ZemD9w2yWsBE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=ZB1U/Pdf; arc=none smtp.client-ip=217.70.183.196
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com
Received: by mail.gandi.net (Postfix) with ESMTPSA id D06D643349;
Fri, 30 May 2025 09:08:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1;
t=1748596129;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=YDcQoFFC4NqCXcyobvRRuP1Ua4ytiuIE7XjIkD34fbk=;
b=ZB1U/Pdfi7HtDnqYB1OWNlxulO3P8Fzu1T1afPYQ754WfHDNuOCqhr37hUY6ZczMdot6mN
iKfgB57p8ne86qqiVAZL4T0zsuD2oXjkNi9Lx3+FRbgiijwLmb9ZSxZ3KK2eC8Xqd9CioZ
yzOYPApcG7YNnNy58ZNYVwhc7L78+lx/W8BrCXo2NEU35lMAFE1SSpZx26hyQJVZ3Nrnmb
w6+mG5x8R8W7GNQ2s81ezwluiyStYudEhpPnKiYruUKX3GhapRbICKk4/l3DWhZDNjo9ME
QUFFW58toUQT05s34GNXa92rPdx7Bu+JwK3kC06Yh9cWmK4T9/7lyc5QvFJqLA==
From: Romain Gantois <romain.gantois@xxxxxxxxxxx>
To: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
Cc: Maxime Chevallier <maxime.chevallier@xxxxxxxxxxx>, davem@xxxxxxxxxxxxx,
netdev@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
linux-arm-msm@xxxxxxxxxxxxxxx, thomas.petazzoni@xxxxxxxxxxx,
Andrew Lunn <andrew@xxxxxxx>, Jakub Kicinski <kuba@xxxxxxxxxx>,
Eric Dumazet <edumazet@xxxxxxxxxx>, Paolo Abeni <pabeni@xxxxxxxxxx>,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
Christophe Leroy <christophe.leroy@xxxxxxxxxx>,
Herve Codina <herve.codina@xxxxxxxxxxx>,
Florian Fainelli <f.fainelli@xxxxxxxxx>,
Heiner Kallweit <hkallweit1@xxxxxxxxx>,
Vladimir Oltean <vladimir.oltean@xxxxxxx>,
=?UTF-8?B?S8O2cnk=?= Maincent <kory.maincent@xxxxxxxxxxx>,
Marek =?UTF-8?B?QmVow7pu?= <kabel@xxxxxxxxxx>,
Oleksij Rempel <o.rempel@xxxxxxxxxxxxxx>,
=?UTF-8?B?Tmljb2zDsg==?= Veronese <nicveronese@xxxxxxxxx>,
Simon Horman <horms@xxxxxxxxxx>, mwojtas@xxxxxxxxxxxx,
Antoine Tenart <atenart@xxxxxxxxxx>, devicetree@xxxxxxxxxxxxxxx,
Conor Dooley <conor+dt@xxxxxxxxxx>, Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Rob Herring <robh@xxxxxxxxxx>, Daniel Golle <daniel@xxxxxxxxxxxxxx>,
Dimitri Fedrau <dimitri.fedrau@xxxxxxxxxxxx>
Subject:
Re: [PATCH net-next v6 06/14] net: phy: Introduce generic SFP handling for
PHY drivers
Date: Fri, 30 May 2025 11:08:41 +0200
Message-ID: <12687918.O9o76ZdvQC@fw-rgant>
In-Reply-To: <aDliS9uMFaLf2lCV@xxxxxxxxxxxxxxxxxxxxx>
References:
<20250507135331.76021-1-maxime.chevallier@xxxxxxxxxxx>
<6159237.lOV4Wx5bFT@fw-rgant> <aDliS9uMFaLf2lCV@xxxxxxxxxxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart5904461.DvuYhMxLoT";
micalg="pgp-sha512"; protocol="application/pgp-signature"
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddtgddvkeeiudculddtuddrgeefvddrtddtmdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefufffkjghfgggtsehgtderredttdejnecuhfhrohhmpeftohhmrghinhcuifgrnhhtohhishcuoehrohhmrghinhdrghgrnhhtohhishessghoohhtlhhinhdrtghomheqnecuggftrfgrthhtvghrnhephfdvleekvefgieejtdduieehfeffjefhleegudeuhfelteduiedukedtieehlefgnecuffhomhgrihhnpegsohhothhlihhnrdgtohhmnecukfhppeeltddrkeelrdduieefrdduvdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepledtrdekledrudeifedruddvjedphhgvlhhopehffidqrhhgrghnthdrlhhotggrlhhnvghtpdhmrghilhhfrhhomheprhhomhgrihhnrdhgrghnthhoihhssegsohhothhlihhnrdgtohhmpdhnsggprhgtphhtthhopeeftddprhgtphhtthhopehlihhnuhigsegrrhhmlhhinhhugidrohhrghdruhhkpdhrtghpthhtohepmhgrgihimhgvrdgthhgvvhgrlhhlihgvrhessghoohhtlhhinhdrtghomhdprhgtphhtthhopegurghvvghmsegurghvvghmlhhofhhtrdhnvghtpdhrtghpthhtohepnhgvthguvghvsehvg
hgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqkhgvrhhnvghlsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqrghrmhdqmhhsmhesvhhgvghrrdhkvghrnhgvlhdrohhrghdprhgtphhtthhopehthhhomhgrshdrphgvthgriiiiohhnihessghoohhtlhhinhdrtghomhdprhgtphhtthhopegrnhgurhgvfieslhhunhhnrdgthh
X-GND-Sasl: romain.gantois@xxxxxxxxxxx
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
--nextPart5904461.DvuYhMxLoT
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Romain Gantois <romain.gantois@xxxxxxxxxxx>
To: "Russell King (Oracle)" <linux@xxxxxxxxxxxxxxx>
Date: Fri, 30 May 2025 11:08:41 +0200
Message-ID: <12687918.O9o76ZdvQC@fw-rgant>
In-Reply-To: <aDliS9uMFaLf2lCV@xxxxxxxxxxxxxxxxxxxxx>
MIME-Version: 1.0
On Friday, 30 May 2025 09:46:19 CEST Russell King (Oracle) wrote:
> On Fri, May 30, 2025 at 09:28:11AM +0200, Romain Gantois wrote:
> > On Thursday, 29 May 2025 15:23:22 CEST Russell King (Oracle) wrote:
> > > On Wed, May 28, 2025 at 09:35:35AM +0200, Romain Gantois wrote:
> > > > > In that regard, you can consider 1000BaseX as a MII mode (we do have
> > > > > PHY_INTERFACE_MODE_1000BASEX).
> > > >
> > > > Ugh, the "1000BaseX" terminology never ceases to confuse me, but yes
> > > > you're
> > > > right.
> > >
> > > 1000BASE-X is exactly what is described in IEEE 802.3. It's a PHY
> > > interface mode because PHYs that use SerDes can connect to the host
> > > using SGMII or 1000BASE-X over the serial link.
> > >
> > > 1000BASE-X's purpose in IEEE 802.3 is as a protocol for use over
> > > fibre links, as the basis for 1000BASE-SX, 1000BASE-LX, 1000BASE-EX
> > > etc where the S, L, E etc are all to do with the properties of the
> > > medium that the electrical 1000BASE-X is sent over. It even includes
> > > 1000BASE-CX which is over copper cable.
> >
> > Ah makes sense, thanks for the explanation. I guess my mistake was
> > assuming
> > that MAC/PHY interface modes were necessarily strictly at the
> > reconciliation sublayer level, and didn't include PCS/PMA functions.
>
> When a serdes protocol such as SGMII, 1000BASE-X, or 10GBASE-R is being
> used with a PHY, the IEEE 802.3 setup isn't followed exactly - in
> effect there are more layers.
>
> On the SoC:
>
> MAC
> Reconciliation (RS)
> PCS
> SerDes (part of the PMA layer)
>
> On the PHY side of the SerDes host-to-phy link:
>
> SerDes
> PCS (which may or may not be exposed in the PHY register set,
> and is normally managed by the PHY itself)
> (maybe other layers, could include MACs back-to-back)
> PCS
> PMA
> PMD
>
> Hope that helps explain what's going on a little more.
Definitely helps a lot, thanks.
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
--nextPart5904461.DvuYhMxLoT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEYFZBShRwOvLlRRy+3R9U/FLj284FAmg5dZkACgkQ3R9U/FLj
285M0g/+Nz1A6obdeKee0RLc6MA2gBvM/EmqYPQ6ZduN6VFL2D6J4NATyQRqu/VW
u4d0pjD2ZOe44w6eAeRcWHsC0LJYfnHPPMhxekF2l+qqggkvZDGp9BmWJZd5UUe0
dDxur4qI6XF2WlWDXyf9auZ3iGvqOUnWYK7VsLu/1hMYeC8M0Q+5dwy72//aAGnH
9lyBU77a7sd3Qhlnd5Flg5f9ZuQmfqcD7Hyjp0OXdSJr7TlXLPJ+4FffNTivOQMK
WonmDnfUOSPfxukMd0ozR7Z2BdvUeKPrlQq6yvcC5aS+9WZvVWCZzLOLrlBylu50
wtEnYLpXd8QVehLsZGfE8mB4u+IuJICnEKhhrQ7YSLdjmXkj4VHCZHjl28WrI5rP
wMCczhfYk4tDM83L2TBDVX5DTvcIcBawWlGxwzOdZ8WbipSVt5LZMtAkICE9TZzz
j0oJ6+4xxi8mXGVduWD7kztOgXFl+UAx9GG8RsWoSPE0+t1f2nO0YV55UTW5RhEA
/hNR+P1Z8pB9SHjHM9TskW6LC4Z/NEIBnI0N98BacAdjSc/KX4uHSH01ANVHRyEs
wD5PJQKAj705h81tvNA4RzUkqC+UAa9bjtE3gtqj0KnusZhSiPBtIRe55sJ3W9aU
uYNbFO3CW8dD+WMqYm9fQrWtbqX/tOWRCOzdM5KMSNpbVyBWNDs=
=r0Tf
-----END PGP SIGNATURE-----
--nextPart5904461.DvuYhMxLoT--
Return-Path: <linux-kernel+bounces-667829-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 1716A41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:09:27 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 5679D1664C3
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:09:28 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 1FD1C21323C;
Fri, 30 May 2025 09:09:23 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="lDB5jcZA";
dkim=fail reason="signature verification failed" (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="c3p4Jmtb"
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32])
(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 E5E9C1E3769
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:09:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596161; cv=fail; b=PRBsz8Jnen+ZHmY+03l64f+yeirpuvKlEkcHM/cLvwB8ifV3J1OK+5TxOj3MGrgCmIPWRnneJigin/FBL9Ur1RYOvvYzGJqYFljlo35r/ddPRD7P+xwBhv7Pyg1gwQ6l+SwybPquIBgvdgahLbYX2YLJOKqpr4go78kftR2EuMg=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596161; c=relaxed/simple;
bh=gcyjxFwEVDKlLnvHjop5wPdfXDkcIsCj2uC4t+V6CQU=;
h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
Content-Disposition:In-Reply-To:MIME-Version; b=TCxkeHgENFt/hVvQGMqsQJDzwYg/KJQXVNnfJNkooaEnPLayeKeflc9XIHZhcF/hBHKUl15plI0T6+Nfw0RRW5D5YEH4RZx+y/xyqYcD0fykOyJYbVfwk/AUg9vpSWkSFQKrQowMj85ykSs5Tj9v+YRpaxuPrq+nPWfROkfoD+4=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=lDB5jcZA; dkim=fail (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=c3p4Jmtb reason="signature verification failed"; arc=fail smtp.client-ip=205.220.177.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Received: from pps.filterd (m0246631.ppops.net [127.0.0.1])
by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U6trF6005019;
Fri, 30 May 2025 09:03:51 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
:content-transfer-encoding:content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to; s=
corp-2025-04-25; bh=o+0WkFDl/nLu/BK2nLXnQzO9kdoajAfNAibA7+RUqhE=; b=
lDB5jcZAqHjONqsi+AgImEBqfg6wrGGp5VvTB+9WXuLcjir9DBGjgUZg+bSOmD0/
tBBfNcJHyq8xRYr9HyDf/z08S9L3x/QYmOGUnoMDDeZthyRoYxE5ysMCL0u+4iJQ
zmvk4Qaxc9i1e7h4Bn1yvhSSQMm0qKTxn38Pek8ilt1sTW1rfJiYYjOzmfJjedKD
3C0/Gp02sC+F8pAYzklXQKn3ubcDT/m1uR2FwZNVfuWMP/glJq5UILNw76nnOx9m
wNMrLoF4srcEpZbWKtEKhdUfHVoL/SwaVuolNN3OpzKd7avQCZYZVRlL2Jad202A
u9XIX68wVJSd/xMORT++5g==
Received: from phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta03.appoci.oracle.com [138.1.37.129])
by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46wjbcnudq-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 09:03:50 +0000 (GMT)
Received: from pps.filterd (phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 54U8NwvQ026702;
Fri, 30 May 2025 09:03:49 GMT
Received: from ch1pr05cu001.outbound.protection.outlook.com (mail-northcentralusazon11010044.outbound.protection.outlook.com [52.101.193.44])
by phxpaimrmta03.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 46u4jd1c1r-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 09:03:49 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=sS1JRtdCJs4MdK6cV6uzT+BJEEbV42hzgwmRKvuDM/G8DuaWVnjoFWleL8JgvvrngXfqyFgBivErimRwopb17IZPz313IDUqsIJ7jkRGYscsAR6g5qaXIWfD1qmLLuiIsn3niz08KcbkS2TkMpkLWl/jiJVGkbfzeAHmQ9uoEB5uG9OyzVjsM4v2J8Lhrr/0UbRXOmkqmL3427PDlUzhfIU7NIGL8p6A7xCuUVMblXU90w//XFjj1qfnzjMcHMaXtM5qNjsRRxsJrmbD9D/PucicevyrWYuNFTjEhDprEJZ8Ed1Cghz2q5rISVhOxoLzdczYLJnjGuqlrOsGxXS8Lg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=8Q60Cklp6/T+1mNpP3E85IzyFSebAgOq7YV0tDJ1IyM=;
b=fja4dE48B13wN08QvVSUL+KIMbEVaIbPg+sd3ecg6GfS9+i3qBYOqRCa5WqpFbNJ182UV2qc0VLBlz8UsvVtyxF+yvZenR9ogVeEiIhsPqYfcP+zpHPMjbHf5TVDxXSJCVNB+b/o+2SYhk+9miyfxTvSxrQlFEYWgwUJfJVAKl5dmHMlTCRDWnyc/FAgEPJqDiZxXUkgmo/FeuuNUZd0Q+bi898AAtTK2KOxcjSgd1o2NGiI2UJ4WMh6wkssc4isXPwnLeJsxMQ8QYS5oaenUQSGbzZ3IMeG1gxtSxuAaVBbB7HXHEDMd11O+4rs2K08iOu81WabxrE1uTLaLObP4g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=8Q60Cklp6/T+1mNpP3E85IzyFSebAgOq7YV0tDJ1IyM=;
b=c3p4JmtbVdXOtCohAf2t0Rim7NPeLLhcORcvbQ/6UoPVMjoIXuo50BQFNYmh29IW+/mJkCcKlvG2CsP/fj0G/NaTZ0NMiwA2virovGK7fn3QxEl7Iu4BDMIDiOq+jFmAH7NHQq04tb3rlOBjumCN1ny4TuAlTPY2kvcTizbF7X0=
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
by SN7PR10MB6361.namprd10.prod.outlook.com (2603:10b6:806:26f::20) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.40; Fri, 30 May
2025 09:03:46 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.8746.030; Fri, 30 May 2025
09:03:46 +0000
Date: Fri, 30 May 2025 10:03:44 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
To: David Hildenbrand <david@xxxxxxxxxx>
Cc: Pu Lehui <pulehui@xxxxxxxxxxxxxxx>, Oleg Nesterov <oleg@xxxxxxxxxx>,
mhiramat@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, Liam.Howlett@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx, vbabka@xxxxxxx, jannh@xxxxxxxxxx,
pfalcato@xxxxxxx, linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
pulehui@xxxxxxxxxx
Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when
expanding vma during mremap
Message-ID: <205f8165-449c-441f-8ee9-58f69d23dbeb@lucifer.local>
References: <13c5fe73-9e11-4465-b401-fc96a22dc5d1@xxxxxxxxxx>
<4cbc1e43-ea46-44de-9e2b-1c62dcd2b6d5@xxxxxxxxxxxxxxx>
<20250526154850.GA4156@xxxxxxxxxx>
<06bd94c0-fefe-4bdc-8483-2d9b6703c3d6@xxxxxxxxxx>
<57533126-eb30-4b56-bc4d-2f27514ae5ad@xxxxxxxxxxxxxxx>
<cba0155e-d2b9-41fa-bc51-f3738ae73cff@xxxxxxxxxx>
<956124be-c73c-4023-9edd-25372f3f865a@xxxxxxxxxxxxxxx>
<ccf359b0-8baa-4209-b2c3-75e3813ca804@xxxxxxxxxx>
<b2dd29b0-aa12-4cb7-9c05-d3a998f7b0da@lucifer.local>
<172df994-7f24-4fbb-876c-4fab22937177@xxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <172df994-7f24-4fbb-876c-4fab22937177@xxxxxxxxxx>
X-ClientProxiedBy: LO4P265CA0012.GBRP265.PROD.OUTLOOK.COM
(2603:10a6:600:2ad::7) To DM4PR10MB8218.namprd10.prod.outlook.com
(2603:10b6:8:1cc::16)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|SN7PR10MB6361:EE_
X-MS-Office365-Filtering-Correlation-Id: 0dfe7952-2a57-409f-3a5f-08dd9f58e2b7
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
=?iso-8859-1?Q?eAwd5tivdw3ZGf/lwYATHD6A/IWsSty72P4FhH+clJGBt2JFJ0SqJnbHVB?=
=?iso-8859-1?Q?sh8217sV6+Mz0fTczEif3FLWl+DA93X6QrVSbLvH8NylnySc7KHDHovlHX?=
=?iso-8859-1?Q?wxxHKZk8meAbRMD0Ie79rnu8cHcJB8bdbIJtD+4WoGaq7X5K2f7wodGzPZ?=
=?iso-8859-1?Q?qXp5yhfbNszKzEO8xlEH1zFk/YnTpysQfGEeEsbjqaPT40aAERTKEw4clC?=
=?iso-8859-1?Q?BN7lydVjjxz2L09qyZXM9ydtFNe4eoXigjTzIYQ1VNTTA5Rq2icnwzIP01?=
=?iso-8859-1?Q?VqbaCg9h35xTcVElM7zplKGYum72kQlcIcArnCLz67onsXO7kC7yX+4ZTb?=
=?iso-8859-1?Q?IxVesKL/8Vem72d16MO3AytdZ8tRzWZB+VY+nItgrfapI7IsaIYzQ+wlEJ?=
=?iso-8859-1?Q?4oX8xVYYTiF1fs1xBlfv/KrbhS5npyJpsk6aNvxoPUc7V2Y2QYgKXvonoo?=
=?iso-8859-1?Q?8+XAE2zWT7pU8Vp/yhxrwbnrjwIbXpxkXpS0wHhQ1OBh1WXryv/gjPPl31?=
=?iso-8859-1?Q?hKf3EXXcBwLJP4uvOLD7OC19+K2NsO0CHSjdtYTlJNKXc0+ifhsX/DUs7P?=
=?iso-8859-1?Q?DSBoiBj6vMI0VKSV1eP3Cvc7tqOgSzRuLxWot8rPH0TJmdFA30QjQTesif?=
=?iso-8859-1?Q?HmTVhA1/CrWMF63oLWfGnqCPnbdWhlXFXrXrlVHtM2Vy9sdL725S4FSynA?=
=?iso-8859-1?Q?1TvpsdcNgRqGw8gPQf+zmZoX0MI9sD5XJCNc7EVtXSP646t0QAwWU1zcnQ?=
=?iso-8859-1?Q?znHG7i36pAST3l4NKVfzynVIo0XEFF/odRb5tm2kj7jFiw2rcopxefxPI2?=
=?iso-8859-1?Q?M7WTnSXoNWxE5fuccFlmaktHfq8M1cFuYkgVaLB9ONKI5UrIVC3zbkXKt9?=
=?iso-8859-1?Q?3apnMMzdAccGizokbwufL5taHDNgFUylNKRXnBwMRrImdKWTZSIdwlNCir?=
=?iso-8859-1?Q?j7bV6h5kJ1AW88hROetNCV1EC4YnMamV0umMIge8FC6ssMgRQ2qoMi9BpQ?=
=?iso-8859-1?Q?XVXHWFKXsVW1+fczwtwDLZ2T8B4XrIadU4fvTQ8y9M5/MGEYBi8oUsdcS1?=
=?iso-8859-1?Q?BWKOtWd4WHosfbd2cZ3BvrbipG92+dcA3un+Z2F3msqjVSgBP/k+UJXjLz?=
=?iso-8859-1?Q?JOfs7LOGq1u8RlAzJsr9igmioDHEbUmYRMdUaZpZDLSDIexNdGXzJHRIq9?=
=?iso-8859-1?Q?bIY8S6GS+fLg/+xfhJcUWG6McGDxj3kaqpvBP8W7OFuj4Pa0KiwmUoQsVp?=
=?iso-8859-1?Q?TGANtYTQDxYFqbDr0k8NLFJMyT/oCajKu+bwVYDdMjvn4p7ZROPUAwUfHm?=
=?iso-8859-1?Q?qWjFF54c2axaVVIwMa6IV7+Bc22Lv7GQYuPUtoN7sh3JXyiH7tGJ5V4YYK?=
=?iso-8859-1?Q?9MXqapJ3BVb0FkJtpTYBQ1mp7SJn3U81vKFG2yOisUsJa25veNVWKtY2vH?=
=?iso-8859-1?Q?2VJv/2tymgOzRVzGACs7AfPE4RIbVf0Wb1oxitPGp0i0FqBsA4JMapcQ49?=
=?iso-8859-1?Q?0=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?iso-8859-1?Q?nE34zQm9NWjT6QAuQuc9vaTTeIhw49huOq36IoXGiqxeEVkpiHOSAyn/ux?=
=?iso-8859-1?Q?JDW6EpNhYW25NbIMflTQN9GLyLXkj5E719IW2JvBbsAJd97LsK7lfVVgxV?=
=?iso-8859-1?Q?gmJVHXAvkPFKmepxpTLYWnPzodfPSrloilZPWJ+XVQpfhJOeiP/Z03hDJQ?=
=?iso-8859-1?Q?r5USZ9tEq/hgYxv2nG7EFGcaL0DnMfbzEgivF7GRQP0Dg8uGxqgViSQfS4?=
=?iso-8859-1?Q?clXSby34uZ0foEJDjEX49MudgmaCjAsZClW2U6L+832bL69EIjMLaB9k0o?=
=?iso-8859-1?Q?Ht9PVHJpqX/dPN04LvmpQprw2A80FGW22W/4UHYRXJx/9wL277R31jBO9J?=
=?iso-8859-1?Q?ZqHegcnOZGqlqyO0wrt2Vplm5L0OlwZQsJnteGNvDgzOoIsgGhfvIYuHD2?=
=?iso-8859-1?Q?350/lDsMZG1Tl9rRB+SPeDggmoG0oZyMOHBkHEjZbM2cXndAKZGkyj4GpT?=
=?iso-8859-1?Q?MOdwfUL75zYmy4BPHl1asVkfmAaddk9slsrgcbxfmr/kP4nGM8LBklq0zp?=
=?iso-8859-1?Q?yf1XmHwJbWVffRPA52yYGMFqpwbAp6NXTNv06tC/SuU2Ukgdy9hrBCiJRV?=
=?iso-8859-1?Q?XIx6L2z+HN9KXtuTlZyJMue9eZ2292QyiZi+CByIC9HeeA4ENNAAdAuKgC?=
=?iso-8859-1?Q?JDKMcBFxcaH9tDUauV3VhijYl8YZq36/H6//CqpmDs3CwwjT6q2kkdt5yQ?=
=?iso-8859-1?Q?x+/U4pYoeTXsSZySjrjuKtdSdmoBp4ORP1lauEwcH/0aAm1I0QPgk2Z+AQ?=
=?iso-8859-1?Q?WLtUsOnx8vYwP7n1gMJJtuxIKTC+lFXe9w0f7whFocFt74KpK8HnQvgrVE?=
=?iso-8859-1?Q?I1EcJV6B6gTkVP5eNrRgy37ni7ONHSLWnORdwP4KwZ6pIjrqj48VlPLoB+?=
=?iso-8859-1?Q?URZeq+X3ZyKt4vDiF4WjxucE/8s8E4fDN5gznzd3Fag/72HBIsaQi4tG52?=
=?iso-8859-1?Q?vKXs15rurGcx0avigdScvZbQcJd5QfUoSFrblqfzNBpBk6uAo6SeMOcQ3Z?=
=?iso-8859-1?Q?j4pb3NEoBg9oZY6Ef6dwSRZdqeKTo/sJqpKoCVrtpH+AOeGIsX4MI8e0dt?=
=?iso-8859-1?Q?zM4fHn55bWMNDYvMhHf5WQh5KE2gkhnZSm2NhLTdvPTm3l7ED/EeDqRMZu?=
=?iso-8859-1?Q?TrSbru5/WG9aF70zMMegCyrH08CG/PAvCBjVt9bBMoS8f7xHq7hNxQOffK?=
=?iso-8859-1?Q?c0IC4Yge5HMwjPyy62NTAhEI+4wciCE2GWpCpi//acfENSSwGkelmhOxsH?=
=?iso-8859-1?Q?FZkSGuc8D5ZiBqdImEnylM1nA8Avi34qi0nD/yIKavb25A6xyp6Lbhmp5X?=
=?iso-8859-1?Q?5U8xwZ+ccPV+LO75UGKx8WjNr+c7didmGLkiM8S6kWS9jN6KM7XplqoPO5?=
=?iso-8859-1?Q?0MP0Qu2AsGymoD3j4grOVymNkPeC58twyWu8eYYBpMs57WxQyMvyOIb9PQ?=
=?iso-8859-1?Q?4sFhLJVoDo0NC9cb2QOGFC2igPwnGnP/QJ6GAe8CHOs9WqsmkvOZaWBIrM?=
=?iso-8859-1?Q?I+3V/ISNnSdgISdlJFJsQUYnG8t3gaAe3R6la1okxZLoiwuWs9L8f7yYZW?=
=?iso-8859-1?Q?3OiFHGvAfG1vyqNdPg17StuyBEgNGvyi4EOMivSUD46gBLSwvEQcaypnt0?=
=?iso-8859-1?Q?2Qou28BzCjIx/2K/kGnyBlPwr5cs/r49PHlOkHWec5u5DMIjNcFg6YrQ?=
=?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
+ddTqyvYoyWdjIrX58v4sKMWltnQUdYKyfXI/8Lzot5Vs4cdJIO31N/1j5W8WUfLB490DOmSlT1khH9/leN8kHxqp92ibwyPAyfJSaSdFEwA8FJWX0woOsYFy2CedXwMKlazGRyYPhtNLdl7FEJREMaGEGGfnmk+GA1aPDCljN+2tGVp5AEgGsxg8HxoE4bFYKsxAEbVp4IeHm446B9pnAOQRhi9Bp9MFwobu/eUkVPBKP4ICvYfqNDSgOv0bsz9Ppu2BTcJ27yjvfifSKryBX9OQmiUR67QDnaoXzAWUqBMafS98dg4MlPlIuUAR1XIDcDcpBYrDScQ0hgahAWCwm4OoEWAMCSX0NZ0SePl0xzXupcK+oVkrmAAKRWCIW9F6Qu/+o8BK+EvzpMONjZknM/JiusK9LwkKjsioxDej+2iPyCVPzvWwGGYANJjsLKcIfGSC2n7HSZnr2QzMapf7zoPY4NmgP/KYQ0cwOw8DaF/Qyd3RB773CZ7Ml3Ym+B/TpEaSOwr8BJLvEVgg598KOHF9HfOHjVN/J14TnAkU5r/9JGbxVpidPP4vPRx2CyYyMY/uJlU96Ob+8gY9MvTlKWcV/2d2PwBB5LmEYRuq8M=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0dfe7952-2a57-409f-3a5f-08dd9f58e2b7
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 09:03:46.6761
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: /fcPxWegZe596AGrgH+/28pRVHPK8vkn9p4zQGQCeBfDT/U70Cg2nfqk1gjo96HuNjtPDkizlIGssetJCZWptRP/tufc7zHZsjhMJdKYjek=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR10MB6361
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 adultscore=0
malwarescore=0 mlxlogscore=999 bulkscore=0 spamscore=0 phishscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
definitions=main-2505300076
X-Proofpoint-GUID: Jce1fhaMxWJONRmXOfRbWabRsScpALEo
X-Proofpoint-ORIG-GUID: Jce1fhaMxWJONRmXOfRbWabRsScpALEo
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA3NiBTYWx0ZWRfXyGG7xmvUPNBj JLsFOrLj88RXHkIgTSIZIZB4Gg6IdMSwZv2R0jxgd3LL8jczjzwxQQbaCQ0H2L64FcgMZq9BMGD x+kzqsdjkbQXCTCIIxCz5DRfeO4bctGQyNTG/w5WMXBlwDl7koCRk9DtfSQPhEJdP+uctKZzeJu
VhPGPWO/yCEBiIvNtEZGT8Y9Yz69Lpy8u6/9139IesmsqUV/R7QZc+r+ZgFxsEbtltW/QOQSOHP WOM7zUpZ9eWYgBgjj5I/BvwKt27ELMS1UBvBoeY6Dl8T/xlnjvIcLVOh3uuNOAH38JC7u3w7NVP on1BHF+7oKzLhijntutL/6BY4bNVawSR+Q5YhKZzF3jtMUr94c5xPH/ckUZcRdUjGztQkYuHuJO
bZ8QUD/GpnMI4JWaNbz66/dTdOKW+hdCX0mIJ3O9NPINx4Nh6zv4opjyfBdWocLzEt5Rr5ld
X-Authority-Analysis: v=2.4 cv=c8qrQQ9l c=1 sm=1 tr=0 ts=68397476 b=1 cx=c_pps a=WeWmnZmh0fydH62SvGsd2A==:117 a=WeWmnZmh0fydH62SvGsd2A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=8nJEP1OIZ-IA:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=Yy3iyKY8KCAegk6HaBYA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10
X-Spam-Status: No, score=-3.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 10:50:25AM +0200, David Hildenbrand wrote:
> On 30.05.25 10:41, Lorenzo Stoakes wrote:
> > On Fri, May 30, 2025 at 10:33:16AM +0200, David Hildenbrand wrote:
> > > On 29.05.25 18:07, Pu Lehui wrote:
> > > >
> > > > On 2025/5/28 17:03, David Hildenbrand wrote:
> > > > > On 27.05.25 15:38, Pu Lehui wrote:
> > > > > > Hi David,
> > > > > >
> > > > > > On 2025/5/27 2:46, David Hildenbrand wrote:
> > > > > > > On 26.05.25 17:48, Oleg Nesterov wrote:
> > > > > > > > Hi Lehui,
> > > > > > > >
> > > > > > > > As I said, I don't understand mm/, so can't comment, but...
> > > > > > > >
> > > > > > > > On 05/26, Pu Lehui wrote:
> > > > > > > > >
> > > > > > > > > To make things simpler, perhaps we could try post-processing, that is:
> > > > > > > > >
> > > > > > > > > diff --git a/mm/mremap.c b/mm/mremap.c
> > > > > > > > > index 83e359754961..46a757fd26dc 100644
> > > > > > > > > --- a/mm/mremap.c
> > > > > > > > > +++ b/mm/mremap.c
> > > > > > > > > @@ -240,6 +240,11 @@ static int move_ptes(struct
> > > > > > > > > pagetable_move_control
> > > > > > > > > *pmc,
> > > > > > > > > if (pte_none(ptep_get(old_pte)))
> > > > > > > > > continue;
> > > > > > > > >
> > > > > > > > > + /* skip move pte when expanded range has uprobe */
> > > > > > > > > + if (unlikely(pte_present(*new_pte) &&
> > > > > > > > > + vma_has_uprobes(pmc->new, new_addr,
> > > > > > > > > new_addr +
> > > > > > > > > PAGE_SIZE)))
> > > > > > > > > + continue;
> > > > > > > > > +
> > > > > > > >
> > > > > > > > I was thinking about
> > > > > > > >
> > > > > > > > WARN_ON(!pte_none(*new_pte))
> > > > > > > >
> > > > > > > > at the start of the main loop.
> > > > > > > >
> > > > > > > > Obviously not to fix the problem, but rather to make it more explicit.
> > > > > > >
> > > > > > > Yeah, WARN_ON_ONCE().
> > > > > > >
> > > > > > > We really should fix the code to not install uprobes into the area we
> > > > > > > are moving.
> > > > > > Alright, so let's try this direction.
> > > > > >
> > > > > > >
> > > > > > > Likely, the correct fix will be to pass the range as well to
> > > > > > > uprobe_mmap(), and passing that range to build_probe_list().
> > > > > >
> > > > > > It will be great. But IIUC, the range we expand to is already included
> > > > > > when entering uprobe_mmap and also build_probe_list.
> > > > >
> > > > > Right, you'd have to communicate that information through all layers
> > > > > (expanded range).
> > > > >
> > > > > As an alternative, maybe we can really call handle_vma_uprobe() after
> > > > > moving the pages.
> > > >
> > > > Hi David,
> > > >
> > > > Not sure if this is possible, but I think it would be appropriate to not
> > > > handle this uprobe_mmap at the source, and maybe we should make it clear
> > > > that new_pte must be NULL when move_ptes, otherwise it should be an
> > > > exception?
> > >
> > > Yeah, we should ay least document that if we find any non-none pte in the
> > > range we are moving to, we have a big problem.
By the way I agree with this.
> > >
> > > I think the main issue is that vma_complete() calls uprobe_mmap() before
> > > moving the page tables over.
> >
> > Well vma_complete() is not _normally_ invoked before moving page tables,
> > it's mremap that's making things strange :)
> >
> > That's why I think my suggested approach of specifically indicating that we
> > want different behaviour for mremap is a reasonable one here, as it special
> > cases things for this case.
> >
> > However...
> >
> > >
> > > If we could defer the uprobe_mmap() call, we might be good.
> > >
> > > The entry point is copy_vma_and_data(), where we call copy_vma() before
> > > move_page_tables().
> > >
> > > copy_vma() should trigger the uprobe_mmap() through vma_merge_new_range().
> > >
> > > I wonder if there might be a clean way to move the uprobe_mmap() out of
> > > vma_complete(). (or at least specify to skip it because it will be done
> > > manually).
> >
> > ...I would also love to see some means of not having to invoke
> > uprobe_mmap() in the VMA code, but I mean _at all_.
> >
> > But that leads into my desire to not do:
> >
> > if (blah blah)
> > some_specific_hardcoded_case();
> >
> > I wish we had a better means of hooking stuff like this.
> >
> > However I don't think currently we can reasonably do so, as in all other
> > merge cases we _do_ want to invoke it.
>
> "all other" -- not so sure.
>
> Why would we invoke uprobe when merging VMAs after mprotect, mremap,
> madvise, ordinary mremap where we are not mapping anything new but just ...
> merging VMAs?
>
> Really, we need to invoke uprobe only when adding new VMAs or extending
> existing VMAs -- mapping new file ranges some way.
>
> Or am I missing something important?
Well, this is where my limited knowledge of uprobe comes in.
I'm _assuming_ we must invoke it for merge. I'm happy to consider a refactoring
that applies generally, I'm not happy to see something that changes what merge
code does in non-mremap cases just for mremap.
>
> --
> Cheers,
>
> David / dhildenb
>
Return-Path: <linux-kernel+bounces-667830-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id D426E41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:09:39 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 9806E9E3038
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:09:17 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 4CB7D21CFF6;
Fri, 30 May 2025 09:09:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="MAyTs0UH"
Received: from casper.infradead.org (casper.infradead.org [90.155.50.34])
(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 4642421D5AA;
Fri, 30 May 2025 09:09:25 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596168; cv=none; b=mqXezoi5wuNByqcoFgHfYCc/eSh7QY+aHQa86xL/zor2kVYea/AcqUu+It6Kb5CNM3iPPKR9Oy8f0m5OuZv6vdhH5asQnoj3z77s3bXynWpdYGqf2d530dOFAxI7QD4SIVVkPSeJ7dRqXyKxIQMnr4WYWZzXwl56TKLX6/AMcNI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596168; c=relaxed/simple;
bh=zsGAJjYLsmPlm2wB128S10iUARQb+H7Mj+zl0TaQXas=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=Qpo1GNO7eMlMI7kLQngETyVJ0X/alBLrEGz45zr3Yd2fNQlW2ajfCvOhvx1fqM/pMfa1ixcF0LhotjxJUHjLRo80Yq1BuBnRCGzOQTBpuTXQcXQVj2iwE3NBZRstWHzTpZHVcTFPyfocldX1v/rsFitRi/B+9RYr9K88x0HN9Cg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=MAyTs0UH; arc=none smtp.client-ip=90.155.50.34
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org
Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
Content-Transfer-Encoding:Content-ID:Content-Description;
bh=KV51Tq5Hn+Qgevf9gWTDy9yyqkC2J2EnaAWxedH0XH0=; b=MAyTs0UHki9WYlSirqlJs3y03b
ed1bGPuX5V/rH2Vac/Wcrz1fq1Z9pgmoiaCUX2Uf2v69+ASWAwUM5SSe8DDUpEgrqrOD/HGw/yBso
KTV610rhBoZGwjPbhxwvGjOUzPrDK6UlVPUry41fDpMQUHNnAJPwf8aHibgYnXSjQ9ld0RYteqgTG
C3oaoCV1ds+FDpuLm9LAlst6TTeX3RhnKbxKNW/sIW9zGCo7t+3jAlst5GZJxV1rJxykNODbUAexT
N9kWq9RZDEJw+scmaRSmwJXMWR7xe5gTaqedSqE3PW5tYCeIkIFfq4ZJVMkjtim24JmuPmJCh6mww
bxWnBZ+Q==;
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net)
by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
id 1uKvjt-0000000FeW1-1Dxy;
Fri, 30 May 2025 09:09:21 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
id A5B2030066A; Fri, 30 May 2025 11:09:20 +0200 (CEST)
Date: Fri, 30 May 2025 11:09:20 +0200
From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
To: Roman Gushchin <roman.gushchin@xxxxxxxxx>
Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx,
Jann Horn <jannh@xxxxxxxxxx>, Will Deacon <will@xxxxxxxxxx>,
"Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxx>,
Nick Piggin <npiggin@xxxxxxxxx>, Hugh Dickins <hughd@xxxxxxxxxx>
Subject: Re: [PATCH v6] mmu_gather: move tlb flush for VM_PFNMAP/VM_MIXEDMAP
vmas into free_pgtables()
Message-ID: <20250530090920.GB21197@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20250522012838.163876-1-roman.gushchin@xxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250522012838.163876-1-roman.gushchin@xxxxxxxxx>
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Thu, May 22, 2025 at 01:28:38AM +0000, Roman Gushchin wrote:
> Commit b67fbebd4cf9 ("mmu_gather: Force tlb-flush VM_PFNMAP vmas")
> added a forced tlbflush to tlb_vma_end(), which is required to avoid a
> race between munmap() and unmap_mapping_range(). However it added some
> overhead to other paths where tlb_vma_end() is used, but vmas are not
> removed, e.g. madvise(MADV_DONTNEED).
>
> Fix this by moving the tlb flush out of tlb_end_vma() into new
> tlb_flush_vmas() called from free_pgtables(), somewhat similar to the
> stable version of the original commit:
> commit 895428ee124a ("mm: Force TLB flush for PFNMAP mappings before
> unlink_file_vma()").
>
> Note, that if tlb->fullmm is set, no flush is required, as the whole
> mm is about to be destroyed.
>
> Signed-off-by: Roman Gushchin <roman.gushchin@xxxxxxxxx>
Acked-by: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
Return-Path: <linux-kernel+bounces-667831-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 0847D41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:10:45 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id D25DD1BC40F7
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:10:57 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id C31D821CC64;
Fri, 30 May 2025 09:10:37 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="chvmN4hN"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
(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 0571A1EB5D8
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:10:34 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596236; cv=none; b=tuexOkb+M0uaP/QKBq0Ez9HfxbU6tH1FRxf4lx04iwPn3KHXfGOrIYoulYcnN7jRFOwgpJobxMmiRJHKIKgzK5S7rbDQmGsIEG+AMOIZq5GDRFXNRFcZF3YkChWWa2WKBnDyMhv/XFMmFQBk5g8wEUjknvBEpMBkDaydVlgI3as=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596236; c=relaxed/simple;
bh=i2n+Zfvh00SWR94z0VELlIDX9Y7OMV+2vDHKYzIV9ms=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=A7H/J9WRpJw93vq59aDh7ifuMw+RdqOvdcz/L7a2JH8Z9dcAJWcrjnqq79fwRuYfxhb1eSvsQ5DS+vG4T8YkP5Xd71RtY//3oUPYdN7+S7ZZ21my1XKcwnTw9+pSoxCdRtCtAEd16VrzpeyxjKz5avPbvdwbb7Q0CTXLwByCq30=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=chvmN4hN; arc=none smtp.client-ip=170.10.133.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748596233;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=Bxb0W2Gh1ooa50suLf89Op86r0jsbF9L9U6sQJKzyW0=;
b=chvmN4hNQO6ZKHPzW6rONRJchTGWdFXmk4AsKebG9cN2hH8yJlb2FOpFSnukxNzYBcs1qh
gW06hpGlZFwdi9KSZiksBQqxVlClWDXkWEt7QXBBZQD88OHHXNoFWkhQ6DI5GmI6/YzgKV
JKBqkkEuX5HApigHOXodSaAv1oSuEyw=
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
[209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-184-1IRZmZw5N9KxMv_CCmPNJw-1; Fri, 30 May 2025 05:10:32 -0400
X-MC-Unique: 1IRZmZw5N9KxMv_CCmPNJw-1
X-Mimecast-MFC-AGG-ID: 1IRZmZw5N9KxMv_CCmPNJw_1748596231
Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-440667e7f92so12445935e9.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:10:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748596231; x=1749201031;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=Bxb0W2Gh1ooa50suLf89Op86r0jsbF9L9U6sQJKzyW0=;
b=jpKc9U+zhLhndjHOOobTy3wjulsyUYNWXEldZrduR48+pfglkI9HnzTpjMpVxmMz92
PtAsXW9i/Ty8bTA1W9VMC25VRoTQub+KiFTor+YViP2lniMfEiMz9D+C+C9OvrqKY+1n
w1fbCD5BktGotBoaxtDD7b6M2/huPUBLT3/lygqw2fVNiyu7rK3+OCxp9p466HakSJ/v
+SADuKXPx6d+09gy3nJQzns8Z7qtzi1FoQPmwDgwreoA5GeupZPckp4sMiJSOD12LgHg
J/AI/Jgd1ifzUA3RnmD5hbj+HHDTPCQOXtETjRy8rLgmOpU3AbH6qDSqtiJXgRop1AmJ
pq5Q==
X-Forwarded-Encrypted: i=1; AJvYcCV48gxVdzwRZBhRRgW4EnFxx1d6xdc6teGima1C2fwvjFJmPl08XKxKoxP7j8Y+rHDPsX7HuHfc9KeSwXU=@vger.kernel.org
X-Gm-Message-State: AOJu0YxJq6qToBC71ATF8d9ewi0o8gtLVaqOw/OSs+46hz1iW3IMtJA4
WAWXn9yA9V/a6pEW1446cKL1Oskd0+qBmGl8JRqW3ECL4TaZ2Q/Zm2c0PL8M8m4GrocTTMIzCHw
Ho4vvhALrDntkzCO/vPeZUKWAznTqgA0O2aQ7m7ygJPvK98SzVjvCXL4CnQ+oezWomg==
X-Gm-Gg: ASbGnctjLO1z8y4Pe3PIigotVREZxhIjyiSzeIQ8NguXfcWAMa+uL9bV/BlXa6rgRkY
90iZ8UinnZxAGSM4vEQulL2r+CWfFVUmAyzWGz+oUhr7XygJ1QJ7PRCnFjDOWKb9WU5EsfqjSBz
VlrFL7UfTwVJk+Ssfq/1ojubRI3rphRTbOrS4e40wukmRPoYJ/X9gzsbyD956y4362gIBVqghKc
VUEV4W1kDIVr6zj4463uoZEqWPxjQGTjEPw046wYRc8N2v1E2jClKGjGhrGhuYe4LK61JP/x06R
hxg8s9EA2yBNWMFzkOII5hF7nmGcR5ir7pfHA4nGoVh8ZmYKlhC3lM1cY/dyghdxKLvmPHvcExz
zGxW7MkMJOnUWBpeDx4T3UZDekFswysHP1ZTKF8w=
X-Received: by 2002:a05:600c:1c89:b0:450:d4ad:b7de with SMTP id 5b1f17b1804b1-450d651b4edmr28818185e9.3.1748596231504;
Fri, 30 May 2025 02:10:31 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEfflLrqrEXjnPZqbpip1MsBqjhVJHcWObTFxT8759BVjb+hyECfogpcPX4XQvCJ38zt84oEA==
X-Received: by 2002:a05:600c:1c89:b0:450:d4ad:b7de with SMTP id 5b1f17b1804b1-450d651b4edmr28817735e9.3.1748596231027;
Fri, 30 May 2025 02:10:31 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe6c738sm4174668f8f.24.2025.05.30.02.10.29
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 02:10:30 -0700 (PDT)
Message-ID: <abe284a4-db5c-4a5f-b2fd-e28e1ab93ed1@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:10:29 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
To: Ryan Roberts <ryan.roberts@xxxxxxx>,
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
<f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
<9b1bac6c-fd9f-4dc1-8c94-c4da0cbb9e7f@xxxxxxx>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <9b1bac6c-fd9f-4dc1-8c94-c4da0cbb9e7f@xxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 10:59, Ryan Roberts wrote:
> On 30/05/2025 09:44, David Hildenbrand wrote:
>> On 30.05.25 10:04, Ryan Roberts wrote:
>>> On 29/05/2025 09:23, Baolin Wang wrote:
>>>> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
>>>> the system-wide anon/shmem THP sysfs settings, which means that even though
>>>> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
>>>> attempt to collapse into a anon/shmem THP. This violates the rule we have
>>>> agreed upon: never means never. This patch set will address this issue.
>>>
>>> This is a drive-by comment from me without having the previous context, but...
>>>
>>> Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
>>> user-initiated, synchonous request to use huge pages for a range of memory.
>>> There is nothing *transparent* about it, it just happens to be implemented using
>>> the same logic that THP uses.
>>>
>>> I always thought this was a deliberate design decision.
>>
>> If the admin said "never", then why should a user be able to overwrite that?
>
> Well my interpretation would be that the admin is saying never *transparently*
> give anyone any hugepages; on balance it does more harm than good for my
> workloads. The toggle is called transparent_hugepage/enabled, after all.
I'd say it's "enabling transparent huge pages" not "transparently
enabling huge pages". After all, these things are ... transparent huge
pages.
But yeah, it's confusing.
>
> Whereas MADV_COLLAPSE is deliberately applied to a specific region at an
> opportune moment in time, presumably because the user knows that the region
> *will* benefit and because that point in the execution is not sensitive to latency.
Not sure if MADV_HUGEPAGE is really *that* different.
>
> I see them as logically separate.
>
>>
>> The design decision I recall is that if VM_NOHUGEPAGE is set, we'll ignore that.
>> Because that was set by the app itself (MADV_NOHUEPAGE).
>
> Hmm, ok. My instinct would have been the opposite; MADV_NOHUGEPAGE means "I
> don't want the risk of latency spikes and memory bloat that THP can cause". Not
> "ignore my explicit requests to MADV_COLLAPSE".
>
> But if that descision was already taken and that's the current behavior then I
> agree we have an inconsistency with respect to the sysfs control.
>
> Perhaps we should be guided by real world usage - AIUI there is a cloud that
> disables THP at system level today (Google?).
The use case I am aware of for disabling it for debugging purposes.
Saved us quite some headake in the past at customer sites for
troubleshooting + workarounds ...
Let's take a look at the man page:
MADV_COLLAPSE is independent of any sysfs (see sysfs(5)) setting
under /sys/kernel/mm/transparent_hugepage, both in terms of determining
THP eligibility, and allocation semantics.
I recall we discussed that it should ignore the max_ptes_none/swap/shared.
But "any" setting would include "enable" ...
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667832-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 3A23E41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:11:57 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 2C903188C81E
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:12:10 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id CAF1A21CA0A;
Fri, 30 May 2025 09:11:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="N0oeLiPp"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
(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 687E91411EB
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:11:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596309; cv=none; b=oS2T2W8heVJnxQKR5+/IpVRUxCz4j2CtDWzyGyZTIuPSCOBZ2m2+TYmTkZcmNHVS3A4YMHmbffupMDeuU/TsfNYXdwZt+ONCi6qccboCjuBpebWCERel+fV/BbpRhHNC8InCwCFTrfGyjEfVVsWfbpR1VOg27+FcXYQmqaCqvaE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596309; c=relaxed/simple;
bh=pA4gDaYrX/ZskPIrVNn7kpuqs8HJHeoR/Xc+f5rMXNk=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=r6TYFme9GzPg/y5HFStQ/VdcEEjIykjosEQWqv4pI63dcxjcTZwamqCWopYgKjDlun3Pa8QpPl8CHpWBtjeNR4aDLbyLdq0TUIMGMmC6TOg53Gax6L3TLfqLa4cUDRbTrvrqtG0mkSf+2c8r4zhPv5BmbiV72fwjSPfQXHtTsd4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=N0oeLiPp; arc=none smtp.client-ip=170.10.133.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748596305;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=FcLOeL0j8aYWy2M7p1kJWLoT3h6nC08D9zaPSw+D+1I=;
b=N0oeLiPpZSVm2kJLnIkG0SZiJ2PX782J6jmz2Z44BAJRby6Ql2EykRvXlz15L2bh7SK4YM
SdLR3u/cgiESCu8upEu3MVg7vjUkKY8uJRSdkteSV5e65JEGSUP1qiAtKLNtNgNUZ77BgH
/NV+FbXuRwL6gY6B7aHRkvOdPf6aKUU=
Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com
[209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-338-FnrbumUNOayNS7kbmM-oNw-1; Fri, 30 May 2025 05:11:43 -0400
X-MC-Unique: FnrbumUNOayNS7kbmM-oNw-1
X-Mimecast-MFC-AGG-ID: FnrbumUNOayNS7kbmM-oNw_1748596302
Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3a4cceb558aso868880f8f.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:11:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748596302; x=1749201102;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=FcLOeL0j8aYWy2M7p1kJWLoT3h6nC08D9zaPSw+D+1I=;
b=Z9esl1xkmo+usUooppKMU+qsPRX+3HNVFhlstHYYlF9edEPrqxdyslFaio2lS0PVRD
OvC+F+5/ksABMLtY/KD8YK5WRcuoIjFvRSiPa2UwFpMEs362m5mmbTNOa7TTVfKjppCu
xD4xOOnqjKtI/3Je245XaKRMRbrk/pXGiRTK3+4ZzLKqoptXDgJ0MCaGBXMsz8aUv/9Z
ZywxbJAetDzbls5tQnkVFMpkpTNv4EWQuZ4em4Iyc7uBlJ3iYDrFZcKO0cFKBzAmMECz
kd4TNv58legdXxdGWGRlIsZft2OGrsTqXwUU6M59Ji7+3aDzmCF5ITMki0xucv+IhCxz
X7AQ==
X-Forwarded-Encrypted: i=1; AJvYcCVmJbMNlGWZRMD06UvnBcH35e2wbnlXhDHYpCHhzFbN0CqeAbQmwS1mpc+lOzSLh5g2NP9phQf+oXJgibw=@vger.kernel.org
X-Gm-Message-State: AOJu0Yz4p8MYfEW9+2umfl1hIU7LIQDNBWT6ZAQ1+AciB7yh86f7TvPM
grNETo8NtLM9/Y244nHiVuvzo6LXkCCdGWpHS5lckw1UORBvuMiZVAlIk58RZfmHhuVCBMSoI5n
3fKSBeZGkjmgnqvWMC/wD+WiKpuGM/ocoS7Wr2sn5kDZYe0cKoH3DB3P8DchE5g/FiB4n6Awjn5
1i
X-Gm-Gg: ASbGnct6H6tbcjShrLz2iW5g808mviwonGQwRlfUKBYWp96rkz6hTEOoxA2kuJxn6Qw
TFFnOQH7zet+M/8c3liK0Y3awKylKZKks1UHZcu0aPTqSXLripjIKr92uiiIeOjll7Ny0aTi8gV
HwMTeWbZftrAJnmsELQW5ryQoJvRIzTRfec09GHMx4DnI1W8nJPOFhy7uXv97BU2AAOkFrjQlGT
PYgJGIFQOdniP+1P2QJL0aZShWYmKfFnmI8mkvEajSfyqhAkbw14Fq20GQeNae1SkWoBXdkedhz
CiP7BwZVqrgkLTyx1snwYn2R2A4Ldxr0ySGlPQnzBGqznbeZzeFjTeq/r4iCw42AObZLvBmBAs7
bSnftkSyLn0xc2UaYeDFaIYP5pLIgbSQsEW8ufgA=
X-Received: by 2002:a5d:4ad0:0:b0:3a4:f7ae:77e8 with SMTP id ffacd0b85a97d-3a4f7ae78f2mr1566388f8f.15.1748596302376;
Fri, 30 May 2025 02:11:42 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IF60h8rKE0nPobuy20ZXqTnSFgBrTuintIRkVxcH5DFZBoUxjL88SfayitoqDnRNANVj/A56Q==
X-Received: by 2002:a5d:4ad0:0:b0:3a4:f7ae:77e8 with SMTP id ffacd0b85a97d-3a4f7ae78f2mr1566375f8f.15.1748596301992;
Fri, 30 May 2025 02:11:41 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe6d0dbsm4192895f8f.40.2025.05.30.02.11.41
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 02:11:41 -0700 (PDT)
Message-ID: <04a49de5-eb79-431b-ba5b-eae2536781c6@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:11:40 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/5] kdump: crashkernel reservation from CMA
To: Michal Hocko <mhocko@xxxxxxxx>
Cc: Baoquan He <bhe@xxxxxxxxxx>, Donald Dutile <ddutile@xxxxxxxxxx>,
Jiri Bohac <jbohac@xxxxxxx>, Vivek Goyal <vgoyal@xxxxxxxxxx>,
Dave Young <dyoung@xxxxxxxxxx>, kexec@xxxxxxxxxxxxxxxxxxx,
Philipp Rudo <prudo@xxxxxxxxxx>, Pingfan Liu <piliu@xxxxxxxxxx>,
Tao Liu <ltao@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
David Hildenbrand <dhildenb@xxxxxxxxxx>
References: <Z7dc9Cd8KX3b_brB@xxxxxxxxxxxxx>
<04904e86-5b5f-4aa1-a120-428dac119189@xxxxxxxxxx>
<427fec88-2a74-471e-aeb6-a108ca8c4336@xxxxxxxxxx>
<Z8Z/gnbtiXT9QAZr@MiWiFi-R3L-srv>
<e9c5c247-85fb-43f1-9aa8-47d62321f37b@xxxxxxxxxx>
<aDgQ0lbt1h5v0lgE@tiehlicka>
<a1a5af90-bc8a-448a-81fa-485624d592f3@xxxxxxxxxx>
<aDlsF5tAcUxo4VgT@tiehlicka>
<e0f7fc1e-2227-4c6b-985a-34a697a52679@xxxxxxxxxx>
<aDl1ViMpK_6q_z06@tiehlicka>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <aDl1ViMpK_6q_z06@tiehlicka>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 11:07, Michal Hocko wrote:
> On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
>> On 30.05.25 10:28, Michal Hocko wrote:
> [...]
>>> All that being said I would go with an additional parameter to the
>>> kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
>>> otherwise. That would make the optimized behavior opt in, we do not need
>>> to support all sorts of timeouts and also learn if this is not
>>> sufficient.
>>>
>>> Makes sense?
>>
>> Just so I understand correctly, you mean extending the "crashkernel=" option
>> with a boolean parameter? If set, e.g., wait 1s, otherwise magic number 10?
>
> crashkernel=1G,cma,cma_sane_dma # no wait on transition
But is no wait ok? I mean, any O_DIRECT with any device would at least
take a bit, no?
Of course, there is a short time between the crash and actually
triggerying kdump.
> crashkernel=1G,cma # wait on transition with e.g. 10s timeout
In general, would work for me.
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667833-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 8680741E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:14:52 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 376EA3B4B57
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:14:31 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 1FDD121D3DC;
Fri, 30 May 2025 09:14:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="RSEvMt+v";
dkim=fail reason="signature verification failed" (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="QU7eRfGK"
Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32])
(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 41B4813AC1;
Fri, 30 May 2025 09:14:39 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.177.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596482; cv=fail; b=oWcSkIfTTfISZwuzY9hNxvRQ+h/Jlx1A2B6aMJyQZNn1rbnXBbjRdhmW1jbcnSVVxehyrTLdraeIBKt/0ieceTZOCNSXs1tGqMkGNvRfLC5sv60GJhFRIRP1L0LDNnQ+vn2pte8BMZWSZJyDhrtMvh3W7lRniaFnnugjP7hMmxQ=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596482; c=relaxed/simple;
bh=JSEXr0vsliahzdPEaX5mrxauoCpEc0/SCQEmcT9QG8U=;
h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
Content-Disposition:In-Reply-To:MIME-Version; b=DgIlsQ2J4iUA4Wik7Pr/M+0CTMLQQx+ShVnva6djvG3xoI88ypxKnnIXpY8iziO94opr5xtbglTQi1GlTkT30jPPt2+oy4jg3nl0e3pba2FbPCO/IJrJT38t3T11pCdYcLRwyzAyCNeGKIc+B+ZlJ4jgnzuMaBXWXpuTeU/4cvk=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=RSEvMt+v; dkim=fail (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=QU7eRfGK reason="signature verification failed"; arc=fail smtp.client-ip=205.220.177.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Received: from pps.filterd (m0333520.ppops.net [127.0.0.1])
by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U6trSA015432;
Fri, 30 May 2025 09:14:22 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
:content-transfer-encoding:content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to; s=
corp-2025-04-25; bh=JSEXr0vsliahzdPEaX5mrxauoCpEc0/SCQEmcT9QG8U=; b=
RSEvMt+vLjBOwmjyCanucDNLsGRAXh3TVEV3MFVgn804Qu4BJ3lr8/+jrKtivnVP
jRuiZqEreDA4KddbGVc51fPd6+rZfF7NyYQRIkGxzKQRTB9KTtqcRbNoXi1iV1NC
aGQeajaU02pCD0LifjVbBepxntU6XAE1B3KPe+Wl+keA4b0CHNy1I9+JW5Vz/AP7
ZvfkKLWMo6kz4Q8z5XGmETuHPNqaO5y+UU8gkotiIOLAzq7w8eLUfBYD0DYR+rIn
gjR398q+ikxdRRWRU6f0HFFaNcBSbKov7w5jNzah99oDl3txFsbcWdjFTqxNpaX2
f9P97/Izyr+pMeDagCn/dA==
Received: from phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (phxpaimrmta01.appoci.oracle.com [138.1.114.2])
by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46v0g2hye6-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 09:14:21 +0000 (GMT)
Received: from pps.filterd (phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com [127.0.0.1])
by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 54U8cMZq020324;
Fri, 30 May 2025 09:14:20 GMT
Received: from cy4pr02cu008.outbound.protection.outlook.com (mail-westcentralusazon11011055.outbound.protection.outlook.com [40.93.199.55])
by phxpaimrmta01.imrmtpd1.prodappphxaev1.oraclevcn.com (PPS) with ESMTPS id 46u4jct8ww-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 09:14:20 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=VUnh5hNlzxT/F5HTA/6vB4E90ytezACoqp2q1+QgHtw7/JZVqyYwMvUR4zRAOpTWK9OPIK6aKSHyyN66W8bgeUO5mBUC8UsbXNrXf7OZijH9DDSyAR8Fjk/VDtJbYVYp8LzzDm4UvwdYTuFQ5omATS1QYDitIX5Ra/fuRDWnlXWY/wM7kW3OjYqb+lNXy4mfP6woAZ5XuV9/0VcDcOs9k3vim+cVSnYB27tyTWmtJlFcOk12AO1U07O3oTOgPFiE1SFOpB07AWzH4e17ygygzSUwH4FJRfMzY4T4aCNfIGC8dNQU2VojP19+hWmOaXn1CRplQlbXB3SVVDPv/caThw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=64OPANDehAsJUx8uLpk44yoVSFPJ2AR+5QaL1uksHd4=;
b=O9FU5KNdrlbVcvi2GBjr1l1GqTXB/9jfoIz0qxm5rv7irX3jYo7x+BMT+qjBVr4NCU8f8p8wdvyuhIDSALQ8vyiKimLREQVcd9a3gWGmlNQ5sD/OwEkBVD/lcCJmIW6fUQzcIS3mgRCqQR7krIvACR2TVT9T86uapbUsNQOsp3nNNu8fO91HQjFbEzHMTbgtoFiq5sEcQesMkjcpKOsFUG8rkXWmLohKIG7jNwhmLX3K2VKJSbcgGT13SusiSBqIfFNia6bteh1dIZziZDrNwdxtmGzhWui47GU4p7EjbJ0li+86uJkZLR/NMBm+yNgeHwSM7ThNIGQyuvkAbIxfzQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=64OPANDehAsJUx8uLpk44yoVSFPJ2AR+5QaL1uksHd4=;
b=QU7eRfGK4oFl7yB9cy9ud3dIs9EXWooN7UXMjZ2bHrcUurKFGv8l96OSHvik9qAH68TkTVUT2CY+pUookOh/G/Dy+0IfgjspaCwnfRzSQx0KtnXrNkA8BcPYeUFjkKX5JcOi/Zm7XTD1SDxtEddJrb/3M98ManqsbjgvHF3VII0=
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
by SA1PR10MB5711.namprd10.prod.outlook.com (2603:10b6:806:23e::20) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.35; Fri, 30 May
2025 09:14:18 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.8746.030; Fri, 30 May 2025
09:14:18 +0000
Date: Fri, 30 May 2025 10:14:11 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
To: Ryan Roberts <ryan.roberts@xxxxxxx>
Cc: David Hildenbrand <david@xxxxxxxxxx>,
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
Message-ID: <94b1c1c9-bae5-4e40-ad5e-20dfba5b0ba1@lucifer.local>
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
<f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
<ade3bdb7-7103-4ecd-bce2-7768a0d729ef@lucifer.local>
<9c920642-228b-4eb0-920a-269473ea824e@xxxxxxxxxx>
<00999fc3-3a4a-4ee5-8021-81c73253fe7f@xxxxxxx>
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <00999fc3-3a4a-4ee5-8021-81c73253fe7f@xxxxxxx>
X-ClientProxiedBy: CT2P275CA0132.ZAFP275.PROD.OUTLOOK.COM
(2603:1086:100:21::20) To DM4PR10MB8218.namprd10.prod.outlook.com
(2603:10b6:8:1cc::16)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|SA1PR10MB5711:EE_
X-MS-Office365-Filtering-Correlation-Id: 0b996ff5-12c1-4048-22ff-08dd9f5a5b41
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|366016|7416014|376014;
X-Microsoft-Antispam-Message-Info:
=?iso-8859-1?Q?DyYdF/XGieCWRoboMcgatTKDfbqK+3aFf6dF8M42ijLwoDrxZWXvbdCe7r?=
=?iso-8859-1?Q?WhbV/PFBIkdCfr/dZXVWQg5U1NLTI+ZbtSBrljm23AwoAbZZZ8xwa8ttnJ?=
=?iso-8859-1?Q?nrIiN0iFzOghzwI64JBfNcmMe6X+bM/0lgdmZy/jz1Az/MX3OXBvagZXMc?=
=?iso-8859-1?Q?vk86/p00wLhPSlXMgI1/Wpo/vIJyx7L3o0N13ujVg/7RzPvxgACeIF08H1?=
=?iso-8859-1?Q?xA1TYFnfwU6ppohnuIB8EbQey5znkU1YM/pTnI6c6PbY91CQyv3Ni9uL+7?=
=?iso-8859-1?Q?hvo94tZ5kxdW3BMCk0lBbUqoyWx80qMQHvpGFAb2YD0kKNiqNS+ymtp7+C?=
=?iso-8859-1?Q?x9s0HdR9r16yV6joE+gyHUvwB8yBiJWM2KXd8BrRvKDUirdsg2wDWZBycC?=
=?iso-8859-1?Q?ycCG486b/n6KC8VtEKOMiMrw9yrG9kYSjAVN3Mb8ZOwfGmBfCs7W6pdRKH?=
=?iso-8859-1?Q?sEXlxjbRIrcXnDEmf7Deq4oy5GqT0ZMbNiYr4ADVL8yzbUgcbvyqF95iE2?=
=?iso-8859-1?Q?8ek5aoNFjcSfs/IYh+DupXxXZ+xGtY207k990K+zewcVuHkHIZytA1wy1E?=
=?iso-8859-1?Q?ufayMLFhVbOYTRSYw8LiXr4ATZcJuWFBesgLN1RElB9HdGgIHQgCjI/Y4O?=
=?iso-8859-1?Q?pFptj8S4+7iOdDNUpGlxbl0Z24iCWo4bURhSh23Q9U+mup8OkuG7CjhJvN?=
=?iso-8859-1?Q?eP07PFDG08UDgsHWJrotzXrHvWbnX51t0Jyj64FZx8FP0M22m0L58stEJF?=
=?iso-8859-1?Q?PMXiZkJso0h7JqCvIrXWn+Bvb1fuvvM0i++hIDLfmZSJHJb35Nz6z/zuii?=
=?iso-8859-1?Q?zn38a+VFnDPvHW5eu0nInu2ZW3ym6gPbNGPuVnxR7DBnJQp0aMxdOoEUL0?=
=?iso-8859-1?Q?6ZQgofAiFtqV99nvkMulbsJn9k0jtBG+ySTQafCS0gHU4xmIpvxdTa/wf5?=
=?iso-8859-1?Q?dpRmwo4IXPas7FwPs87fcLhvmfcdtA5dKNVtGreV1XEt1hYyBlm4gX18WD?=
=?iso-8859-1?Q?ajzNdbk0jo5ihj4Qphz19v/gLzCTiQmKzFT7ukuiDEYKWB/+iCUDSE6BX8?=
=?iso-8859-1?Q?mRwTQjxvi4TwmqR9hXlaTxz+s5ZDb2yJ5s35aj2JsY1LfvbWsPDa5q0w2k?=
=?iso-8859-1?Q?ts8IkHAKPWiRLtu9Vg0OimQtJD1vkw33hnO1M5a85oZniPUr5uCryPQMrP?=
=?iso-8859-1?Q?TJ0rI3KEVzlVeNsS8m9GLnuOgXSQNRtzpGEHCurbFIcAkFPrIY0aQ058yO?=
=?iso-8859-1?Q?in2lXEODrSuPdpt64cdQYVenAqz6K8qFae2UX5VmIW74LHrCw2a7v/GsBU?=
=?iso-8859-1?Q?yTBiBchT62dj6pbl9PHfSpBMkMBUb48C3aJnR9/LaBlOFZi5+jg04ww7+M?=
=?iso-8859-1?Q?OS7y/MjMZMryeuqJaIO7dmx/AuOcuZUYJ/miywopW1+mzq0TCTwf3gHkge?=
=?iso-8859-1?Q?UpgZntfv1CbOZdRiQzumZnAfGTPnNONS4wgka5a6TZN1sPH2qcX17l0OR6?=
=?iso-8859-1?Q?A=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(366016)(7416014)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?iso-8859-1?Q?4JIFs1hovPfRD/jog9WfbxdnqYaunlNeCTxLxklbD2fuyA59sMdWH5pnda?=
=?iso-8859-1?Q?/WRHE5J3uTUE6AM7244uJFeh8tfC3lBRZOWB8VILRKtYGVErDKx7HrySKk?=
=?iso-8859-1?Q?AAoNHmGv4TToJQlYNmjbPmH8cF/2SSYu20YaqZyGvOoE8v15tr6EZ3UzAa?=
=?iso-8859-1?Q?4DlLILNtr5m/XbkM79LUVxTibFD5LCBgmurLuBLGQI3WGpi97mIf0d5S7Y?=
=?iso-8859-1?Q?FSVR9tu1GHqZBXeNbqyxW4ApCj29D+6Xn0i8JDIARY6IVGO8JOvwk4rO3J?=
=?iso-8859-1?Q?CwpHh1x0sohF8Fp9G+PC2ewUl8cwSmcKutRQxZrVmS66QaF8tJ5/RqgnGt?=
=?iso-8859-1?Q?PVZBCYD7ytN1Wy153ZC9nLhw25Z7pTPy5YTEBSdq4iEHAWgbtkTwwYBBPl?=
=?iso-8859-1?Q?pHciYHRqEHcE1FYEvHFkuGf9TLr4m9oWE9lGhdj5dT3GqQMBSogAyaimYS?=
=?iso-8859-1?Q?Qh4drDJS1vDJ4jTn4NdpNHmsEpL0DchHicCLk6dJ6Cu8o1VxFs7bWtnupg?=
=?iso-8859-1?Q?u94p6lc2xFMIetq31CGucG+FVIAdVJw7ao/TYmJ9QTLpUgWxu9QBe1qAfz?=
=?iso-8859-1?Q?H6JBX+TKVR7cSv4ls0v7+epndrACF4Sw00N9MrDcCxgYP2W7E8IiBnhWYv?=
=?iso-8859-1?Q?XQgRae0I6GQqrHRaVoLnqJ8Lo//isDgXF+o+Habirn7WfvUaFkRAaMsSQj?=
=?iso-8859-1?Q?kd2b54oxSd5u2X+n86EWijn3ll0ssfg7Q6j3pRH6+vtl93GUUVxFFTPPUS?=
=?iso-8859-1?Q?uIKqSch2012nr0OkpejIHqVWrkeiMQ23KWFW+rYilSawl7Zq3dZaQ77LLD?=
=?iso-8859-1?Q?W/ES9R25dsZMElz2slbaW6eeIPXwM3nRL5tv9nA9Vmxjeje3AL6QDrMDFS?=
=?iso-8859-1?Q?RDE9cw5VVN71qTejPHZoKBLZzB+q/Tl6NkXPBhyER9bPMpiCRhtOdYNa54?=
=?iso-8859-1?Q?xVSErEWSsy0n7F76MLX0XsN/DrN8aRszObYp4/t4IqTc79Bd/ojMnRSLvI?=
=?iso-8859-1?Q?H0/u71S9FHXr0FrUTui5uOIrl5mW1Txqx2zIMzEx6sysciFFh4th8G27Oy?=
=?iso-8859-1?Q?gcpyY+LBY5lGhql6gz4NX5J655ujKoX/Hj7NoH6Owl9Z+9OwKklbbbR2Ug?=
=?iso-8859-1?Q?KIeOAM+lz0dP1Q7moHUDetIyJjtSCFdsYunoVQo08mnB879wbv5ani97Rr?=
=?iso-8859-1?Q?8aiK1tkAyxqn/gfWX/h5XAFzxJ5DuDSJeVf64zViPVWRNVuXDDLWX66Xag?=
=?iso-8859-1?Q?hoZzvOfT9o7huuYnpw74qTNQwo6ShSwAdFJ5iOziV68M1udAMhjukjStE+?=
=?iso-8859-1?Q?FK4p9EAXKWwm1PJbO0l6cI+oLOcQA8ZHQtf9fF1srhU0weEa68lHGWbAAm?=
=?iso-8859-1?Q?U7m1AdG6/e6vzN48F5TAwpvKDIrtvT5U+BwyDDXG0JETeIKpapvPDhAQce?=
=?iso-8859-1?Q?g9lJXT7YP5dTh4NR3AhWzjpwAnWg+w/8KKd+pA6cvnr76vozTLX/CJ12lk?=
=?iso-8859-1?Q?luYUXDue5DXzDa+CMLSSePAs22AcmGwgX5z9qURMP4ydkbzpYQU6m7WYtq?=
=?iso-8859-1?Q?ibuo0+lv5FgCSQ3zxVfQ7bLlBkki59O3ZwyIzeafUBT/5lABdptjdRaQl1?=
=?iso-8859-1?Q?TU5cYWvckNWTmmOJzbw4jZsqBYlSo98GahEUzNBLTstu71vwTu80JFcQ?=
=?iso-8859-1?Q?=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
Q8s8nG20sGGu0cxWV9Q2baYDZlwXG1esPZxJ5+b6IbFXcfoZoqBXLodHjDfUV7Jok//ys1Ctm9oWcXWq/ICSVRW2Mslz9HRjl6+3XN2voewlMpeiueXo0CGxSqc6XUa1lQB+Ftq51vYPkidmxwhwqk7i9JAyNMG70nr2tEjtlCCFkAgELkECqXJisba67uxHSMZX3n0tu1nsVgOLiHKnm7v8ZYAZKw2qQA1MaSrnnQAiOG/GpYlWFQLTkqC7r68981LGIXIwRr4Kl042tCr5V1mU1lVkWrYdiBhPAnbIzjAeZOyS9S9YfwmknRjuA5Q/4QThflsQaH74wzRIP37IOWxG8XECaoxENSDudwD++4eBW1emrdeMjxABVGyc0qj0ofIA+Qh9wtJixutzwnXdUfZ7z/BbqUrv88LaRkhk2am9RG+/8evQSZpJMmEBVVq+VbF46S2KLPNC3wtOCL2RQLBsK9QmRgb0/iK60hZSQR9jDBAMIwWHrmX1UzVpMPjLt5JWf7BqlOVn4FOBVY+vhOeC2yKkmAjH/kzzpl1njbxih1jcq+O6C1xmWcXSLKwAWCHqunAbULeEcD2gfVpuUdSuyuU7zot418ISRw+vVUI=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0b996ff5-12c1-4048-22ff-08dd9f5a5b41
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 09:14:18.4068
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: j8SM/x8sx2F6mcMCErbw1EF9PUwLF/5JcL5ngm1lVGXHcPt2Av2KkYJzF1yNYj4uMjQMsFVOkwcE5VgWzXL4pGusZnYS3TjszpMqmhur23g=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR10MB5711
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 suspectscore=0
adultscore=0 malwarescore=0 bulkscore=0 mlxscore=0 mlxlogscore=999
classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
definitions=main-2505300078
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA3OCBTYWx0ZWRfX8FPBCFBHq0mT /4muMjisSI5vcUimSsmy2OpqQni4dFzleB53GECLoYwGXNX2whvNmY9qpjkHJMOECe2QC9HUBtU 8pmgAXuSlgOqyuaLZ86CYWmWtjktgEpTxm2kSt1ONQhMmnpiHc+n4pY2O0hW8cPKZnkDLNwKEBk
V9MlC5IQ8J7HLdo1Kz63mn0QRdtKM9yETlbbBAtPdmPSmmlR+8ANtKe5c0BSKg4pQWpka+c5Pl0 H7pYL20FAttcdBm1BNX5cLZYDIYOlJ9HeUwf+3o2jxxtsHfliWd9GAQWFWcYl7eL9GkXX+XJjSp wsWmzQ2uk5j7ub2R8m/UDfTcq0ZsRnB6QCd55mZNolETpKgAZPE5hIhEmeY7V8axo96JBbO3xFG
dM230fxyMHJfQJYSEk4Ad1al0LW/y7JkLqVtbnFF0zpwQVCx97Jln6OKlqyVffukW47m64H+
X-Authority-Analysis: v=2.4 cv=NJLV+16g c=1 sm=1 tr=0 ts=683976ed cx=c_pps a=XiAAW1AwiKB2Y8Wsi+sD2Q==:117 a=XiAAW1AwiKB2Y8Wsi+sD2Q==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=8nJEP1OIZ-IA:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=w1_QSfExazcfhmdj_ywA:9 a=3ZKOabzyN94A:10 a=wPNLvfGTeEIA:10
X-Proofpoint-ORIG-GUID: K7G1jC4NDpPsL09jwhDkfbID9-aMC4CX
X-Proofpoint-GUID: K7G1jC4NDpPsL09jwhDkfbID9-aMC4CX
X-Spam-Status: No, score=-3.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 10:07:11AM +0100, Ryan Roberts wrote:
> On 30/05/2025 09:52, David Hildenbrand wrote:
> > On 30.05.25 10:47, Lorenzo Stoakes wrote:
> >> On Fri, May 30, 2025 at 10:44:36AM +0200, David Hildenbrand wrote:
> >>> On 30.05.25 10:04, Ryan Roberts wrote:
> >>>> On 29/05/2025 09:23, Baolin Wang wrote:
> >>>>> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
> >>>>> the system-wide anon/shmem THP sysfs settings, which means that even though
> >>>>> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
> >>>>> attempt to collapse into a anon/shmem THP. This violates the rule we have
> >>>>> agreed upon: never means never. This patch set will address this issue.
> >>>>
> >>>> This is a drive-by comment from me without having the previous context, but...
> >>>>
> >>>> Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
> >>>> user-initiated, synchonous request to use huge pages for a range of memory.
> >>>> There is nothing *transparent* about it, it just happens to be implemented
> >>>> using
> >>>> the same logic that THP uses.
> >>>>
> >>>> I always thought this was a deliberate design decision.
> >>>
> >>> If the admin said "never", then why should a user be able to overwrite that?
> >>>
> >>> The design decision I recall is that if VM_NOHUGEPAGE is set, we'll ignore
> >>> that. Because that was set by the app itself (MADV_NOHUEPAGE).
> >>>
> >>
> >> I'm with David on this one.
> >>
> >> I think it's principal of least surprise - to me 'never' is pretty
> >> emphatic, and keep in mind the other choices are 'always' and... 'madvise'
> >> :) which explicitly is 'hey only do this if madvise tells you to'.
>
> I think it's a bit reductive to suggest that enabled=madvise means all madvise
> calls though. I don't think anyone would suggest MADV_DONTNEED should be ignored
> if enabled=never. MADV_COLLAPSE just happens to be implemented on top of the THP
> logic. But it's a different feature in my view.
No I absolutely take your point, and indeed this is very reductive, but I think
that's a product of this interface being... sub-optimal.
if you dig into the docs for instance it's explicit about that referring to
MADV_[NO]HUGEPAGE.
But, as a user/sys-admin, I'd definitely find that surprising.
I think the intent of 'never' people is 'THP bad I don't want it' for whatever
reason that might be the case.
>
> >>
> >> I'd be rather surprised if I hadn't set madvise and a user uses madvise to
> >> in some fashion override the never.
> >>
> >> I mean I think we all agree this interface is to use a technical term -
> >> crap - and we need something a lot more fine-grained and smart,
>
> Yes agreed there!
>
> >> but I think
> >> given the situation we're in we should make it at least as least surprising
> >> as possible.
>
> >
> > Yes. If you configure "never" you are supposed to suffer, consistently.
> >
>
> OK fair enough. Just giving my 2 cents.
>
>
Your input is very welcome! We have made a mess here so it's good to talk it
through.
Return-Path: <linux-kernel+bounces-667834-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 1588E41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:15:38 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 3E0F74A353B
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:15:39 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id DAC6E20AF98;
Fri, 30 May 2025 09:15:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="nXNoqDvZ";
dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="nXNoqDvZ"
Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2086.outbound.protection.outlook.com [40.107.249.86])
(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 333CB1B0424
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:15:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.249.86
ARC-Seal:i=3; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596532; cv=fail; b=siFwWeTgIS3wLHAp+0bnIqRAKoU1BQqQZ6rXb0FmoAG0rpKhi7HBDIKnuCHIvMyk3mY6wq7YKzjnA4Ozev2+CUSNxBZIgoArkDSB2wqCBznGvtH0+CMfeQSFPlJRTTZfDHjAbRPG2+EO2PxUiM5danc7rHQ6IT5Vtcpu6kMW8lY=
ARC-Message-Signature:i=3; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596532; c=relaxed/simple;
bh=Qy35vRDNo1o34aeArtrynZhzbdYsYKGOmniehb2NUxY=;
h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:
Content-Type:MIME-Version; b=k1ofVUyWbExwqYqQ7xYBeWmfiO0WZFLcvVgW8q+AncRSy4THl6AWuF7ykFb/bSyB3RLrd/A0gQbi9Ru8hLwFIkYnNa4ROd2b6HgaBSm2MKSBXu7sMgooo97yMHmnMa/+eEBbVVTG6ox7uEY386mswfSegRB0i5l6AfyZmkv4KBc=
ARC-Authentication-Results:i=3; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=nXNoqDvZ; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=nXNoqDvZ; arc=fail smtp.client-ip=40.107.249.86
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass;
b=dYA742EnvUMoA+AdBiYf8ua2VRRuF4qNLnun6xT6MqTdhcT0QUXq8QHkfq4k+AieVTgKdnqgk3VhT7O3hKi1d0+6XaYSIFZm7Ckub5d2LMIcqCRBS+azvJd9HzAJybwZbuo6e+zi+uSkoFz30AQPum/EgtYP443rKb0cGGjYPGYBuqOV62Tvb9pi1pq01DSXlQBwfIK8ny8k6bL2wh2EJSAOylBS5JFtN7wL+n9+He6M76WH3RRQfzeXMoFwbqSXXUekkV2ot84X3eGQzUkPRH3v0NSA7Hj/A05epjWh3jDdNzDmnzbUAuL4rtEngkVWL0laGQng10P+F5A5qWK9hg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=8NYD8lIwEtkyeiGV2hg5zGeooAcj2uoDesyDxL28Vpc=;
b=rJKec4mqLDvYAM968nxaU50oD+DEkL2hgd1N0XHHCf0LvufGbpdyDkLLjtSSJN+ecNNdEEQPPjnc4DXaE1Gwy3h0sNU7uMszeXumERXJTkf5+1Kwy6oU9V1nL/XAXE+RNkpjyEdJ9DUcM7rTubRdtVUW5+x0ZLYW8gEK+C8tC9OJCr9ZMXF8aHc7qYKZrcRokpzXAaHLEu9QIXZaYBrIZPE8B3Xpjgg1lzKgtllU2FmqKK/nZUaITZMBrjlVo5zpWLNoqdC8syfvR726QNKjYyrmLl0ghN3orhKx3cuzofJBbO9sRm7FVBj+z6EQNYDh2OVW8wXcaydISi/ADLPDYQ==
ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is
4.158.2.129) smtp.rcpttodomain=kernel.org smtp.mailfrom=arm.com; dmarc=pass
(p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass
(signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1
spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com]
dmarc=[1,1,header.from=arm.com])
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=8NYD8lIwEtkyeiGV2hg5zGeooAcj2uoDesyDxL28Vpc=;
b=nXNoqDvZ1/gQ+uCeGIakKLOY44V7l9Gv9Exf0OZkXi5atN8WVXOxwMMHKIo+K/fCS/diLMkg/uo1KhO/Z1eD+LOvjqckCj3vb6QpCVPP43BORe1Rb3/BrLu0Jw9ZTHxjsO6t1ipnl46SPHPiB2FWGtoa/1E3U0oFgB4XAKFE5fY=
Received: from AS4P251CA0028.EURP251.PROD.OUTLOOK.COM (2603:10a6:20b:5d3::17)
by DU0PR08MB9439.eurprd08.prod.outlook.com (2603:10a6:10:42d::10) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.27; Fri, 30 May
2025 09:15:25 +0000
Received: from AM2PEPF0001C716.eurprd05.prod.outlook.com
(2603:10a6:20b:5d3:cafe::5) by AS4P251CA0028.outlook.office365.com
(2603:10a6:20b:5d3::17) with Microsoft SMTP Server (version=TLS1_3,
cipher=TLS_AES_256_GCM_SHA384) id 15.20.8792.19 via Frontend Transport; Fri,
30 May 2025 09:15:25 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129)
smtp.mailfrom=arm.com; dkim=pass (signature was verified)
header.d=arm.com;dmarc=pass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
4.158.2.129 as permitted sender) receiver=protection.outlook.com;
client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C
Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by
AM2PEPF0001C716.mail.protection.outlook.com (10.167.16.186) with Microsoft
SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.20.8769.18
via Frontend Transport; Fri, 30 May 2025 09:15:25 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=jL3VNaHe12SwJf0TD9EbnJmINdyf1dbLi+sr9HoPxAbl976UmpjbWcQGXoX/IW3gb+XmSbp0XU4MnmFZMghnPdczHjuWijKSiRYk/5SEtvMxxVZEA7alKGLxeBHU8fDFXxCZEmYW5pY11+3eRIlcaQnCQuCofNFuJ96JS7jQIFCJmw69jicAkG1hVXPU/5YeHRvfZ85nVRPdkQBiWbQHxbmmog3MjQYlmWuoQf4v2SPiGiA/C2F5P39gsJWMWPOPcT62jFrX4gicrl04um7vh5uBAbpTei5iXNH5rZ5CEtFQNTuwo2uzipiha+3KjxMRLUgr9+XBO25mIs3BwNQbXg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=8NYD8lIwEtkyeiGV2hg5zGeooAcj2uoDesyDxL28Vpc=;
b=sKBqGKisdEl/jSYbjryeCvWz8UT/QJiQ61Dd15/53313077HtkyGLuYnYKAfBV1jG3RUKu976zdHKuUo+PBUioYu//aA6gWno77KZiylfWCCL5p/qgNxn3xxQz630NT3lsz2Z/8o3wdVBO5Qml7i7XNWu3ax3AaQq5pr822fJIx89uZziJAa6Tn/dpyD+4KGIrPktA1tV91hhjjyLDm92KpYrMEv3JbJGkdlY7dtLF7AOhugZgM+80MqB3ZMgHcLBf34QmIObxfErj9o0II1KOQttK7NVPN+u5OCAvgorCPKMsoVQb7Ok62xIg9RhS9YNcEovthHpjdZV3SF6Ls1Ug==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass
header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=8NYD8lIwEtkyeiGV2hg5zGeooAcj2uoDesyDxL28Vpc=;
b=nXNoqDvZ1/gQ+uCeGIakKLOY44V7l9Gv9Exf0OZkXi5atN8WVXOxwMMHKIo+K/fCS/diLMkg/uo1KhO/Z1eD+LOvjqckCj3vb6QpCVPP43BORe1Rb3/BrLu0Jw9ZTHxjsO6t1ipnl46SPHPiB2FWGtoa/1E3U0oFgB4XAKFE5fY=
Authentication-Results-Original: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=arm.com;
Received: from AM9PR08MB7120.eurprd08.prod.outlook.com (2603:10a6:20b:3dc::22)
by AS8PR08MB6503.eurprd08.prod.outlook.com (2603:10a6:20b:33b::18) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Fri, 30 May
2025 09:14:52 +0000
Received: from AM9PR08MB7120.eurprd08.prod.outlook.com
([fe80::2933:29aa:2693:d12e]) by AM9PR08MB7120.eurprd08.prod.outlook.com
([fe80::2933:29aa:2693:d12e%2]) with mapi id 15.20.8769.025; Fri, 30 May 2025
09:14:52 +0000
Message-ID: <832e84a9-4303-4e21-a88b-94395898fa3e@xxxxxxx>
Date: Fri, 30 May 2025 14:44:47 +0530
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] arm64: Enable vmalloc-huge with ptdump
To: Ryan Roberts <ryan.roberts@xxxxxxx>, catalin.marinas@xxxxxxx,
will@xxxxxxxxxx
Cc: anshuman.khandual@xxxxxxx, quic_zhenhuah@xxxxxxxxxxx,
kevin.brodsky@xxxxxxx, yangyicong@xxxxxxxxxxxxx, joey.gouly@xxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
david@xxxxxxxxxx
References: <20250530082021.18182-1-dev.jain@xxxxxxx>
<d2b63b97-232e-4d2e-816b-71fd5b0ffcfa@xxxxxxx>
Content-Language: en-US
From: Dev Jain <dev.jain@xxxxxxx>
In-Reply-To: <d2b63b97-232e-4d2e-816b-71fd5b0ffcfa@xxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: MA0PR01CA0057.INDPRD01.PROD.OUTLOOK.COM
(2603:1096:a01:ac::15) To AM9PR08MB7120.eurprd08.prod.outlook.com
(2603:10a6:20b:3dc::22)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-TrafficTypeDiagnostic:
AM9PR08MB7120:EE_|AS8PR08MB6503:EE_|AM2PEPF0001C716:EE_|DU0PR08MB9439:EE_
X-MS-Office365-Filtering-Correlation-Id: a393d67c-6e50-4528-b182-08dd9f5a8317
x-checkrecipientrouted: true
NoDisclaimer: true
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam-Untrusted: BCL:0;ARA:13230040|366016|1800799024|376014;
X-Microsoft-Antispam-Message-Info-Original:
=?utf-8?B?NHR5Z2dxMDliQnVhUWxPOXJtU0krUlpML3c1dGIrd0VwSkRSci9UamJ0blNH?=
=?utf-8?B?cVJYeDdwREUrTW1JMWd2Mm91cm5kbXdwSnVkbEppV3pTN29hK2VvQVV0bTZz?=
=?utf-8?B?aUhONFJhN0RrU0pSSkt4K3BVWVB5eThMcnFCanRVeWpYVXRlRi94UHQ0d3hO?=
=?utf-8?B?UDU3WTRQMTFYa2xjQlExSTBRNmVGS0xLOEhUak1jTGpQaWY3WjZWMXRhbDYw?=
=?utf-8?B?SnhUaHpmZWRudE9VWkc5TlZLcWkrWEJJMnIzclJ6WW1kUDBGc0hRL3NWTzhy?=
=?utf-8?B?RXBnL3VHOG1SNUhxblhrcHNmaDREdzBFZlFnc0twdGJxVms2aGdYVzI4VTZW?=
=?utf-8?B?cVBkQ0FwUnpwYUdURDlONmhWa0xYV054cTQ5SDNtdk9ZOXpmVis4TEdJb09p?=
=?utf-8?B?dTNpV3ZGOTFNeXl0dlBFR2kwYzdLcmJ6ekRodm42MEhUTXZNY0h4TjE2aGtF?=
=?utf-8?B?L1Rlb0V5b0oxUVVsY2QwMzRHUHlWSHVYUDg0cHJNN1ZFS3pLc09KZjRiSGJH?=
=?utf-8?B?cWdOOVg3b3pTb3B6VXUxa2xJYUJDaWpZbmlwNE9FUk1PMi9CSEJ4VmhMUDdT?=
=?utf-8?B?cVFINEF3WWc2VUJRU0hiWmxwSFZiUFBab2o3dUxrMzhodDg0d1BETGlzR2tT?=
=?utf-8?B?NHczcGozaG9oSHRaMU9qS052d2dxOWdKQ2hBbXJ3M2lkTCtNazExaUJTaUV5?=
=?utf-8?B?VFNXbWQzS3haMTJ3bzVJK0NLdkRNQjRGM1E5QlE1RXEvL0dLUzRpdU4zSWhI?=
=?utf-8?B?QVJDSWxrNzBGOXl4YndNSkNXMlU4bng3U3QvYW9JK25ieGsvNXR4WFd3NWhJ?=
=?utf-8?B?Q1doOWlwelRKZ3lxZzZoN0dRenJQWUdYRldNUlJQQlhaKy9rdVBSODgvMjZy?=
=?utf-8?B?VmZoNUxRalZlekwwdHp1dDZaTlJnRVpkMzFlRUg2WE1KbUFRc1MyRXBLQVg0?=
=?utf-8?B?ZUxLVkFPUjF2NElMMlprU2prWTl0cDNzVEpVVUZzUHdFa0YyVytERlp5OGRC?=
=?utf-8?B?K3g1akxXdnZBZExab3ZnVHZadGgyU0ZLUUZVR3U4WFNKZnFBTThOekpINnMz?=
=?utf-8?B?cGl6TlRSTnQ4SEgzSERnTC9kTytLOWY0ZGF5ZVpBTkJ1c0NrMUNaTmc1dEh0?=
=?utf-8?B?OEVhUlNaYkFTc2xlZ0hmWDJZSXd3K0V6Vm51Q3pSWTduNmNwd2U1S2xpL0xT?=
=?utf-8?B?Mk01b2REbFp4VkJ5ellUb2tvb0w2NEF1aTVaczFCckRHcGl4VW1qWTc1MHhm?=
=?utf-8?B?OWZKSmtSVmYraEdtd1BFazRQMUdvNmE4dklzTUM1Z25uaW5ISFQzSlRBQlIw?=
=?utf-8?B?Qm1yU2NLV0g3S1VMelZ0bFJpNUh3UERjM0o4cU8zYVN6dCsrM3psT0V3UU1I?=
=?utf-8?B?TndwYWRTdVprUVF3ZlpnNGwvSVpNMzRMNkZMell3S0hWeGhMMWZxRTJHV0ww?=
=?utf-8?B?c3FncU03aWlUSk9JaHlyY3NXRWhGVWtyRmoyMzNsOVVCSGE1eFJ4NEZieUpz?=
=?utf-8?B?VHlLbjluZ1o3MkFEQTAraHhraXl0RU0vdG01VWQ1cmZ6RDB1NHUyOUdGOTQ5?=
=?utf-8?B?QUc4VWNpeTZPQ1ZqOFNTQnZqR3BUaytFbXdoUEZTcitGV0lBd3ozRXBBaDJw?=
=?utf-8?B?WHREK2hMaUtGUHBYUjk0RG1zRDlaRmFkbnJxdSticnRoY2JVZUVoMGxGUDA1?=
=?utf-8?B?bmpZSmdpOGVGMG1Kejg1ZVJra2o2RDM3Ri9EaEQ4aFNFWVZGYVNKTEZkcEVY?=
=?utf-8?B?QW8rQ3JzYitCYlIvVFk0ZzljL1lzcmlocmVYRTI2MitJRWR5a1U3aVU1c2Ey?=
=?utf-8?B?YWV0d3E3aURQeHBqRWNtT2FLQlJKQUFDbFFHMy9rT0M4d3FOL2M1ZzdEN2kw?=
=?utf-8?B?MVZVejg1cVRMOU5JRmtJL1Fjb2lVbDJFOFV0THJtWmZoa2c9PQ==?=
X-Forefront-Antispam-Report-Untrusted:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:AM9PR08MB7120.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014);DIR:OUT;SFP:1101;
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6503
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped:
AM2PEPF0001C716.eurprd05.prod.outlook.com
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id-Prvs:
f64290b3-6508-461d-3941-08dd9f5a6f72
X-Microsoft-Antispam:
BCL:0;ARA:13230040|1800799024|36860700013|35042699022|376014|14060799003|82310400026;
X-Microsoft-Antispam-Message-Info:
=?utf-8?B?aS9mR3RFb2dYL0pJRXUrNjRCQ3EvbFI3RFF3dXh6M1JvdUxiY0R0ZmxYVG9h?=
=?utf-8?B?VlNobEd0WnhlYXI3cTVDVkh4bG1QWURGOFNYVm9Nbm1JZFh4Mnd3YnBYaEkv?=
=?utf-8?B?RFRXMFRBM042VTlyZEUvZVM4OExXa3c0OUpnSXBPckRPRHZ5Yko2cURRaVRo?=
=?utf-8?B?K2dOUEFMMDUvQ3M1UU5ia29iZWJQYkdKSkg1QjZyVTUyRnNWTmYwNHg1Qmdn?=
=?utf-8?B?N3Q0b3ZuNmRoT1liY0ExNGpVYklZVmhXUUtmMHB3eVNmeGx6a0p3QjVtaW1Z?=
=?utf-8?B?Q3lEYXRqRmJFY1YwblYrTjVtMUIyUHNhSHdQTy90Vnllb3BLR0liWE1ZdEtx?=
=?utf-8?B?bDF2NmtnbHhmUG1mNUpicllibEVMOTN3a3E3Y2lxWUFMVjhQZUtIMm5vWkR3?=
=?utf-8?B?aENDY2tEWFVQTGxjdENJY25BY3RyaWRQSkpOYzIyUG9kNlV2U2hwL0cxVm9p?=
=?utf-8?B?dmdZMWc2RG50cHExQTJXWVVnSDdJd1FadDNmQ1BDSEU1bDE1VGtWYmtKdnhw?=
=?utf-8?B?M01GTTZDdHhxN09hRHVDZnpHbzZLendrcGxaQktwTEYybGlSMDZlZE5GV2FF?=
=?utf-8?B?M1VsTVZuemdIajg4S1RyVHIrKzhUR3VIQlE0TW1BK25SYXJnRW1IWlViSURK?=
=?utf-8?B?SDgvNm1WRDA5ZXVLZXIwb2ZDVU9GN2Vyc0hOb2EwclZ4eUZRQWt3QkpCYkps?=
=?utf-8?B?MEZsSjhaWVFXenRhcXMzc1dTaTdqSmFWZUFmWkpndjJ5WDFTQkNQY3JGYTIw?=
=?utf-8?B?eUhhZUZGZnVXNUI3TW5sUzdtcGRqK0pjUG5WRzdVTlVKUEI0emIrQ285eGk0?=
=?utf-8?B?Z2lVWHZOZTdJVEpwdjdKaHhJNTFsRjRjQktZbWYrUnNuZU00cktlZFZQMVVl?=
=?utf-8?B?cDFObE9iSEpKUmE0REpCZ1pQc1ZyTDEzU2IwbGpZL3g2Y0dPSEl1RWNKT1pk?=
=?utf-8?B?N2wrWGJkejg5MmRXaktjTERrZGJNZGl4TnlYeVhqMXFYaTcyOUVHRUNPYUdC?=
=?utf-8?B?ZzZJL0NyRTl5TURWMmhwZ0YwNFhSQlkyQ3ZMN1JzTWh6RG52bTdKMjRqYjRs?=
=?utf-8?B?c2xxZGRRdndCamIyQnM2d29peHZkRkhTS284RStnZjY0aTFFL3BTdVdMNmxE?=
=?utf-8?B?TUlvOXRJcjRVZGJ0cXVnblZqZ3Z0TWQ0ZDdJUzJJa0l4cmhveGJoVTk2YTJ2?=
=?utf-8?B?OXloRkU2TVUvODhQU3VtWWNlN2xwNkhUZElVcXZwaHY2cjhOcVVPMzA3aS9Y?=
=?utf-8?B?US82SjY2SWhkRSszVHJ6b01QTWhieUdpRzBQYWo4MGt5TVJ2cFdnVFJYUjNl?=
=?utf-8?B?VzFYeVRBSWV1b0daTWI1MjBleTkyTFR0OTZHMmZJVmFBRmdIbnJmbUsxaGh6?=
=?utf-8?B?cVBBR1E5SXNhZzFnbW9uejd2R3QwdUpkaVdxbkM2ZkxoQktFYUdldGxYaWs1?=
=?utf-8?B?NjdRM09mWWZaYVdhbzUrNHFFTndsRWJLZ2tZbUhoaUxHMXhCVVA3QUVKdHVH?=
=?utf-8?B?eFVDR0pHNjNnMHphL2xheHBPT0dJWGsxK0JraTVFQmd6NWpUbGJiUGQ1eHA2?=
=?utf-8?B?UHZQNGwzMEVXVnVEZDBPRjhwNHVKdXVaTXoweHovY3JXRVZPaCsrR3l5K0E4?=
=?utf-8?B?Wm5tTE1CZS9WNWxKM1F1NGozQzNIaEJMRVVHQ1Jzc3BuZ0NIMUovazcxMkZM?=
=?utf-8?B?YndTRnovbGVQNkhMU1RRQURkNExPdVU0VnM1bHVJcldGbVNraFRaYXBNV2NW?=
=?utf-8?B?VHUreW56VURhaWhKd0x3SVFSMUNpZFJ5dTBaS3dycXBkZWZJUXQxci9DdXVE?=
=?utf-8?B?Qk82R280NE00Q1ltSW9qTW5mTmt5MW14aGxjc1dWd2tWNFBKb2Z6dytodVlq?=
=?utf-8?B?SHphS0V2RHk1LzNIZHgyK1BJWlptODRRWms2dnQ2dHMxSEJReVhNNWtrdzhC?=
=?utf-8?B?d0M0NmJQWTBndnZ6QmthM3REZEhxcGNlWE9wbUNoakRpdHRRMWN4elhaMFZm?=
=?utf-8?B?ZkJsRDZycjZSQURnMjJtbG42Mktia0dJZ0J4dnkvTnRwUGhtWkF2WEhoazNW?=
=?utf-8?Q?S5Ocb9?=
X-Forefront-Antispam-Report:
CIP:4.158.2.129;CTRY:GB;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:outbound-uk1.az.dlp.m.darktrace.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230040)(1800799024)(36860700013)(35042699022)(376014)(14060799003)(82310400026);DIR:OUT;SFP:1101;
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 09:15:25.0729
(UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a393d67c-6e50-4528-b182-08dd9f5a8317
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[4.158.2.129];Helo=[outbound-uk1.az.dlp.m.darktrace.com]
X-MS-Exchange-CrossTenant-AuthSource:
AM2PEPF0001C716.eurprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9439
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30/05/25 2:10 pm, Ryan Roberts wrote:
> On 30/05/2025 09:20, Dev Jain wrote:
>> arm64 disables vmalloc-huge when kernel page table dumping is enabled,
>> because an intermediate table may be removed, potentially causing the
>> ptdump code to dereference an invalid address. We want to be able to
>> analyze block vs page mappings for kernel mappings with ptdump, so to
>> enable vmalloc-huge with ptdump, synchronize between page table removal in
>> pmd_free_pte_page()/pud_free_pmd_page() and ptdump pagetable walking. We
>> use mmap_read_lock and not write lock because we don't need to synchronize
>> between two different vm_structs; two vmalloc objects running this same
>> code path will point to different page tables, hence there is no race.
My "correction" from race->no problem was incorrect after all :) There will
be no race too since the vm_struct object has exclusive access to whatever
table it is clearing.
>>
>> Signed-off-by: Dev Jain <dev.jain@xxxxxxx>
>> ---
>> arch/arm64/include/asm/vmalloc.h | 6 ++----
>> arch/arm64/mm/mmu.c | 7 +++++++
>> 2 files changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/vmalloc.h b/arch/arm64/include/asm/vmalloc.h
>> index 38fafffe699f..28b7173d8693 100644
>> --- a/arch/arm64/include/asm/vmalloc.h
>> +++ b/arch/arm64/include/asm/vmalloc.h
>> @@ -12,15 +12,13 @@ static inline bool arch_vmap_pud_supported(pgprot_t prot)
>> /*
>> * SW table walks can't handle removal of intermediate entries.
>> */
>> - return pud_sect_supported() &&
>> - !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
>> + return pud_sect_supported();
>> }
>>
>> #define arch_vmap_pmd_supported arch_vmap_pmd_supported
>> static inline bool arch_vmap_pmd_supported(pgprot_t prot)
>> {
>> - /* See arch_vmap_pud_supported() */
>> - return !IS_ENABLED(CONFIG_PTDUMP_DEBUGFS);
>> + return true;
>> }
>>
>> #endif
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index ea6695d53fb9..798cebd9e147 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -1261,7 +1261,11 @@ int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr)
>> }
>>
>> table = pte_offset_kernel(pmdp, addr);
>> +
>> + /* Synchronize against ptdump_walk_pgd() */
>> + mmap_read_lock(&init_mm);
>> pmd_clear(pmdp);
>> + mmap_read_unlock(&init_mm);
> So this works because ptdump_walk_pgd() takes the write_lock (which is mutually
> exclusive with any read_lock holders) for the duration of the table walk, so it
> will either consistently see the pgtables before or after this removal. It will
> never disappear during the walk, correct?
>
> I guess there is a risk of this showing up as contention with other init_mm
> write_lock holders. But I expect that pmd_free_pte_page()/pud_free_pmd_page()
> are called sufficiently rarely that the risk is very small. Let's fix any perf
> problem if/when we see it.
We can avoid all of that by my initial approach - to wrap the lock around CONFIG_PTDUMP_DEBUGFS.
I don't have a strong opinion, just putting it out there.
>
>> __flush_tlb_kernel_pgtable(addr);
> And the tlbi doesn't need to be serialized because there is no security issue.
> The walker can be trusted to only dereference memory that it sees as it walks
> the pgtable (obviously).
>
>> pte_free_kernel(NULL, table);
>> return 1;
>> @@ -1289,7 +1293,10 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr)
>> pmd_free_pte_page(pmdp, next);
>> } while (pmdp++, next += PMD_SIZE, next != end);
>>
>> + /* Synchronize against ptdump_walk_pgd() */
>> + mmap_read_lock(&init_mm);
>> pud_clear(pudp);
>> + mmap_read_unlock(&init_mm);
> Hmm, so pud_free_pmd_page() is now going to cause us to acquire and release the
> (upto) lock 513 times (for a 4K kernel). I wonder if there is an argument for
> clearing the pud first (under the lock), then the pmds can all be cleared
> without a lock, since the walker won't be able to see the pmds once the pud is
> cleared.
Yes, we can isolate the PMD table in case the caller of pmd_free_pte_page is
pud_free_pmd_page. In this case, vm_struct_1 has exclusive access to the entire
pmd page, hence no race will occur. But, in case of vmap_try_huge_pmd() being the
caller, we cannot drop the locks around pmd_free_pte_page. So we can have something
like
#ifdef CONFIG_PTDUMP_DEBUGFS
static inline void ptdump_synchronize_lock(bool flag)
{
if (flag)
mmap_read_lock(&init_mm);
}
and pass false when the caller is pud_free_pmd_page.
>
> Thanks,
> Ryan
>
>> __flush_tlb_kernel_pgtable(addr);
>> pmd_free(NULL, table);
>> return 1;
Return-Path: <linux-kernel+bounces-667835-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id BAE2941E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:16:22 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 81C587AF9B8
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:15:02 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 2003821CA1C;
Fri, 30 May 2025 09:16:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="w+x4MLul"
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 CF8AF1B0424
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:16:07 +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=1748596571; cv=none; b=ruhQgvDYVw38Ujp0NN2fyrkcsFKU48D7SwbdMVRf5puyzqLt4pIg9YOQSEvQ9bniiorUvbv42rK/6OuQ60i04d+g/BPQ07pLw4GagBUIWMgY3brBfAdCnL8+0Rz+vrRWH7UTI8pvJ8JYgHr5QNIald5N9c2ZxQ2NbQwf743GnJo=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596571; c=relaxed/simple;
bh=owr2CtBbxpsrcTH/9aunq/TI9QRa09vxoY6sSA98HoA=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=LlgQY0EmFBrIptmHXliRKhf26tpWI498TV8XfKYPK2j+Fkq1i2hRNLyRZI2av5yLv/5iZZj9354gAolBLtir29/vZ2EigfNSvaX4Qm6s0fmdyPHD7MuoQmjC6FRykb2MY8kf5JqKFjSZ94Q+4KlRvhSJujPJwhuOvfdiljqdG+I=
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=w+x4MLul; arc=none smtp.client-ip=209.85.128.41
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-f41.google.com with SMTP id 5b1f17b1804b1-450cf0120cdso14343085e9.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1748596566; x=1749201366; darn=vger.kernel.org;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:from:to:cc:subject:date:message-id:reply-to;
bh=N+8n16Dgs+TLt7SXuEAKpeYWp0+QUtR4WGU4q9KQr8k=;
b=w+x4MLulxFg0dtUx1jwEFAYwRH6etcoWfr4+Qx73kVHpt/b/2OiTkGjRT/J7f7jfcp
yrHyUYj1zuPScIzJTqbBkDIPO795iAuC3j7EP34tTUBBA+VfLmyc5dgK0PLPoyCtNrqc
QFTQOwxn7r7Ufe5IGyRzre9IjeYnmk3z+OXh4LHZaJVwJORzErhR4C9Y8U/XkmaHvttl
D2YBDvCzSpwnWYeEDOUOSVDO/473AC7TYvISjqkPXfZtg+YJEtrFA/e4uoGMAn3MVCXd
2iiGg7if21rM3HV28iU6deFLkMd9fRnIYjeevh1kwtxT7T9M4cmcl5/5/jJi8r0eJsoM
45Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748596566; x=1749201366;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=N+8n16Dgs+TLt7SXuEAKpeYWp0+QUtR4WGU4q9KQr8k=;
b=sLXcoX5Lbv19c7RYYHP16UACjNajBqXuTV24zaBKwGwYWAjDwsFTzgPRJ8m/srQsHR
Yv2Ne7vGw4wFFavADAg2lZ7D6o8ybVnkoFq589li5WDouAGWRzpjzqcEuv74Te/k9PQ3
EiPkPcoOEnXCZzNW7kq07r4BczgW5hMGJ3BFvW5uL8I32eLxMG2rUpBGYE+AX9xr1G6Q
+UrxJeqrgq3e7QN6hJOcpfkNVWhD5jEk/8+ZabvFG0PiOreIN51/JaVUi8m40tPWh6uJ
1N7i5NnvVewlR26BRea3/rAFsx7lj7o3/x/AKeFybEABbGaNkkDB3edN8Sg+DoImYWkG
yY/Q==
X-Forwarded-Encrypted: i=1; AJvYcCWTdl77RPiKvTAw7440TXFz/2/BF3+y1tkhcJOyPkstQ9K7Ls0XceeM31vu2NiUZfP7ieyFhiz4rqetTcc=@vger.kernel.org
X-Gm-Message-State: AOJu0YyowmMQtU8YMySRs3tZ9uA5cbG3AS6L0sAYbbYlocj3/L0Iht+J
e/RfQHsVZcu98vrrKeAj/EZ1JM+AF99Y9PdaZpQ2b8nlYc9ruQ9tSw6T6WiAB6aW864+4Z9QX9V
kWKMXh5Y=
X-Gm-Gg: ASbGnct3fMAMr9cFWwVoVpgvmoIdqjiVacyFt/+lJ9jNbkgzZBfkgpRa5l5lu4nB5Ee
BhJK2imdfrZSUz5HQaQj3bxDfiwVN6n44SximjurrfxUOtMNT/z0Pxv6VO5k/O/SV5krgRy/MlQ
pWaCvT1bZWmmeEHpAOBx0x7H6blV6JKc3tXyzJ6uEwY1dHNXbPo4htop/c7XruZ6qqMVJXOVZOb
zMJDSGV9YmZjYCrVGWZtdWATqVthSfvrhHIEpT29kD2cYUunzwkmqJBkuFpOQy7OYqTDq6GFn6o
xubm3T12fmZ1J81S5T+31T92Pv42vu36/7Lz6aDCRX6NOkna5ScqztJ2cXH8LwHSzkEJv11Ft0M
QfZ7v8CseaGDjhZvo
X-Google-Smtp-Source: AGHT+IEbdS/TpOHmYnUw9uKw+VAaKchZFgRWMcMXvl9FMyzTyiK33jqXfpDzaSbVjh0F091zKNKyZA==
X-Received: by 2002:a05:600c:3551:b0:450:d01e:78e1 with SMTP id 5b1f17b1804b1-450d64dfffbmr27589655e9.9.1748596566095;
Fri, 30 May 2025 02:16:06 -0700 (PDT)
Received: from [192.168.0.35] (188-141-3-146.dynamic.upc.ie. [188.141.3.146])
by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fa2541sm12493885e9.15.2025.05.30.02.16.05
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 02:16:05 -0700 (PDT)
Message-ID: <ca9f7308-4b92-4d23-bfe7-f8d18d20de10@xxxxxxxxxx>
Date: Fri, 30 May 2025 10:16:04 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] interconnect: avoid memory allocation when 'icc_bw_lock'
is held
To: Gabor Juhos <j4g8y7@xxxxxxxxx>, Georgi Djakov <djakov@xxxxxxxxxx>,
Raviteja Laggyshetty <quic_rlaggysh@xxxxxxxxxxx>
Cc: linux-pm@xxxxxxxxxxxxxxx, linux-arm-msm@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx
References: <TIkPOGVjPeCjPzjVtlSb6V5CIcpaXf2-6WG6HjAyaOW59Hj01-9VK7Z8DKadakOKr6fJeQICi6h0Z8mft9DQyg==@protonmail.internalid>
<20250529-icc-bw-lockdep-v1-1-3d714b6a9374@xxxxxxxxx>
Content-Language: en-US
From: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
In-Reply-To: <20250529-icc-bw-lockdep-v1-1-3d714b6a9374@xxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 29/05/2025 15:46, Gabor Juhos wrote:
> The 'icc_bw_lock' mutex is introduced in commit af42269c3523
> ("interconnect: Fix locking for runpm vs reclaim") in order
> to decouple serialization of bw aggregation from codepaths
> that require memory allocation.
>
> However commit d30f83d278a9 ("interconnect: core: Add dynamic
> id allocation support") added a devm_kasprintf() call into a
> path protected by the 'icc_bw_lock' which causes this lockdep
> warning (at least on the IPQ9574 platform):
Missing a Fixes tag.
>
> ======================================================
> WARNING: possible circular locking dependency detected
> 6.15.0-next-20250529 #0 Not tainted
> ------------------------------------------------------
> swapper/0/1 is trying to acquire lock:
> ffffffc081df57d8 (icc_bw_lock){+.+.}-{4:4}, at: icc_init+0x8/0x108
>
> but task is already holding lock:
> ffffffc081d7db10 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x28/0x108
>
> which lock already depends on the new lock.
>
> the existing dependency chain (in reverse order) is:
>
> -> #1 (fs_reclaim){+.+.}-{0:0}:
> fs_reclaim_acquire+0x7c/0xb8
> slab_alloc_node.isra.0+0x48/0x188
> __kmalloc_node_track_caller_noprof+0xa4/0x2b8
> devm_kmalloc+0x5c/0x138
> devm_kvasprintf+0x6c/0xb8
> devm_kasprintf+0x50/0x68
> icc_node_add+0xbc/0x160
> icc_clk_register+0x15c/0x230
> devm_icc_clk_register+0x20/0x90
> qcom_cc_really_probe+0x320/0x338
> nss_cc_ipq9574_probe+0xac/0x1e8
> platform_probe+0x70/0xd0
> really_probe+0xdc/0x3b8
> __driver_probe_device+0x94/0x178
> driver_probe_device+0x48/0xf0
> __driver_attach+0x13c/0x208
> bus_for_each_dev+0x6c/0xb8
> driver_attach+0x2c/0x40
> bus_add_driver+0x100/0x250
> driver_register+0x68/0x138
> __platform_driver_register+0x2c/0x40
> nss_cc_ipq9574_driver_init+0x24/0x38
> do_one_initcall+0x88/0x340
> kernel_init_freeable+0x2ac/0x4f8
> kernel_init+0x28/0x1e8
> ret_from_fork+0x10/0x20
>
> -> #0 (icc_bw_lock){+.+.}-{4:4}:
> __lock_acquire+0x1348/0x2090
> lock_acquire+0x108/0x2d8
> icc_init+0x50/0x108
> do_one_initcall+0x88/0x340
> kernel_init_freeable+0x2ac/0x4f8
> kernel_init+0x28/0x1e8
> ret_from_fork+0x10/0x20
>
> other info that might help us debug this:
>
> Possible unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(fs_reclaim);
> lock(icc_bw_lock);
> lock(fs_reclaim);
> lock(icc_bw_lock);
>
> *** DEADLOCK ***
>
> 1 lock held by swapper/0/1:
> #0: ffffffc081d7db10 (fs_reclaim){+.+.}-{0:0}, at: icc_init+0x28/0x108
>
> stack backtrace:
> CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.15.0-next-20250529 #0 NONE
> Hardware name: Qualcomm Technologies, Inc. IPQ9574/AP-AL02-C7 (DT)
> Call trace:
> show_stack+0x20/0x38 (C)
> dump_stack_lvl+0x90/0xd0
> dump_stack+0x18/0x28
> print_circular_bug+0x334/0x448
> check_noncircular+0x12c/0x140
> __lock_acquire+0x1348/0x2090
> lock_acquire+0x108/0x2d8
> icc_init+0x50/0x108
> do_one_initcall+0x88/0x340
> kernel_init_freeable+0x2ac/0x4f8
> kernel_init+0x28/0x1e8
> ret_from_fork+0x10/0x20
>
> Move the memory allocation part of the code outside of the protected
> path to eliminate the warning. Also add a note about why it is moved
> to there,
>
> Fixes: d30f83d278a9 ("interconnect: core: Add dynamic id allocation support")
> Signed-off-by: Gabor Juhos <j4g8y7@xxxxxxxxx>
> ---
> drivers/interconnect/core.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 1a41e59c77f85a811f78986e98401625f4cadfa3..acdb3b8f1e54942dbb1b71ec2b170b08ad709e6b 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -1023,6 +1023,16 @@ void icc_node_add(struct icc_node *node, struct icc_provider *provider)
> return;
>
> mutex_lock(&icc_lock);
> +
> + if (node->id >= ICC_DYN_ID_START) {
> + /*
> + * Memory allocation must be done outside of codepaths
> + * protected by icc_bw_lock.
> + */
> + node->name = devm_kasprintf(provider->dev, GFP_KERNEL, "%s@%s",
> + node->name, dev_name(provider->dev));
> + }
> +
> mutex_lock(&icc_bw_lock);
>
> node->provider = provider;
> @@ -1038,10 +1048,6 @@ void icc_node_add(struct icc_node *node, struct icc_provider *provider)
> node->avg_bw = node->init_avg;
> node->peak_bw = node->init_peak;
>
> - if (node->id >= ICC_DYN_ID_START)
> - node->name = devm_kasprintf(provider->dev, GFP_KERNEL, "%s@%s",
> - node->name, dev_name(provider->dev));
> -
> if (node->avg_bw || node->peak_bw) {
> if (provider->pre_aggregate)
> provider->pre_aggregate(node);
>
> ---
> base-commit: 5fed7fe33c2cd7104fc87b7bc699a7be892befa2
> change-id: 20250529-icc-bw-lockdep-ed030d892a19
>
> Best regards,
> --
> Gabor Juhos <j4g8y7@xxxxxxxxx>
>
>
The locking in this code is a mess.
Which data-structures does icc_lock protect node* pointers I think and
which data-structures does icc_bw_lock protect - "bw" data structures ?
Hmm.
Looking at this code I'm not sure at all what icc_lock was introduced to do.
Can we not just drop it entirely ?
---
bod
Return-Path: <linux-kernel+bounces-667836-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 7880C41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:17:10 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 79D887B0297
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:15:51 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 11E0921D3F0;
Fri, 30 May 2025 09:16:59 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Nt6pWpEp"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124])
(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 5F25C1B0424
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:16:56 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596618; cv=none; b=WUKF8zIqadGPhwAGcTKl9Y7RUahDiFXp2ArZcJsINQrlf1eJxNU2MSGtyiXPeWKGw8HIwKdz+40HiB5Q2/O5Iip+q+F1AbNIlO8w7WoDdjGBdgHhw+ve3ylniFPnOgiPRcO3XV+eKSILVJT5egzU68dwlgvZOwQhycZpLr9jtEU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596618; c=relaxed/simple;
bh=3Kf6kVi64DQs2E6TDPGaA77+XK9d2spYG+nWC9mHJ4g=;
h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References:
In-Reply-To:Content-Type; b=mbHBTHjye382PLqmVJLcda5EBydeh/8T8KdF95mM0u1ta05gIoZHTQasRc12FWoJcmRJ9wPZxbnHtI5jR2J4V9TAVwxmsLPxI3e7mwtBZz9T3tOdQlT2ftuUIE73fz6AqrvZd1VtZgTeeOBHTaVmyIyXpbSGpie9UQuXtIlP6CQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Nt6pWpEp; arc=none smtp.client-ip=170.10.129.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748596615;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=9y9kTb+lqmmaSukGtEqz0HE9z0BD3W51Gpy3XyW7nPI=;
b=Nt6pWpEpy+fNQ92GjGHJGi2psiAcR/1PHqShXHDv9XmBxWtxY5NsnKnMfAS/zUVX15pN0G
DGtc/fEFzNcmOI+Li50HTTJyNvYqk6JEg6jq+QEqwmzN9LdMDaH0Ab2v/FFBWQhK7WQSDh
8Mi4piAxpfK6Z5nXxNhb2Bt8J0nijD4=
Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com
[209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-383-eOwL4yI9OReShHd45VONxw-1; Fri, 30 May 2025 05:16:54 -0400
X-MC-Unique: eOwL4yI9OReShHd45VONxw-1
X-Mimecast-MFC-AGG-ID: eOwL4yI9OReShHd45VONxw_1748596613
Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-450d9f96f61so2908905e9.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:16:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748596613; x=1749201413;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:references:cc:to:from:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=9y9kTb+lqmmaSukGtEqz0HE9z0BD3W51Gpy3XyW7nPI=;
b=px/uFGMRwW7+g9p93z1UvM12S9zMj42YsFYBMiRSVjtbtk4yZSA2p8Fqr0uBQtsKxm
lpOINfwlxQRxtn07n6LQqGfhq2/fnWQYvrryi3oGYo8DJrziWVaMqYvjHbYjOVBAxFfA
MDhoLz+nuiP5fE1u/1GaT0KSAVnMpYKaEkdBplfAic9bWsDNFrgf+vyCi5EjuX2njnIK
pex+yrV+iyEBhgd9S3vAaSwDW9ZaVU+jVJqQm2gchbP1num2Dmk8yh2jXp3IVfRUvV8I
Fof8+EAYJy7sYrfbktILf+jaxrR9q4XOmQ/OhAPj6mPU47uZ/r8/FlGRLw16hv4WGJ08
xgsw==
X-Forwarded-Encrypted: i=1; AJvYcCWSkNHSQOp/1jVlbq8kIqFlW9l59V3MQNKneZ4S4ATqg1QY6e1vGC8cw0SXvzVCQk+UZfG+6rNBYbe35Cg=@vger.kernel.org
X-Gm-Message-State: AOJu0YxLVA/7mKlyjVDLkhCFUhwhgUVxY5/+W2/FMfbdW603AwYWgJ0M
F6OhuPCcD1nrPUVZmYHGUpKJZOorOXL/T0eaKq3sXNPuhMBWRifSipv0NJvnBuUOsDORNrH/Syh
4e+9M0zcxPvhS6nc4ouF+3squFrF/3tPQI89i+HJ/2ztOfM6mLKV6KmRnN+ujpnA2qA==
X-Gm-Gg: ASbGnctVz7hSGb3N2lTTw4+1NEd5fVhPnJE269IA/cZ2si2cKHJlKCHEh4WRry0Fl41
VlG3PSor0JSEVRPzC05M0WqOCByemlxe7XZv7Ghytcl67LtGHnIKZGgt9i40GFeAuuCi5sogVLb
yPx4dEN7y2+bOswQXR1Gzx6XUBz77PFs/iI41ugBu6nFggl2ygCxMyEn+3AxS8e/d5RhrcyJKmJ
nvuOZMsY1cPz8rNaU2j9oqSLphE9ZwUbUnK24+/hLHUjIFNtB8GenW3/mMLhVgb8I8vmKRXc0Hx
Jcd2kEq1eoKxyJdE17VjMyuEdw3p0cNw0yB+10ilkm4pLY6syF4WPOIgdVU2Ug1Xl6L77gisHMf
m0FgxdnH4SWU75OgKUcRF+9gx4t0xBNCb/0T5wPc=
X-Received: by 2002:a05:600c:524a:b0:450:cf01:7310 with SMTP id 5b1f17b1804b1-450d6515d10mr26944975e9.12.1748596612870;
Fri, 30 May 2025 02:16:52 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEBWocUY/6KmmmRLvQVhuH3iQB0i/0E2uSc2uf1qdijy9zo03eEStvS9QwvnvaE6XwuVgirMQ==
X-Received: by 2002:a05:600c:524a:b0:450:cf01:7310 with SMTP id 5b1f17b1804b1-450d6515d10mr26944665e9.12.1748596612442;
Fri, 30 May 2025 02:16:52 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7fb8751sm12473845e9.29.2025.05.30.02.16.51
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 02:16:52 -0700 (PDT)
Message-ID: <6caefe0b-c909-4692-a006-7f8b9c0299a6@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:16:51 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 0/2] fix MADV_COLLAPSE issue if THP settings are disabled
From: David Hildenbrand <david@xxxxxxxxxx>
To: Ryan Roberts <ryan.roberts@xxxxxxx>,
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx,
hughd@xxxxxxxxxx
Cc: lorenzo.stoakes@xxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, npache@xxxxxxxxxx,
dev.jain@xxxxxxx, ziy@xxxxxxxxxx, linux-mm@xxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
References: <cover.1748506520.git.baolin.wang@xxxxxxxxxxxxxxxxx>
<05d60e72-3113-41f0-b81f-225397f06c81@xxxxxxx>
<f3dad5b5-143d-4896-b315-38e1d7bb1248@xxxxxxxxxx>
<9b1bac6c-fd9f-4dc1-8c94-c4da0cbb9e7f@xxxxxxx>
<abe284a4-db5c-4a5f-b2fd-e28e1ab93ed1@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <abe284a4-db5c-4a5f-b2fd-e28e1ab93ed1@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 11:10, David Hildenbrand wrote:
> On 30.05.25 10:59, Ryan Roberts wrote:
>> On 30/05/2025 09:44, David Hildenbrand wrote:
>>> On 30.05.25 10:04, Ryan Roberts wrote:
>>>> On 29/05/2025 09:23, Baolin Wang wrote:
>>>>> As we discussed in the previous thread [1], the MADV_COLLAPSE will ignore
>>>>> the system-wide anon/shmem THP sysfs settings, which means that even though
>>>>> we have disabled the anon/shmem THP configuration, MADV_COLLAPSE will still
>>>>> attempt to collapse into a anon/shmem THP. This violates the rule we have
>>>>> agreed upon: never means never. This patch set will address this issue.
>>>>
>>>> This is a drive-by comment from me without having the previous context, but...
>>>>
>>>> Surely MADV_COLLAPSE *should* ignore the THP sysfs settings? It's a deliberate
>>>> user-initiated, synchonous request to use huge pages for a range of memory.
>>>> There is nothing *transparent* about it, it just happens to be implemented using
>>>> the same logic that THP uses.
>>>>
>>>> I always thought this was a deliberate design decision.
>>>
>>> If the admin said "never", then why should a user be able to overwrite that?
>>
>> Well my interpretation would be that the admin is saying never *transparently*
>> give anyone any hugepages; on balance it does more harm than good for my
>> workloads. The toggle is called transparent_hugepage/enabled, after all.
>
> I'd say it's "enabling transparent huge pages" not "transparently
> enabling huge pages". After all, these things are ... transparent huge
> pages.
>
> But yeah, it's confusing.
>
>>
>> Whereas MADV_COLLAPSE is deliberately applied to a specific region at an
>> opportune moment in time, presumably because the user knows that the region
>> *will* benefit and because that point in the execution is not sensitive to latency.
>
> Not sure if MADV_HUGEPAGE is really *that* different.
>
>>
>> I see them as logically separate.
>>
>>>
>>> The design decision I recall is that if VM_NOHUGEPAGE is set, we'll ignore that.
>>> Because that was set by the app itself (MADV_NOHUEPAGE).
>>
>> Hmm, ok. My instinct would have been the opposite; MADV_NOHUGEPAGE means "I
>> don't want the risk of latency spikes and memory bloat that THP can cause". Not
>> "ignore my explicit requests to MADV_COLLAPSE".
>>
>> But if that descision was already taken and that's the current behavior then I
>> agree we have an inconsistency with respect to the sysfs control.
>>
>> Perhaps we should be guided by real world usage - AIUI there is a cloud that
>> disables THP at system level today (Google?).
> The use case I am aware of for disabling it for debugging purposes.
> Saved us quite some headake in the past at customer sites for
> troubleshooting + workarounds ...
>
>
> Let's take a look at the man page:
>
> MADV_COLLAPSE is independent of any sysfs (see sysfs(5)) setting
> under /sys/kernel/mm/transparent_hugepage, both in terms of determining
> THP eligibility, and allocation semantics.
>
> I recall we discussed that it should ignore the max_ptes_none/swap/shared.
>
> But "any" setting would include "enable" ...
It kind-of contradicts the linked
Documentation/admin-guide/mm/transhuge.rst, where we have this
*beautiful* comment
"Transparent Hugepage Support for anonymous memory can be entirely
disable (mostly for debugging purposes".
I mean, "entirely" is also pretty clear to me.
I would assume that the man page of MADV_COLLAPSE should have talked
about ignoring *khugepaged* toggles (max_ptes_none ...), at least that's
what I recall from the discussions back then.
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667837-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id A121041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:17:25 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id C47804A34D0
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:17:26 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 41BC621D3F0;
Fri, 30 May 2025 09:17:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Qdssh3k1"
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 66834213E69;
Fri, 30 May 2025 09:17:17 +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=1748596638; cv=none; b=cJHR1eEHXIbZJFahK1bcA9nHodoY51lXfGnHsg0Kn7AcoxPapdTGpN1lTPzUK0rtIyIAaKPP3Y7QJqtkKMra1xP2RlAIbBUOTvQNGoClnb84K0xTmQZHhH+TQfVX+WEblvUGeWehwWU137JXB03fnc1BEHn+/9EFVId008KQpYQ=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596638; c=relaxed/simple;
bh=rvOVWJD5+xqMqRK/AGl01bB/hKBxArXk3yGsiYQz278=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=Emy2AqJZecsGy550AYwtEgMl/fCHSFc8Ey974qEjHi5dC4I/ZM6EM7298BXqCAojHF2NlfEnL14p+unCZElrPeQgEoTaQlzegSquXCfb78mp84R8m35fyRx04LWmUZmL4hx5G+MBCuqbNqIYKhWlTupqimTUANtc+YZnnj8+nEo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Qdssh3k1; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C91FC4CEE9;
Fri, 30 May 2025 09:17:12 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748596637;
bh=rvOVWJD5+xqMqRK/AGl01bB/hKBxArXk3yGsiYQz278=;
h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
b=Qdssh3k1UwPO6qsM3u4ZvtuEHTcMUtaTI1MVf3+Q1Tq4rduKU2AbsCU7qFM1bFIWx
FV+aBu4YPbVVB+82MWwqg5kTpmUmmZ1+XuebfeHK2lzuk9Qrqs12pkGnXu6ouOrHHg
aSaehZrAvwYIeyN0safPGRwq5cMhEcAovlrBAqx45WlUwcVJ0UY6QbuCfUVX6NUmgz
+tb8W953Z/l4XWUma45ZpFEIHvzrXkEGa/fO6Wgo+sLO7+cXPnSPD/ssY4rC2IKxvv
T2cTeBeBkwkFvSqY0RaO9vxH6PQ96u2Y3inr8iGqkzCXYmawjvZuE4OtMEIUng7iV9
tV136S6pLrzNg==
Date: Fri, 30 May 2025 11:17:09 +0200
From: Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx>
To: Peter Maydell <peter.maydell@xxxxxxxxxx>
Cc: Marc Zyngier <maz@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>,
Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>,
Catalin Marinas <catalin.marinas@xxxxxxx>,
Will Deacon <will@xxxxxxxxxx>, andre.przywara@xxxxxxx,
Arnd Bergmann <arnd@xxxxxxxx>,
Sascha Bischoff <sascha.bischoff@xxxxxxx>,
Timothy Hayes <timothy.hayes@xxxxxxx>,
"Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx>,
Mark Rutland <mark.rutland@xxxxxxx>,
Jiri Slaby <jirislaby@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
devicetree@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v4 01/26] dt-bindings: interrupt-controller: Add Arm GICv5
Message-ID: <aDl3lXiw3+l43+Cj@lpieralisi>
References: <20250513-gicv5-host-v4-0-b36e9b15a6c3@xxxxxxxxxx>
<20250513-gicv5-host-v4-1-b36e9b15a6c3@xxxxxxxxxx>
<aDhWlytLCxONZdF9@lpieralisi>
<CAFEAcA_3YLMSy+OsSsRayaRciQ1+jjh-dGzEjrh2Wa8BqdmqrA@xxxxxxxxxxxxxx>
<aDhtVkHfJvDfkfaX@lpieralisi>
<CAFEAcA-=0GWG+rnHDOnsHg8cUq1pszN=x1-W+4MYZXXD8H8Pkg@xxxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAFEAcA-=0GWG+rnHDOnsHg8cUq1pszN=x1-W+4MYZXXD8H8Pkg@xxxxxxxxxxxxxx>
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
[+Suzuki]
On Thu, May 29, 2025 at 03:30:51PM +0100, Peter Maydell wrote:
> On Thu, 29 May 2025 at 15:21, Lorenzo Pieralisi <lpieralisi@xxxxxxxxxx> wrote:
> > On Thu, May 29, 2025 at 02:17:26PM +0100, Peter Maydell wrote:
> > > The dt bindings do allow for describing Secure-world devices:
> > > Documentation/devicetree/bindings/arm/secure.txt has the
> > > details. We use this in QEMU so we can provide a DTB to
> > > guest EL3 firmware that tells it where the hardware is
> > > (and which EL3 can then pass on to an NS kernel). It would
> > > be helpful for the GICv5 binding to be defined in a way that
> > > we can do this for a GICv5 system too.
> > >
> > > > Two questions:
> > > >
> > > > - I don't have to spell out the IRS/ITS config frame (and SETLPI, by
> > > > the way) as non-secure, since that's implicit, is that correct ?
> > >
> > > Do you want the DT binding to handle the case of "CPU and GIC do not
> > > implement EL3, and the only implemented security state is Secure"
> > > without the kernel needing to do something different from "ditto ditto
> > > but the only implemented security state is Nonsecure" ?
> >
> > Not sure I follow you here sorry :)
>
> In a hypothetical system like that the dt could either
> define the (only) IRS frame in reg[], or in secure-reg[].
> The former would let the kernel not care about the fact it was
> in Secure, but would be a bit weird. But I think we can probably
> ignore this hypothetical in favour of keeping the binding simple.
>
> > > (Currently booting.html says you must be in NS, so we effectively
> > > say we don't support booting on this particular unicorn :-)
> > > But the secure.txt bindings envisage "kernel got booted in S",
> > > mostly for the benefit of aarch32.)
> > >
> > > > - How can the schema describe, if present, EL3, Secure and Realm frames ?
> > >
> > > The tempting thing to do is to have regs[] list the frames
> > > in some given order, but the spec makes them not simple
> > > supersets, allowing all of:
> > > * NS
> > > * S
> > > * NS, S, EL3
> > > * NS, Realm, EL3
> > > * NS, Realm, S, EL3
> > >
> > > secure.txt says:
> > > # The general principle of the naming scheme for Secure world bindings
> > > # is that any property that needs a different value in the Secure world
> > > # can be supported by prefixing the property name with "secure-". So for
> > > # instance "secure-foo" would override "foo".
> > >
> > > So maybe we could have
> > > reg : the NS frame(s)
> > > secure-reg : the S frame(s)
> > > realm-reg : the Realm frame(s)
> > > root-reg : the EL3 frame(s)
> > >
> > > ??
> >
> > I assume someone has to write the root/realm binding extensions.
> >
> > In Documentation/devicetree/bindings/arm/secure.txt I don't think that
> > reg is a contemplated property - I don't know if the list of properties
> > is up-to-date.
>
> It's up to date in the sense that so far we've only needed
> to have the 'status' property have a secure- variant. My
> suggestion here is that we might extend that to also allow
> secure-reg, and to have root- and realm- prefixes too.
> Though I don't think we would want to permit secure-reg for
> any old device, so maybe something more-GICv5-specific would
> work better.
I am not sure this is a GICv5 only requirement (looking at SMMUv3,
for instance and there might be more IPs that require security
state awareness).
Or maybe it is a non-existing problem IIUC the paragraph below
correctly (albeit to be frank I don't understand how to determine
whether a dtb is consumed by eg secure-world-only).
"Note that it is still valid for bindings intended for purely Secure
world consumers (like kernels that run entirely in Secure) to simply
describe the view of Secure world using the standard bindings. These
secure- bindings only need to be used where both the Secure and Normal
world views need to be described in a single device tree."
I assume "standard bindings" there would mean that "reg" for the
GICv5 would be just eg "config frame" with no NS/S/Realm/Root attached.
We don't strictly need to have the same dts file for NS and S (example),
NS will never "need" the S bindings at least for GICv5.
Thoughts ?
Thanks,
Lorenzo
Return-Path: <linux-kernel+bounces-667838-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 009F141E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:18:11 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 315284E1B71
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:18:13 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 9C170219A6B;
Fri, 30 May 2025 09:18:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b="ZWmw5mEU"
Received: from esa4.fujitsucc.c3s2.iphmx.com (esa4.fujitsucc.c3s2.iphmx.com [68.232.151.214])
(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 122201E519;
Fri, 30 May 2025 09:18:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=68.232.151.214
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596684; cv=fail; b=UCe2Kixx9iyktQgY9D7whX2kEacG0fRL74zVdJMq0n7U9RVtmQeWSTfmppufa4t3HYCTYDWTEUW/Z31xigZYHzvdgQLLmEDOGM4EGH6x488kOmX+xQ9HFakPjTMu0iFKUR1sAp5+bamZH0X/7i9KYzELd7gkoiGLZkQOmn+5NEo=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596684; c=relaxed/simple;
bh=SKvxegT+PyCyvoStONhOhNJT+7/LMJzlqPlHEv2Juio=;
h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To:
Content-Type:MIME-Version; b=hscF56mKtMRRhlBhCqIBfIDKxzK2UC4ybSTtAKxS4EeWFUIClItvP0/hnmec4Y8FtzCtua+YG+xkxCBoDwTYwmv6X6JovcFIBjXS/4eo6in08+eLqATu6UoBb/8auvKF6bh2lp6ZbAJKC2aCm8v2GKi4t7n7dzcaY8cCrMVG2pE=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com; spf=pass smtp.mailfrom=fujitsu.com; dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b=ZWmw5mEU; arc=fail smtp.client-ip=68.232.151.214
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fujitsu.com
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=fujitsu.com; i=@fujitsu.com; q=dns/txt; s=fj1;
t=1748596682; x=1780132682;
h=from:to:cc:subject:date:message-id:references:
in-reply-to:content-transfer-encoding:mime-version;
bh=SKvxegT+PyCyvoStONhOhNJT+7/LMJzlqPlHEv2Juio=;
b=ZWmw5mEULqRGVVQV3y6OgQ/gWTn1fzs8LVwKRhAYASzoOG+Dobw0KupJ
1HsghB94W31nvSs2Hnmjro8a70LwlTUqifMq8KGxyeUQLrOY9sYDaPB/D
lFkWUIiUF3azid75i/u4RPPTCHmQ9qVefJ+K+9aoDi1QKU480dTnMczCI
jYnpYYF7hip3rvTywo3bSwVWQkPXrdWhEmsuTqapr2TquwQC3Fl7aOvoT
K7/dqmlErV1jCWCN3j64pXlwXgfdkTjbE1z3VbyMHDTAqe5yOmsTaW720
AgIs4ZN99JjcljBc4DaRiGBEpfCB6jLfAbXsgFCluTMKFdyF5GHhlcbl4
A==;
X-CSE-ConnectionGUID: 6IrGqsUcQPuknZREzKicnA==
X-CSE-MsgGUID: 4cbDbAJITx+Rj592nBykeA==
X-IronPort-AV: E=McAfee;i="6700,10204,11448"; a="70040803"
X-IronPort-AV: E=Sophos;i="6.16,195,1744038000";
d="scan'208";a="70040803"
Received: from mail-japanwestazon11011011.outbound.protection.outlook.com (HELO OS0P286CU010.outbound.protection.outlook.com) ([40.107.74.11])
by ob1.fujitsucc.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 May 2025 18:16:44 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=o5IEIhzdkbp9sS8ZeyIU+Tg89Xc1KDypCrELRMs/W+GCu4WFFo0jLv2CuaCAUoFOolpWMRopo9crk4h1Bvx77JNgAjmtLkwJeKrid6+0no+MDBqRC8gWt+qiCIzdha80gmATncpfB+0jq8AMK0/eB3Kn0XkNeOAnZlBNFXU8H1XYJwrm0rrZuE9SXD80BN7ztnIRyctkOsJF7neFTl8YOEnjkOS8jH6NOZqZt3M0jIHp84eQ7dRo/wXoGNru1NHVsR6YHTqJ11GUpRmi58WBjLIO7LUQUXPqLySkUtI5WuEHr/OK3XkaKz7TMl2GXh8CctZfUwO4/jkeve4lOX2cMg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=SKvxegT+PyCyvoStONhOhNJT+7/LMJzlqPlHEv2Juio=;
b=qNEuEM0YYmxNgCU3tQlescjxqHhB7wSC7bmxi++x9UTKyydcW/hJVfWMpOxswfaB1ZGQti8qh1zfwDiv85rb8IRAwZtWcYqGG4lpHFh7bBQzGAPY/wruSwAQtiRGJRKK2DVz0HeGIXl90lMLF3sGp5E7zX0citXxzWG/DncwZCKVn1zRHNW3jio1PkKiIuiCtU+PRJ2kfx7KxkOya1xPEesQXk2Qi3q0LOKHTOPX/WNkcBX0Ng0wx3sXPveIM4y+xdlk3zRhzk7QlkQMlC/voiXS2+xKRgW7bqrg+VEuIJyPnqAY/Iit+wfCN0YbrI3V7Nhr/ydPTA2KjgQPdosGdQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=fujitsu.com; dmarc=pass action=none header.from=fujitsu.com;
dkim=pass header.d=fujitsu.com; arc=none
Received: from TYYPR01MB6715.jpnprd01.prod.outlook.com (2603:1096:400:c4::5)
by OSRPR01MB11520.jpnprd01.prod.outlook.com (2603:1096:604:232::5) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Fri, 30 May
2025 09:16:41 +0000
Received: from TYYPR01MB6715.jpnprd01.prod.outlook.com
([fe80::26fa:7a5:1339:e98a]) by TYYPR01MB6715.jpnprd01.prod.outlook.com
([fe80::26fa:7a5:1339:e98a%5]) with mapi id 15.20.8769.029; Fri, 30 May 2025
09:16:41 +0000
From: "Koichi Okuno (Fujitsu)" <fj2767dz@xxxxxxxxxxx>
To: 'Jonathan Cameron' <Jonathan.Cameron@xxxxxxxxxx>
CC: Will Deacon <will@xxxxxxxxxx>, Mark Rutland <mark.rutland@xxxxxxx>,
Jonathan Corbet <corbet@xxxxxxx>, Catalin Marinas <catalin.marinas@xxxxxxx>,
"linux-arm-kernel@xxxxxxxxxxxxxxxxxxx"
<linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>, Bjorn Andersson
<quic_bjorande@xxxxxxxxxxx>, Geert Uytterhoeven <geert+renesas@xxxxxxxxx>,
Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>, Dmitry Baryshkov
<dmitry.baryshkov@xxxxxxxxxx>, Konrad Dybcio <konradybcio@xxxxxxxxxx>, Neil
Armstrong <neil.armstrong@xxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>,
=?utf-8?B?IE7DrWNvbGFzICIiRi4gUi4gQS4gUHJhZG8iIg==?=
<nfraprado@xxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Peter
Zijlstra <peterz@xxxxxxxxxxxxx>, "linux-doc@xxxxxxxxxxxxxxx"
<linux-doc@xxxxxxxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx"
<linux-kernel@xxxxxxxxxxxxxxx>
Subject: RE: [PATCH v4 1/2] perf: Fujitsu: Add the Uncore MAC PMU driver
Thread-Topic: [PATCH v4 1/2] perf: Fujitsu: Add the Uncore MAC PMU driver
Thread-Index: AQHbZ9NsO46uwuCehEGOGiHfWDaHmrMvolwAgAWk0TCAaP36IIAAYTcAgE0NuEA=
Date: Fri, 30 May 2025 09:16:41 +0000
Message-ID:
<TYYPR01MB6715C2B9828B7921933C64B2C161A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20250116045911.3382537-1-fj5100bi@xxxxxxxxxxx>
<20250116045911.3382537-2-fj5100bi@xxxxxxxxxxx>
<20250130170422.00004c6f@xxxxxxxxxx>
<OS3PR01MB6903DC3738709A4536A62613D4F52@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
<TYYPR01MB67157AE764B00DEAC97D4EAAC1B62@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
<20250411092332.00004b73@xxxxxxxxxx>
In-Reply-To: <20250411092332.00004b73@xxxxxxxxxx>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
=?utf-8?B?TVNJUF9MYWJlbF8xZTkyZWY3My0wYWQxLTQwYzUtYWQ1NS00NmRlMzM5Njgw?=
=?utf-8?B?MmZfQWN0aW9uSWQ9NDQzODQ1MTktYTYxMS00NTk0LTlhZGYtNTc0YzI1YzA0?=
=?utf-8?B?NmMyO01TSVBfTGFiZWxfMWU5MmVmNzMtMGFkMS00MGM1LWFkNTUtNDZkZTMz?=
=?utf-8?B?OTY4MDJmX0NvbnRlbnRCaXRzPTA7TVNJUF9MYWJlbF8xZTkyZWY3My0wYWQx?=
=?utf-8?B?LTQwYzUtYWQ1NS00NmRlMzM5NjgwMmZfRW5hYmxlZD10cnVlO01TSVBfTGFi?=
=?utf-8?B?ZWxfMWU5MmVmNzMtMGFkMS00MGM1LWFkNTUtNDZkZTMzOTY4MDJmX01ldGhv?=
=?utf-8?B?ZD1Qcml2aWxlZ2VkO01TSVBfTGFiZWxfMWU5MmVmNzMtMGFkMS00MGM1LWFk?=
=?utf-8?B?NTUtNDZkZTMzOTY4MDJmX05hbWU9RlVKSVRTVS1QVUJMSUPigIs7TVNJUF9M?=
=?utf-8?B?YWJlbF8xZTkyZWY3My0wYWQxLTQwYzUtYWQ1NS00NmRlMzM5NjgwMmZfU2V0?=
=?utf-8?B?RGF0ZT0yMDI1LTA1LTMwVDA5OjA3OjM1WjtNU0lQX0xhYmVsXzFlOTJlZjcz?=
=?utf-8?B?LTBhZDEtNDBjNS1hZDU1LTQ2ZGUzMzk2ODAyZl9TaXRlSWQ9YTE5ZjEyMWQt?=
=?utf-8?Q?81e1-4858-a9d8-736e267fd4c7;?=
authentication-results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=fujitsu.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: TYYPR01MB6715:EE_|OSRPR01MB11520:EE_
x-ms-office365-filtering-correlation-id: bc7cd9b8-f5b7-44cc-9e03-08dd9f5ab0a4
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
BCL:0;ARA:13230040|376014|1800799024|7416014|366016|1580799027|38070700018;
x-microsoft-antispam-message-info:
=?utf-8?B?dURjR2k5QnR1cjBsS2VhVXhGdzB5Um1UN2hDaEZNeWwrbzdldWpFVXl5K21F?=
=?utf-8?B?eGlIVjJvbmdyVWRtdE93ZUJhYVpvMERudno3aStFY0lkVC8ybFhsSlR0aHMr?=
=?utf-8?B?bTV5M3NtZ0JYUFpZZ0R0ZW9lcnM5TUZzbW4zV1cwa3FUcUttNGNVN2MzSVdM?=
=?utf-8?B?VDVFYldVTEc4QjFtbjdqdGFBM0dLZnRLUnVFbnlNcEFjN0RTK3J1Z3dQcWdr?=
=?utf-8?B?ZnQ3bWd5eTFYemRpOVUvRi9qV0F0eHl5dFh6ZitIMk0yYm9qT2FtMmZadldu?=
=?utf-8?B?NHFIK2JheExLckZVNmxtWFY4bGRncUZLZktNdTdlUng1TmpEdFZQMlQrWHQv?=
=?utf-8?B?TVkySmxKNnZNT09CU2g1TlBYcDdVSExOR21LN3dWaFZhOHM5ekZrWDNvTXd6?=
=?utf-8?B?UUxnTGovUWovUFB5Z0l2WG1CZ0YwbnExcXNZU2Q0U3BrRTFyYmJYdWQ1T0Q0?=
=?utf-8?B?cVVFRVpFVmdKaytYV0VqR045Q3hoa0VVS2llbExqWm01WkpPdjNRMm45TXRE?=
=?utf-8?B?akNyaWFrYVU5S0cycFo1ZnZFeU9uSm9WU2ZPcHdLendUWlF5VmtBdGx6T2Jv?=
=?utf-8?B?WXdQc0RBN3BZQUhOSHBJQTF6OUVuUGdaZ25HL1ZrMG9PeEdsakpvV2lhdFB3?=
=?utf-8?B?WVl3T05WRlNpK0gwRjVlaGVhbjN2bzBhdXRBQmdMb00rNkdGenJ4K1hWMnRa?=
=?utf-8?B?Y0x1bzdSUndoR2xxMFF3SERBKytRMGJhUVNvM0FHNmdtMm1qT1Q5SG43NlJS?=
=?utf-8?B?eWtMaW90VzZrRHZCTjNxVDc5blRKdmM4dVBQcjF6b0RHVHlMMlkxTFR6Nlph?=
=?utf-8?B?V29qK0FrTGNrazJyMHNDUUFnalJEZFZHNmhsdmc0WkcvWGVlalNuK2l3N0R3?=
=?utf-8?B?NFZyTjMvcUYzVkVVK1RPeGN3amE3UG52a295eWd1bUtxRFp5RkRtZDJ1SzRv?=
=?utf-8?B?NXVnMkxrdytCNUl2U21iR3BPczNOMTJ3NGFTZHJhZkRWSEtocXVETkpBSndX?=
=?utf-8?B?UEJ4VjVIVVV4OXdqWkQrU2hOSnNiR0ZxTWthWFMyZFBnTFlhUHcyeWdmclQ1?=
=?utf-8?B?KzY3dVJxc2Vic2lsTzRVaFJjb3A0QjZObkhkR3I3d1NyaFF4aXZKWGRFUlc4?=
=?utf-8?B?QnUvL3Ywa2xEbzQrK2dZWno4SG04bVZ3YmdIV1B3bnU1dmhFeDhNM0JybWNE?=
=?utf-8?B?WHVsMTBnK3FUZHZxMXVEanN0QmRWTnR4c0xrSzQ1UytDMEN6d250VUpwdmFy?=
=?utf-8?B?NldxaHNkd0hlZUlCRkR6ZitSa20wWWdDYXFadm13ejRIcG1tcTdJSXA0Nktu?=
=?utf-8?B?T21lZ2lQeC9BZkhKdTQzZXVHWWNaaW90NlJOOHkyRmpBL2E0SjhDVURpWkdw?=
=?utf-8?B?ZU5lYWc1SWtXdENlcGh5WUJLYmVUOG5yckR0MFJNamo1dWFjR201MVVBckhU?=
=?utf-8?B?VUhNNWdER3F4RS8yQ0ozMWhYbjZ3aWI5Q3NSWG96MkN4UWpDVUJDZ0tlM3Fr?=
=?utf-8?B?MWV0N2E0Q1Z6RzNuNjVod2F4REtlMllzZlhLaldXd1FKbnJwa2kyQWlkRmRm?=
=?utf-8?B?enZDSnBSZ0xRaEV4Sm9lUGdSWko3cXJjbnA2dTdSSGMrZ1h3NEx2aDEzSmVL?=
=?utf-8?B?M2RjTTRXSlJUN29Ddmxld2xXWXdFQVA0bjZaMjhGZ1ZkbXdWemJYTy8weXV2?=
=?utf-8?B?cGd4SDRrRThEaGZrWnFvQVZuZnlxUGZoQkxQeWhJZHF1VmVZbVFkb09kUkNq?=
=?utf-8?B?aGkySVJ5eGVkcVdZOHZadVFxL1R1VVdBSFZBeENwbjZzVWZiQWJwcUVBQjdu?=
=?utf-8?B?Ulp6QVpYanRvTXNIRzJOaVdnbGVoeHZONlpmOWlpUzZvZUJpY3V4THJRMzl4?=
=?utf-8?B?aXVVbjh6bkV1VkFhTUoyYlJQblZVazJ6UWR4c3g3MFBBREVvREhmUHR1QmRr?=
=?utf-8?B?U3VGMFZlaXdZRFpVZmsvRVNCZDMyaU1qbDduaGlLdnhCa1VwNFRoQk1KMFpv?=
=?utf-8?B?V3ZDL2MxKzhibEhXS1I2U0RRV0M3ZWcvUWw4SGpIYjNkUVByUzdzMlZEUnR4?=
=?utf-8?Q?ds4v3O?=
x-forefront-antispam-report:
CIP:255.255.255.255;CTRY:;LANG:ja;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:TYYPR01MB6715.jpnprd01.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(1800799024)(7416014)(366016)(1580799027)(38070700018);DIR:OUT;SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
=?utf-8?B?QXRlYm5LRlFBdGxzdDhZWmUrZHhqMHhua24rLzV0QWVWUVQ2R2FuVzFOVFFa?=
=?utf-8?B?NTZ6eWVUL01rSkc4R2pEYlRqdUVONUhGc3BtRk5nM2lnOXllb0VyTmRScGpV?=
=?utf-8?B?ZUFGMlFoRW5XaVozN0VVQ2sreVJTKy9zOTc4eWpPQktMWUF3cEZvZk5QZnpE?=
=?utf-8?B?Y3FWSEdzRTV2eWRxWFlTOWRnTk1qKzlKVWZoZ3hpdmZaYlMrV3FzcTFwL29H?=
=?utf-8?B?OWN1WEFSWFBPTGZ2OVc3U0thTkZWWEcwankwMG82R0w2R0lNeXdMMkhzZitk?=
=?utf-8?B?Y3ZnYjk3Z0E3Z0xJRFdUQ2lzTXdSYm9Xdit0aU0xNHYyK3RUdlA0Vjh4eVVP?=
=?utf-8?B?SEZja3lFVjV5bUtXQ3IyanJMN1FhTmhSMzZKSithT3dTL29CV3pCdWZ4TkQ2?=
=?utf-8?B?Uzh0MWxUS1RoL1VPaDJzWmw1dGRCSnl4bFVpN3pxSEpuL2lpUU5HWG0vUGc3?=
=?utf-8?B?em9JZjlLeGs1dlhDaDIzbjN2MkJ0Q2JrK3k4K2ZJaHRmbUhxY2NuWEY3aEJI?=
=?utf-8?B?MzhaWlVpb1JMcjdpRWNXUUU2Rlo1dThRTnNJUDBXelliYzRZVWh0dTZUZDU3?=
=?utf-8?B?SU91cUlJNWtHNzIyWWNoZEJsU0luZWVjbkFXbDNjdVdObUFGWXRFZnljMkRm?=
=?utf-8?B?aXFwcE9NT2p2cFFzdmpmSmJKWExISERkQWk2aWxuME5aYUQ0S0FoQjgzbHY4?=
=?utf-8?B?aUxhdEJlWThoYVpzMHF1VDF2SU1jK29kamduQmlJaWpueHM2RHBIZ3JjcU5T?=
=?utf-8?B?SjZwUkNESi8vdHZjTGZPb04xa0l4NFEvcXZlNFhxRTNweTRRL1BqZ1VMbW5W?=
=?utf-8?B?aHlxYjBEUHVFN3VxOWJrZWsyUWVmemdkMGIxeGRGcDNraHdISk5iZnc2SXIw?=
=?utf-8?B?U2FDZGhTbEU2YUpydzRobC92QUdnNnJKd2tOdGIrWVM1ZEF0R3BhRmhFVzQ1?=
=?utf-8?B?WFFLcWIwODVFUklXcDJ4ZXRrb25GS3RBQ2luejl0SnNDbmw0dnVzTWVVUkN5?=
=?utf-8?B?RDFrRGViZnQwYmVLZ2MydUhwWEFZSWhCRHJJQ3JyVFp4R0NXcEFsWmhSQWtw?=
=?utf-8?B?VXN2aHQwNENBRnc2SWpyNnIvOURMbW92Z3hucmxmZFFsTlNCVFFnSXVLYmc5?=
=?utf-8?B?RGZ1Q1g3UHhBS201MXZpdjNhdkEyRlIyaE1kTmhHYTZpVysxSWZ0WUdjU2Iz?=
=?utf-8?B?SGNNZzFyT1N2YzJ1RnRSUUtUN3BHZTd2NHYrUHdWWkYwa2lRRzBialgxcGc2?=
=?utf-8?B?WUg2K0VvNDNNbVg5cVg2V1hiZFh4dkNobjh5NFcxRTY3OXhGcmxnL1dlaUFR?=
=?utf-8?B?MHpZTkwwdzlXY1p6NGlaMGdKd05jYnU0MVZnYzM5dXBTWGIvcmJ1QjB0bUZ3?=
=?utf-8?B?UkJoaVR0SXh5RzRyQ0xZbnpOdWVQUkRyZmFnU0NXZ1p5bGFNVW9mZ2dOYVVO?=
=?utf-8?B?Q00vVDM2RytPcERpQ1dFdTJCUGRtZmZ6RTYxWjRrVjh1T3ZIQVN0THVMbmtP?=
=?utf-8?B?aFQzQkU1YXRzQ2pWT0tzanVrMFNON243NnJCZEhyckUwK1N1Nk1VWGNFU2p1?=
=?utf-8?B?TXArL24zWTA5dnowSjBzS3pFL3NDSjJERlAveTF4WFQ4cW5jVG1DMlhkSUs3?=
=?utf-8?B?MUpISFpwYy9YQXFpRlMrUlVOeXF2dTBYa0hEcDJGUmZabkZySjdRSTRUQzhq?=
=?utf-8?B?cUVCTVFHT0tkVW1xUm4wcVBqRFc5TllKSWYwdk1RMVlmaDVMcitmN0ptMDBv?=
=?utf-8?B?RVVaQThnOEdiK0pQbFJuUzlaeXZpMUVFMGFkaUU1SEM5b0toMklTemNFQnFT?=
=?utf-8?B?Rk5RQmJXMDFoUHM2TXkrUzB2ZHRNeUFocTNLOWM3a241QnhkNEtLMFF3eUt6?=
=?utf-8?B?WjdhcjVVN0luTEpmUnF6clZwbS9BNVBURyt5c2NLclFMdmgwVHFxR3kvZHYx?=
=?utf-8?B?ZnFvenVYWHNBY3kxRXlFR1REZzBJMDZ2YlJrcDJzZEZGVG9SeWpLZmc5VEov?=
=?utf-8?B?UmJ6Tml6VFp0MUZlMXJTNWM3VW5pNzBlZDNzcWNleW5seHNaaXNhOWp2SkJR?=
=?utf-8?B?TDYwTFUxY2s4RnBLN1U3bi9hNXo0VkUzWk5LNlBlRTdwVjFxenFZQ1ZLMlZJ?=
=?utf-8?B?SzF1UHhMSTZUb3JkaVJhb1JXaUlkN3grdk9zUnJ0amxRbDZDdUxHY01pWGxm?=
=?utf-8?B?dUE9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
I545gwo3tTW7o3BCkJP48ThX6q92kSuPwUQ62DM+3Udnz4T7i0pDwaDMw4OIQ+XRvx3DYMT7SR9NGRnB2B2aKAYIQEv6wpjjK0cS7e6k60Z5tHQSM2IOezPkdlAg87yL9h6v5deY06CspjRSQHbIW30DE1R9j9zvmYnUdDLEDTzf7UdtyCh9reulYdKpCNTzuBQWsXukayknGy0qDHLRrLEK1dehjt6RgkLv7JTJ4kB0D1Yizbbg3MetbVYbrEIgpWmNoxmYlqUlTGbxJ5wxXu+yLhGreQFU7YyICo4IdsyvCKlh8qDPgmqpCcO0BFo0M1yvxKDOSWDabZ4irmXwDr3onRHxe5xisheTw5IXXCYxVva16GjmnrMEXKE6ShQeg0LAFpZpochtB9dwiDJwTr7pk/oXjXkuPuaoVe2UpTQj6Go82xign+akc/jYvKF79IvoVbMJaiRpRLROGVTZAPK3xNLXg6G6o26xuzIRXC9Dl7tXG1e7VHYAyXhQfK3EsIgoijEYRUeH72qhsc1W+i04FZhjDAzIiTaxI7tl9J/OeEzdzwM085cTOF544DBpvZS15M1w4RPpYbs842BnsZHceyYFSo2xUGfzFIz4j49WSD4GBu3rWnWlm6gE9dIh
X-OriginatorOrg: fujitsu.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TYYPR01MB6715.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bc7cd9b8-f5b7-44cc-9e03-08dd9f5ab0a4
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 May 2025 09:16:41.5741
(UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a19f121d-81e1-4858-a9d8-736e267fd4c7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: qw7acpajw+P4WunBKdYgw/CqNjGG0XR+X3K1PyZIRcVFjEFnnvO2pUcmwWmrDMlA7/ikC8exLmnK8rXixmtbLNDQ44mriKnN8bGbFW+dH6Y=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSRPR01MB11520
X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
SGksIEpvbmF0aGFuDQoNClNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4NCg0KPiA+IEhpLCBKb25h
dGhhbg0KPiA+IA0KPiA+IFNvcnJ5IGZvciB0aGUgbGF0ZSByZXBseS4NCj4gPiBBbHNvLCB0aGUg
cGVyc29uIGluIGNoYXJnZSBoZXJlIGhhcyBjaGFuZ2VkIGZyb20gRnVydWRlcmEgdG8gT2t1bm8u
DQo+ID4gDQo+IEhpLA0KPiANCj4gDQo+ID4gPiA+IFRleHQgaWRlbnRpY2FsIHRvIG1lbW9yeS1w
d3JpdGUtY291bnQNCj4gPiA+ID4gd2hpY2ggc3VnZ2VzdCB0d28gdGhpbmdzLg0KPiA+ID4gPiBh
KSBuYW1pbmcgaW5jb25zaXN0ZW50LiAgV2h5IGlzIG1hYyBtZW50aW9uZWQgaGVyZSBhbmQgbm90
IGluIHRoZSBuYW1lICANCj4gPiA+IGVhcmxpZXIuICANCj4gPiA+ID4gYikgVGhpcyBjb21tZW50
IGlzIHBlcmhhcHMgd3JvbmcgYXMgSSBhc3N1bWUgaGFzIHNvbWV0aGluZyBtb3JlIHRvZCBvd3Rp
aCAgDQo+ID4gPiB3aXRoICANCj4gPiA+ID4gICAgZW5lcmd5IGVzdGltYXRpb24/ICANCj4gPiA+
IA0KPiA+ID4gV2UgYXJlIGN1cnJlbnRseSBjaGVja2luZyBhbmQgd2lsbCByZXBseSBsYXRlci4g
IA0KPiA+IA0KPiA+IEFmdGVyIGNoZWNraW5nIHdpdGggdGhlIGhhcmR3YXJlIHRlYW0sDQo+ID4g
dGhlICdlYScgZXZlbnRzIGFyZSBtZWFzdXJlZCBhdCBkaWZmZXJlbnQgcG9pbnRzIGFuZCBtYXkg
dGhlcmVmb3JlIA0KPiA+IHJldHVybiBkaWZmZXJlbnQgdmFsdWVzLg0KPiA+IFNpbmNlIG1lbW9y
eS1wd3JpdGUtY291bnQgYW5kIGVhLW1lbW9yeS1tYWMtcHdyaXRlIGN1cnJlbnRseSByZXR1cm4g
DQo+ID4gdGhlIHNhbWUgdmFsdWUsIHRoZXkgc2hhcmUgdGhlIHNhbWUgZGVzY3JpcHRpb24uDQo+
ID4gSG93ZXZlciwgd2UgaGF2ZSBkZWZpbmVkIGRpc3RpbmN0IGV2ZW50IG5hbWVzIHRvIGFjY29t
bW9kYXRlIHBvdGVudGlhbCANCj4gPiBmdXR1cmUgZW5oYW5jZW1lbnRzLg0KPiANCj4gQXMgYW55
IGZ1dHVyZSBlbmhhbmNlbWVudCB0byBtYWtlIHRoZXNlIGRpZmZlcmVudCB3aWxsIGFsc28gbmVl
ZCBhIGNoYW5nZQ0KPiB0byB0aGUgZG9jdW1lbnRhdGlvbiB0byByZWZsZWN0IHRoYXQgZGlmZmVy
ZW5jZSAoYW5kIGhlbmNlIGEga2VybmVsIHBhdGNoKQ0KPiBtYXliZSBpdCBpcyBiZXR0ZXIgdG8g
bm90IHByb3ZpZGUgdGhlIHNlY29uZCBldmVudCBmb3Igbm93Pw0KPiANCj4gT3IgaXMgdGhlcmUg
c29tZSBvdGhlciBzdWJ0bGUgZWZmZWN0IHRvIGRvIHdpdGggZ3JvdXBzIHRoYXQgY2FuIGJlIGVu
YWJsZWQNCj4gYXQgdGhlIHNhbWUgdGltZT8gSSd2ZSBmb3Jnb3R0ZW4gaG93IHRoZSBkcml2ZXIg
d29ya3MhDQo+IA0KPiBKb25hdGhhbg0KDQpBZnRlciBkaXNjdXNzaW5nIHdpdGggdGhlIGhhcmR3
YXJlIHRlYW0sDQpkZWxldGUgRUEgZXZlbnRzIHRoYXQgc2hhcmUgdGhlIHNhbWUgZGVzY3JpcHRp
b24gYXMgYSBNQUMgZXZlbnQuDQpDaGFuZ2UgTUFDIGV2ZW50cyB3aXRoIHRoZSBzYW1lIGRlc2Ny
aXB0aW9uIHRvIGEgZGlmZmVyZW50IGRlc2NyaXB0aW9uLg0KSWYgdGhlcmUgYXJlIG5vIGlzc3Vl
cywgV2UgcGxhbiB0byBzdWJtaXQgdGhlIHY1IHBhdGNoIHNlcmllcyB3aXRoIHRoaXMgZml4Lg0K
DQpCZXN0IFJlZ2FyZHMsDQpLb2ljaGkgT2t1bm8NCg==
Return-Path: <linux-kernel+bounces-667839-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id C509241E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:18:29 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 105864E1C13
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:18:31 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 51136219311;
Fri, 30 May 2025 09:18:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="JO9V1K8/"
Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175])
(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 DF53D218593
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:18:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.175
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596701; cv=none; b=CgBw3o6VlrTL8nG/y0hgFxn5bfi3XkL2ZM2oJ/W7qc1Z3G/938w7vVg3IJpo9ln9o6Nz3lxEKxQJgD75xfoQ0SbZsSlqiRfqN+VzuEIvnZtklqZWjz19EYWB/x7UJgEL6j/FZK01t07Mj3iWVkOJcfH+W/qseAbhwzkCxZNgapw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596701; c=relaxed/simple;
bh=ebOJBYeeHCkyALDjIWQdDTTwURnubvG/RMOC2ONZm84=;
h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
To:Cc:Content-Type; b=eDJ0kSFzLSEciIm4jDaWE/MGgtnnMmCEBBTzl8PWdb4bIaOxWTagREF4LrWjK/giIUahfRzcXQ2NSk7hozn4LSJZrajNOmBOhNIndxHGaiWybs1jJ6sRdo9ypP/fRZO5R4QUpczb3g3SsP6a4PqqQ09G9w5knx+7gP23P5XyY1w=
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=JO9V1K8/; arc=none smtp.client-ip=209.85.219.175
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-yb1-f175.google.com with SMTP id 3f1490d57ef6-e740a09eb00so1574112276.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1748596699; x=1749201499; darn=vger.kernel.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=9LSJUMPXEV1M8KFzX9qlsWTgwSLRhfElyDaP/rhgR2Q=;
b=JO9V1K8/JqVH6STc3aC5hUeFMsyAGvVmnOc6iVsh+JcQAzddXP4NWCcPSxZbqcE9H+
pbtJNqQ/kFu6zyfjQ0Ju8XwmisQPpwGLUi90u6fT1PFy40xo0RK63H/92/TLV7WnV7we
O0hXGEjC9UEK3YZXz8n8yTmLdej1Oab3M2cdXFFldlKpChgPb5moAEtjTLkzdxKYbSIj
BMxFTGg8lngG82+wA7OA9i9AuU3eK1oL4Jl3V2sQGreDu0w0W9NqBxKPZXAxmQ/qBCNL
Aq94l5qiD0ncP+b5o3GRjI4V9IJra6qm48SWpqIZKoRCBsLE4UapoLHxkiO2A+VZaqna
CMSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748596699; x=1749201499;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=9LSJUMPXEV1M8KFzX9qlsWTgwSLRhfElyDaP/rhgR2Q=;
b=VOh+x0yNVQi87FmAFJq6XcQGZckHo+BhLoNPjfaY796FZ4Vrxq3YxIQzrv9lRcKA1T
cLJCPlln5KKXhFRfkhFCnJCQdIKux8UTrzwsnFb8LSH0ifQ7h3G0Jothqw+E3LoWJWq2
BgyS+LhYBEnP0q/nbQf6ft3Sbh3zlVkQEoHIXIKECAm52Vu9aUk+oVtLhfRK3ltBfobN
ohkuPyvgHHabDCIL9mlObQbim/gKxnlll/JU6qG80GyfPkxjfkMnnQjKR/k1FSttG0b2
e1ysMdEOKBhcE/D2WjvSW3YWRAvJHezVnlX6XngcOKeeMta7jBoWid2EsOqLCm2TnV/x
duGg==
X-Forwarded-Encrypted: i=1; AJvYcCU33L0VGlZl6nsdjryCU358G2E/xA/pajq5gKfzbfl3sxXDatjvl1onQJ2u013sjv5lD4ZyMGo5PP3LeII=@vger.kernel.org
X-Gm-Message-State: AOJu0YzH5tRXeCJBbS7iBsIx78/aSYXsWUPGQY8CCVZMGGKeUdF+oyrL
+ZHvzBHqyHG4p1jRRYazNsF5gExB7ZMIDOm3SK4A/vD5AVDJ+QdNGFFvRejSg+ZZ00Zq0yCLweR
Q6h3VItfbZkn61+EB6XiU+SWhARYRmj2HucnJ7/1+DxrIXaysFv/ccaBTSQ==
X-Gm-Gg: ASbGncsUKYLz9IBdlzXR4AE11mg3RDZFxDqtv+08U5QlYeAe4TL1MJLGrULkREE7i1v
3N1lFrGuJTUeF2XebJzuwmHH7mG9BWPf2bb/DwZhK6B//ndEcJsfo2VR0b9ttOj4kn+Q+jTAV2g
sg/hZI88DM1EWPuXcv4qvmeF6YaRL4uXK5yA==
X-Google-Smtp-Source: AGHT+IFfycBwEI3FxueTISbpHh6OJPQeP2Lrq+8rdRXtzuwP9IhvuccKAVwiT0W7cxN5YrLOeQ38HlPh8PvZt5WQSe4=
X-Received: by 2002:a05:6902:1003:b0:e7d:9bfb:a320 with SMTP id
3f1490d57ef6-e7f81f064a1mr3911070276.36.1748596698927; Fri, 30 May 2025
02:18:18 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
References: <20250526122054.65532-1-claudiu.beznea.uj@xxxxxxxxxxxxxx>
<20250526122054.65532-2-claudiu.beznea.uj@xxxxxxxxxxxxxx> <hojdkntm3q5a5ywya7n5i4zy24auko4u6zdqm25infhd44nyfx@x2evb6sc2d45>
<111d2d6c-8ac0-40b9-94c3-02f2f64ef9fe@xxxxxxxxx> <CAPDyKFoQYTNBhtBXY-Ds7E0TohtA6558W1Jf3cLsnXDQC74DSg@xxxxxxxxxxxxxx>
<rmc7me6rvumr6pcekgp5lsrxtuge5houitn474lkljew2hzdcw@z7wh2vtntvs5>
In-Reply-To: <rmc7me6rvumr6pcekgp5lsrxtuge5houitn474lkljew2hzdcw@z7wh2vtntvs5>
From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:17:42 +0200
X-Gm-Features: AX0GCFvzfTrcuWANsmOBcb2p2VazFw-uQgVJQLGJOuhNKKaI5gJPiizsYJAEId8
Message-ID: <CAPDyKFpsk-o0KvaJK+dgNDvW30piHKgvtyOxF7URaUEvrPZmZA@xxxxxxxxxxxxxx>
Subject: Re: [PATCH v2 1/2] PM: domains: Add devres variant for dev_pm_domain_attach()
To: Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
Cc: Claudiu Beznea <claudiu.beznea@xxxxxxxxx>, gregkh@xxxxxxxxxxxxxxxxxxx, rafael@xxxxxxxxxx,
dakr@xxxxxxxxxx, len.brown@xxxxxxxxx, pavel@xxxxxxxxxx, jic23@xxxxxxxxxx,
daniel.lezcano@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
linux-pm@xxxxxxxxxxxxxxx, linux-iio@xxxxxxxxxxxxxxx,
linux-renesas-soc@xxxxxxxxxxxxxxx, bhelgaas@xxxxxxxxxx, geert@xxxxxxxxxxxxxx,
Claudiu Beznea <claudiu.beznea.uj@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Wed, 28 May 2025 at 18:09, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote:
>
> On Wed, May 28, 2025 at 06:04:45PM +0200, Ulf Hansson wrote:
> > [...]
> >
> > > >> +/**
> > > >> + * devm_pm_domain_attach - devres-enabled version of dev_pm_domain_attach()
> > > >> + * @dev: Device to attach.
> > > >> + * @attach_power_on: Use to indicate whether we should power on the device
> > > >> + * when attaching (true indicates the device is powered on
> > > >> + * when attaching).
> > > >> + * @detach_power_off: Used to indicate whether we should power off the device
> > > >> + * when detaching (true indicates the device is powered off
> > > >> + * when detaching).
> > > >> + *
> > > >> + * NOTE: this will also handle calling dev_pm_domain_detach() for
> > > >> + * you during remove phase.
> > > >> + *
> > > >> + * Returns 0 on successfully attached PM domain, or a negative error code in
> > > >> + * case of a failure.
> > > >> + */
> > > >> +int devm_pm_domain_attach(struct device *dev, bool attach_power_on,
> > > >> + bool detach_power_off)
> > > >
> > > > Do we have examples where we power on a device and leave it powered on
> > > > (or do not power on device on attach but power off it on detach)? I
> > >
> > > I haven't found one yet.
> > >
> > > > believe devm release should strictly mirror the acquisition, so separate
> > > > flag is not needed.
> > >
> > > I was in the middle whether I should do it with 2 flags or only to revert
> > > the acquisition.
> > >
> > > >
> > > >
> > > >> +{
> > > >> + int ret;
> > > >> +
> > > >> + ret = dev_pm_domain_attach(dev, attach_power_on);
> > > >> + if (ret)
> > > >> + return ret;
> > > >> +
> > > >> + if (detach_power_off)
> > > >> + return devm_add_action_or_reset(dev, devm_pm_domain_detach_off,
> > > >> + dev);
> > > >> +
> > > >> + return devm_add_action_or_reset(dev, devm_pm_domain_detach_on, dev);
> > > >
> > > > Instead of 2 separate cleanup methods maybe define dedicated devres:
> > > >
> > > > struct dev_pm_domain_devres {
> > > > struct device *dev;
> > > > bool power_off;
> > > > }
> > > >
> > > > ?
> > >
> > > That was the other option I've thought about but I found the one with 2
> > > cleanup methods to be simpler. What would you prefer here?
> > >
> > > Ulf: could you please let me know what would you prefer here?
> >
> > As it looks like we agreed to use one cleanup method, the struct
> > dev_pm_domain_devres seems superfluous to me.
>
> I think we agreed that cleanup should mirror the acquisition, that is
> true. But since attaching to the domain has an option to either turn the
> device on or not we still need 2 cleanup branches. They can either be
> implemented with 2 cleanup callbacks or with 1 callback and dedicated
> devres structure.
Yes, you are right. Better with one callback and using struct
dev_pm_domain_devres to manage the power_off parameter.
Kind regards
Uffe
Return-Path: <linux-kernel+bounces-667840-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 817A641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:18:54 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 4C1F6A27904
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:18:33 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 6431E21E082;
Fri, 30 May 2025 09:18:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tXzmpuwl"
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 A186C1C84A5;
Fri, 30 May 2025 09:18:46 +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=1748596726; cv=none; b=O3NNxk42VzIo2yyl3RarDBngDwqpkqYByJQlPYpG9X2tVBueF9qRuJduMn5NWF6qltATO8t87SX4nopF32yFEVpV9pL3E9V4wgEh3IAdZYH2/i5WBaMfcU9sJSWoNw5uWYCu9ByZ5XiX2zpmvCbn90Yt4vkxBT7HuBjJ1JWAbPk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596726; c=relaxed/simple;
bh=snZT/youdWPPK0aV1SigXN/Mc/jC4HfNSXK++zWhvss=;
h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
To:Cc:Content-Type; b=gKeDm0zQmYfD6EaQAexvnaYYStWgK1gZV5GwM31GN3/Gdua+ABF+fE9tScx01eOSxC+/IyKi1cg/gJHbhUf3xyUbHsZVChqnW9pxP0GRaAh2aobHr5lR7Z5HVg7iPFXiKrDWUnScwsGNKxfQxglWU2v8fz2l5d/0HQ36EIWtcZ0=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tXzmpuwl; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A6B5C4CEEB;
Fri, 30 May 2025 09:18:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748596726;
bh=snZT/youdWPPK0aV1SigXN/Mc/jC4HfNSXK++zWhvss=;
h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
b=tXzmpuwlAj4kyuAaxPpp0aQotfpsdbwAdWOEHEC6GjOUTrY+j2IcrIlzIAqGnPFMc
dxxWCbcYB3qiCOYfnqO5WIDSIcCHlqrIrHqVhsHcJ/rVaHgPl8sKkk6oYc1HlMcnzQ
yrx+ru6X7irCqwtmjvCuISWjx5MpVyvwNr41zjrv/w4nbr40jzQroGlplT3GKulzM6
RqvGk9t5t08RYrE/SaHczpkSPvwSsI6cWIqGtLKdN3ZBlPB6GtCmXuVrtIObKZzkhI
0kG7P7bPfOzkYRRXuw2FALPk0NgOOUS7hyOr4fsNbc1/jJyQKtHPr4zo7zfnNRsZa8
uFzd/7vio6rNA==
Received: by mail-oi1-f173.google.com with SMTP id 5614622812f47-3f8ae3ed8f4so1200176b6e.3;
Fri, 30 May 2025 02:18:46 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCWUybTpO8nkzLtNn9wp7CrsGnq9QeWL3J8toMAHjAUo4Nfkn+d9K8XtoJilZiGgp2uIZTsqUZZ8+ms=@vger.kernel.org, AJvYcCXocrxJgzf+oFso6uoYlkKGVZN7vZViMcsz8kfjnDslpTZzpSkrZVdjE4SIbWEAgBUbjvCz9P1YLBUkx+8=@vger.kernel.org
X-Gm-Message-State: AOJu0YydZBKxNxr5EvQcsNcbjDOeq758Gzi+DaI9iyMZOPXKlbqhq6pX
P1/Lj4m4G0QrjA+G11NX4QyDH6esJ4r1ZUaCTepDXv4iiw3uTOgc9NeJ7vfIFLy+kYvGC74vlQc
Ad32hcd3H/9gUVH6AWiJbeaQmneBLREg=
X-Google-Smtp-Source: AGHT+IHWMb0z4NVl/L+z/yrd/3T3xNhtSlR9ihUabCouVR/sVGUPbbITLPj8K1gVNQTEBwvti2Sjt8Pxu8dyoX06/Mg=
X-Received: by 2002:a05:6808:6b8c:b0:406:67b7:8b62 with SMTP id
5614622812f47-40679778baemr1498658b6e.38.1748596725403; Fri, 30 May 2025
02:18:45 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
References: <2006806.PYKUYFuaPT@xxxxxxxxxxxxx> <20250528131759.GA39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
<CAJZ5v0i=TWMjPKxGa8eT-prV=dtQo=pwys5amcj3QL9qo=EYyQ@xxxxxxxxxxxxxx>
<20250528133807.GC39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAJZ5v0g2+OVdFM-bUCOynNivUc4doxH=ukt9e9Z_nKpoZh6gPA@xxxxxxxxxxxxxx>
<20250528160523.GE39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAJZ5v0jzF19rToJMHhEvU6Zbt3690KWCs-B_0sPR=s9xeRiUnQ@xxxxxxxxxxxxxx>
<20250529085358.GY24938@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAJZ5v0hw1910Gsb57POVhax1hAbEGHa7xksr_FygNd_JL-oeOA@xxxxxxxxxxxxxx>
<20250530080733.GH39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <20250530080733.GH39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:18:33 +0200
X-Gmail-Original-Message-ID: <CAJZ5v0irHEZEbZVrd-tiaXBvxM4aD9spJg1cVRcjrDQ0_HMJAg@xxxxxxxxxxxxxx>
X-Gm-Features: AX0GCFu4bzN34rlFj1VMl2CDYb9hS8t8QF38ItYyh53nEJvlVwnKodQyub2LTqU
Message-ID: <CAJZ5v0irHEZEbZVrd-tiaXBvxM4aD9spJg1cVRcjrDQ0_HMJAg@xxxxxxxxxxxxxx>
Subject: Re: [PATCH v1 0/2] x86/smp: Fix power regression introduced by commit 96040f7273e2
To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>, "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>,
x86 Maintainers <x86@xxxxxxxxxx>, LKML <linux-kernel@xxxxxxxxxxxxxxx>,
Linux PM <linux-pm@xxxxxxxxxxxxxxx>, Len Brown <lenb@xxxxxxxxxx>,
Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxx>,
Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>,
Artem Bityutskiy <artem.bityutskiy@xxxxxxxxxxxxxxx>,
"Gautham R. Shenoy" <gautham.shenoy@xxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>,
Todd Brandt <todd.e.brandt@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 10:07=E2=80=AFAM Peter Zijlstra <peterz@infradead.o=
rg> wrote:
>
> On Thu, May 29, 2025 at 11:38:05AM +0200, Rafael J. Wysocki wrote:
>
> > First off, I'm not sure if all of the requisite things are ready then
> > (sysfs etc.).
>
> Pretty much everything is already running at early_initcall(). Sysfs
> certainly is.
>
> > We may end up doing this eventually, but it may not be straightforward.
> >
> > More importantly, this is not a change for 6.15.y (y > 0).
>
> Seriously, have you even tried?
>
> AFAICT the below is all that is needed. That boots just fine on the one
> randon system I tried, and seems to still work.
>
> And this is plenty small enough to go into 6.15.y
But there is still intel_idle_init() which is device_initcall() ATM
and this needs to be tested on other arches too.
So not really there, sorry.
> diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> index 0835da449db8..0f25de8081af 100644
> --- a/drivers/cpuidle/cpuidle.c
> +++ b/drivers/cpuidle/cpuidle.c
> @@ -814,4 +814,4 @@ static int __init cpuidle_init(void)
>
> module_param(off, int, 0444);
> module_param_string(governor, param_governor, CPUIDLE_NAME_LEN, 0444);
> -core_initcall(cpuidle_init);
> +early_initcall(cpuidle_init);
Return-Path: <linux-kernel+bounces-667841-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 108D641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:20:23 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 109433AF857
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:20:02 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 4893221E08B;
Fri, 30 May 2025 09:20:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=nxp.com header.i=@nxp.com header.b="KP5Q1in7"
Received: from AS8PR04CU009.outbound.protection.outlook.com (mail-westeuropeazon11011002.outbound.protection.outlook.com [52.101.70.2])
(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 39A4E219A6B;
Fri, 30 May 2025 09:20:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=52.101.70.2
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596814; cv=fail; b=ryaHsp5nzpHYuRFWr9B9h2YHsaqlgSEtueHbQ3h1FE9m9w/RyoIPoy5z2jlvxRukNyiRupBWs46X88s7IHYrwQ35st/1G0HQDqVA296zFOqg5DVEpowfMIhnguKbknhijjgIKH2nRAKTeSRM+jjrN2HAxpTr1PxOqVEz6QYiUhE=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596814; c=relaxed/simple;
bh=2BUQqEeHTc36ku7ScZJaPPfb6pPGN4NOv5cHhpYt/Po=;
h=From:To:Cc:Subject:Date:Message-Id:Content-Type:MIME-Version; b=kd7ZwByAmZbWoTGwX8l83HxOPjkCBJsirU13Pl7SKiieBYjL2sm4v9RFb4KN6cQWZjMvrJQaVQCxuvFUL3x11HTDmMnsCyTSnFo98FUeZUizA+qteCtgZysKHdqI8ScXoQaHlFH5moLZTtqUe4zAT+AE4yAL/aWSOqKHnHtnm5g=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nxp.com; spf=pass smtp.mailfrom=nxp.com; dkim=pass (2048-bit key) header.d=nxp.com header.i=@nxp.com header.b=KP5Q1in7; arc=fail smtp.client-ip=52.101.70.2
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=nxp.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=nxp.com
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=lRqXibkl+4AKmYLtcwhskNlLBkjeLCfy3SjxuIgZKltI+ibCgH+XIRrc3UszGO31yM7MoYgM9k6hxGGP/MBNA3yysReEptCiLFiRsy7d1SKMDfFavdvA2sTI7gQrYaUeAMxCmJmA6FCBJorrpsB3d4ifsXu2BtOhpwMEL92Z4OfOzYq6q4ubKOaK7YzFzw+N6r28kIWtsYoJ/X0jyKmTQrmgSh9ivBnT9Mbp3f47M7ap3Dh7HKt14b0hJw6GQafAtAXXdFkPBxKxbLxB8iVNRhNw+anUhS9ntGtMd0onGq/gKPQYw+a/yvpGzbH9o9QQE/M9hCsKnCWKYw3yNjSnAw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=Lj0+gJLtntZkGJpgnIa8t9cEIDVZj1mAGmDvJLn5+xA=;
b=c0g+nSzTqSojd5Eyrux9bvLxxKEuIYSyvsjOyzm/CrcOByynUB7qqqmzxvBJJt0YliirV44NrY1qYRCGv7iAjoUBKmy9cQJDf7tGbZa9N/53hUzjRM+0kBWXx9rpIMNiXwgnTpesMU6I0wesi5p2cdVPkfB/YlV3TShqKT8iWdc6C3xV88YuNZLWYLWndI1MJH8YbvNnO7zZF5PBkstbtsPINBT6i8iNylU94RaF5H9PvX3B9f67hvPgE5BZIMgRE446NQCLOO0TrTEX+7+YqZPQBHbrTq3u6l5qo34hygd1rcn1lCWpWO6GQGE1BCJTgHfoLrC1ZhaNklIiMrjMnw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=nxp.com; dmarc=pass action=none header.from=nxp.com; dkim=pass
header.d=nxp.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nxp.com; s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=Lj0+gJLtntZkGJpgnIa8t9cEIDVZj1mAGmDvJLn5+xA=;
b=KP5Q1in7JTkKcUYRg/5vR1Nr1ZESkt/nsYq6LZmOdscbS2vPfOBJyQeFqZm86Th3/nIzl9MQwrr5B+r8GMu599YK7W31cILfgBKbv0U/+R6l+R505hCpRKnKUk8A0dyM7ZWt5cuo4IkyA4v4oHEvRGUMQU9YJkAVTs31s/UAs9dqvZ1YzLwQigKgrem3O1SgpkvF7dZjTNk/hzZbSMf905P47eqA0VJ4onCGuE49lUd+zchhbUflVOT5SQkvM1L9zCBFw+6H+q+KL/UziH2pONvzypRz0eOJE6u+rPkCag6pyKh+76hGuOfQbSnKnIO9/SiyKCX62shVMY2e3sXDQg==
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=nxp.com;
Received: from PAXPR04MB8510.eurprd04.prod.outlook.com (2603:10a6:102:211::7)
by AM0PR04MB7025.eurprd04.prod.outlook.com (2603:10a6:208:19c::19) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.32; Fri, 30 May
2025 09:20:07 +0000
Received: from PAXPR04MB8510.eurprd04.prod.outlook.com
([fe80::a7c2:e2fa:8e04:40db]) by PAXPR04MB8510.eurprd04.prod.outlook.com
([fe80::a7c2:e2fa:8e04:40db%5]) with mapi id 15.20.8769.031; Fri, 30 May 2025
09:20:07 +0000
From: Wei Fang <wei.fang@xxxxxxx>
To: claudiu.manoil@xxxxxxx,
vladimir.oltean@xxxxxxx,
xiaoning.wang@xxxxxxx,
andrew+netdev@xxxxxxx,
davem@xxxxxxxxxxxxx,
edumazet@xxxxxxxxxx,
kuba@xxxxxxxxxx,
pabeni@xxxxxxxxxx
Cc: netdev@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
imx@xxxxxxxxxxxxxxx
Subject: [PATCH net] net: enetc: fix wrong TPID registers and remove dead branch
Date: Fri, 30 May 2025 17:00:12 +0800
Message-Id: <20250530090012.3989060-1-wei.fang@xxxxxxx>
X-Mailer: git-send-email 2.34.1
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
X-ClientProxiedBy: SG2PR02CA0035.apcprd02.prod.outlook.com
(2603:1096:3:18::23) To PAXPR04MB8510.eurprd04.prod.outlook.com
(2603:10a6:102:211::7)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PAXPR04MB8510:EE_|AM0PR04MB7025:EE_
X-MS-Office365-Filtering-Correlation-Id: 1ae6de35-7969-430f-2351-08dd9f5b2b74
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam:
BCL:0;ARA:13230040|366016|52116014|376014|1800799024|38350700014;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?EqlojVJ8ulOXi9TxjxwmDjFqAB09Mj71RSUKN/7kkIMzrOz5Fg6XczySsLbz?=
=?us-ascii?Q?ztWej0/eGLzGN0ULsBxOXAHJF0yu9uD05ExckA2DaueR9ePd7rMGEUmK8OZt?=
=?us-ascii?Q?SeyMzGtmR2Q3xgpgbAZdcqahFU5oZ117rAWFf82hvQ3+x4fKW58RkJky5JYv?=
=?us-ascii?Q?JcjfLqMpEJUX0SDaREELndCSTYJtCaDOoH3cp4z1SnALRARqLoJrFhRz3o63?=
=?us-ascii?Q?p8EvY+H751oiNbMYxTsd0wC2HFnBBGGrtbBthtXoxao6TY6BbZPRvNDzTDkr?=
=?us-ascii?Q?3N1mQB/MQWTd0L72sSnUH8GppSrajeboZMdBUYKra5o6zqR2FgfJkVXxk1en?=
=?us-ascii?Q?flQorrrAt/wN4ebPR2oZD46NRt18mzHaUkFumc0Tu8yVDOIjI9dSUjOLSqnZ?=
=?us-ascii?Q?xjjSvyefcY5eBfq7FwWqshJbuTZ4FiJq/6ptMR23L8sRUjL9MmZQu+Xqb+ER?=
=?us-ascii?Q?qgOYw5mwuNlanHSraoycJn2r1/W3IPHlNj7Z9yfaIuELOEvyJMflJC3TzphE?=
=?us-ascii?Q?slW9Qir4griSyJMlnGPkrpeF1jwZtZ+7x1fIDfd6uejdsIaJigGBFIjGtk5j?=
=?us-ascii?Q?Nxib176Y9sht41FaKQg0HL5UC2SeLnQj7wA69Wg5uBgm/b+RmjWV87uB9vB+?=
=?us-ascii?Q?Ro4TSxYwaaJJihXovNsRPvCD8mlYi9PT0J8kAhg2ZMrqfW4f5SYR+U/J6Kto?=
=?us-ascii?Q?kQ2HsNvEUomCCzs8OIpPCxjO8OgybR9xZ4YV8WnZOUxTDBmTfAOiJWopKnlz?=
=?us-ascii?Q?DJsGBGW3lrPZWe3nlydm7UuoqC5VphyF3145DOnWTAzJiIqB4WdrauSxXVnf?=
=?us-ascii?Q?3Z3BuKaJmdA1JfVvuhwYipyGCSL7zUHcHatYMuYmxZdpj0YfJGZZ7IiMdGSv?=
=?us-ascii?Q?RnKjH21NdVKPFeJTdtwdUlHEcAmFsgauajwq/BATg2vHDSXxm3Dq8nKegcih?=
=?us-ascii?Q?6zIFH2Uk/CB73tq+LP0d2iT1YjAUk+ukA09D1oyl0CCcnAZBcD8/e59Xq53Z?=
=?us-ascii?Q?Y7yZdnBXkfxJbLPNvufkoQsFTtXt0B3nBtUsZYnZeb79sDcqQDCxZs3mHXbo?=
=?us-ascii?Q?inMPm9svnLAPycgMtFUwyyMMxk34EjBknLEe3AZurp51FYarnrx8GczhwhZ5?=
=?us-ascii?Q?3JgnYGWzqvopxeqc3+dTTGbtdaBZmns8DHd7kjZ6JJPBNvyCvynwWAfn9/ea?=
=?us-ascii?Q?PaEb4VNZfNm9NQ92sLh7k6fVGo4BjzaK8UPmj/8gfkJ2VcsnVVa8qVdBgo8c?=
=?us-ascii?Q?8+IMuyxnbJaRCN0c3EzbB8E4WQXkg2dFHAbPb4HJmATPENkYhY3EZpTR8FmA?=
=?us-ascii?Q?XrOkuc1dsdtjH1M0M1j2PGjyBIAafKZY4t1kKsZ7yefhqImGGJk4FAOkLMj4?=
=?us-ascii?Q?pg8OPSaLzZepZKgvZYXMF/AfwSe0LdWjbHdcFT+j4/rutAEgQADYppZtPJcQ?=
=?us-ascii?Q?LXrJlNtemG3AUakikmrLXpihT5ATIH8ZD4Dc9UZvQk8p1y/N0VPBtQ=3D=3D?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAXPR04MB8510.eurprd04.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(52116014)(376014)(1800799024)(38350700014);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?us-ascii?Q?EzUFr7UR7tkIbMYsMj0eLDJeRr9B6f2nED7//gVzoi/iLeGSq7FbhMM5rD2x?=
=?us-ascii?Q?97lIqjE+7YnVEdedXng1XM+GDh5+L9/nm5lk0YuhTZLy3jKhSA/8gwqJf5oP?=
=?us-ascii?Q?nnbmEQPZjWTA/tUCPoFBwW2Er6NAfB6RG8YIjYvC07l9gFmqIqnDuHsloHfM?=
=?us-ascii?Q?3phbC0nNDuwy8danL93F+K4CAUwWDsSJ1yYfSwVM4LrsXdTHZITGNnrnqgaG?=
=?us-ascii?Q?5/P7DJ+n1pL0/olR9QugTJ+mPHHwW8V2Ew5DdK/HgRIQ8PRNRB5xUZixOlDP?=
=?us-ascii?Q?26nQiUvSp0GHLSMQScWeAIUdW6ASTn7ZqbDAHxmlcvKwFS3AFqIM3ImXPduM?=
=?us-ascii?Q?5/05Ejcuw+OYJbqDCipDg70xVWLSaHyuJ+0fFtQMKPZhaZNd07+MThb75xE3?=
=?us-ascii?Q?qQzu1hFSvzqQZB0Zi4vi1wK75hFPMSsnyfikCp0Muc6N5z0FLSn2I88HkHy4?=
=?us-ascii?Q?oJoGSEkGJpBMH/txQFZHEmsmtWmrvaB9hgy9hv0jZnKZDZXxI7/R5dujjEXo?=
=?us-ascii?Q?3oLDMp33sj8al1FhoTJEzbfQEf7K1X0C/dQLvp0Qr0LoecBYrHESwjq525Of?=
=?us-ascii?Q?nmlb6/PKpN/jzHN03ooecvV0SIAn5xOsrXdu8YPclNVdfwR8EomXFQ5H1SGi?=
=?us-ascii?Q?wvlXd795yYbtIluPSSgFIv/mJ3Xj8htWMn+JAcZKzePlAWAWlDbZrigdL8hB?=
=?us-ascii?Q?FJ74TCrv4uq0Itu5793ILdzAXt2N5M2ognZvSYwPlUyC29tvo83oX4Er7WFL?=
=?us-ascii?Q?4iWDLpfQdE6IjOkB2wnFwwsSjpknnDWmwClgwqueUdlDQTOJRpsO8dxcbiGQ?=
=?us-ascii?Q?by334sycYRidhruauUfHdhkRpTH9N3TArPDu44Xjiedv2Nx06xHPfLa/ud9y?=
=?us-ascii?Q?E+0tDuyqlRAaaDod6nbrOJeL14pZhXEbX2NFItg8sa0L+6WkjxxOEtNSLaD9?=
=?us-ascii?Q?MpsFIki0+qsn9YTphwOsWgGsa/bZqHtjJcv5ivGifEnqCaERNBeEoyQhifiO?=
=?us-ascii?Q?u3XD76fyML2bGd8EiLiGhFq+/Bmpdt2jqoFf7jB4ljRP+FHy2GlQuB4/LuNg?=
=?us-ascii?Q?ZM5dnWTrVzPMTn9kil3IhQzmJK9J6sBko7T5TBpT2AzVTVV5td3topykvh22?=
=?us-ascii?Q?vT+CX5ehZezp1p/nv/arFzTposIgJvE/eLM/pUm559gEhVEGyVbmrujqoGrH?=
=?us-ascii?Q?6suv8TXSj2iWcvUUhz4ZHs0VHFOhSXYtZRmV9V0ZQZL3RZs3qMfhzdmQL+0F?=
=?us-ascii?Q?Knijk5Mk3qY5LXrs4AOpmDx4nofC1SFZkQyLQuxfcTtLr4FITbbaYxw8nY7I?=
=?us-ascii?Q?Nu7VWD42Va7cIAyWbMVv0cBsqAq9SLCfvprCkEPIqD9Egg1Q8X27XK+fDhEF?=
=?us-ascii?Q?c+lIkpChLOy6riUoeEcWs9aSFgoeLawvnJjcL8I5GANo3U98T/cwpuM87dkw?=
=?us-ascii?Q?UroY3Ze+lVYx/cewCAvGWBoGciljZdrzVvS/AXfIUbttVOwdbVz7CMOHyrMs?=
=?us-ascii?Q?y+Oc6D7of0QWeSyCBV7NXm0/FMNn5lwMgxj4dql7mMKYImWg6T4IVCDeuxb3?=
=?us-ascii?Q?evim4xeoZrBfYXiz+W03U/CLwOdc60vzEgt2ARJA?=
X-OriginatorOrg: nxp.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1ae6de35-7969-430f-2351-08dd9f5b2b74
X-MS-Exchange-CrossTenant-AuthSource: PAXPR04MB8510.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 09:20:07.9350
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 5aReHm70IqWTOxSaOgKt30IhCY2rbbO4rZWshNtQ2oP/9XhBF6SxfXQddnBhK7NMcZWNw7IRwnDzFT1T8Yw8Kg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB7025
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Both PF and VF have rx-vlan-offload enabled, however, the PCVLANR1/2
registers are resources controlled by PF, so VF cannot access these
two registers. Fortunately, the hardware provides SICVLANR1/2 registers
for each SI to reflect the value of PCVLANR1/2 registers. Therefore,
use SICVLANR1/2 instead of PCVLANR1/2.
In addition, since ENETC_RXBD_FLAG_TPID is defined as GENMASK(1, 0),
the possible values are only 0, 1, 2, 3, so the default branch will
never be true, so remove the default branch.
Fixes: 827b6fd04651 ("net: enetc: fix incorrect TPID when receiving 802.1ad tagged packets")
Signed-off-by: Wei Fang <wei.fang@xxxxxxx>
---
drivers/net/ethernet/freescale/enetc/enetc.c | 12 +++++-------
drivers/net/ethernet/freescale/enetc/enetc_hw.h | 5 +++--
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index dcc3fbac3481..e4287725832e 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1375,6 +1375,7 @@ static void enetc_get_offloads(struct enetc_bdr *rx_ring,
}
if (le16_to_cpu(rxbd->r.flags) & ENETC_RXBD_FLAG_VLAN) {
+ struct enetc_hw *hw = &priv->si->hw;
__be16 tpid = 0;
switch (le16_to_cpu(rxbd->r.flags) & ENETC_RXBD_FLAG_TPID) {
@@ -1385,15 +1386,12 @@ static void enetc_get_offloads(struct enetc_bdr *rx_ring,
tpid = htons(ETH_P_8021AD);
break;
case 2:
- tpid = htons(enetc_port_rd(&priv->si->hw,
- ENETC_PCVLANR1));
+ tpid = htons(enetc_rd_hot(hw, ENETC_SICVLANR1) &
+ SICVLANR_ETYPE);
break;
case 3:
- tpid = htons(enetc_port_rd(&priv->si->hw,
- ENETC_PCVLANR2));
- break;
- default:
- break;
+ tpid = htons(enetc_rd_hot(hw, ENETC_SICVLANR2) &
+ SICVLANR_ETYPE);
}
__vlan_hwaccel_put_tag(skb, tpid, le16_to_cpu(rxbd->r.vlan_opt));
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_hw.h b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
index 4098f01479bc..0385aa66a391 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_hw.h
+++ b/drivers/net/ethernet/freescale/enetc/enetc_hw.h
@@ -43,6 +43,9 @@
#define ENETC_SIPMAR0 0x80
#define ENETC_SIPMAR1 0x84
+#define ENETC_SICVLANR1 0x90
+#define ENETC_SICVLANR2 0x94
+#define SICVLANR_ETYPE GENMASK(15, 0)
/* VF-PF Message passing */
#define ENETC_DEFAULT_MSG_SIZE 1024 /* and max size */
@@ -178,8 +181,6 @@ enum enetc_bdr_type {TX, RX};
#define ENETC_PSIPMAR0(n) (0x0100 + (n) * 0x8) /* n = SI index */
#define ENETC_PSIPMAR1(n) (0x0104 + (n) * 0x8)
#define ENETC_PVCLCTR 0x0208
-#define ENETC_PCVLANR1 0x0210
-#define ENETC_PCVLANR2 0x0214
#define ENETC_VLAN_TYPE_C BIT(0)
#define ENETC_VLAN_TYPE_S BIT(1)
#define ENETC_PVCLCTR_OVTPIDL(bmp) ((bmp) & 0xff) /* VLAN_TYPE */
--
2.34.1
Return-Path: <linux-kernel+bounces-667842-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 6301941E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:21:20 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 375241BA79EC
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:21:33 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id F109B21CA05;
Fri, 30 May 2025 09:21:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="JnDztR3H"
Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45])
(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 BA2CA212B3D
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:21:08 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596871; cv=none; b=UtbbSWHUu3Bf64ha82eNx40xI4wYPFmVRA49pmcq84wUQ44VlPeFrtOkRrtpopVGd50QTJNMi8jVOTvtga0MAxwpCG/d8JuLQsO86G8lbLiDgRYMEDIe1qUaRgZbFcybopB5QySG7IuLZaHj3rb28bhyX65lPQpQPH8AVjuyQjY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596871; c=relaxed/simple;
bh=D46erJa1hDlfl78bbCvumBIwf11Orw9oayL8XK4PtbE=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=IvRzYonN5UjUO5u3YU4HyLOwU7U6aEZznMcnMEfo5XqhduDY3i3T4pwYz0teIE3mLGoqa7jg5rpBm2fJxYd9U491o1DGw+3I1DLSWOOyB1527rmV6uEkTJMkjNFjeaG5FLOd70Y9i1mn4m3Ar3ry/lCFWlzAdnlcl9MU3TxpwPM=
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=JnDztR3H; arc=none smtp.client-ip=209.85.221.45
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-wr1-f45.google.com with SMTP id ffacd0b85a97d-3a35c894313so1585569f8f.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1748596867; x=1749201667; darn=vger.kernel.org;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:from:to:cc:subject:date:message-id:reply-to;
bh=2FF94acC02KXHXPQmhhdghAhcPWaDPTPL3VB4RqaEg0=;
b=JnDztR3HJGTIGgbjvA7qShbHEkjwjkvVAn+xnPElHGDs62ZG1NSQ4Nm1drlpcHbK5M
rVY4Mx17AJJOCynCrH2WcQe6u0RLjLCrP1dn8QavMlmo3euUL7+xbG4tGyqNeQGfd04U
qi7AsPrgZjkhYB0kSef8e/wN+TvmDxGobuLToWf7DE7DmANh1l0GOD9k1WA2JRJ+GkN9
cMArig3WBFqpdgxeah1lk5+x3DSsR1UPAUx8v8sv6GL0T8gaKNsvnqyBKcmgEiDgpg2g
KF21w051PWr49n5NNkIYa31EfU3rpwLSvYMiR9TiqW0zp3aosc/aYh+yJM7TlDnaXTcc
Vcqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748596867; x=1749201667;
h=content-transfer-encoding:in-reply-to:from:content-language
:references:cc:to:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=2FF94acC02KXHXPQmhhdghAhcPWaDPTPL3VB4RqaEg0=;
b=pG8pKCbsKdWgtQc0WVw+VwdoVsN/CiCU/JI4Hnu9lw5wljjrVmUoRtWbvHuXUHzZWE
elQJOcABPhS74STyX3vR6onXb9qZeFc/SN21nNYZkB7BWyOY4Qe+1Ec5YB4Nr5FubP+B
5uMYSb0UGyQsZKRt9Wt7vnLfC9ZwDBZX5a7nV2Fc6rlCkubEDVtwSK8MdzSKMsXp/9lz
zrhczF9jLT/6AsXwV99ZV1eekYGhp9DPrZnEJ7qYJqKWnpNxBy174CzvwuEDWTMg2dxl
OMMJKrcuYMZmzBv2OaCeX32zkg7lEWV0eG9IEqjmoOKMG5AyIzxF2tmMQbFjb8kInCdH
TDNg==
X-Forwarded-Encrypted: i=1; AJvYcCVs46RkahaAqjQBZ0rubA3aAT2fqrfVkeSruU58/5HhwOktL4YKy/8GPk7E14clYd5uqvpViwdaAnX1BJU=@vger.kernel.org
X-Gm-Message-State: AOJu0Yx5bknXJjuRuZiatjIpTpDhjk/rVgMlzPj/+NOKotymUzSQe0G5
DM8pLbQaUVaSFzqYtkGgCHBGr9PEwEhQmewHupyS4ZHO61jRM0+WegmhduWygK20x1AoOxlyfeh
k9TzSnWI=
X-Gm-Gg: ASbGncsWEdCEKNstMCCd/VwSVAJ/U9h6+F+oWBnT6GwqDUzwbeZvFLGVRM+/wt3H3TW
smUCufcMlNh0ARXkdHUEuXVO7iXB1xJyEWmjxxWtX6RGd40NtgflJ/v3k1vkl+aYTZfqCxucjxc
KLrX9N7g6RxXR+C1An8G/x6lxzcMYvwNUAz2ZO4673Km/mCPgqHFFVXlpq0XnmeQ13Go3qovmZC
vgezkwF88rvqBheXhVNK79ciRAFG+DUa0ALyGqAGqnRlH4PnaYbpuBaxih7k3ZWGFtiLL5Zv+wO
kw5c6+xNjCa0nd+cza1xnNdIyTbXh2EVMhefbrEwe0ZTMUxSu7vv2FtKduUbCd/L4p9LOFaXK5K
Bjp84AMCx7XYYsialUSOLIls5NTM=
X-Google-Smtp-Source: AGHT+IFvcFNB62OxE7MIDiidAN2Mv/BdtuQ0G91swbi4nnUSB4ekkNNovaQmQRzoZEkSDncgY+MwZw==
X-Received: by 2002:a05:6000:4009:b0:3a4:dfa5:325e with SMTP id ffacd0b85a97d-3a4f7a438e5mr1975523f8f.10.1748594904489;
Fri, 30 May 2025 01:48:24 -0700 (PDT)
Received: from [192.168.0.35] (188-141-3-146.dynamic.upc.ie. [188.141.3.146])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe7440asm4317227f8f.58.2025.05.30.01.48.23
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 01:48:23 -0700 (PDT)
Message-ID: <8b396edf-e344-47e9-b497-3f7fb35783ed@xxxxxxxxxx>
Date: Fri, 30 May 2025 09:48:22 +0100
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 5/8] power: supply: qcom_battmgr: Add charge control
support
To: fenglin.wu@xxxxxxxxxxxxxxxx, Sebastian Reichel <sre@xxxxxxxxxx>,
Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>, Conor Dooley
<conor+dt@xxxxxxxxxx>, Heikki Krogerus <heikki.krogerus@xxxxxxxxxxxxxxx>,
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
Cc: Subbaraman Narayanamurthy <subbaraman.narayanamurthy@xxxxxxxxxxxxxxxx>,
David Collins <david.collins@xxxxxxxxxxxxxxxx>, linux-pm@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, linux-arm-msm@xxxxxxxxxxxxxxx,
kernel@xxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
linux-usb@xxxxxxxxxxxxxxx
References: <20250530-qcom_battmgr_update-v2-0-9e377193a656@xxxxxxxxxxxxxxxx>
<497BF3hThnrmYe-YHKmdOyZwdjP3ivm1hFYDDy3-HkSOvkCOMVSkokyhb859mcTarGb55Go5nJLfgsc553u7ZA==@protonmail.internalid>
<20250530-qcom_battmgr_update-v2-5-9e377193a656@xxxxxxxxxxxxxxxx>
Content-Language: en-US
From: Bryan O'Donoghue <bryan.odonoghue@xxxxxxxxxx>
In-Reply-To: <20250530-qcom_battmgr_update-v2-5-9e377193a656@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30/05/2025 08:35, Fenglin Wu via B4 Relay wrote:
> From: Fenglin Wu <fenglin.wu@xxxxxxxxxxxxxxxx>
>
> Add charge control support for SM8550 and X1E80100. It's supported
> with below two power supply properties:
>
> charge_control_end_threshold: SOC threshold at which the charging
> should be terminated.
>
> charge_control_start_threshold: SOC threshold at which the charging
> should be resumed.
Maybe this is very obvious to battery charger experts but what does SOC
mean here ?
Reading your patch you pass a "int soc" and compare it to a threshold
value, without 'soc' having an obvious meaning.
Its a threshold right ? Why not just call it threshold ?
>
> Signed-off-by: Fenglin Wu <fenglin.wu@xxxxxxxxxxxxxxxx>
> ---
> drivers/power/supply/qcom_battmgr.c | 256 ++++++++++++++++++++++++++++++++++--
> 1 file changed, 248 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/power/supply/qcom_battmgr.c b/drivers/power/supply/qcom_battmgr.c
> index d5d0200b92bdc3d9a22f44159ad45b152efe8be0..39009415f4bfcd76b010305179d3c8fb847254a6 100644
> --- a/drivers/power/supply/qcom_battmgr.c
> +++ b/drivers/power/supply/qcom_battmgr.c
> @@ -21,6 +21,8 @@
> enum qcom_battmgr_variant {
> QCOM_BATTMGR_SM8350,
> QCOM_BATTMGR_SC8280XP,
> + QCOM_BATTMGR_X1E80100,
> + QCOM_BATTMGR_SM8550,
You're breaking ordering here.
Well the ordering is already broken but, please sort this list
alphanumerically.
> };
>
> #define BATTMGR_BAT_STATUS 0x1
> @@ -66,6 +68,9 @@ enum qcom_battmgr_variant {
> #define BATT_RESISTANCE 21
> #define BATT_POWER_NOW 22
> #define BATT_POWER_AVG 23
> +#define BATT_CHG_CTRL_EN 24
> +#define BATT_CHG_CTRL_START_THR 25
> +#define BATT_CHG_CTRL_END_THR 26
>
> #define BATTMGR_USB_PROPERTY_GET 0x32
> #define BATTMGR_USB_PROPERTY_SET 0x33
> @@ -90,6 +95,13 @@ enum qcom_battmgr_variant {
> #define WLS_TYPE 5
> #define WLS_BOOST_EN 6
>
> +#define BATTMGR_CHG_CTRL_LIMIT_EN 0x48
> +#define CHARGE_CTRL_START_THR_MIN 50
> +#define CHARGE_CTRL_START_THR_MAX 95
> +#define CHARGE_CTRL_END_THR_MIN 55
> +#define CHARGE_CTRL_END_THR_MAX 100
> +#define CHARGE_CTRL_DELTA_SOC 5
> +
> struct qcom_battmgr_enable_request {
> struct pmic_glink_hdr hdr;
> __le32 battery_id;
> @@ -124,6 +136,13 @@ struct qcom_battmgr_discharge_time_request {
> __le32 reserved;
> };
>
> +struct qcom_battmgr_charge_ctrl_request {
> + struct pmic_glink_hdr hdr;
> + __le32 enable;
> + __le32 target_soc;
> + __le32 delta_soc;
> +};
> +
> struct qcom_battmgr_message {
> struct pmic_glink_hdr hdr;
> union {
> @@ -236,6 +255,8 @@ struct qcom_battmgr_info {
> unsigned int capacity_warning;
> unsigned int cycle_count;
> unsigned int charge_count;
> + unsigned int charge_ctrl_start;
> + unsigned int charge_ctrl_end;
> char model_number[BATTMGR_STRING_LEN];
> char serial_number[BATTMGR_STRING_LEN];
> char oem_info[BATTMGR_STRING_LEN];
> @@ -424,6 +445,8 @@ static const u8 sm8350_bat_prop_map[] = {
> [POWER_SUPPLY_PROP_RESISTANCE] = BATT_RESISTANCE,
> [POWER_SUPPLY_PROP_STATE_OF_HEALTH] = BATT_SOH,
> [POWER_SUPPLY_PROP_POWER_NOW] = BATT_POWER_NOW,
> + [POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD] = BATT_CHG_CTRL_START_THR,
> + [POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD] = BATT_CHG_CTRL_END_THR,
> };
>
> static int qcom_battmgr_bat_sm8350_update(struct qcom_battmgr *battmgr,
> @@ -494,7 +517,8 @@ static int qcom_battmgr_bat_get_property(struct power_supply *psy,
> if (!battmgr->service_up)
> return -EAGAIN;
>
> - if (battmgr->variant == QCOM_BATTMGR_SC8280XP)
> + if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
> + battmgr->variant == QCOM_BATTMGR_X1E80100)
Please run your series through checkpatch
0004-power-supply-qcom_battmgr-Add-state_of_health-proper.patch has no
obvious style problems and is ready for submission.
CHECK: Alignment should match open parenthesis
#95: FILE: drivers/power/supply/qcom_battmgr.c:521:
+ if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
+ battmgr->variant == QCOM_BATTMGR_X1E80100)
CHECK: Alignment should match open parenthesis
#137: FILE: drivers/power/supply/qcom_battmgr.c:678:
+ if (soc < CHARGE_CTRL_START_THR_MIN ||
+ soc > CHARGE_CTRL_START_THR_MAX) {
CHECK: Alignment should match open parenthesis
#139: FILE: drivers/power/supply/qcom_battmgr.c:680:
+ dev_err(battmgr->dev, "charge control start threshold exceed range:
[%u - %u]\n",
+ CHARGE_CTRL_START_THR_MIN, CHARGE_CTRL_START_THR_MAX);
CHECK: Alignment should match open parenthesis
#175: FILE: drivers/power/supply/qcom_battmgr.c:716:
+ if (soc < CHARGE_CTRL_END_THR_MIN ||
+ soc > CHARGE_CTRL_END_THR_MAX) {
CHECK: Alignment should match open parenthesis
#177: FILE: drivers/power/supply/qcom_battmgr.c:718:
+ dev_err(battmgr->dev, "charge control end threshold exceed range: [%u
- %u]\n",
+ CHARGE_CTRL_END_THR_MIN, CHARGE_CTRL_END_THR_MAX);
CHECK: Alignment should match open parenthesis
#196: FILE: drivers/power/supply/qcom_battmgr.c:737:
+static int qcom_battmgr_bat_is_writeable(struct power_supply *psy,
+ enum power_supply_property psp)
CHECK: Alignment should match open parenthesis
#210: FILE: drivers/power/supply/qcom_battmgr.c:751:
+static int qcom_battmgr_bat_set_property(struct power_supply *psy,
+ enum power_supply_property psp,
CHECK: Alignment should match open parenthesis
#326: FILE: drivers/power/supply/qcom_battmgr.c:985:
+ if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
+ battmgr->variant == QCOM_BATTMGR_X1E80100)
CHECK: Alignment should match open parenthesis
#336: FILE: drivers/power/supply/qcom_battmgr.c:1108:
+ if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
+ battmgr->variant == QCOM_BATTMGR_X1E80100)
CHECK: Alignment should match open parenthesis
#367: FILE: drivers/power/supply/qcom_battmgr.c:1527:
+ else if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
+ battmgr->variant == QCOM_BATTMGR_X1E80100)
CHECK: Alignment should match open parenthesis
#396: FILE: drivers/power/supply/qcom_battmgr.c:1606:
+ if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
+ battmgr->variant == QCOM_BATTMGR_X1E80100) {
> ret = qcom_battmgr_bat_sc8280xp_update(battmgr, psp);
> else
> ret = qcom_battmgr_bat_sm8350_update(battmgr, psp);
> @@ -599,6 +623,12 @@ static int qcom_battmgr_bat_get_property(struct power_supply *psy,
> case POWER_SUPPLY_PROP_TIME_TO_FULL_AVG:
> val->intval = battmgr->status.charge_time;
> break;
> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD:
> + val->intval = battmgr->info.charge_ctrl_start;
> + break;
> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD:
> + val->intval = battmgr->info.charge_ctrl_end;
> + break;
> case POWER_SUPPLY_PROP_MANUFACTURE_YEAR:
> val->intval = battmgr->info.year;
> break;
> @@ -624,6 +654,120 @@ static int qcom_battmgr_bat_get_property(struct power_supply *psy,
> return 0;
> }
>
> +static int qcom_battmgr_set_charge_control(struct qcom_battmgr *battmgr,
> + u32 target_soc, u32 delta_soc)
> +{
> + struct qcom_battmgr_charge_ctrl_request request = {
> + .hdr.owner = cpu_to_le32(PMIC_GLINK_OWNER_BATTMGR),
> + .hdr.type = cpu_to_le32(PMIC_GLINK_REQ_RESP),
> + .hdr.opcode = cpu_to_le32(BATTMGR_CHG_CTRL_LIMIT_EN),
> + .enable = cpu_to_le32(1),
> + .target_soc = cpu_to_le32(target_soc),
> + .delta_soc = cpu_to_le32(delta_soc),
> + };
> +
> + return qcom_battmgr_request(battmgr, &request, sizeof(request));
> +}
> +
> +static int qcom_battmgr_set_charge_start_threshold(struct qcom_battmgr *battmgr, int soc)
> +{
> + u32 target_soc, delta_soc;
> + int ret;
> +
> + if (soc < CHARGE_CTRL_START_THR_MIN ||
> + soc > CHARGE_CTRL_START_THR_MAX) {
> + dev_err(battmgr->dev, "charge control start threshold exceed range: [%u - %u]\n",
> + CHARGE_CTRL_START_THR_MIN, CHARGE_CTRL_START_THR_MAX);
> + return -EINVAL;
> + }
'soc' is what - a threshold as far as I can tell.
> +
> + /*
> + * If the new start threshold is larger than the old end threshold,
> + * move the end threshold one step (DELTA_SOC) after the new start
> + * threshold.
> + */
> + if (soc > battmgr->info.charge_ctrl_end) {
> + target_soc = soc + CHARGE_CTRL_DELTA_SOC;
> + target_soc = min_t(u32, target_soc, CHARGE_CTRL_END_THR_MAX);
> + delta_soc = target_soc - soc;
> + delta_soc = min_t(u32, delta_soc, CHARGE_CTRL_DELTA_SOC);
> + } else {
> + target_soc = battmgr->info.charge_ctrl_end;
> + delta_soc = battmgr->info.charge_ctrl_end - soc;
> + }
> +
> + mutex_lock(&battmgr->lock);
> + ret = qcom_battmgr_set_charge_control(battmgr, target_soc, delta_soc);
> + mutex_unlock(&battmgr->lock);
> + if (!ret) {
> + battmgr->info.charge_ctrl_start = soc;
> + battmgr->info.charge_ctrl_end = target_soc;
> + }
> +
> + return 0;
> +}
> +
> +static int qcom_battmgr_set_charge_end_threshold(struct qcom_battmgr *battmgr, int soc)
> +{
> + u32 delta_soc = CHARGE_CTRL_DELTA_SOC;
> + int ret;
> +
> + if (soc < CHARGE_CTRL_END_THR_MIN ||
> + soc > CHARGE_CTRL_END_THR_MAX) {
> + dev_err(battmgr->dev, "charge control end threshold exceed range: [%u - %u]\n",
> + CHARGE_CTRL_END_THR_MIN, CHARGE_CTRL_END_THR_MAX);
> + return -EINVAL;
> + }
> +
> + if (battmgr->info.charge_ctrl_start && soc > battmgr->info.charge_ctrl_start)
> + delta_soc = soc - battmgr->info.charge_ctrl_start;
> +
> + mutex_lock(&battmgr->lock);
> + ret = qcom_battmgr_set_charge_control(battmgr, soc, delta_soc);
> + mutex_unlock(&battmgr->lock);
> + if (!ret) {
> + battmgr->info.charge_ctrl_start = soc - delta_soc;
> + battmgr->info.charge_ctrl_end = soc;
> + }
> +
> + return 0;
> +}
> +
> +static int qcom_battmgr_bat_is_writeable(struct power_supply *psy,
> + enum power_supply_property psp)
> +{
> + switch (psp) {
> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD:
> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD:
> + return 1;
> + default:
> + return 0;
> + }
> +
> + return 0;
> +}
> +
> +static int qcom_battmgr_bat_set_property(struct power_supply *psy,
> + enum power_supply_property psp,
> + const union power_supply_propval *pval)
> +{
> + struct qcom_battmgr *battmgr = power_supply_get_drvdata(psy);
> +
> + if (!battmgr->service_up)
> + return -EAGAIN;
> +
> + switch (psp) {
> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD:
> + return qcom_battmgr_set_charge_start_threshold(battmgr, pval->intval);
> + case POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD:
> + return qcom_battmgr_set_charge_end_threshold(battmgr, pval->intval);
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static const enum power_supply_property sc8280xp_bat_props[] = {
> POWER_SUPPLY_PROP_STATUS,
> POWER_SUPPLY_PROP_PRESENT,
> @@ -657,6 +801,43 @@ static const struct power_supply_desc sc8280xp_bat_psy_desc = {
> .get_property = qcom_battmgr_bat_get_property,
> };
>
> +static const enum power_supply_property x1e80100_bat_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_TECHNOLOGY,
> + POWER_SUPPLY_PROP_CYCLE_COUNT,
> + POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_POWER_NOW,
> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> + POWER_SUPPLY_PROP_CHARGE_FULL,
> + POWER_SUPPLY_PROP_CHARGE_EMPTY,
> + POWER_SUPPLY_PROP_CHARGE_NOW,
> + POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
> + POWER_SUPPLY_PROP_ENERGY_FULL,
> + POWER_SUPPLY_PROP_ENERGY_EMPTY,
> + POWER_SUPPLY_PROP_ENERGY_NOW,
> + POWER_SUPPLY_PROP_TEMP,
> + POWER_SUPPLY_PROP_MANUFACTURE_YEAR,
> + POWER_SUPPLY_PROP_MANUFACTURE_MONTH,
> + POWER_SUPPLY_PROP_MANUFACTURE_DAY,
> + POWER_SUPPLY_PROP_MODEL_NAME,
> + POWER_SUPPLY_PROP_MANUFACTURER,
> + POWER_SUPPLY_PROP_SERIAL_NUMBER,
> + POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD,
> + POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD,
> +};
> +
> +static const struct power_supply_desc x1e80100_bat_psy_desc = {
> + .name = "qcom-battmgr-bat",
> + .type = POWER_SUPPLY_TYPE_BATTERY,
> + .properties = x1e80100_bat_props,
> + .num_properties = ARRAY_SIZE(x1e80100_bat_props),
> + .get_property = qcom_battmgr_bat_get_property,
> + .set_property = qcom_battmgr_bat_set_property,
> + .property_is_writeable = qcom_battmgr_bat_is_writeable,
> +};
> +
> static const enum power_supply_property sm8350_bat_props[] = {
> POWER_SUPPLY_PROP_STATUS,
> POWER_SUPPLY_PROP_HEALTH,
> @@ -689,6 +870,42 @@ static const struct power_supply_desc sm8350_bat_psy_desc = {
> .get_property = qcom_battmgr_bat_get_property,
> };
>
> +static const enum power_supply_property sm8550_bat_props[] = {
> + POWER_SUPPLY_PROP_STATUS,
> + POWER_SUPPLY_PROP_HEALTH,
> + POWER_SUPPLY_PROP_PRESENT,
> + POWER_SUPPLY_PROP_CHARGE_TYPE,
> + POWER_SUPPLY_PROP_CAPACITY,
> + POWER_SUPPLY_PROP_VOLTAGE_OCV,
> + POWER_SUPPLY_PROP_VOLTAGE_NOW,
> + POWER_SUPPLY_PROP_VOLTAGE_MAX,
> + POWER_SUPPLY_PROP_CURRENT_NOW,
> + POWER_SUPPLY_PROP_TEMP,
> + POWER_SUPPLY_PROP_TECHNOLOGY,
> + POWER_SUPPLY_PROP_CHARGE_COUNTER,
> + POWER_SUPPLY_PROP_CYCLE_COUNT,
> + POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
> + POWER_SUPPLY_PROP_CHARGE_FULL,
> + POWER_SUPPLY_PROP_MODEL_NAME,
> + POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
> + POWER_SUPPLY_PROP_TIME_TO_EMPTY_AVG,
> + POWER_SUPPLY_PROP_RESISTANCE,
> + POWER_SUPPLY_PROP_STATE_OF_HEALTH,
> + POWER_SUPPLY_PROP_POWER_NOW,
> + POWER_SUPPLY_PROP_CHARGE_CONTROL_START_THRESHOLD,
> + POWER_SUPPLY_PROP_CHARGE_CONTROL_END_THRESHOLD,
> +};
> +
> +static const struct power_supply_desc sm8550_bat_psy_desc = {
> + .name = "qcom-battmgr-bat",
> + .type = POWER_SUPPLY_TYPE_BATTERY,
> + .properties = sm8550_bat_props,
> + .num_properties = ARRAY_SIZE(sm8550_bat_props),
> + .get_property = qcom_battmgr_bat_get_property,
> + .set_property = qcom_battmgr_bat_set_property,
> + .property_is_writeable = qcom_battmgr_bat_is_writeable,
> +};
> +
> static int qcom_battmgr_ac_get_property(struct power_supply *psy,
> enum power_supply_property psp,
> union power_supply_propval *val)
> @@ -764,7 +981,8 @@ static int qcom_battmgr_usb_get_property(struct power_supply *psy,
> if (!battmgr->service_up)
> return -EAGAIN;
>
> - if (battmgr->variant == QCOM_BATTMGR_SC8280XP)
> + if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
> + battmgr->variant == QCOM_BATTMGR_X1E80100)
> ret = qcom_battmgr_bat_sc8280xp_update(battmgr, psp);
> else
> ret = qcom_battmgr_usb_sm8350_update(battmgr, psp);
> @@ -886,7 +1104,8 @@ static int qcom_battmgr_wls_get_property(struct power_supply *psy,
> if (!battmgr->service_up)
> return -EAGAIN;
>
> - if (battmgr->variant == QCOM_BATTMGR_SC8280XP)
> + if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
> + battmgr->variant == QCOM_BATTMGR_X1E80100)
> ret = qcom_battmgr_bat_sc8280xp_update(battmgr, psp);
> else
> ret = qcom_battmgr_wls_sm8350_update(battmgr, psp);
> @@ -1196,6 +1415,12 @@ static void qcom_battmgr_sm8350_callback(struct qcom_battmgr *battmgr,
> case BATT_POWER_NOW:
> battmgr->status.power_now = le32_to_cpu(resp->intval.value);
> break;
> + case BATT_CHG_CTRL_START_THR:
> + battmgr->info.charge_ctrl_start = le32_to_cpu(resp->intval.value);
> + break;
> + case BATT_CHG_CTRL_END_THR:
> + battmgr->info.charge_ctrl_end = le32_to_cpu(resp->intval.value);
> + break;
> default:
> dev_warn(battmgr->dev, "unknown property %#x\n", property);
> break;
> @@ -1278,6 +1503,7 @@ static void qcom_battmgr_sm8350_callback(struct qcom_battmgr *battmgr,
> }
> break;
> case BATTMGR_REQUEST_NOTIFICATION:
> + case BATTMGR_CHG_CTRL_LIMIT_EN:
> battmgr->error = 0;
> break;
> default:
> @@ -1297,7 +1523,8 @@ static void qcom_battmgr_callback(const void *data, size_t len, void *priv)
>
> if (opcode == BATTMGR_NOTIFICATION)
> qcom_battmgr_notification(battmgr, data, len);
> - else if (battmgr->variant == QCOM_BATTMGR_SC8280XP)
> + else if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
> + battmgr->variant == QCOM_BATTMGR_X1E80100)
> qcom_battmgr_sc8280xp_callback(battmgr, data, len);
> else
> qcom_battmgr_sm8350_callback(battmgr, data, len);
> @@ -1333,7 +1560,8 @@ static void qcom_battmgr_pdr_notify(void *priv, int state)
> static const struct of_device_id qcom_battmgr_of_variants[] = {
> { .compatible = "qcom,sc8180x-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
> { .compatible = "qcom,sc8280xp-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
> - { .compatible = "qcom,x1e80100-pmic-glink", .data = (void *)QCOM_BATTMGR_SC8280XP },
> + { .compatible = "qcom,x1e80100-pmic-glink", .data = (void *)QCOM_BATTMGR_X1E80100 },
> + { .compatible = "qcom,sm8550-pmic-glink", .data = (void *)QCOM_BATTMGR_SM8550 },
Please separate compat string addition from functional changes.
> /* Unmatched devices falls back to QCOM_BATTMGR_SM8350 */
> {}
> };
> @@ -1343,6 +1571,7 @@ static char *qcom_battmgr_battery[] = { "battery" };
> static int qcom_battmgr_probe(struct auxiliary_device *adev,
> const struct auxiliary_device_id *id)
> {
> + const struct power_supply_desc *psy_desc;
> struct power_supply_config psy_cfg_supply = {};
> struct power_supply_config psy_cfg = {};
> const struct of_device_id *match;
> @@ -1373,8 +1602,14 @@ static int qcom_battmgr_probe(struct auxiliary_device *adev,
> else
> battmgr->variant = QCOM_BATTMGR_SM8350;
>
> - if (battmgr->variant == QCOM_BATTMGR_SC8280XP) {
> - battmgr->bat_psy = devm_power_supply_register(dev, &sc8280xp_bat_psy_desc, &psy_cfg);
> + if (battmgr->variant == QCOM_BATTMGR_SC8280XP ||
> + battmgr->variant == QCOM_BATTMGR_X1E80100) {
> + if (battmgr->variant == QCOM_BATTMGR_X1E80100)
> + psy_desc = &x1e80100_bat_psy_desc;
> + else
> + psy_desc = &sc8280xp_bat_psy_desc;
> +
> + battmgr->bat_psy = devm_power_supply_register(dev, psy_desc, &psy_cfg);
> if (IS_ERR(battmgr->bat_psy))
> return dev_err_probe(dev, PTR_ERR(battmgr->bat_psy),
> "failed to register battery power supply\n");
> @@ -1394,7 +1629,12 @@ static int qcom_battmgr_probe(struct auxiliary_device *adev,
> return dev_err_probe(dev, PTR_ERR(battmgr->wls_psy),
> "failed to register wireless charing power supply\n");
> } else {
> - battmgr->bat_psy = devm_power_supply_register(dev, &sm8350_bat_psy_desc, &psy_cfg);
> + if (battmgr->variant == QCOM_BATTMGR_SM8550)
> + psy_desc = &sm8550_bat_psy_desc;
> + else
> + psy_desc = &sm8350_bat_psy_desc;
> +
> + battmgr->bat_psy = devm_power_supply_register(dev, psy_desc, &psy_cfg);
> if (IS_ERR(battmgr->bat_psy))
> return dev_err_probe(dev, PTR_ERR(battmgr->bat_psy),
> "failed to register battery power supply\n");
>
> --
> 2.34.1
>
>
>
Return-Path: <linux-kernel+bounces-667843-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9FE6141E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:21:30 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id A486F3AF583
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:21:09 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 91E4A21CA05;
Fri, 30 May 2025 09:21:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=santannapisa.it header.i=@santannapisa.it header.b="Z7z2YvIL"
Received: from PA4PR04CU001.outbound.protection.outlook.com (mail-francecentralazon11023127.outbound.protection.outlook.com [40.107.162.127])
(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 E911121E082
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:21:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=40.107.162.127
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748596880; cv=fail; b=HaR1UvScNE5MfgL6rpRs8Gx5wk5gDQ3hCNJvPK1Vf8ycPqPJzlAPS39IpCkXCJBlNW8uguzOoTNVSoElpIaRAno3UFZHtDibkC0I3TaHNYJL+cq2Wt+q+kcrYTBmXAxgNvQA3t465czAPM7jF2ZYih6aKufvajVX8DQgMbR+jJo=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748596880; c=relaxed/simple;
bh=LsAah8BKzQ+1S7o1qj4ELyyiBtp4McsrVfFlK05xXlA=;
h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:
Content-Type:MIME-Version; b=RwVOCz/4kV9gogQB/7MuJ6vYlcJRVRYcWJWIKdWpkoz3X3Cp1DaXCB1g2UTnJxsTStOGRICg0L0ZAUCRkm6h7a6f/VNeOXu/3kFX5VQlBDnbD5aUslWIybEozXCo6C8jK7k1zhy4UK3RccFcGgrouZb5tJXOrkQBcJ0wypqihzo=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=santannapisa.it; spf=pass smtp.mailfrom=santannapisa.it; dkim=pass (1024-bit key) header.d=santannapisa.it header.i=@santannapisa.it header.b=Z7z2YvIL; arc=fail smtp.client-ip=40.107.162.127
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=santannapisa.it
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=santannapisa.it
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=rdRQdubzX+nlIlXtmiEycBN1XhzNiXGgndpJj21OdAuQMdta3JR5WG5gY8xprdEaMWUUZ3EFtF25jtM6r+S905so/0AO3nM1rlSWda4GwRoFEgq69rlCA+7kdxki8ex38dJEePwEWR+N6dl37Ypex87hq0JVAFWhDmmOLeyVVaKU/Lb8IhFQqSNgU7WlP2+xktutQ26QJhdZvZDrOSfZinXYvT7MUkVbyQUgXFc98tjdVil1DFx/Pfuszep4I0dRr3ZdIhDZyttGKWgfB2hVfHS9sG5bRxj8xopgJf4GKVKMdjG4bM9V46crS9v/f8tptdjOFBjKpb87YBFUkiEitg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=aSLOJVolvLtBFQwc1c8gyPNV2ZFeIAzz2PZ/fE0C8go=;
b=koA7j7J8FBExHKaD9iRz3E7HA8H3r08MjdlltxnL8PvTWik3r38Dsksbgxp/XX10X8qmdRhajmV52LUajx1FMMBqTjWaJxcWgyMzrZJvHCNwrZhonkIXoHWlGsVTFzvJcGw9+SD3lHfGksuv4hLYFqc3xpJe1awPngt9Cav720DStWSjvJq1Gd8RmQ09etK4JfTuDGYwP6cc4S2z8WJFYi3PxAC1i2rlyxKq5NZLfzRrf2/XWYAx62lBuLHqORcHVp2ybmtguctzOZW+cM5MbI1wXyCld8jFOYXktFB3p83/WCB8DY3ZkLV/jUUynAet3or3KfZhyQrRtRFXLq4xbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=santannapisa.it; dmarc=pass action=none
header.from=santannapisa.it; dkim=pass header.d=santannapisa.it; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=santannapisa.it;
s=selector1;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=aSLOJVolvLtBFQwc1c8gyPNV2ZFeIAzz2PZ/fE0C8go=;
b=Z7z2YvILqkFTF6QkCPM1u8YF1i6l1rI0uPx+w7euHBmT9xJG5+if9PcyjeODPbq0sGoET37x4mR4E41SONjOTWGrQwgsO2ucODpHcHMKxdrzWVupbMC7U6aY6tomIqDa0Oh8vtlu2skPFgYYSyVXYMrerDlF2tfud96XJCTFKnY=
Authentication-Results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=santannapisa.it;
Received: from PAVPR03MB8969.eurprd03.prod.outlook.com (2603:10a6:102:32e::7)
by AS2PR03MB9122.eurprd03.prod.outlook.com (2603:10a6:20b:5f9::9) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8769.30; Fri, 30 May
2025 09:21:11 +0000
Received: from PAVPR03MB8969.eurprd03.prod.outlook.com
([fe80::6bbe:2e22:5b77:7235]) by PAVPR03MB8969.eurprd03.prod.outlook.com
([fe80::6bbe:2e22:5b77:7235%6]) with mapi id 15.20.8769.019; Fri, 30 May 2025
09:21:10 +0000
Date: Fri, 30 May 2025 11:21:08 +0200
From: luca abeni <luca.abeni@xxxxxxxxxxxxxxx>
To: Marcel Ziswiler <marcel.ziswiler@xxxxxxxxxxxxxxx>
Cc: Juri Lelli <juri.lelli@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Ingo
Molnar <mingo@xxxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Vineeth
Pillai <vineeth@xxxxxxxxxxxxxxx>
Subject: Re: SCHED_DEADLINE tasks missing their deadline with
SCHED_FLAG_RECLAIM jobs in the mix (using GRUB)
Message-ID: <20250530112108.63a24cde@luca64>
In-Reply-To: <c91a117401225290fbf0390f2ce78c3e0fb3b2d5.camel@xxxxxxxxxxxxxxx>
References: <ce8469c4fb2f3e2ada74add22cce4bfe61fd5bab.camel@xxxxxxxxxxxxxxx>
<aBTO3r6Py_emwf1Y@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
<f532441d8b3cf35e7058305fd9cd3f2cbd3a9fac.camel@xxxxxxxxxxxxxxx>
<20250507222549.183e0b4a@nowhere>
<92690eb9158c1019dc0945f8298800cad17cae05.camel@xxxxxxxxxxxxxxx>
<20250523214603.043833e3@nowhere>
<c91a117401225290fbf0390f2ce78c3e0fb3b2d5.camel@xxxxxxxxxxxxxxx>
Organization: Scuola Superiore S. Anna
X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-ClientProxiedBy: ZR2P278CA0069.CHEP278.PROD.OUTLOOK.COM
(2603:10a6:910:52::15) To PAVPR03MB8969.eurprd03.prod.outlook.com
(2603:10a6:102:32e::7)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: PAVPR03MB8969:EE_|AS2PR03MB9122:EE_
X-MS-Office365-Filtering-Correlation-Id: 77cd910e-46c9-4bef-3000-08dd9f5b50f3
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|376014|7053199007;
X-Microsoft-Antispam-Message-Info:
=?utf-8?B?aVpid2U2R1NEOW9oeGpDbG5nWEl4ajhwOGN6ZU1rWnJTZlh4UnZ3S2dwdGww?=
=?utf-8?B?ZTdnWDhBVHZBK2tnT2NzYUEvaXZtSFRSeU5qN3JpYzIyZEY4Vm9rMGxpMW5S?=
=?utf-8?B?dFJxNzhoMXhJWk82YUlDY2hGODhPb2FmSUxLL3piUjUyT1lod1RzaHJUdXoy?=
=?utf-8?B?WVZrbE9RMk83UytUWXIvcXYwSDdWREhaZzVVeTVFRzdhSjVJZ1RSRTBZYjJt?=
=?utf-8?B?eHp4UWlPNkxPNTE2WTFrZnVTTlJvbHNpYlNOSDdZR3pRdy9aMEZRRGRMZ1pN?=
=?utf-8?B?M1dhR2x1MC9oeFByWlJqbFlOM1JpdFZUczV2OWpOTndvbUIyZlBJd1dCVWl2?=
=?utf-8?B?aHVrZzNsSUdWWXpLeWlBVFlkVmk0VDgwa3NRUm9YcjZiUThMR2s1NnVNVFlr?=
=?utf-8?B?SmFCNTgyN1d0Ukx0RmcwK3VzMjJpNS8wdTBWUlNLSWo1blNMQTZqUloxSHkx?=
=?utf-8?B?UEs5YllxMDhsUG9XbDVFcEx6dkN2dGx0YjVablJnWGxYY0d1V2VqblBPK1Zk?=
=?utf-8?B?eVVCZWZLbFZFZk9wcjV6bllWbmVjOVp0ZmpHTFdxY3Zod0NyV0RvM09ocFMx?=
=?utf-8?B?NTJ4ajcxY0hXN2cxT3A0bHJRTjE3aDE5U2Z2Tk5EdEVJa1lDNm1aMmdIYWx2?=
=?utf-8?B?b3p4NHJVd21BUHFicEx4R2F2ZllqbEh1Um83T3N2ZVZtT1RWN3BpMDJNTnYr?=
=?utf-8?B?TXA5SzZ5M0Q0U21iR0NEUGNTR0hvQVNMTXJ4Qk9OOWxpU004Uk01anhueDhF?=
=?utf-8?B?Vm9oR0dUTkdVdmZzaE9YWDlURWZsL3pidDM1enJwRlNVRW5XUThLL0dha05v?=
=?utf-8?B?eGh4TGNraWlsQUpEeUxmek9ZMzVNMTQyR1E5TGFrUEpFZ0FZSUUvR3o4Zjgx?=
=?utf-8?B?aGRiT0lKMFRzL3lzR2U1eGEzbjhmUCs0U0VkNDFTOUNabEtnWUNDemM5VkF3?=
=?utf-8?B?ekg1d1p3TFZWSXc4TzNySlZzdnQ4eGlJNGxtMUVPbEpaeGIyWFpmZkNaMjFD?=
=?utf-8?B?ckFNVXRldWNOTWNPbG1JUGRKdVdybFFHKzdoYmM4Tmh1NFRlODJranpSVGF3?=
=?utf-8?B?aUN2WmFUTnhLZURWamh3ajNXYVpTTm84R3V4VktoQnBNM1RKeTFYc0pwdXdV?=
=?utf-8?B?Qm9NeG1UUG5zZ1RIbEJvQTMreDhhZHV0emJ5K2NUaFJMOXA0Y211NUlVYlQ3?=
=?utf-8?B?REdPVFVuYjA0NURMWENwK1NNWUtIOFZ3NVErZHNNTlJwVnRnS01BZmFRdzlE?=
=?utf-8?B?Vjg0S2syVzdtVXBYelFvZGFJODhERHAzV2tqQlIwWkZ0eG5mcDJkMDFyRGhS?=
=?utf-8?B?Tm1wOHFBcHhvZ0p0Rk5FeU5uR0V4UU5UU3podUNnbEdxWFQvU1A3YzZnV2Rp?=
=?utf-8?B?ZzdzMHZEMzhKdFMzdjdpNnFHMmVDTTIxcG04ZXF0aWtBNFoxM0Zkb0RpVnJ4?=
=?utf-8?B?dGJmS1JPRUdnWEpJVVdTbVNEL09lVDZCdGJjVGNyRWQzc1FocWp1UWprK3pE?=
=?utf-8?B?RVRKbmNDWXg0emx4TFAwY2xIVEpZWm1EbUt6by85VlhpTldtTGl1Q1JkWkFZ?=
=?utf-8?B?azlEU1FwcjVlVHFCbnZGVWI3WDBzckJTVU9TQi9mQmtjU0lYRU11UC9UazhW?=
=?utf-8?B?Sy9CcmNMK28yRUFrVjRYS1ozeSt5T2JsT2x3ZDNEVG1vSXpQdldEemdLdGFF?=
=?utf-8?B?LzlIdXo3VnBOZWIrYlVHdERmbzVWK25jaWx5a29ib2JmalFWa2hub3FJRFpy?=
=?utf-8?B?STNLMThvdlBTNzJhUncwSm0xaTV0MjFOTDhlVzJkUStFbnZDZTUrMThtcWlR?=
=?utf-8?B?VExDZVBqVXhpUjZ5OXlscFYyWmcvcUNtN2JhQ3VnMmdsam1WSHVzSlRKbXF6?=
=?utf-8?B?Z3BqZ3NuNTdXeWRMeEErRUQvNXJTcnUvdis1UkpzbE91bnc9PQ==?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PAVPR03MB8969.eurprd03.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(376014)(7053199007);DIR:OUT;SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?utf-8?B?WFJ4VHlmVk1vWmFEeVd4VnZjT2drQXJtSTBvVnhSMGgrRXdZWFA3ZDJKd1ox?=
=?utf-8?B?TFZuWCtJcmZKVEF6R2Y5Rklpd1BnVmNIQk9ZZEN4VUFlU2VPRlpYVlhJTW1x?=
=?utf-8?B?dHNacGk4WFg0aTd0b3dWN0d5R3J3QWh3K1FSREVYbkFCRkdmR0luamJLa2ZD?=
=?utf-8?B?QjBrK1NjVUhVeFFVRnorZWcxZXBnTGtCMmpmeUJtU25RUExFR2dTUWhZQk0y?=
=?utf-8?B?Ukx4ai8vbU1JdldxbFRNc2VaQzQ5QXJTTG5Da2xhMXRNSUlKdVR1cFArcGtG?=
=?utf-8?B?U1RVOTRvSUg1MU5uWWVibncxNU1JUkZxNzF6cm4zWFlXNWRheEdNbEJ4Tmg0?=
=?utf-8?B?bGdpcTlIRkJ0K05JZEs5K1dWcFVnS2JjN3lPb2IrWUpwdzIyTTdNTWJDYlB3?=
=?utf-8?B?ZjlZcHhUVDZldE5WREpUVUtCV0NpQi9kNVpoTkJERjdtMk9adWVWd2E0UFlD?=
=?utf-8?B?OW8vbFpnendyVitZemdwYmpwYlFLQ0Jva1dUd2JiMnY1Snd3bEcxWlV6Zllt?=
=?utf-8?B?MVQyb2wrNW5tWlhpd1psQjZ3RTYxMEYzTFpPc2t4NnExekZIbWJGNE9ESUxO?=
=?utf-8?B?cFNzTmlPK2o3aDBseU1sZytsU3FHUG1GMU90UnNwNk1Wd1lkQzh3d2hZN2VE?=
=?utf-8?B?dmZGaVFGQVEyNCs1TVNKMnRRbkZxeFFUVHJ6MU1qQWlxNDB5dThtWmFGL2Zo?=
=?utf-8?B?YkhRWG12TGdoVVlyam9nYkhRM2l0SklWWHhyakxoeEdEVkZ2T1JCYmVqN3ZG?=
=?utf-8?B?czZIOXBjS0tHeUw0c2RCYWNWeVJZTkN0ZzRyNU9WVitZMGN6NjZMeGJ0eHY4?=
=?utf-8?B?RXhqSW1QV3gwOWlWL0g2QnhvdlF6WVZKVW13NnVkc1diK29vRGFyMzk0UHI4?=
=?utf-8?B?VDAwU0pnUUIyZnJEaktOcTV0ZUtGcTBRQ1RUQ0RWUm9hWlowamFaVHBTSGxX?=
=?utf-8?B?RTBQSi9MQkdjcm4vM3llenVRd1RicjdmbTBhTjVmeW9OSWNEVXFDb3V5RFMz?=
=?utf-8?B?d2hWbnYrWHFoelEyR1VZVXI0ME9EUjRHL29TaDNBeHFmeVhEWDdISlk1Mzg4?=
=?utf-8?B?cVRwZHFzblgvcS9xZGpSbm4xck94WXBQU1NpZHFFaTZxMVBNUFIvTzdWMUlD?=
=?utf-8?B?ZXkxN205ZlB1Si94ZEE0QlFqNklIMVZlS3MvZU9ZY21QVjhBK1UwZ1FSZTVJ?=
=?utf-8?B?Z0tSaVB6S2dGbm5uUWlnWUZoL2RIRkhRWFhMUFVUaE9zVWtJRWZYSlNOS1dz?=
=?utf-8?B?TnJtcm5tbTlhTHpYeUUyaFhyZmVxNjZ6OWZxcnZ2ek1QMzhtNlRVeE5VK0tT?=
=?utf-8?B?VzhhUlIwUGRZNEhxdFZpZ2x4eFU4RVFWc0FmNU40SWoxeHQ1WWQ5aUFFSG9Z?=
=?utf-8?B?Qk5MWE1uNGtFUHlCdE5HakhRbHFScGdxdUpjeFFyc0NOdWpFbk0ycE1ydTl4?=
=?utf-8?B?ck1VMWpka0M3YStmMDZIZG5NZVRZaHFGY2ppOU91V2srSEpDQXo4QmtuWDN6?=
=?utf-8?B?bi9jMmVJUWR6eEV2NGJ6ODF5ZExmanZuU2VvNElFUXFjRTRnVkVWUlNsUTBu?=
=?utf-8?B?aVJFUEhmdXNJN2tBdW9sMGVUa3Fmd2JLUHBCQlBTblRrYzE3ZWd4S3d1dVV5?=
=?utf-8?B?UXdZcExZdDNOdjd4UjZVTm50MENjalBadFZYZUFoYlFnY2MzaWdWMStqQmRR?=
=?utf-8?B?VURUTkl5SDJicTJBTUJjNVIzTG4vdVQ1SDhnK0Z5TWFlVVh0amdycnhlSXhS?=
=?utf-8?B?Y1R5dndWdmhhdnZyYVhHMEpTWi83RWlsV3ZFN2pTKy96VmE4dVNSanZRYTJL?=
=?utf-8?B?NnV4THBsak02OXppRkYvbS80b0xiYUxpb2wwL1p1dzdxTUFyYnVQdEpST2ZR?=
=?utf-8?B?eTRva3JzaWs4eHYvUkdJbkM5TVhnTXdQeElnUEZxenZpSStaaUt6MGRBSnR4?=
=?utf-8?B?d0hXWGxUVnNCUkhxQ1l6Nks2VlhnYW5YTjV1clNLZ1hYWXpnaXBBZ2FIczBG?=
=?utf-8?B?czZUaWFSQWhmakZJMjJzUWlCWXpXOWl2RHVTUVFvNFE2NlRaYjFJeVRHTWpo?=
=?utf-8?B?T2xYemRzbGh1RU9FOU1BWEFFSk1HNnZ0UmJTZTVEazFLcGVWSFFHVU1MZEl0?=
=?utf-8?B?dnFuZDFjVlYvaWhhcCtDSnJtanp6YW1uaEx4bjJXaFdwTitYWkwzQ2lQV3dH?=
=?utf-8?B?OHc9PQ==?=
X-OriginatorOrg: santannapisa.it
X-MS-Exchange-CrossTenant-Network-Message-Id: 77cd910e-46c9-4bef-3000-08dd9f5b50f3
X-MS-Exchange-CrossTenant-AuthSource: PAVPR03MB8969.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 09:21:10.6623
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d97360e3-138d-4b5f-956f-a646c364a01e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: YIn9IWHl7sqvRd+bUunYF5nLrG3LcosM1coOq1KVy3colpAT4KInF39a2lHeSAgl4LiG7xgCJhjEu5sLLw7wa7Yo/zxpYNP82RsYBX/qjJ8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR03MB9122
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hi Marcel,
On Sun, 25 May 2025 21:29:05 +0200
Marcel Ziswiler <marcel.ziswiler@xxxxxxxxxxxxxxx> wrote:
[...]
> > How do you configure systemd? I am having troubles in reproducing
> > your AllowedCPUs configuration... This is an example of what I am
> > trying: sudo systemctl set-property --runtime custom-workload.slice
> > AllowedCPUs=3D1 sudo systemctl set-property --runtime init.scope
> > AllowedCPUs=3D0,2,3 sudo systemctl set-property --runtime
> > system.slice AllowedCPUs=3D0,2,3 sudo systemctl set-property
> > --runtime user.slice AllowedCPUs=3D0,2,3 and then I try to run a
> > SCHED_DEADLINE application with sudo systemd-run --scope -p
> > Slice=3Dcustom-workload.slice <application> =20
>=20
> We just use a bunch of systemd configuration files as follows:
>=20
> [root@localhost ~]# cat /lib/systemd/system/monitor.slice
> # Copyright (C) 2024 Codethink Limited
> # SPDX-License-Identifier: GPL-2.0-only
[...]
So, I copied your *.slice files in /lib/systemd/system (and I added
them to the "Wants=3D" entry of /lib/systemd/system/slices.target,
otherwise the slices are not created), but I am still unable to run
SCHED_DEADLINE applications in these slices.
This is due to the fact that the kernel does not create a new root
domain for these cpusets (probably because the cpusets' CPUs are not
exclusive and the cpuset is not "isolated": for example,
/sys/fs/cgroup/safety1.slice/cpuset.cpus.partition is set to "member",
not to "isolated"). So, the "cpumask_subset(span, p->cpus_ptr)" in
sched_setsched() is still false and the syscall returns -EPERM.
Since I do not know how to obtain an isolated cpuset with cgroup v2 and
systemd, I tried using the old cgroup v1, as described in the
SCHED_DEADLINE documentation.
This worked fine, and enabling SCHED_FLAG_RECLAIM actually reduced the
number of missed deadlines (I tried with a set of periodic tasks having
the same parameters as the ones you described). So, it looks like
reclaiming is working correctly (at least, as far as I can see) when
using cgroup v1 to configure the CPU partitions... Maybe there is some
bug triggered by cgroup v2, or maybe I am misunderstanding your setup.
I think the experiment suggested by Juri can help in understanding
where the issue can be.
Thanks,
Luca
> [Unit]
> Description=3DPrioritized slice for the safety monitor.
> Before=3Dslices.target
>=20
> [Slice]
> CPUWeight=3D1000
> AllowedCPUs=3D0
> MemoryAccounting=3Dtrue
> MemoryMin=3D10%
> ManagedOOMPreference=3Domit
>=20
> [Install]
> WantedBy=3Dslices.target
>=20
> [root@localhost ~]# cat /lib/systemd/system/safety1.slice
> # Copyright (C) 2024 Codethink Limited
> # SPDX-License-Identifier: GPL-2.0-only
> [Unit]
> Description=3DSlice for Safety case processes.
> Before=3Dslices.target
>=20
> [Slice]
> CPUWeight=3D1000
> AllowedCPUs=3D1
> MemoryAccounting=3Dtrue
> MemoryMin=3D10%
> ManagedOOMPreference=3Domit
>=20
> [Install]
> WantedBy=3Dslices.target
>=20
> [root@localhost ~]# cat /lib/systemd/system/safety2.slice
> # Copyright (C) 2024 Codethink Limited
> # SPDX-License-Identifier: GPL-2.0-only
> [Unit]
> Description=3DSlice for Safety case processes.
> Before=3Dslices.target
>=20
> [Slice]
> CPUWeight=3D1000
> AllowedCPUs=3D2
> MemoryAccounting=3Dtrue
> MemoryMin=3D10%
> ManagedOOMPreference=3Domit
>=20
> [Install]
> WantedBy=3Dslices.target
>=20
> [root@localhost ~]# cat /lib/systemd/system/safety3.slice
> # Copyright (C) 2024 Codethink Limited
> # SPDX-License-Identifier: GPL-2.0-only
> [Unit]
> Description=3DSlice for Safety case processes.
> Before=3Dslices.target
>=20
> [Slice]
> CPUWeight=3D1000
> AllowedCPUs=3D3
> MemoryAccounting=3Dtrue
> MemoryMin=3D10%
> ManagedOOMPreference=3Domit
>=20
> [Install]
> WantedBy=3Dslices.target
>=20
> [root@localhost ~]# cat /lib/systemd/system/system.slice=20
> # Copyright (C) 2024 Codethink Limited
> # SPDX-License-Identifier: GPL-2.0-only
>=20
> #
> # This slice will control all processes started by systemd by
> # default.
> #
>=20
> [Unit]
> Description=3DSystem Slice
> Documentation=3Dman:systemd.special(7)
> Before=3Dslices.target
>=20
> [Slice]
> CPUQuota=3D150%
> AllowedCPUs=3D0
> MemoryAccounting=3Dtrue
> MemoryMax=3D80%
> ManagedOOMSwap=3Dkill
> ManagedOOMMemoryPressure=3Dkill
>=20
> [root@localhost ~]# cat /lib/systemd/system/user.slice=20
> # Copyright (C) 2024 Codethink Limited
> # SPDX-License-Identifier: GPL-2.0-only
>=20
> #
> # This slice will control all processes started by systemd-logind
> #
>=20
> [Unit]
> Description=3DUser and Session Slice
> Documentation=3Dman:systemd.special(7)
> Before=3Dslices.target
>=20
> [Slice]
> CPUQuota=3D25%
> AllowedCPUs=3D0
> MemoryAccounting=3Dtrue
> MemoryMax=3D80%
> ManagedOOMSwap=3Dkill
> ManagedOOMMemoryPressure=3Dkill
>=20
> > However, this does not work because systemd is not creating an
> > isolated cpuset... So, the root domain still contains CPUs 0-3, and
> > the "custom-workload.slice" cpuset only has CPU 1. Hence, the check
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /*
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
* Don't allow tasks with an affinity mask
> > smaller than
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
* the entire root_domain to become
> > SCHED_DEADLINE. We
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
* will also fail if there's no bandwidth
> > available. */
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!=
cpumask_subset(span, p->cpus_ptr) ||
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 rq->rd->dl_bw.bw =3D=3D 0) {
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 retval =3D -EPERM;
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto unlock;
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
> > in sched_setsched() fails.
> >=20
> >=20
> > How are you configuring the cpusets? =20
>=20
> See above.
>=20
> > Also, which kernel version are you using?
> > (sorry if you already posted this information in previous emails
> > and I am missing something obvious) =20
>=20
> Not even sure, whether I explicitly mentioned that other than that we
> are always running latest stable.
>=20
> Two months ago when we last run some extensive tests on this it was
> actually v6.13.6.
>=20
> > Thanks, =20
>=20
> Thank you!
>=20
> > Luca =20
>=20
> Cheers
>=20
> Marcel
Return-Path: <linux-kernel+bounces-667844-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 3B61041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:24:16 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 5F5AA4A45A0
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:24:17 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id E9C0C21C9F8;
Fri, 30 May 2025 09:24:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="TApjsBvd"
Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169])
(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 E6C6F1E2607
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:24:06 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597049; cv=none; b=V9f7ifWI6KTG3xKWtIxwr2OUYWO342ME1gnibYs3CUhW3u7V/0C6/F63TbgcHFihhY33NVXD22az2xc9GmFLUdga3NAZPdHC/6GGj8IOsJXu7m8Q/PaxMYEed2QHzFmZjGmYNjNCXAgdf7swXAtbCHYW6Pao7xUVRihzRkdQQvk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597049; c=relaxed/simple;
bh=bfoLz0rtrUNmPt9r/OLCwo6IgYNI5b002SGrw2tPjLk=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=okowtO05bM7bEbI9VR/KyqwBOfWeRFXVtA5o431MKWCyyfqurjOTurtoyq6HL4l1gmm9D5T9xlyD+GkEPtTQITZY25EzVpzKJ1P14kMFH/BJhu7DXTx0aZD1MKuppo1ZZ+oLgsc1NePM91eAdMNXhhXK6m3d6PvKGdlqAlEM0SA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=TApjsBvd; arc=none smtp.client-ip=209.85.214.169
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-22e09f57ed4so26487255ad.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597046; x=1749201846; 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=xIkeShPRKlS37USVcPnC1/eAh/CEn8XdgrvHCexPAXg=;
b=TApjsBvdd2UMnegdcA/sw2j5ap/0mqt1O3u9se8yM9g5x+AlEdFFx7UU25GZUEPBrM
vF1OIIWeEq9pzO+Oiwb2+XcvcmqiP4KZQlEnTdFMGEzyDJ9BteXingHJYEkT5rvH46Rt
l7uwm16k4QB1ywDdb2TzUpqyFfRlOOSXHA027YgHijqXAoK+16ZmHe5gW3yDJ8sZuUh+
lU6YuSt55ldtfFx3rKFHBq0pKQmftilo3XK9vTTQZjPKYiI37KnOMdh3urS26V/KqmKq
iMxBpH0kiiOGOWJx+U5yN3T/LMNiXzkzECtApbQELj7FFp1BwW0jJQN+UiSgAE0enSf7
aVxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597046; x=1749201846;
h=content-transfer-encoding:mime-version:message-id:date:subject:cc
:to:from:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=xIkeShPRKlS37USVcPnC1/eAh/CEn8XdgrvHCexPAXg=;
b=vvzvNbVuj5bsSB58Y1lZ4CZCCEZ6x4Rtx7nOIvkeEnYBDw0aEL+X/rLSycESKw2WNT
iobEMloXKneRUSkGL7VNADuqJ5vAHxnQsMm0C7e3PdjzzZJtzvhDEQ/TJuL7qdyyB25S
ZGo9uXcFAkkQ3jOPOjIzSWWKDoQ+k8hKYtsIf/UyMWfi7r4ccEk7Cqb2JplXzI5jYLLe
NPeOKmvII032T3C7yNIvq9XWUVfxYtC8o3yPY1hv7xApXIC6jK08ILtTkUE9ukPX87H3
uGM7e26/Srz6aAEAxbBYmeByUuE/nnAWcH90zWaT6g3TybJ5JWAfzSBWVlKypicVerra
mu1A==
X-Forwarded-Encrypted: i=1; AJvYcCUYga7uJ3aWc0cosSoqNCIml3TphMKbLo3mGaYZZvsDjyKVoMIt58iYNw54hlO57eQyyV6SoHqidqCxxJ4=@vger.kernel.org
X-Gm-Message-State: AOJu0Yyj+8vhOkbVXMsnE/1tjyRbdxzavDE6Foy93PnyLSfFPHtbngKC
71JGbrwYET/oov9s4Tuao+OVg0oQAdLZS2MhvbIgHSG+gpHKACZa3twTsUeRxGDNP/o=
X-Gm-Gg: ASbGnctxZ3woSS3/XQhM8foSw49VQG/zTaZ3EIu2NILpb8JJhNOnN8LPYVIBCVKvfWa
v67XH/eWKA57N1ulLDImC3MsARzbHf+SfCw/Cx1B/gWu1RlIJ6QPz2AzrJrHqKAaDsLs8oBi6Nf
mw8dttg6DlhgqQIHyYMy8aAOShVUO19HmK41Zd8vCFTZXrmezMowmlTtbEx6j1yMS5AMHTwmiv0
VBzZZFnN6OXjBDoA5fUVjwWz37bMghgk7Uxt08XlAwJKSYCXgMPCdQji2O7d4ee4kIRFyfAEXJB
7uL13M14xqRw0JV9zBgK/1x280nPoAo5vJbe71SWGMZ4CUBXPphZSmVMhwhuInfyo/j2sUhcazc
tmQ==
X-Google-Smtp-Source: AGHT+IHCH599oXAEUYNU0GNXy8bBTUxRQinYHHXmUoGoX7uMtkqXRXPYME/P+Uz+v9cbnxn9jl/p0g==
X-Received: by 2002:a17:902:f70f:b0:22e:491b:20d5 with SMTP id d9443c01a7336-2352b790294mr34633575ad.26.1748597046039;
Fri, 30 May 2025 02:24:06 -0700 (PDT)
Received: from localhost.localdomain ([203.208.189.6])
by smtp.gmail.com with ESMTPSA id d9443c01a7336-23506bc88a7sm24549685ad.39.2025.05.30.02.24.02
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:24:05 -0700 (PDT)
From: lizhe.67@xxxxxxxxxxxxx
To: akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
jgg@xxxxxxxx,
jhubbard@xxxxxxxxxx,
peterx@xxxxxxxxxx
Cc: linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
muchun.song@xxxxxxxxx,
lizhe.67@xxxxxxxxxxxxx
Subject: [PATCH] gup: optimize longterm pin_user_pages() for large folio
Date: Fri, 30 May 2025 17:23:51 +0800
Message-ID: <20250530092351.32709-1-lizhe.67@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.45.2
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
From: Li Zhe <lizhe.67@xxxxxxxxxxxxx>
In the current implementation of the longterm pin_user_pages() function,
we invoke the collect_longterm_unpinnable_folios() function. This function
iterates through the list to check whether each folio belongs to the
"longterm_unpinnabled" category. The folios in this list essentially
correspond to a contiguous region of user-space addresses, with each folio
representing a physical address in increments of PAGESIZE. If this
user-space address range is mapped with large folio, we can optimize the
performance of function pin_user_pages() by reducing the number of if-else
branches and the frequency of memory accesses using READ_ONCE. This patch
leverages this approach to achieve performance improvements.
The performance test results obtained through the gup_test tool from the
kernel source tree are as follows. We achieve an improvement of over 75%
for large folio with pagesize=2M. For normal page, we have only observed
a very slight degradation in performance.
Without this patch:
[root@localhost ~] ./gup_test -HL -m 8192 -n 512
TAP version 13
1..1
# PIN_LONGTERM_BENCHMARK: Time: get:13623 put:10799 us#
ok 1 ioctl status 0
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
[root@localhost ~]# ./gup_test -LT -m 8192 -n 512
TAP version 13
1..1
# PIN_LONGTERM_BENCHMARK: Time: get:129733 put:31753 us#
ok 1 ioctl status 0
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
With this patch:
[root@localhost ~] ./gup_test -HL -m 8192 -n 512
TAP version 13
1..1
# PIN_LONGTERM_BENCHMARK: Time: get:3386 put:10844 us#
ok 1 ioctl status 0
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
[root@localhost ~]# ./gup_test -LT -m 8192 -n 512
TAP version 13
1..1
# PIN_LONGTERM_BENCHMARK: Time: get:131652 put:31393 us#
ok 1 ioctl status 0
# Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Li Zhe <lizhe.67@xxxxxxxxxxxxx>
---
mm/gup.c | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 84461d384ae2..8c11418036e2 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -2317,6 +2317,25 @@ static void pofs_unpin(struct pages_or_folios *pofs)
unpin_user_pages(pofs->pages, pofs->nr_entries);
}
+static struct folio *pofs_next_folio(struct folio *folio,
+ struct pages_or_folios *pofs, long *index_ptr)
+{
+ long i = *index_ptr + 1;
+ unsigned long nr_pages = folio_nr_pages(folio);
+
+ if (!pofs->has_folios)
+ while ((i < pofs->nr_entries) &&
+ /* Is this page part of this folio? */
+ (folio_page_idx(folio, pofs->pages[i]) < nr_pages))
+ i++;
+
+ if (unlikely(i == pofs->nr_entries))
+ return NULL;
+ *index_ptr = i;
+
+ return pofs_get_folio(pofs, i);
+}
+
/*
* Returns the number of collected folios. Return value is always >= 0.
*/
@@ -2324,16 +2343,12 @@ static void collect_longterm_unpinnable_folios(
struct list_head *movable_folio_list,
struct pages_or_folios *pofs)
{
- struct folio *prev_folio = NULL;
bool drain_allow = true;
- unsigned long i;
-
- for (i = 0; i < pofs->nr_entries; i++) {
- struct folio *folio = pofs_get_folio(pofs, i);
+ long i = 0;
+ struct folio *folio;
- if (folio == prev_folio)
- continue;
- prev_folio = folio;
+ for (folio = pofs_get_folio(pofs, 0); folio;
+ folio = pofs_next_folio(folio, pofs, &i)) {
if (folio_is_longterm_pinnable(folio))
continue;
--
2.20.1
Return-Path: <linux-kernel+bounces-667845-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 551A241E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:24:31 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 6B8597A3D38
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:23:12 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 641CA220686;
Fri, 30 May 2025 09:24:13 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 97C2621E0BB
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:24:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597053; cv=none; b=F+aNgizpGCXk4ok8Od27RRI0Y2Any6kWoC//U1c4c3F/qrV204dSjao1QLWaWIL+fkSz4Dyhp2NPv0D2RMRCxSKvJBxizSgnNv7q2AbD6ERaLG0qI1sly/7ng1TIeTo7x39CP61nCBwQK4ZVo6kxVyvItlvAsoVCJIp9WzYVNFw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597053; c=relaxed/simple;
bh=fnG+0XDws3NnDGYdrEF+fT5VwwoGblIyqeGEyFrxjhA=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=S4mLIO9opXquj1q/uxxo4BuXlOgBg/FPT6FdEXhGclav2osYmPoz7S98leo6KWRDmoHTMcPlw5EW1eKA2s21SAfCAwEs6IqSdtEHPp7dUMOEgmepN1GzO4GGrCXVzsIWYCnEv5hFq7h3D4zVJh2P8ie5OJNHmKrdUCUTR1hWFSo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4ED8416F2;
Fri, 30 May 2025 02:23:54 -0700 (PDT)
Received: from MacBook-Pro.blr.arm.com (unknown [10.164.18.49])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id DF2DC3F5A1;
Fri, 30 May 2025 02:24:04 -0700 (PDT)
From: Dev Jain <dev.jain@xxxxxxx>
To: dev.jain@xxxxxxx
Cc: Liam.Howlett@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
catalin.marinas@xxxxxxx,
david@xxxxxxxxxx,
gshan@xxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
mhocko@xxxxxxxx,
rppt@xxxxxxxxxx,
steven.price@xxxxxxx,
surenb@xxxxxxxxxx,
suzuki.poulose@xxxxxxx,
vbabka@xxxxxxx,
will@xxxxxxxxxx,
ryan.roberts@xxxxxxx,
yang@xxxxxxxxxxxxxxxxxxxxxx,
anshuman.khandual@xxxxxxx
Subject: Re: [PATCH 0/3] Enable huge-vmalloc permission change
Date: Fri, 30 May 2025 14:54:00 +0530
Message-Id: <20250530092400.19586-1-dev.jain@xxxxxxx>
X-Mailer: git-send-email 2.39.3 (Apple Git-146)
In-Reply-To: <20250530090407.19237-1-dev.jain@xxxxxxx>
References: <20250530090407.19237-1-dev.jain@xxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Brilliant, after running get_maintainers I forgot to Cc the
most imp people for this :( +Yang and Ryan, along with
Anshuman.
Return-Path: <linux-kernel+bounces-667846-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id E9FBC41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:24:39 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4397E4A4607
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:24:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 46EDA21D3F0;
Fri, 30 May 2025 09:24:21 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 35BDC1EB5D8
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:24:18 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597060; cv=none; b=C7+LOjWQe+59977kSMAOCsV81qGAiiBu6djAsgit7IukIEPt8Ow5yHklbCSxVb/4uQKpMEgMYbcm4++iIukF+hi3MO4TUWeddq48ZMGbcdgFDfKycsESz7Bk/IFYRpd3xJ7fm8OzkvrjKY0IWyei2Qh986/IuzcfiqC1cSZhZMs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597060; c=relaxed/simple;
bh=q0oKYUaOb6DCXRw2x89nqGnsoQzpjfrzOlrmFXcemq8=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=Cac94O1hRaXnAS18gEpJ5osStqJPVqlbkkwFSpiqq3OEeCb3PtIvQo3k43H0Sw4bmePjcqr6Rvmz+wQ2mb2LYA8r8IWJLc56v11djv7Fx4zP7ChO629AGthVdS4Fjy5bSNv6Sw4Yi6IB3wPPl/45FGTPRpuKFWYW4WPGIPy2bPo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 050CE16F2;
Fri, 30 May 2025 02:24:02 -0700 (PDT)
Received: from localhost (e132581.arm.com [10.1.196.87])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1B0A93F5A1;
Fri, 30 May 2025 02:24:17 -0700 (PDT)
Date: Fri, 30 May 2025 10:24:13 +0100
From: Leo Yan <leo.yan@xxxxxxx>
To: Yuanfang Zhang <quic_yuanfang@xxxxxxxxxxx>
Cc: Suzuki K Poulose <suzuki.poulose@xxxxxxx>,
Mike Leach <mike.leach@xxxxxxxxxx>,
James Clark <james.clark@xxxxxxxxxx>,
Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>,
kernel@xxxxxxxxxxxxxxxx, coresight@xxxxxxxxxxxxxxxx,
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH] coresight-tpdm: add trace_id sysfs node
Message-ID: <20250530092413.GA666854@xxxxxxxxxxxxxxx>
References: <20250530-showtraceid-v1-1-2761352cf7b4@xxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250530-showtraceid-v1-1-2761352cf7b4@xxxxxxxxxxx>
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 03:29:14PM +0800, Yuanfang Zhang wrote:
> The trace ID of TPMD is the trace ID of the TPDA or TNOC
> which it is connected to, this change adds trace_id sysfs
> node to expose this trace id to userspace.
>
> Signed-off-by: Yuanfang Zhang <quic_yuanfang@xxxxxxxxxxx>
> ---
> drivers/hwtracing/coresight/coresight-tpdm.c | 16 ++++++++++++++++
> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index 7214e65097ec9ac69f6c7c9278bcd28d25945c9e..8a5d115157924f39b09f8e3005827d7d64aa376c 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -497,6 +497,9 @@ static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
>
> __tpdm_enable(drvdata);
> drvdata->enable = true;
> +
> + if (path)
> + drvdata->traceid = path->trace_id;
In Sysfs mode, the core layer calls coresight_path_assign_trace_id().
Eventually, the source driver's trace_id() callback is invoked to
retrieve the trace ID.
I don't see TPDM driver provides trace_id() callback, so here
"path->trace_id" is an invalid value?
Please refer to STM driver (see stm_trace_id()) for this part.
> spin_unlock(&drvdata->spinlock);
>
> dev_dbg(drvdata->dev, "TPDM tracing enabled\n");
> @@ -554,6 +557,7 @@ static void tpdm_disable(struct coresight_device *csdev,
> __tpdm_disable(drvdata);
> coresight_set_mode(csdev, CS_MODE_DISABLED);
> drvdata->enable = false;
> + drvdata->traceid = 0;
Seems to me, a source device can reserve a trace ID until the module
is unloaded. So it is not necessary to clean up trace ID when
disabling it.
BTW, my understanding is that you are trying to allocate a trace ID in
the TPDM driver and propagate the ID to the TNOC driver. It would be
helpful if you could send the patches in one go, we can review it in
global picture.
Leo.
> spin_unlock(&drvdata->spinlock);
>
> dev_dbg(drvdata->dev, "TPDM tracing disabled\n");
> @@ -655,9 +659,21 @@ static ssize_t integration_test_store(struct device *dev,
> }
> static DEVICE_ATTR_WO(integration_test);
>
> +static ssize_t traceid_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> + val = drvdata->traceid;
> + return sprintf(buf, "%#lx\n", val);
> +}
> +static DEVICE_ATTR_RO(traceid);
> +
> static struct attribute *tpdm_attrs[] = {
> &dev_attr_reset_dataset.attr,
> &dev_attr_integration_test.attr,
> + &dev_attr_traceid.attr,
> NULL,
> };
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
> index b117543897344b689f666f6890cabb59c8ee4869..e12a64f265daa86f1b82fa3640e271e8386f99af 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
> @@ -300,6 +300,7 @@ struct cmb_dataset {
> * @cmb Specifics associated to TPDM CMB.
> * @dsb_msr_num Number of MSR supported by DSB TPDM
> * @cmb_msr_num Number of MSR supported by CMB TPDM
> + * @traceid: Value of the current ID for this component.
> */
>
> struct tpdm_drvdata {
> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
> struct cmb_dataset *cmb;
> u32 dsb_msr_num;
> u32 cmb_msr_num;
> + u8 traceid;
> };
>
> /* Enumerate members of various datasets */
>
> ---
> base-commit: 94305e83eccb3120c921cd3a015cd74731140bac
> change-id: 20250523-showtraceid-2df91c89be8f
>
> Best regards,
> --
> Yuanfang Zhang <quic_yuanfang@xxxxxxxxxxx>
>
> _______________________________________________
> CoreSight mailing list -- coresight@xxxxxxxxxxxxxxxx
> To unsubscribe send an email to coresight-leave@xxxxxxxxxxxxxxxx
Return-Path: <linux-kernel+bounces-667847-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id CCDDC41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:25:35 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id AA4729E2706
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:25:14 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 134FA21D5AF;
Fri, 30 May 2025 09:25:30 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="jV0apYW3"
Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199])
(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 A178F1E2607;
Fri, 30 May 2025 09:25:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597129; cv=none; b=Vzf+lhhcDRixN4weTg4nDdSXxOZf4mVszmNjExDup9xu9dAUuYkyxwDofSW97GenoFRpbGGlkjkho0jyKL3tUCyJ+JTtFng+1rcLFNGHWWGojy6ciqVpXvWF5q7Fm9aubr1qq1ZGfDFafkO3h1JTfNauuXc+UYh4xvVBm5gMkv8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597129; c=relaxed/simple;
bh=VQGmwyM6dLX+gLYISfq5UOreX82SGJdDBvUZapXWo04=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=LnamftOTNKbg4g9KKO3yQmb9IHGmG8noOzIXeZRae6nGdoZB7oyRTADdg4o3LxGcBevxQqwHIEwoI6eP9ZrM5/0IF8/GENSmjHMvykkAWctH1LmPnzrLJVlbo/kESKDJe0YTLXBNbq5Q5N32dBV2vfIPJ1sP1FHguyHZbHDx70Y=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=jV0apYW3; arc=none smtp.client-ip=90.155.92.199
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org
Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
Content-Transfer-Encoding:Content-ID:Content-Description;
bh=gR91zQSzqCbc3p6LvARTFu1cbopw2P782WLK55P4y9w=; b=jV0apYW3ub6N06ZD9T9v3FuV5K
8OCyuhQR5SUnrJzr922AI1qgToxXFgO6EzLmuCrDcA/SAGntoV2dm5WIgeh03WDK7kBzT1wX8R5t6
bkw5aawChHySMdH/PAEr65qjbXWItpI1HhRp+G7EG9yqA7dJKsP+mPNGqnKBXVklbZLjojJ17Pm+F
9F7RLHZ8ySEobL386mYcnQHYD+DdNM+V8SbXXa0fk4RyzIclP0yJuqJME0Idb/NGKNZgONhF/3fuL
RRTe6GPIIVatAgaezKjvjGVe0khmr6MN/kUZHdkBUmmUOGeMaQ5WSdeWRT7gkRXHBcvQkSyDC8K2m
fPb95lpw==;
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net)
by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
id 1uKvzA-00000000EJS-2hvT;
Fri, 30 May 2025 09:25:08 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
id 1C03B30066A; Fri, 30 May 2025 11:25:08 +0200 (CEST)
Date: Fri, 30 May 2025 11:25:07 +0200
From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
To: Kees Cook <kees@xxxxxxxxxx>
Cc: Alessandro Carminati <acarmina@xxxxxxxxxx>,
linux-kselftest@xxxxxxxxxxxxxxx,
Dan Carpenter <dan.carpenter@xxxxxxxxxx>,
Daniel Diaz <daniel.diaz@xxxxxxxxxx>,
David Gow <davidgow@xxxxxxxxxx>,
Arthur Grillo <arthurgrillo@xxxxxxxxxx>,
Brendan Higgins <brendan.higgins@xxxxxxxxx>,
Naresh Kamboju <naresh.kamboju@xxxxxxxxxx>,
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>,
Maxime Ripard <mripard@xxxxxxxxxx>,
Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>,
Daniel Vetter <daniel@xxxxxxxx>, Guenter Roeck <linux@xxxxxxxxxxxx>,
Alessandro Carminati <alessandro.carminati@xxxxxxxxx>,
Jani Nikula <jani.nikula@xxxxxxxxx>,
Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxx>,
Josh Poimboeuf <jpoimboe@xxxxxxxxxx>,
Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>,
Linux Kernel Functional Testing <lkft@xxxxxxxxxx>,
dri-devel@xxxxxxxxxxxxxxxxxxxxx, kunit-dev@xxxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning
backtraces
Message-ID: <20250530092507.GC21197@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20250526132755.166150-1-acarmina@xxxxxxxxxx>
<20250526132755.166150-2-acarmina@xxxxxxxxxx>
<202505281546.DB9D9029@keescook>
<20250529090219.GA24938@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
<202505291033.E7E3E6C@keescook>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <202505291033.E7E3E6C@keescook>
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Thu, May 29, 2025 at 10:46:15AM -0700, Kees Cook wrote:
> Doing it on the other end doesn't look great (see the other reply). I was
> suggesting it's not on fast path because the added code is a dependant
> conditional following an "unlikley" conditional. But if you wanted to
> push it totally out of line, we'd likely need to pass __func__ into
> warn_slowpath_fmt() and __warn_printk(), and then have __warn_printk()
warn_slowpath_fmt() already uses buildin_return_address(0), and then it
can use kallsyms to find the symbol name. No need to pass __func__ as a
string.
> return bool to make the call to __WARN_FLAGS() conditional. e.g.:
>
> - warn_slowpath_fmt(__FILE__, __LINE__, taint, arg); \
> + warn_slowpath_fmt(__FILE__, __LINE__, __func__, taint, arg); \
>
> and:
>
> - __warn_printk(arg); \
> - __WARN_FLAGS(BUGFLAG_NO_CUT_HERE | BUGFLAG_TAINT(taint));\
> + if (__warn_printk(__func__, arg)) \
> + __WARN_FLAGS(BUGFLAG_NO_CUT_HERE | BUGFLAG_TAINT(taint));\
>
> But it still leaves bare __WARN unhandled...
Nah, don't propagate, just eat the __WARN and handle things in
__report_bug(), which is where they all end up.
But the real purpose here seems to be to supress printk output, so why
not use 'suppress_printk' ?
Return-Path: <linux-kernel+bounces-667848-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 3E79A41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:26:19 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 7045A4A51AE
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:26:20 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 0CA9521CA05;
Fri, 30 May 2025 09:26:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="NbjyMilJ"
Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44])
(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 AA7F61E2607
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:26:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597173; cv=none; b=u1xtArtkyauZst0jGYC7r/iAjOMEH2PwYheDVE0GpF0Zfcjhu7P4faxak4ivPeDPxeWHMlra16+f6cbpSmFHgNVrVz2HYsQjzg4l0f6z7HNXgtAIit6xmlX9HYngKlOMbJMl8ZAgEedBZSRYARXA930beFDR5aJ34ee3Yh5d9Lg=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597173; c=relaxed/simple;
bh=/NFAes3Xowf8pKG8nRQbR/7RVUBFs50cJ5eGxmQ+XCA=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=jkT/I0nZeilOoEepacrqmk2fsKpBmQrYEuqmxwIcxFY6HTOTJ019RlyhLldh952RAgEDtpGN3zJ1VtXy8JvkSZsQNf1UdcNoFrTm8COCEU2G18A3DkSTbSO5FS7sqrqt6OElrqeyD5/bTaTW0DxF45LcU3kVnXOKdxHmN0lMKjQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=NbjyMilJ; arc=none smtp.client-ip=209.85.128.44
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com
Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-441c99459e9so11772055e9.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:26:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=suse.com; s=google; t=1748597168; x=1749201968; darn=vger.kernel.org;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to;
bh=WBD4FC4JP/aK9PaRJ0xxbq96AkGHxNwwAgjyDa2KnPU=;
b=NbjyMilJHJQ2qlaSm7NcKt0tqpm9xhMc/08N64/B8zONv5yxkwUsnumTXY++wdcYn1
24iUkWbXU6xdM9ttful4NtrEqsaACZwuUFpqWWr+bB5+evtC46KD/s5GSV2ep+PF/QRW
Kj+j1Bl6l0vuxCMwb0YY5z1jIeHQ+hUbRTHjeTWgFAtOWb2WkXFLzhIpI//IlUHv0ZdW
ppzLr1hPJjHF9ARSOUJfxFRFISIHfLs+jHwtpgaVUfIPQ8IgG4+gOqunVWE8jfoCowbI
PYeSTlHf2ZMNZ/5XZmANaT8FB6JSmQuuWFj6WwXFepmcu9yMZmmGDSBUcXoshvm4fE75
1Pyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597168; x=1749201968;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=WBD4FC4JP/aK9PaRJ0xxbq96AkGHxNwwAgjyDa2KnPU=;
b=NvqCfwPe1nOvPcn5n7o88NXZAQrgwvMxGnQCz3N50iHqRsEeqYlqQ3wAaaJMrQqHSd
Zq8+WzPH4Kvpx122cEcaJZQd4+zHHB7RjbYfxFzeZwUrfCqulJ/YRtX0VRF7/lTGc/36
W2gfMN16atyq6Nl2ZpYMKuxVyrrufkPzpMiMkL7MSNWtd1uU19/h8FFYRAKVS0PU/GuQ
LRKcUVhuDUWRIjt2ddo2y13WI6ZrJBBbeSrLwyeCaZwUKntoMJ3dfUCEQbJbOou59JzE
NsvyPxrmKs/Mimr98/6wS6bAAmAGCzZo3c+1/vz+As52lRKQ+P2d4vpKfRKdpiOUDRO4
X9Cg==
X-Forwarded-Encrypted: i=1; AJvYcCVWeA0NV7mGDHWUIGQwHDT+BE9+7hdaKENNfBQwuzntvFI814cPic524efy6tjiVsTb4/NZeRhVbfn5yvU=@vger.kernel.org
X-Gm-Message-State: AOJu0YwfRU5EeckyrZQblCyGFEv72xgDoB9Ij42B87tWP39PZhHz7Lq1
CAEElJS/WQx3+ul+VUWK3ceJILRt3+4MrNVN5BswkYkfkQ/7eBUVY1BAkXDeWmz2gGQ=
X-Gm-Gg: ASbGncu2rYJ0BlgHvNmUfEL8Iq46lZ8W/XIASu3y9uDSxKShx7LyrRZbN8mh2lf3VFw
U9dFInoElqtsd3f1wf+g2XbFzfrBojPJi76nVxC6gn2u25UFHbVCT7QBWQw/MGp8NmGZBHgY4aE
WHOsAfkgS0piLFDWf/NHHkNXnAgcWAhzfVVCUrG3Mb/69sU/FtYHo2v+oKjPXzssmnEzEWAYiAk
xLjJo4dP4am7edliuDBOp9ZLJmTm2hBwl8U5MbsI6CUvr6TFtqLc5YNKmbgb0q4R9+tZDXc274k
t99ejWIYlNnwbZct0x9UVcBh+XAP5GgVe+J5BfH4Qr/oF5t5GsvgPWtheyV9+law
X-Google-Smtp-Source: AGHT+IHy+f9++7ZGOrh9ZvJit3DYw9n8FLen71ac6q+FlrswfnOM19Wz+9AOWt0fC9IjOkvfOFAdwA==
X-Received: by 2002:a05:600c:5249:b0:43c:f81d:34 with SMTP id 5b1f17b1804b1-450d64d3fbemr26298075e9.9.1748597167912;
Fri, 30 May 2025 02:26:07 -0700 (PDT)
Received: from localhost (109-81-89-112.rct.o2.cz. [109.81.89.112])
by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-450d7fa2278sm12794105e9.12.2025.05.30.02.26.07
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 30 May 2025 02:26:07 -0700 (PDT)
Date: Fri, 30 May 2025 11:26:06 +0200
From: Michal Hocko <mhocko@xxxxxxxx>
To: David Hildenbrand <david@xxxxxxxxxx>
Cc: Baoquan He <bhe@xxxxxxxxxx>, Donald Dutile <ddutile@xxxxxxxxxx>,
Jiri Bohac <jbohac@xxxxxxx>, Vivek Goyal <vgoyal@xxxxxxxxxx>,
Dave Young <dyoung@xxxxxxxxxx>, kexec@xxxxxxxxxxxxxxxxxxx,
Philipp Rudo <prudo@xxxxxxxxxx>, Pingfan Liu <piliu@xxxxxxxxxx>,
Tao Liu <ltao@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
David Hildenbrand <dhildenb@xxxxxxxxxx>
Subject: Re: [PATCH v2 0/5] kdump: crashkernel reservation from CMA
Message-ID: <aDl5rpqCUyf7nX2M@tiehlicka>
References: <04904e86-5b5f-4aa1-a120-428dac119189@xxxxxxxxxx>
<427fec88-2a74-471e-aeb6-a108ca8c4336@xxxxxxxxxx>
<Z8Z/gnbtiXT9QAZr@MiWiFi-R3L-srv>
<e9c5c247-85fb-43f1-9aa8-47d62321f37b@xxxxxxxxxx>
<aDgQ0lbt1h5v0lgE@tiehlicka>
<a1a5af90-bc8a-448a-81fa-485624d592f3@xxxxxxxxxx>
<aDlsF5tAcUxo4VgT@tiehlicka>
<e0f7fc1e-2227-4c6b-985a-34a697a52679@xxxxxxxxxx>
<aDl1ViMpK_6q_z06@tiehlicka>
<04a49de5-eb79-431b-ba5b-eae2536781c6@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <04a49de5-eb79-431b-ba5b-eae2536781c6@xxxxxxxxxx>
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri 30-05-25 11:11:40, David Hildenbrand wrote:
> On 30.05.25 11:07, Michal Hocko wrote:
> > On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
> > > On 30.05.25 10:28, Michal Hocko wrote:
> > [...]
> > > > All that being said I would go with an additional parameter to the
> > > > kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
> > > > otherwise. That would make the optimized behavior opt in, we do not need
> > > > to support all sorts of timeouts and also learn if this is not
> > > > sufficient.
> > > >
> > > > Makes sense?
> > >
> > > Just so I understand correctly, you mean extending the "crashkernel=" option
> > > with a boolean parameter? If set, e.g., wait 1s, otherwise magic number 10?
> >
> > crashkernel=1G,cma,cma_sane_dma # no wait on transition
>
> But is no wait ok? I mean, any O_DIRECT with any device would at least take
> a bit, no?
>
> Of course, there is a short time between the crash and actually triggerying
> kdump.
This is something we can test for and if we need a short timeout in this
case as well then it is just trivial to add it. I am much more
concerned about those potentially unpredictable DMA transfers that could
take too long and it is impossible to test for those and therefore we
need to overshoot.
> > crashkernel=1G,cma # wait on transition with e.g. 10s timeout
>
> In general, would work for me.
>
> --
> Cheers,
>
> David / dhildenb
--
Michal Hocko
SUSE Labs
Return-Path: <linux-kernel+bounces-667849-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 0D4A041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:27:20 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 0A0DF1BA1DAB
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:27:33 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 4E6B821D5AF;
Fri, 30 May 2025 09:27:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="WpoQ9h57"
Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199])
(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 521F028E7;
Fri, 30 May 2025 09:27:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597231; cv=none; b=JdnBE48od39KiDkS7NuPVX2o599/N9OAEGsWSOVEUlRN7KgoKIWMtfcvoHNhKqs7ikdaZTWaPxdlzQiDawAhEQ8r+Fxtx3bVvPwLh9H6gz8EI91crhi5SDspPpYMfO4QW84kzE19sR2wluG83x0SJ2oRa9Oczq2z8DTZWlsO/B8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597231; c=relaxed/simple;
bh=S68uPq17WZaaig3YYau5FbjK8jVtSkT3sV5dlxTcvbw=;
h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
Content-Type:Content-Disposition:In-Reply-To; b=C1F7IoKlkML4T3FBJhuBkTEs3NzWHPcaIbZ+kutgyiLCJQVSQNIFSEFGfJdefTDm1dR5pcCvO7n2YuCv5S+N5zMhv9fev/nWtDe9leO4ctBm+Dx06wUCdWDy15OylDrEAQoby6/B/ffUFpyoCnYdGMi2l28ZPGwnxEyEs7sGaIo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=WpoQ9h57; arc=none smtp.client-ip=90.155.92.199
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org
Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version:
References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:
Content-Transfer-Encoding:Content-ID:Content-Description;
bh=S68uPq17WZaaig3YYau5FbjK8jVtSkT3sV5dlxTcvbw=; b=WpoQ9h57imN1XDky33PL1TodSv
nU41lQXxPIhVXakg1H7t0QzxNN1TqmvTUP9oIsTFOezvvJ7yWTfQlz+t2QBBtYWk1SwdWZ0zw+T9T
KQl22fYC4+NrFD8Bcu/5uAAWoCfOiu6dWRColJ+DrXI6zGBwCl/2x2rwObCx4gvnQD49x2sSQJxQJ
0dTqxQfeVECwhY7qXBAksnDrfgJfw/h7JCaHdhvfp8jej/pVVDgKgt690wRa7OEjePfjyq/wglHyX
27aHCMACf413OMjvmAHdCZ1XclrJ36nRWqdo5D8j36FpkrMi4J8WwMjdU4MT7tcxZDJK8/gtaNj/u
lIqzCukA==;
Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net)
by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux))
id 1uKw0x-00000000EKE-3gbi;
Fri, 30 May 2025 09:27:00 +0000
Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000)
id 733FE30066A; Fri, 30 May 2025 11:26:59 +0200 (CEST)
Date: Fri, 30 May 2025 11:26:59 +0200
From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
To: Alessandro Carminati <acarmina@xxxxxxxxxx>
Cc: linux-kselftest@xxxxxxxxxxxxxxx,
Dan Carpenter <dan.carpenter@xxxxxxxxxx>,
Kees Cook <keescook@xxxxxxxxxxxx>,
Daniel Diaz <daniel.diaz@xxxxxxxxxx>,
David Gow <davidgow@xxxxxxxxxx>,
Arthur Grillo <arthurgrillo@xxxxxxxxxx>,
Brendan Higgins <brendan.higgins@xxxxxxxxx>,
Naresh Kamboju <naresh.kamboju@xxxxxxxxxx>,
Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>,
Maxime Ripard <mripard@xxxxxxxxxx>,
Ville Syrjala <ville.syrjala@xxxxxxxxxxxxxxx>,
Daniel Vetter <daniel@xxxxxxxx>, Guenter Roeck <linux@xxxxxxxxxxxx>,
Alessandro Carminati <alessandro.carminati@xxxxxxxxx>,
Jani Nikula <jani.nikula@xxxxxxxxx>,
Jeff Johnson <jeff.johnson@xxxxxxxxxxxxxxxx>,
Josh Poimboeuf <jpoimboe@xxxxxxxxxx>,
Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>,
Linux Kernel Functional Testing <lkft@xxxxxxxxxx>,
dri-devel@xxxxxxxxxxxxxxxxxxxxx, kunit-dev@xxxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx
Subject: Re: [PATCH v5 1/5] bug/kunit: Core support for suppressing warning
backtraces
Message-ID: <20250530092659.GD21197@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20250526132755.166150-1-acarmina@xxxxxxxxxx>
<20250526132755.166150-2-acarmina@xxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250526132755.166150-2-acarmina@xxxxxxxxxx>
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Mon, May 26, 2025 at 01:27:51PM +0000, Alessandro Carminati wrote:
> A helper function, `__kunit_is_suppressed_warning()`, is used to determine
> whether suppression applies. It is marked as `noinstr`, since some `WARN*()`
> sites reside in non-instrumentable sections. As it uses `strcmp`, a
> `noinstr` version of `strcmp` was introduced.
That just sounds all sorts of wrong.
Return-Path: <linux-kernel+bounces-667850-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 48C8D41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:27:36 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 1AA7A3B5B0C
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:27:15 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 67A0E21D5B0;
Fri, 30 May 2025 09:27:30 +0000 (UTC)
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 2E3F121578F
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:27:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597250; cv=none; b=EAnMvDiACaoLd/jTiZX4zp/aoutHLV8HEzG861Vr16Aajl2sAYJyRt3j9/VL7fVRklXd1vJiEB5enLWqLcq3bAUQVD1Gs7UxerXoFoTcBEeQCTMeN01UchsXMiB6s2ABi25lGfRxau7w/Kn1wWNlbfkq5l5QS5TCZNRrn8X4OFg=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597250; c=relaxed/simple;
bh=L4sn98PBegOTbCmdFYDtAkjiTCnK0s2hWxPSgkN9EzA=;
h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=Sae6MpnpNcwNPIboRwWR/m108Ie4pJRu3leFJSrt5/kHmr3fJ/rh9yfnef4u8/Z79yuQ9LrMLPk0E5/z+mTNdK/E2sYFgf7/mIvcxzhp0p0FReLgXbAoMx1yFKAw+Jv1DfndEilFjLxPZztcLaj8ZBWZVL346DjJS7WZW8Dx16k=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com
Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14])
by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0A66D16F2;
Fri, 30 May 2025 02:27:11 -0700 (PDT)
Received: from e129823.cambridge.arm.com (e129823.arm.com [10.1.197.6])
by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 406103F5A1;
Fri, 30 May 2025 02:27:25 -0700 (PDT)
From: Yeoreum Yun <yeoreum.yun@xxxxxxx>
To: catalin.marinas@xxxxxxx,
will@xxxxxxxxxx,
geert@xxxxxxxxxxxxxx,
broonie@xxxxxxxxxx,
mcgrof@xxxxxxxxxx,
joey.gouly@xxxxxxx,
kristina.martsenko@xxxxxxx,
rppt@xxxxxxxxxx,
pcc@xxxxxxxxxx,
bigeasy@xxxxxxxxxxxxx,
ptosi@xxxxxxxxxx,
mark.rutland@xxxxxxx,
james.morse@xxxxxxx
Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
Yeoreum Yun <yeoreum.yun@xxxxxxx>
Subject: [PATCH] arm64/trap: fix broken ct->nmi_nesting when die() is called in a kthread
Date: Fri, 30 May 2025 10:27:23 +0100
Message-Id: <20250530092723.3307630-1-yeoreum.yun@xxxxxxx>
X-Mailer: git-send-email 2.34.1
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
When a kernel thread hits BUG() outside of an interrupt handler and
panic_on_oops is not set, it exits via make_task_dead(), which is called by die().
In this case, the nmi_nesting value in context_tracking becomes
inconsistent because the proper context tracking exit functions are not reached.
Hereâ??s an example scenario on arm64:
1. A kernel thread hits the BUG() macro outside an interrupt handler,
and panic_on_oops is not set (ct->nmi_nesting == CT_NESTING_IRQ_NONIDLE).
2. The exception handler jumps to el1_dbg() and calls arm64_enter_el1_dbg(),
which invokes ct_nmi_enter(). (ct->nmi_nesting == CT_NESTING_IRQ_NONIDLE + 2)
3. bug_handler() runs, and if the bug type is BUG_TRAP_TYPE_BUG, it calls die().
4. die() then calls make_task_dead(), which terminates the kernel thread and
schedules another taskâ??assume this is the idle_task.
5. The idle_task attempts to enter the idle state by calling ct_idle_enter().
However, since the current ct->nmi_nesting value is CT_NESTING_IRQ_NONIDLE + 2,
ct_kernel_exit() triggers a WARN_ON_ONCE() warning.
Because the kernel thread couldnâ??t call the appropriate context tracking exit
function in step 3, the ct->nmi_nesting value remains incorrect.
This leads to warnings like the following:
[ 7.133093] ------------[ cut here ]------------
[ 7.133129] WARNING: CPU: 2 PID: 0 at kernel/context_tracking.c:127 ct_kernel
[ 7.134157] Modules linked in:
[ 7.134158] not ok 62 kasan_strings
[ 7.134280]
[ 7.134506] CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Tainted: G B D W N
[ 7.134930] Tainted: [B]=BAD_PAGE, [D]=DIE, [W]=WARN, [N]=TEST
[ 7.135150] pstate: 204003c5 (nzCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 7.135441] pc : ct_kernel_exit+0xa4/0xb0
[ 7.135656] lr : ct_kernel_exit+0x1c/0xb0
[ 7.135866] sp : ffff8000829bbd90
[ 7.136011] x29: ffff8000829bbd90 x28: ffff80008224ecf0 x27: 0000000000000004
[ 7.136379] x26: ffff80008228ed30 x25: ffff80008228e000 x24: 0000000000000000
[ 7.137016] x23: f3ff000800a52280 x22: 0000000000000000 x21: ffff00087b6c7408
[ 7.137380] x20: ffff80008224b408 x19: 0000000000000005 x18: 0000000000000000
[ 7.137741] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 7.311316] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 7.311673] x11: 0000000000000000 x10: 0000000000000000 x9 : 4000000000000000
[ 7.312031] x8 : 4000000000000002 x7 : 0000000000000000 x6 : 0000000000000000
[ 7.312387] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000
[ 7.312740] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff8007f947c000
[ 7.313096] Call trace:
[ 7.313210] ct_kernel_exit+0xa4/0xb0 (P)
[ 7.313445] ct_idle_enter+0x14/0x28
[ 7.313666] default_idle_call+0x2c/0x60
[ 7.313902] do_idle+0xec/0x320
[ 7.314104] cpu_startup_entry+0x40/0x50
[ 7.314331] secondary_start_kernel+0x120/0x1a0
This behavior is specific to the arm64 architecture, where ct_nmi_enter()
is called when handling a debug exception.
In contrast, on other architectures, ct_nmi_enter() is not called when
handling BUG().
(i.e) when handling X86_TRAP_UD via handle_invalid_op(), it doesn't call
ct_nmi_enter(). so it doesnâ??t cause any issues
(While irq_entry_enter() does call ct_nmi_enter() for idle tasks,
that doesnâ??t apply to debug exception handling).
To address the issue of a corrupted ct->nmi_nesting value,
add a check before calling make_task_dead() in die().
If the current CPUâ??s ct->nmi_nesting is non-zero and not equal to
CT_NESTING_IRQ_NONIDLE, then ct_nmi_exit() should be called.
Fixes: 2a9b3e6ac69a ("arm64: entry: fix EL1 debug transitions")
Signed-off-by: Yeoreum Yun <yeoreum.yun@xxxxxxx>
---
arch/arm64/kernel/traps.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 529cff825531..9cf03b9ce691 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -227,8 +227,14 @@ void die(const char *str, struct pt_regs *regs, long err)
raw_spin_unlock_irqrestore(&die_lock, flags);
- if (ret != NOTIFY_STOP)
+ if (ret != NOTIFY_STOP) {
+#ifdef CONFIG_CONTEXT_TRACKING_IDLE
+ long nmi_nesting = ct_nmi_nesting();
+ if (nmi_nesting && nmi_nesting != CT_NESTING_IRQ_NONIDLE)
+ ct_nmi_exit();
+#endif
make_task_dead(SIGSEGV);
+ }
}
static void arm64_show_signal(int signo, const char *str)
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}
Return-Path: <linux-kernel+bounces-667851-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id BE0FC41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:27:55 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id C31E01BA1E46
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:08 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 0A62021D5B2;
Fri, 30 May 2025 09:27:51 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FuAW+sf7"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124])
(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 33D1D28E7
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:27:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597269; cv=none; b=Rbw+5qO7sElyIOngoc2gt3fql98ZeCFGYqZJHIGtalIgaYOA74/QHyCKf/6v/vE/RdczMq1SEF0ekiWGSqID1niKWXC2hewvem+WURoadYv6RVEDdIlxzN6nylWE3XbHeegV4ZgRaLTvsUo4RVv8ceJisPKJSRN3KOEHxx/+Z/8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597269; c=relaxed/simple;
bh=2F13+WBGh69tuRqhGjrNAMQtEsMkeasNYqXF2rgVhtA=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=UGpkUCNPGvgkPZV+/17Fw2QHByVOm40VdyG2QovIVwPRZltSb4KDSDjmdRaaUVIOZGDej5NOroo5HC8ZR8Tuw3GcDGRO0lW2cl804dIJvM+rorH86FjtT/uFk8fX0x2ig3IKp5nrJEBVMVUizyIekXXQb4GHankAS9N6HQiF9ic=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FuAW+sf7; arc=none smtp.client-ip=170.10.129.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748597267;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=1PBV9a/LZW4fQlp+cup6+DwAjZlGKxU8VEnOtKkuFIc=;
b=FuAW+sf7sukl+Kq6eafPA69KXov+VO+qJ5dD5Rhq8k13YHtPjNH1akGODQvDKqBKlg0BKV
BlOL8lU7m9wTaZeqzIspLzwugeIdJwW/YD13OBzFQm4xR7DwN7ZbthtQwHNmny/LtutjeN
0A8cEJPnYJq8B1qQ+ZG3jAHoGQcwEWg=
Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com
[209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-443-lLPI-i9JMmqLtPqBGZSUgA-1; Fri, 30 May 2025 05:27:45 -0400
X-MC-Unique: lLPI-i9JMmqLtPqBGZSUgA-1
X-Mimecast-MFC-AGG-ID: lLPI-i9JMmqLtPqBGZSUgA_1748597264
Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-442cdf07ad9so7356615e9.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:27:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597264; x=1749202064;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=1PBV9a/LZW4fQlp+cup6+DwAjZlGKxU8VEnOtKkuFIc=;
b=VGUbSg8tQglKEatKpaZn1pGciIy8iqjoYF1FHEhWu/+i+vQNc6bUH1FzxYFfGm1jzN
gXK2ZZ8DdI+6DdWxHZrIN+g7ZNbtMvWLoqhFVKdFCd5Oz6za8gSOr4Q8BwFpC19ztoYV
1DgV2RmPPG+ckhDFQflesRee9nFfThcAmTuKid+I0carNsuK4KWQa9K20uxBysVnQ5Rb
YJICZufeHSVO1oyHra7xrO+vYrhheg7tpPhrnAKSwWz7iqa7PVrer9sPXIiLq5Ozz082
vjaKofUEMqSvW8ExXcEvM4/n8GRxTfkGJOqArNAefV8bPFlOTFnY9BP/JDgpjdlrpd1Y
3fOQ==
X-Forwarded-Encrypted: i=1; AJvYcCVSqaE8gGGhzSdUW7mBH+cYdJWYBfT0SJzpLk0Pb7MjX9ercli1hTOAkJWD7tcIcRkSzmXskKsK+iM/vbA=@vger.kernel.org
X-Gm-Message-State: AOJu0YyGksc4gR2GhAXD2+w9IYAGIop6IwKn/Ry6aeENSooQByF/DbGB
ZcuTiDGcmPiXUYFNj1VbJV+/oTr2oJ/YVtrFUqgAPVwWBxGgNHPeZzXVYYrZeTKmp8dK+GtNCd0
PJ2rWbmXv9bh+hjq2Nco2Jf5ufFuZ5EdkwIbn8FrZrF2UJcYdvWX0AKdOSu2Yzz0yJg==
X-Gm-Gg: ASbGnct0Z8w+rw8SMTBgTnbZLRRIy7fColX5rAYrACmcbpAwKK9eCad5iqnt04UF60U
5SmfLgKbdFsDNqsOpRQkVFG707kN6WIN5TDAxXIlorhvwsIDy9dOMWOMtd0pzMuUxOlSWJFCnzF
ccfFAwWdrgr8IbTUoevjt4C+nN1ul3N1El8zDZHe2Yz7j10Afvl0A8xaQSeM7vKfdKoVDRrfx7N
pGjJ83hWgq+rYsZWmCU3uhYpdAr/61ScBubSmhpBSnHQAUvwoHpnhcwdXDCa+eEFOAmtWUFbGuL
ZTUzUSZukbW7HF9WvOsxMjnwJOXpe6APom3R7TU+2HqsYyiC1mPan8hxQ0seNLM5h0IuPw+DeUE
xT1EnaEnKoJ6/gHTePhPgRfgmgVlQnTJZeoCvXKM=
X-Received: by 2002:a05:600c:3b8b:b0:442:e9eb:1b48 with SMTP id 5b1f17b1804b1-450d8876132mr12222805e9.24.1748597264268;
Fri, 30 May 2025 02:27:44 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IFQdY6YWefTxM8YvOu7ZkhfBRFXt6xgQbeM3AJW5so2JdhELLq7VspnEked2wUBNMkbAWhI6Q==
X-Received: by 2002:a05:600c:3b8b:b0:442:e9eb:1b48 with SMTP id 5b1f17b1804b1-450d8876132mr12222475e9.24.1748597263789;
Fri, 30 May 2025 02:27:43 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-450d7f8f194sm13143635e9.4.2025.05.30.02.27.42
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 02:27:43 -0700 (PDT)
Message-ID: <9c32dbf6-527f-465b-9010-f5b22cbac075@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:27:42 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [RFC PATCH] mm/mmap: Fix uprobe anon page be overwritten when
expanding vma during mremap
To: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
Cc: Pu Lehui <pulehui@xxxxxxxxxxxxxxx>, Oleg Nesterov <oleg@xxxxxxxxxx>,
mhiramat@xxxxxxxxxx, peterz@xxxxxxxxxxxxx, Liam.Howlett@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx, vbabka@xxxxxxx, jannh@xxxxxxxxxx,
pfalcato@xxxxxxx, linux-mm@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
pulehui@xxxxxxxxxx
References: <13c5fe73-9e11-4465-b401-fc96a22dc5d1@xxxxxxxxxx>
<4cbc1e43-ea46-44de-9e2b-1c62dcd2b6d5@xxxxxxxxxxxxxxx>
<20250526154850.GA4156@xxxxxxxxxx>
<06bd94c0-fefe-4bdc-8483-2d9b6703c3d6@xxxxxxxxxx>
<57533126-eb30-4b56-bc4d-2f27514ae5ad@xxxxxxxxxxxxxxx>
<cba0155e-d2b9-41fa-bc51-f3738ae73cff@xxxxxxxxxx>
<956124be-c73c-4023-9edd-25372f3f865a@xxxxxxxxxxxxxxx>
<ccf359b0-8baa-4209-b2c3-75e3813ca804@xxxxxxxxxx>
<b2dd29b0-aa12-4cb7-9c05-d3a998f7b0da@lucifer.local>
<172df994-7f24-4fbb-876c-4fab22937177@xxxxxxxxxx>
<205f8165-449c-441f-8ee9-58f69d23dbeb@lucifer.local>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <205f8165-449c-441f-8ee9-58f69d23dbeb@lucifer.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 11:03, Lorenzo Stoakes wrote:
> On Fri, May 30, 2025 at 10:50:25AM +0200, David Hildenbrand wrote:
>> On 30.05.25 10:41, Lorenzo Stoakes wrote:
>>> On Fri, May 30, 2025 at 10:33:16AM +0200, David Hildenbrand wrote:
>>>> On 29.05.25 18:07, Pu Lehui wrote:
>>>>>
>>>>> On 2025/5/28 17:03, David Hildenbrand wrote:
>>>>>> On 27.05.25 15:38, Pu Lehui wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> On 2025/5/27 2:46, David Hildenbrand wrote:
>>>>>>>> On 26.05.25 17:48, Oleg Nesterov wrote:
>>>>>>>>> Hi Lehui,
>>>>>>>>>
>>>>>>>>> As I said, I don't understand mm/, so can't comment, but...
>>>>>>>>>
>>>>>>>>> On 05/26, Pu Lehui wrote:
>>>>>>>>>>
>>>>>>>>>> To make things simpler, perhaps we could try post-processing, that is:
>>>>>>>>>>
>>>>>>>>>> diff --git a/mm/mremap.c b/mm/mremap.c
>>>>>>>>>> index 83e359754961..46a757fd26dc 100644
>>>>>>>>>> --- a/mm/mremap.c
>>>>>>>>>> +++ b/mm/mremap.c
>>>>>>>>>> @@ -240,6 +240,11 @@ static int move_ptes(struct
>>>>>>>>>> pagetable_move_control
>>>>>>>>>> *pmc,
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (pte_none(ptep_get(old_pte)))
>>>>>>>>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>>>>>>>>>>
>>>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â /* skip move pte when expanded range has uprobe */
>>>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (unlikely(pte_present(*new_pte) &&
>>>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â vma_has_uprobes(pmc->new, new_addr,
>>>>>>>>>> new_addr +
>>>>>>>>>> PAGE_SIZE)))
>>>>>>>>>> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â continue;
>>>>>>>>>> +
>>>>>>>>>
>>>>>>>>> I was thinking about
>>>>>>>>>
>>>>>>>>> Â Â Â Â Â WARN_ON(!pte_none(*new_pte))
>>>>>>>>>
>>>>>>>>> at the start of the main loop.
>>>>>>>>>
>>>>>>>>> Obviously not to fix the problem, but rather to make it more explicit.
>>>>>>>>
>>>>>>>> Yeah, WARN_ON_ONCE().
>>>>>>>>
>>>>>>>> We really should fix the code to not install uprobes into the area we
>>>>>>>> are moving.
>>>>>>> Alright, so let's try this direction.
>>>>>>>
>>>>>>>>
>>>>>>>> Likely, the correct fix will be to pass the range as well to
>>>>>>>> uprobe_mmap(), and passing that range to build_probe_list().
>>>>>>>
>>>>>>> It will be great. But IIUC, the range we expand to is already included
>>>>>>> when entering uprobe_mmap and also build_probe_list.
>>>>>>
>>>>>> Right, you'd have to communicate that information through all layers
>>>>>> (expanded range).
>>>>>>
>>>>>> As an alternative, maybe we can really call handle_vma_uprobe() after
>>>>>> moving the pages.
>>>>>
>>>>> Hi David,
>>>>>
>>>>> Not sure if this is possible, but I think it would be appropriate to not
>>>>> handle this uprobe_mmap at the source, and maybe we should make it clear
>>>>> that new_pte must be NULL when move_ptes, otherwise it should be an
>>>>> exception?
>>>>
>>>> Yeah, we should ay least document that if we find any non-none pte in the
>>>> range we are moving to, we have a big problem.
>
> By the way I agree with this.
>
>>>>
>>>> I think the main issue is that vma_complete() calls uprobe_mmap() before
>>>> moving the page tables over.
>>>
>>> Well vma_complete() is not _normally_ invoked before moving page tables,
>>> it's mremap that's making things strange :)
>>>
>>> That's why I think my suggested approach of specifically indicating that we
>>> want different behaviour for mremap is a reasonable one here, as it special
>>> cases things for this case.
>>>
>>> However...
>>>
>>>>
>>>> If we could defer the uprobe_mmap() call, we might be good.
>>>>
>>>> The entry point is copy_vma_and_data(), where we call copy_vma() before
>>>> move_page_tables().
>>>>
>>>> copy_vma() should trigger the uprobe_mmap() through vma_merge_new_range().
>>>>
>>>> I wonder if there might be a clean way to move the uprobe_mmap() out of
>>>> vma_complete(). (or at least specify to skip it because it will be done
>>>> manually).
>>>
>>> ...I would also love to see some means of not having to invoke
>>> uprobe_mmap() in the VMA code, but I mean _at all_.
>>>
>>> But that leads into my desire to not do:
>>>
>>> if (blah blah)
>>> some_specific_hardcoded_case();
>>>
>>> I wish we had a better means of hooking stuff like this.
>>>
>>> However I don't think currently we can reasonably do so, as in all other
>>> merge cases we _do_ want to invoke it.
>>
>> "all other" -- not so sure.
>>
>> Why would we invoke uprobe when merging VMAs after mprotect, mremap,
>> madvise, ordinary mremap where we are not mapping anything new but just ...
>> merging VMAs?
>>
>> Really, we need to invoke uprobe only when adding new VMAs or extending
>> existing VMAs -- mapping new file ranges some way.
>>
>> Or am I missing something important?
>
> Well, this is where my limited knowledge of uprobe comes in.
Let me try to summarize it:
Essentially, what it does is go over the VMA to find where to install
breakpoints. A breakpoint is essentially faulting in the file page, to
then trigger a COW fault to get an anonymous page instead that we can
modify to ... install the breakpoint.
So wherever we have a breakpoint, we want to have an anonymous page
mapped later.
That is only required when we map a new file range. When ordinarily
merging/splitting/moving, we already called uprobe before and installed
the breakpoints.
Calling uprobe_mmap() when we already installed breakpoints is not
really problematic, only suboptimal.
Calling uprobe_mmap() before moving page tables is bad.
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667852-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id A875441E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:28:07 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 913B99E1EDC
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:27:46 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 568ED22068B;
Fri, 30 May 2025 09:27:56 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jjUUitks"
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 91BB028E7;
Fri, 30 May 2025 09:27:55 +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=1748597275; cv=none; b=HnWTwDXZHJFGwgh+HTLMEycD04/rTcfxglihMj0zpN66e/g9EKZwzjarszbupvq7XIG5e1/sS1EyubLFaNwiT5uYgd3jAVPkn+5omxmdj7gsRxCOpUtxTedh934zvPfYGZdIzqD4YEYMFr8gsx6sGiznrVr1WoQCOVcJWqttMh0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597275; c=relaxed/simple;
bh=RSiqO/kmQ8iZ5K+uJsE1ImfJmQxmaHfrScdUILlX7vw=;
h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
To:Cc:Content-Type; b=Ne+Tz3NdfpZM0stdLc5Yjj5YX5j6RBrW41lyW1IeyXDirRjgo5Wcs9OhDb0lCWUehGzgHbfd2wHKw4smb9GkmDR95B9dxhrsrMmBpSJYAwCA14ciCm8DMDoTVyu1hsOBzD+x5wDPe1QC6shmEC03TrjX/ZSHAvJ1VdGmNKzHHzQ=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jjUUitks; arc=none smtp.client-ip=10.30.226.201
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 227BBC4CEEF;
Fri, 30 May 2025 09:27:55 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
s=k20201202; t=1748597275;
bh=RSiqO/kmQ8iZ5K+uJsE1ImfJmQxmaHfrScdUILlX7vw=;
h=References:In-Reply-To:From:Date:Subject:To:Cc:From;
b=jjUUitksHOEzwX3xq+/GgKAPVOsU+wG6wGPkZvuj2Xfr6xhH+rUbAy+qCZvtwcfVC
iSlvN06+eLala1U8idzdU5UKQcxOGCWJF7N8rgks+wreA7zSa/9leT+kFiwBCDXlgC
mgemYZjiKU23S6MmtRnzXpFM8xzgeXANhRI8GQpvQ8iuo7AE2y1RmoXWWIOZCwsfZb
+nqdk7we2WiMC6n11/N0P91x86NaDn1gUoBHblLblZWQRlIiJtmqmpBbtbA4eDuFuw
pTOfEoLJFaa3WuRfi9uyQjBwgCu8KywzY0pO4D0ZQX3v1DYuypu59UUwgvCNrS6Po3
a1hkbjZbkzHhg==
Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-3fbaa18b810so507149b6e.2;
Fri, 30 May 2025 02:27:55 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCV2lNGzE2glvb6bgU2+im1C4pRqhsV8PN29Z1ax3phVfzTeWYYWsbHIG4MZOAfNhoqM7AlUeRRjl2C/p3U=@vger.kernel.org, AJvYcCWuz6kl/TMARaiiNtTi4JFbtdAhXnUlSz1VNwEHECPycOY6mqp1is5uZ8R3opgz1Y9MbnsgqTlApbE=@vger.kernel.org
X-Gm-Message-State: AOJu0Ywl6gcs1/WujHIjB/uaLMvdKFwPMl4+hwjzkPePvLpBAbg9xFH3
D8BOzwHmIBoNn35zHz+LIHFG+7NTpDr2YV60L5XU9YUZ0/FrbG6m0Lznx995wGc/YtiJ4S8Ncwz
nP38HWy/ADDfHnZ5QE1/Iy3oFFKI8388=
X-Google-Smtp-Source: AGHT+IGJLxY/YP4qQcPSGdC9M+XSOtwoc14LjM91TbppT+2aS41XhEg2kIpcpB3/+sLOP4lhOK2f/pb3lYY/B5ouX6E=
X-Received: by 2002:a05:6820:98b:b0:60b:edbb:1f50 with SMTP id
006d021491bc7-60d52d6db2fmr625648eaf.4.1748597274497; Fri, 30 May 2025
02:27:54 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
References: <2006806.PYKUYFuaPT@xxxxxxxxxxxxx> <20250528131759.GA39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
<CAJZ5v0i=TWMjPKxGa8eT-prV=dtQo=pwys5amcj3QL9qo=EYyQ@xxxxxxxxxxxxxx>
<20250528133807.GC39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAJZ5v0g2+OVdFM-bUCOynNivUc4doxH=ukt9e9Z_nKpoZh6gPA@xxxxxxxxxxxxxx>
<20250528160523.GE39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAJZ5v0jzF19rToJMHhEvU6Zbt3690KWCs-B_0sPR=s9xeRiUnQ@xxxxxxxxxxxxxx>
<20250529085358.GY24938@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAJZ5v0hw1910Gsb57POVhax1hAbEGHa7xksr_FygNd_JL-oeOA@xxxxxxxxxxxxxx>
<20250530080733.GH39944@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <CAJZ5v0irHEZEbZVrd-tiaXBvxM4aD9spJg1cVRcjrDQ0_HMJAg@xxxxxxxxxxxxxx>
In-Reply-To: <CAJZ5v0irHEZEbZVrd-tiaXBvxM4aD9spJg1cVRcjrDQ0_HMJAg@xxxxxxxxxxxxxx>
From: "Rafael J. Wysocki" <rafael@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:27:42 +0200
X-Gmail-Original-Message-ID: <CAJZ5v0gbE1Y5zjD_WbwfXYUco=6gtJHYJrTDy0t+sGkBjdD8pQ@xxxxxxxxxxxxxx>
X-Gm-Features: AX0GCFtXA3TjByyV2Y_Ee8S3152mP4t9FecpBX4C3ns-oPIQRIfIXrWE6bVa4Zk
Message-ID: <CAJZ5v0gbE1Y5zjD_WbwfXYUco=6gtJHYJrTDy0t+sGkBjdD8pQ@xxxxxxxxxxxxxx>
Subject: Re: [PATCH v1 0/2] x86/smp: Fix power regression introduced by commit 96040f7273e2
To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>, x86 Maintainers <x86@xxxxxxxxxx>,
LKML <linux-kernel@xxxxxxxxxxxxxxx>, Linux PM <linux-pm@xxxxxxxxxxxxxxx>,
Len Brown <lenb@xxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Borislav Petkov <bp@xxxxxxx>,
Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>,
Artem Bityutskiy <artem.bityutskiy@xxxxxxxxxxxxxxx>,
"Gautham R. Shenoy" <gautham.shenoy@xxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>,
Todd Brandt <todd.e.brandt@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-6.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Fri, May 30, 2025 at 11:18=E2=80=AFAM Rafael J. Wysocki <rafael@kernel.o=
rg> wrote:
>
> On Fri, May 30, 2025 at 10:07=E2=80=AFAM Peter Zijlstra <peterz@infradead=
.org> wrote:
> >
> > On Thu, May 29, 2025 at 11:38:05AM +0200, Rafael J. Wysocki wrote:
> >
> > > First off, I'm not sure if all of the requisite things are ready then
> > > (sysfs etc.).
> >
> > Pretty much everything is already running at early_initcall(). Sysfs
> > certainly is.
> >
> > > We may end up doing this eventually, but it may not be straightforwar=
d.
> > >
> > > More importantly, this is not a change for 6.15.y (y > 0).
> >
> > Seriously, have you even tried?
> >
> > AFAICT the below is all that is needed. That boots just fine on the on=
e
> > randon system I tried, and seems to still work.
> >
> > And this is plenty small enough to go into 6.15.y
>
> But there is still intel_idle_init() which is device_initcall() ATM
> and this needs to be tested on other arches too.
>
> So not really there, sorry.
BTW, I do think that this is the way to go, but not in a hurry, and if
6.15.y does not include a proper fix for the original issue, this is
not the end of the world.
If it turns out to be unproblematic and all goes well, we may as well
try to put it into 6.16.
> > diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
> > index 0835da449db8..0f25de8081af 100644
> > --- a/drivers/cpuidle/cpuidle.c
> > +++ b/drivers/cpuidle/cpuidle.c
> > @@ -814,4 +814,4 @@ static int __init cpuidle_init(void)
> >
> > module_param(off, int, 0444);
> > module_param_string(governor, param_governor, CPUIDLE_NAME_LEN, 0444);
> > -core_initcall(cpuidle_init);
> > +early_initcall(cpuidle_init);
Return-Path: <linux-kernel+bounces-667853-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 24BEF41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:28:22 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 561077A3FC6
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:27:03 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 56E1D21FF21;
Fri, 30 May 2025 09:28:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="SGjcQHCL"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
(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 AE8F321CA05
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:07 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597289; cv=none; b=HncuIFkxS6tgZ/kP4TRRtNwe+fJv13AzCrUv1bXP/iY7/bcsgUqMeEudQD8C67Z8aQhXbu+WibIK4YsnI9HGx4g7BL+jMUHMjMTLhHaZ3aTxs/amFD7N02uAFH9s04UyFgET6clf1hjqQifu+57t9PG5XJ/VVa+i9S4vcz6KBO0=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597289; c=relaxed/simple;
bh=UPgrN+I2yqTJYCpGaX5IMke5p2FuQ5Fto8LxZ7iAGOE=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=V0i8FWo/wPH+mG5jsrs+tWWpf1Mi/XQiCnJunGVNPfNMBW9BGxm4WPCd0QmhucIHAqY+FwHZ0kUWQN2hGAMs3gvHxbDyCrXqtbEVhTAfieqfuA2zP0Sfo/ixl7LoExVRAqzwxvhOnEhyixTdFmiSKDSkBPO0BSRYBRzBFZPM27g=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=SGjcQHCL; arc=none smtp.client-ip=170.10.133.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748597286;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=MaatFJjQ8egE/8VtOwBSoT6wLagg2lOTiOnjBKEO9pM=;
b=SGjcQHCL9TkEtLRHNl1uYHuBajy8I7QMy0k7jldx/EUuNotLiKKZe15QROdVuAiUg/zl89
EZeU9q1uOKAq9SOB2HHMdDyyXfYshegixlT4mqrJPQfg+2iS7SLBULou1Squom94N0IHe0
Gh5DygbopDp43FJ+9kEfR2W7r8HXZP0=
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com
[209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-442-0gERuKarOW6tGj8GvVESlA-1; Fri, 30 May 2025 05:28:05 -0400
X-MC-Unique: 0gERuKarOW6tGj8GvVESlA-1
X-Mimecast-MFC-AGG-ID: 0gERuKarOW6tGj8GvVESlA_1748597284
Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-3a4f85f31d9so254590f8f.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:28:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597284; x=1749202084;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=MaatFJjQ8egE/8VtOwBSoT6wLagg2lOTiOnjBKEO9pM=;
b=tXjybnQHHjGyYXM1RRqHVsHL5wFO9iZnbswNsRrVVf3llx68ddBCmeThlvPCmU2im6
UKoSo4iNuOf+aJdhera3CuwRsLuZiYGpM1l8YbY8NSUh4jIWmwJnllcTTpvrv/Ko9+PV
Kp6PWKUBoZtZIk6IrYhNYg6+ELkJfdcJxK8nKvqHN/bsDRlWMAZI7Kp07NTDJs5TGFXQ
m6Qd1jS8FCPWZxkvm6WBIs9Qh3yOWsmElxofwm33zYL0DFxEpic6axt652roE5xTUi4p
zm9Yt2AxwcT4naF/XbNvraEjiDuDoT6wUXk5DMjTBSO9ReXJuSor3Rvc5EUgdj7UKxIS
M74g==
X-Forwarded-Encrypted: i=1; AJvYcCUvSaklPu/Z6b7FCUg9V3CyTUkl8GhaEg5ZzA80MkULb+ajDHjDO/Svs8g4HwbqkWtp2Iszlcg0ynRLLc0=@vger.kernel.org
X-Gm-Message-State: AOJu0YxtnVFNTK4yg+VQ1UXxwPDxm8DciYWm4L72nKBGJ6cTysWZPGTa
wUd1HNjmM4r5UhcWSo5qs0wscN3/LrYcqtxwQ/Bwc5cUTsqJ4l7JYIYAqKXGIzUEhRjpSraMGFB
Z+Ex/IEPFGhVXBVczt9VIeysLgDUhxJDUQiXTFqJZi9gigqMjDPcgKvNgXiD1LCDPkQ==
X-Gm-Gg: ASbGncvexKlR9h8doSHmnWcSJbrz3NkbciLPxapmeM9vY6Ckj2YPMQ5Z5dcbD0ww8dw
UsNI3JzizARudrbTSW3qiJDHiurpR9fnZJ669Kcunct0bbgTb9franZgSMVFtutVXcu6vXRpoQw
Zyomn1uXc5keJP2Nr0drYA9dO/oOZ8gBNXPCn3ViOeCdUjl8bMk2foY+UDe1JC1e/JKhLxQUnMq
vk/AJtzTqeezSScK78KKYrLCtaHq0tcjcf3F1EcHLjJwGMbplvNvUXttN8Qkpv235VL5EY9bcVO
LcBYit1A/hdDx9qVd4hu6NstXDes0D3Brf6Osx9H5eKXra0Gc/hQENfduUz5a/m6Mno3pf9+VSv
/Re45VllBdDWUPZoGpAgOaTTovtvnBIInwdnelD4=
X-Received: by 2002:a05:6000:230b:b0:3a4:e318:1aa9 with SMTP id ffacd0b85a97d-3a4f89ead67mr1079180f8f.59.1748597283683;
Fri, 30 May 2025 02:28:03 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IHSN415fVjodgeAGej8jr3DGQGkFoBTJfuX+0MivXSEcmg1XYg2YU3IQl5r7q4efo/bqIG2xA==
X-Received: by 2002:a05:6000:230b:b0:3a4:e318:1aa9 with SMTP id ffacd0b85a97d-3a4f89ead67mr1079154f8f.59.1748597283295;
Fri, 30 May 2025 02:28:03 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4f009757fsm4336476f8f.78.2025.05.30.02.28.02
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 02:28:02 -0700 (PDT)
Message-ID: <2fb04e1b-8ce0-4216-9255-fc09c04e860b@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:28:01 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 0/5] kdump: crashkernel reservation from CMA
To: Michal Hocko <mhocko@xxxxxxxx>
Cc: Baoquan He <bhe@xxxxxxxxxx>, Donald Dutile <ddutile@xxxxxxxxxx>,
Jiri Bohac <jbohac@xxxxxxx>, Vivek Goyal <vgoyal@xxxxxxxxxx>,
Dave Young <dyoung@xxxxxxxxxx>, kexec@xxxxxxxxxxxxxxxxxxx,
Philipp Rudo <prudo@xxxxxxxxxx>, Pingfan Liu <piliu@xxxxxxxxxx>,
Tao Liu <ltao@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx,
David Hildenbrand <dhildenb@xxxxxxxxxx>
References: <04904e86-5b5f-4aa1-a120-428dac119189@xxxxxxxxxx>
<427fec88-2a74-471e-aeb6-a108ca8c4336@xxxxxxxxxx>
<Z8Z/gnbtiXT9QAZr@MiWiFi-R3L-srv>
<e9c5c247-85fb-43f1-9aa8-47d62321f37b@xxxxxxxxxx>
<aDgQ0lbt1h5v0lgE@tiehlicka>
<a1a5af90-bc8a-448a-81fa-485624d592f3@xxxxxxxxxx>
<aDlsF5tAcUxo4VgT@tiehlicka>
<e0f7fc1e-2227-4c6b-985a-34a697a52679@xxxxxxxxxx>
<aDl1ViMpK_6q_z06@tiehlicka>
<04a49de5-eb79-431b-ba5b-eae2536781c6@xxxxxxxxxx>
<aDl5rpqCUyf7nX2M@tiehlicka>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <aDl5rpqCUyf7nX2M@tiehlicka>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 30.05.25 11:26, Michal Hocko wrote:
> On Fri 30-05-25 11:11:40, David Hildenbrand wrote:
>> On 30.05.25 11:07, Michal Hocko wrote:
>>> On Fri 30-05-25 10:39:39, David Hildenbrand wrote:
>>>> On 30.05.25 10:28, Michal Hocko wrote:
>>> [...]
>>>>> All that being said I would go with an additional parameter to the
>>>>> kdump cma setup - e.g. cma_sane_dma that would skip waiting and use 10s
>>>>> otherwise. That would make the optimized behavior opt in, we do not need
>>>>> to support all sorts of timeouts and also learn if this is not
>>>>> sufficient.
>>>>>
>>>>> Makes sense?
>>>>
>>>> Just so I understand correctly, you mean extending the "crashkernel=" option
>>>> with a boolean parameter? If set, e.g., wait 1s, otherwise magic number 10?
>>>
>>> crashkernel=1G,cma,cma_sane_dma # no wait on transition
>>
>> But is no wait ok? I mean, any O_DIRECT with any device would at least take
>> a bit, no?
>>
>> Of course, there is a short time between the crash and actually triggerying
>> kdump.
>
> This is something we can test for and if we need a short timeout in this
> case as well then it is just trivial to add it. I am much more
> concerned about those potentially unpredictable DMA transfers that could
> take too long and it is impossible to test for those and therefore we
> need to overshoot.
Agreed.
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667854-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id CF71E41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:28:33 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 0E1EA4E38BD
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:35 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 00E7F21FF28;
Fri, 30 May 2025 09:28:28 +0000 (UTC)
Received: from mail-il1-f208.google.com (mail-il1-f208.google.com [209.85.166.208])
(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 7ADBA21C9F8
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:25 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.166.208
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597307; cv=none; b=hoSOLYRidOwTQUCyChN5y48O6WTJ1z/qdKM441NyPldxUKU9b5rPi6Q+vgU+daIXBCh5YW5wE91rQUXnRFyQRVsLMd+H2Flyi4zoUVMJDGuiV/AgZvc7N6h4+wnYWeXd4fqsPCQEww7R+QdBq11XvKOGKOSZgq7vhMo1hxXPomk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597307; c=relaxed/simple;
bh=uT25BXC8aiIN2if1X7W5ufA0j1GYNkBxlIjE05cNxLM=;
h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=nzIxm6a7gE12MUUTyqhgyh/MWHiRw4AwFw+HWFcOUPPeaMDrTB7LSQlLyFWqZTfPYbPJ4sWPRKPJmczceHlXLZ8m6b0dfInpbGmR0K3glsaGkFyYA79NWJOrM8FWjCWnRBamLkBAZ43jthCP4H+kFrW1UshgYkef3O9F39wSomM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com; arc=none smtp.client-ip=209.85.166.208
Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=syzkaller.appspotmail.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=M3KW2WVRGUFZ5GODRSRYTGD7.apphosting.bounces.google.com
Received: by mail-il1-f208.google.com with SMTP id e9e14a558f8ab-3db9a090c15so22226525ab.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:28:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597304; x=1749202104;
h=to:from:subject:message-id:date:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=tmZLF+sbgUSSdhYb3r1jseS5cZOLcM/dMLZzx55rrmo=;
b=cuoXUivNACTzh7xrZYRueerQYh431BdAvxp1q2GV8ajqNKeV3rcrEXiHFaSyZmXw7y
zQw4cHm/JMgqgI6WUQG8butc6lQkHQmpe79oxv1o/9fzj8XB5lh4GXfhtVHo3UJmq3KH
ei1ZzGhAUvOX/C22vSzKFqUrwzZlMDOCaKSMggCq6T5G98ibe4k6qwbaBN/mkYZQ9wVI
cZsz6XCtLn25h+dElm1A7uUorXo1OgRo1K/LmXGDy3kTwelo4ktrJlXc3hj5oPuNKtWY
z0JLbwshC7o3G9Y8v2D0Z2vnN6hQipTDFIhvUkgsS7rm4dLX7RjOAF27tTvi79PdEPyN
dQdQ==
X-Forwarded-Encrypted: i=1; AJvYcCUuaYtId/w/0ItPNO8ncfBSo7NPIC8l3IE9QE9TRQmoG+ZwAR/TMbCgTPs0LsKiO9uHmw1CjgRURx8zXU8=@vger.kernel.org
X-Gm-Message-State: AOJu0YwE7/vhMPf++mNRgx1xad2bKItRxbXRFyssbsSjAyJkWt0akXph
H4sX0RPYVmrId+cMUzHmqHkWBqd5G0u+zI3Yp5z0V4mGw/lR9egyW5EPeI2ss+NnmY9aaDTBSxt
KJnO2g/WuWIOV0xCaF3lJVjGqNUhLkHLCmrj4M1sCyeiL3MBz3zgLQYLI4f4=
X-Google-Smtp-Source: AGHT+IFgBAWP9tjCTLpYZOQkDZy1UGz7BNuGsiaWqONI2VPxMt8mjJCFr0fI/7GfmufaiXEoVClOTmhVCDBYeTCuwC2tjqhaawVm
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-Received: by 2002:a05:6e02:1a21:b0:3dd:892d:b25e with SMTP id
e9e14a558f8ab-3dd9cbf6c36mr12434255ab.22.1748597304567; Fri, 30 May 2025
02:28:24 -0700 (PDT)
Date: Fri, 30 May 2025 02:28:24 -0700
X-Google-Appengine-App-Id: s~syzkaller
X-Google-Appengine-App-Id-Alias: syzkaller
Message-ID: <68397a38.a00a0220.d8eae.0005.GAE@xxxxxxxxxx>
Subject: [syzbot] [ext4?] WARNING in jbd2_journal_dirty_metadata (2)
From: syzbot <syzbot+f71f98e4cf272ac05861@xxxxxxxxxxxxxxxxxxxxxxxxx>
To: jack@xxxxxxxx, linux-ext4@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
syzkaller-bugs@xxxxxxxxxxxxxxxx, tytso@xxxxxxx
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.0 required=5.0 tests=FROM_LOCAL_HEX,
HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hello,
syzbot found the following issue on:
HEAD commit: c89756bcf406 Merge tag 'pm-6.16-rc1' of git://git.kernel.o..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=174dabf4580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ded97a85afe9a6c8
dashboard link: https://syzkaller.appspot.com/bug?extid=f71f98e4cf272ac05861
compiler: Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-c89756bc.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/b21d74e73303/vmlinux-c89756bc.xz
kernel image: https://storage.googleapis.com/syzbot-assets/b778ededeb75/bzImage-c89756bc.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+f71f98e4cf272ac05861@xxxxxxxxxxxxxxxxxxxxxxxxx
loop0: detected capacity change from 0 to 32768
=======================================================
WARNING: The mand mount option has been deprecated and
and is ignored by this kernel. Remove the mand
option from the mount to silence this warning.
=======================================================
ocfs2: Mounting device (7,0) on (node local, slot 0) with writeback data mode.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 5317 at fs/jbd2/transaction.c:1552 jbd2_journal_dirty_metadata+0x978/0xcd0 fs/jbd2/transaction.c:1552
Modules linked in:
CPU: 0 UID: 0 PID: 5317 Comm: syz.0.0 Not tainted 6.15.0-syzkaller-03478-gc89756bcf406 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
RIP: 0010:jbd2_journal_dirty_metadata+0x978/0xcd0 fs/jbd2/transaction.c:1552
Code: 24 41 89 e8 4d 89 f9 50 41 56 41 55 53 e8 a0 f2 a0 fe 48 83 c4 20 90 0f 0b 90 bb ea ff ff ff e9 09 fe ff ff e8 a9 57 39 ff 90 <0f> 0b 90 bb e4 ff ff ff e9 f6 fd ff ff 48 8b 44 24 28 48 83 c0 18
RSP: 0018:ffffc9000d4ce938 EFLAGS: 00010283
RAX: ffffffff82869aa7 RBX: 0000000000000000 RCX: 0000000000100000
RDX: ffffc9000de7a000 RSI: 0000000000092c37 RDI: 0000000000092c38
RBP: ffff888052d6b750 R08: 0000000000000003 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff52001a99d18 R12: 1ffff1100a59d7cf
R13: dffffc0000000000 R14: 1ffff1100a5ad6e9 R15: 1ffff1100a59d7cc
FS: 00007f2f05ca06c0(0000) GS:ffff88808d28f000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000055c7145f1168 CR3: 000000003f33b000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ocfs2_journal_dirty+0x149/0x740 fs/ocfs2/journal.c:834
ocfs2_split_refcount_rec+0xb46/0x12a0 fs/ocfs2/refcounttree.c:1965
ocfs2_decrease_refcount_rec fs/ocfs2/refcounttree.c:2190 [inline]
__ocfs2_decrease_refcount+0x551/0x1780 fs/ocfs2/refcounttree.c:2249
ocfs2_make_clusters_writable fs/ocfs2/refcounttree.c:3262 [inline]
ocfs2_replace_cow+0xd5a/0x1b90 fs/ocfs2/refcounttree.c:3346
ocfs2_refcount_cow_hunk fs/ocfs2/refcounttree.c:3424 [inline]
ocfs2_refcount_cow+0x779/0xc90 fs/ocfs2/refcounttree.c:3467
ocfs2_prepare_inode_for_write fs/ocfs2/file.c:2340 [inline]
ocfs2_file_write_iter+0xe28/0x1d10 fs/ocfs2/file.c:2451
iter_file_splice_write+0x93a/0x1000 fs/splice.c:738
do_splice_from fs/splice.c:935 [inline]
direct_splice_actor+0x101/0x160 fs/splice.c:1158
splice_direct_to_actor+0x5a5/0xcc0 fs/splice.c:1102
do_splice_direct_actor fs/splice.c:1201 [inline]
do_splice_direct+0x181/0x270 fs/splice.c:1227
do_sendfile+0x4da/0x7e0 fs/read_write.c:1370
__do_sys_sendfile64 fs/read_write.c:1431 [inline]
__se_sys_sendfile64+0x13e/0x190 fs/read_write.c:1417
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f2f04d8e969
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f2f05ca0038 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007f2f04fb5fa0 RCX: 00007f2f04d8e969
RDX: 0000000000000000 RSI: 0000000000000007 RDI: 0000000000000007
RBP: 00007f2f04e10ab1 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000800000009 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f2f04fb5fa0 R15: 00007fff8a1ca8d8
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@xxxxxxxxxxxxxxxx.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
Return-Path: <linux-kernel+bounces-667855-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 92AA341E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:28:51 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 55A141BA4CB2
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:04 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 0AD9222126C;
Fri, 30 May 2025 09:28:31 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="a60OGV5B"
Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.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 0EB63212B3D
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:26 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597309; cv=none; b=pI6v/T+X4JbMcnzboiv3UuEJqD5KEX2cYY4/f4dL6OZB4X+pTfVjM2CR2bjLNXt9wOxSkTWIo/0b4LQDtYB2r7Mdc5ruC7Z5jOphMNL6RucU/Ilxwqy8prgYiu5WJTWRCECHbeUD60QSPByuNImBsw3xvQpnS3TGebvpc1fj1w8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597309; c=relaxed/simple;
bh=4ZpYH9gjzEMK0JBNxeSHRVQaFIcBi9bPL+YcG/+ScUw=;
h=From:To:Cc:Subject:Date:Message-Id:MIME-Version:Content-Type; b=l9OIISmQGpPivXZRG0sfLGRuTvmg8+/rMYx5yll4lj3Z03WrRiCRZ3XhTZe+HOCcNWK9pJQVnRS7PuGThNevLJCY/rXNHWRPAvutoCgifEAdJmq/f5uhcn6I8ue/I9sYqSG9Uh9sbutMW7iGZlZubaIpKR/8t1dLkXoKVuQRQq4=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=a60OGV5B; arc=none smtp.client-ip=209.85.214.177
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-22d95f0dda4so22551445ad.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:28:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597306; x=1749202106; 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=CczhYEWNGyPrtfRTCWOMeu+EteVzhsXFynQaRlBzWFA=;
b=a60OGV5BvwE5Q+EJMzbNOsNKtlkoEu1D7N4L492i74V6aNYYf64gF49/xTgsUIh3Bi
QZxduSz06RHvH+Pma9F+PRcgEwkBDEXbobP1xaKxE33t51Vqz6h+YLGX34EQtTj2Ps7f
Cad5+mHnAAiLZwR5Fyec4gBuWfOUqKnaCrLM4F3w3ZM+kWUm8qyBZQJq8snilbUQ/GVe
IvPMurO+aHpE+v22ZWowHpqPn4ZfdusAbffzngapYcFmCW6ocTTmJZm6s/VXGITIgLlM
6xnHlK1BEju6dN8a/I9EkESxaL1RX3weGgAXDDO615hBrN5Pp1wfsOnuB0JuW7IHzx3F
hnhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597306; x=1749202106;
h=content-transfer-encoding:mime-version:message-id:date:subject:cc
:to:from:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=CczhYEWNGyPrtfRTCWOMeu+EteVzhsXFynQaRlBzWFA=;
b=I0HnvWz8dF97LMkASWicrTTZ4aLklaXDhyL+fB8+cC3wjAHtcq/d7wuDt/htwWtNgN
xV3/hswWirBN1QvLobUyUXZ+iphuGCdsIZaWofi9qXgHSk13vFj2DjBDgio1W39GOJbd
d8N7M5CqzeUas6SK6kJ1LKtX8a88VdIM7Ynm1pfQ0ZK6565eKW9sNCPTpEi9UnLtnED3
MtB1A2wpzR7pTGisCMioxXsYwH9bxoAisuAIYD4P/XnveIQkWyQEPSHWN/aQq7s7U1cN
rRFQUMOPMlkNtT5Naz+2gV/e9PLys1VP1YWuZaHu2Chue/IwHab+f5TruU8FPv9yzoWb
HxOQ==
X-Forwarded-Encrypted: i=1; AJvYcCWIUuei4Un/elw/WlhDmY7f6Fm9vpVI05DUxypcrUqFCSzk3mXmPTkFAlP+RNu4out8xG9qf+etjttLnjI=@vger.kernel.org
X-Gm-Message-State: AOJu0YwwZ+RpL52wiO5tJ9Bssvw+ifv9nOmieojinYMTqUQpzjafNomX
56WEqYQJVMbLDDqTExDGFh53od9W9liJ0SuWBOq758dQG27/st2Q/Z41p+o6nP99qlQ=
X-Gm-Gg: ASbGncsIwpZ96uBq/t9xlBLBe0JOXqYwoymhA23GT9wDDjW+xUrqWBYQmruITb3IrrB
se/se6k2EC83BcbshwYJ9Ve2P5T8clrH9nIjWsjxQHZsCAfmnGt51lvrKpM2U832tjFjfNGgxgh
wvlY2ICF9vomHwSe8m7jlpZhPlS/dtR/seCRZhFLh0WXGDmf39PP7oa5lr2XDPiESBeG1Bt+E52
2bTzRSiod/2fmXCMnOiQu0ibkFEL/dxgnLkwFVqxlS5l6jlzlYlmy/3DbKMn2oG9ArrK8vuZWIx
KqtQJijbkX7ZCHq7AN511wrkDxCklYnYFeUFwZwu2Cj7oqkRIq+Sclv1EHRPYAYT1ZxvQTj5EbK
L6dCBK8mHRA==
X-Google-Smtp-Source: AGHT+IFvYzOyzz0QKmq8BmP2270HEIZC3kk4v2nCSX/dhDAlMnvHnsDN8Dwflm9/0Lg34e9Yf5+UhQ==
X-Received: by 2002:a17:902:e807:b0:234:cb4a:bc30 with SMTP id d9443c01a7336-2352991146cmr46663765ad.41.1748597305966;
Fri, 30 May 2025 02:28:25 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.28.10
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:28:25 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 00/35] optimize cost of inter-process communication
Date: Fri, 30 May 2025 17:27:28 +0800
Message-Id: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Changelog:
v2:
- Port the RPAL functions to the latest v6.15 kernel.
- Add a supplementary introduction to the application scenarios and
security considerations of RPAL.
link to v1:
https://lore.kernel.org/lkml/CAP2HCOmAkRVTci0ObtyW=3v6GFOrt9zCn2NwLUbZ+Di49xkBiw@xxxxxxxxxxxxxx/
--------------------------------------------------------------------------
# Introduction
We mainly apply RPAL to the service mesh architecture widely adopted in
modern cloud-native data centers. Before the rise of the service mesh
architecture, network functions were usually integrated into monolithic
applications as libraries, and the main business programs invoked them
through function calls. However, to facilitate the independent development
and operation and maintenance of the main business programs and network
functions, the service mesh removed the network functions from the main
business programs and made them independent processes (called sidecars).
Inter-process communication (IPC) is used for interaction between the main
business program and the sidecar, and the introduced inter-process
communication has led to a sharp increase in resource consumption in
cloud-native data centers, and may even occupy more than 10% of the CPU of
the entire microservice cluster.
To achieve the efficient function call mechanism of the monolithic
architecture under the service mesh architecture, we introduced the RPAL
(Running Process As Library) architecture, which implements the sharing of
the virtual address space of processes and the switching threads in user
mode. Through the analysis of the service mesh architecture, we found that
the process memory isolation between the main business program and the
sidecar is not particularly important because they are split from one
application and were an integral part of the original monolithic
application. It is more important for the two processes to be independent
of each other because they need to be independently developed and
maintained to ensure the architectural advantages of the service mesh.
Therefore, RPAL breaks the isolation between processes while preserving the
independence between them. We think that RPAL can also be applied to other
scenarios featuring sidecar-like architectures, such as distributed file
storage systems in LLM infra.
In RPAL architecture, multiple processes share a virtual address space, so
this architecture can be regarded as an advanced version of the Linux
shared memory mechanism:
1. Traditional shared memory requires two processes to negotiate to ensure
the mapping of the same piece of memory. In RPAL architecture, two RPAL
processes still need to reach a consensus before they can successfully
invoke the relevant system calls of RPAL to share the virtual address
space.
2. Traditional shared memory only shares part of the data. However, in RPAL
architecture, processes that have established an RPAL communication
relationship share a virtual address space, and all user memory (such as
data segments and code segments) of each RPAL process is shared among these
processes. However, a process cannot access the memory of other processes
at any time. We use the MPK mechanism to ensure that the memory of other
processes can only be accessed when special RPAL functions are called.
Otherwise, a page fault will be triggered.
3. In RPAL architecture, to ensure the consistency of the execution context
of the shared code (such as the stack and thread local storage), we further
implement the thread context switching in user mode based on the ability to
share the virtual address space of different processes, enabling the
threads of different processes to directly perform fast switching in user
mode without falling into kernel mode for slow switching.
# Background
In traditional inter-process communication (IPC) scenarios, Unix domain
sockets are commonly used in conjunction with the epoll() family for event
multiplexing. IPC operations involve system calls on both the data and
control planes, thereby imposing a non-trivial overhead on the interacting
processes. Even when shared memory is employed to optimize the data plane,
two data copies still remain. Specifically, data is initially copied from
a process's private memory space into the shared memory area, and then it
is copied from the shared memory into the private memory of another
process.
This poses a question: Is it possible to reduce the overhead of IPC with
only minimal modifications at the application level? To address this, we
observed that the functionality of IPC, which encompasses data transfer
and invocation of the target thread, is similar to a function call, where
arguments are passed and the callee function is invoked to process them.
Inspired by this analogy, we introduce RPAL (Run Process As Library), a
framework designed to enable one process to invoke another as if making
a local function call, all without going through the kernel.
# Design
First, letâ??s formalize RPALâ??s core objectives:
1. Data-plane efficiency: Reduce the number of data copies from two (in the
shared memory solution) to one.
2. Control-plane optimization: Eliminate the overhead of system calls and
kernel's thread switches.
3. Application compatibility: Minimize the modifications to existing
applications that utilize Unix domain sockets and the epoll() family.
To attain the first objective, processes that use RPAL share the same
virtual address space. So one process can access another's data directly
via a data pointer. This means data can be transferred from one process to
another with just one copy operation.
To meet the second goal, RPAL relies on the shared address space to do
lightweight context switching in user space, which we call an "RPAL call".
This allows one process to execute another process's code just like a
local function call.
To achieve the third target, RPAL stays compatible with the epoll family
of functions, like epoll_create(), epoll_wait(), and epoll_ctl(). If an
application uses epoll for IPC, developers can switch to RPAL with just a
few small changes. For instance, you can just replace epoll_wait() with
rpal_epoll_wait(). The basic epoll procedure, where a process waits for
another to write to a monitored descriptor using an epoll file descriptor,
still works fine with RPAL.
## Address space sharing
For address space sharing, RPAL partitions the entire userspace virtual
address space and allocates non-overlapping memory ranges to each process.
On x86_64 architectures, RPAL uses a memory range size covered by a
single PUD (Page Upper Directory) entry, which is 512GB. This restricts
each processâ??s virtual address space to 512GB on x86_64, sufficient for
most applications in our scenario. The rationale is straightforward:
address space sharing can be simply achieved by copying the PUD from one
processâ??s page table to anotherâ??s. So one process can directly use the
data pointer to access another's memory.
|------------| <- 0
|------------| <- 512 GB
| Process A |
|------------| <- 2*512 GB
|------------| <- n*512 GB
| Process B |
|------------| <- (n+1)*512 GB
|------------| <- STACK_TOP
| Kernel |
|------------|
## RPAL call
We refer to the lightweight userspace context switching mechanism as RPAL
call. It enables the caller (or sender) thread of one process to directly
switch to the callee (or receiver) thread of another process.
When Process Aâ??s caller thread initiates an RPAL call to Process Bâ??s
callee thread, the CPU saves the callerâ??s context and loads the calleeâ??s
context. This enables direct userspace control flow transfer from the
caller to the callee. After the callee finishes data processing, the CPU
saves Process Bâ??s callee context and switches back to Process Aâ??s caller
context, completing a full IPC cycle.
|------------| |---------------------|
| Process A | | Process B |
| |-------| | | |-------| |
| | caller| --- RPAL call --> | | callee| handle |
| | thread| <------------------ | thread| -> event |
| |-------| | | |-------| |
|------------| |---------------------|
# Security and compatibility with kernel subsystems
## Memory protection between processes
Since processes using RPAL share the address space, unintended
cross-process memory access may occur and corrupt the data of another
process. To mitigate this, we leverage Memory Protection Keys (MPK) on x86
architectures.
MPK assigns 4 bits in each page table entry to a "protection key", which
is paired with a userspace register (PKRU). The PKRU register defines
access permissions for memory regions protected by specific keys (for
detailed implementation, refer to the kernel documentation "Memory
Protection Keys"). With MPK, even though the address space is shared
among processes, cross-process access is restricted: a process can only
access the memory protected by a key if its PKRU register is configured
with the corresponding permission. This ensures that processes cannot
access each otherâ??s memory unless an explicit PKRU configuration is set.
## Page fault handling and TLB flushing
Due to the shared address space architecture, both page fault handling and
TLB flushing require careful consideration. For instance, when Process A
accesses Process Bâ??s memory, a page fault may occur in Process A's
context, but the faulting address belongs to Process B. In this case, we
must pass Process B's mm_struct to the page fault handler.
TLB flushing is more complex. When a thread flushes the TLB, since the
address space is shared, not only other threads in the current process but
also other processes that share the address space may access the
corresponding memory (related to the TLB flush). Therefore, the cpuset used
for TLB flushing should be the union of the mm_cpumasks of all processes
that share the address space.
## Lazy switch of kernel context
In RPAL, a mismatch may arise between the user context and the kernel
context. The RPAL call is designed solely to switch the user context,
leaving the kernel context unchanged. For instance, when a RPAL call takes
place, transitioning from caller thread to callee thread, and subsequently
a system call is initiated within callee thread, the kernel will
incorrectly utilize the caller's kernel context (such as the kernel stack)
to process the system call.
To resolve context mismatch issues, a kernel context switch is triggered at
the kernel entry point when the callee initiates a syscall or an
exception/interrupt occurs. This mechanism ensures context consistency
before processing system calls, interrupts, or exceptions. We refer to this
kernel context switch as a "lazy switch" because it defers the switching
operation from the traditional thread switch point to the next kernel entry
point.
Lazy switch should be minimized as much as possible, as it significantly
degrades performance. We currently utilize RPAL in an RPC framework, in
which the RPC sender thread relies on the RPAL call to invoke the RPC
receiver thread entirely in user space. In most cases, the receiver
thread is free of system calls and the code execution time is relatively
short. This characteristic effectively reduces the probability of a lazy
switch occurring.
## Time slice correction
After an RPAL call, the callee's user mode code executes. However, the
kernel incorrectly attributes this CPU time to the caller due to the
unchanged kernel context.
To resolve this, we use the Time Stamp Counter (TSC) register to measure
CPU time consumed by the callee thread in user space. The kernel then uses
this user-reported timing data to adjust the CPU accounting for both the
caller and callee thread, similar to how CPU steal time is implemented.
## Process recovery
Since processes can access each otherâ??s memory, there is a risk that the
target processâ??s memory may become invalid at the access time (e.g., if
the target process has exited unexpectedly). The kernel must handle such
cases; otherwise, the accessing process could be terminated due to
failures originating from another process.
To address this issue, each thread of the process should pre-establish a
recovery point when accessing the memory of other processes. When such an
invalid access occurs, the thread traps into the kernel. Inside the page
fault handler, the kernel restores the user context of the thread to the
recovery point. This mechanism ensures that processes maintain mutual
independence, preventing cascading failures caused by cross-process memory
issues.
# Performance
To quantify the performance improvements driven by RPAL, we measured
latency both before and after its deployment. Experiments were conducted on
a server equipped with two Intel(R) Xeon(R) Platinum 8336C CPUs (2.30 GHz)
and 1 TB of memory. Latency was defined as the duration from when the
client thread initiates a message to when the server thread is invoked and
receives it.
During testing, the client transmitted 1 million 32-byte messages, and we
computed the per-message average latency. The results are as follows:
*****************
Without RPAL: Message length: 32 bytes, Total TSC cycles: 19616222534,
Message count: 1000000, Average latency: 19616 cycles
With RPAL: Message length: 32 bytes, Total TSC cycles: 1703459326,
Message count: 1000000, Average latency: 1703 cycles
*****************
These results confirm that RPAL delivers substantial latency improvements
over the current epoll implementationâ??achieving a 17,913-cycle reduction
(an ~91.3% improvement) for 32-byte messages.
We have applied RPAL to an RPC framework that is widely used in our data
center. With RPAL, we have successfully achieved up to 15.5% reduction in
the CPU utilization of processes in real-world microservice scenario. The
gains primarily stem from minimizing control plane overhead through the
utilization of userspace context switches. Additionally, by leveraging
address space sharing, the number of memory copies is significantly
reduced.
# Future Work
Currently, RPAL requires the MPK (Memory Protection Key) hardware feature,
which is supported by a range of Intel CPUs. For AMD architectures, MPK is
supported only on the latest processor, specifically, 3th Generation AMD
EPYCâ?¢ Processors and subsequent generations. Patch sets that extend RPAL
support to systems lacking MPK hardware will be provided later.
Accompanying test programs are also provided in the samples/rpal/
directory. And the user-mode RPAL library, which realizes user-space RPAL
call, is in the samples/rpal/librpal directory.
We hope to get some community discussions and feedback on RPAL's
optimization approaches and architecture.
Look forward to your comments.
Bo Li (35):
Kbuild: rpal support
RPAL: add struct rpal_service
RPAL: add service registration interface
RPAL: add member to task_struct and mm_struct
RPAL: enable virtual address space partitions
RPAL: add user interface
RPAL: enable shared page mmap
RPAL: enable sender/receiver registration
RPAL: enable address space sharing
RPAL: allow service enable/disable
RPAL: add service request/release
RPAL: enable service disable notification
RPAL: add tlb flushing support
RPAL: enable page fault handling
RPAL: add sender/receiver state
RPAL: add cpu lock interface
RPAL: add a mapping between fsbase and tasks
sched: pick a specified task
RPAL: add lazy switch main logic
RPAL: add rpal_ret_from_lazy_switch
RPAL: add kernel entry handling for lazy switch
RPAL: rebuild receiver state
RPAL: resume cpumask when fork
RPAL: critical section optimization
RPAL: add MPK initialization and interface
RPAL: enable MPK support
RPAL: add epoll support
RPAL: add rpal_uds_fdmap() support
RPAL: fix race condition in pkru update
RPAL: fix pkru setup when fork
RPAL: add receiver waker
RPAL: fix unknown nmi on AMD CPU
RPAL: enable time slice correction
RPAL: enable fast epoll wait
samples/rpal: add RPAL samples
arch/x86/Kbuild | 2 +
arch/x86/Kconfig | 2 +
arch/x86/entry/entry_64.S | 160 ++
arch/x86/events/amd/core.c | 14 +
arch/x86/include/asm/pgtable.h | 25 +
arch/x86/include/asm/pgtable_types.h | 11 +
arch/x86/include/asm/tlbflush.h | 10 +
arch/x86/kernel/asm-offsets.c | 3 +
arch/x86/kernel/cpu/common.c | 8 +-
arch/x86/kernel/fpu/core.c | 8 +-
arch/x86/kernel/nmi.c | 20 +
arch/x86/kernel/process.c | 25 +-
arch/x86/kernel/process_64.c | 118 +
arch/x86/mm/fault.c | 271 ++
arch/x86/mm/mmap.c | 10 +
arch/x86/mm/tlb.c | 172 ++
arch/x86/rpal/Kconfig | 21 +
arch/x86/rpal/Makefile | 6 +
arch/x86/rpal/core.c | 477 ++++
arch/x86/rpal/internal.h | 69 +
arch/x86/rpal/mm.c | 426 +++
arch/x86/rpal/pku.c | 196 ++
arch/x86/rpal/proc.c | 279 ++
arch/x86/rpal/service.c | 776 ++++++
arch/x86/rpal/thread.c | 313 +++
fs/binfmt_elf.c | 98 +-
fs/eventpoll.c | 320 +++
fs/exec.c | 11 +
include/linux/mm_types.h | 3 +
include/linux/rpal.h | 633 +++++
include/linux/sched.h | 21 +
init/init_task.c | 6 +
kernel/exit.c | 5 +
kernel/fork.c | 32 +
kernel/sched/core.c | 676 +++++
kernel/sched/fair.c | 109 +
kernel/sched/sched.h | 8 +
mm/mmap.c | 16 +
mm/mprotect.c | 106 +
mm/rmap.c | 4 +
mm/vma.c | 18 +
samples/rpal/Makefile | 17 +
samples/rpal/asm_define.c | 14 +
samples/rpal/client.c | 178 ++
samples/rpal/librpal/asm_define.h | 6 +
samples/rpal/librpal/asm_x86_64_rpal_call.S | 57 +
samples/rpal/librpal/debug.h | 12 +
samples/rpal/librpal/fiber.c | 119 +
samples/rpal/librpal/fiber.h | 64 +
.../rpal/librpal/jump_x86_64_sysv_elf_gas.S | 81 +
.../rpal/librpal/make_x86_64_sysv_elf_gas.S | 82 +
.../rpal/librpal/ontop_x86_64_sysv_elf_gas.S | 84 +
samples/rpal/librpal/private.h | 341 +++
samples/rpal/librpal/rpal.c | 2351 +++++++++++++++++
samples/rpal/librpal/rpal.h | 149 ++
samples/rpal/librpal/rpal_pkru.h | 78 +
samples/rpal/librpal/rpal_queue.c | 239 ++
samples/rpal/librpal/rpal_queue.h | 55 +
samples/rpal/librpal/rpal_x86_64_call_ret.S | 45 +
samples/rpal/offset.sh | 5 +
samples/rpal/server.c | 249 ++
61 files changed, 9710 insertions(+), 4 deletions(-)
create mode 100644 arch/x86/rpal/Kconfig
create mode 100644 arch/x86/rpal/Makefile
create mode 100644 arch/x86/rpal/core.c
create mode 100644 arch/x86/rpal/internal.h
create mode 100644 arch/x86/rpal/mm.c
create mode 100644 arch/x86/rpal/pku.c
create mode 100644 arch/x86/rpal/proc.c
create mode 100644 arch/x86/rpal/service.c
create mode 100644 arch/x86/rpal/thread.c
create mode 100644 include/linux/rpal.h
create mode 100644 samples/rpal/Makefile
create mode 100644 samples/rpal/asm_define.c
create mode 100644 samples/rpal/client.c
create mode 100644 samples/rpal/librpal/asm_define.h
create mode 100644 samples/rpal/librpal/asm_x86_64_rpal_call.S
create mode 100644 samples/rpal/librpal/debug.h
create mode 100644 samples/rpal/librpal/fiber.c
create mode 100644 samples/rpal/librpal/fiber.h
create mode 100644 samples/rpal/librpal/jump_x86_64_sysv_elf_gas.S
create mode 100644 samples/rpal/librpal/make_x86_64_sysv_elf_gas.S
create mode 100644 samples/rpal/librpal/ontop_x86_64_sysv_elf_gas.S
create mode 100644 samples/rpal/librpal/private.h
create mode 100644 samples/rpal/librpal/rpal.c
create mode 100644 samples/rpal/librpal/rpal.h
create mode 100644 samples/rpal/librpal/rpal_pkru.h
create mode 100644 samples/rpal/librpal/rpal_queue.c
create mode 100644 samples/rpal/librpal/rpal_queue.h
create mode 100644 samples/rpal/librpal/rpal_x86_64_call_ret.S
create mode 100755 samples/rpal/offset.sh
create mode 100644 samples/rpal/server.c
--
2.20.1
Return-Path: <linux-kernel+bounces-667856-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9B59441E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:29:21 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 60AB47A40C8
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:27:51 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 667A922128B;
Fri, 30 May 2025 09:28:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="RNJbGHOV"
Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45])
(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 30000219A97
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:41 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.45
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597323; cv=none; b=jdLr3JrTLZ13m8YK/7ZUpxNCKWzYVBLGyahjNZj9iMCqm0LYB0HyR0t/f/qEYZMEtuWed3JPq3KpNnm+GlR5Z7LMg8QazvyGVp8cFaTWQsxvJrawDVxbZViSARCPVed6lJA/pnCQknusEpNeNKANFlUySyXmMP1xOjPdwaM8CKs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597323; c=relaxed/simple;
bh=ppCxvzGPzwxMK0c+R/BjMfinsaxs9oKUnADG8qsL8g4=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=jwj9EcbDlRPi37P76sV1Nx4m6keD/yucBX1rrhLoeYD8sDW/ZKcWwfFI67V+7fEZ/U6fFcDRgdQUUgwo1IUeLJom2YVhy9oZBYlyXhVrwySj21riZjbP6Htqy1TCSOCewrxxTvS2GVqiyRETR/E5wFTblY3vqTnjqNigFc6u11E=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=RNJbGHOV; arc=none smtp.client-ip=209.85.216.45
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f45.google.com with SMTP id 98e67ed59e1d1-310cf8f7301so1486040a91.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:28:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597321; x=1749202121; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=H/A+gAHA3ZAGJfkMi3IvOeV45q7o44ZhkocltOJrpQQ=;
b=RNJbGHOVy+7gA5xoBsRaT1rKXF040JsAQapN8McX3jn1Wyk4I0ZZsaZbS8pB8DpatB
3g4kRPZGZxPujBKYFUZMfrHtujffJ6DNwYHUekHRdsao5cXm3myz9VwKiW0EuyowgMpp
PIq4oAY9ym5CCsuoHm1VxXGovdSKOHG+FuKhYGkKeL9YBIHHrbtc9YanYWLHXJH0UO0a
LESGRa9jM7y2+XjtsoLNrWJIkVkQFrL6526NQ1Dw8BichmkPc+kjMxzJ27kZyTD+tHiw
Zj/SCHFZIYYbr2XsoSF3U/5XhRQ5EWBkm35poP/UZR0nPRMb18IBTzExgW4+GBKCcGFy
SKVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597321; x=1749202121;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=H/A+gAHA3ZAGJfkMi3IvOeV45q7o44ZhkocltOJrpQQ=;
b=dIC1YCD0QdLb+XcYner9Idy6gylVb2rtgU4Is59+ThfNdu6dCW+m2zhA32YcAPT9BC
tj2oZimLtwiJfbfujyFIIxA1JUamFX9ec0qy3yS4tuqemmREz/+Xsb0jGI1sDeevSzft
QK0m75ryJA1cquIWGCMghaZFkGU8PZ9Y+QMopgqli9t6tCICg6U/f68G7Pq9RQ6h/AbD
9hEMONn3pjohXVRgY1gmEuhL54XayewWZ2DlcAiMs+kq0LyxAFziqpzbJBebdzAVKZLe
uKvKMtNpkEvv8sWiYoPhqOUEr2cSz/T5OLTmNpJZH9jQ2NFFb5A/qEYMl0elmYUr1QNm
cFZg==
X-Forwarded-Encrypted: i=1; AJvYcCU74ckBAVmEXdpyUztXzucvgP2WswHfKtDLvOrRUEiVyFYbyQu9J79+0eI9GkUo/5PdHHxwekpstmfhbPQ=@vger.kernel.org
X-Gm-Message-State: AOJu0YwvMOVRxwU4ffm38LrJrenaGosoZGQeKhGp4uzmMzOgcsQ+xVGH
0vyr9chOWocX1T1D+U7joGLJLaRp9YkGjENMunsLRZOsnz3ZK50qZt2JqCZexIk8lf8=
X-Gm-Gg: ASbGncssKRIT3xbW5PUkX9MQu/P1+d15MEXWjB4kOnu5ZlYAKtpBmk85wXupQaknFMo
7uJ1PolOj2dqeD7Qt0k44HlAMZlluDMh+wUOni+55HBBCLWCF8CtbboALVpK6+mmHKpk7cEIV30
5moJhot2Fti6JjJ4DX56n6oWhNIOYZ8Mb9PgflzVBXMVEa6AY0z7bv/DuzwO9SZf+ABoXJXjtyP
QPNONJoBmh99g9ENDjQBkgWfQKOJfsYKWc4TcPNC9pBI5nz5Bpe0mVMpFuKL5afYJils3r4pep/
TuPaQrDiDOT7rhFEaNCalioMIUC+AOEo2EkJEA66p7XjHDdf91S2r/lzPhgzREjZZ2/bbHIiK3r
CjdP8plXEf7qtC0z7eSgU
X-Google-Smtp-Source: AGHT+IGtvKSy5BRqT77HroAME3q1wPsiRK2qsvrkfhGABhYMviWMHBoI0lrSImjloPHkxtdJIsjzUQ==
X-Received: by 2002:a17:90b:4a0d:b0:310:b602:bc52 with SMTP id 98e67ed59e1d1-31214e11d96mr9868483a91.2.1748597321318;
Fri, 30 May 2025 02:28:41 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.28.26
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:28:41 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 01/35] Kbuild: rpal support
Date: Fri, 30 May 2025 17:27:29 +0800
Message-Id: <e68046d85a19a0d161e6f76f31ef6a208c646bb8.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Add kbuild support for RPAL, including new folder arch/x86/kernel/rpal and
new config CONFIG_RPAL.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/Kbuild | 2 ++
arch/x86/Kconfig | 2 ++
arch/x86/rpal/Kconfig | 11 +++++++++++
arch/x86/rpal/Makefile | 0
4 files changed, 15 insertions(+)
create mode 100644 arch/x86/rpal/Kconfig
create mode 100644 arch/x86/rpal/Makefile
diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index f7fb3d88c57b..26c406442d79 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -34,5 +34,7 @@ obj-$(CONFIG_KEXEC_FILE) += purgatory/
obj-y += virt/
+obj-y += rpal/
+
# for cleaning
subdir- += boot tools
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 121f9f03bd5c..3f53b6fc943f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2359,6 +2359,8 @@ config X86_BUS_LOCK_DETECT
Enable Split Lock Detect and Bus Lock Detect functionalities.
See <file:Documentation/arch/x86/buslock.rst> for more information.
+source "arch/x86/rpal/Kconfig"
+
endmenu
config CC_HAS_NAMED_AS
diff --git a/arch/x86/rpal/Kconfig b/arch/x86/rpal/Kconfig
new file mode 100644
index 000000000000..e5e6996553ea
--- /dev/null
+++ b/arch/x86/rpal/Kconfig
@@ -0,0 +1,11 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# This Kconfig describes RPAL options
+#
+
+config RPAL
+ def_bool y
+ depends on X86_64
+ help
+ This option enables system support for Run Process As
+ library (RPAL).
\ No newline at end of file
diff --git a/arch/x86/rpal/Makefile b/arch/x86/rpal/Makefile
new file mode 100644
index 000000000000..e69de29bb2d1
--
2.20.1
Return-Path: <linux-kernel+bounces-667857-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id AAEB041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:29:22 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 268AC3B14F7
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:01 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id F298E21E082;
Fri, 30 May 2025 09:28:51 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="FGfqdXk6";
dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b="aSSlQ7nR"
Received: from mx0a-00069f02.pphosted.com (mx0a-00069f02.pphosted.com [205.220.165.32])
(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 44A92220F4E;
Fri, 30 May 2025 09:28:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=205.220.165.32
ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597330; cv=fail; b=ts+Yskfe44xOcZgJcfQ0ciasM24HDZ0qo38DgQa96Oe4eseyN7WglLWatbwdny9qj431eS1YrBlWA4sfX/isuAG3tIEZvlzddYxvQxpmTWMr20vRBOyykycOmHuWWY2ommrkYohJCl6e5sJFEcJIoILjGwr4xpO1Z1ECLW8ent4=
ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597330; c=relaxed/simple;
bh=0QKVr2JT3gUYFcKgExS+GQvbMIw5M7JfhLjoeIbi0Gk=;
h=Date:From:To:Cc:Subject:Message-ID:References:Content-Type:
Content-Disposition:In-Reply-To:MIME-Version; b=caDSOTJR3uoNBYWMSlMa2U03tSLXJKVHMJ15zv4HbvEqR7jtfp5ddId9B9uF7BJOgHotogljVJ+KoS1nMl6ECMZQhSEK3ABEOs7zQJlXco5XQikdKwTgnUfhCNl+eoiA75h8rTq2C8RPvrPANLFdHj6HMhXM1tkYBaCinkx3GYA=
ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com; spf=pass smtp.mailfrom=oracle.com; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b=FGfqdXk6; dkim=pass (1024-bit key) header.d=oracle.onmicrosoft.com header.i=@oracle.onmicrosoft.com header.b=aSSlQ7nR; arc=fail smtp.client-ip=205.220.165.32
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oracle.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oracle.com
Received: from pps.filterd (m0246629.ppops.net [127.0.0.1])
by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U6u4QK013019;
Fri, 30 May 2025 09:28:19 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc
:content-type:date:from:in-reply-to:message-id:mime-version
:references:subject:to; s=corp-2025-04-25; bh=mQeLNDmcmbWkV8TfUO
3TMjmg4QdyOKYZQU8rDFcqnu4=; b=FGfqdXk6/vdXwMDWjlxgRrSlk7Gx5Ll0uw
5hX2SS0lnQQWfkD37iDONoQ8g84az7KFmjhf3kJb6AKjMrEdLoz3kUPo5YQp+O7l
wAfqg7+rzKU28ny+D+P5st8zI7lZzW2GFjb0zdSV7rr2SP6Mcn88LMdKEspf2NtB
/v33+/Kl2opO+zQx+oRovJNVhIg3RxgatL0hgvZ8OTgs66sswaqdS4ciLN2xYXJz
trwT3YlgIrV1DemIXd9nEsNNYa86a21+npjrCE5aTbixA5acqWtvYJxWH/i5/2Mh
cC/qs52rHDhiyZgFa4N6rE3AS4DC6c3JX8qVcu8VJib6K0plfBrg==
Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27])
by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 46v3pd9p3j-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 09:28:19 +0000 (GMT)
Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1])
by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 54U80hPE025697;
Fri, 30 May 2025 09:28:18 GMT
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10on2065.outbound.protection.outlook.com [40.107.93.65])
by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 46u4jkajty-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
Fri, 30 May 2025 09:28:17 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=cFKtmiNMLQwm6hDI1YlEI0ROAsDN9QQAnn9p945EYD3Xc5cH7OIjxUowithCRaNcr0YzGCKmrZrB9Vj5ARJNtDHjQJ1gE+agLgkwQy9eHWNjJTgHBKzCN/4sQI1LQgezIMZXdY1o8rBW0CEz+N4sN5LoGe5JlE41mDbkOsffFjkIsN6205ijNUo0xi802ZFIJCuKHTGcf3Y8kH+5dxpXGY0tF0Q1gth8J1CUsNehdOdMCvAsAmYTwvBhgEB6j7tbf1+Pv053FuIePS82Ij0iE4pVS/bg8VwKY8WMyaiq8oby9VAuURtt3nIef/2BmJFUqBDeOB55WibXh9PskklwtA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=mQeLNDmcmbWkV8TfUO3TMjmg4QdyOKYZQU8rDFcqnu4=;
b=m7fGb9NpYEeMY47qxQbiN+wxnZ56buUGKOyVksEuMgT88msPkXU4HxwGa5YIrOP/lWiBNoe6pmJAV6QQCB+x8/nP+CI/upwVRi37k6brggmWNniTo0ChzmGXAvETsAt9WBXCA+FCgNQkoM26M+SY74F6bQoljQLaiWkseul98DhYb0h+re9mn36/V5ezqEZNgmihRk2aRGQ2go9h0w7xrqwrNNHLuOte6MBhjHTH8cTU9De74d7q16h+P5llQeHYyIiVZYqK6bUeh0j9RUIG6nVsTdKGQQnEDP1LnaCUMHtK1z2r9F8EyhiHxlXVmVWdCZk/7vqqQrZMiWvzE83rxQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
dkim=pass header.d=oracle.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=mQeLNDmcmbWkV8TfUO3TMjmg4QdyOKYZQU8rDFcqnu4=;
b=aSSlQ7nRRs49685uVjGnBnScjYH7QZilLqGiBz5c6aZ4ixg9CImOGJ1B9ceqhQLkRC5h2RgLvRdTzyIFIMU8GvlKpy/Cm930CxRol47xvwZDe2Vs9yttIySke65DiXjOlxuskF8kkP3nuu1cMj7pGlebX7TUcp7ZvnKqAnsxHx0=
Received: from DM4PR10MB8218.namprd10.prod.outlook.com (2603:10b6:8:1cc::16)
by SN4PR10MB5656.namprd10.prod.outlook.com (2603:10b6:806:20f::18) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8746.38; Fri, 30 May
2025 09:28:13 +0000
Received: from DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2]) by DM4PR10MB8218.namprd10.prod.outlook.com
([fe80::2650:55cf:2816:5f2%5]) with mapi id 15.20.8746.030; Fri, 30 May 2025
09:28:13 +0000
Date: Fri, 30 May 2025 10:28:11 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
To: Pu Lehui <pulehui@xxxxxxxxxxxxxxx>
Cc: mhiramat@xxxxxxxxxx, oleg@xxxxxxxxxx, peterz@xxxxxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx, Liam.Howlett@xxxxxxxxxx, vbabka@xxxxxxx,
jannh@xxxxxxxxxx, pfalcato@xxxxxxx, linux-mm@xxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, stable@xxxxxxxxxxxxxxx,
pulehui@xxxxxxxxxx
Subject: Re: [PATCH v1 1/4] mm: Fix uprobe pte be overwritten when expanding
vma
Message-ID: <2a13548c-afbb-40b2-a9b4-326b3958ba29@lucifer.local>
References: <20250529155650.4017699-1-pulehui@xxxxxxxxxxxxxxx>
<20250529155650.4017699-2-pulehui@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20250529155650.4017699-2-pulehui@xxxxxxxxxxxxxxx>
X-ClientProxiedBy: LO4P123CA0491.GBRP123.PROD.OUTLOOK.COM
(2603:10a6:600:1ab::10) To DM4PR10MB8218.namprd10.prod.outlook.com
(2603:10b6:8:1cc::16)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DM4PR10MB8218:EE_|SN4PR10MB5656:EE_
X-MS-Office365-Filtering-Correlation-Id: d8e47410-b2d9-4d55-e7ce-08dd9f5c4d34
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;ARA:13230040|376014|7416014|1800799024|366016;
X-Microsoft-Antispam-Message-Info:
=?us-ascii?Q?0QzBwuu98vbqAYRiHngK9n5X/RsUcJFYwQ340nRJ7BqoW9JHyeJ0QnZts9qP?=
=?us-ascii?Q?wi/BiACrmZiWGoAE+2DMdTm/4EXq9M5Db3T6AcbL+V1RGwDpT4I+xS679LY7?=
=?us-ascii?Q?X6V8mYad8VYkLtdPFa60MIEKM67X8Dr7dUgAfYBz+SuZqAPjTuWIa8EzWlXf?=
=?us-ascii?Q?L8nfr5be9BaLtO4PM6xrTHBX9YbLvGinv/W08i4rukoJst0iDlTiRDvZO56W?=
=?us-ascii?Q?fZ0MXC8DF5EyFpo9BrZUzCEePxFBAX83ImW4gFqIxOgKdMvr1IuIOJ6Ge2dq?=
=?us-ascii?Q?oL/2W17hK6CA4YpLfn45wDupoz3LfShe6mwloJeniANfghcmaBxrfAbdsQOw?=
=?us-ascii?Q?okjcpMv7lC6SWO1qdLZEVY/Y5ifc/ppyueA/fp54vo3ai15c/cXIo4fOcrMD?=
=?us-ascii?Q?cwUJeJ5573Kuw5GH7hm3YyFKNszVrT9tfMPnHAE2dzI3O3LotJvNsr2cXyav?=
=?us-ascii?Q?z9mzoFBayWa9BxDD1dWp6CnmFfI8DdUQaQ/1tem8AfXxzrq9xsprddufR1Ah?=
=?us-ascii?Q?MV3IpkYIK8rSQlxCNKgUPw6zQYuYg7uOPOr1uIpG57hP2MZDFDbgezICFOKG?=
=?us-ascii?Q?KBxOHull6n9SYyH43mC47mk9rQ8En/CYnVyLlldpxyyGsx6o8THJXB700UhN?=
=?us-ascii?Q?+JoC+wb2qGJ16k/DT7Xip0XoZhWNJTxZbeAuFJy+VhsYD1r/qQRm9CaWmyOy?=
=?us-ascii?Q?IzuSau3jo0VnQfxFHia5PAzW9WG3UiEvWd/dv6HUBuMOz1zo1Ti5htm4pwlf?=
=?us-ascii?Q?FFKhAuxeaAxhhbMbdobwsjnydJLoZI6W+sKISJddk05yPzQECLwElu6p4p0O?=
=?us-ascii?Q?JV5/RmwOLOt+IwOm4urdhuv+12kwcncsh+gZgRhn3iFTZqIvM5BzmSGnTJLS?=
=?us-ascii?Q?wZhFFL8EvxdzCtaV7bM/WHHCVszfhttWFhuW2hH4E+wsqWqHWYd4JgYeU79q?=
=?us-ascii?Q?z+MtJJKNTBPYnPUEkyACtTuY+fZMF4kfUiQFtY+KeY+H48xG3YLYMRCpwyZn?=
=?us-ascii?Q?3AQYTbx9q0WlYaoz6s590zCVPU/Zom5jzBwv/3OVm6MnRCJMbvXOY/N1yWCr?=
=?us-ascii?Q?DACo99l6n5oYNn/Db5tme4abPqt5WKEfjgSKVjZzQuWLGk5rYzDAAUq273pP?=
=?us-ascii?Q?M4yCXahK/cVBJzVy4HDCfROARjF29Yhu4KmhbJltklOrQPLvGrZfZhOJVe6H?=
=?us-ascii?Q?+xzYBciV+fFm9pffnQJ432JuH3EhErS1DEE5EVDsq3LjkbcqDUys9rOIs+iX?=
=?us-ascii?Q?wOKHNzHrITMrCs0hfE8qMvlfyJgzYiepq798wo3OjLckiDya8RUhOkbHaBMA?=
=?us-ascii?Q?Uh4l/k1tTrNM26nAqQv663Itc3c8RXRDc9syjxmlb5MXr7ZVlTFWt1O3h/L+?=
=?us-ascii?Q?obF7xQ8JxRW2t9uKP2JIcy8YysMg?=
X-Forefront-Antispam-Report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM4PR10MB8218.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(376014)(7416014)(1800799024)(366016);DIR:OUT;SFP:1101;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
=?us-ascii?Q?nu6TCFTq3raln7HX+IpZHGCKTjwsNnwojeZtx42+Fj4arHZVWn/4pYA7njd+?=
=?us-ascii?Q?TGOt3sh898KuezdYUbsUBmsR1+euZWVbJQ/OiuNDRTZ0BLLDnKn0I02qIpLL?=
=?us-ascii?Q?c6DbznmD8XXUYqGiCWRM38fl/rt2BE3h+ddkvA9+FxU48U9Dye9gOGjBPATk?=
=?us-ascii?Q?3/OS2PnCCwiV1hHP/r5TNV5/OlHZDPEWf972MjPb52aFqs6bQL0sqrmUkjgd?=
=?us-ascii?Q?zpF0ceVfeYNzD/LSpsTgZw4/IgE7sZ0/oPpS92aA20yt/E6m4NJyn2Wrtb3s?=
=?us-ascii?Q?qxyerXEv+R8NfgD3l6s0iyRcxvFM6SZXrm8rIPnD7dL54OI2Jv7ORPYfAKFk?=
=?us-ascii?Q?mwQjvT5p8j6oiz1+N95Csatnl8Uhdq/b92cwEgftJB/dv4p1cVIEKabp+e3T?=
=?us-ascii?Q?VOQ7oEtWbkm2TMA7TPrrSJp3MBcI57UbMFpfZZ4HSNddZPTW8fpecdmHDOri?=
=?us-ascii?Q?gtZ0satmnWnbiAQMyTQqvpAf6tMkHicgn6mBD8myg/SyccAdrs1Xnj9CEB6K?=
=?us-ascii?Q?scVXkLYIgH3O0oNi5cCUs1sijhjdgRguTtjfA7QIDpAVT46EWM5vjRTYUIAg?=
=?us-ascii?Q?M2+qZWVaynX1GtzQ5P2b5mj/uIWGSHxQ5c5hWXpzU+OHHZ8DtVntb/VIwavz?=
=?us-ascii?Q?YYP7J5TaIbxZfaBiHeeDW9oPNEGNtlTAv32d8WLbK1bhnx0PfjHngdkoOOGN?=
=?us-ascii?Q?ELEqCymQDNNEr1igjfxK6LVS6jv3p7BAMILkNL28GmWOA5UBGLZA8da09LeM?=
=?us-ascii?Q?Uw78Qdn5Lv+ZKk0wmUpQojWGhxMjXpqg9a8kJNFSBVxEBQP9fuIxEuNSPpfQ?=
=?us-ascii?Q?cwAQ+hLAxfleUJfnkxk6b1aDlRMjKL/d0jjqmxoSkQPqy8A8Zidn/d8/TiMp?=
=?us-ascii?Q?6TJmjR6P7OWmlwmEHnF99yTif/MI8Il2Th88o/83ZJxyoebu/2SOF+x3vKFx?=
=?us-ascii?Q?EbVi5nGcIlnAHhP7/WG3DUCpHQGDxr5/XolOBtxuFjC4SXdsfCiGHUx1L4SN?=
=?us-ascii?Q?TmAVuJ1/ffHFWPft8zk7gj1xeizPe6xaIPAuRzuCe87a4wZ5wMoSnCHwMGox?=
=?us-ascii?Q?z7XAADZcwevxJu5BZur40W6Kjk4awtsNScB6kbzhQQ6FiEOwa3eZ8a4xIbST?=
=?us-ascii?Q?UYqg1JR+Gk1ke5kSgI+13eQJYAMwtM6mAOyDMODgDWuprBM7RlIbeml2CqFt?=
=?us-ascii?Q?bwVz2rEQN6+NkIerPq3c3HC/PZKWqBFTP6OEBFYp3EvGBrbp3I0y9mqlerE+?=
=?us-ascii?Q?fjfoB5K102fhfp8nN2niCQ5/5md7z8xRUCN60vvEMKuHmmh1BCEIgel+nxz0?=
=?us-ascii?Q?S9PKwqN34pKDOl2ejrBd7rUAWOudQlwcQmpzJjXitUGM0CI1hstsMHRhbJaN?=
=?us-ascii?Q?lEDiV90ZedL57bcpZKdzjnGrVj8Go8QJuCeektWYxK5W/1yZ6RC1Rs57vsqF?=
=?us-ascii?Q?Aqo7ARyfx9fG70FSl+Zged/+r5y+12aO8g4po+tp+Mc4xPgjif+S1lpd+ybv?=
=?us-ascii?Q?Pf4FOPDVBV5MbVtX7Wblxsg6rE9u/0EWvNK4oUZt651U+IUUypmbkrWitwvf?=
=?us-ascii?Q?wsuTvPtf6ce6s84ZYwTmopRXLivvge9uZiS62Umh9VyVP15jzoP9aoljyclh?=
=?us-ascii?Q?DQ=3D=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0:
+FAit5mjNs15JIGppEKQllAcDT7WT1LaQJ/Y5xPrErn5HnvHpcT+rkAldwnMV3veQTdV5od7VmhclsMc6HAw1/r74oXZp2drFFiLQjSiBfnEsINh5R2aCdQNHdBMuBlVR0gU+p0c1yWjvSR2e2l74PVdeoX9N/D855gZy80Vy6qsoj4s5sUX8zsGpiLK/Xn7eqVuRVSWN+zWrwaJ8CISKy2YlcKATPDdKct8aVkPVDkDbt+A2o1fPtZj8klWz5hjRu7cgZKVcp+ACuhBUIplCAp+rKRRDPL8Fz1h4vz/sAxpssBdJ929lMIZ2XZtCuIjbT64YnSHgtTN1pfQKsFxjwu07Vltp7L0RltYODXO0qOhIi0TN6aqUmQtEWI3xalBjT5zdAP5FmZKZ4h1gzI68BHewXYdJQ3RQ9VIEAkpm+vDbVVhwbOSB8A1SG+C9g8H47CJRu/dXVEjULvPUUj7HyHH/sk93Ka+o4pny6/MdDW3vTw4P6qsSbHfwArp00XndLggkcQZ4DFMFeJWbRAI9FCpL/D3WDOZ7htwhHYtze76BkU4JE/kH2Rrt0De8Dnq+Z9AxX6pZ1oOZRtYo8z410gLe9j/08m6bcqrTeUypco=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d8e47410-b2d9-4d55-e7ce-08dd9f5c4d34
X-MS-Exchange-CrossTenant-AuthSource: DM4PR10MB8218.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 May 2025 09:28:13.8308
(UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: YNcEX+JOwBnAdWveos+ddc6RHBwrqcxtakE7nEFEswPAepx6X+qFoTa7CaAX+8pRRnyhtQ5SrjJzGOk+xzzfwhgso901CZB0WHGdvKOEsWo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR10MB5656
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 phishscore=0
adultscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0
classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2505160000
definitions=main-2505300080
X-Proofpoint-ORIG-GUID: FpzKDnr82wBU-FoNmizRI7i06f64HgRW
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA4MCBTYWx0ZWRfXwgsaveThVlJq Q0XFpt7p4q0mCCppQvjh8zCMkM0Ug4+F91Epb7VDXpk3Rv3IbC3nn4unSzZl7WNL4HYk/I9n4+o ywKVATvFxrabzcGjGigK3uhJuJ6aFnkmX745kRja4AdkwWVERI99R2JExwzy45CVQMSbMuWYVdS
md0/0dB1yGE8FS+zvxQp8b/d4OLv6NXLlMwKdtJtrSX7MobYVJg+rZFJx3f5TJ6S4RUN1pceAMu UPfxgfFBLe/iDOiqKox8ZGPUsbDc6/yf8psWP2UbG0x9rFnBkiiISjGbJhMcaivMsOe9o1OEOZw CiXLY7fhhg9vnCgvvJHJL5NWR/xKKGYsqO2i2Bz/e/s1hDQGqAuDrmzp8CDnHnAenvC53USuYyg
5dqPDGMXPDNLRpwzaeZm4CJdQ/riCYv1WTocALjdbetIMrVQYl5UjVnrCWlAdhJSmUWppKsz
X-Authority-Analysis: v=2.4 cv=UZNRSLSN c=1 sm=1 tr=0 ts=68397a33 b=1 cx=c_pps a=qoll8+KPOyaMroiJ2sR5sw==:117 a=qoll8+KPOyaMroiJ2sR5sw==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=wKuvFiaSGQ0qltdbU6+NXLB8nM8=:19
a=Ol13hO9ccFRV9qXi2t6ftBPywas=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=dt9VzEwgFbYA:10 a=GoEa3M9JfhUA:10 a=VwQbUJbxAAAA:8 a=1XWaLZrsAAAA:8 a=i0EeH86SAAAA:8 a=yPCof4ZbAAAA:8 a=2Ei7gBovnH3WVZM9m-IA:9 a=CjuIK1q_8ugA:10 cc=ntf awl=host:13207
X-Proofpoint-GUID: FpzKDnr82wBU-FoNmizRI7i06f64HgRW
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Thu, May 29, 2025 at 03:56:47PM +0000, Pu Lehui wrote:
> From: Pu Lehui <pulehui@xxxxxxxxxx>
>
> We encountered a BUG alert triggered by Syzkaller as follows:
> BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1
>
> And we can reproduce it with the following steps:
> 1. register uprobe on file at zero offset
> 2. mmap the file at zero offset:
> addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);
> 3. mremap part of vma1 to new vma2:
> addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);
> 4. mremap back to orig addr1:
> mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);
>
> In the step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new
> vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from
> the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096]. In
> tht step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to
> the addr range [addr1, addr1 + 4096]. Since the addr range
> [addr1 + 4096, addr1 + 8192] still maps the file, it will take
> vma_merge_new_range to expand the range, and then do uprobe_mmap in
> vma_complete. Since the merged vma pgoff is also zero offset, it will
> install uprobe anon page to the merged vma. However, the upcomming
> move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte
> to the merged vma, will overwrite the newly uprobe pte in the merged
> vma, and lead that pte to be orphan.
>
> Since the uprobe pte will be remapped to the merged vma, we can
> remove the unnecessary uprobe_mmap upon merged vma.
>
> This problem was first find in linux-6.6.y and also exists in the
> community syzkaller:
> https://lore.kernel.org/all/000000000000ada39605a5e71711@xxxxxxxxxx/T/
>
> CC: stable@xxxxxxxxxxxxxxx
> Fixes: 2b1444983508 ("uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints")
> Suggested-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
> Signed-off-by: Pu Lehui <pulehui@xxxxxxxxxx>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
> ---
> mm/vma.c | 20 +++++++++++++++++---
> mm/vma.h | 7 +++++++
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/mm/vma.c b/mm/vma.c
> index 1c6595f282e5..b2d7c03d8aa4 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -169,6 +169,9 @@ static void init_multi_vma_prep(struct vma_prepare *vp,
> vp->file = vma->vm_file;
> if (vp->file)
> vp->mapping = vma->vm_file->f_mapping;
> +
> + if (vmg && vmg->skip_vma_uprobe)
> + vp->skip_vma_uprobe = true;
> }
>
> /*
> @@ -358,10 +361,13 @@ static void vma_complete(struct vma_prepare *vp, struct vma_iterator *vmi,
>
> if (vp->file) {
> i_mmap_unlock_write(vp->mapping);
> - uprobe_mmap(vp->vma);
>
> - if (vp->adj_next)
> - uprobe_mmap(vp->adj_next);
> + if (!vp->skip_vma_uprobe) {
> + uprobe_mmap(vp->vma);
> +
> + if (vp->adj_next)
> + uprobe_mmap(vp->adj_next);
> + }
> }
>
> if (vp->remove) {
> @@ -1823,6 +1829,14 @@ struct vm_area_struct *copy_vma(struct vm_area_struct **vmap,
> faulted_in_anon_vma = false;
> }
>
> + /*
> + * If the VMA we are copying might contain a uprobe PTE, ensure
> + * that we do not establish one upon merge. Otherwise, when mremap()
> + * moves page tables, it will orphan the newly created PTE.
> + */
> + if (vma->vm_file)
> + vmg.skip_vma_uprobe = true;
> +
> new_vma = find_vma_prev(mm, addr, &vmg.prev);
> if (new_vma && new_vma->vm_start < addr + len)
> return NULL; /* should never get here */
> diff --git a/mm/vma.h b/mm/vma.h
> index 9a8af9be29a8..0db066e7a45d 100644
> --- a/mm/vma.h
> +++ b/mm/vma.h
> @@ -19,6 +19,8 @@ struct vma_prepare {
> struct vm_area_struct *insert;
> struct vm_area_struct *remove;
> struct vm_area_struct *remove2;
> +
> + bool skip_vma_uprobe :1;
> };
>
> struct unlink_vma_file_batch {
> @@ -120,6 +122,11 @@ struct vma_merge_struct {
> */
> bool give_up_on_oom :1;
>
> + /*
> + * If set, skip uprobe_mmap upon merged vma.
> + */
> + bool skip_vma_uprobe :1;
> +
> /* Internal flags set during merge process: */
>
> /*
> --
> 2.34.1
>
Return-Path: <linux-kernel+bounces-667858-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id D09B641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:29:44 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id B99D91BA7F45
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:53 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 35548221FDE;
Fri, 30 May 2025 09:29:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="HZy7M2u+"
Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43])
(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 BF7AA220F4E
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:57 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597339; cv=none; b=Pthsy8hsuuuVxx6duykfYVzkdIkgGmmko7K+qu12N/tLgcRtMWl6Dk9ozKJ0leY8lePuvEjZpebRCjfHUUoPBVNu715Sh3Z4YA4wwOYkfQw+l/LSCpye1Xcqt1OHh4O3ovGwcdr1waHFExfLOAC7BJ9vYqNZVG/lSIjg01An+wY=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597339; c=relaxed/simple;
bh=Vc7NbMjHAO2dZd+RVkA7mhRl8eTmZhbc/UEd+aji6oE=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=taRaqeYszlQhGZE3TLY0u4MzWsezlGOPSQfiammPK6QtIyXvolAc4jLjlvCtYUX9SRtdaHOOuX9bnJFUUSClA0W0G+eFSP5hTzMbRGACuJWJucFR2ViHaShdRVunE8WMCfK36eswiWmnPD3esqkVJqOC8qOvhx8dAtVGNKooFqA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=HZy7M2u+; arc=none smtp.client-ip=209.85.216.43
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-3122368d7c4so1174147a91.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597337; x=1749202137; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=tHtdmIKid/axHIhLP0cCYOHEJ6hr+IyJWWADeBRNQ/E=;
b=HZy7M2u+7GpR0jjgD3VvbuWXLAZzxDhZ8MFb1aLnTzO/OdeLksVR4Sp4RcuDwi1+uV
J8ZKCyEPW6zPmzQtYc0CBUyZG41mWqwWNMPcjBinHleStwkLACO2cXrXusHc5q4kwBQD
wciRQn7IEeNK+1xJkLX/PTIq3NVK4yOddbKkR/kw+Hx7gbzEo0rEe6+tNOidiU1DmfkK
xAw2isnYIzbo4J1ZCCK2TBSLIdiwDXTDjTE+ZN7fGPKU6yqNek+wg51KzWEdfn6xY9hh
gNqWdIXaNdt5XXNDbtOGrJJe8yWtI/eqFBNTr3/MKjcJdUrn8ErZbH9hCYgQm8wQCh6t
W3Nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597337; x=1749202137;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=tHtdmIKid/axHIhLP0cCYOHEJ6hr+IyJWWADeBRNQ/E=;
b=BfkObf+EoTohFqbAEmo85lZGo2x7J2VkLjP7tCOdFA4EyJs9JKqODHyqSPC7OODVq+
S2vwoJZUT0BqckxjgKZM6MmjHHHg2hA+5oAi+OJK2/yjUuMsYA5NBGf4kBrMqCldwBj7
rp3Gb8Xg6kYkqhprKFLBl2eXhYE6okM+Prv/TsYUCCivmBVPVKBAsnfpNMKd4WLM7YBI
f6B8hbzadC3HJ7NeVospo3o0M4FdEzMdVakbL5SH8sSW34eVnAnT7caCaZy/8wzZBNZT
ySgpla6Rilp4cgBXLV8v0hZ/kwLYeMM7doOTqr1olv42LZ03VMcaHy9sGsMw2uhv51oO
pzHQ==
X-Forwarded-Encrypted: i=1; AJvYcCWXk/3jTOPe9wip6XLZJWrFj8ypPJwD4o4gMs2Klhynrw+5nODaybEmkUKPpVfGu2gRegL5duRJSOhb7xM=@vger.kernel.org
X-Gm-Message-State: AOJu0YyjuPK3MqKq8wu/ifcI7vzSq6MR9cnvKarP3jC4S9QGOqzQtDc9
y9WGblwDzPUVg/AK6OQxzU25mSHcyMODnTGsSFsKAs0MWm1h+kztWInB4acqTyLB72g=
X-Gm-Gg: ASbGnctrMiOnjf+9WIf30FlInN/E9EPsPcEyhCu+Yv/FS/rHLKMFGe0jOOms0Krj70F
7v3RCftzJKcHjA20rUVjdFdgRJGyjGmKmqqCIrvCt9KVzqDy8nopMFJzu1bYGfKLJ6WaTn6/yA7
aIoADXEJguddxS26IKbFFL8j3tmhxTEMrsuxzAiZfIZ65XSnH0uTaJ9ynAeOs+pKvaFBThGtyVu
l+PbHeRDyhoNzXIdlEsck119rXt7e3HDW5TZgdLJTDEN0o/ABRRmu5dJNj9uwEcMephidu0Fx0s
XBSLRP2Mu82Z/UT9iNwn6vB/j0+1zAhwRYoD8MeMKb+xNNFkTAma+CrA1DvwEJudfwSCP6+o9/b
ERigjD9ErRzMnWWzLATUN
X-Google-Smtp-Source: AGHT+IF0jYnDB+2g7ZGuSYnYueYT47NoQiuIJK3WP4+gDWcAJJRqzT7RDm6Iq/1/p9n6sv5YTlCMUg==
X-Received: by 2002:a17:90b:2f8c:b0:2ee:d371:3227 with SMTP id 98e67ed59e1d1-31241735b7fmr4743727a91.17.1748597336731;
Fri, 30 May 2025 02:28:56 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.28.41
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:28:56 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 02/35] RPAL: add struct rpal_service
Date: Fri, 30 May 2025 17:27:30 +0800
Message-Id: <58ca31eb0711ad773c19a167e6888173a64ff890.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Each process that uses RPAL features is called an RPAL service.
This patch adds the RPAL header file rpal.h and defines the rpal_service
structure. The struct rpal_service uses a dedicated kmem_cache for
allocation and deallocation, and atomic variables to maintain references
to the struct rpal_service. Additionally, the patch introduces the
rpal_get_service() and rpal_put_service() interfaces to manage reference
counts.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/Makefile | 5 ++++
arch/x86/rpal/core.c | 32 +++++++++++++++++++++++
arch/x86/rpal/internal.h | 13 ++++++++++
arch/x86/rpal/service.c | 56 ++++++++++++++++++++++++++++++++++++++++
include/linux/rpal.h | 43 ++++++++++++++++++++++++++++++
5 files changed, 149 insertions(+)
create mode 100644 arch/x86/rpal/core.c
create mode 100644 arch/x86/rpal/internal.h
create mode 100644 arch/x86/rpal/service.c
create mode 100644 include/linux/rpal.h
diff --git a/arch/x86/rpal/Makefile b/arch/x86/rpal/Makefile
index e69de29bb2d1..ee3698b5a9b3 100644
--- a/arch/x86/rpal/Makefile
+++ b/arch/x86/rpal/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_RPAL) += rpal.o
+
+rpal-y := service.o core.o
diff --git a/arch/x86/rpal/core.c b/arch/x86/rpal/core.c
new file mode 100644
index 000000000000..495dbc1b1536
--- /dev/null
+++ b/arch/x86/rpal/core.c
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RPAL service level operations
+ * Copyright (c) 2025, ByteDance. All rights reserved.
+ *
+ * Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
+ */
+
+#include <linux/rpal.h>
+
+#include "internal.h"
+
+int __init rpal_init(void);
+
+bool rpal_inited;
+
+int __init rpal_init(void)
+{
+ int ret = 0;
+
+ ret = rpal_service_init();
+ if (ret)
+ goto fail;
+
+ rpal_inited = true;
+ return 0;
+
+fail:
+ rpal_err("rpal init fail\n");
+ return -1;
+}
+subsys_initcall(rpal_init);
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
new file mode 100644
index 000000000000..e44e6fc79677
--- /dev/null
+++ b/arch/x86/rpal/internal.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * RPAL service level operations
+ * Copyright (c) 2025, ByteDance. All rights reserved.
+ *
+ * Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
+ */
+
+extern bool rpal_inited;
+
+/* service.c */
+int __init rpal_service_init(void);
+void __init rpal_service_exit(void);
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
new file mode 100644
index 000000000000..c8e609798d4f
--- /dev/null
+++ b/arch/x86/rpal/service.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RPAL service level operations
+ * Copyright (c) 2025, ByteDance. All rights reserved.
+ *
+ * Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
+ */
+
+#include <linux/rpal.h>
+#include <linux/sched/signal.h>
+#include <linux/sched/task.h>
+#include <linux/slab.h>
+
+#include "internal.h"
+
+static struct kmem_cache *service_cache;
+
+static void __rpal_put_service(struct rpal_service *rs)
+{
+ kmem_cache_free(service_cache, rs);
+}
+
+struct rpal_service *rpal_get_service(struct rpal_service *rs)
+{
+ if (!rs)
+ return NULL;
+ atomic_inc(&rs->refcnt);
+ return rs;
+}
+
+void rpal_put_service(struct rpal_service *rs)
+{
+ if (!rs)
+ return;
+
+ if (atomic_dec_and_test(&rs->refcnt))
+ __rpal_put_service(rs);
+}
+
+int __init rpal_service_init(void)
+{
+ service_cache = kmem_cache_create("rpal_service_cache",
+ sizeof(struct rpal_service), 0,
+ SLAB_PANIC, NULL);
+ if (!service_cache) {
+ rpal_err("service init fail\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+void __init rpal_service_exit(void)
+{
+ kmem_cache_destroy(service_cache);
+}
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
new file mode 100644
index 000000000000..73468884cc5d
--- /dev/null
+++ b/include/linux/rpal.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * RPAL service level operations
+ * Copyright (c) 2025, ByteDance. All rights reserved.
+ *
+ * Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
+ */
+
+#ifndef _LINUX_RPAL_H
+#define _LINUX_RPAL_H
+
+#include <linux/sched.h>
+#include <linux/types.h>
+#include <linux/atomic.h>
+
+#define RPAL_ERROR_MSG "rpal error: "
+#define rpal_err(x...) pr_err(RPAL_ERROR_MSG x)
+#define rpal_err_ratelimited(x...) pr_err_ratelimited(RPAL_ERROR_MSG x)
+
+struct rpal_service {
+ /* reference count of this struct */
+ atomic_t refcnt;
+};
+
+/**
+ * @brief get new reference to a rpal service, a corresponding
+ * rpal_put_service() should be called later by the caller.
+ *
+ * @param rs The struct rpal_service to get.
+ *
+ * @return new reference of struct rpal_service.
+ */
+struct rpal_service *rpal_get_service(struct rpal_service *rs);
+
+/**
+ * @brief put a reference to a rpal service. If the reference count of
+ * the service turns to be 0, then release its struct rpal_service.
+ * rpal_put_service() may be used in an atomic context.
+ *
+ * @param rs The struct rpal_service to put.
+ */
+void rpal_put_service(struct rpal_service *rs);
+#endif
--
2.20.1
Return-Path: <linux-kernel+bounces-667859-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 8361B41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:30:05 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 984D21BA8212
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:13 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id B11602236FF;
Fri, 30 May 2025 09:29:04 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="a0DGJ29c"
Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131])
(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 1272421CA1C;
Fri, 30 May 2025 09:29:01 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597343; cv=none; b=NzAvr7T5yEqlvO6DDMWx9Hf4NVRg/cY3U3B7dWzMcaARxzDOlaTA0Dx/3eafbNbc1MRfX6jDrJOaMRwO6CgRsR83/ebuk+JrjnZXAsH0xHE6joX9b0UVysMsXbvvkcdLI+JIJSu1RyzHRSUJoQcuJ3lzSYuTDdYiR7OZLt45XR8=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597343; c=relaxed/simple;
bh=+nnAW901u/7kim1WteT+SbToRv8MGG7Jlhk2AneGY0w=;
h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
MIME-Version; b=fIrjjgG42qhiu/T3iVTi1Fz8GQ6oSEPbZhoy8UnSAb21gzEyBFbd7ick2fc5nmlfaLa1xvi+M8Gv/sgcnNjKJP2tnrjee50eTWvMLoQuK5Xs5I4peRs21QZpkiaZ5teaCUBeNhvyWBlg3nAE++EDOOePu3ppt/jjzmn/kYhPFzo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=qualcomm.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=a0DGJ29c; arc=none smtp.client-ip=205.220.180.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qualcomm.com
Received: from pps.filterd (m0279872.ppops.net [127.0.0.1])
by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U0HtcL011636;
Fri, 30 May 2025 09:28:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
cc:content-transfer-encoding:date:from:in-reply-to:message-id
:mime-version:references:subject:to; s=qcppdkim1; bh=rPTtssiBb0c
T02GWRXrKHcoWtGBOpMfNNrIk01XIVOg=; b=a0DGJ29cja4baqDAndviQ+8Yvry
0lXgESpXEPQSGsWlGQ4iEOFzpnC6NZXmgO/vFaVkUKC+eNBMJUxdNk+RswMR8o5Z
jPYBGEG+EPkaAG1syLu16U7Ku3avCAMEkGa+qfZh4vuMVseNCt5QW9/G0XEK4InL
RUEvRxsU5jMJC9swr+Hyia9pE6ClhyCfwmPH2FQON1U4ZapqDyYAAuhZVsYZ7HN7
CZZxU/f29RHgJdJLKRIK+ZqB/34kMDThRUq7/4bxbBoVAAhM0moQuQoXZaxl9Q18
Ikcd2fVjBLmyMOo0XBk3aDw4fnviDsg34G4OCDQNIM3WBZrVGx8ZDh1/axg==
Received: from apblrppmta01.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19])
by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 46u6g98jnh-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:56 +0000 (GMT)
Received: from pps.filterd (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTP id 54U9SqLb008748;
Fri, 30 May 2025 09:28:52 GMT
Received: from pps.reinject (localhost [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 46u76my9gs-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: from APBLRPPMTA01.qualcomm.com (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54U9SqIn008724;
Fri, 30 May 2025 09:28:52 GMT
Received: from hu-devc-hyd-u22-c.qualcomm.com (hu-wasimn-hyd.qualcomm.com [10.147.246.180])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 54U9SqNJ008718
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: by hu-devc-hyd-u22-c.qualcomm.com (Postfix, from userid 3944840)
id 2E1FF5AF; Fri, 30 May 2025 14:58:51 +0530 (+0530)
From: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
To: Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, kernel@xxxxxxxxxxx,
kernel@xxxxxxxxxxxxxxxx, Pratyush Brahma <quic_pbrahma@xxxxxxxxxxx>,
Prakash Gupta <quic_guptap@xxxxxxxxxxx>,
Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
Subject: [PATCH v9 2/4] arm64: dts: qcom: iq9: Introduce new memory map for qcs9100/qcs9075
Date: Fri, 30 May 2025 14:58:45 +0530
Message-ID: <20250530092850.631831-3-quic_wasimn@xxxxxxxxxxx>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
References: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-QCInternal: smtphost
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Authority-Analysis: v=2.4 cv=d4b1yQjE c=1 sm=1 tr=0 ts=68397a59 cx=c_pps
a=Ou0eQOY4+eZoSc0qltEV5Q==:117 a=Ou0eQOY4+eZoSc0qltEV5Q==:17
a=dt9VzEwgFbYA:10 a=COk6AnOGAAAA:8 a=6-hPHUfSg4vTJukFU5oA:9
a=TjNXssC_j7lpFel5tvFf:22
X-Proofpoint-ORIG-GUID: kem6xOdGyRCOom30fZYvtWoy0Bhp6U93
X-Proofpoint-GUID: kem6xOdGyRCOom30fZYvtWoy0Bhp6U93
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA4MSBTYWx0ZWRfX3Mck+3BoW+h/
Q7dJW143CPLjZJUJrq917AL/r9THrq5p5L+1r4qOQb5ctejWR8WU2fEvo9VveN/ueFwhOp+vxD2
nao/Sb9AVwF2OJvuG/MkXn6H9DmU1WcMK1dq6zJ1aFRPOktiWfDYaWgENTYdWsWyedHSWyFDZ4k
JoEZ+DykQqCxQsKqQaib94+8gpiGhiiXyzH1QQKA67s4iz3svacqNp7ED1W8v4wb1BSHFfHlPVh
VGVJgrfIcb1eUaYWj+QvktZ/W2SHAXys5SqFwawnFQac8ShL31F3xIKvYtpfSnmlsvREeITJ/JG
+Cs8u++K0fqpDFGSdCikGrm43yFnGLsoeiNQQfgVdyOBg1yHGYaZuT07eZVBDvS2GA8St1Fsfsv
cUXM4Tz/ZJnM+hM3AABvHxOWw84PBpI26BnbvL46iQdn5ROeXeFm2fD8WKVEmvUYepXc9B7N
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
adultscore=0 suspectscore=0 malwarescore=0 phishscore=0 mlxlogscore=999
lowpriorityscore=0 priorityscore=1501 bulkscore=0 spamscore=0 clxscore=1015
impostorscore=0 mlxscore=0 classifier=spam authscore=0 authtc=n/a authcc=
route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505160000
definitions=main-2505300081
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
From: Pratyush Brahma <quic_pbrahma@xxxxxxxxxxx>
SA8775P has a memory map which caters to the auto specific requirements.
QCS9100 & QCS9075 are its IOT variants (with marketing name as IQ9) which
inherit the memory map of SA8775P require a slightly different memory
map as compared to SA8775P auto parts.
This new memory map is applicable for all the IoT boards which inherit
the initial SA8775P memory map. This is not applicable for non-IoT
boards.
Some new carveouts (viz. gunyah_md and a few pil dtb carveouts) have been
introduced as part of firmware updates for IoT. The size and base address
have been updated for video PIL carveout compared to SA8775P since it is
being brought up for the first time on IoT boards. The base addresses
of the rest of the PIL carveouts have been updated to accommodate the
change in size of video since PIL regions are relocatable and their
functionality is not impacted due to this change. The size of camera
pil has also been increased without breaking any feature.
The size of trusted apps carveout has also been reduced since it is
sufficient to meet IoT requirements. Also, audio_mdf_mem & tz_ffi_mem
carveout and its corresponding scm reference has been removed as these
are not required for IoT parts.
Incorporate these changes in the updated memory map.
Signed-off-by: Pratyush Brahma <quic_pbrahma@xxxxxxxxxxx>
Signed-off-by: Prakash Gupta <quic_guptap@xxxxxxxxxxx>
Signed-off-by: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
---
.../boot/dts/qcom/iq9-reserved-memory.dtsi | 113 ++++++++++++++++++
1 file changed, 113 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/iq9-reserved-memory.dtsi
diff --git a/arch/arm64/boot/dts/qcom/iq9-reserved-memory.dtsi b/arch/arm64/boot/dts/qcom/iq9-reserved-memory.dtsi
new file mode 100644
index 000000000000..ff2600eb5e3d
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/iq9-reserved-memory.dtsi
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: BSD-3-Clause
+
+/*
+ * Copyright (c) 2025 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/delete-node/ &pil_camera_mem;
+/delete-node/ &pil_adsp_mem;
+/delete-node/ &pil_gdsp0_mem;
+/delete-node/ &pil_gdsp1_mem;
+/delete-node/ &pil_cdsp0_mem;
+/delete-node/ &pil_gpu_mem;
+/delete-node/ &pil_cdsp1_mem;
+/delete-node/ &pil_cvp_mem;
+/delete-node/ &pil_video_mem;
+/delete-node/ &audio_mdf_mem;
+/delete-node/ &trusted_apps_mem;
+/delete-node/ &hyptz_reserved_mem;
+/delete-node/ &tz_ffi_mem;
+
+/ {
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gunyah_md_mem: gunyah-md@91a80000 {
+ reg = <0x0 0x91a80000 0x0 0x80000>;
+ no-map;
+ };
+
+ pil_camera_mem: pil-camera@95200000 {
+ reg = <0x0 0x95200000 0x0 0x700000>;
+ no-map;
+ };
+
+ pil_adsp_mem: pil-adsp@95900000 {
+ reg = <0x0 0x95900000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ q6_adsp_dtb_mem: q6-adsp-dtb@97700000 {
+ reg = <0x0 0x97700000 0x0 0x80000>;
+ no-map;
+ };
+
+ q6_gdsp0_dtb_mem: q6-gdsp0-dtb@97780000 {
+ reg = <0x0 0x97780000 0x0 0x80000>;
+ no-map;
+ };
+
+ pil_gdsp0_mem: pil-gdsp0@97800000 {
+ reg = <0x0 0x97800000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ pil_gdsp1_mem: pil-gdsp1@99600000 {
+ reg = <0x0 0x99600000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ q6_gdsp1_dtb_mem: q6-gdsp1-dtb@9b400000 {
+ reg = <0x0 0x9b400000 0x0 0x80000>;
+ no-map;
+ };
+
+ q6_cdsp0_dtb_mem: q6-cdsp0-dtb@9b480000 {
+ reg = <0x0 0x9b480000 0x0 0x80000>;
+ no-map;
+ };
+
+ pil_cdsp0_mem: pil-cdsp0@9b500000 {
+ reg = <0x0 0x9b500000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ pil_gpu_mem: pil-gpu@9d300000 {
+ reg = <0x0 0x9d300000 0x0 0x2000>;
+ no-map;
+ };
+
+ q6_cdsp1_dtb_mem: q6-cdsp1-dtb@9d380000 {
+ reg = <0x0 0x9d380000 0x0 0x80000>;
+ no-map;
+ };
+
+ pil_cdsp1_mem: pil-cdsp1@9d400000 {
+ reg = <0x0 0x9d400000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ pil_cvp_mem: pil-cvp@9f200000 {
+ reg = <0x0 0x9f200000 0x0 0x700000>;
+ no-map;
+ };
+
+ pil_video_mem: pil-video@9f900000 {
+ reg = <0x0 0x9f900000 0x0 0x1000000>;
+ no-map;
+ };
+
+ trusted_apps_mem: trusted-apps@d1900000 {
+ reg = <0x0 0xd1900000 0x0 0x1c00000>;
+ no-map;
+ };
+ };
+
+ firmware {
+ scm {
+ /delete-property/ memory-region;
+ };
+ };
+};
--
2.49.0
Return-Path: <linux-kernel+bounces-667861-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 4875341E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:30:08 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id A5CDF7A634E
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:28:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 51F3021FF25;
Fri, 30 May 2025 09:29:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="D3CpsgoY"
Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131])
(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 C8E4F21FF31;
Fri, 30 May 2025 09:29:02 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597344; cv=none; b=siqIYs65ISxvv9mDlxMtqqEp/1Ca7Q5VwaYUCwOnJswM63ne0xjlpeUzRk9nNimvdzLnG5DyWqNHVnyhsEJzi+quy1w26xHD/MRXH/5MdRz7tmkE5SXhdgFawvCPOpB40cbCqGJU/5KqNPXuR27KZ45y5+IhY3wOmedIvgS8+1Y=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597344; c=relaxed/simple;
bh=SnpVa7I426a7+tDo9ZDH4Qa/C0XkGmiVoXDvxpI+gHM=;
h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
MIME-Version; b=DQ62+uxlTwLL8mD2ZqKyBf0j6Hpwk6DX8G6omLopdfgapRfrHd+wCXk3+N1YyPbxOW4YI3yCebk/Coy8HbOfHQU+as/3Nx0KmxNx83Dqrwkixuzh5OPM1f7BCFlUPLTLe1kgXYUQBfwKIh/WcQycCu7vZ98BSfxB7lkL1pGPSMc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=qualcomm.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=D3CpsgoY; arc=none smtp.client-ip=205.220.180.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qualcomm.com
Received: from pps.filterd (m0279868.ppops.net [127.0.0.1])
by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U1pvTe005156;
Fri, 30 May 2025 09:28:58 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
cc:content-transfer-encoding:date:from:in-reply-to:message-id
:mime-version:references:subject:to; s=qcppdkim1; bh=SnpVa7I426a
7+tDo9ZDH4Qa/C0XkGmiVoXDvxpI+gHM=; b=D3CpsgoYL9PfEw8Yx+ofrasQU9m
KNqHYsrbxq6dC1iurDoqrX6JwXROHKQKNCUULjD5YQG1ECMKZQnpLfnahYcWAEJQ
fXIKf8QrSpV6a5udDqVQce4DuM8NfawV2GZwnv4y6f7+zWJjXvmaRcGhjlBnlkYB
OKSjR0KLcdZiMVlualiHgGOwqar207st6l5B6IhgZQTYum08gJCmXOP39FkKC7mD
S1tbj9EMqpXzRe1bUH4lsbvkO6rQB9yCkEawJoNdI6tF4ejYyuZ+o5rLHmcjHBgC
/EALB68cDCKa+mwtnO5Un3wEvhNJUjsgtlWAjeYeYGuowrLTve+QYW0xD2Q==
Received: from apblrppmta01.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19])
by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 46u5ek8b83-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:57 +0000 (GMT)
Received: from pps.filterd (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTP id 54U9SqMC008750;
Fri, 30 May 2025 09:28:52 GMT
Received: from pps.reinject (localhost [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 46u76my9gq-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: from APBLRPPMTA01.qualcomm.com (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54U9SqQg008722;
Fri, 30 May 2025 09:28:52 GMT
Received: from hu-devc-hyd-u22-c.qualcomm.com (hu-wasimn-hyd.qualcomm.com [10.147.246.180])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 54U9Sqc4008715
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: by hu-devc-hyd-u22-c.qualcomm.com (Postfix, from userid 3944840)
id 324A85B1; Fri, 30 May 2025 14:58:51 +0530 (+0530)
From: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
To: Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, kernel@xxxxxxxxxxx,
kernel@xxxxxxxxxxxxxxxx, Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
Subject: [PATCH v9 3/4] arm64: dts: qcom: qcs9075: Introduce QCS9075 SOM
Date: Fri, 30 May 2025 14:58:46 +0530
Message-ID: <20250530092850.631831-4-quic_wasimn@xxxxxxxxxxx>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
References: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-QCInternal: smtphost
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Authority-Analysis: v=2.4 cv=GIgIEvNK c=1 sm=1 tr=0 ts=68397a59 cx=c_pps
a=Ou0eQOY4+eZoSc0qltEV5Q==:117 a=Ou0eQOY4+eZoSc0qltEV5Q==:17
a=dt9VzEwgFbYA:10 a=COk6AnOGAAAA:8 a=wRu9zdmjipw6Plw-N58A:9
a=TjNXssC_j7lpFel5tvFf:22
X-Proofpoint-ORIG-GUID: HqP6n_lF_pMw2y1QK4t7xl6769bBOvgo
X-Proofpoint-GUID: HqP6n_lF_pMw2y1QK4t7xl6769bBOvgo
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA4MSBTYWx0ZWRfX/fPxDbMF5ezt
v0KlBeoNEic9DqMPNA2C6hq/lhO0+iSTBu4y9O5cMbx/YfYWceO1/6mFFvLw5JLANtps2MBwmVt
qtMFRrv2wmkekik7SQ5MHlWo6il4Mx2be8Po/dPKTiV1R9OcxbLcC/25iuqJ5HJUt3CVTuUuX1e
Jcb1bCRehCmdbJgmGsHMlFTUc/ysp0f9fhk8dK59HnOdqi1TaNRVHz2C4ygOUVZI9aswjNq/2ki
BNN2l9lf0u4U+4DqVyceVYHDuyjhsLx3bssng2mSSYEmKuq02lDnI8Ajt6ARYReSGnBH7laNaec
+XGzu4wVifht/FeG0i3gpnFVFYyTqFbTvJ3eyhyetbLTe9tSKdUu1pFF2KI6X6pF8diW1oLLMJK
8x90hAVsvyvjU1NVZfcv8gs509kzgnCnZ7wtlgKQmbcijy/AhhdWIltuevucA1rXv6P5kIoB
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
impostorscore=0 malwarescore=0 bulkscore=0 clxscore=1015 lowpriorityscore=0
adultscore=1 priorityscore=1501 mlxscore=0 phishscore=0 spamscore=0
suspectscore=0 mlxlogscore=788 classifier=spam authscore=0 authtc=n/a authcc=
route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505160000
definitions=main-2505300081
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
QCS9075 is an IoT variant of SA8775P SOC, most notably without
safety monitoring feature of Safety Island(SAIL) subsystem.
Add qcs9075-som.dtsi to specifies QCS9075 based SOM having SOC,
PMICs, Memory-map updates.
Use this SOM for qcs9075-iq-9075-evk board.
Signed-off-by: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/qcs9075-som.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-som.dtsi
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-som.dtsi b/arch/arm64/boot/dts/qcom/qcs9075-som.dtsi
new file mode 100644
index 000000000000..552e40c95e06
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-som.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "sa8775p.dtsi"
+#include "iq9-reserved-memory.dtsi"
+#include "sa8775p-pmics.dtsi"
--
2.49.0
Return-Path: <linux-kernel+bounces-667860-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id CD30D41E003FB
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:30:08 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 146044E3C01
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:10 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8DD7D2248AB;
Fri, 30 May 2025 09:29:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="YMM8XEXx"
Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131])
(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 8C7552222CC;
Fri, 30 May 2025 09:29:02 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597344; cv=none; b=QHXaU3DlRB05Lz0uIVi+tXCMCnoDgO3L6Fjbq1EqpGZZErL1ZMYB+0tyu+V9YdWL/fOtx6Sxf4G5U5dFzILSMoNdq+3UOpfSNh/rbaeta91QKEKULXonEUeVaA8KK7JCrqCh/5YWfEVDfJL34WBHc1w66etB4vrsxGYo6OsIrcA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597344; c=relaxed/simple;
bh=9UZrE7H6vAF+pGUfoHbDFIXFfGUnDWPrsrVbgKOW0T8=;
h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
MIME-Version; b=XjirMSQDsvwkE/92bC4UQR8cGnp/MFCayeUqi7cki12RATBd0liM4eQS2RpQ5/eN+LrovTtX0HJ5PmHAp2td1/P4SiMLgGIPGHp4p7Wy45uYZHw5Wt7g6P8EsSWNrfVICXaPr6UxULpopvLt960sQdrfGX/i+rk2lnCFh5Sz/+Y=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=qualcomm.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=YMM8XEXx; arc=none smtp.client-ip=205.220.180.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qualcomm.com
Received: from pps.filterd (m0279869.ppops.net [127.0.0.1])
by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U1IfQv003587;
Fri, 30 May 2025 09:28:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
cc:content-transfer-encoding:date:from:in-reply-to:message-id
:mime-version:references:subject:to; s=qcppdkim1; bh=pEjcvN806nZ
MhWg+HLfbExGftOGwvLxvJZxahVTbZh0=; b=YMM8XEXxJ9YMNCc1dsaexpvHFfh
ZJzoWt/pIZqC6cLGsHOqDbmACJiand6rfcdBGQFY/YjYZ//0KvC3GWe6KPoUvMoO
Av9BplvGPLLbHNYsaJXBlPNgAJstv9XT/I0/lAYyxeWcUv0ANWDg6ZBclfCMNakZ
PB2roGVqOgDjB0OA5QLNubzcKnzlHBdgsDJwiY7AmywNm/qDt3yia2nH6Kf38sVB
WmfAriMUTxnYNCwWsehEyVstSO9/ISaarleUtWG4Z2jrNX2mExF/AsytSUOMa8Ed
nn42q25QPiV2W/+wY85NblG8qGiry/TMI6IP7GcZQTWpo/QnZTvveasvZdQ==
Received: from apblrppmta01.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19])
by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 46u549rdfb-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:56 +0000 (GMT)
Received: from pps.filterd (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTP id 54U9Sqdx008749;
Fri, 30 May 2025 09:28:52 GMT
Received: from pps.reinject (localhost [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 46u76my9gr-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: from APBLRPPMTA01.qualcomm.com (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54U9SqWb008723;
Fri, 30 May 2025 09:28:52 GMT
Received: from hu-devc-hyd-u22-c.qualcomm.com (hu-wasimn-hyd.qualcomm.com [10.147.246.180])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 54U9Sq4d008716
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: by hu-devc-hyd-u22-c.qualcomm.com (Postfix, from userid 3944840)
id 36D175B3; Fri, 30 May 2025 14:58:51 +0530 (+0530)
From: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
To: Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, kernel@xxxxxxxxxxx,
kernel@xxxxxxxxxxxxxxxx, Wasim Nazir <quic_wasimn@xxxxxxxxxxx>,
Rakesh Kota <quic_kotarake@xxxxxxxxxxx>,
Sayali Lokhande <quic_sayalil@xxxxxxxxxxx>
Subject: [PATCH v9 4/4] arm64: dts: qcom: Add support for qcs9075 IQ-9075-EVK
Date: Fri, 30 May 2025 14:58:47 +0530
Message-ID: <20250530092850.631831-5-quic_wasimn@xxxxxxxxxxx>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
References: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-QCInternal: smtphost
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-GUID: 46aGDsXxsLDAwI6kCckd_1Q690K0wGZl
X-Authority-Analysis: v=2.4 cv=E9nNpbdl c=1 sm=1 tr=0 ts=68397a59 cx=c_pps
a=Ou0eQOY4+eZoSc0qltEV5Q==:117 a=Ou0eQOY4+eZoSc0qltEV5Q==:17
a=dt9VzEwgFbYA:10 a=COk6AnOGAAAA:8 a=cGvm-S34xVoSblkgu4kA:9
a=TjNXssC_j7lpFel5tvFf:22
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA4MSBTYWx0ZWRfX8jBlg0jYqb/p
SjyhCkfSKcYtVghEE2vxKmv0QpKTTzCduiyEktx2tGEfdzRtnYVC2i2dj4qpkTfWHcL0CY1bRZ+
UyQR3gT/dyznvs3dPujxl33WshDUYj+hnUYGOrL7W1/Jx8Lb3e1JXsHpMg/ivVVXLmYqluDctpQ
pUmoCGitBnP5Q7/1OcQsRjMkAYsKgf2gJtWqeGoVhsXYx9CL+oij2LOjkuCKo5JcvN5v/EbBAaS
1SQ8tmlDdO/6tN3DMztuXYrOv2P+Cu9sjIvRjxWnf9Hm4jQc/atCSX8UPsXNSvELlTIUAlAbRdg
yylLM6hmAlOoyz9CLcRWWWdqh5WJw7rGk70vIt3BWhBLpDFyqIzYPIQEVMKSY93iXQJu4h7pKRR
aL5EO/OjTD1mwTuN3ZyZiRk6G2BrdTOFmF3g0Z1wnADr7C0NHS0JxY4bLbrns5U7tKnKfOe0
X-Proofpoint-ORIG-GUID: 46aGDsXxsLDAwI6kCckd_1Q690K0wGZl
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
mlxscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 priorityscore=1501
adultscore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0
clxscore=1015 bulkscore=0 classifier=spam authscore=0 authtc=n/a authcc=
route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505160000
definitions=main-2505300081
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Add initial device tree support for IQ-9075-EVK board,
based on Qualcomm's QCS9075 SOC.
Implement basic features like uart/ufs to enable boot to shell.
Co-developed-by: Rakesh Kota <quic_kotarake@xxxxxxxxxxx>
Signed-off-by: Rakesh Kota <quic_kotarake@xxxxxxxxxxx>
Co-developed-by: Sayali Lokhande <quic_sayalil@xxxxxxxxxxx>
Signed-off-by: Sayali Lokhande <quic_sayalil@xxxxxxxxxxx>
Signed-off-by: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/qcs9075-iq-9075-evk.dts | 289 ++++++++++++++++++
2 files changed, 290 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-iq-9075-evk.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 669b888b27a1..77501a13d91e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -124,6 +124,7 @@ dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs9075-iq-9075-evk.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
dtb-$(CONFIG_ARCH_QCOM) += qdu1000-idp.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs9075-iq-9075-evk.dts b/arch/arm64/boot/dts/qcom/qcs9075-iq-9075-evk.dts
new file mode 100644
index 000000000000..f1f725691ba2
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs9075-iq-9075-evk.dts
@@ -0,0 +1,289 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2024-2025, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "qcs9075-som.dtsi"
+
+/ {
+ model = "Qualcomm Technologies, Inc. IQ 9075 EVK";
+ compatible = "qcom,qcs9075-iq-9075-evk", "qcom,qcs9075", "qcom,sa8775p";
+
+ aliases {
+ serial0 = &uart10;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "a";
+
+ vreg_s4a: smps4 {
+ regulator-name = "vreg_s4a";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1816000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5a: smps5 {
+ regulator-name = "vreg_s5a";
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1996000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s9a: smps9 {
+ regulator-name = "vreg_s9a";
+ regulator-min-microvolt = <535000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4a: ldo4 {
+ regulator-name = "vreg_l4a";
+ regulator-min-microvolt = <788000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5a: ldo5 {
+ regulator-name = "vreg_l5a";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <950000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6a: ldo6 {
+ regulator-name = "vreg_l6a";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7a: ldo7 {
+ regulator-name = "vreg_l7a";
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <950000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8a: ldo8 {
+ regulator-name = "vreg_l8a";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9a: ldo9 {
+ regulator-name = "vreg_l9a";
+ regulator-min-microvolt = <2970000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vreg_l1c: ldo1 {
+ regulator-name = "vreg_l1c";
+ regulator-min-microvolt = <1140000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c: ldo2 {
+ regulator-name = "vreg_l2c";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3c: ldo3 {
+ regulator-name = "vreg_l3c";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c: ldo4 {
+ regulator-name = "vreg_l4c";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5c: ldo5 {
+ regulator-name = "vreg_l5c";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6c: ldo6 {
+ regulator-name = "vreg_l6c";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c: ldo7 {
+ regulator-name = "vreg_l7c";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c: ldo8 {
+ regulator-name = "vreg_l8c";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c: ldo9 {
+ regulator-name = "vreg_l9c";
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <2700000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pmm8654au-rpmh-regulators";
+ qcom,pmic-id = "e";
+
+ vreg_s4e: smps4 {
+ regulator-name = "vreg_s4e";
+ regulator-min-microvolt = <970000>;
+ regulator-max-microvolt = <1520000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s7e: smps7 {
+ regulator-name = "vreg_s7e";
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1170000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s9e: smps9 {
+ regulator-name = "vreg_s9e";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <570000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6e: ldo6 {
+ regulator-name = "vreg_l6e";
+ regulator-min-microvolt = <1280000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8e: ldo8 {
+ regulator-name = "vreg_l8e";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1950000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&sleep_clk {
+ clock-frequency = <32768>;
+};
+
+&uart10 {
+ compatible = "qcom,geni-debug-uart";
+ pinctrl-0 = <&qup_uart10_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l8a>;
+ vcc-max-microamp = <1100000>;
+ vccq-supply = <&vreg_l4c>;
+ vccq-max-microamp = <1200000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l4a>;
+ vdda-pll-supply = <&vreg_l1c>;
+
+ status = "okay";
+};
+
+&xo_board_clk {
+ clock-frequency = <38400000>;
+};
--
2.49.0
Return-Path: <linux-kernel+bounces-667862-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id D9BBB41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:30:40 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 128667A4208
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:22 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 1634422170B;
Fri, 30 May 2025 09:29:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="JI4W7V0d"
Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131])
(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 C5CE4220F5F;
Fri, 30 May 2025 09:29:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597353; cv=none; b=saIw2g9dJrnpW8xIG6vLP+3oDEMh3Da8Ij2djEY8Nk/H/JtTzlfLvBa/Q2C7GBUOAopT48DewrkX0aOYAiG46WOoof9JC+6kVssioRi1RD+vNCaF4/LRTvZBtIQKdvSxE+ywfV3wCCgKyKZQtwdbzAdvTsIzRscHxiu5Wu0TLiI=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597353; c=relaxed/simple;
bh=StvqrR/KMPt4u0QVmgVVABaEWr7rgSio0K+BjrS71pw=;
h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
MIME-Version; b=Ys6tGBCZhiknpug4DozYFS4kdviVgZFrBIXrzcjut8ZHQ3ttUq0jVu+GxNzHP7dShV+44FEwrj5kSRwfCTljm1N7yrRfxKpYaHVo67UZxznGTb2IlIdtH5Klan1cvC3ApSTiZ1JpjG7R2nesZh6tLA8McfZxkPfrHcDbTSl87Cg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=qualcomm.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=JI4W7V0d; arc=none smtp.client-ip=205.220.168.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qualcomm.com
Received: from pps.filterd (m0279867.ppops.net [127.0.0.1])
by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U0d4PV009479;
Fri, 30 May 2025 09:28:57 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
cc:content-transfer-encoding:date:from:in-reply-to:message-id
:mime-version:references:subject:to; s=qcppdkim1; bh=T+ZaYlXkMV/
3zAis8DcjNCqUTkV9KdxdODhGIpNgDIY=; b=JI4W7V0dq7z4HsBcDb+jVQwOqYf
Gqef7hnnzE6XABix7OFwgIEnxHzU4HdcZ68SsZwNKMVGVBAe3byHgMCmGlJKnO+B
Frchun5KHkMws325J45IL9wwPzgN9Pi7kmuyyFeulZAhHWjQVcFevAFF1kjdhVgr
TUbDTdjxNr3MDDHWoHdT8OzzqAQmFaasCq9SIZc1AnmoWzbcS2K2xcHP24BgwWTF
mPWTr4rJoPHi7kfMPxEK1g9trym5aK3sRBgnIqy4NgxHiUrYSIqbNNDSevClNR7j
l8QpEMB0rGOwX2fEM7xYv2N3SqScLjaYypWYvdDPfPjdVWDu0m/BCsc8bnQ==
Received: from apblrppmta01.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19])
by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 46w691k4g7-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:57 +0000 (GMT)
Received: from pps.filterd (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTP id 54U9SqEX008747;
Fri, 30 May 2025 09:28:52 GMT
Received: from pps.reinject (localhost [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 46u76my9gp-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: from APBLRPPMTA01.qualcomm.com (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54U9Sqo8008721;
Fri, 30 May 2025 09:28:52 GMT
Received: from hu-devc-hyd-u22-c.qualcomm.com (hu-wasimn-hyd.qualcomm.com [10.147.246.180])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 54U9SqFN008717
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: by hu-devc-hyd-u22-c.qualcomm.com (Postfix, from userid 3944840)
id 2A5154FD; Fri, 30 May 2025 14:58:51 +0530 (+0530)
From: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
To: Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, kernel@xxxxxxxxxxx,
kernel@xxxxxxxxxxxxxxxx, Wasim Nazir <quic_wasimn@xxxxxxxxxxx>,
Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
Subject: [PATCH v9 1/4] dt-bindings: arm: qcom: Add bindings for QCS9075 SOC based board
Date: Fri, 30 May 2025 14:58:44 +0530
Message-ID: <20250530092850.631831-2-quic_wasimn@xxxxxxxxxxx>
X-Mailer: git-send-email 2.49.0
In-Reply-To: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
References: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-QCInternal: smtphost
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Authority-Analysis: v=2.4 cv=WfoMa1hX c=1 sm=1 tr=0 ts=68397a59 cx=c_pps
a=Ou0eQOY4+eZoSc0qltEV5Q==:117 a=Ou0eQOY4+eZoSc0qltEV5Q==:17
a=dt9VzEwgFbYA:10 a=VwQbUJbxAAAA:8 a=KKAkSRfTAAAA:8 a=COk6AnOGAAAA:8
a=htuHtO1j-8kfaUu6lmQA:9 a=cvBusfyB2V15izCimMoJ:22 a=TjNXssC_j7lpFel5tvFf:22
X-Proofpoint-GUID: tRktHrlRX-mi8vYazSvXgQtyClRUc-Br
X-Proofpoint-ORIG-GUID: tRktHrlRX-mi8vYazSvXgQtyClRUc-Br
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA4MSBTYWx0ZWRfX6g0dZKVeEU/x
YhVzovQy1Tb+feGR4hVvJhA9UiO390W0bf/ORrspsgZfk2MfIA18cznsjZ1YJ2tYcxX/69hzoyW
P8XZZnHZTUioUygRBKT/DSivCJ36Gi9GIGL51F/kZxM8uz5PZ4GFGbCH7JY7SUhyVPzRtZSwrv8
6KfneMRLtff3GC4p3+4hEeKXy1pyleLQ+lbkNuzb/rJn/e9Y6jKKJEHOSO29zNYz4e3gKslyDc3
gpOZyZB8pq6eAbj4XUv5AX1bMaDP3xmpPGM49X/rRE8YwZs8ipqp10P05+MO0yiX0pZWhHo9kL0
RF/wjdSUeJ4wGLVSF81WMCMj5+SJHNTkyFYK5k52VzaLuBKQkJpCSaKN6gY6tUI3nGr9vtRxHaV
paBp7qlYsDZy2iar0xZHUtPFBGjaxi0kEYeKecoQYgBFdORwGBXqROLHdXjX7EyJgnwyFn1Z
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0
bulkscore=0 adultscore=0 spamscore=0 suspectscore=0 malwarescore=0
clxscore=1011 impostorscore=0 classifier=spam authscore=0 authtc=n/a authcc=
route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505160000
definitions=main-2505300081
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
QCS9075 is compatible Industrial-IOT grade variant of SA8775p SOC.
Unlike QCS9100, it doesn't have safety monitoring feature of
Safety-Island(SAIL) subsystem, which affects thermal management.
qcs9075-iq-9075-evk board is based on QCS9075 SOC.
Acked-by: Rob Herring (Arm) <robh@xxxxxxxxxx>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
Signed-off-by: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 56f78f0f3803..3b2c60af12cd 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -58,6 +58,7 @@ description: |
qcs8550
qcm2290
qcm6490
+ qcs9075
qcs9100
qdu1000
qrb2210
@@ -961,6 +962,12 @@ properties:
- qcom,sa8775p-ride-r3
- const: qcom,sa8775p
+ - items:
+ - enum:
+ - qcom,qcs9075-iq-9075-evk
+ - const: qcom,qcs9075
+ - const: qcom,sa8775p
+
- items:
- enum:
- qcom,qcs9100-ride
--
2.49.0
Return-Path: <linux-kernel+bounces-667864-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id E71AB41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:30:54 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id CDFBF3AF837
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:33 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 5791C22A80A;
Fri, 30 May 2025 09:29:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b="gRDjdDlg"
Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131])
(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 C0434227E8F;
Fri, 30 May 2025 09:29:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597354; cv=none; b=Ul3X2DFWF9+3MT1rGAJ+M0GEPy13ALECoBvwNscrJfx0J8LmOZ3wlwvwMsWLtn4uoMSVqxB5Y9H4B/JaC9K9QQEYMsYoWmIUa+JWIDQ/mm+CPFmd042uRdzKOZaU1kxhuvK8ey85x4u/rndARzmkb8mHox0nWMuNAPpJkfMCJTk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597354; c=relaxed/simple;
bh=ZEybsHDXyPCaqq5mNJW+mpZvnSf4f7JjB5O+755MU3k=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=X691093w6eExPcHX2ZQDig66/ZysXyTfgwUhu8kdEDhAE3LxL5MEm5gGkwyxrcPQV+WnDokfooJJL+Kw40jSd8CtAZ4amzzA9+uVJj6H9I3lIvNrY8ru742A/hAGdgWTBp2RIVm9RiwPCUgs4YnoMMjfKA2zQHE/HNqNVU2IjoM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com; spf=pass smtp.mailfrom=qualcomm.com; dkim=pass (2048-bit key) header.d=quicinc.com header.i=@quicinc.com header.b=gRDjdDlg; arc=none smtp.client-ip=205.220.168.131
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=quicinc.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=qualcomm.com
Received: from pps.filterd (m0279863.ppops.net [127.0.0.1])
by mx0a-0031df01.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 54U0T53G008030;
Fri, 30 May 2025 09:28:58 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=
cc:content-transfer-encoding:content-type:date:from:message-id
:mime-version:subject:to; s=qcppdkim1; bh=tzmvSRrblqgZgKJaCs+zrv
qpz5Rlg71VuyXyzdUPXeM=; b=gRDjdDlgopV3yajHmhLV/TvaqgRArmvhCFeiIG
xhfQg3TSpo34Tc4I7EK3s+84a/PcKpnAKXIcLH0rrMYTvGVOIA8mQ3nOz31zoatv
nPy68UGt//IYiktcVo6XvmDuL6sM7dl2kXixPRyFxXJVR6EicM7tnM1f+vsnX95o
W+4HNI7cjvMVBOLfmYzZdw+CgCs4eVuOZV8S91nbK5uphQdlwkN4iQ2n22dzf1RK
8XnpzE8L+FBZw0K6D9Ivyq4AEScQGtvtKi8gGHGnOLs8WvS8hDc6lx9WCIawvK5n
BUqMkIZuY+HaHS4a9qEZ73qZB0Mwm0ajeRag1dC81sBAY+Mw==
Received: from apblrppmta01.qualcomm.com (blr-bdr-fw-01_GlobalNAT_AllZones-Outside.qualcomm.com [103.229.18.19])
by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 46whuf8x28-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:57 +0000 (GMT)
Received: from pps.filterd (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (8.18.1.2/8.18.1.2) with ESMTP id 54U9Sq8u008752;
Fri, 30 May 2025 09:28:52 GMT
Received: from pps.reinject (localhost [127.0.0.1])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 46u76my9gn-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: from APBLRPPMTA01.qualcomm.com (APBLRPPMTA01.qualcomm.com [127.0.0.1])
by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 54U9Sqf8008720;
Fri, 30 May 2025 09:28:52 GMT
Received: from hu-devc-hyd-u22-c.qualcomm.com (hu-wasimn-hyd.qualcomm.com [10.147.246.180])
by APBLRPPMTA01.qualcomm.com (PPS) with ESMTPS id 54U9SqqA008719
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Fri, 30 May 2025 09:28:52 +0000
Received: by hu-devc-hyd-u22-c.qualcomm.com (Postfix, from userid 3944840)
id 27DF259B; Fri, 30 May 2025 14:58:51 +0530 (+0530)
From: Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
To: Bjorn Andersson <andersson@xxxxxxxxxx>,
Konrad Dybcio <konradybcio@xxxxxxxxxx>, Rob Herring <robh@xxxxxxxxxx>,
Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>
Cc: linux-arm-msm@xxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx, kernel@xxxxxxxxxxx,
kernel@xxxxxxxxxxxxxxxx, Wasim Nazir <quic_wasimn@xxxxxxxxxxx>
Subject: [PATCH v9 0/4] qcom: Add support for IQ-9075-evk board
Date: Fri, 30 May 2025 14:58:43 +0530
Message-ID: <20250530092850.631831-1-quic_wasimn@xxxxxxxxxxx>
X-Mailer: git-send-email 2.49.0
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-QCInternal: smtphost
X-QCInternal: smtphost
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085
X-Authority-Analysis: v=2.4 cv=OslPyz/t c=1 sm=1 tr=0 ts=68397a59 cx=c_pps
a=Ou0eQOY4+eZoSc0qltEV5Q==:117 a=Ou0eQOY4+eZoSc0qltEV5Q==:17
a=IkcTkHD0fZMA:10 a=dt9VzEwgFbYA:10 a=VwQbUJbxAAAA:8 a=COk6AnOGAAAA:8
a=u6Jdqvu1gAsBJA_3vmsA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10
a=TjNXssC_j7lpFel5tvFf:22
X-Proofpoint-ORIG-GUID: bCPyZCNHn_0psLFWJTWRehzF6fSOhSb1
X-Proofpoint-GUID: bCPyZCNHn_0psLFWJTWRehzF6fSOhSb1
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUwNTMwMDA4MSBTYWx0ZWRfX87BzHTAyUUvr
KevXIY5/L7DHZolCNjsZ3qC3XXmBIWOkVuGGYxaZ/pV4w/UxQNtKzHx4Qywc810h7iE814COeUy
gqYkZhsxWiZspIO6w7FFT69DogvnVURVxGiJF6ilB2m0hQ8QxoMHO7wl0k8f7C5ESK+ZuwHbFjL
74A9ToIgUSF+32GeRiV31Vsvgf3Ncs9snqpjz7UbA1j1UrOLmnhScwCQeZp7vOr2merdUXicucL
PW8JubjEjCUN48fjvaKIH/SU2W9PcvfZeoRZzOZe1rgXyx4ArnmRINFs/U1w3x85Y4S5hv39ejz
zRYN9VJ3AFY8QhVy51Zds9Dz4gJQqFueT1DBGVowq72k8FSW2Bv2UV5MKVoQm/i4d73VXdHUOgP
+LFiVaW6D4aLIrMmv+vyJy9BavlOkPElol07yPnxonBTKCem0d1Gg5jfAUPHO/p9vgIeXXOZ
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1099,Hydra:6.0.736,FMLib:17.12.80.40
definitions=2025-05-30_04,2025-05-29_01,2025-03-28_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
impostorscore=0 phishscore=0 mlxlogscore=999 adultscore=0 malwarescore=0
bulkscore=0 priorityscore=1501 clxscore=1015 mlxscore=0 lowpriorityscore=0
spamscore=0 suspectscore=0 classifier=spam authscore=0 authtc=n/a authcc=
route=outbound adjust=0 reason=mlx scancount=1 engine=8.19.0-2505160000
definitions=main-2505300081
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
This series:
Add support for Qualcomm's iq9-evk board using QCS9075 SOC.
QCS9075 is compatible IoT-industrial grade variant of SA8775p SOC.
Unlike QCS9100, it doesn't have safety monitoring feature of
Safety-Island(SAIL) subsystem, which affects thermal management.
In QCS9100 SOC, the safety subsystem monitors all thermal sensors and
does corrective action for each subsystem based on sensor violation
to comply safety standards. But as QCS9075 is non-safe SOC it requires
conventional thermal mitigation for thermal management.
In this series thermal mitigation changes are not included as it needs
more discussion whether to include the change in DT or in drivers.
Below are detailed informations on IQ-9075-evk HW:
------------------------------------------------------
QCS9075 SOM is stacked on top of IQ-9075-evk board.
On top of IQ-9075-evk board additional mezzanine boards can be stacked
in future.
IQ-9075-evk is single board supporting these peripherals:
- Storage: 2 Ã? 128 GB UFS, micro-SD card, EEPROMs for MACs,
eMMC on mezzanine card
- Audio/Video, Camera & Display ports
- Connectivity: RJ45 2.5GbE, WLAN/Bluetooth, CAN/CAN-FD
- Sensors: IMU
- PCIe ports
- USB & UART ports
Currently basic features are enabled to support 'boot to shell'.
---
Changelog:
v9:
- Retain earlier tags from Rob Herring [1] & Krzysztof Kozlowski [2]
- v8-link: [3]
v8:
- Squash UFS support [4] into initial board support patch.
- Remove uart10 pinctrl settings from board, it is moved to sa8775p.dtsi.
- Arrange ufs nodes in alphabetical order.
- v7-link: [5]
[1] https://lore.kernel.org/all/173142574295.951085.7523517676553074543.robh@xxxxxxxxxx/
[2] https://lore.kernel.org/all/20250430-enlightened-enchanted-jellyfish-7049d0@kuoka/
[3] https://lore.kernel.org/all/20250528122753.3623570-1-quic_wasimn@xxxxxxxxxxx/
[4] https://lore.kernel.org/all/20250513084309.10275-1-quic_sayalil@xxxxxxxxxxx/
[5] https://lore.kernel.org/all/20250521140807.3837019-1-quic_wasimn@xxxxxxxxxxx/
Pratyush Brahma (1):
arm64: dts: qcom: iq9: Introduce new memory map for qcs9100/qcs9075
Wasim Nazir (3):
dt-bindings: arm: qcom: Add bindings for QCS9075 SOC based board
arm64: dts: qcom: qcs9075: Introduce QCS9075 SOM
arm64: dts: qcom: Add support for qcs9075 IQ-9075-EVK
.../devicetree/bindings/arm/qcom.yaml | 7 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../boot/dts/qcom/iq9-reserved-memory.dtsi | 113 +++++++
.../boot/dts/qcom/qcs9075-iq-9075-evk.dts | 289 ++++++++++++++++++
arch/arm64/boot/dts/qcom/qcs9075-som.dtsi | 10 +
5 files changed, 420 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/iq9-reserved-memory.dtsi
create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-iq-9075-evk.dts
create mode 100644 arch/arm64/boot/dts/qcom/qcs9075-som.dtsi
base-commit: 3be1a7a31fbda82f3604b6c31e4f390110de1b46
--
2.49.0
Return-Path: <linux-kernel+bounces-667863-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id E8AEE41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:30:56 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id ECF643AFDC2
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:35 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 8067622A80E;
Fri, 30 May 2025 09:29:15 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="JF2KgJ8c"
Received: from mail-pl1-f171.google.com (mail-pl1-f171.google.com [209.85.214.171])
(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 BA17C2253A0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.171
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597354; cv=none; b=jsRxn8ZZcIVgT29UGn2+A86aRY6HpD3f96GhatWN4vXwoKzqNWGXdmCb/U6eOVojWKeescczasPjxjaotOeZackouOwJKrBWKvDZ5b+eD1eQPLxnElfdB7eOq1tVmcv6Y2Rqvb5VCa3LAhReORD8ejyP+qf2jfk6yTNpJIODZ50=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597354; c=relaxed/simple;
bh=VCOCu6O/NADHfF14Am0W07s7tA5GTZgRlngfMicR/Ns=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=Q7s+ySDq3H3kTkNTftmsCdKfTEGXzVGAFowU6r+K1RXj6yNJcwV6qvwvh45js6vt6Kqx9A8ebhwrlkIyPqXoisHlbfkcJSXQpfOjJPm90zGBqgUK8Q+PTiZ4NznXwzGgzF5qshAT/LR6RIps1W91QmRqDPYBNhCeBd4J3tW9t+c=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=JF2KgJ8c; arc=none smtp.client-ip=209.85.214.171
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pl1-f171.google.com with SMTP id d9443c01a7336-23526264386so8607445ad.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597352; x=1749202152; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=qGQ/MSD2aq8Zt0uX+CveEn5QJtfmVtywDoJlykkJ748=;
b=JF2KgJ8cx2NSohpk333GW3x0my23qoG68NSIxWf5sYIpcvmj7bxkarfiGI+IITH+wK
aTcwd7A9kmW/XD7Nqc9N8Cp0KUzCcOoCrWY9y8mRvBC8RtHBmWtQtCgKUwu143NGBm2o
/L4ATUoviWRFPR6BmI6F/OeXAPiKS/5DIk6/4VIxNsCSFCOLtMLv257BUSqfhvQAnYM8
7OhsnPp33+CBv9gcOf6K9XyCogI5HvwzR36gX5UNssqDkEnYLBsshsJPvwi5Z+pNJY+6
tUzmm3lBJiRrwHSHt6NOPup1OvuIhn+pW7nz6kM09D44SIZ21LGlph6fmlCi80Hy891o
Tu7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597352; x=1749202152;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=qGQ/MSD2aq8Zt0uX+CveEn5QJtfmVtywDoJlykkJ748=;
b=cUEgOjKkwtzuf9T6iYgvMGXoB/PTTZzwrRrzmfxEiLF9Zr224s5NHmWJ9LMKGjHWy+
vR5sDUSpyzGjauZfHIOcKkUzezyg6ofdO1KN8Hq3tThl9vB7IIRSbmoEnbgsJWaVu/NB
et2KhsLYFDvvIp3O1zvrAo3+GVmgCdw6MaatkKMwoc3UTrDac92HRt70J2iJupk2IdRf
vn0dynnQZWOa7AC8j4v2k8eXxX53+HnQa4w1fPzlOHjD+N4LTqgxLH1+QK1yta6nGowo
LPrOlcDX3UonahplVFgr1LcVAdNo/Ye+AwFDz70VbamCDSvvnOPsRZprTWhjTjp9L1+j
/O3A==
X-Forwarded-Encrypted: i=1; AJvYcCW8eEwOiMtV3XidR9dz723atBiYGyodYwWyiWRWDb7ytuM7IbQPGJYF5g0pO/cQ8lYnxrndSeZUX4KQLgo=@vger.kernel.org
X-Gm-Message-State: AOJu0YxxwFPMt+KgqiAJXS2Ng6mjld726JMa+sjszcr2Vx0a4EHVQsIW
PibKww0yIybbMkAteShfm/drAhqAs7mCHTJD1mRkmAeetJ6P+R5i6zKZoogg7IsQowg=
X-Gm-Gg: ASbGncuf+HlU7mMSXlCV3VMS79IhnD6Ef/XRfHsJ9eacF/5pK0l1I4DyGdGk0eZQq9h
N0KhueAifWGzH9/UTFFAKcc8ViR8zJzUnskBx3ypA3EGW5Db0IHVRIetyW6F+ZV/jCmYP7fIQCs
o03nTlTYhxHuXdb1XkBSAjxyITblHO7xWT8GCT2K3rayXiVqr6gw/ex/JzEndr2m1I3jQkmKNOw
NTOTAUkyug3zi2CoiLMnKz+qzb4/U8iMc6gpgkmZuaXkIt4ziZsrQ+fzwtZ45dQFeeGemfkEdcf
Os5rhP581hBCPxB4JxYj15FGnlWOtVAVP3d1VfR8k1oERxziecvqHGsKCGSJLJQPmjgyWAHNkfk
Wxt3jytLAEQ==
X-Google-Smtp-Source: AGHT+IHXNv6SBDXy0RRoZRael/cpWOT8NPAPr0x/A4zO15FUEF6dVXWmKj+6rOHNmQu7F4oEsyx/Vw==
X-Received: by 2002:a17:90b:3a82:b0:311:ab20:159d with SMTP id 98e67ed59e1d1-3124163a55amr3859759a91.19.1748597351985;
Fri, 30 May 2025 02:29:11 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.28.57
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:29:11 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 03/35] RPAL: add service registration interface
Date: Fri, 30 May 2025 17:27:31 +0800
Message-Id: <f3d83dbf77500433986cdfb649bf603ea9031961.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Every rpal service should be registered and managed. Each RPAL service has
a 64-bit key as its unique identifier, the key should never repeat before
kernel reboot. Each RPAL service has an ID to indicate which 512GB virtual
address space it can use. Any alive RPAL service has its unique ID, which
will never be reused until the service dead.
This patch adds a registration interface for RPAL services. Newly
registered rpal_service instances are assigned a key that increments
starting from 1. The 64-bit length of the key ensures that keys are almost
impossible to exhaust before system reboot. Meanwhile, a bitmap is used to
allocate IDs, ensuring no duplicate IDs are assigned. RPAL services are
managed via a hash list, which facilitates quick lookup of the
corresponding rpal_service by key.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/service.c | 130 ++++++++++++++++++++++++++++++++++++++++
include/linux/rpal.h | 31 ++++++++++
2 files changed, 161 insertions(+)
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index c8e609798d4f..609c9550540d 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -13,13 +13,56 @@
#include "internal.h"
+static DECLARE_BITMAP(rpal_id_bitmap, RPAL_NR_ID);
+static atomic64_t service_key_counter;
+static DEFINE_HASHTABLE(service_hash_table, ilog2(RPAL_NR_ID));
+DEFINE_SPINLOCK(hash_table_lock);
static struct kmem_cache *service_cache;
+static inline void rpal_free_service_id(int id)
+{
+ clear_bit(id, rpal_id_bitmap);
+}
+
static void __rpal_put_service(struct rpal_service *rs)
{
kmem_cache_free(service_cache, rs);
}
+static int rpal_alloc_service_id(void)
+{
+ int id;
+
+ do {
+ id = find_first_zero_bit(rpal_id_bitmap, RPAL_NR_ID);
+ if (id == RPAL_NR_ID) {
+ id = RPAL_INVALID_ID;
+ break;
+ }
+ } while (test_and_set_bit(id, rpal_id_bitmap));
+
+ return id;
+}
+
+static bool is_valid_id(int id)
+{
+ return id >= 0 && id < RPAL_NR_ID;
+}
+
+static u64 rpal_alloc_service_key(void)
+{
+ u64 key;
+
+ /* confirm we do not run out keys */
+ if (unlikely(atomic64_read(&service_key_counter) == _AC(-1, UL))) {
+ rpal_err("key is exhausted\n");
+ return RPAL_INVALID_KEY;
+ }
+
+ key = atomic64_fetch_inc(&service_key_counter);
+ return key;
+}
+
struct rpal_service *rpal_get_service(struct rpal_service *rs)
{
if (!rs)
@@ -37,6 +80,90 @@ void rpal_put_service(struct rpal_service *rs)
__rpal_put_service(rs);
}
+static u32 get_hash_key(u64 key)
+{
+ return key % RPAL_NR_ID;
+}
+
+struct rpal_service *rpal_get_service_by_key(u64 key)
+{
+ struct rpal_service *rs, *rsp;
+ u32 hash_key = get_hash_key(key);
+
+ rs = NULL;
+ hash_for_each_possible(service_hash_table, rsp, hlist, hash_key) {
+ if (rsp->key == key) {
+ rs = rsp;
+ break;
+ }
+ }
+ return rpal_get_service(rs);
+}
+
+static void insert_service(struct rpal_service *rs)
+{
+ unsigned long flags;
+ int hash_key;
+
+ hash_key = get_hash_key(rs->key);
+
+ spin_lock_irqsave(&hash_table_lock, flags);
+ hash_add(service_hash_table, &rs->hlist, hash_key);
+ spin_unlock_irqrestore(&hash_table_lock, flags);
+}
+
+static void delete_service(struct rpal_service *rs)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&hash_table_lock, flags);
+ hash_del(&rs->hlist);
+ spin_unlock_irqrestore(&hash_table_lock, flags);
+}
+
+struct rpal_service *rpal_register_service(void)
+{
+ struct rpal_service *rs;
+
+ if (!rpal_inited)
+ return NULL;
+
+ rs = kmem_cache_zalloc(service_cache, GFP_KERNEL);
+ if (!rs)
+ goto alloc_fail;
+
+ rs->id = rpal_alloc_service_id();
+ if (!is_valid_id(rs->id))
+ goto id_fail;
+
+ rs->key = rpal_alloc_service_key();
+ if (unlikely(rs->key == RPAL_INVALID_KEY))
+ goto key_fail;
+
+ atomic_set(&rs->refcnt, 1);
+
+ insert_service(rs);
+
+ return rs;
+
+key_fail:
+ kmem_cache_free(service_cache, rs);
+id_fail:
+ rpal_free_service_id(rs->id);
+alloc_fail:
+ return NULL;
+}
+
+void rpal_unregister_service(struct rpal_service *rs)
+{
+ if (!rs)
+ return;
+
+ delete_service(rs);
+
+ rpal_put_service(rs);
+}
+
int __init rpal_service_init(void)
{
service_cache = kmem_cache_create("rpal_service_cache",
@@ -47,6 +174,9 @@ int __init rpal_service_init(void)
return -1;
}
+ bitmap_zero(rpal_id_bitmap, RPAL_NR_ID);
+ atomic64_set(&service_key_counter, RPAL_FIRST_KEY);
+
return 0;
}
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 73468884cc5d..75c5acf33844 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -11,13 +11,40 @@
#include <linux/sched.h>
#include <linux/types.h>
+#include <linux/hashtable.h>
#include <linux/atomic.h>
#define RPAL_ERROR_MSG "rpal error: "
#define rpal_err(x...) pr_err(RPAL_ERROR_MSG x)
#define rpal_err_ratelimited(x...) pr_err_ratelimited(RPAL_ERROR_MSG x)
+/*
+ * The first 512GB is reserved due to mmap_min_addr.
+ * The last 512GB is dropped since stack will be initially
+ * allocated at TASK_SIZE_MAX.
+ */
+#define RPAL_NR_ID 254
+#define RPAL_INVALID_ID -1
+#define RPAL_FIRST_KEY _AC(1, UL)
+#define RPAL_INVALID_KEY _AC(0, UL)
+
+/*
+ * Each RPAL service has a 64-bit key as its unique identifier, and
+ * the 64-bit length ensures that the key will never repeat before
+ * the kernel reboot.
+ *
+ * Each RPAL service has an ID to indicate which 512GB virtual address
+ * space it can use. All alive RPAL processes have unique IDs, ensuring
+ * their address spaces do not overlap. When a process exits, its ID
+ * is released, allowing newly started RPAL services to reuse the ID.
+ */
struct rpal_service {
+ /* Unique identifier for RPAL service */
+ u64 key;
+ /* virtual address space id */
+ int id;
+ /* Hashtable list for this struct */
+ struct hlist_node hlist;
/* reference count of this struct */
atomic_t refcnt;
};
@@ -40,4 +67,8 @@ struct rpal_service *rpal_get_service(struct rpal_service *rs);
* @param rs The struct rpal_service to put.
*/
void rpal_put_service(struct rpal_service *rs);
+
+void rpal_unregister_service(struct rpal_service *rs);
+struct rpal_service *rpal_register_service(void);
+struct rpal_service *rpal_get_service_by_key(u64 key);
#endif
--
2.20.1
Return-Path: <linux-kernel+bounces-667865-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 09FF841E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:31:26 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id D57343B5421
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:04 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 2106321E08B;
Fri, 30 May 2025 09:29:31 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="i+8bKHHV"
Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50])
(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 1629D21E082
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:27 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.50
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597369; cv=none; b=R9q104r3mAr7KNlO72M1CIY9TJuFJ21x2Sngccu7WCimPACesWNrpO5E2gYwdCgiPtf4L44zOIgmbiFh6bC+UJvDeti43dpy/6nMnhSctMIVZsUza6XJF/iMOXiHay3ZLmDbfBUnpZhR+0blr4j24I2CIUyL0PUIvSoQ4brVddk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597369; c=relaxed/simple;
bh=HWUbzvJ0czQHj89YGQM3u0dk16ZJgWmPR8JTmwOLaAI=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=A1xp0eq8ChVBECTruxn57Jc8XEOjI/V7urJbkt1h3pBdEYn+Ybdun5yJWhzuRCcwoeZjHKXpqeHlhucpEVz5vTjf2SOJHP+FEL9X5/gOFsJrT6WwcnagKErOVatc5Yys7OSZx+sjpeMZEoYXy1kVNraUEcQY3cvlzz6gDAwKsjo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=i+8bKHHV; arc=none smtp.client-ip=209.85.216.50
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-311e993f49aso1475171a91.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597367; x=1749202167; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=qlcCT7HpVRiKFCiWQ8GjTfMWomzbPQPS5hEo4l8oJpI=;
b=i+8bKHHVu0Iwh+zALug//jSVJrcArOw6+1Sb2X6JYatwx0UBHy5421qx7NXWu/ZxbF
ubtHM2AsBEMIoFzuk9lY5UfMjZU6imL1Z/wNa+88TU2vHdC/0qZw8IKsCrJ/z5l4UUIP
4tdt8H2iPqD+a4ll95djQDmPnJ8PO4U6359RE0QkHs/sbfIQAl4yzBhi/lVzBB4X2e/c
+dzZy19UlwSn6pBOKLY5LDSsfZbjblPBmDYvQh5MgywpsVLy5zFaCljULT4cwzRUWIUh
QUip7XlnryUZDvUSIQt8XnwlZW0/5WOOILHikCQUy1UNbvWQb08L7fnPDpJOiVNB8IXD
mN9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597367; x=1749202167;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=qlcCT7HpVRiKFCiWQ8GjTfMWomzbPQPS5hEo4l8oJpI=;
b=jfWFl2GOrSRgZ1yiXD5II8+EM44vSEW1HE0nSvoB66qupttY9/5TDdPC06VRZuoJwO
X+5d7ui6JAz4IuhV/BFauD8fa4nd2ZtRJ8KU6gFgRbwXfIyQwmjsvoA5zaQLh42ztlZs
8VEf9VEvIfc3ZGtEfyk7pt7E4oXqqEkrhGhxnZunQ7fFkds9iitchfMVKo8iNLOde2Jt
a8j+WqN0wVGLjS6qzOaO7AHOwSpjiby0+ZU/QEjZ3yyLrlAZnLfeoinSGklaguAeO1AS
Qs4ugMd+VNSmLdyUK1GJmxKu5RfxvrIU2un26fwtvIkL4YJUFby5pCbyGLAdzSJsxpkx
7qbg==
X-Forwarded-Encrypted: i=1; AJvYcCWi0c+xARzcUIZpQexvoX9kRXLVyvjX3Bkalr0v1cYAstM9tC6vbDrcCEQCzsd4Cm94VSzGkHo9JOcy01w=@vger.kernel.org
X-Gm-Message-State: AOJu0YxhlzZbVn8CT+QmtUBdiUlKwO/uA7eMAYSueeaNtLalvV+of1cj
XBjIt2BuUJmP8dN+GiYVLMZLXGweLqN7LoD4YWQ6k3jLsm/UpjD2D0js30lflurz8hk=
X-Gm-Gg: ASbGncvclYnmjFu8wo0uCeUAYXWXa++EJjxqhT1P7iu6zWQfFcaXUhYV1P1+/3RN1SC
T5mzHckNbpZRDefOiNMn9OVmlT2AN8blihCgjgxGmX8j9WEgWnw3gnKLwySC8xPRQKOIyO/HqpV
/jBk5uuRCg5vcUORqYFBeMd+zMyCW+/H/YlK8JB+sfQneH/JpQYHIAdN//ThpBR6km0qAi9JVOp
DJ+bVNI5hdzqFuw91kQ62rnlRA4DT//w3YYC8HryxebqwTxaP4eRarWKuCbwkQTBSCm0HfcgOG1
3CmqkItwz/cMcbBA7g2GJdwUpMXQA0GOO4SK66NCilims47puhg+Q2AA1h8/c3loKNZbzJsvtm6
eRSAxikCB3w==
X-Google-Smtp-Source: AGHT+IHhT+/kCKbFwXp40FdH2tTAUVIIkiKVWdZUIpWhrB1L0an0nzdMBrvxVW8z9SoZzZut7sVHuQ==
X-Received: by 2002:a17:90b:5288:b0:312:ec:4128 with SMTP id 98e67ed59e1d1-31250476af1mr2024876a91.34.1748597367284;
Fri, 30 May 2025 02:29:27 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.29.12
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:29:26 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 04/35] RPAL: add member to task_struct and mm_struct
Date: Fri, 30 May 2025 17:27:32 +0800
Message-Id: <aed20a6acacb2646fe45ed2ba5ada800095b5dbf.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
In lazy switch and memory-related operations, there is a need to quickly
locate the corresponding rpal_service structure. Therefore, rpal_service
members are added to these two data structures.
This patch adds an rpal_service member to both task_struct and mm_struct,
and introduces initialization operations. Meanwhile, rpal_service is also
augmented with references to the task_struct and mm_struct of the
group_leader. For threads created via fork, the kernel acquires a reference
to rpal_service and assigns it to the new task_struct. References to
rpal_service are released when threads exit.
Regarding the deallocation of rpal_struct, since rpal_put_service may be
called in an atomic context (where mmdrop() cannot be invoked), this patch
uses delayed work for deallocation. The work delay is set to 30 seconds,
which ensures that IDs are not recycled and reused in the short term,
preventing other processes from confusing the reallocated ID with the
previous one due to race conditions.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/service.c | 77 +++++++++++++++++++++++++++++++++++++---
fs/exec.c | 11 ++++++
include/linux/mm_types.h | 3 ++
include/linux/rpal.h | 29 +++++++++++++++
include/linux/sched.h | 5 +++
init/init_task.c | 3 ++
kernel/exit.c | 5 +++
kernel/fork.c | 16 +++++++++
8 files changed, 145 insertions(+), 4 deletions(-)
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index 609c9550540d..55ecb7e0ef8c 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -26,9 +26,24 @@ static inline void rpal_free_service_id(int id)
static void __rpal_put_service(struct rpal_service *rs)
{
+ pr_debug("rpal: free service %d, tgid: %d\n", rs->id,
+ rs->group_leader->pid);
+
+ rs->mm->rpal_rs = NULL;
+ mmdrop(rs->mm);
+ put_task_struct(rs->group_leader);
+ rpal_free_service_id(rs->id);
kmem_cache_free(service_cache, rs);
}
+static void rpal_put_service_async_fn(struct work_struct *work)
+{
+ struct rpal_service *rs =
+ container_of(work, struct rpal_service, delayed_put_work.work);
+
+ __rpal_put_service(rs);
+}
+
static int rpal_alloc_service_id(void)
{
int id;
@@ -75,9 +90,16 @@ void rpal_put_service(struct rpal_service *rs)
{
if (!rs)
return;
-
- if (atomic_dec_and_test(&rs->refcnt))
- __rpal_put_service(rs);
+ /*
+ * Since __rpal_put_service() calls mmdrop() (which
+ * cannot be invoked in atomic context), we use
+ * delayed work to release rpal_service.
+ */
+ if (atomic_dec_and_test(&rs->refcnt)) {
+ INIT_DELAYED_WORK(&rs->delayed_put_work,
+ rpal_put_service_async_fn);
+ schedule_delayed_work(&rs->delayed_put_work, HZ * 30);
+ }
}
static u32 get_hash_key(u64 key)
@@ -128,6 +150,12 @@ struct rpal_service *rpal_register_service(void)
if (!rpal_inited)
return NULL;
+ if (!thread_group_leader(current)) {
+ rpal_err("task %d is not group leader %d\n", current->pid,
+ current->tgid);
+ goto alloc_fail;
+ }
+
rs = kmem_cache_zalloc(service_cache, GFP_KERNEL);
if (!rs)
goto alloc_fail;
@@ -140,10 +168,27 @@ struct rpal_service *rpal_register_service(void)
if (unlikely(rs->key == RPAL_INVALID_KEY))
goto key_fail;
- atomic_set(&rs->refcnt, 1);
+ current->rpal_rs = rs;
+
+ rs->group_leader = get_task_struct(current);
+ mmgrab(current->mm);
+ current->mm->rpal_rs = rs;
+ rs->mm = current->mm;
+
+ /*
+ * The reference comes from:
+ * 1. registered service always has one reference
+ * 2. leader_thread also has one reference
+ * 3. mm also hold one reference
+ */
+ atomic_set(&rs->refcnt, 3);
insert_service(rs);
+ pr_debug(
+ "rpal: register service, key: %llx, id: %d, command: %s, tgid: %d\n",
+ rs->key, rs->id, current->comm, current->tgid);
+
return rs;
key_fail:
@@ -161,7 +206,31 @@ void rpal_unregister_service(struct rpal_service *rs)
delete_service(rs);
+ pr_debug("rpal: unregister service, id: %d, tgid: %d\n", rs->id,
+ rs->group_leader->tgid);
+
+ rpal_put_service(rs);
+}
+
+void copy_rpal(struct task_struct *p)
+{
+ struct rpal_service *cur = rpal_current_service();
+
+ p->rpal_rs = rpal_get_service(cur);
+}
+
+void exit_rpal(bool group_dead)
+{
+ struct rpal_service *rs = rpal_current_service();
+
+ if (!rs)
+ return;
+
+ current->rpal_rs = NULL;
rpal_put_service(rs);
+
+ if (group_dead)
+ rpal_unregister_service(rs);
}
int __init rpal_service_init(void)
diff --git a/fs/exec.c b/fs/exec.c
index cfbb2b9ee3c9..922728aebebe 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -68,6 +68,7 @@
#include <linux/user_events.h>
#include <linux/rseq.h>
#include <linux/ksm.h>
+#include <linux/rpal.h>
#include <linux/uaccess.h>
#include <asm/mmu_context.h>
@@ -1076,6 +1077,16 @@ static int de_thread(struct task_struct *tsk)
/* we have changed execution domain */
tsk->exit_signal = SIGCHLD;
+#if IS_ENABLED(CONFIG_RPAL)
+ /*
+ * The rpal process is going to load another binary, we
+ * need to unregister rpal since it is going to be another
+ * process. Other threads have already exited by the time
+ * we come here, we need to set group_dead as true.
+ */
+ exit_rpal(true);
+#endif
+
BUG_ON(!thread_group_leader(tsk));
return 0;
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 32ba5126e221..b29adef082c6 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -1172,6 +1172,9 @@ struct mm_struct {
#ifdef CONFIG_MM_ID
mm_id_t mm_id;
#endif /* CONFIG_MM_ID */
+#ifdef CONFIG_RPAL
+ struct rpal_service *rpal_rs;
+#endif
} __randomize_layout;
/*
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 75c5acf33844..7b9d90b62b3f 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -11,6 +11,8 @@
#include <linux/sched.h>
#include <linux/types.h>
+#include <linux/sched/mm.h>
+#include <linux/workqueue.h>
#include <linux/hashtable.h>
#include <linux/atomic.h>
@@ -29,6 +31,9 @@
#define RPAL_INVALID_KEY _AC(0, UL)
/*
+ * Each RPAL process (a.k.a RPAL service) should have a pointer to
+ * struct rpal_service in all its tasks' task_struct.
+ *
* Each RPAL service has a 64-bit key as its unique identifier, and
* the 64-bit length ensures that the key will never repeat before
* the kernel reboot.
@@ -39,10 +44,23 @@
* is released, allowing newly started RPAL services to reuse the ID.
*/
struct rpal_service {
+ /* The task_struct of thread group leader. */
+ struct task_struct *group_leader;
+ /* mm_struct of thread group */
+ struct mm_struct *mm;
/* Unique identifier for RPAL service */
u64 key;
/* virtual address space id */
int id;
+
+ /*
+ * Fields above should never change after initialization.
+ * Fields below may change after initialization.
+ */
+
+ /* delayed service put work */
+ struct delayed_work delayed_put_work;
+
/* Hashtable list for this struct */
struct hlist_node hlist;
/* reference count of this struct */
@@ -68,7 +86,18 @@ struct rpal_service *rpal_get_service(struct rpal_service *rs);
*/
void rpal_put_service(struct rpal_service *rs);
+#ifdef CONFIG_RPAL
+static inline struct rpal_service *rpal_current_service(void)
+{
+ return current->rpal_rs;
+}
+#else
+static inline struct rpal_service *rpal_current_service(void) { return NULL; }
+#endif
+
void rpal_unregister_service(struct rpal_service *rs);
struct rpal_service *rpal_register_service(void);
struct rpal_service *rpal_get_service_by_key(u64 key);
+void copy_rpal(struct task_struct *p);
+void exit_rpal(bool group_dead);
#endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 45e5953b8f32..ad35b197543c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -72,6 +72,7 @@ struct rcu_node;
struct reclaim_state;
struct robust_list_head;
struct root_domain;
+struct rpal_service;
struct rq;
struct sched_attr;
struct sched_dl_entity;
@@ -1645,6 +1646,10 @@ struct task_struct {
struct user_event_mm *user_event_mm;
#endif
+#ifdef CONFIG_RPAL
+ struct rpal_service *rpal_rs;
+#endif
+
/* CPU-specific state of this task: */
struct thread_struct thread;
diff --git a/init/init_task.c b/init/init_task.c
index e557f622bd90..0c5b1927da41 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -220,6 +220,9 @@ struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
#ifdef CONFIG_SECCOMP_FILTER
.seccomp = { .filter_count = ATOMIC_INIT(0) },
#endif
+#ifdef CONFIG_RPAL
+ .rpal_rs = NULL,
+#endif
};
EXPORT_SYMBOL(init_task);
diff --git a/kernel/exit.c b/kernel/exit.c
index 38645039dd8f..0c8387da59da 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -70,6 +70,7 @@
#include <linux/user_events.h>
#include <linux/uaccess.h>
#include <linux/pidfs.h>
+#include <linux/rpal.h>
#include <uapi/linux/wait.h>
@@ -944,6 +945,10 @@ void __noreturn do_exit(long code)
taskstats_exit(tsk, group_dead);
trace_sched_process_exit(tsk, group_dead);
+#if IS_ENABLED(CONFIG_RPAL)
+ exit_rpal(group_dead);
+#endif
+
exit_mm();
if (group_dead)
diff --git a/kernel/fork.c b/kernel/fork.c
index 85afccfdf3b1..1d1c8484a8f2 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -105,6 +105,7 @@
#include <uapi/linux/pidfd.h>
#include <linux/pidfs.h>
#include <linux/tick.h>
+#include <linux/rpal.h>
#include <asm/pgalloc.h>
#include <linux/uaccess.h>
@@ -1216,6 +1217,10 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
tsk->mm_cid_active = 0;
tsk->migrate_from_cpu = -1;
#endif
+
+#ifdef CONFIG_RPAL
+ tsk->rpal_rs = NULL;
+#endif
return tsk;
free_stack:
@@ -1312,6 +1317,9 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
#endif
mm_init_uprobes_state(mm);
hugetlb_count_init(mm);
+#ifdef CONFIG_RPAL
+ mm->rpal_rs = NULL;
+#endif
if (current->mm) {
mm->flags = mmf_init_flags(current->mm->flags);
@@ -2651,6 +2659,14 @@ __latent_entropy struct task_struct *copy_process(
current->signal->nr_threads++;
current->signal->quick_threads++;
atomic_inc(¤t->signal->live);
+#if IS_ENABLED(CONFIG_RPAL)
+ /*
+ * For rpal process, the child thread needs to
+ * inherit p->rpal_rs. Therefore, we can get the
+ * struct rpal_service for any thread of rpal process.
+ */
+ copy_rpal(p);
+#endif
refcount_inc(¤t->signal->sigcnt);
task_join_group_stop(p);
list_add_tail_rcu(&p->thread_node,
--
2.20.1
Return-Path: <linux-kernel+bounces-667866-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 1B49D41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:31:41 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 5A5D34E4005
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:42 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id BCE15221FC9;
Fri, 30 May 2025 09:29:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="iLObVoMY"
Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180])
(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 9ADD521E0AA
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:43 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.180
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597385; cv=none; b=EVjAXWGLY0aVEaf6bM2T4RhU6MyMaJlXuAuuZcTM9KsV+J90b/Bx+wMNFkSFYhWB1+Ukc+f0OfrOiCagJ52HiAtdTcCx5tL7lfMYr1kIwm/NQJNJNwNiE4NCYibVKMXhjd/zPaMjWY2OXCqrfgGRozwWW1oQjmogBE8sCFK3wi4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597385; c=relaxed/simple;
bh=S20otgpxbfyI8rSmt5eNc2YoPuXrdf/0GSL9ciOvIuU=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=klk/gWt1gRKFLSPwNeckFhfkKREcOSBlIGKMv+bHez0vlo9VZrfoOwWSxNKaFXt7Iqpw/wM7be2dt0uMXT90dpgpwT139Uiuaw0FODO4YsMouDtbTsTYnk98HvhsZzrShQQSfgnz/ssvacpwbvOOzM4O93hIbejRAsZ/Ha+Rhng=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=iLObVoMY; arc=none smtp.client-ip=209.85.215.180
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pg1-f180.google.com with SMTP id 41be03b00d2f7-b2c3c689d20so1402443a12.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:29:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597383; x=1749202183; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=fsVmARra3PYHgocOota+jP5MYor7RDP1xSKc/otYVfE=;
b=iLObVoMYwVTx9dhtWeCngYlgKCMrTA89+js5cJ0RTSqzOZ4UgePxNvcf8jYO6Y5tUF
yT6Cf/7ITvg0YCbz+hQnvej2YkXbHWclcB9TkFDxHJw3LvvBigI/TeocZ8YFUoiwAVD4
fOjac9/1X7ptj3WKAnchTLK2e7NoPagBOZwkI7Go4RbmNvkaynfvxYRWDqrl6gpkHwoU
T20DkUTDq2gcdh98euhWD4xZCLZjGfH3Se/xiCQxFmNzDLSq1NhA4/DflY0Dg5z84yJz
R12oC38E1BmVKU+fjwnStUPCB6XMzTlFwEQqFqV7NuTLfPTtNxGZvAcOxFW7YPGU5OQ0
zISA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597383; x=1749202183;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=fsVmARra3PYHgocOota+jP5MYor7RDP1xSKc/otYVfE=;
b=c2QAfpLq7vI4JJbKBXzsV9d89WAGrTQDehiVToxkaisXP9SVy2uFU/4qAqVG9qdN7L
NLxAgnD1K4vt+xmgIN9P0OtepjQ7nCnmsnyIL5F3qDsm/77Br4Fq4lUn0GSkUOrDBJS7
uRntQlCtLSgYJsnX52+UHP/7mPB2wsW702wv/d7ZgO8+OomUbjwNTeSqmkszjxAmw2V+
KB/F9BBqJR7XEO6+ExXugid0vbLJvCN57Mnl4cyuWnCyRALK0hVlXPbtRRnp0VKXwjjY
ursVqC4F4gFZK7rkdtPVJuqQcsYy6Ln/rIfE0IkP5cgyPM6DxFB/FLIpO2mkLfRIEeaO
NdJg==
X-Forwarded-Encrypted: i=1; AJvYcCVI3wiydOaJVvz1u9dsFTbwfeSXpQP5ZrKz1/x3J+Yp14f2kZhvxdiN28yF+unys9U/1WzW1fP+LFz2H38=@vger.kernel.org
X-Gm-Message-State: AOJu0YwUSSRKB2E3VuLh4XsSykDwcCD6DClb29XgVLBsy5kXQv7jwB0j
ELzpHcQaJ929qbIrRf5lhJk7A9+n5FV6KtIzhsV+GN1ERtBY+I4APn8hrsnGmJAW0mk=
X-Gm-Gg: ASbGncuqwI1Xs357HAlty9U1AbH5N8FNkEC9tExt8ezmMGlXFB1qmOtWPSrdPaVXlmI
26wwwgFvuN7rZiQG8vngPk2zwNoUB9KZXoCHleTSOYzWmlx7jWvnUjDnhHA48WGvWPcPOFD7s7z
XLPZ7olBsKNCly1VDP1WXeXP5Bd4rALFb/CxScgoGaTHXBCYp5iLWSuf8at80pDb4vshh8q6rwy
gZjI/nf2P3r8BXNpcfiaiUskFjJyvz0sk03XsMhJbSHX+lAXhocMX5mvtc4SUmMTMoX3WRcp6Ke
SzWtzA7akm5VgMjKV0btl6bd+4msrc0zQ2xdr9gINGNkO6NvOQ4W7HCfV8b/6kHYwUumDhDiai4
oLniIxCRWSJBGxZScn/gWe/ySwO8igDw=
X-Google-Smtp-Source: AGHT+IGDxz/qX0egNQr6P0EaiRBDIQcZ9ust5aoVSte6/Q83iWKLonGQ/1cLLq8vU8IelvR0XV1gQw==
X-Received: by 2002:a17:90b:5344:b0:312:b4a:6342 with SMTP id 98e67ed59e1d1-31241e9c28fmr4334365a91.33.1748597382681;
Fri, 30 May 2025 02:29:42 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.29.27
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:29:42 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 05/35] RPAL: enable virtual address space partitions
Date: Fri, 30 May 2025 17:27:33 +0800
Message-Id: <a5737be8dc2fb2f5058f6536f081fed611bdd093.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Each RPAL service occupies a contiguous 512GB virtual address space, with
its base address determined by the id assigned during initialization. For
userspace virtual address space beyond this 512GB range, we employ memory
ballooning to occupy these regions, ensuring that processes do not utilize
these virtual addresses.
Since the address space layout is determined when the process is loaded,
RPAL sets the unused fields in the header of the ELF binary to the "RPAL"
characters to alter the loading method of RPAL processes, enabling the
process to be located within the correct 512GB address space upon loading.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/mm/mmap.c | 10 +++++
arch/x86/rpal/Makefile | 2 +-
arch/x86/rpal/mm.c | 70 +++++++++++++++++++++++++++++
arch/x86/rpal/service.c | 8 ++++
fs/binfmt_elf.c | 98 ++++++++++++++++++++++++++++++++++++++++-
include/linux/rpal.h | 65 +++++++++++++++++++++++++++
6 files changed, 251 insertions(+), 2 deletions(-)
create mode 100644 arch/x86/rpal/mm.c
diff --git a/arch/x86/mm/mmap.c b/arch/x86/mm/mmap.c
index 5ed2109211da..504f2b9a0e8e 100644
--- a/arch/x86/mm/mmap.c
+++ b/arch/x86/mm/mmap.c
@@ -19,6 +19,7 @@
#include <linux/sched/mm.h>
#include <linux/compat.h>
#include <linux/elf-randomize.h>
+#include <linux/rpal.h>
#include <asm/elf.h>
#include <asm/io.h>
@@ -119,6 +120,15 @@ static void arch_pick_mmap_base(unsigned long *base, unsigned long *legacy_base,
*base = mmap_base(random_factor, task_size, rlim_stack);
}
+#ifdef CONFIG_RPAL
+void rpal_pick_mmap_base(struct mm_struct *mm, struct rlimit *rlim_stack)
+{
+ arch_pick_mmap_base(&mm->mmap_base, &mm->mmap_legacy_base,
+ arch_rnd(RPAL_MAX_RAND_BITS), rpal_get_top(mm->rpal_rs),
+ rlim_stack);
+}
+#endif
+
void arch_pick_mmap_layout(struct mm_struct *mm, struct rlimit *rlim_stack)
{
if (mmap_is_legacy())
diff --git a/arch/x86/rpal/Makefile b/arch/x86/rpal/Makefile
index ee3698b5a9b3..2c858a8d7b9e 100644
--- a/arch/x86/rpal/Makefile
+++ b/arch/x86/rpal/Makefile
@@ -2,4 +2,4 @@
obj-$(CONFIG_RPAL) += rpal.o
-rpal-y := service.o core.o
+rpal-y := service.o core.o mm.o
diff --git a/arch/x86/rpal/mm.c b/arch/x86/rpal/mm.c
new file mode 100644
index 000000000000..f469bcf57b66
--- /dev/null
+++ b/arch/x86/rpal/mm.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RPAL service level operations
+ * Copyright (c) 2025, ByteDance. All rights reserved.
+ *
+ * Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
+ */
+
+#include <linux/rpal.h>
+#include <linux/security.h>
+#include <linux/mman.h>
+#include <linux/mm.h>
+
+static inline int rpal_balloon_mapping(unsigned long base, unsigned long size)
+{
+ struct vm_area_struct *vma;
+ unsigned long addr, populate;
+ int is_fail = 0;
+
+ if (size == 0)
+ return 0;
+
+ addr = do_mmap(NULL, base, size, PROT_NONE,
+ MAP_FIXED | MAP_ANONYMOUS | MAP_PRIVATE,
+ VM_DONTEXPAND | VM_PFNMAP | VM_DONTDUMP, 0, &populate,
+ NULL);
+
+ is_fail = base != addr;
+
+ if (is_fail) {
+ pr_info("rpal: Balloon mapping 0x%016lx - 0x%016lx, %s, addr: 0x%016lx\n",
+ base, base + size, is_fail ? "Fail" : "Success", addr);
+ }
+ vma = find_vma(current->mm, addr);
+ if (vma->vm_start != addr || vma->vm_end != addr + size) {
+ is_fail = 1;
+ rpal_err("rpal: find vma 0x%016lx - 0x%016lx fail\n", addr,
+ addr + size);
+ }
+
+ return is_fail;
+}
+
+#define RPAL_USER_TOP TASK_SIZE
+
+int rpal_balloon_init(unsigned long base)
+{
+ unsigned long top;
+ struct mm_struct *mm = current->mm;
+ int ret;
+
+ top = base + RPAL_ADDR_SPACE_SIZE;
+
+ mmap_write_lock(mm);
+
+ if (base > mmap_min_addr) {
+ ret = rpal_balloon_mapping(mmap_min_addr, base - mmap_min_addr);
+ if (ret)
+ goto out;
+ }
+
+ ret = rpal_balloon_mapping(top, RPAL_USER_TOP - top);
+ if (ret && base > mmap_min_addr)
+ do_munmap(mm, mmap_min_addr, base - mmap_min_addr, NULL);
+
+out:
+ mmap_write_unlock(mm);
+
+ return ret;
+}
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index 55ecb7e0ef8c..caa4afa5a2c6 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -143,6 +143,11 @@ static void delete_service(struct rpal_service *rs)
spin_unlock_irqrestore(&hash_table_lock, flags);
}
+static inline unsigned long calculate_base_address(int id)
+{
+ return RPAL_ADDRESS_SPACE_LOW + RPAL_ADDR_SPACE_SIZE * id;
+}
+
struct rpal_service *rpal_register_service(void)
{
struct rpal_service *rs;
@@ -168,6 +173,9 @@ struct rpal_service *rpal_register_service(void)
if (unlikely(rs->key == RPAL_INVALID_KEY))
goto key_fail;
+ rs->bad_service = false;
+ rs->base = calculate_base_address(rs->id);
+
current->rpal_rs = rs;
rs->group_leader = get_task_struct(current);
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index a43363d593e5..9d27d9922de4 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -47,6 +47,7 @@
#include <linux/dax.h>
#include <linux/uaccess.h>
#include <linux/rseq.h>
+#include <linux/rpal.h>
#include <asm/param.h>
#include <asm/page.h>
@@ -814,6 +815,61 @@ static int parse_elf_properties(struct file *f, const struct elf_phdr *phdr,
return ret == -ENOENT ? 0 : ret;
}
+#if IS_ENABLED(CONFIG_RPAL)
+static int rpal_create_service(char *e_ident, struct rpal_service **rs,
+ unsigned long *rpal_base, int *retval,
+ struct linux_binprm *bprm, int executable_stack)
+{
+ /*
+ * The first 16 bytes of the elf binary is magic number, and the last
+ * 7 bytes of that is reserved and ignored. We use the last 4 bytes
+ * to indicate a rpal binary. If the last 4 bytes is "RPAL", then this
+ * is a rpal binary and we need to do register routinue.
+ */
+ if (memcmp(e_ident + RPAL_MAGIC_OFFSET, RPAL_MAGIC, RPAL_MAGIC_LEN) ==
+ 0) {
+ unsigned long rpal_stack_top = STACK_TOP;
+
+ *rs = rpal_register_service();
+ if (*rs != NULL) {
+ *rpal_base = rpal_get_base(*rs);
+ rpal_stack_top = *rpal_base + RPAL_ADDR_SPACE_SIZE;
+ /*
+ * We need to recalculate the mmap_base, otherwise the address space
+ * layout randomization will not make any difference.
+ */
+ rpal_pick_mmap_base(current->mm, &bprm->rlim_stack);
+ }
+ /*
+ * RPAL process only has a contiguous 512GB address space, Whose base
+ * address is given by its struct rpal_service. We need to rearrange
+ * the user stack in this 512GB address space.
+ */
+ *retval = setup_arg_pages(bprm,
+ randomize_stack_top(rpal_stack_top),
+ executable_stack);
+ /*
+ * We use memory ballon to avoid kernel allocating vma other than
+ * the process's 512GB memory.
+ */
+ if (unlikely(*rs != NULL && rpal_balloon_init(*rpal_base))) {
+ rpal_err("pid: %d, comm: %s: rpal balloon init fail\n",
+ current->pid, current->comm);
+ rpal_unregister_service(*rs);
+ *rs = NULL;
+ *retval = -EINVAL;
+ goto out;
+ }
+ } else {
+ *retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP),
+ executable_stack);
+ }
+
+out:
+ return 0;
+}
+#endif
+
static int load_elf_binary(struct linux_binprm *bprm)
{
struct file *interpreter = NULL; /* to shut gcc up */
@@ -836,6 +892,10 @@ static int load_elf_binary(struct linux_binprm *bprm)
struct arch_elf_state arch_state = INIT_ARCH_ELF_STATE;
struct mm_struct *mm;
struct pt_regs *regs;
+#ifdef CONFIG_RPAL
+ struct rpal_service *rs = NULL;
+ unsigned long rpal_base;
+#endif
retval = -ENOEXEC;
/* First of all, some simple consistency checks */
@@ -1008,10 +1068,19 @@ static int load_elf_binary(struct linux_binprm *bprm)
setup_new_exec(bprm);
+#ifdef CONFIG_RPAL
+ /* call original function if fails */
+ if (rpal_create_service((char *)&elf_ex->e_ident, &rs, &rpal_base,
+ &retval, bprm, executable_stack))
+ retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP),
+ executable_stack);
+#else
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
retval = setup_arg_pages(bprm, randomize_stack_top(STACK_TOP),
executable_stack);
+#endif
+
if (retval < 0)
goto out_free_dentry;
@@ -1055,6 +1124,22 @@ static int load_elf_binary(struct linux_binprm *bprm)
* is needed.
*/
elf_flags |= MAP_FIXED_NOREPLACE;
+#ifdef CONFIG_RPAL
+ /*
+ * If We load MAP_FIXED binary, it will either fail when
+ * doing mmap, as we have done the memory balloon before,
+ * or work well, where we are so lucky to have fixed address
+ * in it's RPAL address space. A MAP_FIXED binary should
+ * by no means be a RPAL service. Here we only print
+ * an error. Maybe we will handle it in the future.
+ */
+ if (unlikely(rs != NULL)) {
+ rpal_err(
+ "pid: %d, common: %s, load a binary with MAP_FIXED segment\n",
+ current->pid, current->comm);
+ rs->bad_service = true;
+ }
+#endif
} else if (elf_ex->e_type == ET_DYN) {
/*
* This logic is run once for the first LOAD Program
@@ -1128,6 +1213,12 @@ static int load_elf_binary(struct linux_binprm *bprm)
/* Adjust alignment as requested. */
if (alignment)
load_bias &= ~(alignment - 1);
+#ifdef CONFIG_RPAL
+ if (rs != NULL) {
+ load_bias &= RPAL_RAND_ADDR_SPACE_MASK;
+ load_bias += rpal_base;
+ }
+#endif
elf_flags |= MAP_FIXED_NOREPLACE;
} else {
/*
@@ -1306,7 +1397,12 @@ static int load_elf_binary(struct linux_binprm *bprm)
if (!IS_ENABLED(CONFIG_COMPAT_BRK) &&
IS_ENABLED(CONFIG_ARCH_HAS_ELF_RANDOMIZE) &&
elf_ex->e_type == ET_DYN && !interpreter) {
- elf_brk = ELF_ET_DYN_BASE;
+#ifdef CONFIG_RPAL
+ if (rs && !rs->bad_service)
+ elf_brk = rpal_base;
+ else
+#endif
+ elf_brk = ELF_ET_DYN_BASE;
/* This counts as moving the brk, so let brk(2) know. */
brk_moved = true;
}
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 7b9d90b62b3f..f7c0de747f55 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -15,11 +15,17 @@
#include <linux/workqueue.h>
#include <linux/hashtable.h>
#include <linux/atomic.h>
+#include <linux/sizes.h>
#define RPAL_ERROR_MSG "rpal error: "
#define rpal_err(x...) pr_err(RPAL_ERROR_MSG x)
#define rpal_err_ratelimited(x...) pr_err_ratelimited(RPAL_ERROR_MSG x)
+/* RPAL magic macros in binary elf header */
+#define RPAL_MAGIC "RPAL"
+#define RPAL_MAGIC_OFFSET 12
+#define RPAL_MAGIC_LEN 4
+
/*
* The first 512GB is reserved due to mmap_min_addr.
* The last 512GB is dropped since stack will be initially
@@ -30,6 +36,47 @@
#define RPAL_FIRST_KEY _AC(1, UL)
#define RPAL_INVALID_KEY _AC(0, UL)
+/*
+ * Process Virtual Address Space Layout (For 4-level Paging)
+ * |-------------|
+ * | No Mapping |
+ * |-------------| <-- 64 KB (mmap_min_addr)
+ * | ... |
+ * |-------------| <-- 1 * 512GB
+ * | service 0 |
+ * |-------------| <-- 2 * 512 GB
+ * | Service 1 |
+ * |-------------| <-- 3 * 512 GB
+ * | Service 2 |
+ * |-------------| <-- 4 * 512 GB
+ * | ... |
+ * |-------------| <-- 255 * 512 GB
+ * | Service 254 |
+ * |-------------| <-- 128 TB
+ * | |
+ * | ... |
+ * |-------------| <-- PAGE_OFFSET
+ * | |
+ * | Kernel |
+ * |_____________|
+ *
+ */
+#define RPAL_ADDR_SPACE_SIZE (_AC(512, UL) * SZ_1G)
+/*
+ * Since RPAL restricts the virtual address space used by a single
+ * process to 512GB, the number of bits for address randomization
+ * must be correspondingly reduced; otherwise, issues such as overlaps
+ * in randomized addresses could occur. RPAL employs 20-bit (page number)
+ * address randomization to balance security and usability.
+ */
+#define RPAL_RAND_ADDR_SPACE_MASK _AC(0xfffffff0, UL)
+#define RPAL_MAX_RAND_BITS 20
+
+#define RPAL_NR_ADDR_SPACE 256
+
+#define RPAL_ADDRESS_SPACE_LOW ((0UL) + RPAL_ADDR_SPACE_SIZE)
+#define RPAL_ADDRESS_SPACE_HIGH ((0UL) + RPAL_NR_ADDR_SPACE * RPAL_ADDR_SPACE_SIZE)
+
/*
* Each RPAL process (a.k.a RPAL service) should have a pointer to
* struct rpal_service in all its tasks' task_struct.
@@ -52,6 +99,10 @@ struct rpal_service {
u64 key;
/* virtual address space id */
int id;
+ /* virtual address space base address of this service */
+ unsigned long base;
+ /* bad rpal binary */
+ bool bad_service;
/*
* Fields above should never change after initialization.
@@ -86,6 +137,16 @@ struct rpal_service *rpal_get_service(struct rpal_service *rs);
*/
void rpal_put_service(struct rpal_service *rs);
+static inline unsigned long rpal_get_base(struct rpal_service *rs)
+{
+ return rs->base;
+}
+
+static inline unsigned long rpal_get_top(struct rpal_service *rs)
+{
+ return rs->base + RPAL_ADDR_SPACE_SIZE;
+}
+
#ifdef CONFIG_RPAL
static inline struct rpal_service *rpal_current_service(void)
{
@@ -100,4 +161,8 @@ struct rpal_service *rpal_register_service(void);
struct rpal_service *rpal_get_service_by_key(u64 key);
void copy_rpal(struct task_struct *p);
void exit_rpal(bool group_dead);
+int rpal_balloon_init(unsigned long base);
+
+extern void rpal_pick_mmap_base(struct mm_struct *mm,
+ struct rlimit *rlim_stack);
#endif
--
2.20.1
Return-Path: <linux-kernel+bounces-667868-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 6127941E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:32:25 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 70E969E270F
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:51 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id CDC1422B8CE;
Fri, 30 May 2025 09:30:12 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="L3OEBkIb"
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
(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 4010A2206BB
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:09 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597411; cv=none; b=by5Cu+cPW/90OwiKAs+V8+q1GAB76hx9a7xtpXSOZfUYR4hFWz/Fweuj78ZMZKydQxOnMBc2ArKZ1WNcPM7FO/ijp1+FgifdoUsGwfFx1dQ21/2vM3RMVBk04gvoau06dMUsfRvw81YkHQOXw1UUl8AqC7j5VO/p2/rlnzdu3Ec=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597411; c=relaxed/simple;
bh=nMA6BOKNQortAfZjTY+8NXKVM4Z8Hukb0WuDxYV4S0c=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=WGUGva8WufawxxY2vUHMLe75ryTqBaAXzDZ6T/C75qW/HbIxh25z3eGwaxp0GoskiwVyLZTYPvDO+xUyoE4Tb6AszGuMShNDr6LJViiraO/+Fj9j5vCwJQhbz3xKA8Eat6hIuXs+n53UCdkyRhk6tEvIB8jRmbe04FmRGTTikuM=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=L3OEBkIb; arc=none smtp.client-ip=170.10.133.124
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1748597408;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:autocrypt:autocrypt;
bh=0RNzhwsqUku1xsJElyNHLGqFPxx7/6+2t/Rn5eNr9pY=;
b=L3OEBkIbVlM/qinu0CvWlKb4eKT2iycTEiGBmVVVsscYWTx/AVC36IBzQOzSDwjfRv/KEY
IVXRTDHswsvRzjs+eQB7T1LilDKFCu0xT/f2ijsmyd0nhQ6Pv1rx9v/xLw4iUwjqbdXlpV
7KDk2ZiYxYsHmRX8P8CNpNJpTsUWvcc=
Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com
[209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-604-fRnALyDZMay1iMvn-vPq7Q-1; Fri, 30 May 2025 05:30:07 -0400
X-MC-Unique: fRnALyDZMay1iMvn-vPq7Q-1
X-Mimecast-MFC-AGG-ID: fRnALyDZMay1iMvn-vPq7Q_1748597406
Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-43d007b2c79so14782585e9.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:30:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597406; x=1749202206;
h=content-transfer-encoding:in-reply-to:organization:autocrypt
:content-language:from:references:cc:to:subject:user-agent
:mime-version:date:message-id:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=0RNzhwsqUku1xsJElyNHLGqFPxx7/6+2t/Rn5eNr9pY=;
b=FPgcVjb8L/QW84Tv3YLlYKXd3PY4OxEhMYvpR37IkxJTmnzKC3uw3TznaxNAUcGuf1
xIb3cM9WPZArcaTjtLjmKuqVxJlIZccYaVrtCwUeamAh46sBWjfYS29FRjXlMRYiJj2C
NkZTHS8TOqSaKx8zGdM+JCtVr5yq7LbtCvwPk9vy+KSlfJ+uXkJPRRm8p0qG1d/y93Zg
6cFnQNCyYBkryp3BDIB72FWeH+zhxTkcGwf6KXGtQqZAUqsLZ/3pnCF1tjQe6tj/rm6l
oy2rr2H7SXnBCrqHgKmQMSy8RHgBIcUAEKRMa5NGS5N/fKugmMslk0lDNorHEP83eNx1
6B7A==
X-Gm-Message-State: AOJu0YwYa8v12eLpzhARgVhjn8W0C1QreNhDcmXFkNeI3paESzsI6Bx3
7L0HgTn+v2qSokmW8A8IrXZGYK2/1YE/H0aG8msp/AQ2H5QjyrMcSIzKKiIBUmsgI1UjRX8nV45
MrLTiP8ljx0xfv0mBsjHYdpyEBYJTuS0Hs/XL2E6uQ/Isx1VfrifqNZdAKXKxis+596vuuJpoZK
ko
X-Gm-Gg: ASbGncvvFCS4J0WmY32JYf/h0ctRL9/eR5ohIJrAqmn1NI3U7PC9mX4VjG/jqzXdrQD
x0Ay3bFyomhmcOzhzvBh/Zy3OspRsfvJFP8QqYfVpjm/yxssCMCDj1VNoAEBNmHGa1IlwDjf2BM
0ozdpWVV7dp6EcH6cT5fovNtj3uhJZNF5KU3X96nFCssXp2yJWy1yTYudmdZFUBASqWmdrWwYZ2
F1gWdJRdEw376orgpoPHF5gTVR6agolnVfPeVU71/MHlWc7hLCR1c+IqPTvDqItWDdo8kd3aseM
sMVxtj50KiSEJVTu1k7P5BipDmPvIaFYsg8gZ9sI7X26NITAvXk0F/xNX3Dq0TKTsIdg9dPhmO7
+UpPXGlidvxA3KtwyIVRTENcKl8jeiakVZQ/en1g=
X-Received: by 2002:a05:600c:a088:b0:442:f97f:8174 with SMTP id 5b1f17b1804b1-450d6547524mr26073855e9.18.1748597405843;
Fri, 30 May 2025 02:30:05 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IF2BOtiydMOfq1UD1dFaTSdbt9kgs6g/FvHe0NUDZiW/Mb+ZwIUaJljI/hl7D5dUDFLJdO/0w==
X-Received: by 2002:a05:600c:a088:b0:442:f97f:8174 with SMTP id 5b1f17b1804b1-450d6547524mr26073605e9.18.1748597405404;
Fri, 30 May 2025 02:30:05 -0700 (PDT)
Received: from ?IPV6:2003:d8:2f03:5b00:f549:a879:b2d3:73ee? (p200300d82f035b00f549a879b2d373ee.dip0.t-ipconnect.de. [2003:d8:2f03:5b00:f549:a879:b2d3:73ee])
by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a4efe6c525sm4319304f8f.23.2025.05.30.02.30.04
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 May 2025 02:30:04 -0700 (PDT)
Message-ID: <40c773a3-e1d7-4c8c-a6e4-793f8aa7f983@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:30:04 +0200
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/3] virtio-mem: fix multiple typos in struct comments
and function docs
To: Alok Tiwari <alok.a.tiwari@xxxxxxxxxx>, mst@xxxxxxxxxx,
jasowang@xxxxxxxxxx, xuanzhuo@xxxxxxxxxxxxxxxxx, eperezma@xxxxxxxxxx,
virtualization@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx, darren.kenny@xxxxxxxxxx
References: <20250529084350.3145699-1-alok.a.tiwari@xxxxxxxxxx>
<20250529084350.3145699-2-alok.a.tiwari@xxxxxxxxxx>
From: David Hildenbrand <david@xxxxxxxxxx>
Content-Language: en-US
Autocrypt: addr=david@xxxxxxxxxx; keydata=
xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ
dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL
QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp
XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK
Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9
PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt
WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc
UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv
jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb
B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk
ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW
AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q
9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp
rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf
wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4
3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l
pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd
KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE
BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs
9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF
89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9
M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz
Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb
T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A
2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk
CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G
NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75
7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx
5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS
lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv
AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa
N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3
AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB
boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq
3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f
XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ
a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq
Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6
3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8
kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E
th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr
jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt
WNyWQQ==
Organization: Red Hat
In-Reply-To: <20250529084350.3145699-2-alok.a.tiwari@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-6.3 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On 29.05.25 10:42, Alok Tiwari wrote:
> Corrected several spelling mistakes in code comments, including:
> - "bock" -> "block"
> - "valued" -> "value"
> - "actipn" -> "action"
> - "accidentially" -> "accidentally"
> - Improved grammar in a few places for clarity.
>
> These changes are purely cosmetic and do not affect functionality.
>
> Signed-off-by: Alok Tiwari <alok.a.tiwari@xxxxxxxxxx>
Reviewed-by: David Hildenbrand <david@xxxxxxxxxx>
--
Cheers,
David / dhildenb
Return-Path: <linux-kernel+bounces-667867-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9FABD41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:32:41 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id 932241889766
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:32:14 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 648182236FF;
Fri, 30 May 2025 09:30:01 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="WB6z6OIw"
Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49])
(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 E5B96222562
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:29:58 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597400; cv=none; b=cSDtoDO1RgGBhmB1lKshupq1FuNLViznCtclqM0+R+ZmYfcTnlCEw475PB7gCkjCRju4UayXz3QKaXDUDzsYazT7AYWDmSptRFueU/XSJobi9TxffU4DfhSdqd8vWDN/h/sL1exidYJT+blFTP0qtuZM5m/gAML1dLTlPFUnRyA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597400; c=relaxed/simple;
bh=VIZG5AiWC/s7En/XmKPIO2DjZgsCQ6G5W9Jx/My9WHo=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=fvpkuSnPGtfbg/BAhDejjUOM2QLUZMMUAWAwlgDG9HvjY3wtshiUP1dlk0gyF+r0X3FaZrONnIMmTp9sU1LDkj57SQQuUfhH691/kWXU+YqgBMz4J9ni1Q1uRDOj2WWf27v0ru2VgMCIDluEbQ26/M5FmZm21VNPOD+JXwW65cA=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=WB6z6OIw; arc=none smtp.client-ip=209.85.216.49
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-312116d75a6so1581828a91.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:29:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597398; x=1749202198; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=rxNHqqJshuS1h1cgjJgJ0ZrC1Xqsxa5tk/BB5ji3hvs=;
b=WB6z6OIw5FMSobnxLBt+fPmPsX/NsOiTiisAYiUGKxuhRaLdy/ylTQVQVyf4Dg6kI/
Jx/wkwLFji+l2wZ7nS6xPiWQDqHH5Bv23q2M8bNC3MBIMq22NYwZcwzGKug2VkHWcFW5
Yhlmw5c+XWobbD+qMo7S/YQs4FZrJy3B/FQACXZ8HebyhjqZ8bH3u4Hlqs7/jglQejc4
rZiaNVK4g5bik6IOs5wiJQ13/WYUNFY3iiMIF1wvviEcKkIjVt8CnlhFQGEy0Vx3Bc6L
yTpm9aJ+BemoU+Pg6tleE3oHLwOY6LW4/wjv7hEosq+BxU+lCwMCi+6B0l+CcjM6f3Yh
GJgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597398; x=1749202198;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=rxNHqqJshuS1h1cgjJgJ0ZrC1Xqsxa5tk/BB5ji3hvs=;
b=odk1AsfM+CdUV8Q/gaRkfOt4zCVOTLMOYxxcAbwjAX7VhLNZEnJHhPsBzOTjCnlWRG
6ROU8oVugf556Chi/4BW2W5O0MWGMESMVHy/lAl7+pL+uA86rEqZUsBzVFnntxm6qKM1
CI8nwcIo0r9S9B0uY2OJN0r0MlIG+zgkiCMMXWfh11GonrdBh/ppHDOMkeU7b2ibmKhd
MTs2D6b0iiUYFRz5vCEHGj/Z5WFgfak3KATv8JozYXpwVMhLKSgETCY0t6qTsV+FIDAS
IceQQnopLoodIWUrMdIUc6jOUhCCujSQYn6uFUzWzMJt5nhNi7HvPEeOzBrtCwq6rQeD
F4aA==
X-Forwarded-Encrypted: i=1; AJvYcCW44j5GxawEuxTUQEOHAsPhBE7Fpfek1ZDonAVQ6XMp7XtacNv4jNgP1IkwK42ZUsrwJhhBCUQ9DHe6NPE=@vger.kernel.org
X-Gm-Message-State: AOJu0YyG2+za+waH3z2qZCRBLNOzTs2t5cR+ap7czTadw4k7iQ8eYx3W
a8etKc6riXAfvxEDeqEgwDpQc0dO0jGxUU4uMSZx/CdkMhqlW13/Pinne+inGr8jRGI=
X-Gm-Gg: ASbGncs0IPDWF8MNewPKfnBua2jsQPW9lTEeX0LVFopSj51OFjaf5/sVlDuVqcMMwse
NvFOukxdCJuY3+g2EvB1/sPtyH6bM5/V315F6ZR6Sr1qDH5zLy49pVNTbUhWRa73t4a/GK7co/Z
uGlIaLpqey5uRjddl5p2c++xl7kgCAVrYNckjza+NkXk631bmwBSwOIXCMpewUpgP9YuG/ddqWu
zkjDKnx6i/v49krkbdsW9k7cSnhf+a/mVh4zKZQ738psoILKQcqBsPjRBGnoiPVWP7nSDwmAH0V
i8pmle4nDBfvfE33nUTJMskZjpnaEZ3ytu2lwlrWIRYGYJdondbHeAIgsci6Ce1i+eGd6qQBwfj
iKy6kiFhCww==
X-Google-Smtp-Source: AGHT+IGBCG8Y5BoAzUhA//fCiLwTsxIymub8I3vmhNOr1M4fJfMNuuh617dJ5r3jIttsydinbIXPuQ==
X-Received: by 2002:a17:90b:39c5:b0:311:b5ac:6f5d with SMTP id 98e67ed59e1d1-31241e975d6mr4419282a91.29.1748597398101;
Fri, 30 May 2025 02:29:58 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.29.43
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:29:57 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 06/35] RPAL: add user interface
Date: Fri, 30 May 2025 17:27:34 +0800
Message-Id: <de89b7dbd8277f809c61b1220cdca29875863fd6.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Add the userspace interface of RPAL. The interface makes use of /proc
files. Compared with adding syscalls, /proc files provide more interfaces,
such as mmap, poll, etc. These interfaces can facilitate RPAL to implement
more complex kernel-space/user-space interaction functions in the future.
This patch implements the ioctl interface, The interfaces initially
implemented include obtaining the RPAL version, and retrieving the key and
ID of the RPAL service.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/Makefile | 2 +-
arch/x86/rpal/core.c | 3 ++
arch/x86/rpal/internal.h | 3 ++
arch/x86/rpal/proc.c | 71 ++++++++++++++++++++++++++++++++++++++++
include/linux/rpal.h | 34 +++++++++++++++++++
5 files changed, 112 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/rpal/proc.c
diff --git a/arch/x86/rpal/Makefile b/arch/x86/rpal/Makefile
index 2c858a8d7b9e..a5926fc19334 100644
--- a/arch/x86/rpal/Makefile
+++ b/arch/x86/rpal/Makefile
@@ -2,4 +2,4 @@
obj-$(CONFIG_RPAL) += rpal.o
-rpal-y := service.o core.o mm.o
+rpal-y := service.o core.o mm.o proc.o
diff --git a/arch/x86/rpal/core.c b/arch/x86/rpal/core.c
index 495dbc1b1536..61f5d40b0157 100644
--- a/arch/x86/rpal/core.c
+++ b/arch/x86/rpal/core.c
@@ -13,11 +13,14 @@
int __init rpal_init(void);
bool rpal_inited;
+unsigned long rpal_cap;
int __init rpal_init(void)
{
int ret = 0;
+ rpal_cap = 0;
+
ret = rpal_service_init();
if (ret)
goto fail;
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
index e44e6fc79677..c102a4c50515 100644
--- a/arch/x86/rpal/internal.h
+++ b/arch/x86/rpal/internal.h
@@ -6,6 +6,9 @@
* Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
*/
+#define RPAL_COMPAT_VERSION 1
+#define RPAL_API_VERSION 1
+
extern bool rpal_inited;
/* service.c */
diff --git a/arch/x86/rpal/proc.c b/arch/x86/rpal/proc.c
new file mode 100644
index 000000000000..1ced30e25c15
--- /dev/null
+++ b/arch/x86/rpal/proc.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * RPAL service level operations
+ * Copyright (c) 2025, ByteDance. All rights reserved.
+ *
+ * Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
+ */
+
+#include <linux/rpal.h>
+#include <linux/proc_fs.h>
+
+#include "internal.h"
+
+static int rpal_open(struct inode *inode,
+ struct file *file)
+{
+ return 0;
+}
+
+static int rpal_get_api_version_and_cap(void __user *p)
+{
+ struct rpal_version_info rvi;
+ int ret;
+
+ rvi.compat_version = RPAL_COMPAT_VERSION;
+ rvi.api_version = RPAL_API_VERSION;
+ rvi.cap = rpal_cap;
+
+ ret = copy_to_user(p, &rvi, sizeof(rvi));
+ if (ret)
+ return -EFAULT;
+
+ return 0;
+}
+
+static long rpal_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
+{
+ struct rpal_service *cur = rpal_current_service();
+ int ret = 0;
+
+ if (!cur)
+ return -EINVAL;
+
+ switch (cmd) {
+ case RPAL_IOCTL_GET_API_VERSION_AND_CAP:
+ ret = rpal_get_api_version_and_cap((void __user *)arg);
+ break;
+ case RPAL_IOCTL_GET_SERVICE_KEY:
+ ret = put_user(cur->key, (u64 __user *)arg);
+ break;
+ case RPAL_IOCTL_GET_SERVICE_ID:
+ ret = put_user(cur->id, (int __user *)arg);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+const struct proc_ops proc_rpal_operations = {
+ .proc_open = rpal_open,
+ .proc_ioctl = rpal_ioctl,
+};
+
+static int __init proc_rpal_init(void)
+{
+ proc_create("rpal", 0644, NULL, &proc_rpal_operations);
+ return 0;
+}
+fs_initcall(proc_rpal_init);
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index f7c0de747f55..3bc2a2a44265 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -77,6 +77,8 @@
#define RPAL_ADDRESS_SPACE_LOW ((0UL) + RPAL_ADDR_SPACE_SIZE)
#define RPAL_ADDRESS_SPACE_HIGH ((0UL) + RPAL_NR_ADDR_SPACE * RPAL_ADDR_SPACE_SIZE)
+extern unsigned long rpal_cap;
+
/*
* Each RPAL process (a.k.a RPAL service) should have a pointer to
* struct rpal_service in all its tasks' task_struct.
@@ -118,6 +120,38 @@ struct rpal_service {
atomic_t refcnt;
};
+/*
+ * Following structures should have the same memory layout with user.
+ * It seems nothing being different between kernel and user structure
+ * padding by different C compilers on x86_64, so we need to do nothing
+ * special here.
+ */
+/* Begin */
+struct rpal_version_info {
+ int compat_version;
+ int api_version;
+ unsigned long cap;
+};
+
+/* End */
+
+enum rpal_command_type {
+ RPAL_CMD_GET_API_VERSION_AND_CAP,
+ RPAL_CMD_GET_SERVICE_KEY,
+ RPAL_CMD_GET_SERVICE_ID,
+ RPAL_NR_CMD,
+};
+
+/* RPAL ioctl macro */
+#define RPAL_IOCTL_MAGIC 0x33
+#define RPAL_IOCTL_GET_API_VERSION_AND_CAP \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_GET_API_VERSION_AND_CAP, \
+ struct rpal_version_info *)
+#define RPAL_IOCTL_GET_SERVICE_KEY \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_GET_SERVICE_KEY, u64 *)
+#define RPAL_IOCTL_GET_SERVICE_ID \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_GET_SERVICE_ID, int *)
+
/**
* @brief get new reference to a rpal service, a corresponding
* rpal_put_service() should be called later by the caller.
--
2.20.1
Return-Path: <linux-kernel+bounces-667870-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 6696D41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:32:49 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 552EE170780
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:32:48 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id A3849223DE7;
Fri, 30 May 2025 09:30:33 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="ihzlDemt"
Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47])
(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 964921E8323
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:29 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.47
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597432; cv=none; b=Rpm4LmdSmwg8YfYcFS4InE2mr3pCMatHgwX+HY1cqgLs4yLcglmhRqRMx2nJlg06F69UpZXG/nikvBVsA3oHbXEiFwhb+arcxThyLLTEuWiXrulivIa+tGD5kb2uoUGr8nq6XcR/uDDBJeCG9gECgIQpj3sDbxZaj5Vl8VM0+/c=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597432; c=relaxed/simple;
bh=DFUGROHVCTniD49Ozv49pSZ2hICpYueXEA09N4l6CVc=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=Bv94HmpRQ4PW4Zacn5VNzLXGX7tz56Ek0CqKjvX4BOaxlFoNadD+gbWofi56iExrMoqEWp3xJiL+sStjrS6dGNJG+7JRMRmvO82jJn2vZNdpLsJT4SgHGKLtnCa2ZR9Z19YesaCa29vHeuCjH4oKn4Ep8Dw1T031XW1z6HrnCzs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=ihzlDemt; arc=none smtp.client-ip=209.85.216.47
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-30e5430ed0bso1620769a91.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:30:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597429; x=1749202229; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=It0nagCB2dMHz+A5VnrcLdhvjSzG9DfFTU//7hpwVEI=;
b=ihzlDemthbTov5PXhPgH3PlMpPQsHOe4zKAOJCRsWUntI5rjURuIxsST5IrMwsmZXr
cMDEeCqiJd11fkseRgWWyviZqSJkK90CiEOQCi+63DZPZGAwHHbVuNqC/asOl1MrlB+U
B9XEHrLdr001jKPVuSAEHq2+C6XfUM/p8jWCMM4aE2JCGwafNiP5n7tD2YKVlCgT72A2
+YQ9G7z8HD8tX/VLki2z6cgf2nB9c3s2CKVZG0bq3TQqvrfq6HxAW6Vi6S1ieVoG/m0h
jJyF82BmP7J2fnlAb4gZu5bAYyrwIZ9M2HKGl+A/8fnY7L3tu3ITXC0hQjFrT7os80aw
jvlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597429; x=1749202229;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=It0nagCB2dMHz+A5VnrcLdhvjSzG9DfFTU//7hpwVEI=;
b=MkweBph4W5yhelBknbj1Bs6S/htHdx8UvwCYPVz0u4X5k0OR6fG4P0EJmVsrIvnXFX
+FDQD8LOvm4BcGD6G57XKxMAKvXUn7XOxoC/nb7wOf6hu0V7RFo7eUEncPv+ihHMBIUR
FTkXmR5URGVAMnFI7Mi5Acp6ZPcSW2u9SYn6r6yec5KKFqDc6XsYTP8NklH3pNJiMSir
8kVRenPmjPB1vMvFl4rZheAe8kwPCKzxQcIWb/vUe25H6lkUIECZTkiwO2cUVQJgBi7Q
rSxG8X9TB4Q2ApmwJcJdBwtNEsHQ0v/cvI0dJi1eBW4IIZuAJyFEZlY4Gbxj6XePrFzM
7reQ==
X-Forwarded-Encrypted: i=1; AJvYcCWllE6eT2TZJ/OUoFSHDV6DcgBKK7PV4msB7UTMUSV9zxlMckSDNpuOFof4KW4o0oQb9CQzUO68pKmkPqY=@vger.kernel.org
X-Gm-Message-State: AOJu0YyQMEW3RBe5J/Zc/zJRKf431KZX+wkjLzaqx0kRQlL+pj2TrQa5
K+7ccDK75LoOXaBDBzAGP6kaZIAELIOMnpfXcGA58XLG+UZZ5JygX73tPvTZ3RIRxdM=
X-Gm-Gg: ASbGnct2sLmLeto6yy1A9xyGr+Icv51i3GSfFbYCAcPpEXSiE52eSs7p/qxgurULjdA
bPz82f7c31excF3+3XCTMBV3WpxQMnOYNxeY/shViRxbHtSajaZBnmIWMXo6lrRQ2sD0XtM6am4
sen8Lz1GkW6WHSwpPNULTibv0ogYV2LxKH/1rgqoEmoJOATtsebcKjK3GA1J5XyKqRVJuoJbAWP
8tTL0kXjRy1ADnnjO8iwjsctHzYFGpdEqDtNfGzmLsbFXXdhpYIvO3mQjc8v3tsTA6z4sIzOa4o
oHT54uY6SQx2mRiu6raQaLtB2MTtWJPB2voFYY6hPxaAhhi1mAU+TdrWKbem6Xb/XEjkvTm4jWk
0VioC/6hawOeVZUH7f4rG
X-Google-Smtp-Source: AGHT+IHhFP+YSRyY0vGcXgga6NhFTtrcJFFIO4OfIe90gNYiOLxgktzPA73bwtmVpC1QBkXNF+uurw==
X-Received: by 2002:a17:90b:4fd2:b0:311:f99e:7f4a with SMTP id 98e67ed59e1d1-31250427d15mr1963416a91.26.1748597428884;
Fri, 30 May 2025 02:30:28 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.30.13
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:30:28 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 08/35] RPAL: enable sender/receiver registration
Date: Fri, 30 May 2025 17:27:36 +0800
Message-Id: <a999df69234df38638909f3503d99bd6d8e54a84.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
In RPAL, there are two roles: the sender (caller) and the receiver (
callee). This patch provides an interface for threads to register as
a sender or a receiver with the kernel. Each sender and receiver has
its own data structure, along with a block of memory shared between the
user space and the kernel space, which is allocated through rpal_mmap().
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/Makefile | 2 +-
arch/x86/rpal/internal.h | 7 ++
arch/x86/rpal/proc.c | 12 +++
arch/x86/rpal/service.c | 6 ++
arch/x86/rpal/thread.c | 165 +++++++++++++++++++++++++++++++++++++++
include/linux/rpal.h | 79 +++++++++++++++++++
include/linux/sched.h | 15 ++++
init/init_task.c | 2 +
kernel/fork.c | 2 +
9 files changed, 289 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/rpal/thread.c
diff --git a/arch/x86/rpal/Makefile b/arch/x86/rpal/Makefile
index a5926fc19334..89f745382c51 100644
--- a/arch/x86/rpal/Makefile
+++ b/arch/x86/rpal/Makefile
@@ -2,4 +2,4 @@
obj-$(CONFIG_RPAL) += rpal.o
-rpal-y := service.o core.o mm.o proc.o
+rpal-y := service.o core.o mm.o proc.o thread.o
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
index 65fd14a26f0e..3559c9c6e868 100644
--- a/arch/x86/rpal/internal.h
+++ b/arch/x86/rpal/internal.h
@@ -34,3 +34,10 @@ static inline void rpal_put_shared_page(struct rpal_shared_page *rsp)
int rpal_mmap(struct file *filp, struct vm_area_struct *vma);
struct rpal_shared_page *rpal_find_shared_page(struct rpal_service *rs,
unsigned long addr);
+
+/* thread.c */
+int rpal_register_sender(unsigned long addr);
+int rpal_unregister_sender(void);
+int rpal_register_receiver(unsigned long addr);
+int rpal_unregister_receiver(void);
+void exit_rpal_thread(void);
diff --git a/arch/x86/rpal/proc.c b/arch/x86/rpal/proc.c
index 86947dc233d0..8a1e4a8a2271 100644
--- a/arch/x86/rpal/proc.c
+++ b/arch/x86/rpal/proc.c
@@ -51,6 +51,18 @@ static long rpal_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
case RPAL_IOCTL_GET_SERVICE_ID:
ret = put_user(cur->id, (int __user *)arg);
break;
+ case RPAL_IOCTL_REGISTER_SENDER:
+ ret = rpal_register_sender(arg);
+ break;
+ case RPAL_IOCTL_UNREGISTER_SENDER:
+ ret = rpal_unregister_sender();
+ break;
+ case RPAL_IOCTL_REGISTER_RECEIVER:
+ ret = rpal_register_receiver(arg);
+ break;
+ case RPAL_IOCTL_UNREGISTER_RECEIVER:
+ ret = rpal_unregister_receiver();
+ break;
default:
return -EINVAL;
}
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index f29a046fc22f..42fb719dbb2a 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -176,6 +176,7 @@ struct rpal_service *rpal_register_service(void)
mutex_init(&rs->mutex);
rs->nr_shared_pages = 0;
INIT_LIST_HEAD(&rs->shared_pages);
+ atomic_set(&rs->thread_cnt, 0);
rs->bad_service = false;
rs->base = calculate_base_address(rs->id);
@@ -216,6 +217,9 @@ void rpal_unregister_service(struct rpal_service *rs)
if (!rs)
return;
+ while (atomic_read(&rs->thread_cnt) != 0)
+ schedule();
+
delete_service(rs);
pr_debug("rpal: unregister service, id: %d, tgid: %d\n", rs->id,
@@ -238,6 +242,8 @@ void exit_rpal(bool group_dead)
if (!rs)
return;
+ exit_rpal_thread();
+
current->rpal_rs = NULL;
rpal_put_service(rs);
diff --git a/arch/x86/rpal/thread.c b/arch/x86/rpal/thread.c
new file mode 100644
index 000000000000..7550ad94b63f
--- /dev/null
+++ b/arch/x86/rpal/thread.c
@@ -0,0 +1,165 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * RPAL service level operations
+ * Copyright (c) 2025, ByteDance. All rights reserved.
+ *
+ * Author: Jiadong Sun <sunjiadong.lff@xxxxxxxxxxxxx>
+ */
+
+#include <linux/rpal.h>
+
+#include "internal.h"
+
+static void rpal_common_data_init(struct rpal_common_data *rcd)
+{
+ rcd->bp_task = current;
+ rcd->service_id = rpal_current_service()->id;
+}
+
+int rpal_register_sender(unsigned long addr)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_shared_page *rsp;
+ struct rpal_sender_data *rsd;
+ long ret = 0;
+
+ if (rpal_test_current_thread_flag(RPAL_SENDER_BIT)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ rsp = rpal_find_shared_page(cur, addr);
+ if (!rsp) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (addr + sizeof(struct rpal_sender_call_context) >
+ rsp->user_start + rsp->npage * PAGE_SIZE) {
+ ret = -EINVAL;
+ goto put_shared_page;
+ }
+
+ rsd = kzalloc(sizeof(*rsd), GFP_KERNEL);
+ if (rsd == NULL) {
+ ret = -ENOMEM;
+ goto put_shared_page;
+ }
+
+ rpal_common_data_init(&rsd->rcd);
+ rsd->rsp = rsp;
+ rsd->scc = (struct rpal_sender_call_context *)(addr - rsp->user_start +
+ rsp->kernel_start);
+
+ current->rpal_sd = rsd;
+ rpal_set_current_thread_flag(RPAL_SENDER_BIT);
+
+ atomic_inc(&cur->thread_cnt);
+
+ return 0;
+
+put_shared_page:
+ rpal_put_shared_page(rsp);
+out:
+ return ret;
+}
+
+int rpal_unregister_sender(void)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_sender_data *rsd = current->rpal_sd;
+ long ret = 0;
+
+ if (!rpal_test_current_thread_flag(RPAL_SENDER_BIT)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ rpal_put_shared_page(rsd->rsp);
+ rpal_clear_current_thread_flag(RPAL_SENDER_BIT);
+ kfree(rsd);
+
+ atomic_dec(&cur->thread_cnt);
+
+out:
+ return ret;
+}
+
+int rpal_register_receiver(unsigned long addr)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_receiver_data *rrd;
+ struct rpal_shared_page *rsp;
+ long ret = 0;
+
+ if (rpal_test_current_thread_flag(RPAL_RECEIVER_BIT)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ rsp = rpal_find_shared_page(cur, addr);
+ if (!rsp) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (addr + sizeof(struct rpal_receiver_call_context) >
+ rsp->user_start + rsp->npage * PAGE_SIZE) {
+ ret = -EINVAL;
+ goto put_shared_page;
+ }
+
+ rrd = kzalloc(sizeof(*rrd), GFP_KERNEL);
+ if (rrd == NULL) {
+ ret = -ENOMEM;
+ goto put_shared_page;
+ }
+
+ rpal_common_data_init(&rrd->rcd);
+ rrd->rsp = rsp;
+ rrd->rcc =
+ (struct rpal_receiver_call_context *)(addr - rsp->user_start +
+ rsp->kernel_start);
+
+ current->rpal_rd = rrd;
+ rpal_set_current_thread_flag(RPAL_RECEIVER_BIT);
+
+ atomic_inc(&cur->thread_cnt);
+
+ return 0;
+
+put_shared_page:
+ rpal_put_shared_page(rsp);
+out:
+ return ret;
+}
+
+int rpal_unregister_receiver(void)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_receiver_data *rrd = current->rpal_rd;
+ long ret = 0;
+
+ if (!rpal_test_current_thread_flag(RPAL_RECEIVER_BIT)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ rpal_put_shared_page(rrd->rsp);
+ rpal_clear_current_thread_flag(RPAL_RECEIVER_BIT);
+ kfree(rrd);
+
+ atomic_dec(&cur->thread_cnt);
+
+out:
+ return ret;
+}
+
+void exit_rpal_thread(void)
+{
+ if (rpal_test_current_thread_flag(RPAL_SENDER_BIT))
+ rpal_unregister_sender();
+
+ if (rpal_test_current_thread_flag(RPAL_RECEIVER_BIT))
+ rpal_unregister_receiver();
+}
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 986dfbd16fc9..c33425e896af 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -79,6 +79,11 @@
extern unsigned long rpal_cap;
+enum rpal_task_flag_bits {
+ RPAL_SENDER_BIT,
+ RPAL_RECEIVER_BIT,
+};
+
/*
* Each RPAL process (a.k.a RPAL service) should have a pointer to
* struct rpal_service in all its tasks' task_struct.
@@ -117,6 +122,9 @@ struct rpal_service {
int nr_shared_pages;
struct list_head shared_pages;
+ /* sender/receiver thread count */
+ atomic_t thread_cnt;
+
/* delayed service put work */
struct delayed_work delayed_put_work;
@@ -149,10 +157,55 @@ struct rpal_shared_page {
struct list_head list;
};
+struct rpal_common_data {
+ /* back pointer to task_struct */
+ struct task_struct *bp_task;
+ /* service id of rpal_service */
+ int service_id;
+};
+
+/* User registers state */
+struct rpal_task_context {
+ u64 r15;
+ u64 r14;
+ u64 r13;
+ u64 r12;
+ u64 rbx;
+ u64 rbp;
+ u64 rip;
+ u64 rsp;
+};
+
+struct rpal_receiver_call_context {
+ struct rpal_task_context rtc;
+ int receiver_id;
+};
+
+struct rpal_receiver_data {
+ struct rpal_common_data rcd;
+ struct rpal_shared_page *rsp;
+ struct rpal_receiver_call_context *rcc;
+};
+
+struct rpal_sender_call_context {
+ struct rpal_task_context rtc;
+ int sender_id;
+};
+
+struct rpal_sender_data {
+ struct rpal_common_data rcd;
+ struct rpal_shared_page *rsp;
+ struct rpal_sender_call_context *scc;
+};
+
enum rpal_command_type {
RPAL_CMD_GET_API_VERSION_AND_CAP,
RPAL_CMD_GET_SERVICE_KEY,
RPAL_CMD_GET_SERVICE_ID,
+ RPAL_CMD_REGISTER_SENDER,
+ RPAL_CMD_UNREGISTER_SENDER,
+ RPAL_CMD_REGISTER_RECEIVER,
+ RPAL_CMD_UNREGISTER_RECEIVER,
RPAL_NR_CMD,
};
@@ -165,6 +218,14 @@ enum rpal_command_type {
_IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_GET_SERVICE_KEY, u64 *)
#define RPAL_IOCTL_GET_SERVICE_ID \
_IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_GET_SERVICE_ID, int *)
+#define RPAL_IOCTL_REGISTER_SENDER \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_REGISTER_SENDER, unsigned long)
+#define RPAL_IOCTL_UNREGISTER_SENDER \
+ _IO(RPAL_IOCTL_MAGIC, RPAL_CMD_UNREGISTER_SENDER)
+#define RPAL_IOCTL_REGISTER_RECEIVER \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_REGISTER_RECEIVER, unsigned long)
+#define RPAL_IOCTL_UNREGISTER_RECEIVER \
+ _IO(RPAL_IOCTL_MAGIC, RPAL_CMD_UNREGISTER_RECEIVER)
/**
* @brief get new reference to a rpal service, a corresponding
@@ -200,8 +261,26 @@ static inline struct rpal_service *rpal_current_service(void)
{
return current->rpal_rs;
}
+
+static inline void rpal_set_current_thread_flag(unsigned long bit)
+{
+ set_bit(bit, ¤t->rpal_flag);
+}
+
+static inline void rpal_clear_current_thread_flag(unsigned long bit)
+{
+ clear_bit(bit, ¤t->rpal_flag);
+}
+
+static inline bool rpal_test_current_thread_flag(unsigned long bit)
+{
+ return test_bit(bit, ¤t->rpal_flag);
+}
#else
static inline struct rpal_service *rpal_current_service(void) { return NULL; }
+static inline void rpal_set_current_thread_flag(unsigned long bit) { }
+static inline void rpal_clear_current_thread_flag(unsigned long bit) { }
+static inline bool rpal_test_current_thread_flag(unsigned long bit) { return false; }
#endif
void rpal_unregister_service(struct rpal_service *rs);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index ad35b197543c..5f25cc09fb71 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -72,6 +72,9 @@ struct rcu_node;
struct reclaim_state;
struct robust_list_head;
struct root_domain;
+struct rpal_common_data;
+struct rpal_receiver_data;
+struct rpal_sender_data;
struct rpal_service;
struct rq;
struct sched_attr;
@@ -1648,6 +1651,18 @@ struct task_struct {
#ifdef CONFIG_RPAL
struct rpal_service *rpal_rs;
+ unsigned long rpal_flag;
+ /*
+ * The first member of both rpal_sd and rpal_rd has a type
+ * of struct rpal_common_data. So if we do not care whether
+ * it is a struct rpal_sender_data or a struct rpal_receiver_data,
+ * use rpal_cd instead of rpal_sd or rpal_rd.
+ */
+ union {
+ struct rpal_common_data *rpal_cd;
+ struct rpal_sender_data *rpal_sd;
+ struct rpal_receiver_data *rpal_rd;
+ };
#endif
/* CPU-specific state of this task: */
diff --git a/init/init_task.c b/init/init_task.c
index 0c5b1927da41..2eb08b96e66b 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -222,6 +222,8 @@ struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
#endif
#ifdef CONFIG_RPAL
.rpal_rs = NULL,
+ .rpal_flag = 0,
+ .rpal_cd = NULL,
#endif
};
EXPORT_SYMBOL(init_task);
diff --git a/kernel/fork.c b/kernel/fork.c
index 1d1c8484a8f2..01cd48eadf68 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1220,6 +1220,8 @@ static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
#ifdef CONFIG_RPAL
tsk->rpal_rs = NULL;
+ tsk->rpal_flag = 0;
+ tsk->rpal_cd = NULL;
#endif
return tsk;
--
2.20.1
Return-Path: <linux-kernel+bounces-667871-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 718B041E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:33:06 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id A3C967B4E47
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:47 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 1CF6F220F30;
Fri, 30 May 2025 09:30:48 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="ZfFuStJw"
Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178])
(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 4F2A11F4E3B
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:45 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.178
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597447; cv=none; b=LCkgVKcbbLhx71/bWEWngmCBFkPxnT9eo5VMZfORRoJOnjeuJH/1Zmq/gk5DlaeSJ8EUeqzH2N1n3l2xI/ND9qTupjQxmhf80Yt3YwFC2msYCD13XbiPd1guDqA5gKAIS+rlkyOxa/itrqQe3mU43+elGiNfYC+zKpgJu7zs46c=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597447; c=relaxed/simple;
bh=cZEQ0MqKbOvC/as7YQeo0L+z+hUgvHRxc+aL7T32ukk=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=JkdSYPOnpb7myy5fd1uhk10dVQ0FKg7AfGtDm20sDN5+kgmOVKSA6m/UyoUMuO5JyS9T5ROKRlt7LVDUL5QZ62uRtdFwVrwDw3Ts+N4v7yx4sL5AZ2GNN9YqmKphlRwnKMwzAZgNT1wQh62V8d9o+lq/C0VuatpuMNWGvY2GcZs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=ZfFuStJw; arc=none smtp.client-ip=209.85.215.178
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pg1-f178.google.com with SMTP id 41be03b00d2f7-b26f7d2c1f1so1765290a12.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:30:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597444; x=1749202244; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=MCkN3xSvk7RNOqtTsnso8pu1jgTl1XSXrm3OEL9CcBU=;
b=ZfFuStJwx/BN5fNeH96ss/AySEuyezo8B0bfDe8tMKyDwgL098ciD8jt8L7GdT+AlT
ghBvvwMCIn8m3u2zk+iDtRMlyZ4g0Zcp9gInoNmbl6OGZ4vXHi4HMNUYrwiqlHbvhgXR
rOFyRJhGmYpfIytDCZKohBYk3yZnd3yBQ9/4MUiB6ISpvVQSxazUuD+bvWfR3ni8HGYJ
2WTZMlh4DZ8KVZ1OBH3QcQq7I7T58qKyfJaDApCuMtPfvBwndFZarGroYdhHLjBTioAi
ksl/sMIeWv6qiH/hLRFjub5+vtaw/gEWfNwOEBIDS+PBybSHccw4P2ANkboLgheKQw8R
nL+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597444; x=1749202244;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=MCkN3xSvk7RNOqtTsnso8pu1jgTl1XSXrm3OEL9CcBU=;
b=EAdTqpeYN/r8Z9Pk/s7dkUBZrGEdO8f29QTVPgXIHwGWR1T5cyzkrt2OBrR0LpCSf+
KcbjzoMCJk0C+rdp8ksBCFM646HW33IgRAggnzPSIIAU3fhpayX1sMMCnH3pfbUd8IGW
YkrKeZVOwcFbM9xKLnlE51mZDRvDr+jRr96+UFPVyOB3sFoaiuwogu1VWW66a4SVcBzX
1GGLRgVo1OotwZ6jYcWwcsTaHPIhdMNGPP5ql8F3IZPnyEcISkeltzOL8WVSgBKx+Lf5
bY1VUF56MaGmPgDq4fKqYOYG67ve+3FXT0E7cG/j1awepIu0bVxHoqDpdpb1PaI5FSbO
bH7w==
X-Forwarded-Encrypted: i=1; AJvYcCUHoxRPDRtc/JvvYVlzu5oT2udsNPmAlbEK9BG4KAd8huexcrKmgBQFYP4XjPweKPub7ZF9b8Mla3QOo4w=@vger.kernel.org
X-Gm-Message-State: AOJu0YxQbSHv61Ya/A/TYU4adPN+HEjd1k8h9Wp7CLStu3xRPbXfZ9B6
1RyDq2vyM1a6l52M3yhSd2qG/TsrOIEfQst0SHqmr09kCKPbEX21Kg4wS1yn9Q9KVLw=
X-Gm-Gg: ASbGnctPN0XtOS48t8yKBJmPUw4rgpKxStmsS4a70uC0GBt+8FU8L+yWhhe8jRkvs31
RyLFVYnovSTzWHLW1vkPwI08+Ifo+GK20MENTg+h/gsniDpEafBQBQWi/Uy6J9QNeXBAOLWi02a
GDQFmF0D5O2Lt8j3LGXq9CkyogE9uW6eO5BtoU8PBXUXtqYkmnQLJzAjdBZtvwFqog4S3XvqhXu
hzkR/3DmESVSO1ZIxbNVf0kBAC65fr/1InLvqQtPWocN2cOL9XPb+X76ixJDdfHFGIzhgiPDvib
C/pBdK7FtiPKI8sIXwmCraBePR9e/ngX4kWCMvTCT4o3Rf8i3WRQS4zZMyx691gFWtXd7ffbwAy
0H4LhQ3NerQ==
X-Google-Smtp-Source: AGHT+IGxnH4FN8v0lfXoJ+KLdg1DAlTGeu78x7GO8KMsAYvLDaxWhgMloZ/K96UmZpYHSFOIcwKPxQ==
X-Received: by 2002:a17:90b:2248:b0:311:ff18:b84b with SMTP id 98e67ed59e1d1-31250427cdamr2068655a91.25.1748597444187;
Fri, 30 May 2025 02:30:44 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.30.29
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:30:43 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 09/35] RPAL: enable address space sharing
Date: Fri, 30 May 2025 17:27:37 +0800
Message-Id: <2b5378f3686fd2831468e65c49609fbb19072b43.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
RPAL's memory sharing is implemented by copying p4d entries, which requires
implementing corresponding interfaces. Meanwhile, copying p4d entries can
cause the process's page table to contain p4d entries that do not belong to
it, and RPAL needs to resolve compatibility issues with other subsystems
caused by this.
This patch implements the rpal_map_service() interface to complete the
mutual copying of p4d entries between two RPAL services. For the copied p4d
entries, RPAL adds a _PAGE_RPAL_IGN flag to them. This flag makes
p4d_none() return true and p4d_present() return false, ensuring that these
p4d entries are invisible to other kernel subsystems. The protection of p4d
entries is guaranteed by the memory balloon, which ensures that the address
space corresponding to the p4d entries is not used by the current service.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/include/asm/pgtable.h | 25 ++++
arch/x86/include/asm/pgtable_types.h | 11 ++
arch/x86/rpal/internal.h | 2 +
arch/x86/rpal/mm.c | 175 +++++++++++++++++++++++++++
4 files changed, 213 insertions(+)
diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 5ddba366d3b4..54351bfe4e47 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -1137,12 +1137,37 @@ static inline int pud_bad(pud_t pud)
#if CONFIG_PGTABLE_LEVELS > 3
static inline int p4d_none(p4d_t p4d)
{
+#if IS_ENABLED(CONFIG_RPAL)
+ p4dval_t p4dv = native_p4d_val(p4d);
+
+ /*
+ * Since RPAL copy p4d entry to share address space,
+ * it is important that other process will not manipulate
+ * this copied p4d. Thus, make p4d_none() always return
+ * 0 to bypass kernel page table logic on copied p4d.
+ */
+ return (p4dv & _PAGE_RPAL_IGN) ||
+ ((p4dv & ~(_PAGE_KNL_ERRATUM_MASK)) == 0);
+#else
return (native_p4d_val(p4d) & ~(_PAGE_KNL_ERRATUM_MASK)) == 0;
+#endif
}
static inline int p4d_present(p4d_t p4d)
{
+#if IS_ENABLED(CONFIG_RPAL)
+ p4dval_t p4df = p4d_flags(p4d);
+
+ /*
+ * Since RPAL copy p4d entry to share address space,
+ * it is important that other process will not manipulate
+ * this copied p4d. Thus, make p4d_present() always return
+ * 0 to bypass kernel page table logic on copied p4d.
+ */
+ return ((p4df & (_PAGE_PRESENT | _PAGE_RPAL_IGN)) == _PAGE_PRESENT);
+#else
return p4d_flags(p4d) & _PAGE_PRESENT;
+#endif
}
static inline pud_t *p4d_pgtable(p4d_t p4d)
diff --git a/arch/x86/include/asm/pgtable_types.h b/arch/x86/include/asm/pgtable_types.h
index b74ec5c3643b..781b0f5bc359 100644
--- a/arch/x86/include/asm/pgtable_types.h
+++ b/arch/x86/include/asm/pgtable_types.h
@@ -35,6 +35,13 @@
#define _PAGE_BIT_SOFT_DIRTY _PAGE_BIT_SOFTW3 /* software dirty tracking */
#define _PAGE_BIT_KERNEL_4K _PAGE_BIT_SOFTW3 /* page must not be converted to large */
#define _PAGE_BIT_DEVMAP _PAGE_BIT_SOFTW4
+/*
+ * _PAGE_BIT_SOFTW1 is used by _PAGE_BIT_SPECIAL.
+ * but we are not conflicted with _PAGE_BIT_SPECIAL
+ * as we use it only on p4d/pud level and _PAGE_BIT_SPECIAL
+ * is only used on pte level.
+ */
+#define _PAGE_BIT_RPAL_IGN _PAGE_BIT_SOFTW1
#ifdef CONFIG_X86_64
#define _PAGE_BIT_SAVED_DIRTY _PAGE_BIT_SOFTW5 /* Saved Dirty bit (leaf) */
@@ -95,6 +102,10 @@
#define _PAGE_SOFT_DIRTY (_AT(pteval_t, 0))
#endif
+#if IS_ENABLED(CONFIG_RPAL)
+#define _PAGE_RPAL_IGN (_AT(pteval_t, 1) << _PAGE_BIT_RPAL_IGN)
+#endif
+
/*
* Tracking soft dirty bit when a page goes to a swap is tricky.
* We need a bit which can be stored in pte _and_ not conflict
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
index 3559c9c6e868..65f2cf4baf8f 100644
--- a/arch/x86/rpal/internal.h
+++ b/arch/x86/rpal/internal.h
@@ -34,6 +34,8 @@ static inline void rpal_put_shared_page(struct rpal_shared_page *rsp)
int rpal_mmap(struct file *filp, struct vm_area_struct *vma);
struct rpal_shared_page *rpal_find_shared_page(struct rpal_service *rs,
unsigned long addr);
+int rpal_map_service(struct rpal_service *tgt);
+void rpal_unmap_service(struct rpal_service *tgt);
/* thread.c */
int rpal_register_sender(unsigned long addr);
diff --git a/arch/x86/rpal/mm.c b/arch/x86/rpal/mm.c
index 8a738c502d1d..f1003baae001 100644
--- a/arch/x86/rpal/mm.c
+++ b/arch/x86/rpal/mm.c
@@ -215,3 +215,178 @@ void rpal_exit_mmap(struct mm_struct *mm)
rpal_put_service(rs);
}
}
+
+/*
+ * Since the user address space size of rpal process is 512G, which
+ * is the size of one p4d, we assume p4d entry will never change after
+ * rpal process is created.
+ */
+static int mm_link_p4d(struct mm_struct *dst_mm, p4d_t src_p4d,
+ unsigned long addr)
+{
+ spinlock_t *dst_ptl = &dst_mm->page_table_lock;
+ unsigned long flags;
+ pgd_t *dst_pgdp;
+ p4d_t p4d, *dst_p4dp;
+ p4dval_t p4dv;
+ int ret = 0;
+
+ BUILD_BUG_ON(CONFIG_PGTABLE_LEVELS < 4);
+
+ mmap_write_lock(dst_mm);
+ spin_lock_irqsave(dst_ptl, flags);
+ dst_pgdp = pgd_offset(dst_mm, addr);
+ /*
+ * dst_pgd must exists, otherwise we need to alloc pgd entry. When
+ * src_p4d is freed, we also need to free the pgd entry. This should
+ * be supported in the future.
+ */
+ if (unlikely(pgd_none_or_clear_bad(dst_pgdp))) {
+ rpal_err("cannot find pgd entry for addr 0x%016lx\n", addr);
+ ret = -EINVAL;
+ goto unlock;
+ }
+
+ dst_p4dp = p4d_offset(dst_pgdp, addr);
+ if (unlikely(!p4d_none_or_clear_bad(dst_p4dp))) {
+ rpal_err("p4d is previously mapped\n");
+ ret = -EINVAL;
+ goto unlock;
+ }
+
+ p4dv = p4d_val(src_p4d);
+
+ /*
+ * Since RPAL copy p4d entry to share address space,
+ * it is important that other process will not manipulate
+ * this copied p4d. We need mark the copied p4d and make
+ * p4d_present() and p4d_none() ignore such p4d.
+ */
+ p4dv |= _PAGE_RPAL_IGN;
+
+ if (boot_cpu_has(X86_FEATURE_PTI))
+ p4d = native_make_p4d((~_PAGE_NX) & p4dv);
+ else
+ p4d = native_make_p4d(p4dv);
+
+ set_p4d(dst_p4dp, p4d);
+ spin_unlock_irqrestore(dst_ptl, flags);
+ mmap_write_unlock(dst_mm);
+
+ return 0;
+unlock:
+ spin_unlock_irqrestore(dst_ptl, flags);
+ mmap_write_unlock(dst_mm);
+ return ret;
+}
+
+static void mm_unlink_p4d(struct mm_struct *mm, unsigned long addr)
+{
+ spinlock_t *ptl = &mm->page_table_lock;
+ unsigned long flags;
+ pgd_t *pgdp;
+ p4d_t *p4dp;
+
+ mmap_write_lock(mm);
+ spin_lock_irqsave(ptl, flags);
+ pgdp = pgd_offset(mm, addr);
+ p4dp = p4d_offset(pgdp, addr);
+ p4d_clear(p4dp);
+ spin_unlock_irqrestore(ptl, flags);
+ mmap_write_unlock(mm);
+
+ flush_tlb_mm(mm);
+}
+
+static int get_mm_p4d(struct mm_struct *mm, unsigned long addr, p4d_t *srcp)
+{
+ spinlock_t *ptl;
+ unsigned long flags;
+ pgd_t *pgdp;
+ p4d_t *p4dp;
+ int ret = 0;
+
+ ptl = &mm->page_table_lock;
+ spin_lock_irqsave(ptl, flags);
+ pgdp = pgd_offset(mm, addr);
+ if (pgd_none(*pgdp)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ p4dp = p4d_offset(pgdp, addr);
+ if (p4d_none(*p4dp) || p4d_bad(*p4dp)) {
+ ret = -EINVAL;
+ goto out;
+ }
+ *srcp = *p4dp;
+
+out:
+ spin_unlock_irqrestore(ptl, flags);
+
+ return ret;
+}
+
+int rpal_map_service(struct rpal_service *tgt)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct mm_struct *cur_mm, *tgt_mm;
+ unsigned long cur_addr, tgt_addr;
+ p4d_t cur_p4d, tgt_p4d;
+ int ret = 0;
+
+ cur_mm = current->mm;
+ tgt_mm = tgt->mm;
+ if (!mmget_not_zero(tgt_mm)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ cur_addr = rpal_get_base(cur);
+ tgt_addr = rpal_get_base(tgt);
+
+ ret = get_mm_p4d(tgt_mm, tgt_addr, &tgt_p4d);
+ if (ret)
+ goto put_tgt;
+
+ ret = get_mm_p4d(cur_mm, cur_addr, &cur_p4d);
+ if (ret)
+ goto put_tgt;
+
+ ret = mm_link_p4d(cur_mm, tgt_p4d, tgt_addr);
+ if (ret)
+ goto put_tgt;
+
+ ret = mm_link_p4d(tgt_mm, cur_p4d, cur_addr);
+ if (ret) {
+ mm_unlink_p4d(cur_mm, tgt_addr);
+ goto put_tgt;
+ }
+
+put_tgt:
+ mmput(tgt_mm);
+out:
+ return ret;
+}
+
+void rpal_unmap_service(struct rpal_service *tgt)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct mm_struct *cur_mm, *tgt_mm;
+ unsigned long cur_addr, tgt_addr;
+
+ cur_mm = current->mm;
+ tgt_mm = tgt->mm;
+
+ cur_addr = rpal_get_base(cur);
+ tgt_addr = rpal_get_base(tgt);
+
+ if (mmget_not_zero(tgt_mm)) {
+ mm_unlink_p4d(tgt_mm, cur_addr);
+ mmput(tgt_mm);
+ } else {
+ /* If tgt has exited, then we get a NULL tgt_mm */
+ pr_debug("rpal: [%d] cannot find target mm\n", current->pid);
+ }
+ mm_unlink_p4d(cur_mm, tgt->base);
+}
--
2.20.1
Return-Path: <linux-kernel+bounces-667869-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id A861541E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:33:24 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id BE3F71885CA7
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:32:44 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 22893223DC4;
Fri, 30 May 2025 09:30:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="YmPlmkBx"
Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176])
(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 6ABB9224AFE
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:30:14 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.176
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597416; cv=none; b=HuyhCgYmYBqTIw8MfeuLJJTYLJiYgxomcal5lQckgywWHjeKMUGrPvUd6iWJ5vfQki217kZ5r8RNIu/IQjgXVg7FycBjJ0O3vWhP+mxb6CwnnaGVkdmj+5O9SwI/0GSgW0pkPXr0jIcDvIEnI0dhCA/4JbABoewovSLR1RIYlDs=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597416; c=relaxed/simple;
bh=422OX9nkZoEDUi615uXpiGE4CKGrzo9OxUzw3vP+lYs=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=Ltk6sz9rq45cTXaWbk8xoB0+gc/+J0pdc2533eDIe9RbTqEnPqU4onp87RlB+mzP7TMD0WpQYh2v29bqprCCU1xYTLNnLNkw1tsZJol+A+TZgaJMHySxekalLcMqY/chnLb7XOEP+VOVK2yk2N0Tvk+nWxRDdQKiuOaONsfdfiI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=YmPlmkBx; arc=none smtp.client-ip=209.85.210.176
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pf1-f176.google.com with SMTP id d2e1a72fcca58-742c3d06de3so2055688b3a.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597413; x=1749202213; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=flixYT7qZa2BQQysi97LfHe75SLaTmZqxePIcANrNj8=;
b=YmPlmkBx4f/H8kQ0ZSI35VDZkWg/orrROUWKIlf7Aycmim9cqmVwVuIduIQTOwcP4f
TCSZbKbCGTlElnr3Q/Dm+6xt9JaMCPiYZA6C21WTQl2Dy2CKCzE/YbSd86UgSmHjeQal
1hmkOFVD0plnR4eqIjjgLoB66bknFnLXnLS6hnVrDb+sJH56gW7c8rBEwT9QPMkbfS2t
NPyolzsP/U82hAIXrgEwlYno8BQ4P0VrUpWjMoB9Ea2csF+sI6je3SSkxBtf/5UCTJcB
olpZZNTnwtpXc+laNjtJTjf3bh1vLLT8VzBzf6miP71a8RqHxVokecWnL4etjfNR1y0S
yb4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597413; x=1749202213;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=flixYT7qZa2BQQysi97LfHe75SLaTmZqxePIcANrNj8=;
b=lA0ZOwSX4NPXMC/jhbrvt7RrMBlCsMP0sHh9WFduGcTx8CSLnKZliVl+y+7deh7Lxl
a8+1F8AlV4be1fRC7LUzBsHtSaGaXlo4XjmVAr2MADoYsblvoKTOTHI7dWBTG67oHalg
NnyxI/19s7dNwWNquFU6IuEDDe3CmNMuhTit68Q/K4Kxm+XtyL9KUWxuIzgUIXoO/8dm
Wr3veeUvXhB7yyF8SMO0aebkRhO2ml07JMiwx3e1V8rpFGubwpQ6yU0VaERtIOKwI9o8
9MJXPSVK2+yLzhgdmOivi2uLtuMKWmUpRJ9FUbKk+BTnn/45EcyG1pQC+PjvEanqryJJ
tQaA==
X-Forwarded-Encrypted: i=1; AJvYcCWzkRFAyZVGpEivzXhoR8eqRS6QMCTIi6tw+jtvyPgJC7p2a/G27b5PF5rTJ4z3gfK9c8yye1rRI1J35MI=@vger.kernel.org
X-Gm-Message-State: AOJu0Yz3C3HCbyI4K81zBpqkGJOURWgn9kzZMxsKoUOt6SQg1DBsPOme
X2kEacSGp/5C0Zqn0Uz6aAQAmPtOylf0EPz+FieUrEFjIPtQxsoQJL9npy3PmA4jP/w=
X-Gm-Gg: ASbGncu58AAPlcRd2u829YMLianqjUzxsAmDrFaO29N1F3ybi5RfsB87IOcwWRFYorE
Vq+/9LzzN+BjRndlAKaCX1A+p528Z45pAs+dqj2yI4CemIuPIv5MfYOe27839u6RQSIX2iLK/Gj
RoI/kFbIwMQ4EwWWV79/9RgLdi2DS4no8/YR4WQBFkz9lpDYhPCkeuJ9zVW22TQCKOLNiPq8SKi
BX4apHQAhjhcvZrrYSRJ0RxiVxLo85Xl7lvO33ontcnmVsbhvIJoNeS6AUnJNOa4Fbamzmoz1Vz
Iku06x2Ycn72DQnD8YHPaNQP/MWwSGf8L1V7oqV+Toew8LgPSRwL9NKlSjYM7cetzAXyYY3/GHY
Fi+x65FqoVFNFp0ZNHvP0
X-Google-Smtp-Source: AGHT+IHA2yGD8wMUj4lSxB67R095/h8/6O6yJ7zAmlSwm5/Pic/viWYeW3kwOjE2By4p9s+RPQhz5w==
X-Received: by 2002:a17:90b:1d50:b0:311:fde5:c4b6 with SMTP id 98e67ed59e1d1-31250344995mr2204788a91.6.1748597413513;
Fri, 30 May 2025 02:30:13 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.29.58
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:30:13 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 07/35] RPAL: enable shared page mmap
Date: Fri, 30 May 2025 17:27:35 +0800
Message-Id: <11d4a94318efc8af41f77235f5117aabb8795afe.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
RPAL needs to create shared memory between the kernel and user space for
the transfer of states and data.
This patch implements the rpal_mmap() interface. User processes can create
shared memory by calling mmap() on /proc/rpal. To prevent users from
creating excessive memory, rpal_mmap() limits the total size of the shared
memory that can be created. The shared memory is maintained through
reference counting, and rpal_munmap() is implemented for the release of
the shared memory.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/internal.h | 20 ++++++
arch/x86/rpal/mm.c | 147 +++++++++++++++++++++++++++++++++++++++
arch/x86/rpal/proc.c | 1 +
arch/x86/rpal/service.c | 4 ++
include/linux/rpal.h | 15 ++++
mm/mmap.c | 4 ++
6 files changed, 191 insertions(+)
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
index c102a4c50515..65fd14a26f0e 100644
--- a/arch/x86/rpal/internal.h
+++ b/arch/x86/rpal/internal.h
@@ -9,8 +9,28 @@
#define RPAL_COMPAT_VERSION 1
#define RPAL_API_VERSION 1
+#include <linux/mm.h>
+#include <linux/file.h>
+
extern bool rpal_inited;
/* service.c */
int __init rpal_service_init(void);
void __init rpal_service_exit(void);
+
+/* mm.c */
+static inline struct rpal_shared_page *
+rpal_get_shared_page(struct rpal_shared_page *rsp)
+{
+ atomic_inc(&rsp->refcnt);
+ return rsp;
+}
+
+static inline void rpal_put_shared_page(struct rpal_shared_page *rsp)
+{
+ atomic_dec(&rsp->refcnt);
+}
+
+int rpal_mmap(struct file *filp, struct vm_area_struct *vma);
+struct rpal_shared_page *rpal_find_shared_page(struct rpal_service *rs,
+ unsigned long addr);
diff --git a/arch/x86/rpal/mm.c b/arch/x86/rpal/mm.c
index f469bcf57b66..8a738c502d1d 100644
--- a/arch/x86/rpal/mm.c
+++ b/arch/x86/rpal/mm.c
@@ -11,6 +11,8 @@
#include <linux/mman.h>
#include <linux/mm.h>
+#include "internal.h"
+
static inline int rpal_balloon_mapping(unsigned long base, unsigned long size)
{
struct vm_area_struct *vma;
@@ -68,3 +70,148 @@ int rpal_balloon_init(unsigned long base)
return ret;
}
+
+static void rpal_munmap(struct vm_area_struct *area)
+{
+ struct mm_struct *mm = area->vm_mm;
+ struct rpal_service *rs = mm->rpal_rs;
+ struct rpal_shared_page *rsp = area->vm_private_data;
+
+ if (!rs) {
+ rpal_err(
+ "free shared page after exit_mmap or fork a child process\n");
+ return;
+ }
+
+ mutex_lock(&rs->mutex);
+ if (unlikely(!atomic_dec_and_test(&rsp->refcnt))) {
+ rpal_err("refcnt(%d) of shared page is not 0\n", atomic_read(&rsp->refcnt));
+ send_sig_info(SIGKILL, SEND_SIG_PRIV, rs->group_leader);
+ }
+
+ list_del(&rsp->list);
+ rs->nr_shared_pages -= rsp->npage;
+ __free_pages(virt_to_page(rsp->kernel_start), get_order(rsp->npage));
+ kfree(rsp);
+ mutex_unlock(&rs->mutex);
+}
+
+const struct vm_operations_struct rpal_vm_ops = { .close = rpal_munmap };
+
+#define RPAL_MAX_SHARED_PAGES 8192
+
+int rpal_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_shared_page *rsp;
+ struct page *page = NULL;
+ unsigned long size = (unsigned long)(vma->vm_end - vma->vm_start);
+ int npage;
+ int order = -1;
+ int ret = 0;
+
+ if (!cur) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ /*
+ * Check whether the vma is aligned and whether the page number
+ * is power of 2. This makes shared pages easy to manage.
+ */
+ if (!IS_ALIGNED(size, PAGE_SIZE) ||
+ !IS_ALIGNED(vma->vm_start, PAGE_SIZE)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ npage = size >> PAGE_SHIFT;
+ if (!is_power_of_2(npage)) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ order = get_order(size);
+
+ mutex_lock(&cur->mutex);
+
+ /* make sure user does not alloc too much pages */
+ if (cur->nr_shared_pages + npage > RPAL_MAX_SHARED_PAGES) {
+ ret = -ENOMEM;
+ goto unlock;
+ }
+
+ rsp = kmalloc(sizeof(*rsp), GFP_KERNEL);
+ if (!rsp) {
+ ret = -EAGAIN;
+ goto unlock;
+ }
+
+ page = alloc_pages(GFP_KERNEL | __GFP_ZERO, order);
+ if (!page) {
+ ret = -ENOMEM;
+ goto free_rsp;
+ }
+
+ rsp->user_start = vma->vm_start;
+ rsp->kernel_start = (unsigned long)page_address(page);
+ rsp->npage = npage;
+ atomic_set(&rsp->refcnt, 1);
+ INIT_LIST_HEAD(&rsp->list);
+ list_add(&rsp->list, &cur->shared_pages);
+
+ vma->vm_ops = &rpal_vm_ops;
+ vma->vm_private_data = rsp;
+
+ /* map to shared pages userspace */
+ ret = remap_pfn_range(vma, vma->vm_start, page_to_pfn(page), size,
+ vma->vm_page_prot);
+ if (ret)
+ goto free_page;
+
+ cur->nr_shared_pages += npage;
+ mutex_unlock(&cur->mutex);
+
+ return 0;
+
+free_page:
+ __free_pages(page, order);
+ list_del(&rsp->list);
+free_rsp:
+ kfree(rsp);
+unlock:
+ mutex_unlock(&cur->mutex);
+out:
+ return ret;
+}
+
+struct rpal_shared_page *rpal_find_shared_page(struct rpal_service *rs,
+ unsigned long addr)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_shared_page *rsp, *ret = NULL;
+
+ mutex_lock(&cur->mutex);
+ list_for_each_entry(rsp, &rs->shared_pages, list) {
+ if (rsp->user_start <= addr &&
+ addr < rsp->user_start + rsp->npage * PAGE_SIZE) {
+ ret = rpal_get_shared_page(rsp);
+ break;
+ }
+ }
+ mutex_unlock(&cur->mutex);
+
+ return ret;
+}
+
+void rpal_exit_mmap(struct mm_struct *mm)
+{
+ struct rpal_service *rs = mm->rpal_rs;
+
+ if (rs) {
+ mm->rpal_rs = NULL;
+ /* all shared pages should be freed at this time */
+ WARN_ON_ONCE(rs->nr_shared_pages != 0);
+ rpal_put_service(rs);
+ }
+}
diff --git a/arch/x86/rpal/proc.c b/arch/x86/rpal/proc.c
index 1ced30e25c15..86947dc233d0 100644
--- a/arch/x86/rpal/proc.c
+++ b/arch/x86/rpal/proc.c
@@ -61,6 +61,7 @@ static long rpal_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
const struct proc_ops proc_rpal_operations = {
.proc_open = rpal_open,
.proc_ioctl = rpal_ioctl,
+ .proc_mmap = rpal_mmap,
};
static int __init proc_rpal_init(void)
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index caa4afa5a2c6..f29a046fc22f 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -173,6 +173,10 @@ struct rpal_service *rpal_register_service(void)
if (unlikely(rs->key == RPAL_INVALID_KEY))
goto key_fail;
+ mutex_init(&rs->mutex);
+ rs->nr_shared_pages = 0;
+ INIT_LIST_HEAD(&rs->shared_pages);
+
rs->bad_service = false;
rs->base = calculate_base_address(rs->id);
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 3bc2a2a44265..986dfbd16fc9 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -110,6 +110,12 @@ struct rpal_service {
* Fields above should never change after initialization.
* Fields below may change after initialization.
*/
+ /* Mutex for time consuming operations */
+ struct mutex mutex;
+
+ /* pinned pages */
+ int nr_shared_pages;
+ struct list_head shared_pages;
/* delayed service put work */
struct delayed_work delayed_put_work;
@@ -135,6 +141,14 @@ struct rpal_version_info {
/* End */
+struct rpal_shared_page {
+ unsigned long user_start;
+ unsigned long kernel_start;
+ int npage;
+ atomic_t refcnt;
+ struct list_head list;
+};
+
enum rpal_command_type {
RPAL_CMD_GET_API_VERSION_AND_CAP,
RPAL_CMD_GET_SERVICE_KEY,
@@ -196,6 +210,7 @@ struct rpal_service *rpal_get_service_by_key(u64 key);
void copy_rpal(struct task_struct *p);
void exit_rpal(bool group_dead);
int rpal_balloon_init(unsigned long base);
+void rpal_exit_mmap(struct mm_struct *mm);
extern void rpal_pick_mmap_base(struct mm_struct *mm,
struct rlimit *rlim_stack);
diff --git a/mm/mmap.c b/mm/mmap.c
index bd210aaf7ebd..98bb33d2091e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -48,6 +48,7 @@
#include <linux/sched/mm.h>
#include <linux/ksm.h>
#include <linux/memfd.h>
+#include <linux/rpal.h>
#include <linux/uaccess.h>
#include <asm/cacheflush.h>
@@ -1319,6 +1320,9 @@ void exit_mmap(struct mm_struct *mm)
__mt_destroy(&mm->mm_mt);
mmap_write_unlock(mm);
vm_unacct_memory(nr_accounted);
+#if IS_ENABLED(CONFIG_RPAL)
+ rpal_exit_mmap(mm);
+#endif
}
/* Insert vm structure into process list sorted by address
--
2.20.1
Return-Path: <linux-kernel+bounces-667873-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id C687341E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:33:37 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 955737B52EC
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:32:19 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id C87EE22B5A8;
Fri, 30 May 2025 09:31:15 +0000 (UTC)
Received: from mailgw.kylinos.cn (mailgw.kylinos.cn [124.126.103.232])
(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 66E23221560;
Fri, 30 May 2025 09:31:10 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=124.126.103.232
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597475; cv=none; b=XDQsH0+YHY5XjVaTgW1RXTiRtlDQ/lp88FXy4/cj7GBakfV6qVUY2cKke9J9lZ2jjdpFZv55ByhPv8cTeziefySjasfOZXZKIhjru0aIZ4rpFGehtisopqnpXMlQp9s0H1c1alTedwqiyPewprK8rgH/9aKuIj06/sty1GfygjU=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597475; c=relaxed/simple;
bh=aggFkJ8dzIspA0Ee5ZCSXr4Q9BtosF9ZAdFKHZ23WJo=;
h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
In-Reply-To:Content-Type; b=Z6FuM1baEJfcQGThZwWYaN+tXugFSQ43L79TFAHQKqmMcJO3zBO4hcsOV1PreEBWZPOoKjgp/ikJgmnHs04zx/bTKn1i1toDcQIVcX36h4aAZVp5otRMe4K6ck3XLd8y/IODVygwXlFdCqId1AnSDQtpXJumA+v4tUm77xuySus=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn; spf=pass smtp.mailfrom=kylinos.cn; arc=none smtp.client-ip=124.126.103.232
Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kylinos.cn
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kylinos.cn
X-UUID: ce23f0383d3811f0b29709d653e92f7d-20250530
X-CID-P-RULE: Release_Ham
X-CID-O-INFO: VERSION:1.1.45,REQID:9901f846-04db-40fa-9f89-284431738858,IP:10,
URL:0,TC:0,Content:0,EDM:0,RT:0,SF:-9,FILE:0,BULK:30,RULE:Release_Ham,ACTI
ON:release,TS:31
X-CID-INFO: VERSION:1.1.45,REQID:9901f846-04db-40fa-9f89-284431738858,IP:10,UR
L:0,TC:0,Content:0,EDM:0,RT:0,SF:-9,FILE:0,BULK:30,RULE:Release_Ham,ACTION
:release,TS:31
X-CID-META: VersionHash:6493067,CLOUDID:9a3853ec8758490979c83e53ed79c393,BulkI
D:250522180435BN613KC0,BulkQuantity:9,Recheck:0,SF:17|19|24|38|45|64|66|78
|80|81|82|83|102|841,TC:nil,Content:0|50,EDM:-3,IP:-2,URL:0,File:nil,RT:ni
l,Bulk:40|23,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0,LES:1,SPR:NO,DKR:0,DKP:
0,BRR:0,BRE:0,ARC:0
X-CID-BVR: 0
X-CID-BAS: 0,_,0,_
X-CID-FACTOR: TF_CID_SPAM_FAS,TF_CID_SPAM_FSD,TF_CID_SPAM_FSI,TF_CID_SPAM_SNR
X-UUID: ce23f0383d3811f0b29709d653e92f7d-20250530
X-User: aichao@xxxxxxxxxx
Received: from [172.25.120.86] [(112.64.161.44)] by mailgw.kylinos.cn
(envelope-from <aichao@xxxxxxxxxx>)
(Generic MTA with TLSv1.3 TLS_AES_128_GCM_SHA256 128/128)
with ESMTP id 1724392610; Fri, 30 May 2025 17:31:03 +0800
Message-ID: <22dfeb0b-c3ff-4a7a-8471-1bb89dccdc17@xxxxxxxxxx>
Date: Fri, 30 May 2025 17:30:58 +0800
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 2/6] ASoC: aoa: Use helper function
for_each_child_of_node_scoped()
To: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>, perex <perex@xxxxxxxx>,
tiwai <tiwai@xxxxxxxx>,
"kuninori.morimoto.gx" <kuninori.morimoto.gx@xxxxxxxxxxx>,
lgirdwood <lgirdwood@xxxxxxxxx>, broonie <broonie@xxxxxxxxxx>,
jbrunet <jbrunet@xxxxxxxxxxxx>, "neil.armstrong"
<neil.armstrong@xxxxxxxxxx>, khilman <khilman@xxxxxxxxxxxx>,
"martin.blumenstingl" <martin.blumenstingl@xxxxxxxxxxxxxx>,
"shengjiu.wang" <shengjiu.wang@xxxxxxxxx>, "Xiubo.Lee"
<Xiubo.Lee@xxxxxxxxx>, festevam <festevam@xxxxxxxxx>,
nicoleotsuka <nicoleotsuka@xxxxxxxxx>, shawnguo <shawnguo@xxxxxxxxxx>,
"s.hauer" <s.hauer@xxxxxxxxxxxxxx>,
"srinivas.kandagatla" <srinivas.kandagatla@xxxxxxxxxx>
Cc: linux-sound <linux-sound@xxxxxxxxxxxxxxx>,
linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>,
linuxppc-dev <linuxppc-dev@xxxxxxxxxxxxxxxx>,
linux-renesas-soc <linux-renesas-soc@xxxxxxxxxxxxxxx>,
linux-arm-kernel <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>,
linux-amlogic <linux-amlogic@xxxxxxxxxxxxxxxxxxx>, imx
<imx@xxxxxxxxxxxxxxx>, kernel <kernel@xxxxxxxxxxxxxx>,
linux-arm-msm <linux-arm-msm@xxxxxxxxxxxxxxx>
References: <2aq0nyvyf7t-2aq4hsc7kp6@nsmail7.0.0--kylin--1>
<7e708dcc98c6f0f615b1b87d190464cfe78be668.camel@xxxxxxxxxxxxxxxx>
<eb1ddeb3-06b6-4ac5-b20a-06b92c7f1363@xxxxxxxxxx>
<23aadbd78d3585c900c579c26f360011cf1ca830.camel@xxxxxxxxxxxxxxxx>
<9ec008a8-b569-4ad1-9206-fe241fb1712d@xxxxxxxxxx>
<b36908bf35a20f7196bec4fe22e392a015d9b7d1.camel@xxxxxxxxxxxxxxxx>
Content-Language: en-US
From: Ai Chao <aichao@xxxxxxxxxx>
In-Reply-To: <b36908bf35a20f7196bec4fe22e392a015d9b7d1.camel@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hi Johannes:
   Thanks for your feedback. I will drop it.
> On Mon, 2025-05-26 at 16:20 +0800, Ai Chao wrote:
>> Hi Johannes:
>>>> for_each_child_of_node.
>>> You still haven't explained why it's even correct.
>>>
>>> johannes
>> The for_each_child_of_node() function is used to iterate over all child
>> nodes of a device tree node.
>> During each iteration, it retrieves a pointer to the child node via
>> of_get_next_child() and automatically increments the node's reference
>> count (of_node_get()).
>> Each call to of_get_next_child() increases the reference count
>> (refcount) of the returned child node, ensuring that the node is not
>> freed while in use.
>> for_each_child_of_node() increments the child node's reference count in
>> each iteration but does not decrement it automatically.
>> If of_node_put() is not called manually, the reference count will never
>> reach zero, resulting in a memory leak of the node.
> Yes, good! Now show that you can apply what you've learned to the
> specific code (and changes) at hand.
>
> johannes
--
Best regards,
Ai Chao
Return-Path: <linux-kernel+bounces-667874-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9A42F41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:33:52 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 7A3E3167596
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:33:51 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 5BC92221D9C;
Fri, 30 May 2025 09:31:19 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="Y/Wa05cw"
Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49])
(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 5E9A522B5AA
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:16 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597478; cv=none; b=tSMjodNPwG4U0g9Rd+9L6HqrM4oBIVn02KShTJtB+ry4sEsb2AReuJgN71dDotTzN0VKpyVfkX4iNlgq9QZDlcsRaVW1sKtP5zY91EOkSECslR7/AECA4FnN6hDVcYZb+aLHfSyUyCyVvP2BZ+LmMsT7LHcHiJXZJ5B/hQYZ29U=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597478; c=relaxed/simple;
bh=Tz+y1/2E7hEgjo92We1jW9pwmbJC4Y8VL7rWkTlATqs=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=shgINVY3iMedLC74iitX6mDPuWVZjgII6eIaVdt+Y2P5Kz34e2wvg46qd4gJs7Ba5QXnvhYFccXoQ1qhP2Z4fq3fXNTCm3FEJl/uuT71BhsNF7VfbHo7bOr/S9f8jmxqZkbAtr9zooH52YgjAsd689T6m5zRB+ypW8hgK8tRdEI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=Y/Wa05cw; arc=none smtp.client-ip=209.85.216.49
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-3081fe5987eso1482476a91.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:31:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597475; x=1749202275; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=FwsjAroG47yqr2xPwlaPw9IAGrmPcW3kvk56UsePHN4=;
b=Y/Wa05cw69+qKOFH87dOlfhVUtl62vYn8/tYhSU5dPdLb2jAyiYYipf7pUeoh72E9R
hOjVYM6Ie5QxLl1tI8mDVg7WdN7Bm2P3p95hJZY5pFaWc4PYF4CuWwrpqYIvugN52alF
1DlurKWNoIsr2aOV9KB5opggiRtyFbnUK6Y4XPaJ4bXM7664cf3fQ1ss7473NqnM8oZV
li7rFoRIUyHitkUD1AlHf2yN91eISE+ay4aaOGv6YBVYS87IADfLjGuYvYX5uEbWzEbU
3jKTvGou6BBXutBH2P/mXnVK5fD5qElszqHRBBBxrzgmtbSX85YIzUgI+ckYXgu3o8Ic
dsLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597475; x=1749202275;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=FwsjAroG47yqr2xPwlaPw9IAGrmPcW3kvk56UsePHN4=;
b=SztOFuS2NlYXq8gvxQkxfP0NJ0tHIZiP9KmmKenI1HArCjWpOERzDpbE6s5dj4XIoV
v+HVZt6/XPomMGMOFsOwy7p1l3YvvmPJOGK5P7E/NQW87a8koGGfhwA3DvZKJZwAfwJ3
UWLJcc5wT0toijwPqHh1mlEB5kDIUAg8E9z0linZJKYNO1qM2YPaqvw9XfLK68wJaQ8E
dzRw2OCH6xsXue7yO37CwShFcqnQXE3n/oEUDZNE4uvv5BMsys3Y5JZtpUTHYGkvT9Ar
tK4o57hmaIqNjUHjeDM4d3ArmrJ2o1uhmUldq3+DmvW4YHTIYhal5dk6oqCjfDhjsdFK
QGmA==
X-Forwarded-Encrypted: i=1; AJvYcCXzwScqmplshHB5lmS/KG1JanJTTZrw4x0uvGQsv802ehwIQQ0DPVsIvN3FdVoWQTb3GBq2LGQM7kr6XVU=@vger.kernel.org
X-Gm-Message-State: AOJu0YyQOtm2db3SjR4njEj72QmNazXpNLNVAmbkITazkTZAuntKyUKx
8VTffD3PiI154Cytdb0hVCVOXawQBa6KIMnBPJ9SgAxJMKTind7w/jTXOcaNHyHf6OA=
X-Gm-Gg: ASbGncs/MA+LvH4BY4hevxYRRQK15oLv+qSHFLVcnvHcj36dYSV/sIgr+6Vumdod5ES
K2sHTOFnyD53Ava236qrH798siK6vYLaCwH01jCno9Z0SwBk9h7XIGRdxIHN1idZY+VVt7CcxDt
7fBS232MM6E/QXwYOrb4g/2th2MEYY8QgfA98R/DWD72jJS8MKFTte/7jaqvtvvtnFHW/xACFq8
K+nAjeX5hOrLEgIuUSxvRPNq6mt4VTo/hiQEi6MVoUOu0AESu7pUrU2FRx4fzJMhdbEbzC/eiDO
yPpex26motLfXTpIFJZ2ZnOVJU7p7cQVSfMCArD1lZdsn5RzWHvX0d+0op8EmdcJ4/YhDg6K3qu
1GIzFQAxc4nfwHg6w4dy5
X-Google-Smtp-Source: AGHT+IHRc0pSTHqnWWemzLU4cZ03FJzQxrkM5nsu9yl2b6TGMlL/6vitJMQ7NNciKXpMzxjmPBfgdQ==
X-Received: by 2002:a17:90a:d448:b0:312:29e:9ed8 with SMTP id 98e67ed59e1d1-31250413834mr2149974a91.20.1748597475019;
Fri, 30 May 2025 02:31:15 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.31.00
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:31:14 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 11/35] RPAL: add service request/release
Date: Fri, 30 May 2025 17:27:39 +0800
Message-Id: <d3e954630da8219029d5aba22fc27acc1e234fdb.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Services communicating via RPAL require a series of operations to perform
RPAL calls, such as mapping each other's memory and obtaining each other's
metadata.
This patch adds the rpal_request_service() and rpal_release_service()
interfaces. Before communication, services must first complete a handshake
process by mutually requesting each other. Only after both parties have
completed their requests will RPAL copy each other's p4d entries into the
other party's page tables, thereby achieving address space sharing. The
patch defines RPAL_REQUEST_MAP and RPAL_REVERSE_MAP to indicate whether a
service has requested another service or has been requested by another
service.
rpal_release_service() can release previously requested services, which
triggers the removal of mutual p4d entries and terminates address space
sharing. When a service exits the enabled state, the kernel will release
all services it has ever requested, thereby terminating all address space
sharing involving this service.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/internal.h | 5 +
arch/x86/rpal/proc.c | 6 +
arch/x86/rpal/service.c | 265 ++++++++++++++++++++++++++++++++++++++-
include/linux/rpal.h | 42 +++++++
4 files changed, 316 insertions(+), 2 deletions(-)
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
index 769d3bbe5a6b..c504b6efff64 100644
--- a/arch/x86/rpal/internal.h
+++ b/arch/x86/rpal/internal.h
@@ -12,6 +12,9 @@
#include <linux/mm.h>
#include <linux/file.h>
+#define RPAL_REQUEST_MAP 0x1
+#define RPAL_REVERSE_MAP 0x2
+
extern bool rpal_inited;
/* service.c */
@@ -19,6 +22,8 @@ int __init rpal_service_init(void);
void __init rpal_service_exit(void);
int rpal_enable_service(unsigned long arg);
int rpal_disable_service(void);
+int rpal_request_service(unsigned long arg);
+int rpal_release_service(u64 key);
/* mm.c */
static inline struct rpal_shared_page *
diff --git a/arch/x86/rpal/proc.c b/arch/x86/rpal/proc.c
index acd814f31649..f001afd40562 100644
--- a/arch/x86/rpal/proc.c
+++ b/arch/x86/rpal/proc.c
@@ -69,6 +69,12 @@ static long rpal_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
case RPAL_IOCTL_DISABLE_SERVICE:
ret = rpal_disable_service();
break;
+ case RPAL_IOCTL_REQUEST_SERVICE:
+ ret = rpal_request_service(arg);
+ break;
+ case RPAL_IOCTL_RELEASE_SERVICE:
+ ret = rpal_release_service(arg);
+ break;
default:
return -EINVAL;
}
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index 8a7b679bc28b..16a2155873a1 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -178,6 +178,9 @@ struct rpal_service *rpal_register_service(void)
INIT_LIST_HEAD(&rs->shared_pages);
atomic_set(&rs->thread_cnt, 0);
rs->enabled = false;
+ atomic_set(&rs->req_avail_cnt, MAX_REQUEST_SERVICE);
+ bitmap_zero(rs->requested_service_bitmap, RPAL_NR_ID);
+ spin_lock_init(&rs->lock);
rs->bad_service = false;
rs->base = calculate_base_address(rs->id);
@@ -229,6 +232,262 @@ void rpal_unregister_service(struct rpal_service *rs)
rpal_put_service(rs);
}
+static inline void set_requested_service_bitmap(struct rpal_service *rs, int id)
+{
+ set_bit(id, rs->requested_service_bitmap);
+}
+
+static inline void clear_requested_service_bitmap(struct rpal_service *rs, int id)
+{
+ clear_bit(id, rs->requested_service_bitmap);
+}
+
+static int add_mapped_service(struct rpal_service *rs, struct rpal_service *tgt,
+ int type_bit)
+{
+ struct rpal_mapped_service *node;
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&rs->lock, flags);
+ node = rpal_get_mapped_node(rs, tgt->id);
+ if (type_bit == RPAL_REQUEST_MAP) {
+ if (atomic_read(&rs->req_avail_cnt) == 0) {
+ ret = -EINVAL;
+ goto unlock;
+ }
+ }
+
+ if (node->rs == NULL) {
+ node->rs = rpal_get_service(tgt);
+ set_bit(type_bit, &node->type);
+ } else {
+ if (node->rs != tgt) {
+ ret = -EINVAL;
+ goto unlock;
+ } else {
+ if (test_and_set_bit(type_bit, &node->type)) {
+ ret = -EINVAL;
+ goto unlock;
+ }
+ }
+ }
+
+ if (type_bit == RPAL_REQUEST_MAP) {
+ set_requested_service_bitmap(rs, tgt->id);
+ atomic_dec(&rs->req_avail_cnt);
+ }
+
+unlock:
+ spin_unlock_irqrestore(&rs->lock, flags);
+ return ret;
+}
+
+static void remove_mapped_service(struct rpal_service *rs, int id, int type_bit)
+{
+ struct rpal_mapped_service *node;
+ struct rpal_service *t;
+ unsigned long flags;
+
+ spin_lock_irqsave(&rs->lock, flags);
+ node = rpal_get_mapped_node(rs, id);
+ if (node->rs == NULL)
+ goto unlock;
+
+ clear_bit(type_bit, &node->type);
+ if (type_bit == RPAL_REQUEST_MAP) {
+ clear_requested_service_bitmap(rs, id);
+ atomic_inc(&rs->req_avail_cnt);
+ }
+
+ if (node->type == 0) {
+ t = node->rs;
+ node->rs = NULL;
+ rpal_put_service(t);
+ }
+
+unlock:
+ spin_unlock_irqrestore(&rs->lock, flags);
+}
+
+static bool ready_to_map(struct rpal_service *cur, int tgt_id)
+{
+ struct rpal_mapped_service *node;
+ unsigned long flags;
+ bool need_map = false;
+
+ spin_lock_irqsave(&cur->lock, flags);
+ node = rpal_get_mapped_node(cur, tgt_id);
+ if (test_bit(RPAL_REQUEST_MAP, &node->type) &&
+ test_bit(RPAL_REVERSE_MAP, &node->type)) {
+ need_map = true;
+ }
+ spin_unlock_irqrestore(&cur->lock, flags);
+
+ return need_map;
+}
+
+int rpal_request_service(unsigned long arg)
+{
+ struct rpal_service *cur, *tgt;
+ struct rpal_request_arg rra;
+ long ret = 0;
+ int id;
+
+ cur = rpal_current_service();
+
+ if (copy_from_user(&rra, (void __user *)arg, sizeof(rra))) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ if (cur->key == rra.key) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ if (atomic_read(&cur->req_avail_cnt) == 0) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ mutex_lock(&cur->mutex);
+
+ if (!cur->enabled) {
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ tgt = rpal_get_service_by_key(rra.key);
+ if (tgt == NULL) {
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ if (!tgt->enabled) {
+ ret = -EPERM;
+ goto put_service;
+ }
+
+ ret = put_user((unsigned long)(tgt->rsm.user_meta), rra.user_metap);
+ if (ret) {
+ ret = -EFAULT;
+ goto put_service;
+ }
+
+ ret = put_user(tgt->id, rra.id);
+ if (ret) {
+ ret = -EFAULT;
+ goto put_service;
+ }
+
+ id = tgt->id;
+ ret = add_mapped_service(cur, tgt, RPAL_REQUEST_MAP);
+ if (ret < 0)
+ goto put_service;
+
+ ret = add_mapped_service(tgt, cur, RPAL_REVERSE_MAP);
+ if (ret < 0)
+ goto remove_request;
+
+ /* only map shared address space when both process request each other */
+ if (ready_to_map(cur, id)) {
+ ret = rpal_map_service(tgt);
+ if (ret < 0)
+ goto remove_reverse;
+ }
+
+ mutex_unlock(&cur->mutex);
+
+ rpal_put_service(tgt);
+
+ return 0;
+
+remove_reverse:
+ remove_mapped_service(tgt, cur->id, RPAL_REVERSE_MAP);
+remove_request:
+ remove_mapped_service(cur, tgt->id, RPAL_REQUEST_MAP);
+put_service:
+ rpal_put_service(tgt);
+unlock_mutex:
+ mutex_unlock(&cur->mutex);
+out:
+ return ret;
+}
+
+static int release_service(struct rpal_service *cur, struct rpal_service *tgt)
+{
+ remove_mapped_service(tgt, cur->id, RPAL_REVERSE_MAP);
+ remove_mapped_service(cur, tgt->id, RPAL_REQUEST_MAP);
+ rpal_unmap_service(tgt);
+
+ return 0;
+}
+
+static void rpal_release_service_all(void)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_service *tgt;
+ int ret, i;
+
+ rpal_for_each_requested_service(cur, i) {
+ struct rpal_mapped_service *node;
+
+ if (i == cur->id)
+ continue;
+ node = rpal_get_mapped_node(cur, i);
+ tgt = rpal_get_service(node->rs);
+ if (!tgt)
+ continue;
+
+ if (test_bit(RPAL_REQUEST_MAP, &node->type)) {
+ ret = release_service(cur, tgt);
+ if (unlikely(ret)) {
+ rpal_err("service %d release service %d fail\n",
+ cur->id, tgt->id);
+ }
+ }
+ rpal_put_service(tgt);
+ }
+}
+
+int rpal_release_service(u64 key)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_service *tgt = NULL;
+ struct rpal_mapped_service *node;
+ int ret = 0;
+ int i;
+
+ mutex_lock(&cur->mutex);
+
+ if (cur->key == key) {
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ rpal_for_each_requested_service(cur, i) {
+ node = rpal_get_mapped_node(cur, i);
+ if (node->rs->key == key) {
+ tgt = rpal_get_service(node->rs);
+ break;
+ }
+ }
+
+ if (!tgt) {
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+ ret = release_service(cur, tgt);
+
+ rpal_put_service(tgt);
+
+unlock_mutex:
+ mutex_unlock(&cur->mutex);
+ return ret;
+}
+
int rpal_enable_service(unsigned long arg)
{
struct rpal_service *cur = rpal_current_service();
@@ -270,6 +529,8 @@ int rpal_disable_service(void)
goto unlock_mutex;
}
+ rpal_release_service_all();
+
unlock_mutex:
mutex_unlock(&cur->mutex);
return ret;
@@ -289,11 +550,11 @@ void exit_rpal(bool group_dead)
if (!rs)
return;
- exit_rpal_thread();
-
if (group_dead)
rpal_disable_service();
+ exit_rpal_thread();
+
current->rpal_rs = NULL;
rpal_put_service(rs);
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 2e5010602177..1fe177523a36 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -77,6 +77,9 @@
#define RPAL_ADDRESS_SPACE_LOW ((0UL) + RPAL_ADDR_SPACE_SIZE)
#define RPAL_ADDRESS_SPACE_HIGH ((0UL) + RPAL_NR_ADDR_SPACE * RPAL_ADDR_SPACE_SIZE)
+/* No more than 15 services can be requested due to limitation of MPK. */
+#define MAX_REQUEST_SERVICE 15
+
extern unsigned long rpal_cap;
enum rpal_task_flag_bits {
@@ -92,6 +95,18 @@ struct rpal_service_metadata {
void __user *user_meta;
};
+struct rpal_request_arg {
+ unsigned long version;
+ u64 key;
+ unsigned long __user *user_metap;
+ int __user *id;
+};
+
+struct rpal_mapped_service {
+ unsigned long type;
+ struct rpal_service *rs;
+};
+
/*
* Each RPAL process (a.k.a RPAL service) should have a pointer to
* struct rpal_service in all its tasks' task_struct.
@@ -125,6 +140,8 @@ struct rpal_service {
*/
/* Mutex for time consuming operations */
struct mutex mutex;
+ /* spinlock for short operations */
+ spinlock_t lock;
/* pinned pages */
int nr_shared_pages;
@@ -137,6 +154,13 @@ struct rpal_service {
bool enabled;
struct rpal_service_metadata rsm;
+ /* the number of services allow to be requested */
+ atomic_t req_avail_cnt;
+
+ /* map for services required, being required and mapped */
+ struct rpal_mapped_service service_map[RPAL_NR_ID];
+ DECLARE_BITMAP(requested_service_bitmap, RPAL_NR_ID);
+
/* delayed service put work */
struct delayed_work delayed_put_work;
@@ -220,6 +244,8 @@ enum rpal_command_type {
RPAL_CMD_UNREGISTER_RECEIVER,
RPAL_CMD_ENABLE_SERVICE,
RPAL_CMD_DISABLE_SERVICE,
+ RPAL_CMD_REQUEST_SERVICE,
+ RPAL_CMD_RELEASE_SERVICE,
RPAL_NR_CMD,
};
@@ -244,6 +270,16 @@ enum rpal_command_type {
_IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_ENABLE_SERVICE, unsigned long)
#define RPAL_IOCTL_DISABLE_SERVICE \
_IO(RPAL_IOCTL_MAGIC, RPAL_CMD_DISABLE_SERVICE)
+#define RPAL_IOCTL_REQUEST_SERVICE \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_REQUEST_SERVICE, unsigned long)
+#define RPAL_IOCTL_RELEASE_SERVICE \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_RELEASE_SERVICE, unsigned long)
+
+#define rpal_for_each_requested_service(rs, idx) \
+ for (idx = find_first_bit(rs->requested_service_bitmap, RPAL_NR_ID); \
+ idx < RPAL_NR_ID; \
+ idx = find_next_bit(rs->requested_service_bitmap, RPAL_NR_ID, \
+ idx + 1))
/**
* @brief get new reference to a rpal service, a corresponding
@@ -274,6 +310,12 @@ static inline unsigned long rpal_get_top(struct rpal_service *rs)
return rs->base + RPAL_ADDR_SPACE_SIZE;
}
+static inline struct rpal_mapped_service *
+rpal_get_mapped_node(struct rpal_service *rs, int id)
+{
+ return &rs->service_map[id];
+}
+
#ifdef CONFIG_RPAL
static inline struct rpal_service *rpal_current_service(void)
{
--
2.20.1
Return-Path: <linux-kernel+bounces-667875-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 813B841E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:34:11 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 9B3377A3F83
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:32:52 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 2A82721FF28;
Fri, 30 May 2025 09:31:34 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="QMN/uMDJ"
Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176])
(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 902DF212B0A
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:31 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597493; cv=none; b=ay+Bf4Qx6lpPWhtaYDdRKgmX1Rj6WuesZoxHgifrNVaduqBp1ScQEdf6dEC7tKw3D6yZ+W/1syIZU6drbz9tc3zE+F0XQ4GvjbLa3JaO+mhXiDe+ll4m4fjHAP+Gm4GS+BG31EN/gEmODTfJQxIhpjTfQ9Kb892CDpr8+z32eoA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597493; c=relaxed/simple;
bh=CSDCXobBWZhtRTJYQJOr5+LQO5QZF5XuFGMveHLRtkY=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=BqOeal2+/EsmNGtwnAB+vOAzGg290CE2+dF+qmoO8buSBg/HiaJkQsIlrKVqXXVq3Lm+m3DPBh4A0PjHnKVnC/3leyV1a/NVJEW1fTNOTaAuwNUKVur9rN0xWt0AjQdIQfUC3Dzxvw1YBqIC4i4xPQIKVVqsJmOPQK7xym6pdiE=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=QMN/uMDJ; arc=none smtp.client-ip=209.85.215.176
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-b13e0471a2dso1244359a12.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:31:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597491; x=1749202291; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=rWr/E1U9MoZB6J4RM+OE8fwerNiGURyoNSQ2TTxCRRo=;
b=QMN/uMDJAC+cia0D5Uie7ylDSB8V955tA2GjAZEnP/hpfefNtYZ2IY9p7iwvn3gjI/
y5nHUjhDjU7dtFQyJkLpP7cilJVsUFSds/l+kvPKRTW/6Ovy1bYNpnvZdgEJ9lQ7Wmb6
DQipz4gUfcFAB15jSSj6KTRpqTq5auBHaRUOTfIzpQUcMVWimE9wD9DmOijdlRvEg04P
SvIxTF1nIqA9QIu8kxTJwkl/ANtRZsdPSI3GZfdSyL4r96RjnGHu4Vxni0w7VpDUpldH
Szljcpzm05jHfapokWUMaZ8sdnRyXtpaIy0yx4Bd051fqrT6zKzazXQeUtiFLx1YM+C7
SiTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597491; x=1749202291;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=rWr/E1U9MoZB6J4RM+OE8fwerNiGURyoNSQ2TTxCRRo=;
b=PV+cM8sF/1du80yVNnKjQv1VfGeuIRyTam8bNVIHgrXL58RUSXX19Ao77OILHzGHNd
YD5xJd4HPGFNYSr9N9Il/nrz8/dDnBsw48yzV+r9BTM4BrdfCAiuqkiZAPpI280b8otV
7BwsHWYGkd0kq9kHTg3fh9Xmu4qgj7Gdwu0c365rudaj0OsQ3u3XxT+Iiz5scsqE5b7M
u5zR/e1ikY+2LjNw8QLFfU38XlYmYsVK97hd2Pfv17e4X04Bf2drFWnrRGSPyxOg1a+4
+VZtRyrWoMXph/RmTYhK6ovk2veAMD5Mt1ilt5nQziZD7Ywl8XzSC6360Rs1GblddQ4P
FLIQ==
X-Forwarded-Encrypted: i=1; AJvYcCWCS3/uHgA/BvpUoOZmnK3oGAgn+Lm0KamJNksiHnpun0x6MiYKUChJsLLeqHjpDQRTz7UEOD9htFRPzSc=@vger.kernel.org
X-Gm-Message-State: AOJu0YzU/kz0wj23Hxv3TjslWztHx5y/BrBJ1l+0rmUkjfVhSvTrE/Iv
us54uChL6Br9+HcskZBao0TlGbCIG74F+Ai7euNNgo9puo5V/SWYhRys46x5g1pZoSY=
X-Gm-Gg: ASbGnctLj7MUg3fqK0gRNoAGPCs5v1w3+18GZ8WSGXm6I74jzudKpm762wGI/7vZgm1
OFy9lLhPVgJpD7BvuQE9afZyyEWdtmnElgKYdSjhf68+AdtEq8oLo/V/UzRvEE6DKLni17OR6zr
AwwU12slqaEH+eDA4oi8OKxeT+lZo6TcrQHCeC3azxX2vboCiVdvWsk+sUSzA3abHtFDSOEqEI8
/GqX1c11Wq6vM0zjSXY0C+rXIAuK6x/CU7gbEImgCDqHqRvUUBTxZqSTcPSQEHLt6VsvpeDltlR
V5o6YF1ktnxkBX0ZlQ+8S/ZktMSJu/WlqJRdj45oSEd55pRwyTs29im5bDskdUPKx4Y/8JCmlOY
PPuxxk9pCtfmRZ8xPMiUMCHeDlzvfo6k=
X-Google-Smtp-Source: AGHT+IHWxhBqxJC7pLUfy1wWPlfI3PTo1BKYuowDxnWEkooeR6TUqW9HSM93HT5AUTV5EBB5Y+mNrQ==
X-Received: by 2002:a17:90b:48d2:b0:311:ad7f:3281 with SMTP id 98e67ed59e1d1-3125036ba85mr2606005a91.12.1748597490626;
Fri, 30 May 2025 02:31:30 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.31.15
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:31:30 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 12/35] RPAL: enable service disable notification
Date: Fri, 30 May 2025 17:27:40 +0800
Message-Id: <20a49e36e1efc99b1489d81eb7b5fe8787fcee4c.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
When a service is disabled, all services that request this service need
to be notified.
This patch use poll functions of file to implement such notification.
When a service is disabled, it will notify all services that request it
by set bit in others services' dead_key_bitmap. And the poll function
will then issue a poll epoll event, other services can aware the service
has been disabled.
The key of disabled service can be read from the proc file.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/proc.c | 61 +++++++++++++++++++++++++++++++++++++++++
arch/x86/rpal/service.c | 37 +++++++++++++++++++++++--
include/linux/rpal.h | 10 +++++++
3 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/arch/x86/rpal/proc.c b/arch/x86/rpal/proc.c
index f001afd40562..16ac9612bfc5 100644
--- a/arch/x86/rpal/proc.c
+++ b/arch/x86/rpal/proc.c
@@ -8,6 +8,7 @@
#include <linux/rpal.h>
#include <linux/proc_fs.h>
+#include <linux/poll.h>
#include "internal.h"
@@ -82,10 +83,70 @@ static long rpal_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
return ret;
}
+static ssize_t rpal_read(struct file *file, char __user *buf, size_t count,
+ loff_t *pos)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_poll_data *rpd;
+ u64 released_keys[MAX_REQUEST_SERVICE];
+ unsigned long flags;
+ int nr_key = 0;
+ int nr_byte = 0;
+ int idx;
+
+ if (!cur)
+ return -EINVAL;
+
+ rpd = &cur->rpd;
+
+ spin_lock_irqsave(&rpd->poll_lock, flags);
+ idx = find_first_bit(rpd->dead_key_bitmap, RPAL_NR_ID);
+ while (idx < RPAL_NR_ID) {
+ released_keys[nr_key++] = rpd->dead_keys[idx];
+ idx = find_next_bit(rpd->dead_key_bitmap, RPAL_NR_ID, idx + 1);
+ }
+ spin_unlock_irqrestore(&rpd->poll_lock, flags);
+ nr_byte = nr_key * sizeof(u64);
+
+ if (copy_to_user(buf, released_keys, nr_byte)) {
+ nr_byte = -EAGAIN;
+ goto out;
+ }
+out:
+ return nr_byte;
+}
+
+static __poll_t rpal_poll(struct file *filep, struct poll_table_struct *wait)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_poll_data *rpd;
+ unsigned long flags;
+ __poll_t mask = 0;
+
+ if (unlikely(!cur)) {
+ rpal_err("Not a rpal service\n");
+ goto out;
+ }
+
+ rpd = &cur->rpd;
+
+ poll_wait(filep, &rpd->rpal_waitqueue, wait);
+
+ spin_lock_irqsave(&rpd->poll_lock, flags);
+ if (find_first_bit(rpd->dead_key_bitmap, RPAL_NR_ID) < RPAL_NR_ID)
+ mask |= EPOLLIN | EPOLLRDNORM;
+ spin_unlock_irqrestore(&rpd->poll_lock, flags);
+
+out:
+ return mask;
+}
+
const struct proc_ops proc_rpal_operations = {
.proc_open = rpal_open,
+ .proc_read = rpal_read,
.proc_ioctl = rpal_ioctl,
.proc_mmap = rpal_mmap,
+ .proc_poll = rpal_poll,
};
static int __init proc_rpal_init(void)
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index 16a2155873a1..f490ab07301d 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -181,6 +181,9 @@ struct rpal_service *rpal_register_service(void)
atomic_set(&rs->req_avail_cnt, MAX_REQUEST_SERVICE);
bitmap_zero(rs->requested_service_bitmap, RPAL_NR_ID);
spin_lock_init(&rs->lock);
+ spin_lock_init(&rs->rpd.poll_lock);
+ bitmap_zero(rs->rpd.dead_key_bitmap, RPAL_NR_ID);
+ init_waitqueue_head(&rs->rpd.rpal_waitqueue);
rs->bad_service = false;
rs->base = calculate_base_address(rs->id);
@@ -296,6 +299,7 @@ static void remove_mapped_service(struct rpal_service *rs, int id, int type_bit)
clear_bit(type_bit, &node->type);
if (type_bit == RPAL_REQUEST_MAP) {
+ clear_bit(id, rs->rpd.dead_key_bitmap);
clear_requested_service_bitmap(rs, id);
atomic_inc(&rs->req_avail_cnt);
}
@@ -424,15 +428,30 @@ static int release_service(struct rpal_service *cur, struct rpal_service *tgt)
return 0;
}
+static void rpal_notify_disable(struct rpal_poll_data *rpd, u64 key, int id)
+{
+ unsigned long flags;
+ bool need_wake = false;
+
+ spin_lock_irqsave(&rpd->poll_lock, flags);
+ if (!test_bit(id, rpd->dead_key_bitmap)) {
+ need_wake = true;
+ rpd->dead_keys[id] = key;
+ set_bit(id, rpd->dead_key_bitmap);
+ }
+ spin_unlock_irqrestore(&rpd->poll_lock, flags);
+ if (need_wake)
+ wake_up_interruptible(&rpd->rpal_waitqueue);
+}
+
static void rpal_release_service_all(void)
{
struct rpal_service *cur = rpal_current_service();
struct rpal_service *tgt;
+ struct rpal_mapped_service *node;
int ret, i;
rpal_for_each_requested_service(cur, i) {
- struct rpal_mapped_service *node;
-
if (i == cur->id)
continue;
node = rpal_get_mapped_node(cur, i);
@@ -449,6 +468,20 @@ static void rpal_release_service_all(void)
}
rpal_put_service(tgt);
}
+
+ for (i = 0; i < RPAL_NR_ID; i++) {
+ if (i == cur->id)
+ continue;
+
+ node = rpal_get_mapped_node(cur, i);
+ tgt = rpal_get_service(node->rs);
+ if (!tgt)
+ continue;
+
+ if (test_bit(RPAL_REVERSE_MAP, &node->type))
+ rpal_notify_disable(&tgt->rpd, cur->key, cur->id);
+ rpal_put_service(tgt);
+ }
}
int rpal_release_service(u64 key)
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 1fe177523a36..b9622f0235bf 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -107,6 +107,13 @@ struct rpal_mapped_service {
struct rpal_service *rs;
};
+struct rpal_poll_data {
+ spinlock_t poll_lock;
+ u64 dead_keys[RPAL_NR_ID];
+ DECLARE_BITMAP(dead_key_bitmap, RPAL_NR_ID);
+ wait_queue_head_t rpal_waitqueue;
+};
+
/*
* Each RPAL process (a.k.a RPAL service) should have a pointer to
* struct rpal_service in all its tasks' task_struct.
@@ -161,6 +168,9 @@ struct rpal_service {
struct rpal_mapped_service service_map[RPAL_NR_ID];
DECLARE_BITMAP(requested_service_bitmap, RPAL_NR_ID);
+ /* Notify service is released by others */
+ struct rpal_poll_data rpd;
+
/* delayed service put work */
struct delayed_work delayed_put_work;
--
2.20.1
Return-Path: <linux-kernel+bounces-667872-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org [147.75.80.249])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 9D5AC41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:34:15 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id DD0871885631
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:33:35 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id D7B6F22A80F;
Fri, 30 May 2025 09:31:02 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="UTab4Njo"
Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51])
(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 749D3221560
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:00 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.51
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597461; cv=none; b=FwFyAOiFT+Rf5sCCWEuo1O31BCkDUott2dnsDvilrz/P9ozCBfckF3U+jYPV/fn7IpNHZZINQZYTucXguPXKJaK+W65PjTs2HqrfF3isOXtWrpZy74IwTYE7+27UEdafTuKVoEIsVdIuWFVZwkx1VG8hiX3Rcywyp76zbZ0cj+E=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597461; c=relaxed/simple;
bh=zWuwJn1AfK9f6Ju/rr0kFMON4yyaiLCS77HNg2YNluA=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=geD4hR6aGupV4u6KNuwtjZ1PIQn8uWtnltniK98M00LfhdCoWZBVxNJA/OU2KjYw21/CbdoJpbrNraVJxzbINZchThQQtgSWn27u+zlEUR82jySCBrpf4IklFtSkEX21LQKtH7iiojjMK1YxM6VWukMyEdEQkCaUicJIr7bmjcg=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=UTab4Njo; arc=none smtp.client-ip=209.85.216.51
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-30f0d8628c8so2061994a91.0
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:31:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597460; x=1749202260; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=kZkk3bjH1sfOYp+VjBWd01Gh2LTXey//pWYFXMUcbnQ=;
b=UTab4NjoLFxlKeL8jmboXD5UpJMWaUHx3DVCAYwZLB0nlwEIlfiWuXkN22bpxm4Vi9
DTYrVN9yOy9VnBFeRgd2x8I5ZuuGH0WWwucVoUAv1AgR2lBacf6sTSZhDN9NNTQJoIq+
n3v8UiML8CowCq3JUHmtMvuVFYD22l5wG/lZ7TwlFcSvwCvCiD1TKBltNVnDZClzfipx
WdFgJsC2Qf54Z2bSF6uFlzzY/0CeWh0mm8ttBgqOtvLWFUdrFaRaSVGW7yjBXCRIWoiK
UvmKF9rH2tUV1J9ndAicxUy3UJGVcmSqBxY7jkpzEAWmcB2KeTTE3GLIcbp0y9hjo+17
XyZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597460; x=1749202260;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=kZkk3bjH1sfOYp+VjBWd01Gh2LTXey//pWYFXMUcbnQ=;
b=PDFbFXrXSBZGTWLToirV9oEvVhp8TPLXfi48rWjgYN6MqsqgAjE+5pMV5TPI4LOURH
ZNTC8lMTxVxn5fnfF7+OZ+bYpIxL6PxdHBKWKgUZ5aO2TJG9pI3DeQ6r/TGB1pHpy3Zr
zvOXLP3YOVrxiD0pfimx8pJtp9EemV3+1j9OeYSQ3slya11bBWL1RIGyb49UCBafDU2y
W4f4WeCNnm0S0tP28PiXpV5CgbyI2S/b+YipaWaRuk1xoBZuXmT9P/VkGJNfwK3JMCH2
QBJl/z/znTdl8ZP8g5LQ96DlQuUZ4fUWhR5V85YaBuqhyxudt4xe1mI4LJYxoaTEDKLT
HsEA==
X-Forwarded-Encrypted: i=1; AJvYcCV8N5r8E7TQrqfFLEV/HS79KlUVpi4ibC8McExAeRtLSOtuvCc+bIq+90v2ePGuSa+v0spfyd+T5iEVzxY=@vger.kernel.org
X-Gm-Message-State: AOJu0YzvOPFzRiyK+aRiEn0W+X3xAGWphTbnV72qpknsVnxZ8yFJoWbb
gHTXixQEg2fwq2mk4cD3Av6UTuHTGCW/teeXHam/gD/qvLKqP+/dk8XBpMD8DtGmvEs=
X-Gm-Gg: ASbGncsvB6SsP72NBwGziQspZKEgVxqnz+yZdm/Qr2udQW7QUCDascPQspFFbtdTA9o
M3styXsOz73UDITZeay+BtnvErNXyZhzakNm4byKhr8DDKs+3HP5nzpMPL2uZWWi4wJMefJX/ja
YxoIAKaoOWMNt9Xw46HAP0+yliGxm9YIyTijMYoyFwuFF0kAktVaJS1s2yiAiHlS5dMNA27O/tM
Q2FG4S85CUNxX2nBJlCeOULu8QBqRWZ6XWK+t1hp/3Bkce5NXY8GwFQ4knjrz7z1mmJjQZ6z6Up
8Ewm/vx1mt25l0ycZu6dCHuJM9ps7pSYI2PnyL5HSFgTor9xI18qzoCGRj5QdPJEf0mW0sXxxEk
K6WXUcg+PvnZdJNimnmwGmawf6x8p0gA=
X-Google-Smtp-Source: AGHT+IEDp+vpzbXXEsQMocz8uu8WDoupHL7dKOSkVefmCskmswDnpl1KI6oBSxmQepUxjo/3kPsGsg==
X-Received: by 2002:a17:90b:28c8:b0:30e:e9f1:8447 with SMTP id 98e67ed59e1d1-31214e11c6cmr9475340a91.4.1748597459572;
Fri, 30 May 2025 02:30:59 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.30.44
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:30:59 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 10/35] RPAL: allow service enable/disable
Date: Fri, 30 May 2025 17:27:38 +0800
Message-Id: <34c12765bcf534c5afedd10ee3e763695c6a045d.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Since RPAL involves communication between services, and services require
certain preparations (e.g., registering senders/receivers) before
communication, the kernel needs to sense whether a service is ready to
perform RPAL call-related operations.
This patch adds two interfaces: rpal_enable_service() and
rpal_disable_service(). rpal_enable_service() passes necessary information
to the kernel and marks the service as enabled. RPAL only permits
communication between services in the enabled state. rpal_disable_service()
clears the service's enabled state, thereby prohibiting communication
between the service and others via RPAL.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/rpal/internal.h | 2 ++
arch/x86/rpal/proc.c | 6 +++++
arch/x86/rpal/service.c | 50 ++++++++++++++++++++++++++++++++++++++++
include/linux/rpal.h | 18 +++++++++++++++
4 files changed, 76 insertions(+)
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
index 65f2cf4baf8f..769d3bbe5a6b 100644
--- a/arch/x86/rpal/internal.h
+++ b/arch/x86/rpal/internal.h
@@ -17,6 +17,8 @@ extern bool rpal_inited;
/* service.c */
int __init rpal_service_init(void);
void __init rpal_service_exit(void);
+int rpal_enable_service(unsigned long arg);
+int rpal_disable_service(void);
/* mm.c */
static inline struct rpal_shared_page *
diff --git a/arch/x86/rpal/proc.c b/arch/x86/rpal/proc.c
index 8a1e4a8a2271..acd814f31649 100644
--- a/arch/x86/rpal/proc.c
+++ b/arch/x86/rpal/proc.c
@@ -63,6 +63,12 @@ static long rpal_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
case RPAL_IOCTL_UNREGISTER_RECEIVER:
ret = rpal_unregister_receiver();
break;
+ case RPAL_IOCTL_ENABLE_SERVICE:
+ ret = rpal_enable_service(arg);
+ break;
+ case RPAL_IOCTL_DISABLE_SERVICE:
+ ret = rpal_disable_service();
+ break;
default:
return -EINVAL;
}
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index 42fb719dbb2a..8a7b679bc28b 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -177,6 +177,7 @@ struct rpal_service *rpal_register_service(void)
rs->nr_shared_pages = 0;
INIT_LIST_HEAD(&rs->shared_pages);
atomic_set(&rs->thread_cnt, 0);
+ rs->enabled = false;
rs->bad_service = false;
rs->base = calculate_base_address(rs->id);
@@ -228,6 +229,52 @@ void rpal_unregister_service(struct rpal_service *rs)
rpal_put_service(rs);
}
+int rpal_enable_service(unsigned long arg)
+{
+ struct rpal_service *cur = rpal_current_service();
+ struct rpal_service_metadata rsm;
+ int ret = 0;
+
+ if (cur->bad_service) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ ret = copy_from_user(&rsm, (void __user *)arg, sizeof(rsm));
+ if (ret) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ mutex_lock(&cur->mutex);
+ if (!cur->enabled) {
+ cur->rsm = rsm;
+ cur->enabled = true;
+ }
+ mutex_unlock(&cur->mutex);
+
+out:
+ return ret;
+}
+
+int rpal_disable_service(void)
+{
+ struct rpal_service *cur = rpal_current_service();
+ int ret = 0;
+
+ mutex_lock(&cur->mutex);
+ if (cur->enabled) {
+ cur->enabled = false;
+ } else {
+ ret = -EINVAL;
+ goto unlock_mutex;
+ }
+
+unlock_mutex:
+ mutex_unlock(&cur->mutex);
+ return ret;
+}
+
void copy_rpal(struct task_struct *p)
{
struct rpal_service *cur = rpal_current_service();
@@ -244,6 +291,9 @@ void exit_rpal(bool group_dead)
exit_rpal_thread();
+ if (group_dead)
+ rpal_disable_service();
+
current->rpal_rs = NULL;
rpal_put_service(rs);
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index c33425e896af..2e5010602177 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -84,6 +84,14 @@ enum rpal_task_flag_bits {
RPAL_RECEIVER_BIT,
};
+/*
+ * user_meta will be sent to other service when requested.
+ */
+struct rpal_service_metadata {
+ unsigned long version;
+ void __user *user_meta;
+};
+
/*
* Each RPAL process (a.k.a RPAL service) should have a pointer to
* struct rpal_service in all its tasks' task_struct.
@@ -125,6 +133,10 @@ struct rpal_service {
/* sender/receiver thread count */
atomic_t thread_cnt;
+ /* service metadata */
+ bool enabled;
+ struct rpal_service_metadata rsm;
+
/* delayed service put work */
struct delayed_work delayed_put_work;
@@ -206,6 +218,8 @@ enum rpal_command_type {
RPAL_CMD_UNREGISTER_SENDER,
RPAL_CMD_REGISTER_RECEIVER,
RPAL_CMD_UNREGISTER_RECEIVER,
+ RPAL_CMD_ENABLE_SERVICE,
+ RPAL_CMD_DISABLE_SERVICE,
RPAL_NR_CMD,
};
@@ -226,6 +240,10 @@ enum rpal_command_type {
_IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_REGISTER_RECEIVER, unsigned long)
#define RPAL_IOCTL_UNREGISTER_RECEIVER \
_IO(RPAL_IOCTL_MAGIC, RPAL_CMD_UNREGISTER_RECEIVER)
+#define RPAL_IOCTL_ENABLE_SERVICE \
+ _IOWR(RPAL_IOCTL_MAGIC, RPAL_CMD_ENABLE_SERVICE, unsigned long)
+#define RPAL_IOCTL_DISABLE_SERVICE \
+ _IO(RPAL_IOCTL_MAGIC, RPAL_CMD_DISABLE_SERVICE)
/**
* @brief get new reference to a rpal service, a corresponding
--
2.20.1
Return-Path: <linux-kernel+bounces-667876-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org [139.178.88.99])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 7A76641E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:34:23 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sv.mirrors.kernel.org (Postfix) with ESMTPS id 7E4CB3B626D
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:34:02 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id EF28122D7B4;
Fri, 30 May 2025 09:31:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="a7G9f4sB"
Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182])
(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 7CB79221277
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:44 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597506; cv=none; b=OvngwBkZtECJsC2Q0TXkDpyeteN2iYhBNvi8PQ0cZ8PbmigsCDM58GT8lmyySxB9hrCWU3DyeTycq80uleRsAnpXvCLaN2OFHbxCyEBcDDVEYLQj3jPAHVHdtg29wRv54Z/HATUie78c3ZLzIWe0WCVPcsJG6DERU+9OXzqP/gE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597506; c=relaxed/simple;
bh=zjDdMcJo7Ja3I/WBhXEJPi7Vf8GGUIfVIusJmH+sQRo=;
h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
To:Cc:Content-Type; b=JO3Scn60DQJG+epi51OQjHNL/HRJrrRQ0ijv/POTsmPh4eeq1HCh0QSMxvh7ZJoH5jxzS80VqWwgv0K7b8CHb5mNFm4lwlkNJ/1+kCLqLh9e6h1YqlJijqb6lPcvXMmt69hDQyrExSxwMfkkNOCBWj1cxZ+Cc/SRuqH6iehW+ug=
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=a7G9f4sB; arc=none smtp.client-ip=209.85.219.182
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-yb1-f182.google.com with SMTP id 3f1490d57ef6-e75668006b9so1673881276.3
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:31:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=linaro.org; s=google; t=1748597503; x=1749202303; darn=vger.kernel.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=nl25XztXyY+91TCe2znVYLQyRFe3A02EIrzJh6x7GCo=;
b=a7G9f4sBEY/YGgHiyzGfQtcl5WwSScKP5t262cYRu4yvgwRWO9SoLXiW9BrGywzoYP
en2jB2ZZrJLDZXKGRBwjZKU2IzeMHq2Q2B/cdLNOS/g5z6WwCzJSBHmEXzF6F7gQcJAD
qJvCEjWHh++ezR3sYbYR2h9+7UgMUgX0E2UXBJtvH52TziCwzxe/iYQ7PqWg/kJPHtn7
WklZyDsFHsyOKXYknJx1Oa6RhetNNgCw0ZN4IjkRiw1MJUQsTDKtuLSakphPQ0em8wfi
XfUfHrbAPLNhkEAldnqqsuDHaXRSV40TjZJops9Kgcb7Y6yfi/H6DTsOYZJYcKvgAMty
2t1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597503; x=1749202303;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=nl25XztXyY+91TCe2znVYLQyRFe3A02EIrzJh6x7GCo=;
b=bWs+5cSm+drV8N0GUT8+xrOUlUBN4vXffswxIb6WsEAQ1YoyKNIK4UG5BdjGVH5OJp
6OM2zHY9iG3WsJ77ivgo9bjXohb7m/6CO+HmUG1QDK9AD+3/I3OB6t5c8d6iOEE/zisq
H0nmt/1dVQxaK1r/+gCulFunapMBmPVJePh7hI1TxwMGxjAxn7ELbfO4adXgEz9vO4qR
2Ee+oo8AtYbyBaouW28YQv4c533CvrOHzVpZy5/le2sk4awnHRBu/MJ2AFegmRSbFFqq
u94w2s+ILeRK8aD0CEczaNfcxpo+MED9QKt0InJix0Xq/Xe234b3qD2NG6i34So1xkcD
eY+Q==
X-Forwarded-Encrypted: i=1; AJvYcCVgtJ9jbKU5PbquVQJVVMzNytpVF61D6bLoQYMW/rPFu1ZsRn/bW+dLQpxB80Up4Xzc4aVaFhB8YD/ctno=@vger.kernel.org
X-Gm-Message-State: AOJu0YygsUMF49RXZwkXGnBDZGImybrSJYGq5Kq9WlkOpIRpdVm+Mq77
W2MiuR4F9AQR2f2OWRadeN00wqt1+apQPb9DASNr2sC5z6FsFHsyskbdX6Kldga/QFjh+WTx7Q+
BFdcWrlzDxEDBzIMiFIhVR36IKbIgAHCrmcdacuhoTQ==
X-Gm-Gg: ASbGncsMkNLS3962e/j4SQlPzkE4Kh0V1rPRZSlju23TQKCSZuqSfsoAusEz5Zd7EXL
xuxRykW75TNooWJWhyVH9HDpMIm8lhtOZoi9eS5QaPEefkLUV0buTbwwsNnxxP+6GUZ4YR8Qw04
4SUF+/dY4MdX7XEfbnLtAQ5f9c5t7EOhDjWMQ9Av28H+dRI3TYbRUmakc=
X-Google-Smtp-Source: AGHT+IH95Myawh7TbubfOpFEx22AdElqILjS1RFSDs37pv1ARTzzSoQyHKeRwabQyQ3x8Rz9anZLL/Bb5eyOoF6wyYc=
X-Received: by 2002:a05:6902:20c7:b0:e7d:c9f4:952b with SMTP id
3f1490d57ef6-e7f81de0626mr3793584276.16.1748597503389; Fri, 30 May 2025
02:31:43 -0700 (PDT)
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
References: <20250528-pmdomain-hierarchy-onecell-v2-0-7885ae45e59c@xxxxxxxxxxxx>
<20250528-pmdomain-hierarchy-onecell-v2-1-7885ae45e59c@xxxxxxxxxxxx>
In-Reply-To: <20250528-pmdomain-hierarchy-onecell-v2-1-7885ae45e59c@xxxxxxxxxxxx>
From: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
Date: Fri, 30 May 2025 11:31:07 +0200
X-Gm-Features: AX0GCFsDY9QpXv-TDLaqMDwAZXQiaP-2ORBs2bXkP6yJWXm02HY-f6aS5ywCE0Y
Message-ID: <CAPDyKFqs=EuwzBodoh9-tnuDQP85bv3UnS5eoekCpjUbictfBQ@xxxxxxxxxxxxxx>
Subject: Re: [PATCH RFC v2 1/2] dt-bindings: power: add nexus map for power-domains
To: Kevin Hilman <khilman@xxxxxxxxxxxx>
Cc: Rob Herring <robh@xxxxxxxxxx>, Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>,
Conor Dooley <conor+dt@xxxxxxxxxx>, "Rafael J. Wysocki" <rjw@xxxxxxxxxxxxx>, linux-pm@xxxxxxxxxxxxxxx,
devicetree@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx,
arm-scmi@xxxxxxxxxxxxxxx
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
On Wed, 28 May 2025 at 23:59, Kevin Hilman <khilman@xxxxxxxxxxxx> wrote:
>
> Add support for nexus map to be able to support hierarchical power
> domains for providers with #power-domain-cells > 0.
>
> Suggested-by: Rob Herring <robh@xxxxxxxxxx>
> Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxxxx>
Reviewed-by: Ulf Hansson <ulf.hansson@xxxxxxxxxx>
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/power/power-domain.yaml | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index 8fdb529d560b..9f099d326aee 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -68,6 +68,15 @@ properties:
> by the given provider should be subdomains of the domain specified
> by this binding.
>
> + power-domains-map:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + Nexus node mapping property that establishes parent-child relationships
> + for PM domains using the format defined in the Device Tree specification
> + section 2.5.1. Each map entry consists of child domain specifier,
> + parent phandle, and optional parent specifier arguments. This property
> + is only supported for onecell providers (#power-domain-cells = 1).
> +
> required:
> - "#power-domain-cells"
>
> @@ -133,3 +142,29 @@ examples:
> min-residency-us = <7000>;
> };
> };
> +
> + - |
> + // Example using power-domains-map for Nexus mapping
> + main_pd: power-controller@12370000 {
> + compatible = "foo,power-controller";
> + reg = <0x12370000 0x1000>;
> + #power-domain-cells = <0>;
> + };
> +
> + wkup_pd: power-controller@12380000 {
> + compatible = "foo,power-controller";
> + reg = <0x12380000 0x1000>;
> + #power-domain-cells = <0>;
> + };
> +
> + scmi_pds protocol@11 {
> + compatible = "arm,scmi-power-domain";
> + reg = <0x11>;
> + #power-domain-cells = <1>;
> + power-domains-map = <15 &main_pd>,
> + <19 &wkup_pd>;
> + };
> +
> + // In this example using Nexus node mapping:
> + // - Child domain 15 (scmi_pds 15) becomes a subdomain of main_pd
> + // - Child domain 19 (scmi_pds 19) becomes a subdomain of wkup_pd
>
> --
> 2.49.0
>
Return-Path: <linux-kernel+bounces-667877-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 8C61C41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:34:40 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id CA22417E91B
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:34:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 7601922DA05;
Fri, 30 May 2025 09:31:49 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="UIhFXuhK"
Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.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 9A30C2222C1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:31:46 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597508; cv=none; b=YLsTIkZyr/Lxj3xCg3gqtxROwEMQ4aCTWGsGdOt2faJrA08J6RLeoajEZvQAE2SeIO26phg5/XB5Sa5mH99x/IDf2lfi7jCybijaUTjRHPojwGwCI4+MtmsUraqnn/FndaRAJ5BATfnLSmWVwFlhPPBExt9u+mKay59n3q3IKpE=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597508; c=relaxed/simple;
bh=x42OvKF8cu3SGLWZonaQOFG1mLKzqSw7oCqoTulLIhU=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=RnyYX6BhRrqJjsUPgCdp3Cp7NgmeRhZe+UZXmUctQyN0EW1lZGQjc+KxhON7z2iA1fMCpOwMCrZ0dyzIuUSWyWll7oiOLylCNOd7rIqjPHsBVYUtnislMmL1m2LJEEQ9e5aD7KwahPXkIUrFIW50dTd4yaI6s6nY6McS6Lcv+Xk=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=UIhFXuhK; arc=none smtp.client-ip=209.85.216.41
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-3124f18c214so295304a91.2
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:31:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597506; x=1749202306; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=lqEqFVUYhIQ6uCyFMSKyc3XjCtHWAqaCcpg8jFQsxWM=;
b=UIhFXuhKkT4Y96MhzklPzS+CDHR0Hw8VJ3D0QgE5uV/f0ZucyRKOfLHwT9vxTiLErV
j/R1Ct0aZGJOi9mfTNDGtDO/U7JHgHzd0D/7f3Z02wZCMehFDya7ysKmcdrLPqfa+Kgq
jdeAef2VgY6bSAmZeYcaxI75LLX8O8+ImWRe5C6OQmjNP64UgseKPtNB8/sBDld/OO7E
gBRLKl/EAGe2+e3mvcMrEiNKYFfPhqBslo/LfYZt0in/HfDVApFPGY4Fsbwe7TO0Ojl4
7tswhefuv5qkD9ggG7FBUkyGDBpgw0LY3WDOgW40Ng7qocSI1ce1YHVfSPN9ASiwORY7
nRAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597506; x=1749202306;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=lqEqFVUYhIQ6uCyFMSKyc3XjCtHWAqaCcpg8jFQsxWM=;
b=UKpUOSuoLfv1uW43q6yaptbWcjp7xh465EXaXSJSastvM+9VuydNfi88Pd116aYjFi
5ZKtyDEjYWAGs0jSS/hnWbE4EMgONA4/xTuKVcfd3YBdXQhVMkNd0SipBWcuWSPeSApx
OS4vgH1QUstpX8waKEKDqHvEzAREto1+iXZ1FSQ/cem8y3L5ZMMGod8hl6nRFSz1Rjzt
FeF/XRRmLPdsHHLG1x05cbpgWxMvoGe6dEcFOSCpB8/UKk25Seah/WLinIsTBRk/fPzn
/4KqPIPUl4BLF35InyViOSMtJWjaEPsSWAByucUGQFBwaCtdL84XUGA9NQ1usJ+Amufe
TC+Q==
X-Forwarded-Encrypted: i=1; AJvYcCUnNdgfWmbu1POJvhmU7UWHONXjlki01oJytfxO/k1uJbLmKgZ2bjYe7gBW5MecgmEurRquGGu4HuhCXbw=@vger.kernel.org
X-Gm-Message-State: AOJu0YxGiRPUhIhEalpoe/onAzJyH7pwyPpUDEMViu1/DWFqbZvLTEE0
srERtIVcCEwJfr8V9fRjyfeNqdBbjC6vd086022ICpmYDR0yyv97RftSt6cAteOjVkc=
X-Gm-Gg: ASbGnct+WzVXOsNaxsH7JZme53xj0AdZv3DsA0bdi96bI83UZAmOYCsBBTYmC89E20Z
Q/tvl77ELaEAmZVpc1Zv0ZHJA70kukZ06y92SP//a6PWECoWmxpNppbQjyYHZgwt+zR2Zx5RKJg
RWp10FImbin9oYGforzrEDdnc34TmRxWQN8gSAaC5vyy8lJk+O4BNaYVanBp20869LaV/mvSgqY
UvY95oyAc6qISlm0izmedP6lHhSpDJ1PhTg24AghYuf+xeoQgiFcYnYkjP/w44VOYaKk8yZWNil
u6kAMH5nEbG1ML2tPSdbHgQGOei/iWf+axZ5z9QdSKpnbLJUGPQAT8/oCUz1ayy6u8S8DFamrUX
CFJj8Bv40UQ==
X-Google-Smtp-Source: AGHT+IGF62FX0HQNv9LilxlCiViF0h8d1bY/G1W0X5Q0qQ2cdYg03wna6Pf30NCPziT41+dazZ7wew==
X-Received: by 2002:a17:90b:3b50:b0:312:1c83:58e9 with SMTP id 98e67ed59e1d1-3124150e464mr3530070a91.5.1748597505955;
Fri, 30 May 2025 02:31:45 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.31.31
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:31:45 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 13/35] RPAL: add tlb flushing support
Date: Fri, 30 May 2025 17:27:41 +0800
Message-Id: <c1eeca7e95433f2e51eeae63375f41d7fafd4c5b.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
When a thread flushes the TLB, since the address space is shared,
not only other threads in the current process but also other processes
that share the address space may access the corresponding memory (related
to the TLB flush). Therefore, the cpuset used for TLB flushing should be
the union of the mm_cpumasks of all processes that share the address
space.
This patch extend flush_tlb_info to store other process's mm_struct,
and when a CPU in the union of the mm_cpumasks if invoked to handle
tlb flushing, it will check whether cpu_tlbstate.loaded_mm matches any
of mm_structs stored in flush_tlb_info. If match, the CPU will do local
tlb flushing for that mm_struct.
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/include/asm/tlbflush.h | 10 ++
arch/x86/mm/tlb.c | 172 ++++++++++++++++++++++++++++++++
arch/x86/rpal/internal.h | 3 -
include/linux/rpal.h | 12 +++
mm/rmap.c | 4 +
5 files changed, 198 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
index e9b81876ebe4..f57b745af75c 100644
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -227,6 +227,11 @@ struct flush_tlb_info {
u8 stride_shift;
u8 freed_tables;
u8 trim_cpumask;
+#ifdef CONFIG_RPAL
+ struct mm_struct **mm_list;
+ u64 *tlb_gen_list;
+ int nr_mm;
+#endif
};
void flush_tlb_local(void);
@@ -356,6 +361,11 @@ static inline void arch_tlbbatch_add_pending(struct arch_tlbflush_unmap_batch *b
mmu_notifier_arch_invalidate_secondary_tlbs(mm, 0, -1UL);
}
+#ifdef CONFIG_RPAL
+void rpal_tlbbatch_add_pending(struct arch_tlbflush_unmap_batch *batch,
+ struct mm_struct *mm);
+#endif
+
static inline void arch_flush_tlb_batched_pending(struct mm_struct *mm)
{
flush_tlb_mm(mm);
diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 39f80111e6f1..a0fe17b13887 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -12,6 +12,7 @@
#include <linux/task_work.h>
#include <linux/mmu_notifier.h>
#include <linux/mmu_context.h>
+#include <linux/rpal.h>
#include <asm/tlbflush.h>
#include <asm/mmu_context.h>
@@ -1361,6 +1362,169 @@ void flush_tlb_multi(const struct cpumask *cpumask,
__flush_tlb_multi(cpumask, info);
}
+#ifdef CONFIG_RPAL
+static void rpal_flush_tlb_func_remote(void *info)
+{
+ struct mm_struct *loaded_mm = this_cpu_read(cpu_tlbstate.loaded_mm);
+ struct flush_tlb_info *f = info;
+ struct flush_tlb_info tf = *f;
+ int i;
+
+ /* As it comes from RPAL path, f->mm cannot be NULL */
+ if (f->mm == loaded_mm) {
+ flush_tlb_func(f);
+ return;
+ }
+
+ for (i = 0; i < f->nr_mm; i++) {
+ /* We always have f->mm_list[i] != NULL */
+ if (f->mm_list[i] == loaded_mm) {
+ tf.mm = f->mm_list[i];
+ tf.new_tlb_gen = f->tlb_gen_list[i];
+ flush_tlb_func(&tf);
+ return;
+ }
+ }
+}
+
+static void rpal_flush_tlb_func_multi(const struct cpumask *cpumask,
+ const struct flush_tlb_info *info)
+{
+ count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
+ if (info->end == TLB_FLUSH_ALL)
+ trace_tlb_flush(TLB_REMOTE_SEND_IPI, TLB_FLUSH_ALL);
+ else
+ trace_tlb_flush(TLB_REMOTE_SEND_IPI,
+ (info->end - info->start) >> PAGE_SHIFT);
+
+ if (info->freed_tables || mm_in_asid_transition(info->mm))
+ on_each_cpu_mask(cpumask, rpal_flush_tlb_func_remote,
+ (void *)info, true);
+ else
+ on_each_cpu_cond_mask(should_flush_tlb,
+ rpal_flush_tlb_func_remote, (void *)info,
+ 1, cpumask);
+}
+
+static void rpal_flush_tlb_func_local(struct mm_struct *mm, int cpu,
+ struct flush_tlb_info *info,
+ u64 new_tlb_gen)
+{
+ struct mm_struct *loaded_mm = this_cpu_read(cpu_tlbstate.loaded_mm);
+
+ if (loaded_mm == info->mm) {
+ lockdep_assert_irqs_enabled();
+ local_irq_disable();
+ flush_tlb_func(info);
+ local_irq_enable();
+ } else {
+ int i;
+
+ for (i = 0; i < info->nr_mm; i++) {
+ if (info->mm_list[i] == loaded_mm) {
+ lockdep_assert_irqs_enabled();
+ local_irq_disable();
+ info->mm = info->mm_list[i];
+ info->new_tlb_gen = info->tlb_gen_list[i];
+ flush_tlb_func(info);
+ info->mm = mm;
+ info->new_tlb_gen = new_tlb_gen;
+ local_irq_enable();
+ }
+ }
+ }
+}
+
+static void rpal_flush_tlb_mm_range(struct mm_struct *mm, int cpu,
+ struct flush_tlb_info *info, u64 new_tlb_gen)
+{
+ struct rpal_service *cur = mm->rpal_rs;
+ cpumask_t merged_mask;
+ struct mm_struct *mm_list[MAX_REQUEST_SERVICE];
+ u64 tlb_gen_list[MAX_REQUEST_SERVICE];
+ int nr_mm = 0;
+ int i;
+
+ cpumask_copy(&merged_mask, mm_cpumask(mm));
+ if (cur) {
+ struct rpal_service *tgt;
+ struct mm_struct *tgt_mm;
+
+ rpal_for_each_requested_service(cur, i) {
+ struct rpal_mapped_service *node;
+
+ if (i == cur->id)
+ continue;
+ node = rpal_get_mapped_node(cur, i);
+ if (!rpal_service_mapped(node))
+ continue;
+
+ tgt = rpal_get_service(node->rs);
+ if (!tgt)
+ continue;
+ tgt_mm = tgt->mm;
+ if (!mmget_not_zero(tgt_mm)) {
+ rpal_put_service(tgt);
+ continue;
+ }
+ mm_list[nr_mm] = tgt_mm;
+ tlb_gen_list[nr_mm] = inc_mm_tlb_gen(tgt_mm);
+
+ nr_mm++;
+ cpumask_or(&merged_mask, &merged_mask,
+ mm_cpumask(tgt_mm));
+ rpal_put_service(tgt);
+ }
+ info->mm_list = mm_list;
+ info->tlb_gen_list = tlb_gen_list;
+ info->nr_mm = nr_mm;
+ }
+
+ if (cpumask_any_but(&merged_mask, cpu) < nr_cpu_ids)
+ rpal_flush_tlb_func_multi(&merged_mask, info);
+ else
+ rpal_flush_tlb_func_local(mm, cpu, info, new_tlb_gen);
+
+ for (i = 0; i < nr_mm; i++)
+ mmput_async(mm_list[i]);
+}
+
+void rpal_tlbbatch_add_pending(struct arch_tlbflush_unmap_batch *batch,
+ struct mm_struct *mm)
+{
+ struct rpal_service *cur = mm->rpal_rs;
+ struct rpal_service *tgt;
+ struct mm_struct *tgt_mm;
+ int i;
+
+ rpal_for_each_requested_service(cur, i) {
+ struct rpal_mapped_service *node;
+
+ if (i == cur->id)
+ continue;
+
+ node = rpal_get_mapped_node(cur, i);
+ if (!rpal_service_mapped(node))
+ continue;
+
+ tgt = rpal_get_service(node->rs);
+ if (!tgt)
+ continue;
+ tgt_mm = tgt->mm;
+ if (!mmget_not_zero(tgt_mm)) {
+ rpal_put_service(tgt);
+ continue;
+ }
+ inc_mm_tlb_gen(tgt_mm);
+ cpumask_or(&batch->cpumask, &batch->cpumask,
+ mm_cpumask(tgt_mm));
+ mmu_notifier_arch_invalidate_secondary_tlbs(tgt_mm, 0, -1UL);
+ rpal_put_service(tgt);
+ mmput_async(tgt_mm);
+ }
+}
+#endif
+
/*
* See Documentation/arch/x86/tlb.rst for details. We choose 33
* because it is large enough to cover the vast majority (at
@@ -1439,6 +1603,11 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
info = get_flush_tlb_info(mm, start, end, stride_shift, freed_tables,
new_tlb_gen);
+#if IS_ENABLED(CONFIG_RPAL)
+ if (mm->rpal_rs)
+ rpal_flush_tlb_mm_range(mm, cpu, info, new_tlb_gen);
+ else {
+#endif
/*
* flush_tlb_multi() is not optimized for the common case in which only
* a local TLB flush is needed. Optimize this use-case by calling
@@ -1456,6 +1625,9 @@ void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start,
flush_tlb_func(info);
local_irq_enable();
}
+#if IS_ENABLED(CONFIG_RPAL)
+ }
+#endif
put_flush_tlb_info();
put_cpu();
diff --git a/arch/x86/rpal/internal.h b/arch/x86/rpal/internal.h
index c504b6efff64..cf6d608a994a 100644
--- a/arch/x86/rpal/internal.h
+++ b/arch/x86/rpal/internal.h
@@ -12,9 +12,6 @@
#include <linux/mm.h>
#include <linux/file.h>
-#define RPAL_REQUEST_MAP 0x1
-#define RPAL_REVERSE_MAP 0x2
-
extern bool rpal_inited;
/* service.c */
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index b9622f0235bf..36be1ab6a9f3 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -80,6 +80,11 @@
/* No more than 15 services can be requested due to limitation of MPK. */
#define MAX_REQUEST_SERVICE 15
+enum {
+ RPAL_REQUEST_MAP,
+ RPAL_REVERSE_MAP,
+};
+
extern unsigned long rpal_cap;
enum rpal_task_flag_bits {
@@ -326,6 +331,13 @@ rpal_get_mapped_node(struct rpal_service *rs, int id)
return &rs->service_map[id];
}
+static inline bool rpal_service_mapped(struct rpal_mapped_service *node)
+{
+ unsigned long type = (1 << RPAL_REQUEST_MAP) | (1 << RPAL_REVERSE_MAP);
+
+ return (node->type & type) == type;
+}
+
#ifdef CONFIG_RPAL
static inline struct rpal_service *rpal_current_service(void)
{
diff --git a/mm/rmap.c b/mm/rmap.c
index 67bb273dfb80..e68384f97ab9 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -682,6 +682,10 @@ static void set_tlb_ubc_flush_pending(struct mm_struct *mm, pte_t pteval,
return;
arch_tlbbatch_add_pending(&tlb_ubc->arch, mm, start, end);
+#ifdef CONFIG_RPAL
+ if (mm->rpal_rs)
+ rpal_tlbbatch_add_pending(&tlb_ubc->arch, mm);
+#endif
tlb_ubc->flush_required = true;
/*
--
2.20.1
Return-Path: <linux-kernel+bounces-667878-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id 2AD3E41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:35:00 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 93BDF7AD67E
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:33:41 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id C7991221F2D;
Fri, 30 May 2025 09:32:05 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="HYsOtTwq"
Received: from mail-pg1-f176.google.com (mail-pg1-f176.google.com [209.85.215.176])
(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 707EB222565
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:32:02 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.176
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597524; cv=none; b=P+UJAdSUpORB0g0aXt9jN4dTiONVKWhOC9vnRW2J1YgGaOrSoj48IGCHTgKBNs2elqmTA7DmNfSzbtjqop3oqp7f/JgzCyFUlNkSb86teUK6UFGyJeTVkKqTMAJGijgur8f7D+ES2vP5qwvdOFxGcJhOePhA7H64a66wnfT21J4=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597524; c=relaxed/simple;
bh=v0y8BsMdpB12xLvFn5vAwwkHzR1Wq6pNBECHF1ePs8o=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=du2HrmQiXo78CciFPwMZ8IGpbhGcvdtMpMfYkLjIxq0sM1Ctdw8m1jcAVjpOqqYlPGTBeyQD/b/dexYq1TSzWIBxymyEW7T07MZ3wVXZQOr2kVcQY9xKPueFlQ/I7I212BEocFHa9QBDkGgHkTl/K8jPAZ5JKM4/iq+fEoXvtyI=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=HYsOtTwq; arc=none smtp.client-ip=209.85.215.176
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pg1-f176.google.com with SMTP id 41be03b00d2f7-af6a315b491so1533617a12.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:32:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597522; x=1749202322; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=dO6otkog24Nl4MqGG9SKHBZpR3sFE7cRfJye6EEtKwU=;
b=HYsOtTwqn7S/y04wP3C85vE2nFJV+K9wtaqiRJohu+f+XYSjGnOuUrbY8pmTlg/+p3
yBxR1fgOc7FXWQpwH+g+Kozu3uCpxusa5vgbfp6fpGeQR0J6TmAaAgkRdmIkSVr0sRyQ
p1fJ5rGcazqjI/Bz2d6Mu20bsCyE810r9VouqmECRrFC4z+MqeuO5SYb3IVFtVVhZHfb
Dib8PeqnNuJ5IY5b0MRXNz7iIGUxeRBO5vIetq1Ka7SpM905TsScuVZaOUWHOPmiarfj
JgO/C7mkZIaj1Tdo5Q+2vmca/JQYdh+6Gd+PLWIlIrFCRE3Ro2pBWSMM0E2B+O/PHF0w
zWKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597522; x=1749202322;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=dO6otkog24Nl4MqGG9SKHBZpR3sFE7cRfJye6EEtKwU=;
b=ro7BvmoWAnV1di6bz7ogFcEtGSYrjj+yMLUiwdrtYQXlyJEOARt4bn9aU6LFCPm6Gi
+SN7GvbRBhSG+UmroElLxudP3rxFvh4KvI1RcA3YbeK18Ah2LTLCb73LJLjXA42v1oLf
hMRSAIqImnApdJXiLdgl0ruAP3XsIDCvB8/7kcxmQeIrfZavKe0136158+jaDscLuI+4
E/eRLSPi2bYYu4hRLba3gda+fkM4xF6tsCwsClYqpFLLVrQJ1fQJDrHWE6HfeuL4OHE6
ExPNu0A4DNYvQbkQ/hS1ynPryJ49ZQfYlQ7yc5eTsFNTXgq7IE6FLkU2JnHjTBllHgAQ
2eTg==
X-Forwarded-Encrypted: i=1; AJvYcCXlYBzYzWKXVLbSDyvSlhqUM8j/dyE4738EeJpW0oGYTCwnRDFZZU5U0Sk9QM4jGnFgjH+zADXnx+gakzg=@vger.kernel.org
X-Gm-Message-State: AOJu0YwHUIRJn4AT4RsfZZChTKGLxCPTFEuI42PkRCMmV3Li/CGgm9Zw
ddMpQD+zbX+Rm7mvhXjDa2YTEmjoW5CeUHs5H03I45Wjlbin6Fa36jZEGeXmvW0noxs=
X-Gm-Gg: ASbGncvwVDYg88zWmGVXE2CNPR4z/kU0UkxHYATg4/CcuklRGwr//Bhuwvd+UxanZcZ
eInqoGB8mo73jruR0uQa0zAhRlkuV/UQblyMgqNdILYd6QceIIQjTtwOq4tMtipXen+ICxTIMSP
hkl+f6wP0zoPkaZT6bzWjwkqcr1jrSBFGFYCS8os0cH6XKkvV7Z5O6s4Asm2EdCOgQmTsV8hiQT
wUtYppUR275sFfZIeBnOay/76RHxq5Maj+ltQIXgGYfQRE+89WSiK0nKWOHaCksSW8deqfuKmVV
cLXgMy/4ROP5Kb+Z1p0ZKWSpHUo1p4oeRxjfRsmaUaJy/qORMPUO41plavZRY3rimOW1crTU350
iR4Bb/vwICgTVx/pG/q1m
X-Google-Smtp-Source: AGHT+IHUkj4Y6AZ8cB5OAPZaSl8VUuiU504h/MLG14sBKE++U+CpU83URutH7UTuLZZMbY0g/ZO+FA==
X-Received: by 2002:a17:90b:1d50:b0:311:fde5:c4b6 with SMTP id 98e67ed59e1d1-31250344995mr2213817a91.6.1748597521434;
Fri, 30 May 2025 02:32:01 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.31.46
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:32:01 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 14/35] RPAL: enable page fault handling
Date: Fri, 30 May 2025 17:27:42 +0800
Message-Id: <a7c183833cca723238d4173a6df771dd7e340762.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
RPAL's address space sharing allows one process to access the memory of
another process, which may trigger page faults. To ensure programs can run
normally, RPAL needs to handle page faults occurring in the address space
of other processes. Additionally, to prevent processes from generating
coredumps due to invalid memory in other processes, RPAL must also restore
the current thread state to a pre-saved state under specific circumstances.
For handling page faults, by passing the correct vm_area_struct to
handle_page_fault(), RPAL locates the process corresponding to the address
where the page fault occurred and uses its mm_struct to handle the page
fault. Regarding thread state restoration, RPAL restores the thread's
state to a predefined state in userspace when it cannot locate the
mm_struct of the corresponding process (i.e., when the process has already
exited).
Signed-off-by: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
---
arch/x86/mm/fault.c | 271 ++++++++++++++++++++++++++++++++++++++++
arch/x86/rpal/mm.c | 34 +++++
arch/x86/rpal/service.c | 24 ++++
arch/x86/rpal/thread.c | 23 ++++
include/linux/rpal.h | 81 ++++++++----
5 files changed, 412 insertions(+), 21 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 998bd807fc7b..35f7c60a5e4f 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -19,6 +19,7 @@
#include <linux/mm_types.h>
#include <linux/mm.h> /* find_and_lock_vma() */
#include <linux/vmalloc.h>
+#include <linux/rpal.h>
#include <asm/cpufeature.h> /* boot_cpu_has, ... */
#include <asm/traps.h> /* dotraplinkage, ... */
@@ -1460,6 +1461,268 @@ trace_page_fault_entries(struct pt_regs *regs, unsigned long error_code,
trace_page_fault_kernel(address, regs, error_code);
}
+#if IS_ENABLED(CONFIG_RPAL)
+static void rpal_do_user_addr_fault(struct pt_regs *regs, unsigned long error_code,
+ unsigned long address, struct mm_struct *real_mm)
+{
+ struct vm_area_struct *vma;
+ vm_fault_t fault;
+ unsigned int flags = FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE;
+
+ if (unlikely(error_code & X86_PF_RSVD))
+ pgtable_bad(regs, error_code, address);
+
+ if (unlikely(cpu_feature_enabled(X86_FEATURE_SMAP) &&
+ !(error_code & X86_PF_USER) &&
+ !(regs->flags & X86_EFLAGS_AC))) {
+ page_fault_oops(regs, error_code, address);
+ return;
+ }
+
+ if (unlikely(faulthandler_disabled())) {
+ bad_area_nosemaphore(regs, error_code, address);
+ return;
+ }
+
+ if (WARN_ON_ONCE(!(regs->flags & X86_EFLAGS_IF))) {
+ bad_area_nosemaphore(regs, error_code, address);
+ return;
+ }
+
+ local_irq_enable();
+
+ perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
+
+ if (error_code & X86_PF_SHSTK)
+ flags |= FAULT_FLAG_WRITE;
+ if (error_code & X86_PF_WRITE)
+ flags |= FAULT_FLAG_WRITE;
+ if (error_code & X86_PF_INSTR)
+ flags |= FAULT_FLAG_INSTRUCTION;
+
+ if (user_mode(regs))
+ flags |= FAULT_FLAG_USER;
+
+#ifdef CONFIG_X86_64
+ if (is_vsyscall_vaddr(address)) {
+ if (emulate_vsyscall(error_code, regs, address))
+ return;
+ }
+#endif
+
+ if (!(flags & FAULT_FLAG_USER))
+ goto lock_mmap;
+
+ vma = lock_vma_under_rcu(real_mm, address);
+ if (!vma)
+ goto lock_mmap;
+
+ if (unlikely(access_error(error_code, vma))) {
+ bad_area_access_error(regs, error_code, address, NULL, vma);
+ count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
+ return;
+ }
+
+ fault = handle_mm_fault(vma, address, flags | FAULT_FLAG_VMA_LOCK, regs);
+ if (!(fault & (VM_FAULT_RETRY | VM_FAULT_COMPLETED)))
+ vma_end_read(vma);
+
+ if (!(fault & VM_FAULT_RETRY)) {
+ count_vm_vma_lock_event(VMA_LOCK_SUCCESS);
+ goto done;
+ }
+ count_vm_vma_lock_event(VMA_LOCK_RETRY);
+ if (fault & VM_FAULT_MAJOR)
+ flags |= FAULT_FLAG_TRIED;
+
+ /* Quick path to respond to signals */
+ if (fault_signal_pending(fault, regs)) {
+ if (!user_mode(regs))
+ kernelmode_fixup_or_oops(regs, error_code, address,
+ SIGBUS, BUS_ADRERR,
+ ARCH_DEFAULT_PKEY);
+ return;
+ }
+lock_mmap:
+
+retry:
+ /*
+ * Here we don't need to lock current->mm since no vma in
+ * current->mm is used to handle this page fault. However,
+ * we do need to lock real_mm, as the address belongs to
+ * real_mm's vma.
+ */
+ vma = lock_mm_and_find_vma(real_mm, address, regs);
+ if (unlikely(!vma)) {
+ bad_area_nosemaphore(regs, error_code, address);
+ return;
+ }
+
+ if (unlikely(access_error(error_code, vma))) {
+ bad_area_access_error(regs, error_code, address, real_mm, vma);
+ return;
+ }
+
+ fault = handle_mm_fault(vma, address, flags, regs);
+
+ if (fault_signal_pending(fault, regs)) {
+ /*
+ * Quick path to respond to signals. The core mm code
+ * has unlocked the mm for us if we get here.
+ */
+ if (!user_mode(regs))
+ kernelmode_fixup_or_oops(regs, error_code, address,
+ SIGBUS, BUS_ADRERR,
+ ARCH_DEFAULT_PKEY);
+ return;
+ }
+
+ /* The fault is fully completed (including releasing mmap lock) */
+ if (fault & VM_FAULT_COMPLETED)
+ return;
+
+ if (unlikely(fault & VM_FAULT_RETRY)) {
+ flags |= FAULT_FLAG_TRIED;
+ goto retry;
+ }
+
+ mmap_read_unlock(real_mm);
+done:
+ if (likely(!(fault & VM_FAULT_ERROR)))
+ return;
+
+ if (fatal_signal_pending(current) && !user_mode(regs)) {
+ kernelmode_fixup_or_oops(regs, error_code, address, 0, 0,
+ ARCH_DEFAULT_PKEY);
+ return;
+ }
+
+ if (fault & VM_FAULT_OOM) {
+ /* Kernel mode? Handle exceptions or die: */
+ if (!user_mode(regs)) {
+ kernelmode_fixup_or_oops(regs, error_code, address,
+ SIGSEGV, SEGV_MAPERR,
+ ARCH_DEFAULT_PKEY);
+ return;
+ }
+
+ pagefault_out_of_memory();
+ } else {
+ if (fault & (VM_FAULT_SIGBUS|VM_FAULT_HWPOISON|
+ VM_FAULT_HWPOISON_LARGE))
+ do_sigbus(regs, error_code, address, fault);
+ else if (fault & VM_FAULT_SIGSEGV)
+ bad_area_nosemaphore(regs, error_code, address);
+ else
+ BUG();
+ }
+}
+NOKPROBE_SYMBOL(rpal_do_user_addr_fault);
+
+static inline void rpal_try_to_rebuild_context(struct pt_regs *regs,
+ unsigned long address,
+ int error_code)
+{
+ int handle_more = 0;
+
+ /*
+ * We only rebuild sender's context, as other threads are not supposed
+ * to access other process's memory, thus they will not trigger a page
+ * fault.
+ */
+ handle_more = rpal_rebuild_sender_context_on_fault(regs, address, -1);
+ /*
+ * If we are not able to rebuild sender's context, just
+ * send a signal to let it coredump.
+ */
+ if (handle_more)
+ force_sig_fault(SIGSEGV, SEGV_MAPERR, (void __user *)address);
+}
+
+/*
+ * Most logic of this function is copied from do_user_addr_fault().
+ * RPAL logic is added to handle special cases, such as find another
+ * process's mm and rebuild sender's context if such page table is
+ * not able to be handled.
+ */
+static bool rpal_try_user_addr_fault(struct pt_regs *regs, unsigned long error_code,
+ unsigned long address)
+{
+ struct mm_struct *real_mm;
+ int rebuild = 0;
+
+ /* fast path: avoid mmget and mmput */
+ if (unlikely((error_code & (X86_PF_USER | X86_PF_INSTR)) ==
+ X86_PF_INSTR)) {
+ /*
+ * Whoops, this is kernel mode code trying to execute from
+ * user memory. Unless this is AMD erratum #93, which
+ * corrupts RIP such that it looks like a user address,
+ * this is unrecoverable. Don't even try to look up the
+ * VMA or look for extable entries.
+ */
+ if (is_errata93(regs, address))
+ return true;
+
+ page_fault_oops(regs, error_code, address);
+ return true;
+ }
+
+ /* kprobes don't want to hook the spurious faults: */
+ if (WARN_ON_ONCE(kprobe_page_fault(regs, X86_TRAP_PF)))
+ return true;
+
+ real_mm = rpal_pf_get_real_mm(address, &rebuild);
+
+ if (real_mm) {
+#ifdef CONFIG_MEMCG
+ struct mem_cgroup *memcg = NULL;
+
+ prefetchw(&real_mm->mmap_lock);
+ /* try to charge page alloc to real_mm's memcg */
+ if (!current->active_memcg) {
+ memcg = get_mem_cgroup_from_mm(real_mm);
+ if (memcg)
+ set_active_memcg(memcg);
+ }
+ rpal_do_user_addr_fault(regs, error_code, address, real_mm);
+ if (memcg) {
+ set_active_memcg(NULL);
+ mem_cgroup_put(memcg);
+ }
+#else
+ prefetchw(&real_mm->mmap_lock);
+ rpal_do_user_addr_fault(regs, error_code, address, real_mm);
+#endif
+ mmput_async(real_mm);
+ return true;
+ } else if (user_mode(regs) && rebuild) {
+ rpal_try_to_rebuild_context(regs, address, -1);
+ return true;
+ }
+
+ return false;
+}
+
+static bool rpal_handle_page_fault(struct pt_regs *regs, unsigned long error_code,
+ unsigned long address)
+{
+ struct rpal_service *cur = rpal_current_service();
+
+ /*
+ * For RPAL process, it may access another process's memory and
+ * there may be page fault. We handle this case with our own routine.
+ * If we cannot handle this page fault, just let it go and handle
+ * it as a normal page fault.
+ */
+ if (cur && !rpal_is_correct_address(cur, address)) {
+ if (rpal_try_user_addr_fault(regs, error_code, address))
+ return true;
+ }
+ return false;
+}
+#endif
+
static __always_inline void
handle_page_fault(struct pt_regs *regs, unsigned long error_code,
unsigned long address)
@@ -1473,7 +1736,15 @@ handle_page_fault(struct pt_regs *regs, unsigned long error_code,
if (unlikely(fault_in_kernel_space(address))) {
do_kern_addr_fault(regs, error_code, address);
} else {
+#ifdef CONFIG_RPAL
+ if (rpal_handle_page_fault(regs, error_code, address)) {
+ local_irq_disable();
+ return;
+ }
+ do_user_addr_fault(regs, error_code, address);
+#else /* !CONFIG_RPAL */
do_user_addr_fault(regs, error_code, address);
+#endif
/*
* User address page fault handling might have reenabled
* interrupts. Fixing up all potential exit points of
diff --git a/arch/x86/rpal/mm.c b/arch/x86/rpal/mm.c
index f1003baae001..be7714ede2bf 100644
--- a/arch/x86/rpal/mm.c
+++ b/arch/x86/rpal/mm.c
@@ -390,3 +390,37 @@ void rpal_unmap_service(struct rpal_service *tgt)
}
mm_unlink_p4d(cur_mm, tgt->base);
}
+
+static inline bool check_service_mapped(struct rpal_service *cur, int tgt_id)
+{
+ struct rpal_mapped_service *node;
+ bool is_mapped = true;
+ unsigned long type = (1 << RPAL_REVERSE_MAP) | (1 << RPAL_REQUEST_MAP);
+
+ node = rpal_get_mapped_node(cur, tgt_id);
+ if (unlikely((node->type & type) != type))
+ is_mapped = false;
+
+ return is_mapped;
+}
+
+struct mm_struct *rpal_pf_get_real_mm(unsigned long address, int *rebuild)
+{
+ struct rpal_service *cur, *tgt;
+ struct mm_struct *mm = NULL;
+
+ cur = rpal_current_service();
+
+ tgt = rpal_get_mapped_service_by_addr(cur, address);
+ if (tgt == NULL)
+ goto out;
+
+ mm = tgt->mm;
+ if (unlikely(!check_service_mapped(cur, tgt->id) ||
+ !mmget_not_zero(mm)))
+ mm = NULL;
+ *rebuild = 1;
+ rpal_put_service(tgt);
+out:
+ return mm;
+}
diff --git a/arch/x86/rpal/service.c b/arch/x86/rpal/service.c
index f490ab07301d..49458321e7dc 100644
--- a/arch/x86/rpal/service.c
+++ b/arch/x86/rpal/service.c
@@ -148,6 +148,30 @@ static inline unsigned long calculate_base_address(int id)
return RPAL_ADDRESS_SPACE_LOW + RPAL_ADDR_SPACE_SIZE * id;
}
+struct rpal_service *rpal_get_mapped_service_by_id(struct rpal_service *rs,
+ int id)
+{
+ struct rpal_service *ret;
+
+ if (!is_valid_id(id))
+ return NULL;
+
+ ret = rpal_get_service(rs->service_map[id].rs);
+
+ return ret;
+}
+
+/* This function must be called after rpal_is_correct_address () */
+struct rpal_service *rpal_get_mapped_service_by_addr(struct rpal_service *rs,
+ unsigned long addr)
+{
+ int id;
+
+ id = (addr - RPAL_ADDRESS_SPACE_LOW) / RPAL_ADDR_SPACE_SIZE;
+
+ return rpal_get_mapped_service_by_id(rs, id);
+}
+
struct rpal_service *rpal_register_service(void)
{
struct rpal_service *rs;
diff --git a/arch/x86/rpal/thread.c b/arch/x86/rpal/thread.c
index 7550ad94b63f..e50a4c865ff8 100644
--- a/arch/x86/rpal/thread.c
+++ b/arch/x86/rpal/thread.c
@@ -155,6 +155,29 @@ int rpal_unregister_receiver(void)
return ret;
}
+int rpal_rebuild_sender_context_on_fault(struct pt_regs *regs,
+ unsigned long addr, int error_code)
+{
+ if (rpal_test_current_thread_flag(RPAL_SENDER_BIT)) {
+ struct rpal_sender_call_context *scc = current->rpal_sd->scc;
+ unsigned long erip, ersp;
+ int magic;
+
+ erip = scc->ec.erip;
+ ersp = scc->ec.ersp;
+ magic = scc->ec.magic;
+ if (magic == RPAL_ERROR_MAGIC) {
+ regs->ax = error_code;
+ regs->ip = erip;
+ regs->sp = ersp;
+ /* avoid rebuild again */
+ scc->ec.magic = 0;
+ return 0;
+ }
+ }
+ return -EINVAL;
+}
+
void exit_rpal_thread(void)
{
if (rpal_test_current_thread_flag(RPAL_SENDER_BIT))
diff --git a/include/linux/rpal.h b/include/linux/rpal.h
index 36be1ab6a9f3..3310d222739e 100644
--- a/include/linux/rpal.h
+++ b/include/linux/rpal.h
@@ -85,6 +85,8 @@ enum {
RPAL_REVERSE_MAP,
};
+#define RPAL_ERROR_MAGIC 0x98CC98CC
+
extern unsigned long rpal_cap;
enum rpal_task_flag_bits {
@@ -198,23 +200,6 @@ struct rpal_version_info {
unsigned long cap;
};
-/* End */
-
-struct rpal_shared_page {
- unsigned long user_start;
- unsigned long kernel_start;
- int npage;
- atomic_t refcnt;
- struct list_head list;
-};
-
-struct rpal_common_data {
- /* back pointer to task_struct */
- struct task_struct *bp_task;
- /* service id of rpal_service */
- int service_id;
-};
-
/* User registers state */
struct rpal_task_context {
u64 r15;
@@ -232,17 +217,44 @@ struct rpal_receiver_call_context {
int receiver_id;
};
-struct rpal_receiver_data {
- struct rpal_common_data rcd;
- struct rpal_shared_page *rsp;
- struct rpal_receiver_call_context *rcc;
+/* recovery point for sender */
+struct rpal_error_context {
+ unsigned long fsbase;
+ u64 erip;
+ u64 ersp;
+ int state;
+ int magic;
};
struct rpal_sender_call_context {
struct rpal_task_context rtc;
+ struct rpal_error_context ec;
int sender_id;
};
+/* End */
+
+struct rpal_shared_page {
+ unsigned long user_start;
+ unsigned long kernel_start;
+ int npage;
+ atomic_t refcnt;
+ struct list_head list;
+};
+
+struct rpal_common_data {
+ /* back pointer to task_struct */
+ struct task_struct *bp_task;
+ /* service id of rpal_service */
+ int service_id;
+};
+
+struct rpal_receiver_data {
+ struct rpal_common_data rcd;
+ struct rpal_shared_page *rsp;
+ struct rpal_receiver_call_context *rcc;
+};
+
struct rpal_sender_data {
struct rpal_common_data rcd;
struct rpal_shared_page *rsp;
@@ -338,6 +350,26 @@ static inline bool rpal_service_mapped(struct rpal_mapped_service *node)
return (node->type & type) == type;
}
+static inline bool rpal_is_correct_address(struct rpal_service *rs, unsigned long address)
+{
+ if (likely(rs->base <= address &&
+ address < rs->base + RPAL_ADDR_SPACE_SIZE))
+ return true;
+
+ /*
+ * [rs->base, rs->base + RPAL_ADDR_SPACE_SIZE) is always a
+ * sub range of [RPAL_ADDRESS_SPACE_LOW, RPAL_ADDRESS_SPACE_HIGH).
+ * Therefore, we can only check whether the address is in
+ * [RPAL_ADDRESS_SPACE_LOW, RPAL_ADDRESS_SPACE_HIGH) to determine
+ * whether the address may belong to another RPAL service.
+ */
+ if (address >= RPAL_ADDRESS_SPACE_LOW &&
+ address < RPAL_ADDRESS_SPACE_HIGH)
+ return false;
+
+ return true;
+}
+
#ifdef CONFIG_RPAL
static inline struct rpal_service *rpal_current_service(void)
{
@@ -372,6 +404,13 @@ void copy_rpal(struct task_struct *p);
void exit_rpal(bool group_dead);
int rpal_balloon_init(unsigned long base);
void rpal_exit_mmap(struct mm_struct *mm);
+struct rpal_service *rpal_get_mapped_service_by_addr(struct rpal_service *rs,
+ unsigned long addr);
+struct rpal_service *rpal_get_mapped_service_by_id(struct rpal_service *rs,
+ int id);
+int rpal_rebuild_sender_context_on_fault(struct pt_regs *regs,
+ unsigned long addr, int error_code);
+struct mm_struct *rpal_pf_get_real_mm(unsigned long address, int *rebuild);
extern void rpal_pick_mmap_base(struct mm_struct *mm,
struct rlimit *rlim_stack);
--
2.20.1
Return-Path: <linux-kernel+bounces-667879-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org [147.75.48.161])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id A91B241E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:35:07 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by sy.mirrors.kernel.org (Postfix) with ESMTPS id 504467B0183
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:33:49 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id 3CAA42236FF;
Fri, 30 May 2025 09:32:07 +0000 (UTC)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190])
(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 98D58222578;
Fri, 30 May 2025 09:32:01 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.190
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597526; cv=none; b=mZdzxBgGVaguqIEpYZK2GxTx4gAT0pyhWgMxlq/Xs1qcDALiz5QYyxxvr8yLt530o1pvMigaKqoXl60u0lxwMJFOU/Enf01M9pOqEeQpEebqtc9xnyie3oiHD6A5L+Ej/VavcVlYBF3C/l0vboDdiFO5QU5D6yiiS0XfBv3YLMw=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597526; c=relaxed/simple;
bh=r3EQ7kD0QYtBm/wVC83vp9ptG9VHOOzuguqUtvBO63U=;
h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From:
In-Reply-To:Content-Type; b=DAaRP8bGhEOJ5m2o9uJgUrGh12GDM1JoNISKwv2K2nxIUV/lF61Z43l1gV/7KT3tPNn0GI++SkDIWoMcT3Ei4XHwpLUpNgD2uZtK+u4MDwRIy+rzZrDUnuhlvBWYjLPQClldvb67byZTKu8J8je/171nYoUy//9VjejOYeistfc=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.190
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com
Received: from mail.maildlp.com (unknown [172.19.88.214])
by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4b7yb13zDqz2CfQD;
Fri, 30 May 2025 17:28:13 +0800 (CST)
Received: from kwepemg500008.china.huawei.com (unknown [7.202.181.45])
by mail.maildlp.com (Postfix) with ESMTPS id 696321A016C;
Fri, 30 May 2025 17:31:59 +0800 (CST)
Received: from [127.0.0.1] (10.174.177.71) by kwepemg500008.china.huawei.com
(7.202.181.45) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 30 May
2025 17:31:58 +0800
Message-ID: <6200e067-0ad1-4dc4-9694-05ee1e977f4c@xxxxxxxxxx>
Date: Fri, 30 May 2025 17:31:48 +0800
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 2/4] ext4: move mb_last_[group|start] to ext4_inode_info
To: Jan Kara <jack@xxxxxxx>
CC: <linux-ext4@xxxxxxxxxxxxxxx>, <tytso@xxxxxxx>, <adilger.kernel@xxxxxxxxx>,
<linux-kernel@xxxxxxxxxxxxxxx>, <yi.zhang@xxxxxxxxxx>,
<yangerkun@xxxxxxxxxx>, <libaokun@xxxxxxxxxxxxxxx>, Baokun Li
<libaokun1@xxxxxxxxxx>
References: <20250523085821.1329392-1-libaokun@xxxxxxxxxxxxxxx>
<20250523085821.1329392-3-libaokun@xxxxxxxxxxxxxxx>
<afjkyrm4y5mp5p72ew3ddqma7v4gkmjqdkcloeaidcj55ruami@zfkn6dzgqfwh>
Content-Language: en-US
From: Baokun Li <libaokun1@xxxxxxxxxx>
In-Reply-To: <afjkyrm4y5mp5p72ew3ddqma7v4gkmjqdkcloeaidcj55ruami@zfkn6dzgqfwh>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-ClientProxiedBy: kwepems200001.china.huawei.com (7.221.188.67) To
kwepemg500008.china.huawei.com (7.202.181.45)
X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
Hello Honza,
Thank you for you review!
On 2025/5/29 20:56, Jan Kara wrote:
> On Fri 23-05-25 16:58:19, libaokun@xxxxxxxxxxxxxxx wrote:
>> From: Baokun Li <libaokun1@xxxxxxxxxx>
>>
>> After we optimized the block group lock, we found another lock
>> contention issue when running will-it-scale/fallocate2 with multiple
>> processes. The fallocate's block allocation and the truncate's block
>> release were fighting over the s_md_lock. The problem is, this lock
>> protects totally different things in those two processes: the list of
>> freed data blocks (s_freed_data_list) when releasing, and where to start
>> looking for new blocks (mb_last_[group|start]) when allocating.
>>
>> Moreover, when allocating data blocks, if the first try (goal allocation)
>> fails and stream allocation is on, it tries a global goal starting from
>> the last group we used (s_mb_last_group). This can make things faster by
>> writing blocks close together on the disk. But when many processes are
>> allocating, they all fight over s_md_lock and might even try to use the
>> same group. This makes it harder to merge extents and can make files more
>> fragmented. If different processes allocate chunks of very different sizes,
>> the free space on the disk can also get fragmented. A small allocation
>> might fit in a partially full group, but a big allocation might have
>> skipped it, leading to the small IO ending up in a more empty group.
>>
>> So, we're changing stream allocation to work per inode. First, it tries
>> the goal, then the last group where that inode successfully allocated a
>> block. This keeps an inode's data closer together. Plus, after moving
>> mb_last_[group|start] to ext4_inode_info, we don't need s_md_lock during
>> block allocation anymore because we already have the write lock on
>> i_data_sem. This gets rid of the contention between allocating and
>> releasing blocks, which gives a huge performance boost to fallocate2.
>>
>> Performance test data follows:
>>
>> CPU: HUAWEI Kunpeng 920
>> Memory: 480GB
>> Disk: 480GB SSD SATA 3.2
>> Test: Running will-it-scale/fallocate2 on 64 CPU-bound containers.
>> Observation: Average fallocate operations per container per second.
>>
>> base patched
>> mb_optimize_scan=0 6755 23280 (+244.6%)
>> mb_optimize_scan=1 4302 10430 (+142.4%)
>>
>> Signed-off-by: Baokun Li <libaokun1@xxxxxxxxxx>
> Good spotting with the s_md_lock contention here. But your changes don't
> quite make sense to me. The idea of streaming allocation in mballoc is to
> have an area of filesystem for large files to reduce fragmentation. When
> you switch to per-inode, this effect of packing large files together goes
> away. Futhermore for each inode either all allocations will be very likely
> streaming or not streaming (the logic uses file size) so either your
> per-inode target will be unused or just another constantly used copy of
> goal value.
Sorry, I didn't intend to break streaming allocation's semantics.
A precise definition of streaming allocation is not found in the
existing code, documentation, or historical records. Consequently,
my previous understanding of it was somewhat inaccurate.
I previously thought it was used to optimize the efficiency of linear
traversal. For instance, if 500 inodes are created in group 0 and each
file is sequentially filled to 1GB, each file's goal, being empty, would
be group 1 (the second group in the inode's flex_bg).
Without a global goal and in the absence of non-linear traversal,
after the first inode is filled, the second inode would need to traverse
groups 1 through 8 to find its first free block.
This inefficiency escalates, eventually requiring the 500th inode to
potentially traverse almost 4000 block groups to find its first available
block.
I initially believed it could be split to the inode level to reduce
traversal time and file fragmentation. However, as you pointed out,
its purpose is to cluster large files, not data blocks within a file.
Given this, splitting it to the inode level no longer makes sense.
> So I can see two sensible solutions here:
> a) Drop streaming allocations support altogether.
As mentioned above, it can also greatly improve the efficiency of linear
traversal, so we can't simply remove it.
>
> b) Enhance streaming allocation support to avoid contention between
> processes allocating in parallel and freeing. Frankly, there's no strong
> reason why reads & writes of streaming allocation goal need to use a
> spinlock AFAICS.
Yes, since it's just a hint, we don't need a lock at all, not even
fe_start, we just need the last fe_group.
> We could just store a physical block number and use
> atomic64 accessors for it? Also having single goal value is just causing
> more contention on group locks for parallel writers that end up using it
> (that's the problem I suspect you were hitting the most).
Spot on! We did try a single, lockless atomic64 variable, and just as
you pointed out, all processes started traversing from the very same
group, which just cranked up the contention, dropping OPS to just 6745.
> So perhaps we
> can keep multiple streaming goal slots in the superblock (scale the count
> based on CPU count & filesystem group count) and just pick the slot based
> on inode number hash to reduce contention?
>
> Honza
That's a brilliant idea, actually!
Since most containers are CPU-pinned, this would naturally cluster a single
container's data blocks together. I believe we can also apply this to inode
allocation, so a container's inodes and data are all in a single region,
significantly reducing interference between containers.
My gratitude for your valuable suggestion!
I'm going to try out the CPU bucketing approach.
Regards,
Baokun
>> ---
>> fs/ext4/ext4.h | 7 ++++---
>> fs/ext4/mballoc.c | 20 +++++++++-----------
>> fs/ext4/super.c | 2 ++
>> 3 files changed, 15 insertions(+), 14 deletions(-)
>>
>> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
>> index 9c665a620a46..16c14dd09df6 100644
>> --- a/fs/ext4/ext4.h
>> +++ b/fs/ext4/ext4.h
>> @@ -1171,6 +1171,10 @@ struct ext4_inode_info {
>> __u32 i_csum_seed;
>>
>> kprojid_t i_projid;
>> +
>> + /* where last allocation was done - for stream allocation */
>> + ext4_group_t i_mb_last_group;
>> + ext4_grpblk_t i_mb_last_start;
>> };
>>
>> /*
>> @@ -1603,9 +1607,6 @@ struct ext4_sb_info {
>> unsigned int s_mb_order2_reqs;
>> unsigned int s_mb_group_prealloc;
>> unsigned int s_max_dir_size_kb;
>> - /* where last allocation was done - for stream allocation */
>> - unsigned long s_mb_last_group;
>> - unsigned long s_mb_last_start;
>> unsigned int s_mb_prefetch;
>> unsigned int s_mb_prefetch_limit;
>> unsigned int s_mb_best_avail_max_trim_order;
>> diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
>> index 5c13d9f8a1cc..ee9696f9bac8 100644
>> --- a/fs/ext4/mballoc.c
>> +++ b/fs/ext4/mballoc.c
>> @@ -2138,7 +2138,6 @@ static int mb_mark_used(struct ext4_buddy *e4b, struct ext4_free_extent *ex)
>> static void ext4_mb_use_best_found(struct ext4_allocation_context *ac,
>> struct ext4_buddy *e4b)
>> {
>> - struct ext4_sb_info *sbi = EXT4_SB(ac->ac_sb);
>> int ret;
>>
>> BUG_ON(ac->ac_b_ex.fe_group != e4b->bd_group);
>> @@ -2169,10 +2168,8 @@ static void ext4_mb_use_best_found(struct ext4_allocation_context *ac,
>> folio_get(ac->ac_buddy_folio);
>> /* store last allocated for subsequent stream allocation */
>> if (ac->ac_flags & EXT4_MB_STREAM_ALLOC) {
>> - spin_lock(&sbi->s_md_lock);
>> - sbi->s_mb_last_group = ac->ac_f_ex.fe_group;
>> - sbi->s_mb_last_start = ac->ac_f_ex.fe_start;
>> - spin_unlock(&sbi->s_md_lock);
>> + EXT4_I(ac->ac_inode)->i_mb_last_group = ac->ac_f_ex.fe_group;
>> + EXT4_I(ac->ac_inode)->i_mb_last_start = ac->ac_f_ex.fe_start;
>> }
>> /*
>> * As we've just preallocated more space than
>> @@ -2844,13 +2841,14 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
>> MB_NUM_ORDERS(sb));
>> }
>>
>> - /* if stream allocation is enabled, use global goal */
>> + /* if stream allocation is enabled, use last goal */
>> if (ac->ac_flags & EXT4_MB_STREAM_ALLOC) {
>> - /* TBD: may be hot point */
>> - spin_lock(&sbi->s_md_lock);
>> - ac->ac_g_ex.fe_group = sbi->s_mb_last_group;
>> - ac->ac_g_ex.fe_start = sbi->s_mb_last_start;
>> - spin_unlock(&sbi->s_md_lock);
>> + struct ext4_inode_info *ei = EXT4_I(ac->ac_inode);
>> +
>> + if (ei->i_mb_last_group || ei->i_mb_last_start) {
>> + ac->ac_g_ex.fe_group = ei->i_mb_last_group;
>> + ac->ac_g_ex.fe_start = ei->i_mb_last_start;
>> + }
>> }
>>
>> /*
>> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
>> index 181934499624..6c49c43bb2cb 100644
>> --- a/fs/ext4/super.c
>> +++ b/fs/ext4/super.c
>> @@ -1416,6 +1416,8 @@ static struct inode *ext4_alloc_inode(struct super_block *sb)
>> INIT_WORK(&ei->i_rsv_conversion_work, ext4_end_io_rsv_work);
>> ext4_fc_init_inode(&ei->vfs_inode);
>> mutex_init(&ei->i_fc_lock);
>> + ei->i_mb_last_group = 0;
>> + ei->i_mb_last_start = 0;
>> return &ei->vfs_inode;
>> }
>>
>> --
>> 2.46.1
>>
Return-Path: <linux-kernel+bounces-667880-lkml=lkml.rescloud.iu.edu@xxxxxxxxxxxxxxx>
X-Original-To: lkml@xxxxxxxxxxxxxxxxxxxx
Delivered-To: lkml@xxxxxxxxxxxxxxxxxxxx
Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org [147.75.199.223])
by lkml.rescloud.iu.edu (Postfix) with ESMTPS id ED9AE41E003FA
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 05:35:29 -0400 (EDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by ny.mirrors.kernel.org (Postfix) with ESMTPS id 2BBA64A405B
for <lkml@xxxxxxxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:35:31 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id E79F322C355;
Fri, 30 May 2025 09:32:22 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b="TkX8S0ml"
Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182])
(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 C1094224B1C
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 09:32:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.182
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1748597541; cv=none; b=ZTQlDlu4DzxOGzpQoTZh3kYbRjTI7uMnWQw3rRwIYo3xMTITulRIvM6158JNxSYeIEdLLSJ49QuPkrjHJ4LJcFNXSA8HNCM4lKByAwSpTGi6jl6RKEMxEkTnZi0swjI8fdEmp/Hf17xn5U6BM5bwmK536cEohNLtNDig6epyBYk=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1748597541; c=relaxed/simple;
bh=Vo5W68+B44KDyLABkBRZQtt4MP6EbodSR8b0dyMCe9I=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version; b=pIzvE0SS9VaQbKpvr3Aegn5oPePLJbixR7Ofr3wBiivBOKs7jZ+4pzrx6Deu6R+pSKqu8S1Gf7Mwq9SplhTNXKEnxG69OLQ1B+f8unywtTkaMCW/+2J/WapMRTuGmHlivHnH9XlC48z9BHGste2YERI5YYixvgoPP56leRB7e1E=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass (2048-bit key) header.d=bytedance.com header.i=@bytedance.com header.b=TkX8S0ml; arc=none smtp.client-ip=209.85.215.182
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com
Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-b26f5f47ba1so1205977a12.1
for <linux-kernel@xxxxxxxxxxxxxxx>; Fri, 30 May 2025 02:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bytedance.com; s=google; t=1748597537; x=1749202337; darn=vger.kernel.org;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=WgdxFQILtv1ZFBwGDlokBNLY9DZwyLg+1V8wfJcAxqs=;
b=TkX8S0mlzQALs9Xd5nJpstems/lEQiViliadNUqZ4Vy8VoDCAE5kciPed4kmjZLKad
n8hB45Jt3bYVFXCyFT5oyZz4lK1WLpSj5Fc4MxtiO2L4EGIFb8jmcYRiccXd2tLquT7B
BRHHWEKNw6hlh2CQoq2nyx+qZm+F00Y9/x74H99SsxNixZDyvF13Fhp+iLENW8YOIwKO
Ki8SkEP9Qe9OTkoCcdoZKTBKAAzCdYnz06HFG8XOP7N+0ymzkVd9OGk3pnex18I7Vq9Y
TyxCukQA/nk4bq6n4UCJ9LJ8de/svHiuUk4FzIYNo4r0Aj0tiwYsGugLD0GS90z1O7Kb
GdBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748597537; x=1749202337;
h=content-transfer-encoding:mime-version:references:in-reply-to
:message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=WgdxFQILtv1ZFBwGDlokBNLY9DZwyLg+1V8wfJcAxqs=;
b=Yd5wejABTjHSe3GHpFh1aEomkcyBe9fkuBF7nHSSgV9USIvSXucmNZaHyFn5YM97Y7
aDRW1naLaVm3S146r4XUtPB2N1y5e3nyiCOLI+cy1ec1MYVrxUgCXPSr+xyZ6omshOUq
63wox9RsXQ67IqB3eIEOFRCXtrv5RrrfWK8YCvk8c1X/qbLL7A1ut0Z4PTcmeIRJ0iqk
eGLDu2YpYI+jhP4+6WxYYbDLqWOXRiD9NUkOETGdN4g0AyqjTlM73gDz/cXfpwoi3rHh
9bMPM8k2SuNiHb23u5lo02ImOatV/vItwH2cXyFYmjogVgmkJcSuPfgIGSj3Rv7QTJHT
zj0A==
X-Forwarded-Encrypted: i=1; AJvYcCUMV1bA3TEWC+dU78v7+5nNMjxrfkR0VXkqxp1cyHaNc12s2fMnVhk7wbuA0ymfPpk+ahsMRhEKGm8rgZI=@vger.kernel.org
X-Gm-Message-State: AOJu0YxLfgnDdzVp71Iw7DhMy4qKP+NAePwtk++0BTqbo9uWAaQR5Wnu
AgHfLBxSiL+jEfMmvQCRLxRXmfJh2N5JLDIjhHUBn83j1IzdnYE0lm/uP0OT9RkdBSg=
X-Gm-Gg: ASbGncuuvwxKxuOAkqt+uuGv9F58Nr5ylwFQOAc9I6gXRv7LOtV3qOQDSTMwZ9GZ8vi
/IcIsNvwgrSJTdmwuP5eebN3zF5Hnl6ninaoRkmD0d2bHytyF4yq2Ux2wqEhqVZU3DYhE8ZFjgA
B+1IBsieNj70Lzsox9JkGgoyJM5MzeQnQJzscrEYZuV4kuH7/eEqmjmUu6rFFgGUMk3q4YTv+4/
yVP+z3z2o7YUaQ1CQW/cHaOeJ5p40PPlDN5CHYZN9p/rj/9a7gcfwj1nx/u7pkZo5mJjUVGIksz
JdmLDLBFWAu0T/LrJqZ0rm2eyGKHwBg7Xp8dbkRAIDQ+gz5Pd9NNnV2HgjEGR7sbxwL1ISwUsh1
Bxa8KTVip6g==
X-Google-Smtp-Source: AGHT+IEJreThnxFmdrlfjlpwKZv59IFtRtCaH2wQICekYkicVpLMTveAapFUeJrWIU6RsHlorrZhig==
X-Received: by 2002:a17:90b:314d:b0:311:c1ec:7d0c with SMTP id 98e67ed59e1d1-312504437b2mr2132223a91.27.1748597536883;
Fri, 30 May 2025 02:32:16 -0700 (PDT)
Received: from FQ627FTG20.bytedance.net ([63.216.146.178])
by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3124e29f7b8sm838724a91.2.2025.05.30.02.32.02
(version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256);
Fri, 30 May 2025 02:32:16 -0700 (PDT)
From: Bo Li <libo.gcs85@xxxxxxxxxxxxx>
To: tglx@xxxxxxxxxxxxx,
mingo@xxxxxxxxxx,
bp@xxxxxxxxx,
dave.hansen@xxxxxxxxxxxxxxx,
x86@xxxxxxxxxx,
luto@xxxxxxxxxx,
kees@xxxxxxxxxx,
akpm@xxxxxxxxxxxxxxxxxxxx,
david@xxxxxxxxxx,
juri.lelli@xxxxxxxxxx,
vincent.guittot@xxxxxxxxxx,
peterz@xxxxxxxxxxxxx
Cc: dietmar.eggemann@xxxxxxx,
hpa@xxxxxxxxx,
acme@xxxxxxxxxx,
namhyung@xxxxxxxxxx,
mark.rutland@xxxxxxx,
alexander.shishkin@xxxxxxxxxxxxxxx,
jolsa@xxxxxxxxxx,
irogers@xxxxxxxxxx,
adrian.hunter@xxxxxxxxx,
kan.liang@xxxxxxxxxxxxxxx,
viro@xxxxxxxxxxxxxxxxxx,
brauner@xxxxxxxxxx,
jack@xxxxxxx,
lorenzo.stoakes@xxxxxxxxxx,
Liam.Howlett@xxxxxxxxxx,
vbabka@xxxxxxx,
rppt@xxxxxxxxxx,
surenb@xxxxxxxxxx,
mhocko@xxxxxxxx,
rostedt@xxxxxxxxxxx,
bsegall@xxxxxxxxxx,
mgorman@xxxxxxx,
vschneid@xxxxxxxxxx,
jannh@xxxxxxxxxx,
pfalcato@xxxxxxx,
riel@xxxxxxxxxxx,
harry.yoo@xxxxxxxxxx,
linux-kernel@xxxxxxxxxxxxxxx,
linux-perf-users@xxxxxxxxxxxxxxx,
linux-fsdevel@xxxxxxxxxxxxxxx,
linux-mm@xxxxxxxxx,
duanxiongchun@xxxxxxxxxxxxx,
yinhongbo@xxxxxxxxxxxxx,
dengliang.1214@xxxxxxxxxxxxx,
xieyongji@xxxxxxxxxxxxx,
chaiwen.cc@xxxxxxxxxxxxx,
songmuchun@xxxxxxxxxxxxx,
yuanzhu@xxxxxxxxxxxxx,
chengguozhu@xxxxxxxxxxxxx,
sunjiadong.lff@xxxxxxxxxxxxx,
Bo Li <libo.gcs85@xxxxxxxxxxxxx>
Subject: [RFC v2 15/35] RPAL: add sender/receiver state
Date: Fri, 30 May 2025 17:27:43 +0800
Message-Id: <6582d600063dd2176558bdf2b62a6a143bd594e2.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
X-Mailer: git-send-email 2.39.5 (Apple Git-154)
In-Reply-To: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
References: <cover.1748594840.git.libo.gcs85@xxxxxxxxxxxxx>
Precedence: bulk
X-Mailing-List: linux-kernel@xxxxxxxxxxxxxxx
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@xxxxxxxxxxxxxxx>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@xxxxxxxxxxxxxxx>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,
RCVD_IN_VALIDITY_RPBL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lkml.rescloud.iu.edu
The lazy switch defines six receiver states, and their state transitions
are as follows:
|<--->READY<----> WAIT <----> CALL ----> LAZY_SWITCH ---> KERNEL_RET
| | |
RUNNING <----------------------------------------|---------------|
The receiver thread initially starts in the RUNNING state and can
transition to the WAIT state voluntarily. The READY state is a temporary
state before entering WAIT state. For a receiver in the WAIT state, it
must be in the TASK_INTERRUPTIBLE state. If the receiver thread is woken
up, the WAIT state can transition to the RUNNING state.
Once the receiver is in the WAIT state, the sender thread can
initiate an RPAL call, causing the receiver to enter the CALL state. A
receiver thread in the CALL state cannot be awakened until a lazy switch
occurs or its state changes. The call state carries additional service_id
and sender_id information.
If the sender completes executing the receiver's code without entering the
kernel after issuing the RPAL call, the receiver transitions back from the
CALL state to the WAIT state. Conversely, if the sender enters the kernel
during the RPAL call, the receiver's state changes to LAZY_SWITCH.