linux-kernel - Re: [git pull] mount API series

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 1 Nov 2018 10:53:21 +0000
From:   Steven Whitehouse <swhiteho@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        "Eric W. Biederman" <ebiederm@...hat.com>
Cc:     linux-fsdevel@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] mount API series

Hi,

On 31/10/18 16:18, Linus Torvalds wrote:
> On Tue, Oct 30, 2018 at 10:34 PM Al Viro <viro@...iv.linux.org.uk> 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.