Linus Torvalds FURIOUS ‘Stop Doing These Horrible Things’

Added: 2026-05-05

[00:00:00]This recent patch series and pull request really got Lionus Torvalds, the creator of Linux, fired up. We're going to be going through all of this today and reading through. I'll post a link in the description below if you want to read through yourself. Anyways, the patch series here was in summary made to avoid excessive dut and audit context setup and reset paths when the audit system is enabled. It can do a lot of get file system print working directory calls to get references to the file system print working directory and then releasing those references back with path put later. So overall this patch series just speeds up the Linux virtual file system audit behavior by cutting down unnecessary reference count churn on the current working directory path.

[00:00:39]That's what fpwd stands for. And when this audit is enabled, repeated functions that could get called a lot like get file system, pwd, and path put functions could create lock contention and hurt performance, especially on large multiCPU systems. So that was the intention here for this patch series to really alleviate that sort of issue on a lot of CPUs that they claim it's becoming more and more common these days. Anyways, this was met with a lot of push back from Lionus. Let's see what he has to say and the response to all this. So, let's get into it. I really don't like this one and I'm going to at least delay pulling it because this really feels wrong to me. It feels like a hack just looking at some of the paths that get modified. We have that copy file system strct which does path get file system root and then the very next line ends up being get file system pwd pool locked old and then file system pwd that copies the pwd differently. And the only reason PWD is different is because the audit code treats the PWD and root differently. And that in turn is because the audit code is just historical and broken and can't deal with CH root environments. And what I believe Lionus is trying to say here is that root and pwd are actually two related pieces of a file system state. In one function root is copied the normal straightforward way which we see here. But when it comes to the print working directory, it is getting copied using a new special helper function that we see here. This seems to make Lionus uncomfortable because two similar things are now being handled in in two very different ways.

[00:02:14]So from his point of view here, they're not being treated differently because PWD is fundamentally special in some way. It's only special because the audit subsystem has old behavior that depends on it. So to him, this new helper looks like a workaround, not an actual fix.

[00:02:29]Moving on, the PWD and root paths are two sides of the same coin and any code that treats them differently is wrong.

[00:02:36]So, this basically takes an audit mistake and makes that mistake visible to non- audit users. I absolutely hate it. Strong words from Lionus as we've seen in the past. I'm going to think about this more and maybe I'll end up saying it's still ugly, but whatever, I'll pull it anyway. But right now, I'm going there has to be a better way. And maybe you can convince me this hackery is the right thing. But it really is rubbing me the wrong way entirely. The hackery is evident everywhere like that.

[00:03:03]Which means how many extra references are we holding in the working directory.

[00:03:07]Release one of those references and decrement the count and keep continuing this in the while loop here until all extra references are completely gone because it's obviously too painful to switch everything over to having a decrement by more than one. And this code path is simply not worth the pain because it's just for a stupid audit special case that is largely historical.

[00:03:28]So I see why this all is done. But at the same time it really strikes me as very very ugly. No, I don't have a solution. My gut feel is that a an audit is wrong to begin with to think that only pwd is special and that root is always printed as null. B audit should be taking a ref struck path in the first place but to strct file system strct again treating pwd differently from root is a fundamental mistake always was the only difference between the two is whether you had slash at the beginning of the path or not and the trivial different system calls to set them but as long as it was a mistake just inside the auto path who cares but with this pull it's just broken garbage escaping outside those confines so for example I'd be a lot happier with some kind of borrow the whole strct file system model where audit gets a new borrow reference to the whole strruct and then places that actually change strruct file system struck would create a copy of it and replace any pending audit users with that copy. So I believe Lionus is saying that he would much prefer if an audit would just hold an entire reference to a file system that would contain things like root and path in the actual structure. That way, as long as an audit is using it, the whole snapshot stays valid together. Then, if something needs to change the file system state, you can make a copy of the whole file system and apply the change to the copy. Anyways, moving on. There are exactly three such places that change it all right next to each other. Set file system root, set file system pwd, and change root file system references. And we already have the lock that protects all of this. It's file system sequence. And we could add a new strruct audit borrow strruct that audit uses which has a pointer to the strruct file system strct and the audit would borrow the whole thing. We'd keep a list of current borrowers and unbarorrow it at the end and absolutely nothing would change in the core path handling the couple of places that change the struck file struck could look at the list of borrowers synchronize them and create a new fake strruct file system struck just for them and maybe increment the references at that point.

