Linux 5.3 Released

So we've had a fairly quiet last week, but I think it was good that weended up having that extra week and the final rc8.Even if the reason for that extra week was my travel schedule ratherthan any pending issues, we ended up having a few good fixes come in,including some for some bad btrfs behavior. Yeah, there's someunnecessary noise in there too (like the speling fixes), but we alsohad several last-minute reverts for things that caused issues.One _particularly_ last-minute revert is the top-most commit (ignoringthe version change itself) done just before the release, and whileit's very annoying, it's perhaps also instructive.What's instructive about it is that I reverted a commit that wasn'tactually 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 muchimproved IO patterns it caused then ended up revealing a user-visibleregression due to a real bug in a completely unrelated area.The actual details of that regression are not the reason I point thatrevert out as instructive, though. It's more that it's an instructiveexample of what counts as a regression, and what the whole "noregressions" kernel rule means. The reverted commit didn't change anyAPI's, and it didn't introduce any new bugs. But it ended up exposinganother problem, and as such caused a kernel upgrade to fail for auser. 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 totrigger before. The better IO patterns introduced by the change justhappened to expose an old bug, and people had grown to depend on thepreviously benign behavior of that old issue.And never fear, we'll re-introduce the fix that improved on the IOpatterns once we've decided just how to handle the fact that we had abad interaction with an interface that people had then just happenedto rely on incidental behavior for before. It's just that we'll haveto hash through how to do that (there are no less than three differentpatches by three different developers being discussed, and there mightbe more coming...). In the meantime, I reverted the thing that exposedthe problem to users for this release, even if I hope it will bere-introduced (perhaps even backported as a stable patch) once we haveconsensus about the issue it exposed.Take-away from the whole thing: it's not about whether you change thekernel-userspace ABI, or fix a bug, or about whether the old code"should never have worked in the first place". It's about whethersomething breaks existing users' workflow.Anyway, that was my little aside on the whole regression thing.  Sinceit's that "first rule of kernel programming", I felt it is perhapsworth just bringing it up every once in a while.Other than that aside, I don't find a lot to really talk about lastweek. Drivers, networking (and network drivers), arch updates,selftests. And a few random fixes in various other corners. Theappended shortlog is not overly long, and gives a flavor for thechanges.And this obviously means that the merge window for 5.4 is open, andI'll start doing pull requests for that tomorrow. I already have anumber of them in my inbox, and I appreciate all the people who gotthat over and done with early,                Linus