David Miller <[EMAIL PROTECTED]> writes: > From: Anton Arapov <[EMAIL PROTECTED]> > Date: Wed, 10 Oct 2007 11:56:23 +0200 > >> Yep, that's exactly I'm talking about. I'm sure that >> [...] % (high - low) [...] erroneous from the begining, because >> in such places we want to have 1 in denominator, for the cases when we >> have only one port. Because 34000 34000 in sysctl's >> ip_local_port_range means 1(one) port, not 0(zero). >> >> So it seems to me that we have to fix mentioned denominators in >> kernel/net to have 1, that will be correct logically. And do the >> MAX<MIN check in sysctl code. >> From this point of view, it's best idea to have two patches: one for >> the kernel/net denominators and another one for the sysctl.c's >> function dointvec_minmax(). Because they can live independently. And >> the patch for the kernel/net will do the work at least because we >> prevent kernel trap at all. >> >> Dave, am I right? > > Sure, two patches is fine.
I have been mistaken. We can't modify sysctl code itself to do the checks like (MAX_VAL < MIN_VAL), we have generic functions, and if we want implement something like this we have to implement absolutely new functionality, it's insane to do it. :) It seems to me, all we can is to make this check in code where the MAX_VAL<MINVAL condition brakes logic. FTOH the patch that prevents do_divide_error trap is enough... Kernel will keep working, with huge kernel panic notice in dmesg. :) So, now the way suggested by Denis looks reasonable. What do you think? -- Anton Arapov, <[EMAIL PROTECTED]> Kernel Development, Red Hat GPG Key ID: 0x6FA8C812
pgpKdvARE900u.pgp
Description: PGP signature
