From owner-freebsd-net Wed Oct 16 5:29:37 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4324137B401; Wed, 16 Oct 2002 05:29:35 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2661843EB1; Wed, 16 Oct 2002 05:29:33 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.6/8.12.6) with ESMTP id g9GCTMIw014911; Wed, 16 Oct 2002 14:29:24 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Bruce Evans Cc: net@freebsd.org, arch@freebsd.org Subject: Re: cvs commit: src/sys/dev/kbd atkbdcreg.h In-Reply-To: Your message of "Wed, 16 Oct 2002 22:23:18 +1000." <20021016221657.I5365-100000@gamplex.bde.org> Date: Wed, 16 Oct 2002 14:29:22 +0200 Message-ID: <14910.1034771362@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <20021016221657.I5365-100000@gamplex.bde.org>, Bruce Evans writes: >> This kind of bug is a _really_ horribly thing as we end up with one bit >> of code thinking a particular structure is 136 bytes and another that it >> is only 112 bytes. >> >> Ideally all places would remember to #include the right "opt_foo.h" file, >> but I think in practice file containing the variable sized struct should >> #include it explicitly as a precaution. > >Ideally, header files wouldn't have any "variable sized structs" or >anything else that depends on options. Core headers have to be much >more careful about this because including an options header nested >would break most modules and everything outside of the kernel (apart >from the bug that modules and things outside of the kernel have no >way to determine the correct value for the option). I agree. Suggestions for the best way of fixing "struct ipq" in ip_var.h hereby solicited. I can see that MAC just unceremonously put their own field in there, and I guess that is the most sensible thing to do, despite the RAM this may cost during a DoS attack. Objections to this patch: Index: ip_var.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_var.h,v retrieving revision 1.66 diff -u -r1.66 ip_var.h --- ip_var.h 16 Oct 2002 01:54:44 -0000 1.66 +++ ip_var.h 16 Oct 2002 07:35:44 -0000 @@ -68,10 +68,8 @@ u_short ipq_id; /* sequence id for reassembly */ struct mbuf *ipq_frags; /* to ip headers of fragments */ struct in_addr ipq_src,ipq_dst; -#ifdef IPDIVERT u_int32_t ipq_div_info; /* ipfw divert port & flags */ u_int16_t ipq_div_cookie; /* ipfw divert cookie */ -#endif struct label ipq_label; /* MAC label */ }; #endif /* _KERNEL */ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message