lkml.org 
[lkml]   [2004]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH][SELINUX] 2/7 Add netif controls
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/

\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.093 / U:0.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site