1. 03 Oct, 2011 5 commits
    • Toshiharu Okada's avatar
      pch_gbe: Fixed the issue on which a network freezes · 805e969f
      Toshiharu Okada authored
      The pch_gbe driver has an issue which a network stops,
      when receiving traffic is high.
      In the case, The link down and up are necessary to return a network.
      
      This patch fixed this issue.
      Signed-off-by: default avatarToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      805e969f
    • Toshiharu Okada's avatar
      pch_gbe: Fixed the issue on which PC was frozen when link was downed. · 5f3a1141
      Toshiharu Okada authored
      When a link was downed during network use,
      there is an issue on which PC freezes.
      
      This patch fixed this issue.
      Signed-off-by: default avatarToshiharu Okada <toshiharu-linux@dsn.okisemi.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f3a1141
    • Willem de Bruijn's avatar
      make PACKET_STATISTICS getsockopt report consistently between ring and non-ring · 7091fbd8
      Willem de Bruijn authored
      This is a minor change.
      
      Up until kernel 2.6.32, getsockopt(fd, SOL_PACKET, PACKET_STATISTICS,
      ...) would return total and dropped packets since its last invocation. The
      introduction of socket queue overflow reporting [1] changed drop
      rate calculation in the normal packet socket path, but not when using a
      packet ring. As a result, the getsockopt now returns different statistics
      depending on the reception method used. With a ring, it still returns the
      count since the last call, as counts are incremented in tpacket_rcv and
      reset in getsockopt. Without a ring, it returns 0 if no drops occurred
      since the last getsockopt and the total drops over the lifespan of
      the socket otherwise. The culprit is this line in packet_rcv, executed
      on a drop:
      
      drop_n_acct:
              po->stats.tp_drops = atomic_inc_return(&sk->sk_drops);
      
      As it shows, the new drop number it taken from the socket drop counter,
      which is not reset at getsockopt. I put together a small example
      that demonstrates the issue [2]. It runs for 10 seconds and overflows
      the queue/ring on every odd second. The reported drop rates are:
      ring: 16, 0, 16, 0, 16, ...
      non-ring: 0, 15, 0, 30, 0, 46, 0, 60, 0 , 74.
      
      Note how the even ring counts monotonically increase. Because the
      getsockopt adds tp_drops to tp_packets, total counts are similarly
      reported cumulatively. Long story short, reinstating the original code, as
      the below patch does, fixes the issue at the cost of additional per-packet
      cycles. Another solution that does not introduce per-packet overhead
      is be to keep the current data path, record the value of sk_drops at
      getsockopt() at call N in a new field in struct packetsock and subtract
      that when reporting at call N+1. I'll be happy to code that, instead,
      it's just more messy.
      
      [1] http://patchwork.ozlabs.org/patch/35665/
      [2] http://kernel.googlecode.com/files/test-packetsock-getstatistics.cSigned-off-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7091fbd8
    • David Vrabel's avatar
      net: xen-netback: correctly restart Tx after a VM restore/migrate · d0e5d832
      David Vrabel authored
      If a VM is saved and restored (or migrated) the netback driver will no
      longer process any Tx packets from the frontend.  xenvif_up() does not
      schedule the processing of any pending Tx requests from the front end
      because the carrier is off.  Without this initial kick the frontend
      just adds Tx requests to the ring without raising an event (until the
      ring is full).
      
      This was caused by 47103041 (net:
      xen-netback: convert to hw_features) which reordered the calls to
      xenvif_up() and netif_carrier_on() in xenvif_connect().
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Acked-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0e5d832
    • Andy Gospodarek's avatar
      bonding: properly stop queuing work when requested · a0db2dad
      Andy Gospodarek authored
      During a test where a pair of bonding interfaces using ARP monitoring
      were both brought up and torn down (with an rmmod) repeatedly, a panic
      in the timer code was noticed.  I tracked this down and determined that
      any of the bonding functions that ran as workqueue handlers and requeued
      more work might not properly exit when the module was removed.
      
      There was a flag protected by the bond lock called kill_timers that is
      set when the interface goes down or the module is removed, but many of
      the functions that monitor link status now unlock the bond lock to take
      rtnl first.  There is a chance that another CPU running the rmmod could
      get the lock and set kill_timers after the first check has passed.
      
      This patch does not allow any function to queue work that will make
      itself run unless kill_timers is not set.  I also noticed while doing
      this work that bond_resend_igmp_join_requests did not have a check for
      kill_timers, so I added the needed call there as well.
      Signed-off-by: default avatarAndy Gospodarek <andy@greyhouse.net>
      Reported-by: default avatarLiang Zheng <lzheng@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0db2dad
  2. 29 Sep, 2011 10 commits
  3. 28 Sep, 2011 7 commits
    • Linus Torvalds's avatar
      bootup: move 'usermodehelper_enable()' to the end of do_basic_setup() · d5767c53
      Linus Torvalds authored
      Doing it just before starting to call into cpu_idle() made a sick kind
      of sense only because the original bug we fixed (see commit
      288d5abe: "Boot up with usermodehelper disabled") was about problems
      with some scheduler data structures not being initialized, and they had
      better be initialized at that point.
      
      But it really didn't make any other conceptual sense, and doing it after
      the initial "schedule()" call for the idle thread actually opened up a
      race: what if the main initialization thread did everything without
      needing to sleep, and got all the way into user land too? Without
      actually having scheduled back to the idle thread?
      
      Now, in normal circumstances that doesn't ever happen, but it looks like
      Richard Cochran triggered exactly that on his ARM IXP4xx machines:
      
        "I have some ARM IXP4xx based machines that use the two on chip MAC
         ports (aka NPEs).  The NPE needs a firmware in order to function.
         Ever since the following commit [that 288d5abe one], it is no
         longer possible to bring up the interfaces during the init scripts."
      
      with a call trace showing an ioctl coming from user space. Richard says:
      
        "The init is busybox, and the startup script does mount, syslogd, and
         then ifup, so that all can go by quickly."
      
      The fix is to move the usermodehelper_enable() into the main 'init'
      thread, and just put it after we've done all our initcalls.  By then,
      everything really should be up, but we've obviously not actually started
      the user-mode portion of init yet.
      Reported-and-tested-by: default avatarRichard Cochran <richardcochran@gmail.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d5767c53
    • Linus Torvalds's avatar
      Merge git://github.com/davem330/net · 2ef7b45a
      Linus Torvalds authored
      * git://github.com/davem330/net:
        ipv6-multicast: Fix memory leak in IPv6 multicast.
        ipv6: check return value for dst_alloc
        net: check return value for dst_alloc
        ipv6-multicast: Fix memory leak in input path.
        bnx2x: add missing break in bnx2x_dcbnl_get_cap
        bnx2x: fix WOL by enablement PME in config space
        bnx2x: fix hw attention handling
        net: fix a typo in Documentation/networking/scaling.txt
        ath9k: Fix a dma warning/memory leak
        rtlwifi: rtl8192cu: Fix unitialized struct
        iwlagn: fix dangling scan request
        batman-adv: do_bcast has to be true for broadcast packets only
        cfg80211: Fix validation of AKM suites
        iwlegacy: do not use interruptible waits
        iwlegacy: fix command queue timeout
        ath9k_hw: Fix Rx DMA stuck for AR9003 chips
      2ef7b45a
    • Linus Torvalds's avatar
      Merge git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6 · 07117e30
      Linus Torvalds authored
      * git://bedivere.hansenpartnership.com/git/scsi-rc-fixes-2.6:
        [SCSI] 3w-9xxx: fix iommu_iova leak
        [SCSI] cxgb3i: convert cdev->l2opt to use rcu to prevent NULL dereference
        [SCSI] scsi: qla4xxx needs libiscsi.o
        [SCSI] libsas: fix failure to revalidate domain for anything but the first expander child.
        [SCSI] aacraid: reset should disable MSI interrupt
      07117e30
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · c54a06d4
      Linus Torvalds authored
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: Free queue resources at blk_release_queue()
      c54a06d4
    • Linus Torvalds's avatar
      Merge branch 'writeback-for-linus' of git://github.com/fengguang/linux · e689ec80
      Linus Torvalds authored
      * 'writeback-for-linus' of git://github.com/fengguang/linux:
        writeback: show raw dirtied_when in trace writeback_single_inode
      e689ec80
    • Hannes Reinecke's avatar
      block: Free queue resources at blk_release_queue() · 777eb1bf
      Hannes Reinecke authored
      A kernel crash is observed when a mounted ext3/ext4 filesystem is
      physically removed. The problem is that blk_cleanup_queue() frees up
      some resources eg by calling elevator_exit(), which are not checked for
      in normal operation. So we should rather move these calls to the
      destructor function blk_release_queue() as at that point all remaining
      references are gone. However, in doing so we have to ensure that any
      externally supplied queue_lock is disconnected as the driver might free
      up the lock after the call of blk_cleanup_queue(),
      Signed-off-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      777eb1bf
    • David S. Miller's avatar
  4. 27 Sep, 2011 18 commits