1. 23 3月, 2011 37 次提交
  2. 22 3月, 2011 3 次提交
    • S
      IPVS: Use global mutex in ip_vs_app.c · 736561a0
      Simon Horman 提交于
      As part of the work to make IPVS network namespace aware
      __ip_vs_app_mutex was replaced by a per-namespace lock,
      ipvs->app_mutex. ipvs->app_key is also supplied for debugging purposes.
      
      Unfortunately this implementation results in ipvs->app_key residing
      in non-static storage which at the very least causes a lockdep warning.
      
      This patch takes the rather heavy-handed approach of reinstating
      __ip_vs_app_mutex which will cover access to the ipvs->list_head
      of all network namespaces.
      
      [   12.610000] IPVS: Creating netns size=2456 id=0
      [   12.630000] IPVS: Registered protocols (TCP, UDP, SCTP, AH, ESP)
      [   12.640000] BUG: key ffff880003bbf1a0 not in .data!
      [   12.640000] ------------[ cut here ]------------
      [   12.640000] WARNING: at kernel/lockdep.c:2701 lockdep_init_map+0x37b/0x570()
      [   12.640000] Hardware name: Bochs
      [   12.640000] Pid: 1, comm: swapper Tainted: G        W 2.6.38-kexec-06330-g69b7efe-dirty #122
      [   12.650000] Call Trace:
      [   12.650000]  [<ffffffff8102e685>] warn_slowpath_common+0x75/0xb0
      [   12.650000]  [<ffffffff8102e6d5>] warn_slowpath_null+0x15/0x20
      [   12.650000]  [<ffffffff8105967b>] lockdep_init_map+0x37b/0x570
      [   12.650000]  [<ffffffff8105829d>] ? trace_hardirqs_on+0xd/0x10
      [   12.650000]  [<ffffffff81055ad8>] debug_mutex_init+0x38/0x50
      [   12.650000]  [<ffffffff8104bc4c>] __mutex_init+0x5c/0x70
      [   12.650000]  [<ffffffff81685ee7>] __ip_vs_app_init+0x64/0x86
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.660000]  [<ffffffff811b1c33>] T.620+0x43/0x170
      [   12.660000]  [<ffffffff811b1e9a>] ? register_pernet_subsys+0x1a/0x40
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.660000]  [<ffffffff811b1db7>] register_pernet_operations+0x57/0xb0
      [   12.660000]  [<ffffffff81685a3b>] ? ip_vs_init+0x0/0xff
      [   12.670000]  [<ffffffff811b1ea9>] register_pernet_subsys+0x29/0x40
      [   12.670000]  [<ffffffff81685f19>] ip_vs_app_init+0x10/0x12
      [   12.670000]  [<ffffffff81685a87>] ip_vs_init+0x4c/0xff
      [   12.670000]  [<ffffffff8166562c>] do_one_initcall+0x7a/0x12e
      [   12.670000]  [<ffffffff8166583e>] kernel_init+0x13e/0x1c2
      [   12.670000]  [<ffffffff8128c134>] kernel_thread_helper+0x4/0x10
      [   12.670000]  [<ffffffff8128ad40>] ? restore_args+0x0/0x30
      [   12.680000]  [<ffffffff81665700>] ? kernel_init+0x0/0x1c2
      [   12.680000]  [<ffffffff8128c130>] ? kernel_thread_helper+0x0/0x1global0
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Julian Anastasov <ja@ssi.bg>
      Cc: Hans Schillstrom <hans@schillstrom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      736561a0
    • E
      ipvs: fix a typo in __ip_vs_control_init() · f40f94fc
      Eric Dumazet 提交于
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Cc: Simon Horman <horms@verge.net.au>
      Cc: Julian Anastasov <ja@ssi.bg>
      Acked-by: NSimon Horman <horms@verge.net.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f40f94fc
    • E
      veth: Fix the byte counters · 675071a2
      Eric W. Biederman 提交于
      Commit 44540960 "veth: move loopback logic to common location" introduced
      a bug in the packet counters.  I don't understand why that happened as it
      is not explained in the comments and the mut check in dev_forward_skb
      retains the assumption that skb->len is the total length of the packet.
      
      I just measured this emperically by setting up a veth pair between two
      noop network namespaces setting and attempting a telnet connection between
      the two.  I saw three packets in each direction and the byte counters were
      exactly 14*3 = 42 bytes high in each direction.  I got the actual
      packet lengths with tcpdump.
      
      So remove the extra ETH_HLEN from the veth byte count totals.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      675071a2