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, 10 Oct 2011 12:08:13 -0500 (CDT)
From:	Christoph Lameter <cl@...two.org>
To:	"Alex,Shi" <alex.shi@...el.com>
cc:	tj@...nel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	eric.dumazet@...il.com, "Huang, Ying" <ying.huang@...el.com>
Subject: Re: [PATCH] Code clean up for percpu_xxx() functions

On Mon, 10 Oct 2011, Alex,Shi wrote:

> index 3470c9d..d1de56c 100644
> --- a/arch/x86/include/asm/percpu.h
> +++ b/arch/x86/include/asm/percpu.h
> @@ -46,7 +46,7 @@
>
>  #ifdef CONFIG_SMP
>  #define __percpu_prefix		"%%"__stringify(__percpu_seg)":"
> -#define __my_cpu_offset		percpu_read(this_cpu_off)
> +#define __my_cpu_offset		this_cpu_read(this_cpu_off)

Should this not be __this_cpu_read() instead?

>   * per-thread variables implemented as per-cpu variables and thus
>   * stable for the duration of the respective task.
>   */
> -#define percpu_read(var)		percpu_from_op("mov", var, "m" (var))
> -#define percpu_read_stable(var)		percpu_from_op("mov", var, "p" (&(var)))
> -#define percpu_write(var, val)		percpu_to_op("mov", var, val)
> -#define percpu_add(var, val)		percpu_add_op(var, val)
> -#define percpu_sub(var, val)		percpu_add_op(var, -(val))
> -#define percpu_and(var, val)		percpu_to_op("and", var, val)
> -#define percpu_or(var, val)		percpu_to_op("or", var, val)
> -#define percpu_xor(var, val)		percpu_to_op("xor", var, val)
> -#define percpu_inc(var)		percpu_unary_op("inc", var)
> +#define this_cpu_read(var)		percpu_from_op("mov", var, "m" (var))
> +#define this_cpu_read_stable(var)	percpu_from_op("mov", var, "p" (&(var)))
> +#define this_cpu_write(var, val)	percpu_to_op("mov", var, val)
> +#define this_cpu_add(var, val)		percpu_add_op(var, val)
> +#define this_cpu_sub(var, val)		percpu_add_op(var, -(val))
> +#define this_cpu_and(var, val)		percpu_to_op("and", var, val)
> +#define this_cpu_or(var, val)		percpu_to_op("or", var, val)
> +#define this_cpu_xor(var, val)		percpu_to_op("xor", var, val)
> +#define this_cpu_inc(var)		percpu_unary_op("inc", var)

Why define these operations? They are already defined in the form of
this_cpu_add_1/2/4/8 and include/linux/percpu.h branches out to them.

> @@ -522,7 +522,7 @@ void sock_release(struct socket *sock)
>  	if (rcu_dereference_protected(sock->wq, 1)->fasync_list)
>  		printk(KERN_ERR "sock_release: fasync list not empty!\n");
>
> -	percpu_sub(sockets_in_use, 1);
> +	this_cpu_sub(sockets_in_use, 1);
>  	if (!sock->file) {
>  		iput(SOCK_INODE(sock));
>  		return;

In general __this_cpu_xx operations can be used instead of this_cpu_xx
operations if the context is already preempt safe. There is no change of
the code generated for x86 in those cases. But the fallback code on other
platforms can generate more efficient code.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