linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@poochiereds.net>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Al Viro <viro@ZenIV.linux.org.uk>,
	eparis@redhat.com
Subject: Re: [PATCH v6 00/19] nfsd: open file caching
Date: Thu, 22 Oct 2015 20:21:08 -0400	[thread overview]
Message-ID: <20151022202108.3b7ee9a3@synchrony.poochiereds.net> (raw)
In-Reply-To: <20151022211928.GF5205@fieldses.org>

On Thu, 22 Oct 2015 17:19:28 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> Looks like there's a leak--is this something you've seen already?
> 
> This is on my current nfsd-next, which has some other stuff too.
> 
> --b.
> 
> [  819.980697] kmem_cache_destroy nfsd_file_mark: Slab cache still has objects
> [  819.981326] CPU: 0 PID: 4360 Comm: nfsd Not tainted 4.3.0-rc3-00040-ga6bca98 #360
> [  819.981969] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
> [  819.982805]  ffff8800738d7d30 ffff8800738d7d20 ffffffff816053ac ffff880051ee5540
> [  819.983803]  ffff8800738d7d58 ffffffff811813df ffff8800738d7d30 ffff8800738d7d30
> [  819.984782]  ffff880074fd5e00 ffffffff822f9c80 ffff88007c64cf80 ffff8800738d7d68
> [  819.985751] Call Trace:
> [  819.985940]  [<ffffffff816053ac>] dump_stack+0x4e/0x82
> [  819.986369]  [<ffffffff811813df>] kmem_cache_destroy+0xef/0x100
> [  819.986899]  [<ffffffffa00c2198>] nfsd_file_cache_shutdown+0x78/0xa0 [nfsd]
> [  819.987513]  [<ffffffffa00b2c4d>] nfsd_shutdown_generic+0x1d/0x20 [nfsd]
> [  819.988100]  [<ffffffffa00b2d2d>] nfsd_shutdown_net+0xdd/0x180 [nfsd]
> [  819.988656]  [<ffffffffa00b2c55>] ? nfsd_shutdown_net+0x5/0x180 [nfsd]
> [  819.989218]  [<ffffffffa00b2f34>] nfsd_last_thread+0x164/0x190 [nfsd]
> [  819.989770]  [<ffffffffa00b2dd5>] ? nfsd_last_thread+0x5/0x190 [nfsd]
> [  819.990328]  [<ffffffffa001463e>] svc_shutdown_net+0x2e/0x40 [sunrpc]
> [  819.990996]  [<ffffffffa00b3936>] nfsd_destroy+0xd6/0x190 [nfsd]
> [  819.991719]  [<ffffffffa00b3865>] ? nfsd_destroy+0x5/0x190 [nfsd]
> [  819.992373]  [<ffffffffa00b3bb1>] nfsd+0x1c1/0x280 [nfsd]
> [  819.992960]  [<ffffffffa00b39f5>] ? nfsd+0x5/0x280 [nfsd]
> [  819.993537]  [<ffffffffa00b39f0>] ? nfsd_destroy+0x190/0x190 [nfsd]
> [  819.994195]  [<ffffffff81098d6f>] kthread+0xef/0x110
> [  819.994734]  [<ffffffff81a7677c>] ? _raw_spin_unlock_irq+0x2c/0x50
> [  819.995439]  [<ffffffff81098c80>] ?  kthread_create_on_node+0x200/0x200
> [  819.996129]  [<ffffffff81a7744f>] ret_from_fork+0x3f/0x70
> [  819.996706]  [<ffffffff81098c80>] ?  kthread_create_on_node+0x200/0x200
> [  819.998854] nfsd: last server has exited, flushing export cache
> [  820.195957] NFSD: starting 20-second grace period (net ffffffff822f9c80)
> 

Thanks...interesting.

I'll go over the refcounting again to be sure but I suspect that this
might be a race between tearing down the cache and destruction of the
fsnotify marks.

fsnotify marks are destroyed by a dedicated thread that cleans them up
after the srcu grace period settles. That's a bit of a flimsy guarantee
unfortunately. We can use srcu_barrier(), but if the thread hasn't
picked up the list and started destroying yet then that may not help.

I'll look over that code -- maybe it's possible to use call_srcu
instead, which would allow us to use srcu_barrier to wait for them all
to complete.

Thanks!
-- 
Jeff Layton <jlayton@poochiereds.net>

  reply	other threads:[~2015-10-23  0:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-20 17:33 [PATCH v6 00/19] nfsd: open file caching Jeff Layton
2015-10-20 17:33 ` [PATCH v6 03/19] fs: add a kerneldoc header to fput Jeff Layton
2015-10-20 17:33 ` [PATCH v6 04/19] fs: rename "delayed_fput" infrastructure to "fput_global" Jeff Layton
2015-10-20 17:33 ` [PATCH v6 06/19] fsnotify: export several symbols Jeff Layton
2015-10-20 17:33 ` [PATCH v6 07/19] locks: create a new notifier chain for lease attempts Jeff Layton
     [not found] ` <1445362432-18869-1-git-send-email-jeff.layton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
2015-10-20 17:33   ` [PATCH v6 01/19] nfsd: move include of state.h from trace.c to trace.h Jeff Layton
     [not found]     ` <1445362432-18869-2-git-send-email-jeff.layton-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>
2015-10-21 15:51       ` J. Bruce Fields
2015-10-20 17:33   ` [PATCH v6 02/19] fs: have flush_delayed_fput flush the workqueue job Jeff Layton
2015-10-20 17:33   ` [PATCH v6 05/19] fs: add fput_global Jeff Layton
2015-10-20 17:33   ` [PATCH v6 08/19] sunrpc: add a new cache_detail operation for when a cache is flushed Jeff Layton
2015-10-20 17:33   ` [PATCH v6 09/19] nfsd: add a new struct file caching facility to nfsd Jeff Layton
2015-10-20 17:33   ` [PATCH v6 10/19] nfsd: keep some rudimentary stats on nfsd_file cache Jeff Layton
2015-10-20 17:33   ` [PATCH v6 11/19] nfsd: allow filecache open to skip fh_verify check Jeff Layton
2015-10-20 17:33   ` [PATCH v6 12/19] nfsd: hook up nfsd_write to the new nfsd_file cache Jeff Layton
2015-10-20 17:33   ` [PATCH v6 13/19] nfsd: hook up nfsd_read to the " Jeff Layton
2015-10-20 17:33   ` [PATCH v6 14/19] nfsd: hook nfsd_commit up " Jeff Layton
2015-10-20 17:33   ` [PATCH v6 16/19] nfsd: have nfsd_test_lock use " Jeff Layton
2015-10-20 17:33   ` [PATCH v6 17/19] nfsd: convert fi_deleg_file and ls_file fields to nfsd_file Jeff Layton
2015-10-20 17:33   ` [PATCH v6 18/19] nfsd: hook up nfs4_preprocess_stateid_op to the nfsd_file cache Jeff Layton
2015-10-21 15:57   ` [PATCH v6 00/19] nfsd: open file caching J. Bruce Fields
2015-10-22 21:19   ` J. Bruce Fields
2015-10-23  0:21     ` Jeff Layton [this message]
2015-10-20 17:33 ` [PATCH v6 15/19] nfsd: convert nfs4_file->fi_fds array to use nfsd_files Jeff Layton
2015-10-20 17:33 ` [PATCH v6 19/19] nfsd: rip out the raparms cache Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151022202108.3b7ee9a3@synchrony.poochiereds.net \
    --to=jlayton@poochiereds.net \
    --cc=bfields@fieldses.org \
    --cc=eparis@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).