[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <804dabb00803120917w451b16e6q685016d464a2edde@mail.gmail.com>
Date: Thu, 13 Mar 2008 00:17:28 +0800
From: "Peter Teoh" <htmldeveloper@...il.com>
To: LKML <linux-kernel@...r.kernel.org>
Subject: per cpun+ spin locks coexistence?
Help me out this one - in fs/file.c, there is a function free_fdtable_rcu():
void free_fdtable_rcu(struct rcu_head *rcu)
{
struct fdtable *fdt = container_of(rcu, struct fdtable, rcu);
struct fdtable_defer *fddef;
BUG_ON(!fdt);
if (fdt->max_fds <= NR_OPEN_DEFAULT) {
/*
* This fdtable is embedded in the files structure and that
* structure itself is getting destroyed.
*/
kmem_cache_free(files_cachep,
container_of(fdt, struct files_struct,
fdtab));
return;
}
if (fdt->max_fds <= (PAGE_SIZE / sizeof(struct file *))) {
kfree(fdt->fd);
kfree(fdt->open_fds);
kfree(fdt);
} else {
fddef = &get_cpu_var(fdtable_defer_list);
spin_lock(&fddef->lock);
fdt->next = fddef->next;
fddef->next = fdt;
/* vmallocs are handled from the workqueue context */
schedule_work(&fddef->wq);
spin_unlock(&fddef->lock);
put_cpu_var(fdtable_defer_list);
}
}
Notice above that get_cpu_var() is followed by spin_lock(). Does this
make sense? get_cpu_var() will return a variable that is only
accessible by the current CPU - guaranteed it will not be touch (read or
write) by another CPU, right? so why do we need to spin_lock() it?
Thanks.
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists