1. 18 8月, 2011 2 次提交
  2. 13 8月, 2011 5 次提交
  3. 12 8月, 2011 2 次提交
    • E
      net: cleanup some rcu_dereference_raw · 33d480ce
      Eric Dumazet 提交于
      RCU api had been completed and rcu_access_pointer() or
      rcu_dereference_protected() are better than generic
      rcu_dereference_raw()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      33d480ce
    • E
      neigh: reduce arp latency · cd28ca0a
      Eric Dumazet 提交于
      Remove the artificial HZ latency on arp resolution.
      
      Instead of firing a timer in one jiffy (up to 10 ms if HZ=100), lets
      send the ARP message immediately.
      
      Before patch :
      
      # arp -d 192.168.20.108 ; ping -c 3 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
      64 bytes from 192.168.20.108: icmp_seq=1 ttl=64 time=9.91 ms
      64 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.065 ms
      64 bytes from 192.168.20.108: icmp_seq=3 ttl=64 time=0.061 ms
      
      After patch :
      
      $ arp -d 192.168.20.108 ; ping -c 3 192.168.20.108
      PING 192.168.20.108 (192.168.20.108) 56(84) bytes of data.
      64 bytes from 192.168.20.108: icmp_seq=1 ttl=64 time=0.152 ms
      64 bytes from 192.168.20.108: icmp_seq=2 ttl=64 time=0.064 ms
      64 bytes from 192.168.20.108: icmp_seq=3 ttl=64 time=0.074 ms
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cd28ca0a
  4. 11 8月, 2011 1 次提交
  5. 10 8月, 2011 1 次提交
  6. 08 8月, 2011 6 次提交
  7. 07 8月, 2011 1 次提交
    • D
      net: Compute protocol sequence numbers and fragment IDs using MD5. · 6e5714ea
      David S. Miller 提交于
      Computers have become a lot faster since we compromised on the
      partial MD4 hash which we use currently for performance reasons.
      
      MD5 is a much safer choice, and is inline with both RFC1948 and
      other ISS generators (OpenBSD, Solaris, etc.)
      
      Furthermore, only having 24-bits of the sequence number be truly
      unpredictable is a very serious limitation.  So the periodic
      regeneration and 8-bit counter have been removed.  We compute and
      use a full 32-bit sequence number.
      
      For ipv6, DCCP was found to use a 32-bit truncated initial sequence
      number (it needs 43-bits) and that is fixed here as well.
      Reported-by: NDan Kaminsky <dan@doxpara.com>
      Tested-by: NWilly Tarreau <w@1wt.eu>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6e5714ea
  8. 05 8月, 2011 4 次提交
    • M
      ipv6: check for IPv4 mapped addresses when connecting IPv6 sockets · c15fea2d
      Max Matveev 提交于
      When support for binding to 'mapped INADDR_ANY (::ffff.0.0.0.0)' was added
      in 0f8d3c7a the rest of the code
      wasn't told so now it's possible to bind IPv6 datagram socket to
      ::ffff.0.0.0.0, connect it to another IPv4 address and it will all
      work except for getsockhame() which does not return the local address
      as expected.
      
      To give getsockname() something to work with check for 'mapped INADDR_ANY'
      when connecting and update the in-core source addresses appropriately.
      Signed-off-by: NMax Matveev <makc@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c15fea2d
    • T
      net: Fix security_socket_sendmsg() bypass problem. · c71d8ebe
      Tetsuo Handa 提交于
      The sendmmsg() introduced by commit 228e548e "net: Add sendmmsg socket system
      call" is capable of sending to multiple different destination addresses.
      
      SMACK is using destination's address for checking sendmsg() permission.
      However, security_socket_sendmsg() is called for only once even if multiple
      different destination addresses are passed to sendmmsg().
      
      Therefore, we need to call security_socket_sendmsg() for each destination
      address rather than only the first destination address.
      
      Since calling security_socket_sendmsg() every time when only single destination
      address was passed to sendmmsg() is a waste of time, omit calling
      security_socket_sendmsg() unless destination address of previous datagram and
      that of current datagram differs.
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: NAnton Blanchard <anton@samba.org>
      Cc: stable <stable@kernel.org> [3.0+]
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c71d8ebe
    • A
      net: Cap number of elements for sendmmsg · 98382f41
      Anton Blanchard 提交于
      To limit the amount of time we can spend in sendmmsg, cap the
      number of elements to UIO_MAXIOV (currently 1024).
      
      For error handling an application using sendmmsg needs to retry at
      the first unsent message, so capping is simpler and requires less
      application logic than returning EINVAL.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: stable <stable@kernel.org> [3.0+]
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98382f41
    • A
      net: sendmmsg should only return an error if no messages were sent · 728ffb86
      Anton Blanchard 提交于
      sendmmsg uses a similar error return strategy as recvmmsg but it
      turns out to be a confusing way to communicate errors.
      
      The current code stores the error code away and returns it on the next
      sendmmsg call. This means a call with completely valid arguments could
      get an error from a previous call.
      
      Change things so we only return an error if no datagrams could be sent.
      If less than the requested number of messages were sent, the application
      must retry starting at the first failed one and if the problem is
      persistent the error will be returned.
      
      This matches the behaviour of other syscalls like read/write - it
      is not an error if less than the requested number of elements are sent.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Cc: stable <stable@kernel.org> [3.0+]
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      728ffb86
  9. 03 8月, 2011 1 次提交
  10. 02 8月, 2011 6 次提交
  11. 01 8月, 2011 11 次提交