linux-kernel - Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Mar 2008 00:30:23 +0800
From:	"Peter Teoh" <htmldeveloper@...il.com>
To:	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Johannes Weiner" <hannes@...urebad.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	"Tejun Heo" <htejun@...il.com>,
	"Dipankar Sarma" <dipankar@...ibm.com>
Subject: Re: per cpun+ spin locks coexistence?

Thanks for the answer.   But I still don't get it.

On Sat, Mar 15, 2008 at 1:54 AM, Jeremy Fitzhardinge <jeremy@...p.org> wrote:
>
> Peter Teoh wrote:
>  > 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?
>
>  No, not true.  percpu is for stuff which is generally only touched by
>  one CPU, but there's nothing stopping other processors from accessing it
>  with per_cpu(var, cpu).

get_cpu_var() above, will return a ptr specific for a particular CPU
only, is correct?

#define get_cpu_var(var) (*({                           \
        extern int simple_identifier_##var(void);       \
        preempt_disable();                              \
        &__get_cpu_var(var); }))

SMP:

#define __get_cpu_var(var) \
        (*SHIFT_PERCPU_PTR(&per_cpu_var(var), my_cpu_offset))

#define SHIFT_PERCPU_PTR(__p, __offset) RELOC_HIDE((__p), (__offset))

and RELOC_HIDE() i don't understand.   So from what u said,
per_cpu_var() returns uniquely for each CPU, but __get_cpu_var() may
not be unique among the different CPU - is that correct?

When cpuA and cpuB call get_cpu_var(), the returned ptr is specific
only for cpuA and cpuB, right?   So yes, as u said, different cpu can
call get_cpu_var(), but the returned ptr will be unique to each cpu,
therefore it is guaranteed that another CPU will not get hold of the
returned results of get_cpu_var(), right?   So why spin_lock() comes
after get_cpu_var()?

>
>  Besides, the lock isn't locking the percpu list head, but the thing on
>  the head of the list, presumably to prevent races with the workqueue.

I think I have something much deeper to learn.   Can u point me to
some resources to read more about this?
I don't understand the difference betw locking the percpu list head,
and locking things on the head of the list.   For me, spin_lock() is
always to apply on ANY global variable - so that another cpu will
block when access to it is attempted - whether it is items on a list,
ot head of the list etc.

>  (Though the list structure is nonstandard, so its not completely clear.)
>
>     J

Thank you in advance for the all the help rendered, :=).

-- 
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/