From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-35.mta1.migadu.com [95.215.58.35]) (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 95C4537E5DE for ; Fri, 16 Oct 2026 03:23:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.35 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792120998; cv=none; b=I4d8GTNvxaphxC9wbfDjUnLD7gIiSfspaH8n+5z6btS2l1JdJWZ3AAXLEc9uVlZjXw1Hm8ibI2fA5fjPP2XZX4S9Kl4lq97L0btgJbIZlxSoYL66KoBbsXPegjREAVvaqfu4iWTQuRnWIoM/1gd/UIte635WLvejW+7pslGAGZM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1792120998; c=relaxed/simple; bh=n105cAOrmvacSuxJV1gCXAOncQUE7phVtbmqqTEizuA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=e3GUKL7LOu7HS1QrxI4sU+x+NI6rrk5tg7Vy+tAjpvppM5NZpfA7bKYQ8uLPxrlnIivKG9GjKREFdQcyo80lKxQKhP2IqON4AKHTbKA7nw+ytXraWY96XVplaFyH8cze9cjkrN0CjIhRraKf+Gin9rSNpruugnvI6bKpTnyxDCk= 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=vLSgXi2H; arc=none smtp.client-ip=95.215.58.35 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="vLSgXi2H" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=n105cAOrmvacSuxJV1gCXAOncQUE7phVtbmqqTEizuA=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1792120993; v=1; x=1792725793; b=vLSgXi2HFcPWGFZHyWqR7CzzUbxtfiPkxNictNCq+2DaXzqIJ33NlwInHZdC6DnAO5F3fZMC 5y9loVWYw8bhTiXODz3frE8xBs/t6Bu5sjgo/Sz8qJHH2j06TOIG/gppeA5afSKD6GSHR+Je4KO laOSIuLcmkXMwPc1DsV5Gph8= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id e7b0a4f9dcce94b9; Fri, 16 Oct 2026 03:23:12 +0000 X-Mizu-Trace-ID: e7b0a4f9dcce94b9 X-Migadu-Flow: FLOW_OUT Message-ID: <96276015-a1fa-40ef-9780-867652d7b11f@linux.dev> Date: Fri, 16 Oct 2026 11:23:04 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] mm: memory: fix truncation removing mapped folios To: Baolin Wang , akpm@linux-foundation.org, david@kernel.org Cc: ljs@kernel.org, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, jack@suse.cz, pfalcato@suse.de, ayushr@modal.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 10/16/26 9:48 AM, Baolin Wang wrote: > Ayush reported an issue that shmem/tmpfs folios are still mapped when > truncating them on production: > " > BUG: Bad page cache in process ... pfn:... > page dumped because: still mapped when deleted > " > > I reproduced the issue with Ayush's reproducer [1] with the latest mm-unstable > branch, and I got the following crash info. From the dump message, we can > see that truncate_inode_folio() is really trying to remove mapped folios, > which is incorrect. > > " > [ 189.171977] page: refcount:3 mapcount:1 mapping:00000000fe168ee1 > index:0x3880 pfn:0x191647 > [ 189.171995] memcg:ffff0000cc073d40 > [ 189.171997] aops:shmem_aops ino:3c01 dentry name(?):"memfd:runsc-memory" > [ 189.172006] flags: 0x17fffef0002022d(locked|referenced|uptodate|lru| > workingset|swapbacked|node=0|zone=2|lastcpupid=0x3ffff) > ....... > [ 189.172017] page dumped because: VM_BUG_ON_FOLIO(folio_mapped(folio)) > [ 189.172026] ------------[ cut here ]------------ > [ 189.172027] kernel BUG at mm/filemap.c:155! > [ 189.172057] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP > ....... > [ 189.177721] CPU: 3 UID: 0 PID: 5521 Comm: repro Kdump: loaded Tainted: > 7.3.0-rc4+ #277 PREEMPT(lazy) > ....... > [ 189.183986] Call trace: > [ 189.184124] filemap_unaccount_folio+0xf0/0x1e8 (P) > [ 189.184391] __filemap_remove_folio+0x34/0x160 > [ 189.184633] filemap_remove_folio+0x4c/0xb0 > [ 189.184859] truncate_inode_folio+0x34/0x58 > [ 189.185087] shmem_undo_range+0x220/0x658 > [ 189.185308] shmem_fallocate+0x2f0/0x470 > [ 189.185527] vfs_fallocate+0x128/0x328 > ...... > [ 189.187078] el0t_64_sync+0x184/0x188 > " > > After analysis, I believe the race exists between truncation and MADV_DONTNEED, > and shmem's ->map_pages() merely makes the issue easier to reproduce. Since > MADV_DONTNEED synchronously releases the pagetable page before calling > tlb_flush_rmaps(), this could cause another thread's truncation to skip > zap_pte_range() (due to pmd is none) but still observe the folio's mapcount > as non-zero. A possible race scenario is as follows: > > CPU 0 CPU 1 > shmem_fallocate madvise_dontneed_single_vma > unmap_mapping_range ....... > ...... > (filemap_map_pages() remap folios) > zap_pte_range > truncate_inode_folio zap_empty_pte_table(pmd clear) > unmap_mapping_folio > ...... > zap_pmd_range (saw pmd none, skip) > > filemap_remove_folio > BUG_ON(folio_mapped) > tlb_flush_rmaps(remove rmaps) > > To fix this issue, we should move the pmd clear operation (via zap_empty_pte_table()) > to after tlb_flush_rmaps() and use sync_with_folio_pmd_zap() to sync with > concurrent zapping, so that when we find a pmd_none() while unmapping a folio > without holding the PTL, the folio's mappings are guaranteed to have been > removed via tlb_flush_rmaps(). > > [1] https://lore.kernel.org/all/20260925065013.3682431-1-ayushr@modal.com/ > Reported-by: Ayush Ranjan > Closes: https://lore.kernel.org/all/20260924061708.1645968-1-ayushr@modal.com/ > Fixes: 6375e95f381e ("mm: pgtable: reclaim empty PTE page in madvise(MADV_DONTNEED)") > Signed-off-by: Baolin Wang > --- > Changes from v2: > - Use use sync_with_folio_pmd_zap() to sync with concurrent zapping (Per David). > Changes from v1: > - Add an smp_rmb() to pair with the smp_wmb() (Per Lorenzo and Pedro). > --- > mm/internal.h | 9 +++++---- > mm/memory.c | 25 ++++++++++++------------- > 2 files changed, 17 insertions(+), 17 deletions(-) Thanks for the fix! Acked-by: Qi Zheng