1. 23 9月, 2010 6 次提交
  2. 22 9月, 2010 4 次提交
  3. 21 9月, 2010 6 次提交
  4. 18 9月, 2010 5 次提交
    • E
      qlcnic: dont assume NET_IP_ALIGN is 2 · 04746ff1
      Eric Dumazet 提交于
      qlcnic driver allocates rx skbs and gives to hardware too bytes of extra
      storage, allowing for corruption of kernel data.
      
      NET_IP_ALIGN being 0 on some platforms (including x86), drivers should
      not assume it's 2.
      
      rds_ring->skb_size = rds_ring->dma_size + NET_IP_ALIGN;
      ...
      skb = dev_alloc_skb(rds_ring->skb_size);
      skb_reserve(skb, 2);
      pci_map_single(pdev, skb->data, rds_ring->dma_size, PCI_DMA_FROMDEVICE);
      
      (and rds_ring->skb_size == rds_ring->dma_size) -> bug
      
      
      Because of extra alignment (1500 + 32) -> four extra bytes are available
      before the struct skb_shared_info, so corruption is not noticed.
      
      Note: this driver could use netdev_alloc_skb_ip_align()
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      04746ff1
    • S
      dca: disable dca on IOAT ver.3.0 multiple-IOH platforms · 4e8cec26
      Sosnowski, Maciej 提交于
      Direct Cache Access is not supported on IOAT ver.3.0 multiple-IOH platforms.
      This patch blocks registering of dca providers when multiple IOH detected with IOAT ver.3.0.
      Signed-off-by: NMaciej Sosnowski <maciej.sosnowski@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4e8cec26
    • H
      netpoll: Disable IRQ around RCU dereference in netpoll_rx · f0f9deae
      Herbert Xu 提交于
      We cannot use rcu_dereference_bh safely in netpoll_rx as we may
      be called with IRQs disabled.  We could however simply disable
      IRQs as that too causes BH to be disabled and is safe in either
      case.
      
      Thanks to John Linville for discovering this bug and providing
      a patch.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f0f9deae
    • V
      sctp: Do not reset the packet during sctp_packet_config(). · 4bdab433
      Vlad Yasevich 提交于
      sctp_packet_config() is called when getting the packet ready
      for appending of chunks.  The function should not touch the
      current state, since it's possible to ping-pong between two
      transports when sending, and that can result packet corruption
      followed by skb overlfow crash.
      Reported-by: NThomas Dreibholz <dreibh@iem.uni-due.de>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4bdab433
    • W
      iwlwifi: do not perferm force reset while doing scan · 7acc7c68
      Wey-Yi Guy 提交于
      When uCode error condition detected, driver try to perform either
      rf reset or firmware reload in order bring device back to
      working condition.
      
      If rf reset is required and scan is in process, there is no need
      to issue rf reset since scan already reset the rf.
      
      If firmware reload is required and scan is in process, skip the
      reload request. There is a possibility firmware reload during
      scan cause problem.
      
      [  485.804046] WARNING: at net/mac80211/main.c:310 ieee80211_restart_hw+0x28/0x62()
      [  485.804049] Hardware name: Latitude E6400
      [  485.804052] ieee80211_restart_hw called with hardware scan in progress
      [  485.804054] Modules linked in: iwlagn iwlcore bnep sco rfcomm l2cap crc16 bluetooth [last unloaded: iwlcore]
      [  485.804069] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
      [  485.804072] Call Trace:
      [  485.804079]  [<c103019a>] warn_slowpath_common+0x60/0x75
      [  485.804084]  [<c1030213>] warn_slowpath_fmt+0x26/0x2a
      [  485.804089]  [<c145da67>] ieee80211_restart_hw+0x28/0x62
      [  485.804102]  [<f8b35dc6>] iwl_bg_restart+0x113/0x150 [iwlagn]
      [  485.804108]  [<c10415d5>] process_one_work+0x181/0x25c
      [  485.804119]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
      [  485.804124]  [<c104190a>] worker_thread+0xf9/0x1f2
      [  485.804128]  [<c1041811>] ? worker_thread+0x0/0x1f2
      [  485.804133]  [<c10451b0>] kthread+0x64/0x69
      [  485.804137]  [<c104514c>] ? kthread+0x0/0x69
      [  485.804141]  [<c1002df6>] kernel_thread_helper+0x6/0x10
      [  485.804145] ---[ end trace 3d4ebdc02d524bbb ]---
      [  485.804148] WG> 1
      [  485.804153] Pid: 812, comm: kworker/u:3 Tainted: G        W   2.6.36-rc3-wl+ #74
      [  485.804156] Call Trace:
      [  485.804161]  [<c145da9b>] ? ieee80211_restart_hw+0x5c/0x62
      [  485.804172]  [<f8b35dcb>] iwl_bg_restart+0x118/0x150 [iwlagn]
      [  485.804177]  [<c10415d5>] process_one_work+0x181/0x25c
      [  485.804188]  [<f8b35cb3>] ? iwl_bg_restart+0x0/0x150 [iwlagn]
      [  485.804192]  [<c104190a>] worker_thread+0xf9/0x1f2
      [  485.804197]  [<c1041811>] ? worker_thread+0x0/0x1f2
      [  485.804201]  [<c10451b0>] kthread+0x64/0x69
      [  485.804205]  [<c104514c>] ? kthread+0x0/0x69
      [  485.804209]  [<c1002df6>] kernel_thread_helper+0x6/0x10
      Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
      7acc7c68
  5. 17 9月, 2010 6 次提交
  6. 16 9月, 2010 3 次提交
    • M
      r8169: Handle rxfifo errors on 8168 chips · 801e147c
      Matthew Garrett 提交于
      The Thinkpad X100e seems to have some odd behaviour when the display is
      powered off - the onboard r8169 starts generating rxfifo overflow errors.
      The root cause of this has not yet been identified and may well be a
      hardware design bug on the platform, but r8169 should be more resiliant to
      this. This patch enables the rxfifo interrupt on 8168 devices and removes
      the MAC version check in the interrupt handler, and the machine no longer
      crashes when under network load while the screen turns off.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Acked-by: NFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      801e147c
    • D
      3c59x: Remove atomic context inside vortex_{set|get}_wol · 84176b7b
      Denis Kirjanov 提交于
      There is no need to use spinlocks in vortex_{set|get}_wol.
      This also fixes a bug:
      [  254.214993] 3c59x 0000:00:0d.0: PME# enabled
      [  254.215021] BUG: sleeping function called from invalid context at kernel/mutex.c:94
      [  254.215030] in_atomic(): 0, irqs_disabled(): 1, pid: 4875, name: ethtool
      [  254.215042] Pid: 4875, comm: ethtool Tainted: G        W   2.6.36-rc3+ #7
      [  254.215049] Call Trace:
      [  254.215050]  [] __might_sleep+0xb1/0xb6
      [  254.215050]  [] mutex_lock+0x17/0x30
      [  254.215050]  [] acpi_enable_wakeup_device_power+0x2b/0xb1
      [  254.215050]  [] acpi_pm_device_sleep_wake+0x42/0x7f
      [  254.215050]  [] acpi_pci_sleep_wake+0x5d/0x63
      [  254.215050]  [] platform_pci_sleep_wake+0x1d/0x20
      [  254.215050]  [] __pci_enable_wake+0x90/0xd0
      [  254.215050]  [] acpi_set_WOL+0x8e/0xf5 [3c59x]
      [  254.215050]  [] vortex_set_wol+0x4e/0x5e [3c59x]
      [  254.215050]  [] dev_ethtool+0x1cf/0xb61
      [  254.215050]  [] ? debug_mutex_free_waiter+0x45/0x4a
      [  254.215050]  [] ? __mutex_lock_common+0x204/0x20e
      [  254.215050]  [] ? __mutex_lock_slowpath+0x12/0x15
      [  254.215050]  [] ? mutex_lock+0x23/0x30
      [  254.215050]  [] dev_ioctl+0x42c/0x533
      [  254.215050]  [] ? _cond_resched+0x8/0x1c
      [  254.215050]  [] ? lock_page+0x1c/0x30
      [  254.215050]  [] ? page_address+0x15/0x7c
      [  254.215050]  [] ? filemap_fault+0x187/0x2c4
      [  254.215050]  [] sock_ioctl+0x1d4/0x1e0
      [  254.215050]  [] ? sock_ioctl+0x0/0x1e0
      [  254.215050]  [] vfs_ioctl+0x19/0x33
      [  254.215050]  [] do_vfs_ioctl+0x424/0x46f
      [  254.215050]  [] ? selinux_file_ioctl+0x3c/0x40
      [  254.215050]  [] sys_ioctl+0x40/0x5a
      [  254.215050]  [] sysenter_do_call+0x12/0x22
      
      vortex_set_wol protected with a spinlock, but nested  acpi_set_WOL acquires a mutex inside atomic context.
      Ethtool operations are already serialized by RTNL mutex, so it is safe to drop the locks.
      Signed-off-by: NDenis Kirjanov <dkirjanov@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84176b7b
    • A
      tcp: Prevent overzealous packetization by SWS logic. · 01f83d69
      Alexey Kuznetsov 提交于
      If peer uses tiny MSS (say, 75 bytes) and similarly tiny advertised
      window, the SWS logic will packetize to half the MSS unnecessarily.
      
      This causes problems with some embedded devices.
      
      However for large MSS devices we do want to half-MSS packetize
      otherwise we never get enough packets into the pipe for things
      like fast retransmit and recovery to work.
      
      Be careful also to handle the case where MSS > window, otherwise
      we'll never send until the probe timer.
      Reported-by: Nツ Leandro Melo de Sales <leandroal@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      01f83d69
  7. 15 9月, 2010 4 次提交
  8. 14 9月, 2010 5 次提交
    • M
      vhost-net: fix range checking in mrg bufs case · ee05d693
      Michael S. Tsirkin 提交于
      In mergeable buffer case, we use headcount, log_num
      and seg as indexes in same-size arrays, and
      we know that headcount <= seg and
      log_num equals either 0 or seg.
      
      Therefore, the right thing to do is range-check seg,
      not headcount as we do now: these will be different
      if guest chains s/g descriptors (this does not
      happen now, but we can not trust the guest).
      
      Long term, we should add BUG_ON checks to verify
      two other indexes are what we think they should be.
      Reported-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      ee05d693
    • M
      ipv4: enable getsockopt() for IP_NODEFRAG · a89b4763
      Michael Kerrisk 提交于
      While integrating your man-pages patch for IP_NODEFRAG, I noticed
      that this option is settable by setsockopt(), but not gettable by
      getsockopt(). I suppose this is not intended. The (untested,
      trivial) patch below adds getsockopt() support.
      Signed-off-by: NMichael kerrisk <mtk.manpages@gmail.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a89b4763
    • B
      ipv4: force_igmp_version ignored when a IGMPv3 query received · 79981563
      Bob Arendt 提交于
      After all these years, it turns out that the
          /proc/sys/net/ipv4/conf/*/force_igmp_version
      parameter isn't fully implemented.
      
      *Symptom*:
      When set force_igmp_version to a value of 2, the kernel should only perform
      multicast IGMPv2 operations (IETF rfc2236).  An host-initiated Join message
      will be sent as a IGMPv2 Join message.  But if a IGMPv3 query message is
      received, the host responds with a IGMPv3 join message.  Per rfc3376 and
      rfc2236, a IGMPv2 host should treat a IGMPv3 query as a IGMPv2 query and
      respond with an IGMPv2 Join message.
      
      *Consequences*:
      This is an issue when a IGMPv3 capable switch is the querier and will only
      issue IGMPv3 queries (which double as IGMPv2 querys) and there's an
      intermediate switch that is only IGMPv2 capable.  The intermediate switch
      processes the initial v2 Join, but fails to recognize the IGMPv3 Join responses
      to the Query, resulting in a dropped connection when the intermediate v2-only
      switch times it out.
      
      *Identifying issue in the kernel source*:
      The issue is in this section of code (in net/ipv4/igmp.c), which is called when
      an IGMP query is received  (from mainline 2.6.36-rc3 gitweb):
       ...
      A IGMPv3 query has a length >= 12 and no sources.  This routine will exit after
      line 880, setting the general query timer (random timeout between 0 and query
      response time).  This calls igmp_gq_timer_expire():
      ...
      .. which only sends a v3 response.  So if a v3 query is received, the kernel
      always sends a v3 response.
      
      IGMP queries happen once every 60 sec (per vlan), so the traffic is low.  A
      IGMPv3 query *is* a strict superset of a IGMPv2 query, so this patch properly
      short circuit's the v3 behaviour.
      
      One issue is that this does not address force_igmp_version=1.  Then again, I've
      never seen any IGMPv1 multicast equipment in the wild.  However there is a lot
      of v2-only equipment. If it's necessary to support the IGMPv1 case as well:
      
      837         if (len == 8 || IGMP_V2_SEEN(in_dev) || IGMP_V1_SEEN(in_dev)) {
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      79981563
    • D
      ppp: potential NULL dereference in ppp_mp_explode() · 3429769b
      Dan Carpenter 提交于
      Smatch complains because we check whether "pch->chan" is NULL and then
      dereference it unconditionally on the next line.  Partly the reason this
      bug was introduced is because code was too complicated.  I've simplified
      it a little.
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3429769b
    • D
      net/llc: make opt unsigned in llc_ui_setsockopt() · 339db11b
      Dan Carpenter 提交于
      The members of struct llc_sock are unsigned so if we pass a negative
      value for "opt" it can cause a sign bug.  Also it can cause an integer
      overflow when we multiply "opt * HZ".
      
      CC: stable@kernel.org
      Signed-off-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      339db11b
  9. 13 9月, 2010 1 次提交