Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932143AbcCLVOr (ORCPT ); Sat, 12 Mar 2016 16:14:47 -0500 Received: from mail-pf0-f177.google.com ([209.85.192.177]:35738 "EHLO mail-pf0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753550AbcCLVOj (ORCPT ); Sat, 12 Mar 2016 16:14:39 -0500 Subject: Re: e827091cb1 "block: merge: get the 1st and last bvec via helpers" broken To: Linus Torvalds , Ming Lei References: <20160312074329.GA19066@kmo-pixel> <20160312092421.GA20839@kmo-pixel> <20160312121236.GA25403@kmo-pixel> <20160312134843.GA27821@kmo-pixel> <20160312140256.GA29313@kmo-pixel> <20160312222548.6a81d13b@tom-T450> <20160312143612.GA30418@kmo-pixel> Cc: Kent Overstreet , Ming Lin , Linux Kernel Mailing List From: Jens Axboe Message-ID: <56E486BB.8030103@kernel.dk> Date: Sat, 12 Mar 2016 14:14:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1189 Lines: 35 On 03/12/2016 12:51 PM, Linus Torvalds wrote: > On Sat, Mar 12, 2016 at 6:39 AM, Ming Lei wrote: >> >> I am fine with either way, and I will prepare one patch and let Jens >> decide. > > So guys, this needs to be done *now*. > > And Jens - this is the last time I believe you when you say late > patches are required. > > The buggy patch that introduced this problem was part of that very > late pull request that I already rejected once, and you then claimed > was absolutely required. > > So the dicking around with the block layer stops *now*. > > Seriously. I'm pissed off. Believe me, I'm as impressed as you are... I've queued it up and will run it through testing and send it off later. I still think it's better to apply the fix, rather than revert the original change. > I don't want to see anything even half-way questionable during the > whole next release window. Not even during the merge window. You need > to do some serious quality control, and re-think the whole "large > changes" model. The timing was the issue here, and yeah, it didn't work out well this time at all. It's a momentary lapse, we'll get it sorted for sure. -- Jens Axboe