From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.4]) (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 3BF6A37E30F for ; Wed, 12 Aug 2026 02:36:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786502175; cv=none; b=XHBnnJeJv4HsD5MJBrGnbq0L4Kw4pLbQ/uB0ijDDsdHmEoC2W1+SJlB+VAczgerd8tkf/nsX2cFUui5Qzg+ZPVB3ct9fLm3s3sMVl5UWtB7f2J+szCocTIa3r9fo420dUPl9oJf8ey8nnS4Gi2dgnv12YQ7rnl2muapK5bBIYv0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786502175; c=relaxed/simple; bh=GIhUPQulWC7VAkf7wiRIK8q5uImPbtFsNZuV+yeBcsY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DtZWQlgbNqpW5QuNyJVb+xaQw4T7P0/ZZoy+t2CwvYDnxyt6VL7KCj2KX3b0GbqEJ3K8LbvzEt1Ya4rYn4gQIGhQkyB5by8R6p2fR0hXYRAmRvI6244z9o0FixZKJd2OeF2CVYqFDBZlV+mhLw5LQ+k1kU0EaSkHs3Mjn4EaLH8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com; spf=pass smtp.mailfrom=163.com; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b=ARchWuSN; arc=none smtp.client-ip=117.135.210.4 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=163.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=163.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=163.com header.i=@163.com header.b="ARchWuSN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=E4 8rZGlJpEk2yaQSzI9zGHJcjap4/8TJxtr1yxQ2/gc=; b=ARchWuSNwdfkWAW2QR tJYuU2WAYaKaGWuuc40APKEZ5fNTzTFIXZqKkLuRjKBqroKU26F8faeW9HImicA6 Uzg6ZpwkWE35ZM4x6M/kG30vaHbfPqUa8qTfC6olbQOKwqDKeTT8Ez8e3hRKXn2J A/c1zLB2K7OSVGf0tPMFRP4Fo= Received: from localhost (unknown []) by gzsmtp3 (Coremail) with SMTP id PigvCgD3vw_s23tqtHd3Mg--.32002S2; Wed, 12 Aug 2026 10:35:25 +0800 (CST) From: Hui Su To: akpm@linux-foundation.org Cc: ryabinin.a.a@gmail.com, glider@google.com, andreyknvl@gmail.com, dvyukov@google.com, vincenzo.frascino@arm.com, kasan-dev@googlegroups.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, sashiko-bot@kernel.org Subject: Re: [PATCH] kasan: fix quarantine_size accounting during cache removal Date: Wed, 12 Aug 2026 10:34:42 +0800 Message-ID: <20260812023441.2067480-2-sh_def@163.com> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260811182914.ed2cba4ef1a8a88335b9edab@linux-foundation.org> References: <20260811182914.ed2cba4ef1a8a88335b9edab@linux-foundation.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CM-TRANSID:PigvCgD3vw_s23tqtHd3Mg--.32002S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7WrWDur4DZF1kuryrCFyUKFg_yoW8AF43pa y7Jw13Cw1ktryxGFn7W3WrWr1rKrWrJas8J34furna9F1rGw1IqryfKrWjvFy3urs8XF4j qa4DGrn5CFy5GaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07Uov3nUUUUU= X-CM-SenderInfo: xvkbvvri6rljoofrz/xtbCwg+rC2p72+-PcgAA31 > > quarantine_size tracks the total number of bytes stored in > > global_quarantine[]. It is incremented when per-CPU quarantine objects > > are moved into the global quarantine and decremented when a global > > batch is evicted by kasan_quarantine_reduce(). > > > > kasan_quarantine_remove_cache() also removes objects from the global > > quarantine. qlist_move_cache() rebuilds the source batch and updates > > its .bytes field, but quarantine_size is not adjusted accordingly. > > > > As a result, quarantine_size remains over-counted by the size of the > > removed objects. The stale accounting accumulates across cache removals. > > Once the inflated value exceeds quarantine_max_size, > > kasan_quarantine_reduce() can evict a batch even though the actual > > number of bytes in global_quarantine[] is still below > > quarantine_max_size, shortening the quarantine window. > > > > Fix the accounting by recording each batch's size before > > qlist_move_cache() and subtracting the number of bytes actually removed > > from quarantine_size while holding quarantine_lock. > > > > A KUnit reproducer used during testing observed the over-count grow by > > 4698864 bytes after one kasan_quarantine_remove_cache() call with the > > fix reverted. With this change applied, the over-count did not grow. > > > > Thanks. > > > @@ -365,9 +365,14 @@ void kasan_quarantine_remove_cache(struct kmem_cache *cache) > > Sashiko might have found an unrelated pre-existing bug in here. > > https://sashiko.dev/#/patchset/20260811073332.1351893-1-sh_def@163.com Thanks for pointing this out. The issue found by Sashiko was fixed by a previous patch: https://lore.kernel.org/lkml/20260808031459.3032812-1-sh_def@163.com/