1. 07 Sep, 2010 9 commits
    • Tetsuo Handa's avatar
      UNIX: Do not loop forever at unix_autobind(). · 8df73ff9
      Tetsuo Handa authored
      We assumed that unix_autobind() never fails if kzalloc() succeeded.
      But unix_autobind() allows only 1048576 names. If /proc/sys/fs/file-max is
      larger than 1048576 (e.g. systems with more than 10GB of RAM), a local user can
      consume all names using fork()/socket()/bind().
      
      If all names are in use, those who call bind() with addr_len == sizeof(short)
      or connect()/sendmsg() with setsockopt(SO_PASSCRED) will continue
      
        while (1)
              yield();
      
      loop at unix_autobind() till a name becomes available.
      This patch adds a loop counter in order to give up after 1048576 attempts.
      
      Calling yield() for once per 256 attempts may not be sufficient when many names
      are already in use, for __unix_find_socket_byname() can take long time under
      such circumstance. Therefore, this patch also adds cond_resched() call.
      
      Note that currently a local user can consume 2GB of kernel memory if the user
      is allowed to create and autobind 1048576 UNIX domain sockets. We should
      consider adding some restriction for autobind operation.
      Signed-off-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8df73ff9
    • Mark Lord's avatar
      PATCH: b44 Handle RX FIFO overflow better (simplified) · 32737e93
      Mark Lord authored
      This patch is a simplified version of the original patch from James Courtier-Dutton.
      
      >From: James Courtier-Dutton
      >Subject: [PATCH] Fix b44 RX FIFO overflow recovery.
      >Date: Wednesday, June 30, 2010 - 1:11 pm
      >
      >This patch improves the recovery after a RX FIFO overflow on the b44
      >Ethernet NIC.
      >Before it would do a complete chip reset, resulting is loss of link
      >for a few seconds.
      >This patch improves this to do recovery in about 20ms without loss of link.
      >
      >Signed off by: James@superbug.co.uk
      Signed-off-by: default avatarMark Lord <mlord@pobox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32737e93
    • Dan Carpenter's avatar
      irda: off by one · cf9b94f8
      Dan Carpenter authored
      This is an off by one.  We would go past the end when we NUL terminate
      the "value" string at end of the function.  The "value" buffer is
      allocated in irlan_client_parse_response() or
      irlan_provider_parse_command().
      
      CC: stable@kernel.org
      Signed-off-by: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf9b94f8
    • Ben Hutchings's avatar
      3c59x: Fix deadlock in vortex_error() · 89b12fab
      Ben Hutchings authored
      This fixes a bug introduced in commit
      de847272
      "3c59x: Use fine-grained locks for MII and windowed register access".
      
      vortex_interrupt() holds vp->window_lock over multiple register
      accesses to reduce locking overhead.  However it also needs to call
      vortex_error() sometimes, and that uses the regular functions for
      access to windowed registers, which will try to acquire window_lock
      again.
      
      Therefore, drop window_lock around the call to vortex_error() and set
      the window afterward reacquiring the lock.  Since vortex_error() may
      call vortex_rx(), which *does* require its caller to hold window_lock,
      lift that call up into vortex_interrupt().  This also removes the
      potential for calling vortex_rx() on a later-generation NIC.
      
      Reported-and-tested-by: Jens Schüßler <jgs@trash.net> [in Debian's 2.6.32]
      Signed-off-by: default avatarBen Hutchings <ben@decadent.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89b12fab
    • Nicolas Dichtel's avatar
      netfilter: discard overlapping IPv6 fragment · 1ee89bd0
      Nicolas Dichtel authored
      RFC5722 prohibits reassembling IPv6 fragments when some data overlaps.
      
      Bug spotted by Zhang Zuotao <zuotao.zhang@6wind.com>.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ee89bd0
    • Nicolas Dichtel's avatar
      ipv6: discard overlapping fragment · 70789d70
      Nicolas Dichtel authored
      RFC5722 prohibits reassembling fragments when some data overlaps.
      
      Bug spotted by Zhang Zuotao <zuotao.zhang@6wind.com>.
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      70789d70
    • Helmut Schaa's avatar
      net: fix tx queue selection for bridged devices implementing select_queue · deabc772
      Helmut Schaa authored
      When a net device is implementing the select_queue callback and is part of
      a bridge, frames coming from the bridge already have a tx queue associated
      to the socket (introduced in commit a4ee3ce3,
      "net: Use sk_tx_queue_mapping for connected sockets"). The call to
      sk_tx_queue_get will then return the tx queue used by the bridge instead
      of calling the select_queue callback.
      
      In case of mac80211 this broke QoS which is implemented by using the
      select_queue callback. Furthermore it introduced problems with rt2x00
      because frames with the same TID and RA sometimes appeared on different
      tx queues which the hw cannot handle correctly.
      
      Fix this by always calling select_queue first if it is available and only
      afterwards use the socket tx queue mapping.
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      deabc772
    • Jiri Bohac's avatar
      bonding: Fix jiffies overflow problems (again) · cb32f2a0
      Jiri Bohac authored
      The time_before_eq()/time_after_eq() functions operate on unsigned
      long and only work if the difference between the two compared values
      is smaller than half the range of unsigned long (31 bits on i386).
      
      Some of the variables (slave->jiffies, dev->trans_start, dev->last_rx)
      used by bonding store a copy of jiffies and may not be updated for a
      long time. With HZ=1000, time_before_eq()/time_after_eq() will start
      giving bad results after ~25 days.
      
      jiffies will never be before slave->jiffies, dev->trans_start,
      dev->last_rx by more than possibly a couple ticks caused by preemption
      of this code. This allows us to detect/prevent these overflows by
      replacing time_before_eq()/time_after_eq() with time_in_range().
      Signed-off-by: default avatarJiri Bohac <jbohac@suse.cz>
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb32f2a0
    • Giuseppe Cavallaro's avatar
      stmmac: fix sleep inside atomic · c4433be6
      Giuseppe Cavallaro authored
      We cannot use spinlock when kmalloc is invoked with
      GFP_KERNEL flag because it can sleep.
      So this patch reviews the usage of spinlock within the
      stmmac_resume function avoing this bug.
      Signed-off-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Reported-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c4433be6
  2. 03 Sep, 2010 4 commits
  3. 02 Sep, 2010 6 commits
  4. 01 Sep, 2010 9 commits
  5. 31 Aug, 2010 5 commits
    • Luis R. Rodriguez's avatar
      ath9k_hw: fix parsing of HT40 5 GHz CTLs · 90487974
      Luis R. Rodriguez authored
      The 5 GHz CTL indexes were not being read for all hardware
      devices due to the masking out through the CTL_MODE_M mask
      being one bit too short. Without this the calibrated regulatory
      maximum values were not being picked up when devices operate
      on 5 GHz in HT40 mode. The final output power used for Atheros
      devices is the minimum between the calibrated CTL values and
      what CRDA provides.
      
      Cc: stable@kernel.org [2.6.27+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      90487974
    • Luis R. Rodriguez's avatar
      ath9k_hw: Fix EEPROM uncompress block reading on AR9003 · 803288e6
      Luis R. Rodriguez authored
      The EEPROM is compressed on AR9003, upon decompression
      the wrong upper limit was being used for the block which
      prevented the 5 GHz CTL indexes from being used, which are
      stored towards the end of the EEPROM block. This fix allows
      the actual intended regulatory limits to be used on AR9003
      hardware.
      
      Cc: stable@kernel.org [2.6.36+]
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      803288e6
    • John W. Linville's avatar
      wireless: register wiphy rfkill w/o holding cfg80211_mutex · c3d34d5d
      John W. Linville authored
      Otherwise lockdep complains...
      
      https://bugzilla.kernel.org/show_bug.cgi?id=17311
      
      [ INFO: possible circular locking dependency detected ]
      2.6.36-rc2-git4 #12
      -------------------------------------------------------
      kworker/0:3/3630 is trying to acquire lock:
       (rtnl_mutex){+.+.+.}, at: [<ffffffff813396c7>] rtnl_lock+0x12/0x14
      
      but task is already holding lock:
       (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa014b129>]
      rfkill_switch_all+0x24/0x49 [rfkill]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (rfkill_global_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa014b4ab>] rfkill_register+0x2b/0x29c [rfkill]
             [<ffffffffa0185ba0>] wiphy_register+0x1ae/0x270 [cfg80211]
             [<ffffffffa0206f01>] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
             [<ffffffffa0292e98>] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
             [<ffffffff812d3e9d>] request_firmware_work_func+0x54/0x6f
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      
      -> #1 (cfg80211_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa018605e>] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
             [<ffffffffa0189f36>] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
             [<ffffffff8139a3ce>] ioctl_standard_iw_point+0x1a8/0x272
             [<ffffffff8139a529>] ioctl_standard_call+0x91/0xa7
             [<ffffffff8139a687>] T.723+0xbd/0x12c
             [<ffffffff8139a727>] wext_handle_ioctl+0x31/0x6d
             [<ffffffff8133014e>] dev_ioctl+0x63d/0x67a
             [<ffffffff8131afd9>] sock_ioctl+0x48/0x21d
             [<ffffffff81102abd>] do_vfs_ioctl+0x4ba/0x509
             [<ffffffff81102b5d>] sys_ioctl+0x51/0x74
             [<ffffffff81009e02>] system_call_fastpath+0x16/0x1b
      
      -> #0 (rtnl_mutex){+.+.+.}:
             [<ffffffff810796b0>] __lock_acquire+0xa93/0xd9a
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffff813396c7>] rtnl_lock+0x12/0x14
             [<ffffffffa0185cb5>] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
             [<ffffffffa014aed0>] rfkill_set_block+0x80/0xd5 [rfkill]
             [<ffffffffa014b07e>] __rfkill_switch_all+0x3f/0x6f [rfkill]
             [<ffffffffa014b13d>] rfkill_switch_all+0x38/0x49 [rfkill]
             [<ffffffffa014b821>] rfkill_op_handler+0x105/0x136 [rfkill]
             [<ffffffff81060708>] process_one_work+0x248/0x403
             [<ffffffff81062620>] worker_thread+0x139/0x214
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      c3d34d5d
    • David S. Miller's avatar
      netlink: Make NETLINK_USERSOCK work again. · b963ea89
      David S. Miller authored
      Once we started enforcing the a nl_table[] entry exist for
      a protocol, NETLINK_USERSOCK stopped working.  Add a dummy
      table entry so that it works again.
      Reported-by: default avatarThomas Voegtle <tv@lio96.de>
      Tested-by: default avatarThomas Voegtle <tv@lio96.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b963ea89
    • David S. Miller's avatar
      irda: Correctly clean up self->ias_obj on irda_bind() failure. · 628e300c
      David S. Miller authored
      If irda_open_tsap() fails, the irda_bind() code tries to destroy
      the ->ias_obj object by hand, but does so wrongly.
      
      In particular, it fails to a) release the hashbin attached to the
      object and b) reset the self->ias_obj pointer to NULL.
      
      Fix both problems by using irias_delete_object() and explicitly
      setting self->ias_obj to NULL, just as irda_release() does.
      Reported-by: default avatarTavis Ormandy <taviso@cmpxchg8b.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      628e300c
  6. 30 Aug, 2010 5 commits
  7. 28 Aug, 2010 2 commits