1. 04 4月, 2011 1 次提交
  2. 22 3月, 2011 1 次提交
    • 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
  3. 15 3月, 2011 12 次提交
  4. 25 2月, 2011 1 次提交
  5. 22 2月, 2011 1 次提交
  6. 16 2月, 2011 1 次提交
    • P
      ipvs: make "no destination available" message more informative · 41ac51ee
      Patrick Schaaf 提交于
      When IP_VS schedulers do not find a destination, they output a terse
      "WLC: no destination available" message through kernel syslog, which I
      can not only make sense of because syslog puts them in a logfile
      together with keepalived checker results.
      
      This patch makes the output a bit more informative, by telling you which
      virtual service failed to find a destination.
      
      Example output:
      
      kernel: [1539214.552233] IPVS: wlc: TCP 192.168.8.30:22 - no destination available
      kernel: [1539299.674418] IPVS: wlc: FWM 22 0x00000016 - no destination available
      
      I have tested the code for IPv4 and FWM services, as you can see from
      the example; I do not have an IPv6 setup to test the third code path
      with.
      
      To avoid code duplication, I put a new function ip_vs_scheduler_err()
      into ip_vs_sched.c, and use that from the schedulers instead of calling
      IP_VS_ERR_RL directly.
      Signed-off-by: NPatrick Schaaf <netdev@bof.de>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      41ac51ee
  7. 02 2月, 2011 1 次提交
  8. 13 1月, 2011 14 次提交
  9. 25 11月, 2010 4 次提交
  10. 16 11月, 2010 2 次提交
  11. 21 10月, 2010 2 次提交
    • J
      ipvs: provide address family for debugging · 0d79641a
      Julian Anastasov 提交于
       	As skb->protocol is not valid in LOCAL_OUT add
      parameter for address family in packet debugging functions.
      Even if ports are not present in AH and ESP change them to
      use ip_vs_tcpudp_debug_packet to show at least valid addresses
      as before. This patch removes the last user of skb->protocol
      in IPVS.
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      0d79641a
    • J
      ipvs: changes for local real server · fc604767
      Julian Anastasov 提交于
       	This patch deals with local real servers:
      
      - Add support for DNAT to local address (different real server port).
      It needs ip_vs_out hook in LOCAL_OUT for both families because
      skb->protocol is not set for locally generated packets and can not
      be used to set 'af'.
      
      - Skip packets in ip_vs_in marked with skb->ipvs_property because
      ip_vs_out processing can be executed in LOCAL_OUT but we still
      have the conn_out_get check in ip_vs_in.
      
      - Ignore packets with inet->nodefrag from local stack
      
      - Require skb_dst(skb) != NULL because we use it to get struct net
      
      - Add support for changing the route to local IPv4 stack after DNAT
      depending on the source address type. Local client sets output
      route and the remote client sets input route. It looks like
      IPv6 does not need such rerouting because the replies use
      addresses from initial incoming header, not from skb route.
      
      - All transmitters now have strict checks for the destination
      address type: redirect from non-local address to local real
      server requires NAT method, local address can not be used as
      source address when talking to remote real server.
      
      - Now LOCALNODE is not set explicitly as forwarding
      method in real server to allow the connections to provide
      correct forwarding method to the backup server. Not sure if
      this breaks tools that expect to see 'Local' real server type.
      If needed, this can be supported with new flag IP_VS_DEST_F_LOCAL.
      Now it should be possible connections in backup that lost
      their fwmark information during sync to be forwarded properly
      to their daddr, even if it is local address in the backup server.
      By this way backup could be used as real server for DR or TUN,
      for NAT there are some restrictions because tuple collisions
      in conntracks can create problems for the traffic.
      
      - Call ip_vs_dst_reset when destination is updated in case
      some real server IP type is changed between local and remote.
      
      [ horms@verge.net.au: removed trailing whitespace ]
      Signed-off-by: NJulian Anastasov <ja@ssi.bg>
      Signed-off-by: NSimon Horman <horms@verge.net.au>
      fc604767