From: Neil Brown <neilb@suse.de>
To: Neil Brown <neilb@suse.de>
Cc: ebiederm@xmission.com (Eric W. Biederman),
Greg Kroah-Hartman <gregkh@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] sysfs: simplify handling for s_active refcount
Date: Mon, 29 Mar 2010 18:47:40 +1100 [thread overview]
Message-ID: <20100329184740.5d99edef@notabene.brown> (raw)
In-Reply-To: <20100329154325.2bb42a9c@notabene.brown>
On Mon, 29 Mar 2010 15:43:25 +1100
Neil Brown <neilb@suse.de> wrote:
> However if we do consider memory ordering guarantees we can describe a clear
> limit to the possibly delay between SYSFS_FLAG_REMOVED being set, and being
> seen. The atomic_inc_not_zero serves as a memory barrier in exactly the same
> way that the current code requires atomic_dec_return. So while
>
> if (likely(sd)
> && (sd->s_flags & SYSFS_FLAG_REMOVED) == 0
> && atomic_inc_not_zero(&sd->s_active)) {
>
> could possibly gain a reference even 'after' SYS_FLAG_REMOVED as been set,
> a second call to this on the same processor will see SYSFS_FLAG_REMOVED.
> So at the absolute most, we could see NCPUS active references gained and
> dropped after SYSFS_FLAG_REMOVED was set - a clear limit which is all we need.
It just occurred to me that this 'proof' isn't quite complete in itself. I
need to also show that there is a suitable memory barrier after
SYSFS_FLAG_REMOVED is set. There is as it is always set under sysfs_mutex,
so the mutex_unlock provides a barrier.
So after sysfs_mutex is unlocked, it is conceivable that each CPU could grant
one active reference against the sysfs_dirent before SYSFS_FLAG_REMOVED was
globally visible.
> I'm still not sure we even need to argue in terms of memory barriers to be
> sure the code is correct, but it seems they are sufficient to give a simple
> proof.
NeilBrown
next prev parent reply other threads:[~2010-03-29 7:47 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-24 3:20 [PATCH 0/3] refcounting improvements in sysfs NeilBrown
2010-03-24 3:20 ` [PATCH 3/3] kref: create karef and use for sysfs_dirent->s_active NeilBrown
2010-03-26 4:50 ` Eric W. Biederman
2010-03-24 3:20 ` [PATCH 1/3] sysfs: simplify handling for s_active refcount NeilBrown
2010-03-26 4:24 ` Eric W. Biederman
2010-03-26 5:32 ` Neil Brown
2010-03-26 5:42 ` Tejun Heo
2010-03-26 7:53 ` Eric W. Biederman
2010-03-29 4:43 ` Neil Brown
2010-03-29 7:47 ` Neil Brown [this message]
2010-03-24 3:20 ` [PATCH 2/3] sysfs: make s_count a kref NeilBrown
2010-03-26 4:29 ` Eric W. Biederman
2010-03-26 3:10 ` [PATCH 0/3] refcounting improvements in sysfs Eric W. Biederman
2010-03-26 3:28 ` Neil Brown
2010-03-26 4:49 ` Tejun Heo
2010-03-26 5:10 ` Tejun Heo
2010-03-26 6:02 ` Neil Brown
2010-03-26 6:32 ` Tejun Heo
2010-03-29 5:10 ` Neil Brown
2010-03-31 3:20 ` Tejun Heo
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=20100329184740.5d99edef@notabene.brown \
--to=neilb@suse.de \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@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 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.