From dd3bda39cf7a9716c1d45dcaba67da7f64116d63 Mon Sep 17 00:00:00 2001 From: Alexander Motin Date: Mon, 26 Jul 2021 19:30:20 -0400 Subject: [PATCH] Add comment on metaslab_class_throttle_reserve() locking Reviewed-by: Brian Behlendorf Signed-off-by: Alexander Motin Issue #12314 Closes #12419 --- module/zfs/metaslab.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/module/zfs/metaslab.c b/module/zfs/metaslab.c index 93d409ceb4..df0d83327c 100644 --- a/module/zfs/metaslab.c +++ b/module/zfs/metaslab.c @@ -5617,6 +5617,13 @@ metaslab_class_throttle_reserve(metaslab_class_t *mc, int slots, int allocator, if (GANG_ALLOCATION(flags) || (flags & METASLAB_MUST_RESERVE) || zfs_refcount_count(&mca->mca_alloc_slots) + slots <= max) { /* + * The potential race between _count() and _add() is covered + * by the allocator lock in most cases, or irrelevant due to + * GANG_ALLOCATION() or METASLAB_MUST_RESERVE set in others. + * But even if we assume some other non-existing scenario, the + * worst that can happen is few more I/Os get to allocation + * earlier, that is not a problem. + * * We reserve the slots individually so that we can unreserve * them individually when an I/O completes. */