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 612153A0EA6 for ; Wed, 10 Jun 2026 20:30:03 +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=1781123404; cv=none; b=mrN/PHjVnL5zgynYKqcHo21IRxvX8lYeuQGKGV8SoLklAzdHVKIScD62Iki/HUcZ0AX4TgVzskFlOE2xYKfaW10+CvfZszY0Gy7FF0Zj81LYIx4oKKsFwiSsCn4YgAeQonMuFrGhWY/CSHOF1wtiVIg1VORRRFi5vHLbhN8RJKE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781123404; c=relaxed/simple; bh=AlWGC7EyUbvrdREyrcFsqLyl4UNjypYHQfU5++/N7gk=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=hskFbwiNdmnWgAByzlkxEOw0ix8P392+M82KWPbC0uKBJMU1srpxHmqmK8OTffhV54mOt+rE2kydU4p9t1L1KjiKPwPqnd5xR+36njV+BPkjorbufriyRIurrjMaIYYVwbars64Vyx3Jzcw8+5frszYT4JVv3U8MEZf+lJV8qto= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=y7RNisUK; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="y7RNisUK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 883721F00893; Wed, 10 Jun 2026 20:30:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1781123403; bh=MgCn5Wxf+Irho0mKTHH0dDK8u5CVGsf6qFgr8U0oMWw=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=y7RNisUK62V0jAffUfNT+LXxlH8Q2iVR/V5651z4ZI6WJBb+ttUACVits6mh1As9e GwOZGq6p4Vt3g25I3lWlu7fewuV2Ej8AC1bSXL5n0zDTdHOKMR3C9qcprAJbiFA/5D MKfWVZsGnRY+K9LLKotfDh50px1hqVaoXV7iDegM= Date: Wed, 10 Jun 2026 13:30:02 -0700 From: Andrew Morton To: "zhaoyang.huang" Cc: David Hildenbrand , Zi Yan , Lorenzo Stoakes , Barry Song , Baolin Wang , Lance Yang , "Liam R . Howlett" , Nico Pache , Ryan Roberts , Dev Jain , , , Zhaoyang Huang , Subject: Re: [RFC PATCH] mm/huge_memory: do not add dropped split tail folios to LRU Message-Id: <20260610133002.4ded8d8cdc8e23e434fedf1a@linux-foundation.org> In-Reply-To: <20260610120535.2370844-1-zhaoyang.huang@unisoc.com> References: <20260610120535.2370844-1-zhaoyang.huang@unisoc.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Wed, 10 Jun 2026 20:05:35 +0800 "zhaoyang.huang" wrote: > From: Zhaoyang Huang > > The kernel panics are keeping to be reported especially when the f2fs > partition get almost full. By investigation, we find that the reason is > one f2fs page got freed to buddy without being deleted from LRU and the > root cause is the race happened in [2] which is enrolled by this commit. > We solve this issue by reverting a f2fs commit 9609dd704725 ("f2fs: remove > non-uptodate folio from the page cache in move_data_block"). > > There are 3 race processes in this scenario, please find below for their > main activities. However, by further investigation over the code, I > think there is a common race window for the truncated folios between > split_folio_to_order and folio_isolate_lru, where the folios lost the > refcount on page cache and remains the transient one of the split > caller, under which the folio could enter free path and compete with the > isolation process. This commit would like to suggest to have the folios > beyond EOF stay out of LRU. > > Truncate: > The changed code in move_data_block() lets the GC path evict the tail-end > folio from the page cache through folio_end_dropbehind(). Once > folio_unmap_invalidate() removes the folio from mapping->i_pages, the > page-cache references for all pages in the folio are dropped. The folio > is then kept alive only by temporary external references, which allows a > later split to operate on a folio whose subpages are no longer protected > by page-cache references. > > Split: > After the page-cache references are gone, split_folio_to_order() can > split the big folio into individual pages and put the resulting subpages > back on the LRU. For tail pages beyond EOF, split removes them from the > page cache and drops their page-cache references. A tail page can then > remain on the LRU with PG_lru set while holding only the split caller's > temporary reference. When free_folio_and_swap_cache() drops that final > reference, the page enters the final folio_put() release path. > > Isolate: > In parallel, folio_isolate_lru() can observe the same tail page with a > non-zero refcount and PG_lru set. It clears PG_lru before taking its own > reference. If this races with the final folio_put() from the split path, > __folio_put() sees PG_lru already cleared and skips lruvec_del_folio(). > The page is then freed back to the allocator while its lru links are > still present in the LRU list. A later LRU operation on a neighboring > page detects the stale link and reports list corruption. Thanks. Sashiko AI review might have found some problems with folio flags: https://sashiko.dev/#/patchset/20260610120535.2370844-1-zhaoyang.huang@unisoc.com