From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 F3D4E39EF0F for ; Wed, 13 May 2026 12:50:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778676610; cv=none; b=ZEoeUqIorbJA19KkQvfyN1oJNU+wjGaq5bAr+kQ9k0S7OolNb5i9FCAnkL4p4P3Q0dC+j2JniPb0uHjSB/L3L59JeTpHhyGFE0psOY9Q4JZl5pxlVfeMdHCvoPyuSS049DG4oebOYKW4WquMfeKNHEkzHZNBwmZAOQHt31SxJ38= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778676610; c=relaxed/simple; bh=xWp5F/zlkZPBsAYnK+Nghu/hnueSUHPcE9kIRTriBU8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PxwGapdxi5koborsp82H9KG0P7r6IpFfmH+0p2qmUh9UWwjfyhXp8qiFFPDYWqjdgQiHvQ2P+GPWvTOh2jZ4MNG0VfOgRHiboPPOFklReHdDdGqmo/va5YXfqGY921JEOQX376AbmEAFFF+jgReRrdbhGpZesqVz09mqO50K9vU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=CMZs4x4b; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="CMZs4x4b" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=CBk5DzwdzLt/Urbldt92PqU6c02fC0avSSxyBcUGUso=; b=CMZs4x4bpSIwqjodW45+vmq95g TlFJ1getpPHKzZigMPMUjLF3PSw3G7tnVJDJaYO/LL3dwCtbMujH/h93FsYwBrr6Kp9lM8dSeOpw2 Dvz/KK+Az7Fz0JFbmEMIfocrVcB5HAEEhmDqRZmo16ZoDXwMaAYEnxtkHOv34BW2gYac6/dS2ZQLF ttBimzUXZHrfXYgWIHivSBfxFvfp3fkkzExSwNqZ9KQ9ric2IHlw7THm4PfRKihSUBHUt+83P3bIB c72KsofB0Miwm88XpdUxWJlpEBcM4gNciW/Q/SZ0DkrxhNi+ghlmE4/hKabRyreb6O+j+WhlycbPX MRJjDuMA==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wN91w-003AhO-0a; Wed, 13 May 2026 12:49:40 +0000 Date: Wed, 13 May 2026 05:49:35 -0700 From: Breno Leitao To: kasong@tencent.com Cc: linux-mm@kvack.org, Andrew Morton , Chris Li , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Youngjun Park , Kairui Song , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm, swap: avoid leaving unused extend table after alloc race Message-ID: References: <20260513-swap-extend-table-fix-v1-1-a71dea851fb3@tencent.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: <20260513-swap-extend-table-fix-v1-1-a71dea851fb3@tencent.com> X-Debian-User: leitao On Wed, May 13, 2026 at 05:21:11PM +0800, Kairui Song via B4 Relay wrote: > From: Kairui Song > > Allocating an extend table requires dropping the ci lock first. > While the lock is dropped, a concurrent put can decrease the slot's > swap count to a value that is no longer maxed out, so the extend > table is no longer required. The current allocation path still > attach the new extend table to the cluster anyway, leaving it unused. > > It's not really leaked, the next maxed out count on the same cluster > reuses the table, and frees it properly. Swapoff will also clean it up. > > The worst case is one unused page pinned per cluster until the next > maxed-out allocation or swapoff. To eliminate the waste, re-check > under the ci lock that the extend table is still needed before > publishing it, and free the local allocation otherwise. The added > overhead is ignorable. > > Fixes: 0d6af9bcf383 ("mm, swap: use the swap table to track the swap count") > Reported-by: Breno Leitao > Closes: https://lore.kernel.org/linux-mm/agG6Dp0umhs6O1SY@gmail.com/ > Signed-off-by: Kairui Song Tested-by: Breno Leitao Thanks for the fix, --breno