检视意见修改-communication

已开启

检视意见修改 #12527

wangrui7创建于 9月12日从wangrui7/communication_dsoftbus_fix_warn： master 合入到 openharmony/communication_dsoftbus： master

检视意见修改 #12527

已开启

wangrui7创建于 9月12日

从wangrui7/communication_dsoftbus_fix_warn master合入到openharmony/communication_dsoftbus master

wangrui7

9月12日

合并受阻

wangrui7

9月12日关联了issue：[Bug]: 检视意见修改

openharmony_ci成员

9月12日添加了label：waiting_on_author

openharmony_ci成员

9月12日评论：

感谢提交 Pull Requests！如果您提交的PR已经开发完毕，请评论 "start build" 触发门禁，更多交互操作，请访问OpenHarmony社区支持命令清单。如果需要调整订阅PR、Issue的变更状态，请访问订阅链接。

Thanks for submitting the pull request. If your Pull Request has already been developed, you can leave a "start build" comment to trigger the gated system. For more commands, please visit OpenHarmony Command List. If you need to change the subscription of a Pull Request or Issue, please visit the link.

openharmony_ci成员

9月12日添加了label：dco检查成功

wangrui7

9月14日强制推送 1 个提交:e69d9566-fix warn

此处折叠了148条消息查看更多

xuhengxiang成员14 天前进行代码检视1

core/bus_center/lnn/decision_center/agent_communication/src/lnn_fragment_recv.c

5757 ListInit(&g_fragmentList);

5858 SoftBusMutexAttr mutexAttr;

5959 (void)SoftBusMutexAttrInit(&mutexAttr);

6060 if (SoftBusMutexInit(&g_fragmentMutex, &mutexAttr) != SOFTBUS_OK) {

xuhengxiang14 天前评论：

当 SoftBusMutexInit 成功但 SoftBusMutexLock 失败时，函数直接返回 SOFTBUS_LOCK_ERR，但已初始化的 g_fragmentMutex 未被销毁。由于 g_isInit 仍为 false，后续调用会再次执行 SoftBusMutexInit 对同一互斥锁重复初始化，可能导致资源泄漏和未定义行为。

在 SoftBusMutexLock 失败的分支中调用 SoftBusMutexDestroy 销毁已初始化的互斥锁后再返回。

xuhengxiang成员14 天前进行代码检视1

core/bus_center/lnn/decision_center/agent_communication/src/lnn_cloud_query_fragment.c

2828#include "softbus_adapter_thread.h"

2929#include "softbus_common.h"

3030#include "softbus_error_code.h"

xuhengxiang14 天前评论：

删除了宏定义 MAX_FRAGMENT_CONTEXT_NUM (5000)，但如果该宏在当前文件或其他依赖文件中仍被引用（例如用于限制分片上下文数量的边界检查），将导致编译失败。即使宏的使用处也被同步删除，若原本基于该宏的资源上限检查被移除，则可能导致分片上下文数量无限制增长，引发内存耗尽或资源泄漏。

确认 MAX_FRAGMENT_CONTEXT_NUM 的所有使用点是否已同步移除或替换为等价的限制机制。若该宏用于资源上限保护，必须保留相应的边界检查逻辑，防止无限制分配分片上下文。

xuhengxiang成员14 天前进行代码检视1

core/bus_center/lnn/decision_center/agent_communication/src/lnn_fragment_recv.c

55- return;

55+ return SOFTBUS_OK;

5656 }

5757 ListInit(&g_fragmentList);

xuhengxiang14 天前评论：

FragmentRecvInit 中对 g_isInit 的检查未加锁，存在 TOCTOU 竞态。两个线程可同时通过 g_isInit==false 检查，随后都调用 ListInit 和 SoftBusMutexInit，导致已存在的分片链表被重置（数据丢失）以及互斥锁被重复初始化（资源泄漏/未定义行为）。原代码中的锁内二次检查被移除，进一步降低了保护。

在首次检查后直接加锁，或在 SoftBusMutexInit 之前加锁（需确保互斥锁已初始化），使用单一加锁路径保护整个初始化过程，避免 ListInit 和 MutexInit 被并发调用。

xuhengxiang成员14 天前进行代码检视1

core/bus_center/lnn/decision_center/agent_communication/src/lnn_fragment_recv.c

55- return;

55+ return SOFTBUS_OK;

5656 }

5757 ListInit(&g_fragmentList);

xuhengxiang14 天前评论：

FragmentRecvInit 中 SoftBusMutexInit 成功后若 SoftBusMutexLock 失败，函数直接返回错误，未调用 SoftBusMutexDestroy 清理已初始化的互斥锁。由于 g_isInit 仍为 false，后续调用会再次执行 SoftBusMutexInit，对已初始化的互斥锁重复初始化，在 POSIX 下属于未定义行为，可能导致资源泄漏或崩溃。

在 SoftBusMutexLock 失败的分支中，先调用 SoftBusMutexDestroy(&g_fragmentMutex) 清理互斥锁再返回错误。

xuhengxiang成员14 天前进行代码检视1

core/bus_center/lnn/decision_center/agent_communication/src/lnn_fragment_recv.c

55- return;

55+ return SOFTBUS_OK;

5656 }

5757 ListInit(&g_fragmentList);

xuhengxiang14 天前评论：

FragmentRecvInit 中移除了锁内双重检查（double-checked locking）。g_isInit 的首次检查在无锁状态下进行，若两个线程同时调用 FragmentRecvInit（例如通过 FragmentRecvProcess 并发处理数据），两者均可通过首次检查，导致 ListInit 被重复调用（重置链表，丢失已有的分片上下文数据）以及 SoftBusMutexInit 被重复调用（对可能正在使用的互斥锁重新初始化，行为未定义）。

在获取锁后、设置 g_isInit 之前恢复对 g_isInit 的二次检查，确保仅有一个线程执行初始化逻辑；或将 ListInit 和 SoftBusMutexInit 移入锁保护范围内。

相关的Issue

原因（目的、解决的问题等）

描述（做了什么，变更了什么）

验证结果（新增、改动、可能影响的功能）

日志规范自检：

安全编码自检：

是否已执行L0用例

合并受阻