linux-kernel - per cpun+ spin locks coexistence?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

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/