是谁在刷KPI 驳：Linux内核维护者点名华为开发者...
本帖最后由 tsvn 于 2021-6-21 20:13 编辑闲着也是闲着
近日，Linux 内核邮件列表出现了一封特殊的邮件，该邮件名为《Please don't waste maintainers' time on your KPI grabbing patches (AKA, don't be a KPI jerk)》，目前已经排在了热门第一位。
在邮件中，Linux 内核维护者 Qu Wenruo 提到了一个 @huawei.com 后缀的账号，Qu 指责后者所提交的补丁只是清理一些错误信息，或者修复拼写错误，有刷 KPI 的嫌疑。
最早应该是来自 2021年06月21日 10:02
https://www.cnbeta.com/articles/tech/1143079.htm
后面的 2021-06-21 12:26IT之家 (姜戈)
https://m.ithome.com/html/558456.htm
甚至专门去知乎发了个提问
迅速刷爆
知乎：
https://www.zhihu.com/question/466111598/answers/updated
v2ex
https://www.v2ex.com/t/784789?p=1
nga
https://bbs.nga.cn/read.php?&tid=27293447
s1
https://bbs.saraba1st.com/2b/thread-2011116-1-1.html
论点：有刷 KPI 的嫌疑
论据：
只是清理一些错误信息
修复拼写错误
且数量还不在少数
既然点名了，查一下菊花内核开发人员在内核的提交记录吧
thunder.leizhen@huawei.com
https://kernel.source.codeaurora ... eizhen%40huawei.com
总共提交159次
1、先看清理一些错误信息 13次
占比 13/159
都是来自
Reported-by: Hulk Robot <hulkci@huawei.com>
这是谁,菊花的自动内核构陷发现机器人
自动内核缺陷发现机器人继续占领Bug提交榜首
在内核测试和 Bug 提交方面，华为的自动内核缺陷发现机器人 HULK Robot（Huawei Unified Linux Kernel Robot）一如既往的表现出色，在 Linux Kernel 5.8 版本中继续霸榜，显示了华为在 Linux 稳定性方面的超群实力。
HULK Robot 的架构师魏勇军介绍，开源模式下除了带来业务生态快速催熟等各种红利外，也引入了越来越多的挑战：海量频繁的补丁合入、成千上万的开发人员、一行修改百倍测试等等。华为通过构建成熟稳健智能的测试机器人，精准挖掘 Linux kernel 缺陷，保障高质量可持续交付的 Linux 内核，配套各解决方案商用。”
通过分析应该是最近在做质量改进方面的工作
2、拼写错误，总共7次
占比 7/159
提交日期分别是：
2021-05-24
2021-04-06 4次，实际是一次性提交的
2016-01-30
2015-09-22
nga的楼主
我说说我的看法
华为可以做这种改改注释的工作吗？当然可以，规范代码注释也是很重要的工作，没什么问题
但是问题是，华为这个人，不是一次把修改打包一起提交的，而是，改两行提交一次，审核折能不抓狂吗
拼写错误提交可以看到2016年就已经有记录了，不会是2016年就开始刷了吧，推测只是个人习惯，而且也都是打包提交修改的，不存在一个错误一个错误提交刷的
不断强调只是简单的修改注释拼写错误（实际占比7/159），可惜的是，这么简单的工作，这么长时间都没有人去做，别人顺手提了反而是问题了
为了达成该员工是在刷KPI的，还有不断的引导该员工之前是正常工作的，后来不正常了，正常到什么时候呢
有说到2017
yanqiyu 31
yanqiyu 4 小时 41 分钟前 ❤️ 1
这次冲突的主要原因还是 https://lore.kernel.org/linux-bt ...dc8f07@gmx.com/T/#t 这个 patch，在被指出无意义之后试图 argue，被认为是在浪费维护者时间。导致 Qu Wenruo 干脆新帐旧账一起算了。
@Stoulla 这人不是实习生，可以在邮件列表看见 17 年之前的 patch，那时候显然还在认真写代码
还有说2018
我简单浏览了一下这个开发者的patch提交记录，大概在2017年以及以前，这个人的patch虽然不多，但大部分还是有意义的patch的，2018年好像是在围绕一个功能前前后后做了一些功能添加和修复的工作。2018年底到2020年下半年几乎销声匿迹快两年，然后一年前突然又出现，出现后画风慢慢的就不太对了，像是找到了什么“法门”，patch数量渐渐多了起来，但是“风格”逐渐向“看着改了很多，但是大部分又没大用”的方向发展下去了，和之前的patch平均质量比可以说是下降了几个台阶。
作者：醉卧沙场
链接：https://www.zhihu.com/question/466111598/answer/1951896502
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
这个回答中有人提了是机器人的工作，但是答主不认同
举报
纸飞机
纸飞机4 小时前
可能那些patch是机器人提交的。。。。。。
赞
回复
踩
举报
醉卧沙场
醉卧沙场 (作者) 回复纸飞机4 小时前
从当前commit的记录来看，不像是机器人。当然我也不能说完全不可能，毕竟用一个账号混合机器人和人类行为在一起也是可能的。
最后还有说到2019
swulling 9 分钟前 via iPhone
@yanqiyu 19 年之前还在好好写代码，多数代码都是驱动相关，应该在华为的内核组或者驱动组工作。
之后画风突变，估计也是为了追 KPI 。
其它的就不看了，都是露屁股而已
一个可怜的菊花工程师，最近开始跑自动内核缺陷发现机器人，提交修改缺陷的补丁，顺便把看到的小问题（包括注释中的拼写错误、代码优化）改一下而已，倒是cnbeta的编辑刷KPI
是转帖时丢了信息吗，感觉读不太懂 @leystage
我修改了一下
用来得出菊花工程师是刷KPI的证据是站不住脚的，邮件中提到的两大点
清理错误信息 13/159 这是跑自动内核缺陷发现机器人发现的缺陷，是真实存在的缺陷，最近该工程师提交的大部分都是这个机器人跑出来的缺陷
修改注释中的拼写错误7/159 这个从2020年以来只有2次提交，早在2016年该工程师就已经有过这些提交记录，这个是多个地方修改一次提交，不存在一次只提交一个刷KPI的问题
https://kernel.source.codeaurora ... q=hulkci@huawei.com
查询机器人的账号hulkci@huawei.com可以看见很多提交，搜索了一下error return code，也翻了几页，发现以前也有很多华为的工程师跑过机器人，提交过错误信息的。
http://tva2.sinaimg.cn/large/007WH5Y2ly1grq5ya5nxcj32yj1i41ei.jpg
http://tvax3.sinaimg.cn/large/007WH5Y2ly1grq5yal771j32ye1hytup.jpg
但是错误信息的提交主要集中在2020年11月至今及2020年5月的一段时间
http://tva1.sinaimg.cn/large/007WH5Y2ly1grq5yc1nzlj32yo1i9wyi.jpg
http://tva2.sinaimg.cn/large/007WH5Y2ly1grq5yd2qflj32yo1i6x0f.jpg
2019-02（更早我没往前翻了）至2020-05，2020-05至2020-11期间都未发现清理错误信息相关提交。
http://tvax2.sinaimg.cn/large/007WH5Y2ly1grq5ydhz7aj32yh1i5qnp.jpg
http://tva3.sinaimg.cn/large/007WH5Y2ly1grq5ydzudpj32yk1hswze.jpg
tsvn 发表于 2021-6-21 20:20
@leystage
我修改了一下
谢谢。我去简单看了一下，确实有些是机器人报告的。但也有些不是。就算背后是出于 KPI，批评者大概也是带了情绪。
结合这些新信息，我作为围观者对这件事的评价从怀疑是刷 KPI 转向中立观望。只针对这种行为本身，我是觉得是对代码质量有帮助的 PR，只要不有意拆分充数，本身并无不妥。但我也不喜欢那种纯粹出于 KPI 而产生的提交。先看看后续。
不过华为有做得好的，也有确实让人摇头的地方，如今已经很难在网络上不引起争议。这也是没办法的事情了吧。 要不楼主你去微博贴一下？看看高华和期货死人的回应
湾区高华码农别说鄙视国内屁民了。
连北美天坑专业出来的博士一样打心底里看不起
我他妈上次在加州去LBL的路上下车喝咖啡结账的时候犹豫了一下
一个哼字就出来了 http://tvax3.sinaimg.cn/large/6fcb9509ly1grq766s0i5j20hs0dcdh8.jpg
脚本机器人跑的 这贴的回复和隔壁帖回复还蛮有意思的 笑死了 你用机器人查bUG就不是刷KPI了么
华为为刷KPI 竟用机器人查BUG 不是很懂，人家骂你不要骚扰我了，你说我是拿机器人骚扰你的，就洗白了？ 今天看到一个17年的service层的代码单词拼错了，犹豫了半天最后还是没改 本帖最后由 tsvn 于 2021-6-21 23:06 编辑
对对对，你们说的都对不靠机器人，靠你们的嘴就可以了
大家都在刷KPI
mark 一记
较真是好事
— from Sony G8441, Android 9 of S1 Next Goose v2.4.4.1
以第一个接受的修改为例
由机器人发现报告
该文件的提交记录，审核这么NB的话，提交的时候怎么没检视出来
机器人不比你们的嘴强吗
同样这个文件也有个提交拼写错误的
你猜怎么着，这个人提交这么多，看着这位的提交记录，你们怎么说
mark下。补个邮件串的链接：
https://lkml.org/lkml/2021/6/18/153
你自己去看原本的邮件原文不就行了 没人点进来是因为懒得说了吧 再来再来
原来你们都是攒一堆BUG修复一起提交的啊，佩服佩服反正我是除了新增功能、特性外，改一个bug提交一次，因为都要验证是不是改好了，当然也有是共性问题，但是少
举个你们最喜欢的intel工程师提交的例子来看看
https://kernel.source.codeaurora.cn/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2e3025434a6ba090c85871a1d4080ff784109e1f&qt=author&q=feng.tang%40intel.com
确实是提交的比菊花的1行2行多啊
嗯，怎么都是注释，只y有一行有效代码
对比一下菊花该工程师的提交
提交日志是分开的，点进去看别人提交时间
都是同一时间提交的
这种还是算loc比较好一些 本帖最后由 fmonion 于 2021-6-22 09:13 编辑
结夜野棠. 发表于 2021-6-22 00:39
你自己去看原本的邮件原文不就行了 没人点进来是因为懒得说了吧
看了。屁大点事拿出来说，而且还不是一般的发个通告提醒所有人，而是指名道姓把菊厂抬出来，以泥潭的标准这妥妥的魔怔人了吧
楼主在挖一碗水有没有端平我觉也得没毛病。
-------
编辑下，下面有讨论解释详情。
这位维护者有道理确实是有道理，嘴贱也确实是嘴贱，都没毛病
本帖最后由 億万千 于 2021-6-22 01:18 编辑
不懂纯问，这些小修小补（应该是吧），cr的人会不会很烦
华为小修小补的量级，和其他组织比怎么样，最近的提交相比是否更密集？
如果华为最近小修补更密集，我觉得喷它没毛病，反过来如果这是通行做法，大家都在帮助清理代码但是你邮件点名华为，那就是对华为有成见 億万千 发表于 2021-6-22 01:15
不懂纯问，这些小修小补（应该是吧），cr的人会不会很烦
华为小修小补的量级，和其他组织比怎么样，最近的 ...
大家都是这么搞的，没看到跟别人有啥差距
附赠两个机器人测试出问题的修改记录
syzbot
kernel test bot
华为不是有自己的系统内核鸿蒙么，为啥要去人家linux的系统里改 本帖最后由 Damenly 于 2021-6-22 08:36 编辑
tsvn 发表于 2021-6-22 01:41
大家都是这么搞的，没看到跟别人有啥差距
附赠两个机器人测试出问题的修改记录
你这么有理有据那就去回lkml 邮件喷呗，不会连plain text 的邮件都不会发吧？syzbot 牛逼的部分在于有fuzz test 和reproductive environment，lkp 好在每个社区提交的单个patch 都会编译测试，lkp和syzbot都是直接向社区发邮件报bug的，你以为这两个测试只会跑compiler warning test ？另外你这么会搜，你去搜搜btrfs 邮件列表之前有个阿里的bot ，qu也是喷了他，清华的bot 也有，但是合进去了，为什么呢？你自己去看看人家commit 意义是不是比leizhen的这个意义大？另外linux社区是分module的，你找找看David当maintainer以来，btrfs有没有单个的typo fix？有没有单个的这种remove unnessary error message的？ Damenly 发表于 2021-6-22 08:16
你这么有理有据那就去回lkml 邮件喷呗，不会连plain text 的邮件都不会发吧？syzbot 牛逼的部分在于有fuzz ...
你要考虑到程序员的水平和陋习，清华一年才毕业多少个程序员 Damenly 发表于 2021-6-22 08:16
你这么有理有据那就去回lkml 邮件喷呗，不会连plain text 的邮件都不会发吧？syzbot 牛逼的部分在于有fuzz ...
这种东西有类似style guide的文档么？还是基本上就是maintainer口头说了算。 本帖最后由 Damenly 于 2021-6-22 08:58 编辑
fmonion 发表于 2021-6-22 08:47
这种东西有类似style guide的文档么？还是基本上就是maintainer口头说了算。
基本上是maintainer说了算，有的好说话就睁一只眼闭一只眼合掉了。
https://yhbt.net/lore/all/202103 ...haskar@gmail.com/T/
这个是之前有个人一直尝试提交typo fix，但是被拒绝了。
From: David Sterba @ 2021-03-25 12:49 UTC (permalink / raw)
To: Bhaskar Chowdhury; +Cc: clm, josef, dsterba, linux-btrfs, linux-kernel, rdunlap
On Thu, Mar 25, 2021 at 09:51:13AM +0530, Bhaskar Chowdhury wrote:
>
> s/contaning/containing
> s/clearning/clearing/
Have hou scanned the whole subdirectory for typos? We do typo fixing
about once a year in one big patch and won't fix them one by one.
On Fri, Mar 26, 2021 at 06:29:32AM +0530, Bhaskar Chowdhury wrote:>> s/reponsible/responsible/So this is exactly what I don't want to see happen - one patch per typo.I tried to explain it in the previous patch, please either fix all typosunder fs/btrfs or don't bother.
这件事情其实不复杂呀。这位程序员的提交有价值，但是方式可以改进。其他人如果有类似的情况，应该一起改进，比如合并提交之类。批评者有些扩大化，不必因此上升到公司层面，尤其是如果这不是公司普遍问题，甚至不是一家公司的问题时。当然，我觉得如果他只是因为之前的争论而首先发现了这个人的提交比较低效，以他为例来发起讨论，倒也不是问题。总之更多就事论事吧 Damenly 发表于 2021-6-22 08:54
基本上是maintainer说了算，有的好说话就睁一只眼闭一只眼合掉了。
https://yhbt.net/lore/all/202103250 ...
了解了多谢！
所以这种repo里不想处理小更改的原因是因为没有自动化测试，所以每个patch都要自己手测么。。。
今天干活的时候还在想，要是有人跟在我屁股后面帮我修lint的话那可真是太爽了。。。不过如果处理每个patch要花很多的时间就是另一回事儿 fmonion 发表于 2021-6-22 08:59
了解了多谢！
所以这种repo里不想处理小更改的原因是因为没有自动化测试，所以每个patch都要自己手测么 ...
并不是没有自动化测试，每轮RC 基本上负责的mainatainer都会在不同的环境下好很多遍测试，CI也是有的。
linux社区合patch是要人review的，一个patch就是一封邮件，每个typo一封邮件这邮箱就会淹没其他的。你也知道review是很耗精力的，再看这种typo 然后一个个给reviewed-by,然后maintainer再一个个merge很浪费资源。 人家说大公司要做的专业点，还有什么大公司参与提交的，对比下不就完了 zqr211 发表于 2021-6-21 22:38
这个最有意思的是
据说现在扒出来 这个说华为刷kpi的 是个华裔加在日本公司工作。。。。
你这反华是华为的华么 菊花真是牛逼，换个公司早就被笑死了，还这么多考究和围X救华
流石菊花，任何沾上的话题都是屎坑 不针对菊花，这些人写代码时，在注释里开个拼写检查吧，比语法检查门槛低多了。 Damenly 发表于 2021-6-22 08:16
你这么有理有据那就去回lkml 邮件喷呗，不会连plain text 的邮件都不会发吧？syzbot 牛逼的部分在于有fuzz ...
以前的我：编译告警是啥玩意，这影响我程序了吗
现在的我：注释里的拼写错误改一下
确实菊花的垃圾机器人只会跑compiler warning test，不如syzbotNB
门限给的高也不行
社区各种各样的人都有，有人不能接受提交的拼写错误，有人能接受，有人会去争辩，有人不去
author Chengyang Fan <cy.fan@huawei.com> 2021-06-16 17:59:25 +0800
committer David S. Miller <davem@davemloft.net> 2021-06-16 12:41:01 -0700
commit d8e2973029b8b2ce477b564824431f3385c77083 (patch)
tree 1050cc89d9bd434a0e42ddaf80facd3e3bb45caf /net/ipv4/igmp.c
parent c0d982bf825f81d86f4f0b44436c255873881c19 (diff)
download linux-d8e2973029b8b2ce477b564824431f3385c77083.tar.gz
net: ipv4: fix memory leak in ip_mc_add1_src
BUG: memory leak
unreferenced object 0xffff888101bc4c00 (size 32):
comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................
backtrace:
[<00000000f17c5244>] kmalloc include/linux/slab.h:558
[<00000000f17c5244>] kzalloc include/linux/slab.h:688
[<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971
[<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095
[<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416
[<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294
[<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423
[<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857
[<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117
[<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128
[<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125
[<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125
[<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47
[<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xae
In commit 24803f38a5c0 ("igmp: do not remove igmp souce list info when set
link down"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,
because it was also called in igmpv3_clear_delrec().
Rough callgraph:
inetdev_destroy
-> ip_mc_destroy_dev
-> igmpv3_clear_delrec
-> ip_mc_clear_src
-> RCU_INIT_POINTER(dev->ip_ptr, NULL)
However, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't
release in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the
NULL to dev->ip_ptr. As a result, in_dev cannot be obtained through
inetdev_by_index() and then in_dev->mc_list->sources cannot be released
by ip_mc_del1_src() in the sock_close. Rough call sequence goes like:
sock_close
-> __sock_release
-> inet_release
-> ip_mc_drop_socket
-> inetdev_by_index
-> ip_mc_leave_src
-> ip_mc_del_src
-> ip_mc_del1_src
So we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free
in_dev->mc_list->sources.
Fixes: 24803f38a5c0 ("igmp: do not remove igmp souce list info ...")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chengyang Fan <cy.fan@huawei.com>
Acked-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/igmp.c')
-rw-r--r-- net/ipv4/igmp.c 1
1 files changed, 1 insertions, 0 deletions
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 7b272bbed2b43..6b3c558a4f232 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1801,6 +1801,7 @@ void ip_mc_destroy_dev(struct in_device *in_dev)
while ((i = rtnl_dereference(in_dev->mc_list)) != NULL) {
in_dev->mc_list = i->next_rcu;
in_dev->mc_count--;
+ ip_mc_clear_src(i);
ip_ma_put(i);
}
}
页:
[1]
2