[00:05:36]And it would actually improve on the audit code because now audit would at least have the root path too even though it obviously doesn't use it and always thinks root is a global root thing. And no, nobody could ever bother to fix audit but at least conceptually it would set the infrastructure for the audit paths getting this right. Yes. Yes. The above is very very handwavy and I didn't write the code and possibly the rantings of an insane person. Luckily Lionus is realizing he could be the one in the wrong here. I didn't think a lot about this. I just looked at the patch series and threw up in my mouth a little and tried to think of maybe we could do it differently. And the above is a rough draft of something that might work.

[00:06:16]Please humor me and think about it at least. Sign off Lionus. So in short here, Lionus is reacting to this patch series and pull request really as a design critique. He's not saying that the patch is fundamentally broken necessarily here. He is saying that the approach is wrong. The patch here is actually optimizing audit but at the cost of making the core file system structure handling less clean. This is very typical of Lionus to call out and after he's been doing reviews like this for decades, it's clearly not passing his smell test. But it doesn't stop here as Christian here responds as he replies to Lionus. I don't really like it either. Here to the one where Lionus said he doesn't like because this really feels wrong to me. It is. I commented on that explicitly when the series was proposed. We keep going down and maybe you can convince me that this hackery is the right thing. It isn't and I'm not going to try. That's a pretty bold one.

[00:07:08]Really is rubbing me the wrong way entirely. I'm sorry. I can't offer more than agreement with you right now. The only reason I considered it was that my appetite for audit internals is very very low. But to be honest, that shouldn't have led me to accept the hackiness. So again, no long-winded argument for me. I dropped this one from the other pull request. the continuous integration is still running and then I'll resend. So basically full conceding that yes Lionus, you're right. I don't like it either and I'm just going to drop it. So the answer to Lionus is not a technical rebutal. It's just a concession it seems like. So clearly there was an understanding here. The response was basically a total agreement and a withdrawal, not a debate about whether Lionus was wrong or not. And overall this one was fairly tame. But we had another one pop up pretty much right after this which wasn't as tame. Let's get into that one now. But before we do, make sure to check out starlabs.systems where you can use my code savvy3 for an extra 3% off these amazing laptops. I personally use one as it's Linux first with no compromises. It comes pre-installed with Linux and has a wonderful premium build for a workstation. All this with core boot, which is an open- source firmware ideal for people who care about code, privacy, and performance. Anyways, you can get your new workstation today at starlabs.systems.

[00:08:26]with code savvy 3 for an extra 3% off.

[00:08:29]So we move from the file system virtual file system and audit code to a different subsystem the core kernel synchronization or the RCU and in this thread and pull request there's a round or batch of changes for the RCU which stands for read copy update subsystem basically some code cleanup and refactoring bug fixes tweaks and the maintainer here is asking Lionus to actually merge the batch of improvements this is all set for Linux kernel 7.1 but Lionus was in a mood Because in response to the rcu stall of the add boot parameter rcu stall panic kconfig, this is a kernel config parameter option to allow triggering a kernel panic on the rcu stall via kernel boot parameter.

[00:09:11]Linus starts out hot by saying no. Damn it, stop doing these horrible things.

[00:09:16]I've said this a million times by now.

[00:09:18]The kernel config phase is probably one of the biggest pain points for random new people trying to build their own kernels. And we do not ask people stupid things. People who want this can damn well use system control or ctl or maybe some kernel command line option instead.

