From: Marek Lindner <lindner_marek@yahoo.de>
To: The list for a Better Approach To Mobile Ad-hoc Networking
<b.a.t.m.a.n@lists.open-mesh.org>
Subject: Re: [B.A.T.M.A.N.] [PATCHv3 1/9] batman-adv: make struct batadv_neigh_node algorithm agnostic
Date: Fri, 16 Aug 2013 17:27:51 +0800 [thread overview]
Message-ID: <201308161727.51653.lindner_marek@yahoo.de> (raw)
In-Reply-To: <20130816062729.GV849@ritirata.org>
On Friday, August 16, 2013 14:27:29 Antonio Quartulli wrote:
> On Fri, Aug 16, 2013 at 11:46:41AM +0800, Marek Lindner wrote:
> > On Tuesday, August 13, 2013 14:43:44 Antonio Quartulli wrote:
> > > @@ -1011,13 +1011,13 @@ batadv_iv_ogm_update_seqnos(const struct ethhdr
> > > *ethhdr, }
> > >
> > > /* if the window moved, set the update flag. */
> > >
> > > - need_update |= batadv_bit_get_packet(bat_priv,
> > > - tmp_neigh_node->real_bits,
> > > + bitmap = tmp_neigh_node->bat_iv.real_bits;
> > > + need_update |= batadv_bit_get_packet(bat_priv, bitmap,
> > >
> > > seq_diff, set_mark);
> > >
> > > - packet_count = bitmap_weight(tmp_neigh_node->real_bits,
> > > + packet_count = bitmap_weight(tmp_neigh_node->bat_iv.real_bits,
> > >
> > > BATADV_TQ_LOCAL_WINDOW_SIZE);
> > >
> > > - tmp_neigh_node->real_packet_count = packet_count;
> > > + tmp_neigh_node->bat_iv.real_packet_count = packet_count;
> > >
> > > }
> >
> > You can't make assumptions about the size of bitmap because it is
> > platform specific which is why the variable declaration is a macro in
> > the first place.
>
> where do I make such assumption? Variable bitmap is a just storing the
> address of the bitmap.
If it is just the address it probably is ok - you are right.
> > > - struct batadv_priv *bat_priv = netdev_priv(hard_iface->soft_iface);
> > >
> > > struct batadv_neigh_node *neigh_node;
> > >
> > > neigh_node = kzalloc(sizeof(*neigh_node), GFP_ATOMIC);
> > > if (!neigh_node)
> > >
> > > goto out;
> > >
> > > - INIT_HLIST_NODE(&neigh_node->list);
> > > -
> > >
> > > memcpy(neigh_node->addr, neigh_addr, ETH_ALEN);
> > >
> > > - spin_lock_init(&neigh_node->lq_update_lock);
> > > + neigh_node->if_incoming = hard_iface;
> > > + neigh_node->orig_node = orig_node;
> > > +
> > > + spin_lock_bh(&orig_node->neigh_list_lock);
> > > + hlist_add_head_rcu(&neigh_node->list, &orig_node->neigh_list);
> > > + spin_unlock_bh(&orig_node->neigh_list_lock);
> > > +
> > > + INIT_LIST_HEAD(&neigh_node->bonding_list);
> > >
> > > /* extra reference for return */
> > > atomic_set(&neigh_node->refcount, 2);
> > >
> > > - batadv_dbg(BATADV_DBG_BATMAN, bat_priv,
> > > - "Creating new neighbor %pM on interface %s\n", neigh_addr,
> > > - hard_iface->net_dev->name);
> > > -
> > >
> > > out:
> > > return neigh_node;
> > >
> > > }
> >
> > All variables should be initialized before we add the new entry to the
> > any list.
>
> object is allocated with kzalloc: everything is zero. I thought we use
> kzalloc for this purpose: avoid initialisation of every field..no?
What is "INIT_LIST_HEAD(&neigh_node->bonding_list);" ? Looks like an
initialization if I am not mistaken. Moreover, batadv_iv_ogm_neigh_new() inits
even more after this function returns ...
Cheers,
Marek
next prev parent reply other threads:[~2013-08-16 9:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-13 6:43 [B.A.T.M.A.N.] [PATCHv3 0/9] Improving the routing protocol abstraction Antonio Quartulli
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 1/9] batman-adv: make struct batadv_neigh_node algorithm agnostic Antonio Quartulli
2013-08-16 3:46 ` Marek Lindner
2013-08-16 6:27 ` Antonio Quartulli
2013-08-16 9:27 ` Marek Lindner [this message]
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 2/9] batman-adv: make struct batadv_orig_node " Antonio Quartulli
2013-08-16 4:01 ` Marek Lindner
2013-08-16 6:29 ` Antonio Quartulli
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 3/9] batman-adv: add bat_orig_print function API Antonio Quartulli
2013-08-16 4:05 ` Marek Lindner
2013-08-16 6:30 ` Antonio Quartulli
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 4/9] batman-adv: add bat_metric_get API function Antonio Quartulli
2013-08-26 1:44 ` Marek Lindner
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 5/9] batman-adv: add bat_metric_is_equiv_or_better " Antonio Quartulli
2013-08-26 1:49 ` Marek Lindner
2013-08-26 6:37 ` Antonio Quartulli
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 6/9] batman-adv: adapt bonding to use the new API functions Antonio Quartulli
2013-08-26 3:11 ` Marek Lindner
2013-08-27 16:33 ` Antonio Quartulli
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 7/9] batman-adv: adapt the neighbor purging routine " Antonio Quartulli
2013-08-26 3:29 ` Marek Lindner
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 8/9] batman-adv: provide orig_node routing API Antonio Quartulli
2013-08-26 3:31 ` Marek Lindner
2013-08-13 6:43 ` [B.A.T.M.A.N.] [PATCHv3 9/9] batman-adv: adapt the TT component to use the new API functions Antonio Quartulli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201308161727.51653.lindner_marek@yahoo.de \
--to=lindner_marek@yahoo.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.