netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paul Moore <paul.moore@hp.com>
To: paulmck@linux.vnet.ibm.com
Cc: selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org,
	netdev@vger.kernel.org
Subject: Re: [RFC PATCH v1 2/6] netlabel: Replace protocol/NetLabel linking with refrerence counts
Date: Fri, 8 Aug 2008 22:11:32 -0400	[thread overview]
Message-ID: <200808082211.32951.paul.moore@hp.com> (raw)
In-Reply-To: <20080808223716.GM6760@linux.vnet.ibm.com>

On Friday 08 August 2008 6:37:16 pm Paul E. McKenney wrote:
> On Fri, Aug 08, 2008 at 04:53:01PM -0400, Paul Moore wrote:
> >  struct cipso_v4_doi *cipso_v4_doi_getdef(u32 doi)
> >  {
> > -	return cipso_v4_doi_search(doi);
> > +	struct cipso_v4_doi *doi_def;
> > +
> > +	rcu_read_lock();
> > +	doi_def = cipso_v4_doi_search(doi);
> > +	if (doi_def)
>
> Suppose that the doi_def element is removed by some other CPU at
> this point.  The reference-count check would pass (so that the
> deletion function would decline to error out with -EBUSY), and the
> removal would proceed normally.  (Right?)
>
> So we then acquire the reference count on an element that will be
> freed after an RCU grace period, despite the fact that the reference
> count might still be held at that point.
>
> Or am I missing something?  (Wouldn't be a surprise, as it is not
> like I am familiar with this code.)

Hi Paul,

Thanks for taking a look, your point sounds reasonable to me.

> If I am correct, the usual resolution is to combine the reference
> count and the "valid" flag, so that a zero reference counter implies
> "not valid", allowing the atomic_inc() below to become
> atomic_inc_not_zero(), allowing you to simply return NULL should the
> race with removal be detected.  There are other approaches as well...

Combining the valid and refcount fields seems reasonable to me.  I took 
your advice and made the following changes (as well as they other 
changes to replace the valid check with atomic_read(refcount) > 0) ...

struct cipso_v4_doi *cipso_v4_doi_getdef(u32 doi)
{
	struct cipso_v4_doi *doi_def;

	rcu_read_lock();
	doi_def = cipso_v4_doi_search(doi);
	if (doi_def == NULL)
		goto doi_getdef_return;
	if (!atomic_inc_not_zero(&doi_def->refcount))
		doi_def = NULL;

doi_getdef_return:
	rcu_read_unlock();
	return doi_def;
}

int cipso_v4_doi_remove(u32 doi,
			struct netlbl_audit *audit_info,
			void (*callback) (struct rcu_head * head))
{
	struct cipso_v4_doi *doi_def;

	spin_lock(&cipso_v4_doi_list_lock);
	doi_def = cipso_v4_doi_search(doi);
	if (doi_def == NULL) {
		spin_unlock(&cipso_v4_doi_list_lock);
		return -ENOENT;
	}
	if (!atomic_dec_and_test(&doi_def->refcount)) {
		spin_unlock(&cipso_v4_doi_list_lock);
		return -EBUSY;
	}
	list_del_rcu(&doi_def->list);
	spin_unlock(&cipso_v4_doi_list_lock);

	cipso_v4_cache_invalidate();
	call_rcu(&doi_def->rcu, callback);

	return 0;
}

Does that look better?

-- 
paul moore
linux @ hp

  reply	other threads:[~2008-08-09  2:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08 20:52 [RFC PATCH v1 0/6] Labeled networking patches for 2.6.28 Paul Moore
2008-08-08 20:52 ` [RFC PATCH v1 1/6] selinux: Fix a problem in security_netlbl_sid_to_secattr() Paul Moore
2008-08-08 20:53 ` [RFC PATCH v1 2/6] netlabel: Replace protocol/NetLabel linking with refrerence counts Paul Moore
2008-08-08 22:37   ` Paul E. McKenney
2008-08-09  2:11     ` Paul Moore [this message]
2008-08-09 13:23       ` Paul E. McKenney
2008-08-09 14:40         ` Paul Moore
2008-08-08 20:53 ` [RFC PATCH v1 3/6] netlabel: Add a generic way to create ordered linked lists of network addrs Paul Moore
2008-08-08 20:53 ` [RFC PATCH v1 4/6] netlabel: Add network address selectors to the NetLabel/LSM domain mapping Paul Moore
2008-08-08 20:53 ` [RFC PATCH v1 5/6] netlabel: Add functionality to set the security attributes of a packet Paul Moore
2008-08-08 20:53 ` [RFC PATCH v1 6/6] selinux: Set socket NetLabel based on connection endpoint Paul Moore
2008-08-08 23:09 ` [RFC PATCH v1 0/6] Labeled networking patches for 2.6.28 David Miller
2008-08-09  2:18   ` Paul Moore

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=200808082211.32951.paul.moore@hp.com \
    --to=paul.moore@hp.com \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=selinux@tycho.nsa.gov \
    /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).