是谁在刷KPI 驳：Linux内核维护者点名华为开发者...

acgcn

当996刷kpi遇到用爱发电

Damenly

tsvn 发表于 2021-6-22 11:42
以前的我：编译告警是啥玩意，这影响我程序了吗
现在的我：注释里的拼写错误改一下

unreferenced object 0xffff888101bc4c00 (size 32):
  comm "syz-executor527", pid 360, jiffies 4294807421 (age 19.329s)

我认错，看来华为的bot是会跑syzkaller的

Troy_VoV

为什么看v2这个帖子要我的手机号

杨雪崩

seelestil 发表于 2021-6-22 11:47
@wuzhou6058

这里在讨论华为，跟个怨妇一样在扣鹅评论里往米忽悠原神拐，自己也不撒泡尿照照自己，**，呸 ...

………无话可说

开起

如果是自己公司的员工这么改自己公司的代码，那么主管……
如果是别人公司的员工这么改自己负责维护的代码，那么……

有火气也正常

—— 来自 OnePlus KB2000, Android 11上的 S1Next-鹅版 v2.4.4.1

fmonion

开起 发表于 2021-6-22 12:41
如果是自己公司的员工这么改自己公司的代码，那么主管……
如果是别人公司的员工这么改自己负责维护的代码 ...

自己看上面的讨论。事主提交错误信息清理肯定算提升代码质量吧。部分拼写检查也合并了，又不是故意拆开。平均下来一天不到一个patch也算不上刷业绩。
https://git.kernel.org/pub/scm/l ... eizhen%40huawei.com

我在公司处理个1行patch也就半分钟的事，如果有人当免费劳动力干这种清理当然非常欢迎。。。

当然上面有懂的大神说现在内核合并patch非常麻烦，有抱怨也算可以理解就是了。个人感觉在内核社区之外这种抱怨不是常态。我司还有组专门做代码质量清理的机器人给公司里用呢

Jet.Black

fmonion 发表于 2021-6-22 12:59
自己看上面的讨论。事主提交错误信息清理肯定算提升代码质量吧。部分拼写检查也合并了，又不是故意拆开。 ...

半分钟能跑完个什么测试，引入了bug算谁的？将来出问题还不是要review的人管

13号

邮件review的内核大佬的工作方式确实不熟。

以gitlab、github之类的比较常见的工作平台上来说： 你提交个commit，写着typo fix，修了一两处地方，看一眼，5秒钟，直接就approve了。
你提交一个commit，里面有100来个typo fix， 那我是要慢慢的仔细看了， 鬼知道你是不是手**如用了写脚本啊搞了全文替换啊，会不会刚好修改到了不该改的地方呢？

tsvn

Damenly 发表于 2021-6-22 11:52
unreferenced object 0xffff888101bc4c00 (size 32):
  comm "syz-executor527", pid 360, jiffies 42948 ...

还会用kmemleak呢


aboutsummaryrefslogtreecommitdiffstats       

log msg


diff options
context:       
3
space:       
include
mode:       
unified
author        Wang Hai <wanghai38@huawei.com>        2020-11-09 22:09:13 +0800
committer        Jakub Kicinski <kuba@kernel.org>        2020-11-11 14:39:23 -0800
commit        fa6882c63621821f73cc806f291208e1c6ea6187 (patch)
tree        88e25751eb41de5685337ea2c3de7cca8898184d
parent        e87d24fce924bfcef9714bbaeb1514162420052e (diff)
download        linux-fa6882c63621821f73cc806f291208e1c6ea6187.tar.gz
tipc: fix memory leak in tipc_topsrv_start()
kmemleak report a memory leak as follows:

