Hi Liping, On Tue, Sep 27, 2016 at 1:49 PM, Liping Zhang <zlpnobody@xxxxxxxxx> wrote: > Hi Feng, > > 2016-09-27 12:39 GMT+08:00 <fgao@xxxxxxxxxx>: >> From: Gao Feng <fgao@xxxxxxxxxx> >> >> Current xt_osf codes use memcmp to check if two user fingers are same, >> so it depends on that the struct xt_osf_user_finger is no padding. >> It is one implicit rule, and is not good to maintain. >> >> Now use zero memory and assign the members explicitly. >> >> Signed-off-by: Gao Feng <fgao@xxxxxxxxxx> >> --- >> net/netfilter/xt_osf.c | 32 ++++++++++++++++++++++++++++++-- >> 1 file changed, 30 insertions(+), 2 deletions(-) >> >> diff --git a/net/netfilter/xt_osf.c b/net/netfilter/xt_osf.c >> index 2455b69..9793670 100644 >> --- a/net/netfilter/xt_osf.c >> +++ b/net/netfilter/xt_osf.c >> @@ -61,6 +61,34 @@ static const struct nla_policy xt_osf_policy[OSF_ATTR_MAX + 1] = { >> [OSF_ATTR_FINGER] = { .len = sizeof(struct xt_osf_user_finger) }, >> }; >> >> +static void copy_user_finger(struct xt_osf_user_finger *dst, >> + const struct xt_osf_user_finger *src) >> +{ >> +#define OSF_COPY_MEMBER(mem) dst->mem = src->mem >> + >> + int i; >> + >> + OSF_COPY_MEMBER(wss.wc); >> + OSF_COPY_MEMBER(wss.val); >> + >> + OSF_COPY_MEMBER(ttl); >> + OSF_COPY_MEMBER(df); >> + OSF_COPY_MEMBER(ss); >> + OSF_COPY_MEMBER(mss); >> + OSF_COPY_MEMBER(opt_num); >> + >> + memcpy(dst->genre, src->genre, sizeof(dst->genre)); >> + memcpy(dst->version, src->version, sizeof(dst->version)); >> + memcpy(dst->subtype, src->subtype, sizeof(dst->subtype)); >> + >> + for (i = 0; i < MAX_IPOPTLEN; ++i) { >> + OSF_COPY_MEMBER(opt[i].kind); >> + OSF_COPY_MEMBER(opt[i].length); >> + OSF_COPY_MEMBER(opt[i].wc.wc); >> + OSF_COPY_MEMBER(opt[i].wc.val); >> + } >> +} >> + > > This xt_osf_user_finger{} is carefully designed, no padding now, and > will not be changed in the future, otherwise backward compatibility will > be broken. Yes, there is no padding now. So it is ok to use memcmp now. I am afraid the struct would be modified for other requirements. If it is never changed forever, it is ok certainly. > > I don't think this convert is necessary, actually it is a little ugly, and will > increase the maintenance burden. I just want the codes don't depend any implicit rule. It is a tradeoff. If never change, needn't do any convert. If may change, the memcmp is a little dangerous. Regards Feng -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html