| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de>
Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From Suzanne Wood <suzannew@cs.pdx.edu>:
Clarify RCU implementation in bpqether.c.
Because bpq_new_device() calls list_add_rcu() and bpq_free_device() calls
list_del_rcu(), substitute list_for_each_entry_rcu() for
list_for_each_entry() in bpq_get_ax25_dev() and in bpq_seq_start().
Add rcu dereference protection in bpq_seq_next().
The rcu_read_lock()/unlock() in bpq_device_event() are removed because
netdev event handlers are called with RTNL locking in place.
FYI: bpq_free_device() calls list_del_rcu() which, per list.h, requires
synchronize_rcu() which can block or call_rcu() or call_rcu_bh() which
cannot block. Herbert Xu notes that synchronization is done here by
unregister_netdevice(). This calls synchronize_net() which in turn uses
synchronize_rcu().
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
|
| |
|
|
|
|
|
|
| |
Rename ax25_encapsulate to ax25_hard_header which these days more
accurately describes what the function is supposed to do.
Signed-off-by: Ralf Baechle DL5RB <ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
|
|
| |
Bonding just wants the device before the skb_bond()
decapsulation occurs, so simply pass that original
device into packet_type->func() as an argument.
It remains to be seen whether we can use this same
exact thing to get rid of skb->input_dev as well.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
|
|
|
|
|
|
|
| |
Replacing the open coded equivalents and making ax25 look more like
a linux network protocol, i.e. more similar to inet.
Signed-off-by: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
|
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
|
