Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp667610ybh; Wed, 15 Jul 2020 11:57:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzlvMxYLgxRMcP1LnH4nMAThCG5Gyn97BRp1OrRa1Cn60UEUVShjbAlNIXtPCsao9MJCQ+s X-Received: by 2002:a17:906:3a04:: with SMTP id z4mr321547eje.441.1594839461419; Wed, 15 Jul 2020 11:57:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594839461; cv=none; d=google.com; s=arc-20160816; b=sL1jBl2spwz821Y7yg0I4BMv72jn3TVRrpGiFKW+qg1DRGB+ssY8hlSQe1YplgM+cd 3nvPtRlNYXup02e7jPIwss5dbVGR0K42BdM8daHDXV7deHsZ+8icfPQFoBnyZ9APcaec krN9NooeuyrpQEdHqMQsfM7Zix0vg8WnzoIE0kTmm5sUPI5r6OWwQVfVWgwF7FbuAB0z LknZA+XowWi9R777EyufdwCsxgq/26aCsle1lg/97eraOqB8OeZjSBS+8q100hNM73bE t+j2YmcNL1fW1zT+fw4J4x0l2EMmlAxeoKHA/pYAuDB6/57/IZ0sL7gub/wYEPmXn+tX GnDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:dkim-filter; bh=w2S46/LpGaeDsInMwudwMxyhSmDQCyI+ZXI0MH2Xs1Q=; b=yjBXvyCzgJvOEYn/2smjNCcCEi+kwqFsbqK1W7uGXpDsDWBw0kU5MxvwU+PwHji44W fVL5Gb2qqlJroUzHI0njva8jNIQK56GD1BE+P8DV+wRnQiwLQyDtYeUWwS85QATR6OZ2 HFOUzQUttoPfJXIfy0hoENiAf05Q6oY7b/3dZPhUu3JHnA4KT/6gSZZIurjG/N2GnY9+ jpNyW8DXMrZzkKoIC0JzuBAortRn/5e8nLjvWoJV8ZrIEDqKAHkuZOnD+lby86E1B4IZ Nu3dJ222lnMD5uoS5pEKk7CZY1m3bqPnVx8wRWvD+MXL8vwGcbwSQ6KHd+8AQ0Vszaql +wFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=U2qeEOlU; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x1si1694025ejj.109.2020.07.15.11.57.07; Wed, 15 Jul 2020 11:57:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@fieldses.org header.s=default header.b=U2qeEOlU; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726761AbgGOSy5 (ORCPT + 99 others); Wed, 15 Jul 2020 14:54:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36066 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726652AbgGOSy5 (ORCPT ); Wed, 15 Jul 2020 14:54:57 -0400 Received: from fieldses.org (fieldses.org [IPv6:2600:3c00:e000:2f7::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 04209C061755 for ; Wed, 15 Jul 2020 11:54:57 -0700 (PDT) Received: by fieldses.org (Postfix, from userid 2815) id 1818A877E; Wed, 15 Jul 2020 14:54:56 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 fieldses.org 1818A877E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fieldses.org; s=default; t=1594839296; bh=w2S46/LpGaeDsInMwudwMxyhSmDQCyI+ZXI0MH2Xs1Q=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U2qeEOlUtB48u+/Yz1wxCrQGsQHjQewZEDMLI52/zPBKV6An9KgaEJ41qBxgwJOfI QajMQcrYHr2TqhoJI2+ULzdNbwLTC3tYqSPKe6tvvWFP01PWPfCzVnKQYBWeUV47Dy mMpg+1DM/UVfr5I/aAZfgyGjGn5sZoLtlqwyLDnU= Date: Wed, 15 Jul 2020 14:54:56 -0400 From: "J. Bruce Fields" To: NeilBrown Cc: Jeff Layton , linux-nfs@vger.kernel.org Subject: Re: nfs4_show_superblock considered harmful :-) Message-ID: <20200715185456.GE15543@fieldses.org> References: <871rn38suc.fsf@notabene.neil.brown.name> <20200529220608.GA22758@fieldses.org> <87a71n7dek.fsf@notabene.neil.brown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87a71n7dek.fsf@notabene.neil.brown.name> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Mon, Jun 01, 2020 at 12:01:07PM +1000, NeilBrown wrote: > On Fri, May 29 2020, J. Bruce Fields wrote: > > > On Fri, May 29, 2020 at 10:53:15AM +1000, NeilBrown wrote: > >> I've received a report of a 5.3 kernel crashing in > >> nfs4_show_superblock(). > >> I was part way through preparing a patch when I concluded that > >> the problem wasn't as straight forward as I thought. > >> > >> In the crash, the 'struct file *' passed to nfs4_show_superblock() > >> was NULL. > >> This file was acquired from find_any_file(), and every other caller > >> of find_any_file() checks that the returned value is not NULL (though > >> one BUGs if it is NULL - another WARNs). > >> But nfs4_show_open() and nfs4_show_lock() don't. > >> Maybe they should. I didn't double check, but I suspect they don't > >> hold enough locks to ensure that the files don't get removed. > > > > I think the only lock held is cl_lock, acquired in states_start. > > > > We're starting here with an nfs4_stid that was found in the cl_stateids > > idr. > > > > A struct nfs4_stid is freed by nfs4_put_stid(), which removes it from > > that idr under cl_lock before freeing the nfs4_stid and anything it > > points to. > > > > I think that was the theory.... > > > > One possible problem is downgrades, like nfs4_stateid_downgrade. > > > > I'll keep mulling it over, thanks. > Oops, I neglected this a while.... > I had another look at code and maybe move_to_close_lru() is the problem. > It can clear remove the files and clear sc_file without taking > cl_lock. So some protection is needed against that. > > I think that only applies to nfs4_show_open() - not show_lock etc. > But I wonder it is might be best to include some extra protection > for each different case, just in case some future code change > allow sc_file to become NULL before the state is detached. > > I'd feel more comforatable about nfs4_show_superblock() if it ignored > nf_inode and just used nf_file - it is isn't NULL. It looks like it > can never be set from non-NULL to NULL. But then that means we've always got a reference on the inode, doesn't it? So I still don't understand the nf_inode comment. So maybe the NULL checks are mainly all we need. Also it looks to me like ls_file lasts as long as the layout stateid, so maybe it's OK. --b. commit 4eef57aa4fc0 Author: J. Bruce Fields Date: Wed Jul 15 13:31:36 2020 -0400 nfsd4: fix NULL dereference in nfsd/clients display code Reported-by: NeilBrown Signed-off-by: J. Bruce Fields diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index ab5c8857ae5a..08b8376c74d7 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -507,6 +507,16 @@ find_any_file(struct nfs4_file *f) return ret; } +static struct nfsd_file *find_deleg_file(struct nfs4_file *f) +{ + struct nfsd_file *ret; + + spin_lock(&f->fi_lock); + ret = nfsd_file_get(f->fi_deleg_file); + spin_unlock(&f->fi_lock); + return ret; +} + static atomic_long_t num_delegations; unsigned long max_delegations; @@ -2444,6 +2454,8 @@ static int nfs4_show_open(struct seq_file *s, struct nfs4_stid *st) oo = ols->st_stateowner; nf = st->sc_file; file = find_any_file(nf); + if (!file) + return 0; seq_printf(s, "- "); nfs4_show_stateid(s, &st->sc_stateid); @@ -2481,6 +2493,8 @@ static int nfs4_show_lock(struct seq_file *s, struct nfs4_stid *st) oo = ols->st_stateowner; nf = st->sc_file; file = find_any_file(nf); + if (!file) + return 0; seq_printf(s, "- "); nfs4_show_stateid(s, &st->sc_stateid); @@ -2513,7 +2527,9 @@ static int nfs4_show_deleg(struct seq_file *s, struct nfs4_stid *st) ds = delegstateid(st); nf = st->sc_file; - file = nf->fi_deleg_file; + file = find_deleg_file(nf); + if (!file) + return 0; seq_printf(s, "- "); nfs4_show_stateid(s, &st->sc_stateid);