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 CCEA3385D91 for ; Tue, 11 Aug 2026 18:46:24 +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=1786473988; cv=none; b=hVknHZqnoIw1AkA9xsSDphlFlVXNgFJ599LN1euIhQqSDqk2XFD6xrOR/9skM0iAmtItH3wx8t5eAav3PKRiiYyWVHwHnFJyQavHoz9cqlVMwpe0ejsrFe69jXmq1wRRD2y4Twszhn1DC7NuT41OTfrAnuPT776Kpq7jkwVzYOQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786473988; c=relaxed/simple; bh=hh41VqTDcahR8eKnCNP9tcr31PLSDqUwmFeeh+8nbBI=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=V7fJVCZcwOyjUwJeff4jl2FliXU3Ou62I/ql2xtVUAfEHu5uRG1MdJj11lXmV4XYLCjSlQKiZfzBFKe/CfhDdedXphNCuSt+rQZ1VAkIEMMaYSi+ROr6qgBisK4e6Ffb9TSiIzhOfYhrPQtZC7gAHpNAUsuuPQJz/qXzdHI7Vu0= 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=ZYy6pYr+; 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="ZYy6pYr+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B17231F000E9; Tue, 11 Aug 2026 18:46:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1786473983; bh=iKPZZ3B0d2sbP/oMQ9LePwX+c7Vb+ZdjwJJLMFTv0Ew=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ZYy6pYr+DxUoI7TbicnIiX4Sh8Mi+oV/yG/61UWORxewaWM0ldGrEpzRBd5WkSxyU wVN3AK8mhvD5HDcSKXMWjziRdrd6JIJsBo+hdK5yX7L41o6BkKrx6scqPiJ5q6h0OV dW+by6O1QQLJM5OChZoEVw9ODM4/8rhmukRYhJ10= Date: Tue, 11 Aug 2026 11:46:22 -0700 From: Andrew Morton To: Youngjun Park Cc: 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 v3 0/4] mm, swap: keep hibernation swap slots out of the swap cache Message-Id: <20260811114622.6a04927b0c7ca0c2d6b39cce@linux-foundation.org> In-Reply-To: <20260811132209.2862708-1-youngjun.park@lge.com> References: <20260811132209.2862708-1-youngjun.park@lge.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 Tue, 11 Aug 2026 22:22:05 +0900 Youngjun Park wrote: > Cluster readahead walks a raw page_cluster sized window of offsets around > the faulting entry. A hibernation slot looks like an ordinary swapped out > slot, so __swap_cache_add_check() lets it in. Readahead reads the offset > off the device into a folio and puts that folio in the swap table where the > hibernation entry was. This has been possible for a long time. It only > wasted a folio and a read. > > That changed with commit 0d6af9bcf383 ("mm, swap: use the swap table to > track the swap count"). A slot with a folio in the swap cache should only > be freed when the folio leaves the cache. swap_put_entries_cluster() still > does that, but the conversion left swap_free_hibernation_slot() freeing the > slot either way. Nothing points at the folio after that, and when reclaim > drops it later, it writes to the table entry at the old offset, which > someone else may own by then. > > Patch 1 is the fix and the only patch for stable. It puts the missing > check back, so both free paths behave the same again. Thanks. When fixing things, please always take care to describe the userspace-visible runtime effects of the bug, particularly when proposing a -stable backport. For [1/4] Gemini tells me "At a high level, this bug triggers silent memory corruption, process crashes, or data instability across completely unrelated userspace applications - typically occurring after a system resumes from hibernation (suspend-to-disk)." Which is what I figured too. Do we have any reports of this? Reported-by/Closes? I'd like to grab [1/4] only, and defer the other three until 7.3-rc1. This might be mistaken, but from a quick read, it's not clear what benefit those three patches offer our users. And there's value in merging the backportable fix alone, to avoid the risk that the other three patches accidentally fix misbehavior in [1/4].