[PATCH] kasan: fix quarantine_size accounting during cache removal

[PATCH] kasan: fix quarantine_size accounting during cache removal

[Hui Su]

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.

Fixes: 64abdcb24351 ("kasan: eliminate long stalls during quarantine reduction")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260808031459.3032812-1-sh_def%40163.com
Signed-off-by: Hui Su <sh_def@163.com>
---
 mm/kasan/quarantine.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 6958aa713c67..c220f0d8ddd0 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -365,9 +365,14 @@ void kasan_quarantine_remove_cache(struct kmem_cache *cache)
 
 	raw_spin_lock_irqsave(&quarantine_lock, flags);
 	for (i = 0; i < QUARANTINE_BATCHES; i++) {
+		size_t old_bytes;
+
 		if (qlist_empty(&global_quarantine[i]))
 			continue;
+		old_bytes = global_quarantine[i].bytes;
 		qlist_move_cache(&global_quarantine[i], &to_free, cache);
+		WRITE_ONCE(quarantine_size, quarantine_size -
+			   (old_bytes - global_quarantine[i].bytes));
 		/* Scanning whole quarantine can take a while. */
 		raw_spin_unlock_irqrestore(&quarantine_lock, flags);
 		cond_resched();

base-commit: d58772d8520c7ef247c4b95c9bd76d3a25da9ff5
-- 
2.43.0

Re: [PATCH] kasan: fix quarantine_size accounting during cache removal

[Andrey Ryabinin]

Hui Su <sh_def@163.com> writes:

> 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.
>
> Fixes: 64abdcb24351 ("kasan: eliminate long stalls during quarantine reduction")
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260808031459.3032812-1-sh_def%40163.com
> Signed-off-by: Hui Su <sh_def@163.com>

Reviewed-by: Andrey Ryabinin <ryabinin.a.a@gmail.com>

Re: [PATCH] kasan: fix quarantine_size accounting during cache removal

[Andrew Morton]

On Tue, 11 Aug 2026 15:33:32 +0800 Hui Su <sh_def@163.com> wrote:

> 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

Re: [PATCH] kasan: fix quarantine_size accounting during cache removal

[Hui Su]

> > 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/