Date: Fri, 9 Jan 2004 16:46:18 -0500 (EST)
From: James Morris <jmorris@redhat.com>
To: Andrew Morton <akpm@osdl.org>
cc: linux-kernel@vger.kernel.org, <sds@epoch.ncsc.mil>,
       <selinux@tycho.nsa.gov>
Subject: Re: [PATCH][SELINUX] 2/7 Add netif controls
In-Reply-To: <20040109130613.711b34a6.akpm@osdl.org>
Message-ID: <Xine.LNX.4.44.0401091638160.22937-100000@thoron.boston.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1393
Lines: 45

On Fri, 9 Jan 2004, Andrew Morton wrote:

> James Morris <jmorris@redhat.com> wrote:
> >
> > +static void sel_netif_destroy(struct sel_netif *netif)
> > +{
> > +	DEBUGP("%s: %s\n", __FUNCTION__, netif->nsec.dev->name);
> > +	
> > +	spin_lock_bh(&sel_netif_lock);
> > +	list_del_rcu(&netif->list);
> > +	sel_netif_total--;
> > +	spin_unlock_bh(&sel_netif_lock);
> > +
> > +	call_rcu(&netif->rcu_head, sel_netif_free, netif);
> > +}
> > +
> > +void sel_netif_put(struct sel_netif *netif)
> > +{
> > +	if (atomic_dec_and_test(&netif->users))
> > +		sel_netif_destroy(netif);
> > +}
> 
> This seems racy.  If the netif is still eligible for lookup on entry to
> sel_netif_put(), another CPU can come in and find the netif while it is
> hashed but while it has a zero refcount.  Only to have the netif destroyed
> under its feet?

The netif won't actually be freed until all of the CPUs have gone through
a quiescent state, and the calling code running on the other CPU will have
called sel_netif_put() before then.  These objects are extremely short
lived and should not be held over context switches.


- James
-- 
James Morris
<jmorris@redhat.com>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/