[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter-devel
Subject:    Re: [patch] Fix ipt_ACCOUNT for large networks - 2nd try
From:       Patrick McHardy <kaber () trash ! net>
Date:       2005-04-24 16:54:35
Message-ID: 426BCF4B.7030500 () trash ! net
[Download RAW message or body]

Carl-Daniel Hailfinger wrote:
> > diff -u -r -b ACCOUNT/linux/net/ipv4/netfilter/ipt_ACCOUNT.c \
> >                 ACCOUNT.1.4/linux/net/ipv4/netfilter/ipt_ACCOUNT.c
> > --- ACCOUNT/linux/net/ipv4/netfilter/ipt_ACCOUNT.c      2004-06-13 \
> >                 22:41:21.000000000 +0200
> > +++ ACCOUNT.1.4/linux/net/ipv4/netfilter/ipt_ACCOUNT.c  2005-04-05 \
> > 09:33:52.000000000 +0200 @@ -694,7 +694,8 @@
> > /* Copy 8 bit network data into a prepared buffer.
> > We only copy entries != 0 to increase performance.
> > */
> > -static int ipt_acc_handle_copy_data(void *to_user, int *pos,
> > +static int ipt_acc_handle_copy_data(void *to_user, u_int32_t *to_user_pos,
> > +                                  u_int32_t *tmpbuf_pos,
> > struct ipt_acc_mask_24 *data,
> > u_int32_t net_ip, u_int32_t net_OR_mask)
> > {
> 
> 
> You seem to like u_int32_t as a type. That causes interesting behaviour
> on 64bit machines. Is there any design objective dictating that?
> I have a patch available changing most occurences of u_int32_t to
> something more generic (of course not for IPs, netmasks and such) which
> may make sense if you ever want to use your module on 64bit machines.

Seems to be fine, AFAICT the u_int32_ts are only used as offsets.

Regards
Patrick


[prev in list] [next in list] [prev in thread] [next in thread]