From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) (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 A8C69313273 for ; Thu, 20 Nov 2025 13:01:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.188 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763643700; cv=none; b=SonAim2Hq6sDwl7tVvh2j3HRQ4zJ6Vj1gGi2wTmmdesW1+D1A0a+qmtx4QZUQdzLf9HmvEsuZ/zsxlmIZpiNammU4xgEfIap0OaDeEGnwtSNkLXFckQR5QMYf1/2THTvRWNNfQkhhPeO4MNWNyDu6k0U204zrXLA80Nt+QfeFOE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763643700; c=relaxed/simple; bh=Ftl+qpQGrT5RpptKkItPeER581J88Xp+vWYHK5zRZgQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Fu0G4/zgpabHNV8BI1Wmjvq185jdOJOd37Va6hHKEj1PFbbhU1hHCmED9D2EjwXwN3mMu3g91zgjRMP1ijCvj0g7lWIby5Y5hCJpY/nsYgT1+/yllre2buZh71jVnFwN3J4DxOmiIu+ahlHWLnyWrVpVeyUSU8X/HQpTkg3RUHU= 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=usJJd61n; arc=none smtp.client-ip=95.215.58.188 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="usJJd61n" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1763643685; 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=Appw5O9xn9vKWf0A+16v30yLtvA63IpanK+xECauBoM=; b=usJJd61nfgOrgJv9VkEZ3PMKtrtJaJEjNlVH8RWyyQmyKQb+9SiV7pZ0w1OZPZ1n9HBCc9 xoFEYp8owtU2QvVmNzWY2cX9h/gQJ517YAyli+xGAvQDmkG+LAEU3kpCek5pkniDCNt3vG saFS6TwzqYvcFwtasFMFWmyOzqAjkI0= Date: Thu, 20 Nov 2025 21:01:11 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH V2 1/2] mm/khugepaged: do synchronous writeback for MADV_COLLAPSE Content-Language: en-US To: Shivank Garg Cc: Zi Yan , Baolin Wang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Steven Rostedt , David Hildenbrand , Masami Hiramatsu , Mathieu Desnoyers , Zach O'Keefe , linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Branden Moore , Lorenzo Stoakes References: <20251120065043.41738-6-shivankg@amd.com> <20251120065043.41738-8-shivankg@amd.com> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: <20251120065043.41738-8-shivankg@amd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2025/11/20 14:50, Shivank Garg wrote: > When MADV_COLLAPSE is called on file-backed mappings (e.g., executable > text sections), the pages may still be dirty from recent writes and > cause collapse to fail with -EINVAL. This is particularly problematic > for freshly copied executables on filesystems, where page cache folios > remain dirty until background writeback completes. > > The current code in collapse_file() triggers async writeback via > filemap_flush() and expects khugepaged to revisit the page later. > However, MADV_COLLAPSE is a synchronous operation where userspace > expects immediate results. > > Perform synchronous writeback in madvise_collapse() before attempting > collapse to avoid failing on first attempt. Thanks! > > Reported-by: Branden Moore > Closes: https://lore.kernel.org/all/4e26fe5e-7374-467c-a333-9dd48f85d7cc@amd.com > Fixes: 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE") > Suggested-by: David Hildenbrand > Signed-off-by: Shivank Garg > --- > mm/khugepaged.c | 26 ++++++++++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 97d1b2824386..066a332c76ad 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -22,6 +22,7 @@ > #include > #include > #include > +#include > > #include > #include "internal.h" > @@ -2784,6 +2785,31 @@ int madvise_collapse(struct vm_area_struct *vma, unsigned long start, > hstart = (start + ~HPAGE_PMD_MASK) & HPAGE_PMD_MASK; > hend = end & HPAGE_PMD_MASK; > > + /* > + * For file-backed VMAs, perform synchronous writeback to ensure > + * dirty folios are flushed before attempting collapse. This avoids > + * failing on the first attempt when freshly-written executable text > + * is still dirty in the page cache. > + */ > + if (!vma_is_anonymous(vma) && vma->vm_file) { > + struct address_space *mapping = vma->vm_file->f_mapping; > + > + if (mapping_can_writeback(mapping)) { > + pgoff_t pgoff_start = linear_page_index(vma, hstart); > + pgoff_t pgoff_end = linear_page_index(vma, hend); > + loff_t lstart = (loff_t)pgoff_start << PAGE_SHIFT; > + loff_t lend = ((loff_t)pgoff_end << PAGE_SHIFT) - 1; It looks like we need to hold a reference to the file here before dropping the mmap lock :) file = get_file(vma->vm_file); Without it, the vma could be destroyed by a concurrent munmap() while we are waiting in filemap_write_and_wait_range(), leading to a UAF on mapping, IIUC ... > + > + mmap_read_unlock(mm); > + mmap_locked = false; > + > + if (filemap_write_and_wait_range(mapping, lstart, lend)) { And drop the reference :) fput(file); > + last_fail = SCAN_FAIL; > + goto out_maybelock; > + } Same here :) fput(file); > + } > + } > + > for (addr = hstart; addr < hend; addr += HPAGE_PMD_SIZE) { > int result = SCAN_FAIL; > Cheers, Lance