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 EBC08439331 for ; Wed, 12 Aug 2026 12:13:40 +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=1786536827; cv=none; b=Yn9BJ7soGw5je0se7STyqXYNC89M5nZAT2Aw9KOL/VzsSZ7P83hycKpK/L+hsX5pW1XIUwnagFAixDNmWMOLr8lvEnSG67PZO1/n23/FNKqsbOP1GF3Ew09vKffW0qS7ErO8RR0K/htS7/i4B4Ds9uequL64fw26ZPdlOTsvQG4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786536827; c=relaxed/simple; bh=GQC8xe/+9Kg148q3MlZnaIEjXEEfIWGCX9QdVL0/fBA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E+6V/R+c98HuoI8g0k914p3H1F08rrMvRnjU/uI6TsHo0mBwCHGtkmHO0m3nZ4PkFf2xLHTIff14dH8u/vR5uTPbEjOQIdNfEwMZdnfFKl69zD/IoveDikGVRk8++ljrmBCMOGpdJ6QilbROsAqRRZuFqsR6ApyHQdF3VlP1rfE= 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 lgeamrelo02.lge.com) (156.147.1.126) by 156.147.23.52 with ESMTP; 12 Aug 2026 21:13:37 +0900 X-Original-SENDERIP: 156.147.1.126 X-Original-MAILFROM: youngjun.park@lge.com Received: from unknown (HELO yjaykim-PowerEdge-T330) (10.177.112.156) by 156.147.1.126 with ESMTP; 12 Aug 2026 21:13:37 +0900 X-Original-SENDERIP: 10.177.112.156 X-Original-MAILFROM: youngjun.park@lge.com Date: Wed, 12 Aug 2026 21:13:37 +0900 From: Youngjun Park To: Andrew Morton 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: References: <20260811132209.2862708-1-youngjun.park@lge.com> <20260811114622.6a04927b0c7ca0c2d6b39cce@linux-foundation.org> 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: <20260811114622.6a04927b0c7ca0c2d6b39cce@linux-foundation.org> On Tue, Aug 11, 2026 at 11:46:22AM -0700, Andrew Morton wrote: > When fixing things, please always take care to describe the > userspace-visible runtime effects of the bug, particularly when > proposing a -stable backport. Thank you for the advice and sorry for it. I will make sure future patches describe the userspace-visible effects clearly! > 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. That is right, with one small correction. this can happen with uswsusp while the hibernation image is being created, not at resume time. Memory corruption, process crashes, or data instability across completely unrelated userspace applications can occur there. > Do we have any reports of this? Reported-by/Closes? I found this while working on giving hibernation slots their own marker in the swap table, which I had discussed with Kairui. (https://lore.kernel.org/linux-mm/abp7aDgYLrxF3Me8@KASONG-MC4/) As far as I know there are no reports, so there is no Reported-by/Closes to add. > 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. Simply put, they are close to cleanups that remove unneeded work. (with a some little optimization.) Patch 2 keeps bad slots out of the swap cache, so readahead no longer wastes a folio on them. Patch 3 keeps hibernation slots out of the swap cache, with the same effect. no wasted folio at readahead time. Patch 4 removes dead code. Thanks, Youngjun Park