bugfix: extend block pool runtime

[yanglimingcn]

What problem does this PR solve?

Issue Number:

Problem Summary:

rdma block pool runtime ExtendBlockPool has some error:

1. a region may has many buckets, extend a region not hold all bucket locks, will case race condition, disable runtime extend a region when buckets greater than 1.
2. when new region created, link the region to idle_list case link list break.
3. add feature, in scenarios where users need to manually specify memory regions (e.g., using hugepages or custom memory pools), when FLAGS_rdma_memory_pool_user_specified_memory is true, user is responsibility of extending memory blocks , this ensuring flexibility for advanced use cases.

What is changed and the side effects?

Changed:

Side effects:

• Performance effects:

• Breaking backward compatibility:

---

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow Contributor Covenant Code of Conduct.

[Copilot]

Pull Request Overview

This PR addresses a bug in the rdma block pool runtime by fixing a race condition during region extension and correcting the idle list linkage.

• Update for proper linking of new idle nodes in ExtendBlockPool.
• Addition of locks for all bucket indices during region extension to prevent race conditions.

Comments suppressed due to low confidence (2)

src/brpc/rdma/block_pool.cpp:181

• Ensure that linking the new idle node via g_info->idle_list correctly preserves the expected ordering for the recycle process; verify that this insertion pattern does not introduce unintended list cycles or ordering issues.

node[i]->next = g_info->idle_list[block_type][i];

src/brpc/rdma/block_pool.cpp:300

• Review the lock acquisition order for the additional bucket locks to ensure no deadlock may occur when multiple threads execute AllocBlockFrom concurrently; consider documenting the lock ordering to aid future maintenance.

other_locks.emplace_back(*g_info->lock[block_type][i]);

[yanglimingcn]

@wwbmmm @chenBright please review this bugfix

[wwbmmm]

LGTM

[chenBright]

!FLAGS_rdma_memory_pool_user_specified_memory？

[yanglimingcn]

FLAGS_rdma_memory_pool_user_specified_memory == false, means not allowed to ExtentBlockPoolByUser

[Copilot]

Pull Request Overview

This PR addresses several bugs in the RDMA block pool runtime extension functionality and introduces a new user-specified memory management feature. The fixes resolve race conditions during region extension, linked list corruption, and add constraints to prevent unsafe multi-bucket scenarios.

• Fixes race condition and linked list corruption in ExtendBlockPool runtime
• Adds user-specified memory pool management with FLAGS_rdma_memory_pool_user_specified_memory
• Changes InitBlockPool return type from void* to bool for cleaner API design

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
src/brpc/rdma/block_pool.h	Updates InitBlockPool signature and adds ExtendBlockPoolByUser declaration with documentation
src/brpc/rdma/block_pool.cpp	Core implementation fixes for thread safety, linked list management, and user memory pool support
src/brpc/rdma/rdma_helper.cpp	Adds UserExtendBlockPool wrapper function
test/brpc_block_pool_unittest.cpp	Updates test assertions to match new InitBlockPool boolean return type

[AnDiXL]

What problem does this PR solve?

Issue Number:

Problem Summary:

rdma block pool runtime ExtendBlockPool has some error:

1. a region may has many buckets, extend a region not hold all bucket locks, will case race condition, disable runtime extend a region when buckets greater than 1.
2. when new region created, link the region to idle_list case link list break.
3. add feature, in scenarios where users need to manually specify memory regions (e.g., using hugepages or custom memory pools), when FLAGS_rdma_memory_pool_user_specified_memory is true, user is responsibility of extending memory blocks , this ensuring flexibility for advanced use cases.

What is changed and the side effects?

Changed:

Side effects:

• Performance effects:
• Breaking backward compatibility:

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow Contributor Covenant Code of Conduct.

“a region may has many buckets, extend a region not hold all bucket locks, will case race condition, disable runtime extend a region when buckets greater than 1.”

Why not modify it so that a lock is added to the bucket when expanding the region? In this way, there would be no need to limit the number of buckets.
For example, in the following form:

    for (size_t i = 0; i < g_buckets; ++i) {
        node[i]->start = (void*)(region->start + i * (region_size / g_buckets));
        node[i]->len = region_size / g_buckets;

        BAIDU_SCOPED_LOCK(*g_info->lock[block_type][i]);
        node[i]->next = g_info->idle_list[block_type][i];
        g_info->idle_list[block_type][i] = node[i];
        g_info->idle_size[block_type][i] += node[i]->len;
    }