Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp675658imd; Thu, 1 Nov 2018 03:53:59 -0700 (PDT) X-Google-Smtp-Source: AJdET5e+HG3XDLGojWSAw4vGqTUXVxq/Bo5e405GwfLdlt6OrfMDY7MSo7xmLwgYOh5nGl1V9k7M X-Received: by 2002:a63:e302:: with SMTP id f2mr6808598pgh.320.1541069639591; Thu, 01 Nov 2018 03:53:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541069639; cv=none; d=google.com; s=arc-20160816; b=bTKGw2pFusakBH0875pEOB22ZniHbS/AvOrrnHV6H9GtPExxf/31tb5TUFiuniIxJP tYJ33EvFRrBU48wt7VvhDJkgh3gu93E9Y5p/wuOZeoMqlR5EzlCnAEYz/OYInUaRhDXE On7iWBVafGlJjRzYpFs76U3jm/DsU7rXXpWyvSi5EYPOTfrfxBkP+EozdV/9n4Brblyn HZ8CkfHHcTEZMjhlVSR8EyKSy7JgpqEMNWKnU7MkL6Oq1wVBV0UeSuE2zU7G7om7pGwD uvviKsZ5Y9p5W2qUhqVFx9yHm/69mEbuITXZBQ62tjMs1WmET0kqFsyauJAtrNSadLN8 FWZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=YURszGhCgxT5IpX9Yt9Ahpb/VFTve0t6eZHobNEpQyQ=; b=CRaf6jkud0Fw9C/VD1bRvYKCW2E7PKVL5JGQkBx85d7+M0QL8Prl6HAHtanUywKVj3 xz/h0upbSJIS4XMwgSBSY0jm+G6s8hKvCmZnQkqUy1oCLxnBqLTiz4ylsM/02U+vW1RA Sy5ahDQfE6TpoRqR+rhPhlig67hrOx8BJpDBo/Xnzgw5NPQWAWydM3AhYnWeluwXq6eU fm8n5KPeSKZMFsRFOvLBdF6gtlJRDu7f1wAPx3izX3lyDgt+DjuYDBsY6t9rryJgbZ+J ZG1uVVFnffkPQyx4nN7FMIf4ADrwdOY8QrlAfN6/Nffz5YHaFPt58Z3KY6ZhzQ1T3l4o t+7A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m5-v6si4018202plt.432.2018.11.01.03.53.45; Thu, 01 Nov 2018 03:53:59 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728204AbeKATzu (ORCPT + 99 others); Thu, 1 Nov 2018 15:55:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58684 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726520AbeKATzu (ORCPT ); Thu, 1 Nov 2018 15:55:50 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2BFCD37E85; Thu, 1 Nov 2018 10:53:24 +0000 (UTC) Received: from 117.195.187.81.in-addr.arpa (unknown [10.33.36.41]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9066F5D9CB; Thu, 1 Nov 2018 10:53:22 +0000 (UTC) Subject: Re: [git pull] mount API series To: Linus Torvalds , Al Viro , "Eric W. Biederman" Cc: linux-fsdevel@vger.kernel.org, Linux Kernel Mailing List References: <20181031053355.GQ32577@ZenIV.linux.org.uk> From: Steven Whitehouse Message-ID: Date: Thu, 1 Nov 2018 10:53:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 01 Nov 2018 10:53:24 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 31/10/18 16:18, Linus Torvalds wrote: > On Tue, Oct 30, 2018 at 10:34 PM Al Viro wrote: >> mount API series from David Howells. Last cycle's objections >> had been of the "I'd do it differently" variety and with no such >> differently done variants having ever materialized over several >> cycles... > Having just lurked on the discussions about the bugs in here, I don't > think this is ready. Maybe they got fixed, but if so, it was recent > and it was pretty fundamental. > > The stated aim of the series is to make the mount API _better_, not > worse. And right now it looks like a "two steps back, one theoretical > step forwards" kind of better. > > Linus The design of the new mount API has been under discussion for some time, both on the mailing lists, and also at LSF/MM too. Al and David (and others) have put a lot of work into getting to the current position, and have specifically requested input from Eric about his concerns over past cycles. When I look at the discussions I'm seeing two main issues (please correct me if you think I'm wrong about this) which are (a) whether the design is correct and (b) whether there are still bugs in the current patch set. Which of these are you most concerned about? It seems to me that there is not a lot of point in spending a large amount of time in additional review/testing of the current patch set if the overall design is set to be rejected. If your concerns are only with the robustness/stability of the patch set, then that provides a clear route to resolving the current impasse, at least assuming that Eric is able to enumerate the issues that he has discovered. It looks like David has already provided a fix for one of the issues which Eric mentioned in his recent email. Eric it would be good if you could confirm that this addresses that particular concern, Steve.