1. 23 8月, 2008 1 次提交
    • D
      icmp: icmp_sk() should not use smp_processor_id() in preemptible code · fdc0bde9
      Denis V. Lunev 提交于
      Pass namespace into icmp_xmit_lock, obtain socket inside and return
      it as a result for caller.
      
      Thanks Alexey Dobryan for this report:
      
      Steps to reproduce:
      
      	CONFIG_PREEMPT=y
      	CONFIG_DEBUG_PREEMPT=y
      	tracepath <something>
      
      BUG: using smp_processor_id() in preemptible [00000000] code: tracepath/3205
      caller is icmp_sk+0x15/0x30
      Pid: 3205, comm: tracepath Not tainted 2.6.27-rc4 #1
      
      Call Trace:
       [<ffffffff8031af14>] debug_smp_processor_id+0xe4/0xf0
       [<ffffffff80409405>] icmp_sk+0x15/0x30
       [<ffffffff8040a17b>] icmp_send+0x4b/0x3f0
       [<ffffffff8025a415>] ? trace_hardirqs_on_caller+0xd5/0x160
       [<ffffffff8025a4ad>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8023a475>] ? local_bh_enable_ip+0x95/0x110
       [<ffffffff804285b9>] ? _spin_unlock_bh+0x39/0x40
       [<ffffffff8025a26c>] ? mark_held_locks+0x4c/0x90
       [<ffffffff8025a4ad>] ? trace_hardirqs_on+0xd/0x10
       [<ffffffff8025a415>] ? trace_hardirqs_on_caller+0xd5/0x160
       [<ffffffff803e91b4>] ip_fragment+0x8d4/0x900
       [<ffffffff803e7030>] ? ip_finish_output2+0x0/0x290
       [<ffffffff803e91e0>] ? ip_finish_output+0x0/0x60
       [<ffffffff803e6650>] ? dst_output+0x0/0x10
       [<ffffffff803e922c>] ip_finish_output+0x4c/0x60
       [<ffffffff803e92e3>] ip_output+0xa3/0xf0
       [<ffffffff803e68d0>] ip_local_out+0x20/0x30
       [<ffffffff803e753f>] ip_push_pending_frames+0x27f/0x400
       [<ffffffff80406313>] udp_push_pending_frames+0x233/0x3d0
       [<ffffffff804067d1>] udp_sendmsg+0x321/0x6f0
       [<ffffffff8040d155>] inet_sendmsg+0x45/0x80
       [<ffffffff803b967f>] sock_sendmsg+0xdf/0x110
       [<ffffffff8024a100>] ? autoremove_wake_function+0x0/0x40
       [<ffffffff80257ce5>] ? validate_chain+0x415/0x1010
       [<ffffffff8027dc10>] ? __do_fault+0x140/0x450
       [<ffffffff802597d0>] ? __lock_acquire+0x260/0x590
       [<ffffffff803b9e55>] ? sockfd_lookup_light+0x45/0x80
       [<ffffffff803ba50a>] sys_sendto+0xea/0x120
       [<ffffffff80428e42>] ? _spin_unlock_irqrestore+0x42/0x80
       [<ffffffff803134bc>] ? __up_read+0x4c/0xb0
       [<ffffffff8024e0c6>] ? up_read+0x26/0x30
       [<ffffffff8020b8bb>] system_call_fastpath+0x16/0x1b
      
      icmp6_sk() is similar.
      Signed-off-by: NDenis V. Lunev <den@openvz.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fdc0bde9
  2. 02 7月, 2008 1 次提交
  3. 12 6月, 2008 1 次提交
  4. 04 4月, 2008 2 次提交
  5. 02 4月, 2008 1 次提交
  6. 26 3月, 2008 2 次提交
  7. 25 3月, 2008 1 次提交
  8. 06 3月, 2008 2 次提交
  9. 04 3月, 2008 3 次提交
  10. 01 3月, 2008 6 次提交
  11. 05 2月, 2008 1 次提交
  12. 29 1月, 2008 7 次提交
  13. 21 1月, 2008 1 次提交
  14. 16 10月, 2007 1 次提交
  15. 11 10月, 2007 1 次提交
    • D
      [IPV6]: Add ICMPMsgStats MIB (RFC 4293) [rev 2] · 14878f75
      David L Stevens 提交于
      Background: RFC 4293 deprecates existing individual, named ICMP
      type counters to be replaced with the ICMPMsgStatsTable. This table
      includes entries for both IPv4 and IPv6, and requires counting of all
      ICMP types, whether or not the machine implements the type.
      
      These patches "remove" (but not really) the existing counters, and
      replace them with the ICMPMsgStats tables for v4 and v6.
      It includes the named counters in the /proc places they were, but gets the
      values for them from the new tables. It also counts packets generated
      from raw socket output (e.g., OutEchoes, MLD queries, RA's from
      radvd, etc).
      
      Changes:
      1) create icmpmsg_statistics mib
      2) create icmpv6msg_statistics mib
      3) modify existing counters to use these
      4) modify /proc/net/snmp to add "IcmpMsg" with all ICMP types
              listed by number for easy SNMP parsing
      5) modify /proc/net/snmp printing for "Icmp" to get the named data
              from new counters.
      [new to 2nd revision]
      6) support per-interface ICMP stats
      7) use common macro for per-device stat macros
      Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14878f75
  16. 15 7月, 2007 1 次提交
    • D
      [IPV6]: MSG_ERRQUEUE messages do not pass to connected raw sockets · f13ec93f
      Dmitry Butskoy 提交于
      From: Dmitry Butskoy <dmitry@butskoy.name>
      
      Taken from http://bugzilla.kernel.org/show_bug.cgi?id=8747
      
      Problem Description:
      
      It is related to the possibility to obtain MSG_ERRQUEUE messages from the udp
      and raw sockets, both connected and unconnected.
      
      There is a little typo in net/ipv6/icmp.c code, which prevents such messages
      to be delivered to the errqueue of the correspond raw socket, when the socket
      is CONNECTED.  The typo is due to swap of local/remote addresses.
      
      Consider __raw_v6_lookup() function from net/ipv6/raw.c. When a raw socket is
      looked up usual way, it is something like:
      
      sk = __raw_v6_lookup(sk, nexthdr, daddr, saddr, IP6CB(skb)->iif);
      
      where "daddr" is a destination address of the incoming packet (IOW our local
      address), "saddr" is a source address of the incoming packet (the remote end).
      
      But when the raw socket is looked up for some icmp error report, in
      net/ipv6/icmp.c:icmpv6_notify() , daddr/saddr are obtained from the echoed
      fragment of the "bad" packet, i.e.  "daddr" is the original destination
      address of that packet, "saddr" is our local address.  Hence, for
      icmpv6_notify() must use "saddr, daddr" in its arguments, not "daddr, saddr"
      ...
      
      Steps to reproduce:
      
      Create some raw socket, connect it to an address, and cause some error
      situation: f.e. set ttl=1 where the remote address is more than 1 hop to reach.
      Set IPV6_RECVERR .
      Then send something and wait for the error (f.e. poll() with POLLERR|POLLIN).
      You should receive "time exceeded" icmp message (because of "ttl=1"), but the
      socket do not receive it.
      
      If you do not connect your raw socket, you will receive MSG_ERRQUEUE
      successfully.  (The reason is that for unconnected socket there are no actual
      checks for local/remote addresses).
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f13ec93f
  17. 11 7月, 2007 1 次提交
    • M
      [IPV6] MIP6: Loadable module support for MIPv6. · 59fbb3a6
      Masahide NAKAMURA 提交于
      This patch makes MIPv6 loadable module named "mip6".
      
      Here is a modprobe.conf(5) example to load it automatically
      when user application uses XFRM state for MIPv6:
      
      alias xfrm-type-10-43 mip6
      alias xfrm-type-10-60 mip6
      
      Some MIPv6 feature is not included by this modular, however,
      it should not be affected to other features like either IPsec
      or IPv6 with and without the patch.
      We may discuss XFRM, MH (RAW socket) and ancillary data/sockopt
      separately for future work.
      
      Loadable features:
      * MH receiving check (to send ICMP error back)
      * RO header parsing and building (i.e. RH2 and HAO in DSTOPTS)
      * XFRM policy/state database handling for RO
      
      These are NOT covered as loadable:
      * Home Address flags and its rule on source address selection
      * XFRM sub policy (depends on its own kernel option)
      * XFRM functions to receive RO as IPv6 extension header
      * MH sending/receiving through raw socket if user application
        opens it (since raw socket allows to do so)
      * RH2 sending as ancillary data
      * RH2 operation with setsockopt(2)
      Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59fbb3a6
  18. 26 4月, 2007 7 次提交