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

[Greg KH]

On Fri, Jun 04, 2004 at 11:27:46AM +1000, Rusty Russell wrote:
> On Fri, 2004-06-04 at 02:51, Greg KH wrote:
> > Just be aware of the size and code your show() function to be defensive
> > and not overrun that size.
> 
> This is where we have a philosophical difference.  As I understand it,
> the rule is, "don't put big things in attributes".  If we want to change
> that rule, we need to do more work, like pass the length to the show
> function, and handle -ENOMEM by reallocating and looping.

We don't want to change the rule, it's a good rule.

> But I think the /rule/ is a good one: if you need to handle something
> arbitrarily large, DON'T USE THIS INTERFACE, because there is no way to
> do that correctly.  This allows us to handle 99.9% of cases as a
> one-liner, which I think has great merit.

Agreed.

> I think we should guarantee any kernel primitive fits into the space:
> this means it should comfortably fit printing a cpumask_t.  I would
> argue for a #error inside the cpumask or sysfs code which ensures we can
> fit two cpumasks (~7000 CPUs on page-size 4096), so we explode early if
> this ever becomes a problem, and a runtime sanity check inside the sysfs
> code to BUG on overrun.

Again, this seems to be a issue with the code that is trying to export a
cpumask_t.  I suggest you keep the check inside that code and keep it
out of the sysfs core, which does not need it for 99.99% of the cases.

thanks,

greg k-h
-
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/