From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 81325330650 for ; Sat, 11 Jul 2026 08:47:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783759641; cv=none; b=lWtI6nNW/tBg67Go9qlcpsQGQyQwmnVnq8T1RlZPShBpGhbqR88BUcgg+lfulSvYIsOK8ZXrDOwo7xiMgF2OGxu+v3D9igyx6TymxAWu7UqUuxOYqud5KeagSs6THFSEsi/tIdrVjQn/QnE6WS72E939JyOc7KWYPkzEma8lCrY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783759641; c=relaxed/simple; bh=dqw2Z+x8qWJybmcXiUvh6JGW05CQ78tnnq6ADpvGIiY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=elWQZAaK6UoTRAZ60Se4MF6Dlyicin6S1TGxhebszF1Pll/AfTMUxXHJ4Vk1sK1uHGvBFLx2KyJlSkizKiRD7NWQle0oMZ2IQN8pg2EVbdC7bfrE/LTSmthgawRn+6xq0NXoyqPrPWJVIYk/m9JjqV3ytQdS/yuKUTjzqPDjJqo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e0MGToar; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e0MGToar" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C1561F000E9; Sat, 11 Jul 2026 08:47:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783759640; bh=QHQp9w2ggknuYjtZUaGm/34wvYegysaIeYER812wVyE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=e0MGToarq6ESWZMk3rknfku5uzZ/pv6MW3MfcvOnv3fq3GptUSOs1neiTjSgD+YSE V2YFCfCq5tFyXouF7MOnlmio1vMJVFFIz1PAaNojIq9m45vC64vmrrgLaZoAjQ7Qbr Ym2MXXPoIe2Jaqz2q3SSuc40Pw1mCm+3juxy/p9hg6qgsYjhv2olkAVU/keYFG2qiS j3lljftbogZ8E5IAx0vsui/2OgO5a+6VVVfNgJcJOhs1PfIDkI0obOmjOiWr17i9y0 6dnIW2zEeG4sFa+WVJ5ZASHPMATOzt1aW32MqDYLRmDVdMSVgbrjEQr+RIfUPnJDxp hS0W6luu+lWig== Date: Sat, 11 Jul 2026 11:47:11 +0300 From: Mike Rapoport To: Dave Hansen Cc: "Denis V. Lunev" , "Denis V. Lunev" , Dave Hansen , Andy Lutomirski , Peter Zijlstra , x86@kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Juergen Gross , Kiryl Shutsemau , linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86/mm/pat: take cpa_lock around large-page collapse Message-ID: References: <20260626163213.2284080-1-den@openvz.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Jul 10, 2026 at 10:15:54AM -0700, Dave Hansen wrote: > cpa_collapse_large_pages() seems to be a never ending source of bugs. Yeah, this one, the race with ptdump and a year old issue on Xen PV. There might be more of course but I wouldn't call it endless. > I'm tempted to say we should just axe it, call it a failed experiment, > and move on with life. > > Is it worth keeping? This what lets keeping executable mappings in 2M granularity. Modules, ftrace and kprobes are already using it and BPF is on the way: https://lore.kernel.org/bpf/20260626-execmem-x86-rox-bpf-v0-v1-0-45a0b0ed4fe9@kernel.org/ -- Sincerely yours, Mike.