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,
Linus
