1. 16 12月, 2008 3 次提交
    • Y
      ipv6: fix the outgoing interface selection order in udpv6_sendmsg() · 9f690db7
      Yang Hongyang 提交于
      1.When no interface is specified in an IPV6_PKTINFO ancillary data
        item, the interface specified in an IPV6_PKTINFO sticky optionis 
        is used.
      
      RFC3542:
      6.7.  Summary of Outgoing Interface Selection
      
         This document and [RFC-3493] specify various methods that affect the
         selection of the packet's outgoing interface.  This subsection
         summarizes the ordering among those in order to ensure deterministic
         behavior.
      
         For a given outgoing packet on a given socket, the outgoing interface
         is determined in the following order:
      
         1. if an interface is specified in an IPV6_PKTINFO ancillary data
            item, the interface is used.
      
         2. otherwise, if an interface is specified in an IPV6_PKTINFO sticky
            option, the interface is used.
      Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9f690db7
    • Y
      ipv6: fix the return interface index when get it while no message is received · f250dcda
      Yang Hongyang 提交于
      When get receiving interface index while no message is received,
      the the value seted with setsockopt() should be returned.
      
      RFC 3542:
         Issuing getsockopt() for the above options will return the sticky
         option value i.e., the value set with setsockopt().  If no sticky
         option value has been set getsockopt() will return the following
         values:
      
         -  For the IPV6_PKTINFO option, it will return an in6_pktinfo
            structure with ipi6_addr being in6addr_any and ipi6_ifindex being
            zero.
      Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f250dcda
    • Y
      ipv6: Add IPV6_PKTINFO sticky option support to setsockopt() · b24a2516
      Yang Hongyang 提交于
      There are three reasons for me to add this support:
      1.When no interface is specified in an IPV6_PKTINFO ancillary data
        item, the interface specified in an IPV6_PKTINFO sticky optionis 
        is used.
      
      RFC3542:
      6.7.  Summary of Outgoing Interface Selection
      
         This document and [RFC-3493] specify various methods that affect the
         selection of the packet's outgoing interface.  This subsection
         summarizes the ordering among those in order to ensure deterministic
         behavior.
      
         For a given outgoing packet on a given socket, the outgoing interface
         is determined in the following order:
      
         1. if an interface is specified in an IPV6_PKTINFO ancillary data
            item, the interface is used.
      
         2. otherwise, if an interface is specified in an IPV6_PKTINFO sticky
            option, the interface is used.
      
      2.When no IPV6_PKTINFO ancillary data is received,getsockopt() should 
        return the sticky option value which set with setsockopt().
      
      RFC 3542:
         Issuing getsockopt() for the above options will return the sticky
         option value i.e., the value set with setsockopt().  If no sticky
         option value has been set getsockopt() will return the following
         values:
      
      3.Make the setsockopt implementation POSIX compliant.
      Signed-off-by: NYang Hongyang <yanghy@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b24a2516
  2. 15 12月, 2008 3 次提交
  3. 11 12月, 2008 9 次提交
  4. 10 12月, 2008 1 次提交
    • J
      ipv6: silence log messages for locally generated multicast · 24fc7b86
      Jan Sembera 提交于
      This patch fixes minor annoyance during transmission of unsolicited
      neighbor advertisements from userspace to multicast addresses (as
      far as I can see in RFC, this is allowed and the similar functionality
      for IPv4 has been in arping for a long time).
      
      Outgoing multicast packets get reinserted into local processing as if they
      are received from the network. The machine thus sees its own NA and fills
      the logs with error messages. This patch removes the message if NA has been
      generated locally.
      Signed-off-by: NJan Sembera <jsembera@suse.cz>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      24fc7b86
  5. 04 12月, 2008 3 次提交
    • J
      36cbac59
    • B
      net: /proc/net/ip_mr_cache, display Iif as a signed short · 999890b2
      Benjamin Thery 提交于
      Today, iproute2 fails to show multicast forwarding unresolved cache
      entries while scanning /proc/net/ip_mr_cache.
      
      Indeed, it expects to see -1 in 'Iif' column to identify unresolved
      entries but the kernel outputs 65535. It's a signed/unsigned issue:
      
      'Iif', the source interface, is retrieved from member mfc_parent in
      struct mfc_cache. mfc_parent is a vifi_t: unsigned short, but is
      displayed in ipmr_mfc_seq_show() as "%-3d", signed integer.
      
      In unresolevd entries, the 65535 value (0xFFFF) comes from this define:
      #define ALL_VIFS    ((vifi_t)(-1))
      
      That may explains why the guy who added support for this in iproute2
      thought a -1 should be expected.
      
      I don't know if this must be fixed in kernel or in iproute2. Who is
      right? What is the correct API? How was it designed originally?
      
      I let you decide if it should goes in the kernel or be fixed in iproute2.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      999890b2
    • B
      net: fix /proc/net/ip_mr_cache display - V2 · 1ea472e2
      Benjamin Thery 提交于
      /proc/net/ip_mr_cache and /proc/net/ip6_mr_cache displays garbage when
      showing unresolved mfc_cache entries.
      
      [root@qemu tests]# cat /proc/net/ip_mr_cache
      Group    Origin   Iif     Pkts    Bytes    Wrong Oifs
      014C00EF 010014AC 1         10    10050        0  2:1    3:1
      024C00EF 010014AC 65535      514        2 -559067475
      
      The first line is correct. It is a resolved cache entry, 10 packets used it...
      The second line represents an unresolved entry, and the columns Pkts(4th),
      Bytes(5th) and Wrong(6th) just show garbage.
      
      In struct mfc_cache, there's an union to store data for resolved and
      unresolved cases. And what ipmr_mfc_seq_show() is printing in these 
      columns for the unresolved entries is some bytes from mfc_cache.mfc_un.res.
      Bad.
      (eg. In our case -559067475 is in fact 0xdead4ead which is the spinlock
      magic from mfc_cache.mfc_un.unres.unresolved.lock.magic).
      
      This patch replaces the garbage data written in these columns for the
      unresolved entries by '0' (zeros) which is more correct.
      This change doesn't break the ABI.
      
      Also, mfc->mfc_un.res.pkt, mfc->mfc_un.res.bytes, mfc->mfc_un.res.wrong_if
      are unsigned long.
      
      It applies on top of net-next-2.6.
      
      The patch for net-2.6 is slightly different because of the NIP6_FMT to
      %pI6 conversion that was made in the seq_printf.
      
      Changelog:
      ==========
      V2:
      * Instead of breaking the ABI by suppressing the columns that have no
        meaning for unresolved entries, fill them with 0 values.
      Signed-off-by: NBenjamin Thery <benjamin.thery@bull.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1ea472e2
  6. 26 11月, 2008 11 次提交
  7. 25 11月, 2008 3 次提交
  8. 24 11月, 2008 2 次提交
    • A
      net: fix tunnels in netns after ndo_ changes · be77e593
      Alexey Dobriyan 提交于
      dev_net_set() should be the very first thing after alloc_netdev().
      
      "ndo_" changes turned simple assignment (which is OK to do before netns
      assignment) into quite non-trivial operation (which is not OK, init_net was
      used). This leads to incomplete initialisation of tunnel device in netns.
      
      BUG: unable to handle kernel NULL pointer dereference at 00000004
      IP: [<c02efdb5>] ip6_tnl_exit_net+0x37/0x4f
      *pde = 00000000 
      Oops: 0000 [#1] PREEMPT DEBUG_PAGEALLOC
      last sysfs file: /sys/class/net/lo/operstate
      
      Pid: 10, comm: netns Not tainted (2.6.28-rc6 #1) 
      EIP: 0060:[<c02efdb5>] EFLAGS: 00010246 CPU: 0
      EIP is at ip6_tnl_exit_net+0x37/0x4f
      EAX: 00000000 EBX: 00000020 ECX: 00000000 EDX: 00000003
      ESI: c5caef30 EDI: c782bbe8 EBP: c7909f50 ESP: c7909f48
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      Process netns (pid: 10, ti=c7908000 task=c7905780 task.ti=c7908000)
      Stack:
       c03e75e0 c7390bc8 c7909f60 c0245448 c7390bd8 c7390bf0 c7909fa8 c012577a
       00000000 00000002 00000000 c0125736 c782bbe8 c7909f90 c0308fe3 c782bc04
       c7390bd4 c0245406 c084b718 c04f0770 c03ad785 c782bbe8 c782bc04 c782bc0c
      Call Trace:
       [<c0245448>] ? cleanup_net+0x42/0x82
       [<c012577a>] ? run_workqueue+0xd6/0x1ae
       [<c0125736>] ? run_workqueue+0x92/0x1ae
       [<c0308fe3>] ? schedule+0x275/0x285
       [<c0245406>] ? cleanup_net+0x0/0x82
       [<c0125ae1>] ? worker_thread+0x81/0x8d
       [<c0128344>] ? autoremove_wake_function+0x0/0x33
       [<c0125a60>] ? worker_thread+0x0/0x8d
       [<c012815c>] ? kthread+0x39/0x5e
       [<c0128123>] ? kthread+0x0/0x5e
       [<c0103b9f>] ? kernel_thread_helper+0x7/0x10
      Code: db e8 05 ff ff ff 89 c6 e8 dc 04 f6 ff eb 08 8b 40 04 e8 38 89 f5 ff 8b 44 9e 04 85 c0 75 f0 43 83 fb 20 75 f2 8b 86 84 00 00 00 <8b> 40 04 e8 1c 89 f5 ff e8 98 04 f6 ff 89 f0 e8 f8 63 e6 ff 5b 
      EIP: [<c02efdb5>] ip6_tnl_exit_net+0x37/0x4f SS:ESP 0068:c7909f48
      ---[ end trace 6c2f2328fccd3e0c ]---
      Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be77e593
    • E
      net: Convert TCP/DCCP listening hash tables to use RCU · c25eb3bf
      Eric Dumazet 提交于
      This is the last step to be able to perform full RCU lookups
      in __inet_lookup() : After established/timewait tables, we
      add RCU lookups to listening hash table.
      
      The only trick here is that a socket of a given type (TCP ipv4,
      TCP ipv6, ...) can now flight between two different tables
      (established and listening) during a RCU grace period, so we
      must use different 'nulls' end-of-chain values for two tables.
      
      We define a large value :
      
      #define LISTENING_NULLS_BASE (1U << 29)
      
      So that slots in listening table are guaranteed to have different
      end-of-chain values than slots in established table. A reader can
      still detect it finished its lookup in the right chain.
      Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c25eb3bf
  9. 22 11月, 2008 1 次提交
  10. 21 11月, 2008 3 次提交
  11. 20 11月, 2008 1 次提交