代码拉取完成，页面将自动刷新
一、缺陷信息
**内核信息：OLK 5.10
**缺陷归属组件：kernel
缺陷归属的版本： 2203-SP2
缺陷简述：
libnuma库通过 syscall __NR_sched_getaffinity 获取cpumask，同时获得cpu number。
当前此syscall返回值有误，返回的是CONFIG_NR_CPUS的值而不是实际的cpu数量，导致libnuma库性能差。
【环境信息】
NA
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
1、内核用CONFIG_CPUMASK_OFFSTACK宏来确定nr_cpumask_bits是采用nr_cpu_ids还是NR_CPUS值，nr_cpu_ids表示系统实际存在的cpu个数，NR_CPUS表示OS镜像支持的最大cpu个数
2、sched_getaffinity函数返回值是取用户传进去len和根据cpumask_size（会调用nr_cpumask_bits进行计算）算出来长度的最小值。cpumask_size以unsigned long为单位，用bit mask表示cpu的个数，所以存在返回值比实际核数大的情况，根据glibc的语义规定，是需要上层结合CPU_COUNT去做判断遍历的范围。
3、虽然内核可以一定程度规避这个问题，但不是内核问题，本质上是上层使用不合理导致。
4、打开CONFIG_CPUMASK_OFFSTACK宏可以规避，打开宏后会导致cpumask_var_t从数组变成指针，导致kabi发生变更
5、可以回合高版本一组补丁规避这个问题，但是建议用户使用的时候需要结合CPU_COUNT去做限制
（https://lore.kernel.org/lkml/20220905230820.3295223-1-yury.norov@gmail.com/T/）
缺陷数据未收集完成，重新打开issue
内核信息 解析失败
缺陷归属组件 解析失败
归属版本 2203-SP2 错误
详情参考链接 解析失败
分析指导链接 解析失败
登录 后才可以发表评论
