From: NeilBrown <neilb@suse.de>
To: "J. Bruce Fields" <bfields@redhat.com>
Cc: linux-nfs@vger.kernel.org
Subject: uncollected nfsd open owners
Date: Fri, 25 Oct 2019 12:22:36 +1100 [thread overview]
Message-ID: <87mudpfwkj.fsf@notabene.neil.brown.name> (raw)
[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]
Hi,
I have a coredump from a machine that was running as an NFS server.
nfs4_laundromat was trying to expire a client, and in particular was
cleaning up the ->cl_openowners.
As there were 6.5 million of these, it took rather longer than the
softlockup timer thought was acceptable, and hence the core dump.
Those open owners that I looked at had empty so_stateids lists, so I
would normally expect them to be on the close_lru and to be removed
fairly soon. But they weren't (only 32 openowners on close_lru).
The only explanation I can think of for this is that maybe an OPEN
request successfully got through nfs4_process_open1(), thus creating an
open owner, but failed to get to or through nfs4_process_open2(), and
so didn't add a stateid. I *think* this can leave an openowner that is
unused but will never be cleaned up (until the client is expired, which
might be too late).
Is this possible? If so, how should we handle those openowners which
never had a stateid?
In 3.0 (which it the kernel were I saw this) I could probably just put
the openowner on the close_lru when it is created.
In more recent kernels, it seems to be assumed that openowners are only
on close_lru if they have a oo_last_closed_stid. Would we need a
separate "never used lru", or should they just be destroyed as soon as
the open fails?
Also, should we put a cond_resched() in some or all of those loops in
__destroy_client() ??
Thanks for your help,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next reply other threads:[~2019-10-25 1:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 1:22 NeilBrown [this message]
2019-10-25 15:20 ` uncollected nfsd open owners J. Bruce Fields
2019-10-26 21:36 ` J. Bruce Fields
2019-10-27 23:49 ` NeilBrown
2019-10-28 14:52 ` J. Bruce Fields
2019-10-28 3:24 ` NeilBrown
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=87mudpfwkj.fsf@notabene.neil.brown.name \
--to=neilb@suse.de \
--cc=bfields@redhat.com \
--cc=linux-nfs@vger.kernel.org \
/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