From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) (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 4D885372056 for ; Wed, 13 May 2026 01:24:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778635483; cv=none; b=ZQ+/onFMjCs5kgszGtX7Ofmq+bNA5v+tGLBCvLDibbOKbfU/ssM6ZDrSfxlUOTgXL65ZuzdwA106WroK7yC2U8bmGUcRPicR9gBfB1d24pVnpCBJYVn4YOOfVdqNJp9EMMgw98/SPK8+86V48te4RjHmPG0HdkRjyRncwbt6xOU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778635483; c=relaxed/simple; bh=V//WEgvYvOtQzork1SgoHWYWyLIW2uok/IJueBniAeU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Message-Id:References:To; b=ZRJXHFTeFegZDFrwV1TN+mhxh+a9F91TWHiah+yNq5BCl5pK8XWViui5pezQogLuAiRvJYJs+s/6Y6izLqDCfqUYmDDlnNHi9m/cqEl88aEvKPjwn160zhkZVKzqW8+A6t93eyQDaoZM/JmzenJEd2MiNQLtp6By4DRJTPBHWGk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=MmLYRPKS; arc=none smtp.client-ip=95.215.58.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="MmLYRPKS" Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1778635473; 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; bh=V//WEgvYvOtQzork1SgoHWYWyLIW2uok/IJueBniAeU=; b=MmLYRPKSxaHspbs3HhvziuF1lVZKSQrugOXH7GXQuYOPxbxGWC+uamUsGqsqb00PbnziHp Y+eXsc1BwbO3MM2k7SWKWzm3AlB6OGteDf7za+X2nvhyfAjt0Xl3uE+FtR2b4zwLCHb7Wx 066H2ekrgGPlJ1Z3/q93irgSGVlFA6o= Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) Subject: Re: [PATCH] Revert "mm/hugetlbfs: update hugetlbfs to use mmap_prepare" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20260512160643.266960-1-ljs@kernel.org> Date: Wed, 13 May 2026 09:23:51 +0800 Cc: Andrew Morton , Oscar Salvador , David Hildenbrand , Pedro Falcato , "Liam R . Howlett" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <732AB0FD-230B-4160-9C6E-5CF7F5FFD737@linux.dev> References: <20260512160643.266960-1-ljs@kernel.org> To: Lorenzo Stoakes X-Migadu-Flow: FLOW_OUT > On May 13, 2026, at 00:06, Lorenzo Stoakes wrote: >=20 > This reverts commit ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to = use > mmap_prepare") with conflict resolution to account for changes in = commit > ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use mmap_prepare"). >=20 > The patch incorrectly handled hugetlb VMA lock allocation at the > mmap_prepare stage, where a failed allocation occurring after = mmap_prepare > is called might result in the lock leaking. >=20 > There is no risk of a merge causing a similar issues, as = VMA_DONTEXPAND_BIT > is set for hugetlb mappings. >=20 > As a first step in addressing this issue, simply revert the change so = we > can rework how we do this having corrected the underlying issues. >=20 > We maintain the VMA flags changes as best we can, accounting for the = fact > that we were working with a VMA descriptor previously and propagating > like-for-like changes for this. >=20 > Note that we invoke vma_set_flags() and do not call vma_start_write() = as > vm_flags_set() does. This is OK as it's being done in an .mmap hook = where > the VMA is not yet linked into the tree so nobody else can be = accessing it. >=20 > Fixes: ea52cb24cd3f ("mm/hugetlbfs: update hugetlbfs to use = mmap_prepare") > Reported-by: Mingyu Wang <25181214217@stu.xidian.edu.cn> > Closes: = https://lore.kernel.org/linux-mm/20260425070700.562229-1-25181214217@stu.x= idian.edu.cn/ > Cc: > Signed-off-by: Lorenzo Stoakes Acked-by: Muchun Song Thanks.