batman-adv: Fix double fetch in RCU version of hlist_*entry*

The backported (<3.9) version of hlist_for_each_entry_rcu and
hlist_for_each_entry_safe uses the new macro hlist_entry_safe. It is called
with an ACCESS_ONCE parameter for the first parameter ptr. This disallows
merging of the two loads which the current version of the macro uses.

This is problematic because this macro must only generate one load. Otherwise
with two contexts (or CPUs) following could happen:

1. context 1 fetches the ptr to the last entry in hlist_entry_safe() and
   accepts this non-NULL ptr

2. context 2 deletes the last entry and terminates the list with NULL

3. context 1 re-fetches the pointer, doesn't check for zero, calculates the
   entry based on a NULL pointer

4. context 1 crashes because it tries to load/write data from/to the invalid
   address

Instead use a single load to a temporary variable and do the NULL-check and
calculation based on that one.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
batman-adv: fix delayed foreign originator recognition

Currently it can happen that the reception of an OGM from a new
originator is not being accepted. More precisely it can happen that
an originator struct gets allocated and initialized
(batadv_orig_node_new()), even the TQ gets calculated and set correctly
(batadv_iv_ogm_calc_tq()) but still the periodic orig_node purging
thread will decide to delete it if it has a chance to jump between
these two function calls.

This is because batadv_orig_node_new() initializes the last_seen value
to zero and its caller (batadv_iv_ogm_orig_get()) makes it visible to
other threads by adding it to the hash table already.
batadv_iv_ogm_calc_tq() will set the last_seen variable to the correct,
current time a few lines later but if the purging thread jumps in between
that it will think that the orig_node timed out and will wrongly
schedule it for deletion already.

If the purging interval is the same as the originator interval (which is
the default: 1 second), then this game can continue for several rounds
until the random OGM jitter added enough difference between these
two (in tests, two to about four rounds seemed common).

Fixing this by initializing the last_seen variable of an orig_node
to the current time before adding it to the hash table.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>