All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Lyakas <alex@zadara.com>
To: linux-nfs@vger.kernel.org
Cc: shyam@zadara.com, Alex Lyakas <alex@zadara.com>
Subject: [RFC-PATCH] nfsd: when unhashing openowners, increment openowner's refcount
Date: Wed, 21 Aug 2019 19:49:06 +0300	[thread overview]
Message-ID: <1566406146-7887-1-git-send-email-alex@zadara.com> (raw)

release_openowner() expects an extra refcnt taken for the openowner,
which it is releasing.

 With nfsd_inject_forget_client_openowners() and nfsd_inject_forget_openowners(),
we unhash openowners and collect them into a reaplist. Later we call
nfsd_reap_openowners(), which calls release_openowner(), which releases all openowner's stateids.
Each OPEN stateid holds a refcnt on the openowner. Therefore, after releasing
the last OPEN stateid via its sc_free function, which is nfs4_free_ol_stateid,
nfs4_put_stateowner() will be called, which will realize its the last
refcnt for the openowner. As a result, openowner will be freed.
But later, release_openowner() will go ahead and call release_last_closed_stateid()
and nfs4_put_stateowner() on the same openowner which was just released.
This corrupts memory and causes random crashes.

After we fixed this, we confirmed that the openowner is not freed
prematurely. It is freed by release_openowner() final call
to nfs4_put_stateowner().

However, we still get (other) random crashes and memory corruptions
when nfsd_inject_forget_client_openowners() and
nfsd_inject_forget_openowners().
According to our analysis, we don't see any other refcount issues.
Can anybody from the community review these flows for other potentials issues?

Signed-off-by: Alex Lyakas <alex@zadara.com>
---
 fs/nfsd/nfs4state.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index 7857942..4e9afca 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -7251,6 +7251,7 @@ static u64 nfsd_foreach_client_lock(struct nfs4_client *clp, u64 max,
 			func(oop);
 			if (collect) {
 				atomic_inc(&clp->cl_rpc_users);
+				nfs4_get_stateowner(&oop->oo_owner);
 				list_add(&oop->oo_perclient, collect);
 			}
 		}
-- 
1.9.1


             reply	other threads:[~2019-08-21 16:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-21 16:49 Alex Lyakas [this message]
2019-08-25 10:12 ` [RFC-PATCH] nfsd: when unhashing openowners, increment openowner's refcount Alex Lyakas
2019-08-26 13:39   ` J. Bruce Fields
2019-08-26 14:38     ` J. Bruce Fields
2019-08-27  9:05     ` Alex Lyakas
2019-08-27 20:51       ` J. Bruce Fields
2019-08-28 15:20         ` Alex Lyakas
2019-08-28 16:54           ` J. Bruce Fields
2019-08-29 18:12             ` Alex Lyakas
2019-08-30 19:08               ` J. Bruce Fields
2019-09-03 13:47                 ` Alex Lyakas
2019-08-30 19:54               ` J. Bruce Fields
2019-09-03 13:48                 ` Alex Lyakas

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=1566406146-7887-1-git-send-email-alex@zadara.com \
    --to=alex@zadara.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=shyam@zadara.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.