Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp7479730imu; Mon, 3 Dec 2018 13:39:43 -0800 (PST) X-Google-Smtp-Source: AFSGD/URzhwT4z1graOyNXlvRorrIi2p0STXaPKl7lVkfuILfQb3GZtnzfXkE3X/EyXuUczZQtyy X-Received: by 2002:a17:902:14b:: with SMTP id 69mr17878365plb.52.1543873183413; Mon, 03 Dec 2018 13:39:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543873183; cv=none; d=google.com; s=arc-20160816; b=WmEwOEDR6IHlGX05g3z0j2jSBpXCU0W0joxH/1yPuCIqK/KtRddeRQ8m4e0MwzPsQ8 +aK19N/P1/hvU0GTcySIB0N+HHGhgS+iw3TdaTuryQ/treX1C4oM9NlKP25/jyuE9tyb 5a+6cLvIkZ4ihNGQuAmSQcxFT/LB3fgNa0iDZIFYYPqPQj51IsAXxwQ6pRp9C/+pXxZD 1QzZJQzklyz++4k6dE/LlcvjsgvXKYETOxuEcoa1WlABXOE9y8fSjn8CPr7GyMKIbtFZ Ra/xzCrvM3tqOrcLWFzE0hySVtW+AIxQVZBop/Iki2JyCXkL/pYW2csrUOMHbxfWBzje HTyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:date:message-id:from :references:cc:to:subject; bh=Jlhdz+X7YpbqFktTsjUZlv6fkgzWBUAyxKtkKQZJFIw=; b=Czn+3gn1WZ3AHcR7x/V9HJa9ub/W1GArtRAyyH3RO8jTZAR794dbdi8RviV7WmvtoV rU8SHLLHytdEoRMDZtPSXs3Cdn4Dikq7X7Hn8XdU5fhH22zrdlKF3kpb96fN8LW8xDym 1mCKEBqKOgwxslnnIqvUr+59Ew7McOdMX1Q1E5OanrK1zMLx4hHEPCiEt1RKrDi3aPGO ytBBsQUOinGte7n+SLktSvI6GlkKdtOdfXDRetgmR4Pm9JY/RA0Pge0v4PcUTJ8c6TVf s8L+bDaf2jlH5N+G/QWaDafa1ci1RCrSbup1IuKAhNSCue68Q1SnOz6erQ+bSvxSaKcB OCkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g8si14218146pgb.128.2018.12.03.13.39.27; Mon, 03 Dec 2018 13:39:43 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726062AbeLCVho convert rfc822-to-8bit (ORCPT + 99 others); Mon, 3 Dec 2018 16:37:44 -0500 Received: from mx1.yrkesakademin.fi ([85.134.45.194]:49318 "EHLO mx1.yrkesakademin.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725903AbeLCVho (ORCPT ); Mon, 3 Dec 2018 16:37:44 -0500 X-Greylist: delayed 903 seconds by postgrey-1.27 at vger.kernel.org; Mon, 03 Dec 2018 16:37:42 EST Subject: Re: [PATCH AUTOSEL 4.14 25/35] iomap: sub-block dio needs to zeroout beyond EOF To: Sasha Levin , Dave Chinner CC: Greg KH , , , Dave Chinner , "Darrick J . Wong" , References: <20181129060110.159878-1-sashal@kernel.org> <20181129060110.159878-25-sashal@kernel.org> <20181129121458.GK19305@dastard> <20181129124756.GA25945@kroah.com> <20181129224019.GM19305@dastard> <20181130082203.GA26830@kroah.com> <20181130101441.GA213156@sasha-vm> <20181130215005.GP19305@dastard> <20181201074909.GC213156@sasha-vm> <20181202232302.GT19305@dastard> <20181203092241.GC235790@sasha-vm> From: Thomas Backlund Message-ID: <2de96c1b-c375-8eed-f934-df5cbcdcd5cc@mageia.org> Date: Mon, 3 Dec 2018 23:22:46 +0159 MIME-Version: 1.0 In-Reply-To: <20181203092241.GC235790@sasha-vm> Content-Type: text/plain; charset="windows-1252" Content-Language: en-US Content-Transfer-Encoding: 8BIT X-WatchGuard-Spam-ID: str=0001.0A0C020E.5C05A227.003D,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 X-WatchGuard-Spam-Score: 0, clean; 0, virus threat unknown X-WatchGuard-Mail-Client-IP: 85.134.45.194 X-WatchGuard-Mail-From: tmb@mageia.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Den 2018-12-03 kl. 11:22, skrev Sasha Levin: > > This is a case where theory collides with the real world. Yes, our QA is > lacking, but we don't have the option of not doing the current process. > If we stop backporting until a future data where our QA problem is > solved we'll end up with what we had before: users stuck on ancient > kernels without a way to upgrade. > Sorry, but you seem to be living in a different "real world"... People stay on "ancient kernels" that "just works" instead of updating to a newer one that "hopefully/maybe/... works" > With the current model we're aware that bugs sneak through, but we try > to deal with it by both improving our QA, and encouraging users to do > their own extensive QA. If we encourage users to update frequently we > can keep improving our process and the quality of kernels will keep > getting better. And here you want to turn/force users into QA ... good luck with that. In reality they wont "update frequently", instead they will stop updating when they have something that works... and start ignoring updates as they expect something "to break as usual" as they actually need to get some real work done too... > > We simply can't go back to the "enterprise distro" days. > Maybe so, but we should atleast get back to having "stable" or "longterm" actually mean something again... Or what does it say when distros starts thinking about ignoring (and some already do) stable/longterm trees because there is _way_ too much questionable changes coming through, even overriding maintainers to the point where they basically state "we dont care about monitoring stable trees anymore, as they add whatever they want anyway"... And pretending that every fix is important enough to backport, and saying if you dont take everything you have an "unsecure" kernel wont help, as reality has shown from time to time that backports can/will open up a new issue instead for no good reason Wich for distros starts to mean, switch back to selectively taking fixes for _known_ security issues are considered way better choice End result, no-one cares about -stable trees -> no-one uses them -> a lot of wasted work for nothing... -- Thomas