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:	Thu, 31 Oct 2013 16:17:39 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Soren Brinkmann <soren.brinkmann@...inx.com>
Cc:	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Peter Crosthwaite <peter.crosthwaite@...inx.com>
Subject: Re: [PATCH 1/6] arm: zynq: platsmp: Fix CPU presence check

On Thu, Oct 31, 2013 at 09:10:14AM -0700, Soren Brinkmann wrote:
> From: Peter Crosthwaite <peter.crosthwaite@...inx.com>
> 
> Fix an off-by-one error in the logic that checks if a CPU is present.
> The ncores variable is a count of cores while the cpu variable is a
> 0 based index. So if ncores == cpu, cpu is out of range. Fix this
> comparison so non-existent CPUs are not probed.
> 
> Signed-off-by: Peter Crosthwaite <peter.crosthwaite@...inx.com>
> Signed-off-by: Michal Simek <michal.simek@...inx.com>

There's another two bugs here.

> ---
>  arch/arm/mach-zynq/platsmp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
> index 689fbbc3d9c8..2512624e657d 100644
> --- a/arch/arm/mach-zynq/platsmp.c
> +++ b/arch/arm/mach-zynq/platsmp.c
> @@ -39,7 +39,7 @@ int zynq_cpun_start(u32 address, int cpu)
>  	u32 trampoline_code_size = &zynq_secondary_trampoline_end -
>  						&zynq_secondary_trampoline;
>  
> -	if (cpu > ncores) {
> +	if (cpu >= ncores) {
>  		pr_warn("CPU No. is not available in the system\n");

Much better: pr_warn("CPU%d is not available\n", cpu);

However, if you have set the cpu possible/present masks correctly,
you will never hit this because the generic code already checks that
the CPU being requested is legal.  So actually I'd suggest getting
rid of this entire if() statement and block.

>  		return -1;

The second issue is one of laziness.  -1 as a return code for something
that gets propagated back to userspace.  Do we really mean to return to
userspace -EPERM because of this or other failures in this function?
All those idiotic and lazy (and that's exactly what they are - idiotic
and lazy) "return -1" statements need to be fixed.

Shame on the arm-soc maintainers for not having an automatic filter for
this kind of sloppy programming.
--
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