So we've had a fairly quiet last week, but I think it was good that we ended up having that extra week and the final rc8.
Even if the reason for that extra week was my travel schedule rather than any pending issues, we ended up having a few good fixes come in, including some for some bad btrfs behavior. Yeah, there's some unnecessary noise in there too (like the speling fixes), but we also had several last-minute reverts for things that caused issues.
One _particularly_ last-minute revert is the top-most commit (ignoring the version change itself) done just before the release, and while it's very annoying, it's perhaps also instructive.
What's instructive about it is that I reverted a commit that wasn't actually buggy. In fact, it was doing exactly what it set out to do, and did it very well. In fact it did it _so_ well that the much improved IO patterns it caused then ended up revealing a user-visible regression due to a real bug in a completely unrelated area.
The actual details of that regression are not the reason I point that revert out as instructive, though. It's more that it's an instructive example of what counts as a regression, and what the whole "no regressions" kernel rule means. The reverted commit didn't change any API's, and it didn't introduce any new bugs. But it ended up exposing another problem, and as such caused a kernel upgrade to fail for a user. So it got reverted.
The point here being that we revert based on user-reported _behavior_, not based on some "it changes the ABI" or "it caused a bug" concept. The problem was really pre-existing, and it just didn't happen to trigger before. The better IO patterns introduced by the change just happened to expose an old bug, and people had grown to depend on the previously benign behavior of that old issue.
And never fear, we'll re-introduce the fix that improved on the IO patterns once we've decided just how to handle the fact that we had a bad interaction with an interface that people had then just happened to rely on incidental behavior for before. It's just that we'll have to hash through how to do that (there are no less than three different patches by three different developers being discussed, and there might be more coming...). In the meantime, I reverted the thing that exposed the problem to users for this release, even if I hope it will be re-introduced (perhaps even backported as a stable patch) once we have consensus about the issue it exposed.
Take-away from the whole thing: it's not about whether you change the kernel-userspace ABI, or fix a bug, or about whether the old code "should never have worked in the first place". It's about whether something breaks existing users' workflow.
Anyway, that was my little aside on the whole regression thing. Since it's that "first rule of kernel programming", I felt it is perhaps worth just bringing it up every once in a while.
Other than that aside, I don't find a lot to really talk about last week. Drivers, networking (and network drivers), arch updates, selftests. And a few random fixes in various other corners. The appended shortlog is not overly long, and gives a flavor for the changes.
And this obviously means that the merge window for 5.4 is open, and I'll start doing pull requests for that tomorrow. I already have a number of them in my inbox, and I appreciate all the people who got that over and done with early,
Some of the products that appear on this site are from companies from which QuinStreet receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not include all companies or all types of products available in the marketplace.