From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (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 2A087242D65 for ; Mon, 10 Aug 2026 18:23:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786386212; cv=none; b=NuFfUBV00ycZnco1K6Bhf0UufkxExPB2h8UX+G5mkbl9QYvAtPJLphFYof64VqPPTwdceDJUk45hykZq78AtT4ud15wk9PF5SiSxCUNiVzGKOCLAi8SXcILA+KdhM1ACPZCkZfWFynqO65au4wKAjj2FG5IYc3UbVfkDfExwjiw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786386212; c=relaxed/simple; bh=mqYBhyhLG9YI/Ika3n4BUCvsHTcoKA3Jk7SSeoHhgKU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Srv7hRpojHpwXw2DGUdjDtOifna2lXQ2qx01c9qcQIbkB+klYBrhCMTQNDltIqMS5S9FGJhGvvh88uPOAOBwrluPVTXetpz/rnWRyskq6OxnTiu0qixXtxWrCgzHcsVuwO8DVWr7D3FbIes7EGHxzKSl66WNPNpNJvKh7V8zGGA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=cnCmPOAG; arc=none smtp.client-ip=209.85.216.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cnCmPOAG" Received: by mail-pj1-f48.google.com with SMTP id 98e67ed59e1d1-38e041ea211so2551121a91.0 for ; Mon, 10 Aug 2026 11:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786386210; x=1786991010; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=78FhXUtIMPLEMb/0q40kgGbueWBdVpdNCXluWOZSpp4=; b=cnCmPOAGhUjQ0D7octjtA86m7ympe23c2ApS9tnI090+c+n6N0dI6gim7lIUtpI/u+ t/3odTIBAJZ0fKKvabI2CXwUoDueq38pkIASRgaZaDe6vt1KRT0WX1qJMk1erjzy0dCo UKagxJlMnsA6cV6cg/fS9hkEPmTCo64GnuTWRLKeB05zHlgbrdpchLe4bTsEmd221cKs E4oyOOVZ2fUYK5hGfF7gHYMpHbiJRRBXKsWqIqIj6hfPXF1YOZLWQs581bXW3V+vfYQb OAkOCkAxmm286vfvnn7eIdRB/O6+eIrgw+Nyb5IzwesJU9uk/EomdVB4RyObODfIOHFK ecsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786386210; x=1786991010; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=78FhXUtIMPLEMb/0q40kgGbueWBdVpdNCXluWOZSpp4=; b=TpCiRb6vQrACDEWh2ZA6XLFrtUuGsyRmWiBy/pm50IWTqiggQ8HNXiq/cEs+XmWf6Q riPF3uy4DzfSq55XHL2HIx2UoV/kmOcraqTXbBClvFSgReSQb3Dxyj6Y3QrA4ge0LqF5 g2ZDVmaJ/GnFGatROcRzx0RYP+BtcRsMgz6fkW4Wpk/7ty00rENRHpKaPFCvxIqzXyOP KH8c9SZs39rMBwlVHaXkUIZ0CLxd5prVxWVkSehicvXsJzega3WJwyZ7W0FeuoEl/DNc 8WIEa3r4CH2br0VJqKzzEGzIXRxMbs+94d6PtT0PhFvFeWwPoIBC7Zc7c4CUJpiD0/Qn Cw2A== X-Forwarded-Encrypted: i=1; AHgh+Rp5UMe2xCVS4LpFmQPBJvex3mXYFcegdjSfhei+3i1KbT//OnjwSQKvIvtUkFtPhAhIm6015uFT5Q2yvhQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwwScgDJCSTwyAfFaeHTKxjDweJpQniQRcXDA2b0sCF93ekT4Hh E2+UgYHWEwAsirpBJ4ZKltMb16hvfG3SmFKBS7jzPW2uCEkH6IYEYZjy X-Gm-Gg: AR+sD10ddsKbplcspqmsUrm/B6L979ZYdRofI80J5V3xjUxp8/oNuBPA1slnJc3Oh6O 7xDmGgxUAEhdii1kTXpQ9BQ0FQoIso/q7vfSonpmv7pkuqQ3lQ3HM1OLJn+6cY3ptaoGkSPLhcn kFLF614yKkbpFwH7v9rjGFY9BiAm3ZWxaYh4kbspw95eKq8V3qK3IK1Lc7dc5TOPHp1Ggg44o5m E3L/kwK4SOQKnbYcyBe0avZmT8rrEajw8VSmewgixkBl1BnFGZEzAjpAP5RskFlm8+jgsu8/k2+ mnEuMShD+HXE2rm9MwxVqNi7pMR8GoREbeNkF7C8zfCbq5I9McFyuCR36mC9aMdWA878or7ahDd vKAYbfLmHikiqBPvbTGv2OnWm6IisyHZI8Qpk+d0yWdmQ2OmEolSsIwIqTBvesFgNnOMRQkp7Fu PIiUeGWBuIv1oiDeYa42i6U2ekZeDYeMyNT0BDogMKTfKMOoOfSZ/mVrcQtNhrAnlHqFM05E213 CvJ3vRgJteG+mnGVkctdo5z X-Received: by 2002:a17:90b:53c5:b0:381:bc4c:da5b with SMTP id 98e67ed59e1d1-3903c61098cmr48757843a91.18.1786386210377; Mon, 10 Aug 2026 11:23:30 -0700 (PDT) Received: from KASONG-MC4 ([101.32.222.185]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-390b35ca2b7sm5822836a91.4.2026.08.10.11.23.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 10 Aug 2026 11:23:29 -0700 (PDT) Date: Tue, 11 Aug 2026 02:23:21 +0800 From: Kairui Song To: Youngjun Park 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 v2 2/4] mm, swap: only allow swapped-out slots into the swap cache Message-ID: References: <20260809144559.2104856-1-youngjun.park@lge.com> <20260809144559.2104856-3-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: <20260809144559.2104856-3-youngjun.park@lge.com> On Sun, Aug 09, 2026 at 11:45:57PM +0800, Youngjun Park wrote: > __swap_cache_add_check() turns away folio entries and slots with no count > and lets everything else in. That is safe only when the caller owns the > slot. Cluster readahead owns nothing, it walks a raw page_cluster sized > window of offsets around the faulting entry, so it can land on any slot. > > A bad slot gets in. The check reads the count with __swp_tb_get_count(), > which shifts the count bits out without looking at the type, and > SWP_TB_BAD has all of them set, so the slot reads as SWP_TB_COUNT_MAX. > Readahead then allocates a folio and reads the offset off the device for a > slot nothing will ever swap in, and the folio entry that replaces it drops > the bad marker. > > Readahead used to be guarded by swap_entry_swapped(), which goes through > swp_tb_get_count() and gets -EINVAL for a bad slot. That call went away > when the swap cache checks moved into __swap_cache_add_check(), and the > raw accessor there does not do the same type test. > > Require a shadow entry instead. A slot dropped from the swap cache always > gets one, empty if there is no workingset value. The type test runs first, > so the count is only read off a countable entry, and the check as a whole > runs before the folio allocation in __swap_cache_alloc(). > > Reproduced with a badpages list written into the swap header by hand. > Readahead took over four bad slots before this patch and none after. It > needs a crafted header, so a normal setup will not hit it. > > Fixes: e1e6750df3b4 ("mm, swap: add support for stable large allocation in swap cache directly") > Signed-off-by: Youngjun Park > --- > mm/swap_state.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Thanks! Acked-by: Kairui Song We need this fix for 7.2 I think.