On 03/03/2016 01:57 PM, Linus Torvalds wrote:
On Thu, Mar 3, 2016 at 9:25 AM, Jens Axboe <ax...@fb.com> wrote:
=>
A set of fixes for 4.5-rc6 - it's a lot bigger than I would like at this
point, but there's really nothing in here that we should not merge for
4.5 final - with a possible exception [..]
With the possible exception of pretty much everything.
NONE of this seems really to be appropriate for this stage. It doesn't
fix regressions, it doesn't fix security stuff, it doesn't really fix
major oopses.
Why did you send it to me?
Right now, the block layer has been the problem child for several
releases. This has got to stop.
I've been a pushover, largely driven by the NVMe changes. But that said,
the changes are good. Maybe a smaller subset of them could have waited,
but the majority should go in. And they have been well tested, mostly in
batches outside of my tree.
Example of a couple of commits that made me decide to actually unpull
this already after I had pulled it:
- commit 35b3ccc7d71c (from yesterday) changed old code that checked
for REQ_TYPE_BLOCK_PC to check for a bigger range
- then, today, commit 5b16f4f2b5e9 then changes that same code to
instead just check for REQ_TYPE_FS
Before this cluster-fuck of a pull request, that code had apparently
worked well enough that it hadn't been touched since 2012.
So the "bug" it fixed clearly was clearly not hugely critical. The fix
itself was clearly not discussed or thought out, since it ended up
changing. It wasn't even important enough to mark for stable, although
the code has clearly been that way for almost three years now.
It does fix a regression - the change is that NVMe now uses the block
layer for these types of requests, and they don't have to adhere to the
regular fs limits of sizing. Hence we broke real use cases, of (for
instance) pulling logs off devices. Both of the referenced commits were
added yesterday, not today. And they should have been folded, but I had
already committed the first one. I don't think that should preclude
doing it much cleaner than the first one.
And Gods, that was just the most obvious "this pull request is pure shit".
The rest of the pull request really in no way looked critical enough
to be rc6+ material. Seriously.
So why the f*ck does the block layer end up being this kind of a problem?
Really. You need to get a grip, and start thinking about your pull
requests a *lot* more.m None of this "let's send Linus random crap at
any time in the release process".
I pulled it and then spent half an hour thinking about it, and decided
that there's no way in hell pulling this is the right thing, so I had
to not just unpull it, but undo and then re-do another pull I had done
in the meantime.
Get your act together, Jens. You knew this was big and late. And
absolutely *none* of it looked critical to me.
I realize it was big, and it is much bigger than I wanted. And I also
realize that this has been a recurring theme the last couple of release.
But that's not me being lazy, there's just been a larger amount of churn
later in the cycle.
Feel free to resend the parts that are actually critical, but explain
exactly why they are so critical when you do.
Fair enough, I can boil it down somewhat. But honestly, the only stuff
I'd feel comfortable pulling out now would be the lightnvm changes which
aren't that critical due to the user base, though that's also why it
would be fine to shove it in now. And the cgroup writeback enable, which
can wait. The two commits referenced above could be folded, but they'd
still be in the new pull request.
So let me know if you want that, or we can proceed with the current
branch, because most of it should really go in as-is.
--
Jens Axboe
