1. 10 Jul, 2013 1 commit
  2. 02 Jul, 2013 1 commit
    • Hannes Frederic Sowa's avatar
      ipv6: call udp_push_pending_frames when uncorking a socket with AF_INET pending data · 8822b64a
      Hannes Frederic Sowa authored
      We accidentally call down to ip6_push_pending_frames when uncorking
      pending AF_INET data on a ipv6 socket. This results in the following
      splat (from Dave Jones):
      skbuff: skb_under_panic: text:ffffffff816765f6 len:48 put:40 head:ffff88013deb6df0 data:ffff88013deb6dec tail:0x2c end:0xc0 dev:<NULL>
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:126!
      invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      Modules linked in: dccp_ipv4 dccp 8021q garp bridge stp dlci mpoa snd_seq_dummy sctp fuse hidp tun bnep nfnetlink scsi_transport_iscsi rfcomm can_raw can_bcm af_802154 appletalk caif_socket can caif ipt_ULOG x25 rose af_key pppoe pppox ipx phonet irda llc2 ppp_generic slhc p8023 psnap p8022 llc crc_ccitt atm bluetooth
      +netrom ax25 nfc rfkill rds af_rxrpc coretemp hwmon kvm_intel kvm crc32c_intel snd_hda_codec_realtek ghash_clmulni_intel microcode pcspkr snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep usb_debug snd_seq snd_seq_device snd_pcm e1000e snd_page_alloc snd_timer ptp snd pps_core soundcore xfs libcrc32c
      CPU: 2 PID: 8095 Comm: trinity-child2 Not tainted 3.10.0-rc7+ #37
      task: ffff8801f52c2520 ti: ffff8801e6430000 task.ti: ffff8801e6430000
      RIP: 0010:[<ffffffff816e759c>]  [<ffffffff816e759c>] skb_panic+0x63/0x65
      RSP: 0018:ffff8801e6431de8  EFLAGS: 00010282
      RAX: 0000000000000086 RBX: ffff8802353d3cc0 RCX: 0000000000000006
      RDX: 0000000000003b90 RSI: ffff8801f52c2ca0 RDI: ffff8801f52c2520
      RBP: ffff8801e6431e08 R08: 0000000000000000 R09: 0000000000000000
      R10: 0000000000000001 R11: 0000000000000001 R12: ffff88022ea0c800
      R13: ffff88022ea0cdf8 R14: ffff8802353ecb40 R15: ffffffff81cc7800
      FS:  00007f5720a10740(0000) GS:ffff880244c00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000000005862000 CR3: 000000022843c000 CR4: 00000000001407e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
       ffff88013deb6dec 000000000000002c 00000000000000c0 ffffffff81a3f6e4
       ffff8801e6431e18 ffffffff8159a9aa ffff8801e6431e90 ffffffff816765f6
       ffffffff810b756b 0000000700000002 ffff8801e6431e40 0000fea9292aa8c0
      Call Trace:
       [<ffffffff8159a9aa>] skb_push+0x3a/0x40
       [<ffffffff816765f6>] ip6_push_pending_frames+0x1f6/0x4d0
       [<ffffffff810b756b>] ? mark_held_locks+0xbb/0x140
       [<ffffffff81694919>] udp_v6_push_pending_frames+0x2b9/0x3d0
       [<ffffffff81694660>] ? udplite_getfrag+0x20/0x20
       [<ffffffff8162092a>] udp_lib_setsockopt+0x1aa/0x1f0
       [<ffffffff811cc5e7>] ? fget_light+0x387/0x4f0
       [<ffffffff816958a4>] udpv6_setsockopt+0x34/0x40
       [<ffffffff815949f4>] sock_common_setsockopt+0x14/0x20
       [<ffffffff81593c31>] SyS_setsockopt+0x71/0xd0
       [<ffffffff816f5d54>] tracesys+0xdd/0xe2
      Code: 00 00 48 89 44 24 10 8b 87 d8 00 00 00 48 89 44 24 08 48 8b 87 e8 00 00 00 48 c7 c7 c0 04 aa 81 48 89 04 24 31 c0 e8 e1 7e ff ff <0f> 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55
      RIP  [<ffffffff816e759c>] skb_panic+0x63/0x65
       RSP <ffff8801e6431de8>
      This patch adds a check if the pending data is of address family AF_INET
      and directly calls udp_push_ending_frames from udp_v6_push_pending_frames
      if that is the case.
      This bug was found by Dave Jones with trinity.
      (Also move the initialization of fl6 below the AF_INET check, even if
      not strictly necessary.)
      Cc: Dave Jones <davej@redhat.com>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  3. 10 Jun, 2013 1 commit
  4. 04 Jun, 2013 1 commit
    • Lorenzo Colitti's avatar
      net: ipv6: Unify {raw,udp}6_sock_seq_show. · 17ef66af
      Lorenzo Colitti authored
      udp6_sock_seq_show and raw6_sock_seq_show are identical, except
      the UDP version displays ports and the raw version displays the
      protocol. Refactor most of the code in these two functions into
      a new common ip6_dgram_sock_seq_show function, in preparation
      for using it to display ICMPv6 sockets as well.
      Also reduce the indentation in parts of include/net/transp_v6.h
      to improve readability.
      Compiles and displays reasonable results with CONFIG_IPV6={n,m,y}
      Signed-off-by: default avatarLorenzo Colitti <lorenzo@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  5. 11 May, 2013 1 commit
    • Eric Dumazet's avatar
      ipv6: do not clear pinet6 field · f77d6021
      Eric Dumazet authored
      We have seen multiple NULL dereferences in __inet6_lookup_established()
      After analysis, I found that inet6_sk() could be NULL while the
      check for sk_family == AF_INET6 was true.
      Bug was added in linux-2.6.29 when RCU lookups were introduced in UDP
      and TCP stacks.
      Once an IPv6 socket, using SLAB_DESTROY_BY_RCU is inserted in a hash
      table, we no longer can clear pinet6 field.
      This patch extends logic used in commit fcbdf09d
      ("net: fix nulls list corruptions in sk_prot_alloc")
      TCP/UDP/UDPLite IPv6 protocols provide their own .clear_sk() method
      to make sure we do not clear pinet6 field.
      At socket clone phase, we do not really care, as cloning the parent (non
      NULL) pinet6 is not adding a fatal race.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  6. 29 Apr, 2013 1 commit
  7. 20 Mar, 2013 1 commit
    • Tom Parkin's avatar
      udp: add encap_destroy callback · 44046a59
      Tom Parkin authored
      Users of udp encapsulation currently have an encap_rcv callback which they can
      use to hook into the udp receive path.
      In situations where a encapsulation user allocates resources associated with a
      udp encap socket, it may be convenient to be able to also hook the proto
      .destroy operation.  For example, if an encap user holds a reference to the
      udp socket, the destroy hook might be used to relinquish this reference.
      This patch adds a socket destroy hook into udp, which is set and enabled
      in the same way as the existing encap_rcv hook.
      Signed-off-by: default avatarTom Parkin <tparkin@katalix.com>
      Signed-off-by: default avatarJames Chapman <jchapman@katalix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  8. 08 Mar, 2013 1 commit
  9. 31 Jan, 2013 1 commit
  10. 23 Jan, 2013 1 commit
    • Tom Herbert's avatar
      soreuseport: UDP/IPv6 implementation · 72289b96
      Tom Herbert authored
      Motivation for soreuseport would be something like a DNS server.  An
      alternative would be to recv on the same socket from multiple threads.
      As in the case of TCP, the load across these threads tends to be
      disproportionate and we also see a lot of contection on the socket lock.
      Note that SO_REUSEADDR already allows multiple UDP sockets to bind to
      the same port, however there is no provision to prevent hijacking and
      nothing to distribute packets across all the sockets sharing the same
      bound port.  This patch does not change the semantics of SO_REUSEADDR,
      but provides usable functionality of it for unicast.
      Signed-off-by: default avatarTom Herbert <therbert@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  11. 08 Jan, 2013 1 commit
  12. 15 Nov, 2012 4 commits
  13. 07 Sep, 2012 1 commit
  14. 14 Aug, 2012 1 commit
  15. 12 Jul, 2012 1 commit
  16. 27 Jun, 2012 1 commit
  17. 15 Jun, 2012 1 commit
    • David S. Miller's avatar
      ipv6: Handle PMTU in ICMP error handlers. · 81aded24
      David S. Miller authored
      One tricky issue on the ipv6 side vs. ipv4 is that the ICMP callouts
      to handle the error pass the 32-bit info cookie in network byte order
      whereas ipv4 passes it around in host byte order.
      Like the ipv4 side, we have two helper functions.  One for when we
      have a socket context and one for when we do not.
      ip6ip6 tunnels are not handled here, because they handle PMTU events
      by essentially relaying another ICMP packet-too-big message back to
      the original sender.
      This patch allows us to get rid of rt6_do_pmtu_disc().  It handles all
      kinds of situations that simply cannot happen when we do the PMTU
      update directly using a fully resolved route.
      In fact, the "plen == 128" check in ip6_rt_update_pmtu() can very
      likely be removed or changed into a BUG_ON() check.  We should never
      have a prefixed ipv6 route when we get there.
      Another piece of strange history here is that TCP and DCCP, unlike in
      ipv4, never invoke the update_pmtu() method from their ICMP error
      handlers.  This is incredibly astonishing since this is the context
      where we have the most accurate context in which to make a PMTU
      update, namely we have a fully connected socket and associated cached
      socket route.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  18. 19 May, 2012 2 commits
  19. 28 Apr, 2012 3 commits
  20. 23 Apr, 2012 1 commit
    • Eric Dumazet's avatar
      net: add a limit parameter to sk_add_backlog() · f545a38f
      Eric Dumazet authored
      sk_add_backlog() & sk_rcvqueues_full() hard coded sk_rcvbuf as the
      memory limit. We need to make this limit a parameter for TCP use.
      No functional change expected in this patch, all callers still using the
      old sk_rcvbuf limit.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Cc: Rick Jones <rick.jones2@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  21. 21 Feb, 2012 1 commit
  22. 08 Feb, 2012 1 commit
  23. 09 Dec, 2011 1 commit
  24. 01 Dec, 2011 1 commit
  25. 22 Nov, 2011 1 commit
  26. 16 Nov, 2011 1 commit
  27. 09 Nov, 2011 1 commit
    • Eric Dumazet's avatar
      ipv4: PKTINFO doesnt need dst reference · d826eb14
      Eric Dumazet authored
      Le lundi 07 novembre 2011 à 15:33 +0100, Eric Dumazet a écrit :
      > At least, in recent kernels we dont change dst->refcnt in forwarding
      > patch (usinf NOREF skb->dst)
      > One particular point is the atomic_inc(dst->refcnt) we have to perform
      > when queuing an UDP packet if socket asked PKTINFO stuff (for example a
      > typical DNS server has to setup this option)
      > I have one patch somewhere that stores the information in skb->cb[] and
      > avoid the atomic_{inc|dec}(dst->refcnt).
      OK I found it, I did some extra tests and believe its ready.
      [PATCH net-next] ipv4: IP_PKTINFO doesnt need dst reference
      When a socket uses IP_PKTINFO notifications, we currently force a dst
      reference for each received skb. Reader has to access dst to get needed
      information (rt_iif & rt_spec_dst) and must release dst reference.
      We also forced a dst reference if skb was put in socket backlog, even
      without IP_PKTINFO handling. This happens under stress/load.
      We can instead store the needed information in skb->cb[], so that only
      softirq handler really access dst, improving cache hit ratios.
      This removes two atomic operations per packet, and false sharing as
      On a benchmark using a mono threaded receiver (doing only recvmsg()
      calls), I can reach 720.000 pps instead of 570.000 pps.
      IP_PKTINFO is typically used by DNS servers, and any multihomed aware
      UDP application.
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  28. 01 Nov, 2011 1 commit
  29. 30 Aug, 2011 1 commit
  30. 17 Aug, 2011 1 commit
  31. 12 Aug, 2011 1 commit
  32. 21 Jul, 2011 1 commit
  33. 21 Jun, 2011 2 commits
    • Xufeng Zhang's avatar
      udp/recvmsg: Clear MSG_TRUNC flag when starting over for a new packet · 9cfaa8de
      Xufeng Zhang authored
      Consider this scenario: When the size of the first received udp packet
      is bigger than the receive buffer, MSG_TRUNC bit is set in msg->msg_flags.
      However, if checksum error happens and this is a blocking socket, it will
      goto try_again loop to receive the next packet.  But if the size of the
      next udp packet is smaller than receive buffer, MSG_TRUNC flag should not
      be set, but because MSG_TRUNC bit is not cleared in msg->msg_flags before
      receive the next packet, MSG_TRUNC is still set, which is wrong.
      Fix this problem by clearing MSG_TRUNC flag when starting over for a
      new packet.
      Signed-off-by: default avatarXufeng Zhang <xufeng.zhang@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    • Xufeng Zhang's avatar
      ipv6/udp: Use the correct variable to determine non-blocking condition · 32c90254
      Xufeng Zhang authored
      udpv6_recvmsg() function is not using the correct variable to determine
      whether or not the socket is in non-blocking operation, this will lead
      to unexpected behavior when a UDP checksum error occurs.
      Consider a non-blocking udp receive scenario: when udpv6_recvmsg() is
      called by sock_common_recvmsg(), MSG_DONTWAIT bit of flags variable in
      udpv6_recvmsg() is cleared by "flags & ~MSG_DONTWAIT" in this call:
          err = sk->sk_prot->recvmsg(iocb, sk, msg, size, flags & MSG_DONTWAIT,
                         flags & ~MSG_DONTWAIT, &addr_len);
      i.e. with udpv6_recvmsg() getting these values:
      	int noblock = flags & MSG_DONTWAIT
      	int flags = flags & ~MSG_DONTWAIT
      So, when udp checksum error occurs, the execution will go to
      csum_copy_err, and then the problem happens:
                  if (flags & MSG_DONTWAIT)
                          return -EAGAIN;
                  goto try_again;
      But it will always go to try_again as MSG_DONTWAIT has been cleared
      from flags at call time -- only noblock contains the original value
      of MSG_DONTWAIT, so the test should be:
                  if (noblock)
                          return -EAGAIN;
      This is also consistent with what the ipv4/udp code does.
      Signed-off-by: default avatarXufeng Zhang <xufeng.zhang@windriver.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>