From: Andrew W Elble <aweits@rit.edu>
To: Jeff Layton <jlayton@poochiereds.net>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
<linux-nfs@vger.kernel.org>,
Anna Schumaker <schumakeranna@gmail.com>
Subject: Re: list_del corruption / unhash_ol_stateid()
Date: Wed, 05 Aug 2015 12:33:16 -0400 [thread overview]
Message-ID: <m2pp31bsqb.fsf@discipline.rit.edu> (raw)
In-Reply-To: <20150805111132.01a14348@tlielax.poochiereds.net> (Jeff Layton's message of "Wed, 5 Aug 2015 11:11:32 -0400")
> I'm not sure I'm following your shorthand correctly, but, I'm guessing
> the above is that you're creating a stateid and then calling
> init_open_stateid on it to hash it?
>
> If you can flesh out the description of the race, it might be more
> clear.
Sorry, knew that was a bit terse.
nfsd4_process_open2 nfsd4_close
stp = open->op_stp;
nfs4_alloc_stid, refcount is 1
init_open_stateid(stp, fp, open);
is hashed, refcount is 2
nfs4_preprocess_seqid_op()
finds the same stateid,
refcount is 3
nfsd4_close_open_stateid()
unhashes stateid,
put_ol_stateid_locked() drops refcount
refcount is 2
nfs4_get_vfs_file() returns
with status due to:
nfsd_open()
nfsd_open_break_lease()
break_lease() returning
-EWOULDBLOCK
release_open_stateid()
calls unhash_open_stateid()
attempts to unhash,
WARN generated for list_del
proceeds to call put_ol_stateid_locked()
decrements refcount inappropriately
refcount is now 1.
nfs4_put_stid()
refcount is 0, memory is freed
nfs4_put_stid
calls atomic_dec_and_lock()
use after free
first corrupt byte is 6a
because of atomic decrement
with slub_debug on
> Unless...the initial task that created the stateid got _really_
> stalled, and another OPEN raced in, found that stateid and was able to
> reply quickly. Then the client could send a CLOSE for that second OPEN
> before the first opener ever finished.
Sounds plausible given the environment. Would take more effort to
directly prove. I have directly observed the same stateid being used in
the above race.
> If you had multiple racing OPENs then one could find the stateid that
> was previously hashed. A simple fix might be to just use list_del_init
> calls in unhash_ol_stateid. That should make any second list_del's a
> no-op.
>
> Whether that's sufficient to fix the mem corruption, I'm not sure...
It's sc_count decrementing when the unhashing "fails" or is going to
fail. For instance, this kind of construct will prevent one of the
possible use-after-free scenarios.
static void release_open_stateid(struct nfs4_ol_stateid *stp)
{
LIST_HEAD(reaplist);
spin_lock(&stp->st_stid.sc_client->cl_lock);
if (stp->st_perfile->next != LIST_POISON1) {
unhash_open_stateid(stp, &reaplist);
put_ol_stateid_locked(stp, &reaplist);
}
spin_unlock(&stp->st_stid.sc_client->cl_lock);
free_ol_stateid_reaplist(&reaplist);
}
Thanks,
Andy
--
Andrew W. Elble
aweits@discipline.rit.edu
Infrastructure Engineer, Communications Technical Lead
Rochester Institute of Technology
PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912
next prev parent reply other threads:[~2015-08-05 16:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 15:13 list_del corruption / unhash_ol_stateid() Andrew W Elble
2015-07-27 18:06 ` Andrew W Elble
2015-07-27 20:40 ` J. Bruce Fields
2015-07-27 21:03 ` Andrew W Elble
2015-07-28 13:02 ` Jeff Layton
2015-07-28 15:01 ` Andrew W Elble
2015-07-28 15:49 ` Jeff Layton
2015-07-28 21:04 ` J. Bruce Fields
2015-07-29 15:17 ` Andrew W Elble
2015-07-29 19:52 ` Andrew W Elble
2015-07-30 11:11 ` Andrew W Elble
2015-07-30 12:57 ` Jeff Layton
2015-08-04 20:18 ` Andrew W Elble
2015-08-05 15:11 ` Jeff Layton
2015-08-05 16:33 ` Andrew W Elble [this message]
2015-08-05 17:12 ` 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=m2pp31bsqb.fsf@discipline.rit.edu \
--to=aweits@rit.edu \
--cc=bfields@fieldses.org \
--cc=jlayton@poochiereds.net \
--cc=linux-nfs@vger.kernel.org \
--cc=schumakeranna@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox