From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out01.mta.xmission.com ([166.70.13.231]:36528 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730203AbeKLL6T (ORCPT ); Mon, 12 Nov 2018 06:58:19 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Steven Whitehouse Cc: Al Viro , Linus Torvalds , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org References: <20181031053355.GQ32577@ZenIV.linux.org.uk> <87a7mut9cm.fsf@xmission.com> <2f4a2d58-dc7b-3a8f-65aa-9db432ce0a1e@redhat.com> Date: Sun, 11 Nov 2018 20:07:20 -0600 In-Reply-To: <2f4a2d58-dc7b-3a8f-65aa-9db432ce0a1e@redhat.com> (Steven Whitehouse's message of "Sat, 10 Nov 2018 14:19:44 +0000") Message-ID: <877ehjkq07.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [git pull] mount API series Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Steven Whitehouse writes: > Hi, > > > On 31/10/18 15:38, Eric W. Biederman wrote: >> Al Viro writes: >> >>> 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... >> Absolutely not. >> >> My objections fundamentally is that I can find real problems when I look >> at the code. Further the changes have not been incremental changes that >> have evolved the code from one state to another but complete >> replacements of code that make code review very difficult and bisection >> completely inapplicable. >> >> I also object that this series completely fails to fix the worst but I >> have ever seen in the mount API. Whit no real intrest shown in working >> to fix it. >> >> A couple of bugs that I can see quickly. Several of which I have >> previously reported: >> >> - There is an easily triggered NULL pointer deference with open_tree >> and mount propagation. >> >> > Can you share some details of what this NULL dereference is? David and > Al have been working on the changes as requested by Linus later in > this thread, and they'd like to tidy up this issue too at the same > time if possible. We are not asking you to actually provide a fix, in > case you are too busy to do so, however it would be good to know what > the issue is so that we can make sure that it is resolved in the next > round of patches, https://lore.kernel.org/lkml/87bm7n5k1r.fsf@xmission.com/ Eric