unreferenced object 0xffff88810a596800 (size 512):
  comm "ip", pid 21558, jiffies 4297568990 (age 112.120s)
  hex dump (first 32 bytes):
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
    ff ff ff ff ff ff ff ff 00 83 60 b0 ff ff ff ff  ..........`.....
  backtrace:
    [<0000000022bbe21f>] tipc_topsrv_init_net+0x1f3/0xa70
    [<00000000fe15ddf7>] ops_init+0xa8/0x3c0
    [<00000000138af6f2>] setup_net+0x2de/0x7e0
    [<000000008c6807a3>] copy_net_ns+0x27d/0x530
    [<000000006b21adbd>] create_new_namespaces+0x382/0xa30
    [<00000000bb169746>] unshare_nsproxy_namespaces+0xa1/0x1d0
    [<00000000fe2e42bc>] ksys_unshare+0x39c/0x780
    [<0000000009ba3b19>] __x64_sys_unshare+0x2d/0x40
    [<00000000614ad866>] do_syscall_64+0x56/0xa0
    [<00000000a1b5ca3c>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

'srv' is malloced in tipc_topsrv_start() but not free before
leaving from the error handling cases. We need to free it.

Fixes: 5c45ab24ac77 ("tipc: make struct tipc_server private for server.c")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Link: https://lore.kernel.org/r/202011 ... anghai38@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat
-rw-r--r--        net/tipc/topsrv.c        10       
1 files changed, 8 insertions, 2 deletions
diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index 5f6f86051c830..13f3143609f9e 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -664,12 +664,18 @@ static int tipc_topsrv_start(struct net *net)

        ret = tipc_topsrv_work_start(srv);
        if (ret < 0)
-                return ret;
+                goto err_start;

        ret = tipc_topsrv_create_listener(srv);
        if (ret < 0)
-                tipc_topsrv_work_stop(srv);
+                goto err_create;

+        return 0;
+
+err_create:
+        tipc_topsrv_work_stop(srv);
+err_start:
+        kfree(srv);
        return ret;
}

leystage

台球论坛网友 发表于 2021-6-22 12:22
有毛的价值，一家科技公司改拼写错误然后当成__技术__社区贡献大肆宣传

真尼玛不要脸 ...

要看整体 commit 里多少是这类的。
如果大量这类，大肆宣传贡献大就很成问题。是不光彩的做法。这也是我在另一个帖子里提的观点。
如果仅少数这类，那更多是看看如何改进方式，提高效率。
但我没去看比例如何，所以只给出评判方式而不下结论。

Damenly

tsvn 发表于 2021-6-22 13:54
还会用kmemleak呢

还会用这些呢

1. CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
   
2. # CONFIG_DEBUG_VIRTUAL is not set
   
3. # CONFIG_DEBUG_MEMORY_INIT is not set
   
4. # CONFIG_DEBUG_PER_CPU_MAPS is not set
   
5. # CONFIG_DEBUG_SHIRQ is not set
   
6. CONFIG_SCHED_DEBUG=y
   
7. # CONFIG_DEBUG_TIMEKEEPING is not set
   
8. CONFIG_DEBUG_PREEMPT=y
   
9. CONFIG_LOCK_DEBUGGING_SUPPORT=y
   
10. CONFIG_DEBUG_RT_MUTEXES=y
    
11. CONFIG_DEBUG_SPINLOCK=y
    
12. CONFIG_DEBUG_MUTEXES=y
    
13. CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
    
14. CONFIG_DEBUG_RWSEMS=y
    
15. CONFIG_DEBUG_LOCK_ALLOC=y
    
16. # CONFIG_DEBUG_LOCKDEP is not set
    
17. CONFIG_DEBUG_ATOMIC_SLEEP=y
    
18. # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
    
19. # CONFIG_DEBUG_KOBJECT is not set
    
20. CONFIG_DEBUG_LIST=y
    
21. # CONFIG_DEBUG_PLIST is not set
    
22. # CONFIG_DEBUG_SG is not set
    
23. # CONFIG_DEBUG_NOTIFIERS is not set
    
24. # CONFIG_DEBUG_CREDENTIALS is not set
    
25. # CONFIG_RCU_EQS_DEBUG is not set
    
26. # CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
    
27. # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
    
28. # CONFIG_HIST_TRIGGERS_DEBUG is not set
    
29. # CONFIG_DEBUG_TLBFLUSH is not set
    
30. # CONFIG_IOMMU_DEBUG is not set
    
31. CONFIG_DEBUG_BOOT_PARAMS=y
    
32. # CONFIG_CPA_DEBUG is not set
    
33. # CONFIG_DEBUG_ENTRY is not set
    
34. # CONFIG_DEBUG_NMI_SELFTEST is not set
    
35. # CONFIG_X86_DEBUG_FPU is not set
    
36. # CONFIG_PUNIT_ATOM_DEBUG is not set
    
37. CONFIG_FAULT_INJECTION_DEBUG_FS=y

复制代码

tsvn

台球论坛网友 发表于 2021-6-22 12:22
有毛的价值，一家科技公司改拼写错误然后当成__技术__社区贡献大肆宣传

真尼玛不要脸 ...

眼睛看不见拼写错误的提交占比 7/159 但是有4次提交是一次提交给社区，不过社区是分开列出来的眼睛看不见intel工程师提交一次都是注释只是进来拉泡屎污染版面

顺便告诉你代码统计的都是非空非注释

fmonion

Jet.Black 发表于 2021-6-22 13:36
半分钟能跑完个什么测试，引入了bug算谁的？将来出问题还不是要review的人管 ...

半分钟是我看代码的时间。公司流程里面自动化测试和CI都是不需要我管的，写patch的人自己走。包括查拼写错误之类的都是在自动化流程之内的。如果有引入bug的风险的而且测试都覆盖不到的话，那恐怕这修的东西也不是像事主说的那样，无足轻重纯粹刷分吧。

当然内核大佬的工作方式我确实不熟，就不多评价了，只是想说不是所有地方都这么搞。

Jet.Black

fmonion 发表于 2021-6-22 14:34
半分钟是我看代码的时间。公司流程里面自动化测试和CI都是不需要我管的，写patch的人自己走。包括查拼写 ...

代码审查半分钟也太神奇了，一般人怕是连文件路径也没看完。

fmonion

Jet.Black 发表于 2021-6-22 14:49
代码审查半分钟也太神奇了，一般人怕是连文件路径也没看完。

个人没用过gitlab，不过可以参见51楼

Jet.Black

fmonion 发表于 2021-6-22 14:54
个人没用过gitlab，不过可以参见51楼

非必要的代码提交，浪费的是所有人的时间。

上下游各种测试编译资源的浪费，上下游各个分支代码冲突解决的时间。

项目人少当然可以随便搞了

tsvn

leystage 发表于 2021-6-22 13:57
要看整体 commit 里多少是这类的。
如果大量这类，大肆宣传贡献大就很成问题。是不光彩的做法。这也是我 ...

菊花在内核贡献度高的原因一个是给钱让提交排名靠前的几个人提交的时候挂上菊花，另外一个是自动机器人持续构建发现缺陷

大可不必纠结

Nanachi

https://www.cnbeta.com/articles/tech/1143971.htm

当事人终于在两天之后进行了回复：

我过去对内核的贡献主要是优化ARM64 SMMU驱动程序的性能，包括iova优化、严格模式优化和懒加载模式优化。同时也致力于一些ARM SoC驱动程序的开发。

在时间和精力允许的情况下，我还为Linux内核的其他模块做贡献，找到一些可以改进的地方，进行了一些清理(cleanup)的工作。

今后，我将继续为Linux社区做出越来越重要的贡献。



而管理员收到这封回复后，回信表示：肯定他过去为社区做了很多重要贡献。

并且，也不是说他另外做的那些“小清理”工作不重要，但请下次合成一个大的patch集来提交。

而他对其背后雇主华为的巨大贡献也非常熟悉，完全没有质疑。

Karuboniru

一方面名词修改不仅限于spelling，还有类似于 normalization 等等都是纯粹的改名字。另一方面 git log 里面都是被合并的代码，要统计提交的代码需要去邮件列表/patchwork找。

Karuboniru

https://lkml.org/lkml/2021/6/8/2050 比如这个 patch，想要修正缩进的空格，被拒绝了，argue没有下文。这类在 git 里面就会看不到

Damenly

UPDATE: 晚上有酷派的人也投了类似的patch，貌似就是之前送话费送的那个酷派手机。
https://lore.kernel.org/linux-bt ... 8057e9@gmx.com/T/#t
鉴于这个人看起来还是个新手，Qu先喷了然后给了reviewed-by, SUSE的人也在讨论是不是应该一视同仁。

btrfs wiki也更新了

https://btrfs.wiki.kernel.org/in ... as#Cleanup_projects