mm/kasan/quarantine.c | 5 +++++ 1 file changed, 5 insertions(+)
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
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
> > 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/
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>
© 2016 - 2026 Red Hat, Inc.