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:	Fri, 19 Jul 2013 18:51:52 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Kevin Hilman <khilman@...aro.org>
Cc:	Russell King <rmk+kernel@....linux.org.uk>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	linaro-kernel@...ts.linaro.org
Subject: Re: [PATCH 2/3] init/Kconfig: VIRT_CPU_ACCOUNTING_GEN: drop 64-bit
 requirement

On Wed, Jul 03, 2013 at 11:36:40AM -0700, Kevin Hilman wrote:
> The 64-bit requirement can be removed after the conversion of the nsec
> granularity cputime to work on !64_BIT, which was done in commit
> 8c23b80e (cputime_nsecs: use math64.h for nsec resolution conversion
> helpers)
> 
> Cc: Frederic Weisbecker <fweisbec@...il.com>
> Signed-off-by: Kevin Hilman <khilman@...aro.org>

So I finally sat down and checked all the use of cputime_t (I probably
missed some) to make sure that readers are safe against concurrent write
in 32 bits archs.

And everything looks ok expect perhaps fs/[compat]binfmt_elf*.c that doesn't
lock the signal struct before getting tsk->signal->cutime and stuff. But perhaps
it's safe for some reason, I'll look more carefully. And I also need to
check further itimers code.

But I think I pushed back the ARM support long enough now so it's time to
get this patch in. The above issues are mostly details that can be dealt
with separately.

Just one thing before we apply this. I haven't checked the arch/* potential
unsafe uses of cputime. So it would be nice to bring a new
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN. This won't require any specific arch
support, it would just be there to inform the arch developer, through the help
text, about the issue with cputime being u64 and resulting possible race.
So the guy can have a look at cputime_t uses in his arch before finally enabling
that config.

Also, of course check that arm is fine wrt. that and finally enable it :)

Thanks!


> ---
>  init/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 2d9b831..e151022 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -325,7 +325,7 @@ config VIRT_CPU_ACCOUNTING_NATIVE
>  
>  config VIRT_CPU_ACCOUNTING_GEN
>  	bool "Full dynticks CPU time accounting"
> -	depends on HAVE_CONTEXT_TRACKING && 64BIT
> +	depends on HAVE_CONTEXT_TRACKING
>  	select VIRT_CPU_ACCOUNTING
>  	select CONTEXT_TRACKING
>  	help
> -- 
> 1.8.3
> 
--
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