"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> >> My hypothesis. No one cares now. >> >> My observation. The way we have been maintaining the binary sysctl >> side of things using it is asking for your application to be broken in >> subtle and nasty ways. >> > > I suspect the right thing to do is simply to make a list of the supported > binary > sysctls, and automatically verify those numbers. Doing that would alleviate > these concerns, wouldn't break anything, and isn't really that hard to do.
Well the list is currently 1200 lines long, with wild cards in it. See sysctl_check.c in the -mm tree. I think I have finally found all of the binary sysctl numbers that are currently in use but I may have missed something. Although that can probably be trimmed a bit now that a number of those sysctls have been identified as impossibly and always broken The real problem is that sysctl uses different functions for the binary path and the proc path. Those functions return the same data in two different forms. When those functions diverge we have problems. As I recently found with about 42 of the netfilter sysctls. The concern is that no one uses these things so no one tests these things, and no one complains about these things so the code bit rots. When the code bit rots we can return the wrong value or set the wrong value in the kernel or skip locking or skip permission checks or various other nasty things. Hmm. Thinking about it I guess so far I have found about 10% of the binary sysctls to have actual implementation problems. Not my idea of well maintained code. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