[00:09:35]And we do not make life worse for everybody else. I have removed that disgusting kernel Kconfig option and I want you to make it very clear to people that the Kconfig files aren't your personal playgrounds. They are the most visible interface to normal users that we want to encourage to build their own kernels so that they can participate in kernel development. And just like Lionus' number one rule, do not break user space. I think he's applying it here as well, just saying don't mess up userfacing interfaces. This applies to things like kernel configs as kconfig is one of the first things users see part of how they learn and interact with the kernel effectively almost a form of user interface. So people next time you feel the urge to add a kconfig option take a deep breath and look at the kconfig file and go maybe I can remove this other useless option instead. Let's improve on the kernel instead of making things worse. Signed off Lionus. Now, this one's a little more heated, and this all seems to come from a long-running frustration where Linus thinks developers often treat the Kconfig as an easy dumping ground for switches without caring that every added option makes the configuration experience worse for users. One, it seems unnecessary to even add this in. Two, it reflects a repeated bad pattern where again, even he said it a million times by now, as clearly he has this pent-up frustration about the K config bloat in general. And three, it touched a userfacing interface, which he is very protected of, especially something that affects ordinary users directly. I probably wanted to be on the end of the first patch series that we just reviewed instead of this one, but let's see how we get a response to all this. It was actually very well taken.

[00:11:16]Apologies. Would making this instead be a colonel boot parameter be acceptable?

[00:11:21]Thanks, Paul. Just asking a question at this point. Does Linus blow up? No, not this time. We already have a system control for this and you should already be able to use a boot parameter for it with just systemctl kernel panic on rcu stall equal to true. Not that I've tried it, so maybe there's some bug somewhere or something I've overlooked, but I really think the whole kernel config option was entirely redundant to begin with. Sign off Linus. And then Paul responds with given the recent improvements to boot config using the systemctl kernel boot parameters should be just fine before those improvements associating particular kernel boot parameters with all kernels was often problematic in large sets of data centers. Even worse were use cases where kernel boot parameters needed to be set differently for different kernel versions. But for most kernel boot parameters, including this one, this should be fine. Now more work is needed for early boot parameters and that is in progress. In this case, I simply failed to get all the pieces in my head at the same time. In particular, I forgot that you can specify kernel boot parameters for systemctl. Thanks, Paul. Just acknowledging that he made a mistake. A fair way to see devs simply accept the fact that they made a mistake. And you can tell Lionus really backed off as soon as he understood that the dev here wasn't taking things personally, understood the mistake. We get another colonel dev who also chimes in and says, "Lus, I'm okay with dropping it and thanks for doing that. No problem." And in the end, these two threads and pull requests show two classic aspects of the Linux kernel development cycle. On one side, subsystem maintainers submit pull requests that are technically sound and often motivated to fix real problems.

[00:12:53]Like we saw in the first one, performance issues in audit and on the second one, added flexibility to the RCU behavior. Lionus Torvald acts as the final gatekeeper and he has to push back quite a bit. Not because these ideas were necessarily wrong or useless, but the way that they get implemented go against deep principles that only seasoned people like Lionus really understand. That's why you get these types of critiques from Lionus. And you can tell maintainers like Christian and Paul who didn't escalate the disagreement. They just acknowledged the concerns and adjusted course, which is always great to see. As it's not always the case, sometimes we do get some back and forth. Luckily with this one, started pretty hot but ended up simmering down. Lionus will continue to enforce this as long as he's a part of the Linux kernel. What did you think about Lionus' approach on all these, let me know in the comment section below.

[00:13:40]Again, if you want to read through these, I will post a link to both threads in the description below. Don't forget to subscribe below and smash that like button on the way back up. You made it to the end of the video. Thanks for watching. I'll catch you in another one.

[00:13:52]Linux can be hard to understand, but I take the most commonly used terms, commands, and subjects in Linux, and I break them down into simple to read documents, including Linux terms, flashcards, a checklist, a cheat sheet, and a mindm. And if you're ready to level up your Linux experience and knowledge, go to savvyick.com now and get access to these sheets.