On Sun, 2002/07/14 at 01:18:10 -0700, Luigi Rizzo wrote:
> Hi,
> the following message seems to suggest that the compiler
> (the way it is invoked) packs structures differently
> when building the kernel and userland.
> The stize of the structure in question is computed
> by both kernel and userland app using sizeof(),
> so there is no assumption on the size of its members,
> so i believe the only possibility of a mismatch is
> the one above.
> Any ideas ?

(Disclaimer: my solution below is untested, so it may all be bogus)

No, you are not accounting for "external" structure padding. Take a

  struct ip_fw {
          struct ip_fw  *next;          /* linked list of rules */
          u_int16_t     act_ofs;        /* offset of action in 32-bit units */
          u_int16_t     cmd_len;        /* # of 32-bit words in cmd     */
          u_int16_t     rulenum;        /* rule number                  */
          u_int16_t     _pad;           /* padding                      */

          /* These fields are present in all rules.                     */
          u_int64_t     pcnt;           /* Packet counter               */
          u_int64_t     bcnt;           /* Byte counter                 */
          u_int32_t     timestamp;      /* tv_sec of last match         */

          struct ip_fw *next_rule;      /* ptr to next rule             */

          ipfw_insn     cmd[1];         /* storage for commands         */

On a 64-bit architecture, pointers are obviously 8 bytes in size;
structure members must or should be on natural borders, depending on
the architecture.
So, next_rule will not be on a natural border; 4 bytes of padding will
be inserted before it. With that, the total structure size would be
The compiler must account for the fact that an array of struct ip_fws
may be used. For obvious reasons, it can not just insert extra padding
in the array case; instead, the structure size must be chosen so that
in this situation, the first member will be on a natural border.
This results in an extra 4 bytes of "external" padding at the end,
after the member 'cmd'.
The macro you use to compute the size in the kernel is:

  #define RULESIZE(rule)  (sizeof(struct ip_fw) + \
          ((struct ip_fw *)(rule))->cmd_len * 4 - 4)

In the userland code, you start at &foo.cmd and append data
directly. This means that the padding will also be used to store
data, so the '- 4' (= sizeof(foo.cmd)) will not always be enough. The
following definition of RULESIZE (untested) should fix this:

  #define RULESIZE(rule)  (offsetof(struct ip_fw, cmd) + \
          ((struct ip_fw *)(rule))->cmd_len * 4)

It also removes the explicit 4 for sizeof(ipfw_insn).

        - thomas

Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/
              <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0  9C0F 1FE6 4F1D 419C 776C

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to