1. 19 2月, 2013 4 次提交
  2. 16 2月, 2013 3 次提交
  3. 15 2月, 2013 1 次提交
  4. 14 2月, 2013 6 次提交
  5. 13 2月, 2013 1 次提交
    • E
      net: fix infinite loop in __skb_recv_datagram() · 77c1090f
      Eric Dumazet 提交于
      Tommi was fuzzing with trinity and reported the following problem :
      
      commit 3f518bf7 (datagram: Add offset argument to __skb_recv_datagram)
      missed that a raw socket receive queue can contain skbs with no payload.
      
      We can loop in __skb_recv_datagram() with MSG_PEEK mode, because
      wait_for_packet() is not prepared to skip these skbs.
      
      [   83.541011] INFO: rcu_sched detected stalls on CPUs/tasks: {}
      (detected by 0, t=26002 jiffies, g=27673, c=27672, q=75)
      [   83.541011] INFO: Stall ended before state dump start
      [  108.067010] BUG: soft lockup - CPU#0 stuck for 22s! [trinity-child31:2847]
      ...
      [  108.067010] Call Trace:
      [  108.067010]  [<ffffffff818cc103>] __skb_recv_datagram+0x1a3/0x3b0
      [  108.067010]  [<ffffffff818cc33d>] skb_recv_datagram+0x2d/0x30
      [  108.067010]  [<ffffffff819ed43d>] rawv6_recvmsg+0xad/0x240
      [  108.067010]  [<ffffffff818c4b04>] sock_common_recvmsg+0x34/0x50
      [  108.067010]  [<ffffffff818bc8ec>] sock_recvmsg+0xbc/0xf0
      [  108.067010]  [<ffffffff818bf31e>] sys_recvfrom+0xde/0x150
      [  108.067010]  [<ffffffff81ca4329>] system_call_fastpath+0x16/0x1b
      Reported-by: NTommi Rantala <tt.rantala@gmail.com>
      Tested-by: NTommi Rantala <tt.rantala@gmail.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Acked-by: NPavel Emelyanov <xemul@parallels.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      77c1090f
  6. 12 2月, 2013 3 次提交
    • N
      netpoll: cleanup sparse warnings · 0790bbb6
      Neil Horman 提交于
      With my recent commit I introduced two sparse warnings.  Looking closer there
      were a few more in the same file, so I fixed them all up.  Basic rcu pointer
      dereferencing suff.
      
      I've validated these changes using CONFIG_PROVE_RCU while starting and stopping
      netconsole repeatedly in bonded and non-bonded configurations
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: fengguang.wu@intel.com
      CC: David Miller <davem@davemloft.net>
      CC: eric.dumazet@gmail.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0790bbb6
    • N
      netpoll: Fix __netpoll_rcu_free so that it can hold the rtnl lock · 2cde6acd
      Neil Horman 提交于
      __netpoll_rcu_free is used to free netpoll structures when the rtnl_lock is
      already held.  The mechanism is used to asynchronously call __netpoll_cleanup
      outside of the holding of the rtnl_lock, so as to avoid deadlock.
      Unfortunately, __netpoll_cleanup modifies pointers (dev->np), which means the
      rtnl_lock must be held while calling it.  Further, it cannot be held, because
      rcu callbacks may be issued in softirq contexts, which cannot sleep.
      
      Fix this by converting the rcu callback to a work queue that is guaranteed to
      get scheduled in process context, so that we can hold the rtnl properly while
      calling __netpoll_cleanup
      
      Tested successfully by myself.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Cong Wang <amwang@redhat.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2cde6acd
    • J
      skbuff: create skb_panic() function and its wrappers · f05de73b
      Jean Sacren 提交于
      Create skb_panic() function in lieu of both skb_over_panic() and
      skb_under_panic() so that code duplication would be avoided. Update type
      and variable name where necessary.
      
      Jiri Pirko suggested using wrappers so that we would be able to keep the
      fruits of the original code.
      Signed-off-by: NJean Sacren <sakiwit@gmail.com>
      Cc: Jiri Pirko <jiri@resnulli.us>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f05de73b
  7. 09 2月, 2013 1 次提交
  8. 07 2月, 2013 4 次提交
    • E
      net: reset mac header in dev_start_xmit() · 6d1ccff6
      Eric Dumazet 提交于
      On 64 bit arches :
      
      There is a off-by-one error in qdisc_pkt_len_init() because
      mac_header is not set in xmit path.
      
      skb_mac_header() returns an out of bound value that was
      harmless because hdr_len is an 'unsigned int'
      
      On 32bit arches, the error is abysmal.
      
      This patch is also a prereq for "macvlan: add multicast filter"
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Ben Greear <greearb@candelatech.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d1ccff6
    • C
      net: adjust skb_gso_segment() for calling in rx path · 12b0004d
      Cong Wang 提交于
      skb_gso_segment() is almost always called in tx path,
      except for openvswitch. It calls this function when
      it receives the packet and tries to queue it to user-space.
      In this special case, the ->ip_summed check inside
      skb_gso_segment() is no longer true, as ->ip_summed value
      has different meanings on rx path.
      
      This patch adjusts skb_gso_segment() so that we can at least
      avoid such warnings on checksum.
      
      Cc: Jesse Gross <jesse@nicira.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: NCong Wang <amwang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      12b0004d
    • N
      netpoll: protect napi_poll and poll_controller during dev_[open|close] · ca99ca14
      Neil Horman 提交于
      Ivan Vercera was recently backporting commit
      9c13cb8b to a RHEL kernel, and I noticed that,
      while this patch protects the tg3 driver from having its ndo_poll_controller
      routine called during device initalization, it does nothing for the driver
      during shutdown. I.e. it would be entirely possible to have the
      ndo_poll_controller method (or subsequently the ndo_poll) routine called for a
      driver in the netpoll path on CPU A while in parallel on CPU B, the ndo_close or
      ndo_open routine could be called.  Given that the two latter routines tend to
      initizlize and free many data structures that the former two rely on, the result
      can easily be data corruption or various other crashes.  Furthermore, it seems
      that this is potentially a problem with all net drivers that support netpoll,
      and so this should ideally be fixed in a common path.
      
      As Ben H Pointed out to me, we can't preform dev_open/dev_close in atomic
      context, so I've come up with this solution.  We can use a mutex to sleep in
      open/close paths and just do a mutex_trylock in the napi poll path and abandon
      the poll attempt if we're locked, as we'll just retry the poll on the next send
      anyway.
      
      I've tested this here by flooding netconsole with messages on a system whos nic
      driver I modfied to periodically return NETDEV_TX_BUSY, so that the netpoll tx
      workqueue would be forced to send frames and poll the device.  While this was
      going on I rapidly ifdown/up'ed the interface and watched for any problems.
      I've not found any.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      CC: Ivan Vecera <ivecera@redhat.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Ben Hutchings <bhutchings@solarflare.com>
      CC: Francois Romieu <romieu@fr.zoreil.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ca99ca14
    • J
      net: core: Remove unnecessary alloc/OOM messages · 62b5942a
      Joe Perches 提交于
      alloc failures already get standardized OOM
      messages and a dump_stack.
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62b5942a
  9. 05 2月, 2013 2 次提交
  10. 04 2月, 2013 1 次提交
  11. 30 1月, 2013 3 次提交
  12. 29 1月, 2013 4 次提交
  13. 28 1月, 2013 1 次提交
    • E
      net: fix possible wrong checksum generation · cef401de
      Eric Dumazet 提交于
      Pravin Shelar mentioned that GSO could potentially generate
      wrong TX checksum if skb has fragments that are overwritten
      by the user between the checksum computation and transmit.
      
      He suggested to linearize skbs but this extra copy can be
      avoided for normal tcp skbs cooked by tcp_sendmsg().
      
      This patch introduces a new SKB_GSO_SHARED_FRAG flag, set
      in skb_shinfo(skb)->gso_type if at least one frag can be
      modified by the user.
      
      Typical sources of such possible overwrites are {vm}splice(),
      sendfile(), and macvtap/tun/virtio_net drivers.
      
      Tested:
      
      $ netperf -H 7.7.8.84
      MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
      7.7.8.84 () port 0 AF_INET
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380  16384  16384    10.00    3959.52
      
      $ netperf -H 7.7.8.84 -t TCP_SENDFILE
      TCP SENDFILE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 7.7.8.84 ()
      port 0 AF_INET
      Recv   Send    Send
      Socket Socket  Message  Elapsed
      Size   Size    Size     Time     Throughput
      bytes  bytes   bytes    secs.    10^6bits/sec
      
       87380  16384  16384    10.00    3216.80
      
      Performance of the SENDFILE is impacted by the extra allocation and
      copy, and because we use order-0 pages, while the TCP_STREAM uses
      bigger pages.
      Reported-by: NPravin Shelar <pshelar@nicira.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cef401de
  14. 24 1月, 2013 1 次提交
  15. 23 1月, 2013 4 次提交
  16. 22 1月, 2013 1 次提交