3 ms·

>> it has a lack of testing and code review Is that really true? I mean my first reaction is that the linked article / thread is a direct counterpoint. All the

>> it has a lack of testing and code review Is that really true? I mean my first reaction is that the linked article / thread is a direct counterpoint. All the review and testing the rust facilities are going through. Are these changes not going through substantively the same process as other proposed changes to the kernel?

medstrom 5y ago
I don't think it lacks code review, it's famously hard to get half-baked stuff through Torvalds.
- staticassertion 5y ago
  That isn't really true.
- wott 5y ago
  The ton of driver code that piles up in the Linux kernel every minute doesn't go through Torvalds. It is delegated. And my reviewing of a few drivers source short commits is enough to tell me that those delegates do not perform a satisfyingly thorough review by any mean. Heck, I saw patches of just a couple dozen lines which exhibited bad copy-pasting errors anyone without prior knowledge could have spotted. You don't need to know what the code does to spot some, you don't either need to know what the driven device does to spot some: purely formal errors with bad macros definitions for example. This kind of stuff wouldn't even pass the first internal review where I worked, which just looked at formal appearance (then there were more in depth reviews, and then there was an external review, but we'd make as sure as possible that our code would be clean before going out). So first you have people (employees of company A) which sends code to a public, external project without having done a proper internal review. Then you have someone else (employee from company B) who claims to have reviewed the commit but hasn't done it properly or at all. And then possibly a third someone who validates this, but doesn't actually check either. It has become a job, a task like another, with the same people who do the same sloppy job as quickly as possible to get rid of it and go home earlier or slack, in the same proportion that you can find in any other position in the world.
- Mic92 5y ago
  They don't even do CI when reviewing patches. Some of the code they review on mailing lists does not even compile.
- yissp 5y ago
  The recent UMN controversy would seem to disprove this.
rocqua 5y ago
On testing, linux does not come with a suite of regression tests.
- cesarb 5y ago
  > linux does not come with a suite of regression tests https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing?h=v5.13 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
geofft 5y ago
The fact that a process is burdensome does not mean it is necessarily effective. Look at the seq_file thing Qualys discovered the other day. The overflow was obvious if you thought about it, and all Qualys did was think about it. But the bug was present since 2014. https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-loc... Linus's law is empirically untrue for security bugs - many eyes don't actually spot them. Moreover, we have computers, which are good at doing repetitive and detail-oriented tasks with 100% accuracy. Why not use them?
- bowyakka 5y ago
  Hmmm while I agree with you, doesn't the fact qualsys went looking out eyes on it? We sure that a seq_lock bug isn't present in say OSX, QNX, Windows?
staticassertion 5y ago
No, what we have here is definitely more of an exception - sort of like an RFC for larger changes that could take months or years to play out. The vast majority of code changes do not go through this.

medstrom 5y ago

I don't think it lacks code review, it's famously hard to get half-baked stuff through Torvalds.

staticassertion 5y ago
That isn't really true.
wott 5y ago
The ton of driver code that piles up in the Linux kernel every minute doesn't go through Torvalds. It is delegated. And my reviewing of a few drivers source short commits is enough to tell me that those delegates do not perform a satisfyingly thorough review by any mean. Heck, I saw patches of just a couple dozen lines which exhibited bad copy-pasting errors anyone without prior knowledge could have spotted. You don't need to know what the code does to spot some, you don't either need to know what the driven device does to spot some: purely formal errors with bad macros definitions for example. This kind of stuff wouldn't even pass the first internal review where I worked, which just looked at formal appearance (then there were more in depth reviews, and then there was an external review, but we'd make as sure as possible that our code would be clean before going out). So first you have people (employees of company A) which sends code to a public, external project without having done a proper internal review. Then you have someone else (employee from company B) who claims to have reviewed the commit but hasn't done it properly or at all. And then possibly a third someone who validates this, but doesn't actually check either. It has become a job, a task like another, with the same people who do the same sloppy job as quickly as possible to get rid of it and go home earlier or slack, in the same proportion that you can find in any other position in the world.
Mic92 5y ago
They don't even do CI when reviewing patches. Some of the code they review on mailing lists does not even compile.
yissp 5y ago
The recent UMN controversy would seem to disprove this.

rocqua 5y ago

On testing, linux does not come with a suite of regression tests.

cesarb 5y ago
> linux does not come with a suite of regression tests https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing?h=v5.13 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

geofft 5y ago

The fact that a process is burdensome does not mean it is necessarily effective. Look at the seq_file thing Qualys discovered the other day. The overflow was obvious if you thought about it, and all Qualys did was think about it. But the bug was present since 2014. https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-local-privilege-escalation-linux.txt https://www.qualys.com/2021/07/20/cve-2021-33909/sequoia-loc... Linus's law is empirically untrue for security bugs - many eyes don't actually spot them. Moreover, we have computers, which are good at doing repetitive and detail-oriented tasks with 100% accuracy. Why not use them?

bowyakka 5y ago
Hmmm while I agree with you, doesn't the fact qualsys went looking out eyes on it? We sure that a seq_lock bug isn't present in say OSX, QNX, Windows?

staticassertion 5y ago

No, what we have here is definitely more of an exception - sort of like an RFC for larger changes that could take months or years to play out. The vast majority of code changes do not go through this.