Viewing profile — gregkh

The members of the kernel security team are not allowed to tell their employers anything that happens on the security list. They are there as individual members, not as employees. …

They hide structures very easily, allowing programmers to accidentally put them on the stack or use them as parameters in functions where they shouldn't be doing so. By forcing "st…

The amount of resources and other stuff that the LF provides to the Linux kernel community has increased over the years, including last year. Just because new people are brought in…

Did anyone think to actually ask the developer who is maintaining the LTS kernel versions why he made that change (back in February?), i.e. me? {sigh} No, I guess that would take t…

No, the only rust code accepted into any released kernels is basic framework infrastructure so that someday, maybe, in the future, real functionality could be written in rust. Ther…

This already happens today at many companies. I write a few of these a year for companies that I do not work at, and have been for the past decade or so. It's not unusual and the c…

Corporate guys "manage me"? Have you talked to any corporate guys who have actually tried that and discussed the results with them? :)

Yes, and because of that, we created a new process for those types of issues (i.e. broken hardware problems that need more coordination.) That process is documented at https://www.…

I've described how we (the kernel security team) handles this type of things many times, and even summarized it in the past here: http://www.kroah.com/log/blog/2018/02/05/linux-ker…

While I did drop by a lot, you aren't describing me, but rather another Linux kernel developer who worked at IBM in our group at the time who is by far more brilliant and smarter t…

I'm not understanding the question here at all, sorry, can you please rephrase it? And if you have questions about how this happened, look at the source for when it was merged, it'…

The person who started udev (i.e. me), and the person who did the majority of the work on udev to make it into the proper solution for everyone (i.e. Kay Sievers), both agreed that…

Off the top of my head, no. The big "downside" is that it takes more work on the patch submitter side. But the benefits in the end are almost always more than worth it (easier revi…

Merge the portions that you know are correct and will have no affect on anyone else now, which makes future work easier as you do not have to keep those "working" commits up to dat…

Thanks for the support. I also now have submitted a patch series that reverts the majority of all of their contributions so that we can go and properly review them at a later point…

Why is it "excessive"? We are running 30+ fixes a day in these kernel releases, who would benefit if we delayed in getting those known-bug/security fixes out to the world quickly a…

So you want us to just stop fixing bugs and pushing out those fixes to users? That feels risky, if you do not want to upgrade to solve known problems, that's fine, feel free to ski…

Time to get a new ISP? :)

And what would that help solve?

We have so many different CI systems running on the kernel on a hourly basis. We have the 0-day bot from Intel that runs so many things on all developer trees. We have kernelci run…

Simplest thing to do, just run Linus's latest releases (the -rc releases), or from his git tree, on your machine and report any problem. Second-simplest thing to do is to run the l…

If people don't report bugs, we don't know they are there as it "works for me!". This isn't "negativity", this is people not understanding how the process works :) And you're welco…

Where in the current CI that we have today is lacking that needs to be improved? We always want more testing and testers, what is preventing everyone from helping with this?

I get a vacation? Hah!

Everyone gets older, the alternative isn't as attractive :) Seriously, the kernel averages about 200-250 new contributors every release (i.e. every 2 1/2 months). We are not starve…