Re: [GIT PULL] Block fixes for 4.5-final

[Jens Axboe]

On 03/03/2016 01:57 PM, Linus Torvalds wrote:
> On Thu, Mar 3, 2016 at 9:25 AM, Jens Axboe <axboe@xxxxxx> 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