Messages in this thread | | | Date | Fri, 4 Jun 2004 11:15:28 -0700 | From | Greg KH <> | Subject | Re: [PATCH] fix sys cpumap for > 352 NR_CPUS |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |