Re: [PATCH] fix sys cpumap for > 352 NR_CPUS

[Andrew Morton]

Paul Jackson <pj@xxxxxxx> wrote:
>
> @@ -21,9 +21,21 @@ static ssize_t node_read_cpumap(struct s
>  	cpumask_t mask = node_dev->cpumap;
>  	int len;
>  
> -	/* FIXME - someone should pass us a buffer size (count) or
> -	 * use seq_file or something to avoid buffer overrun risk. */
> -	len = cpumask_scnprintf(buf, 99 /* XXX FIXME */, mask);
> +	/*
> +	 * Hack alert:
> +	 * 1) This could overwrite a buffer w/o warning.  Someone should
> +	 *     pass us a buffer size (count) or use seq_file or something
> +	 *     to avoid buffer overrun risks.
> +	 * 2) This can return a count larger than the read size requested
> +	 *     by the user code - possibly confusing it.
> +	 * 3) Following hardcodes that mask scnprintf format requires 9
> +	 *     chars of output for each 32 bits of mask or fraction.
> +	 * 4) Following prints stale node_dev->cpumap value, instead of
> +	 *     evaluating afresh node_to_cpumask(node_dev->sysdev.id).
> +	 * 5) Why does struct node even has the field cpumap.  Won't it
> +	 *     just get stale, especially in the face of cpu hotplug?
> +	 */
> +	len = cpumask_scnprintf(buf, ((NR_CPUS+31)/32)*9 /* XXX FIXME */, mask);

Oh dear.  The sysfs failure to pass in a `length' arg bites again.  Can't
we just stick a PAGE_SIZE in here?

wrt the hotplug questions: dunno.  Rusty is ->thattaway.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/