From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lgeamrelo12.lge.com (lgeamrelo12.lge.com [156.147.23.52]) (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 E7D0F19F115 for ; Sun, 9 Aug 2026 03:59:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=156.147.23.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786248000; cv=none; b=WB9IwdMTv0AhZYQNskkzgJOgRhz9ebH8neda74q6qpAL5oO1wWHEKpzDOAUGk1w2gK3X5wA1FpJk/C7OKVr6Fk1NRZMWtSPDITH5dsrMufLz87+1/AzQvqOlNOKcM/omNT1aSGU5nKGqnm7Ho3d3WRlRkRmhH5gGYNtZX5JKtBw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786248000; c=relaxed/simple; bh=IpXqVEFXg2PRE8PkF5GEomqXgDHotvjUeK6lKbInEWQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WCT3Un/ZW7d4+S8LP+9lD+yKHN0xJ1CoTej2xhEGlcdRMexJEW3YcXgse6owCsEueKP3nqodkd8gmzniq4LLTHLRqULCzd3u/wA6VK5dnMGZowl6qTs8O/cnhH9fubZQwXALwabw/lVQBZ5u1hePHE8lnSkYqQAKqN1qZEs8RlM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com; spf=pass smtp.mailfrom=lge.com; arc=none smtp.client-ip=156.147.23.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lge.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lge.com Received: from unknown (HELO lgeamrelo01.lge.com) (156.147.1.125) by 156.147.23.52 with ESMTP; 9 Aug 2026 12:59:47 +0900 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: youngjun.park@lge.com Received: from unknown (HELO yjaykim-PowerEdge-T330) (10.177.112.156) by 156.147.1.125 with ESMTP; 9 Aug 2026 12:59:47 +0900 X-Original-SENDERIP: 10.177.112.156 X-Original-MAILFROM: youngjun.park@lge.com Date: Sun, 9 Aug 2026 12:59:47 +0900 From: Youngjun Park To: Kairui Song Cc: Andrew Morton , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Jianyue Wu , her0gyugyu@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] mm, swap: don't free a hibernation slot that is in the swap cache Message-ID: References: <20260806190636.446205-1-youngjun.park@lge.com> <20260806190636.446205-2-youngjun.park@lge.com> 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 Sat, Aug 08, 2026 at 09:26:34PM +0800, Kairui Song wrote: > On Sat, Aug 08, 2026 at 08:09:44PM +0800, Kairui Song wrote: > > On Fri, Aug 07, 2026 at 04:06:33AM +0800, Youngjun Park wrote: > > > A slot with a folio in the swap cache is freed when the folio leaves the > > > cache, not when its count drops. swap_put_entries_cluster() follows that > > > rule. swap_free_hibernation_slot() does not, it calls > > > __swap_cluster_free_entries() whether or not a folio sits on the slot. > > > > > > Cluster readahead can put one there. It walks a raw page_cluster sized > > > window of offsets around the faulting entry, and a hibernation slot passes > > > __swap_cache_add_check() because it is not a folio and its count is not > > > zero. Freeing the slot then clears the entry under that folio. > > > > > > The folio is now unreachable from the swap table, and the offset goes back > > > to the allocator. The folio is still on the LRU though, so reclaim can > > > pick it up later. It then takes the old offset out of folio->swap and > > > overwrites the table entry there, which by then may belong to someone else. > > > > > > Check for a cached folio before freeing. The slot is then left in the > > > ordinary state where only the swap cache holds it, and it is freed when the > > > folio leaves the cache, either through the reclaim below or through normal > > > reclaim later. > > > > > > Fixes: 0d6af9bcf383 ("mm, swap: use the swap table to track the swap count") > > > Signed-off-by: Youngjun Park > > > --- > > > mm/swapfile.c | 9 ++++++++- > > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > Hi Youngjun, > > > > Thanks a lot for looking into the hibernation issue, I've been thinking > > about using a exclusive type for it, glad to see actual code for it :) > > > > And this patch looks good to me, nice catch! > > > > Acked-by: Kairui Song > > Oh and I think we need to Cc stable? Right, I will Cc stable next iteration soon. Thanks for catching. Youngjun