From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from out4-smtp.messagingengine.com ([66.111.4.28]:33139 "EHLO
        out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S932141AbcKNGzH (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Mon, 14 Nov 2016 01:55:07 -0500
Date: Mon, 14 Nov 2016 07:55:19 +0100
From: Greg KH <greg@kroah.com>
To: Nicolai Stange <nicstange@gmail.com>
Cc: Mike Marshall <hubcap@omnibond.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Martin Brandenburg <martin@omnibond.com>
Subject: Re: debugfs question...
Message-ID: <20161114065519.GA29810@kroah.com>
References: <CAOg9mSSje9unMDnw9NhDd+cC=Ns9c+TK1fE2S0HytLU=HXYDpQ@mail.gmail.com>
 <20161031193823.GA11187@kroah.com>
 <87wpgoff0o.fsf@gmail.com>
 <877f876wo9.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <877f876wo9.fsf@gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Sun, Nov 13, 2016 at 07:51:02PM +0100, Nicolai Stange wrote:
> Hi again,
> 
> bad news: my previous analysis was completely wrong, c.f. below.
> Good news (from my point of view): debugfs is correct, no fix needed for
> it.
> 
> Apologies for the confusion...
> 
> 
> Nicolai Stange <nicstange@gmail.com> writes:
> 
> > Greg KH <greg@kroah.com> writes:
> >
> >> On Mon, Oct 31, 2016 at 02:32:56PM -0400, Mike Marshall wrote:
> >>
> >>> But... really bad things happen if someone unloads the Orangefs
> >>> module after my test program does the open and before the read
> >>> starts. So I picked another debugfs-using-filesystem (f2fs) and
> >>> pointed my tester-program at /sys/kernel/debug/f2fs/status, and
> >>> the same bad thing happens there.
> >
> > [...]
> >
> >>> [ 1240.144316] Call Trace:
> >>> [ 1240.144450]  [<ffffffff8122907f>] __fput+0xdf/0x1d0
> >>> [ 1240.144704]  [<ffffffff812291ae>] ____fput+0xe/0x10
> >>> [ 1240.144962]  [<ffffffff810b97de>] task_work_run+0x8e/0xc0
> >>> [ 1240.145243]  [<ffffffff8109b98e>] do_exit+0x2ae/0xae0
> >
> >
> > Thank you very much for this detailed report!
> >
> > At least for the .../f2fs/status file, your splat at fput() can be
> > readily explained with the full proxy's releaser not being protected
> > against file removals in any way.
> >
> > Partly this is on purpose, c.f. the comment in full_proxy_release().
> >
> > However, I should have at least tried to acquire a reference to the
> > owning module before accessing some static struct file_operations or
> > even calling some ->release() within it. Meh.
> 
> This is what I got wrong: debugfs does acquire the needed references
> correctly (details below). For the case of f2fs' "status" file, the
> file_operations ->owner is simply not set as it should have been,
> i.e. to THIS_MODULE.

Ah, good, care to make a f2fs patch to resolve the issue there?

thanks,

greg k-h