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:	Wed, 27 Jun 2007 15:29:08 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Chris Snook <csnook@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, John Stultz <johnstul@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Roman Zippel <zippel@...ux-m68k.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sys_time-speedup-small-cleanup

On 06/26, Chris Snook wrote:
>
> Oleg Nesterov wrote:
> >on top of sys_time-speedup.patch
> >
> >Ingo Molnar wrote:
> >> asmlinkage long sys_time(time_t __user * tloc)
> >> {
> >>-	time_t i;
> >>-	struct timeval tv;
> >>+	/*
> >>+	 * We read xtime.tv_sec atomically - it's updated
> >>+	 * atomically by update_wall_time(), so no need to
> >>+	 * even read-lock the xtime seqlock:
> >>+	 */
> >>+	time_t i = xtime.tv_sec;
> >> 
> >>-	do_gettimeofday(&tv);
> >>-	i = tv.tv_sec;
> >>+	smp_rmb(); /* sys_time() results are coherent */
> >
> >Why do we need this barrier? My guess it is needed to prevent
> >the reading of xtime.tv_sec twice, yes? In that case a simple
> >barrier() should be enough.
> 
> Without the smp_rmb, you can potentially have a situation where one CPU is 
> still reading an old value from cache while another has the new value.  

I can't understand this.

Fisrt, smp_rmb() can't help in this case. It can't influence the preceeding
LOAD if it was from cache.

Even if it could, another CPU can alter the value just after the reading
completes, and we have the same situation.

Could you please clarify if I am wrong?

Oleg.

-
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