1. 16 Sep, 2010 1 commit
  2. 15 Sep, 2010 3 commits
    • Denis Kirjanov's avatar
      3c59x: Remove atomic context inside vortex_{set|get}_wol · 84176b7b
      Denis Kirjanov authored
      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: default avatarDenis Kirjanov <dkirjanov@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      84176b7b
    • Alexey Kuznetsov's avatar
      tcp: Prevent overzealous packetization by SWS logic. · 01f83d69
      Alexey Kuznetsov authored
      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: default avatarツ Leandro Melo de Sales <leandroal@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      01f83d69
    • David S. Miller's avatar
      net: RPS needs to depend upon USE_GENERIC_SMP_HELPERS · 6dcbc122
      David S. Miller authored
      You cannot invoke __smp_call_function_single() unless the
      architecture sets this symbol.
      Reported-by: default avatarDaniel Hellstrom <daniel@gaisler.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6dcbc122
  3. 14 Sep, 2010 4 commits
  4. 13 Sep, 2010 3 commits
    • Bob Arendt's avatar
      ipv4: force_igmp_version ignored when a IGMPv3 query received · 79981563
      Bob Arendt authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      79981563
    • Dan Carpenter's avatar
      ppp: potential NULL dereference in ppp_mp_explode() · 3429769b
      Dan Carpenter authored
      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: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3429769b
    • Dan Carpenter's avatar
      net/llc: make opt unsigned in llc_ui_setsockopt() · 339db11b
      Dan Carpenter authored
      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: default avatarDan Carpenter <error27@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      339db11b
  5. 12 Sep, 2010 1 commit
  6. 10 Sep, 2010 3 commits
  7. 09 Sep, 2010 4 commits
  8. 08 Sep, 2010 5 commits
    • Jianzhao Wang's avatar
      net: blackhole route should always be recalculated · ae2688d5
      Jianzhao Wang authored
      Blackhole routes are used when xfrm_lookup() returns -EREMOTE (error
      triggered by IKE for example), hence this kind of route is always
      temporary and so we should check if a better route exists for next
      packets.
      Bug has been introduced by commit d11a4dc1.
      Signed-off-by: default avatarJianzhao Wang <jianzhao.wang@6wind.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae2688d5
    • Jarek Poplawski's avatar
      ipv4: Suppress lockdep-RCU false positive in FIB trie (3) · f6b085b6
      Jarek Poplawski authored
      Hi,
      Here is one more of these warnings and a patch below:
      
      Sep  5 23:52:33 del kernel: [46044.244833] ===================================================
      Sep  5 23:52:33 del kernel: [46044.269681] [ INFO: suspicious rcu_dereference_check() usage. ]
      Sep  5 23:52:33 del kernel: [46044.277000] ---------------------------------------------------
      Sep  5 23:52:33 del kernel: [46044.285185] net/ipv4/fib_trie.c:1756 invoked rcu_dereference_check() without protection!
      Sep  5 23:52:33 del kernel: [46044.293627]
      Sep  5 23:52:33 del kernel: [46044.293632] other info that might help us debug this:
      Sep  5 23:52:33 del kernel: [46044.293634]
      Sep  5 23:52:33 del kernel: [46044.325333]
      Sep  5 23:52:33 del kernel: [46044.325335] rcu_scheduler_active = 1, debug_locks = 0
      Sep  5 23:52:33 del kernel: [46044.348013] 1 lock held by pppd/1717:
      Sep  5 23:52:33 del kernel: [46044.357548]  #0:  (rtnl_mutex){+.+.+.}, at: [<c125dc1f>] rtnl_lock+0xf/0x20
      Sep  5 23:52:33 del kernel: [46044.367647]
      Sep  5 23:52:33 del kernel: [46044.367652] stack backtrace:
      Sep  5 23:52:33 del kernel: [46044.387429] Pid: 1717, comm: pppd Not tainted 2.6.35.4.4a #3
      Sep  5 23:52:33 del kernel: [46044.398764] Call Trace:
      Sep  5 23:52:33 del kernel: [46044.409596]  [<c12f9aba>] ? printk+0x18/0x1e
      Sep  5 23:52:33 del kernel: [46044.420761]  [<c1053969>] lockdep_rcu_dereference+0xa9/0xb0
      Sep  5 23:52:33 del kernel: [46044.432229]  [<c12b7235>] trie_firstleaf+0x65/0x70
      Sep  5 23:52:33 del kernel: [46044.443941]  [<c12b74d4>] fib_table_flush+0x14/0x170
      Sep  5 23:52:33 del kernel: [46044.455823]  [<c1033e92>] ? local_bh_enable_ip+0x62/0xd0
      Sep  5 23:52:33 del kernel: [46044.467995]  [<c12fc39f>] ? _raw_spin_unlock_bh+0x2f/0x40
      Sep  5 23:52:33 del kernel: [46044.480404]  [<c12b24d0>] ? fib_sync_down_dev+0x120/0x180
      Sep  5 23:52:33 del kernel: [46044.493025]  [<c12b069d>] fib_flush+0x2d/0x60
      Sep  5 23:52:33 del kernel: [46044.505796]  [<c12b06f5>] fib_disable_ip+0x25/0x50
      Sep  5 23:52:33 del kernel: [46044.518772]  [<c12b10d3>] fib_netdev_event+0x73/0xd0
      Sep  5 23:52:33 del kernel: [46044.531918]  [<c1048dfd>] notifier_call_chain+0x2d/0x70
      Sep  5 23:52:33 del kernel: [46044.545358]  [<c1048f0a>] raw_notifier_call_chain+0x1a/0x20
      Sep  5 23:52:33 del kernel: [46044.559092]  [<c124f687>] call_netdevice_notifiers+0x27/0x60
      Sep  5 23:52:33 del kernel: [46044.573037]  [<c124faec>] __dev_notify_flags+0x5c/0x80
      Sep  5 23:52:33 del kernel: [46044.586489]  [<c124fb47>] dev_change_flags+0x37/0x60
      Sep  5 23:52:33 del kernel: [46044.599394]  [<c12a8a8d>] devinet_ioctl+0x54d/0x630
      Sep  5 23:52:33 del kernel: [46044.612277]  [<c12aabb7>] inet_ioctl+0x97/0xc0
      Sep  5 23:52:34 del kernel: [46044.625208]  [<c123f6af>] sock_ioctl+0x6f/0x270
      Sep  5 23:52:34 del kernel: [46044.638046]  [<c109d2b0>] ? handle_mm_fault+0x420/0x6c0
      Sep  5 23:52:34 del kernel: [46044.650968]  [<c123f640>] ? sock_ioctl+0x0/0x270
      Sep  5 23:52:34 del kernel: [46044.663865]  [<c10c3188>] vfs_ioctl+0x28/0xa0
      Sep  5 23:52:34 del kernel: [46044.676556]  [<c10c38fa>] do_vfs_ioctl+0x6a/0x5c0
      Sep  5 23:52:34 del kernel: [46044.688989]  [<c1048676>] ? up_read+0x16/0x30
      Sep  5 23:52:34 del kernel: [46044.701411]  [<c1021376>] ? do_page_fault+0x1d6/0x3a0
      Sep  5 23:52:34 del kernel: [46044.714223]  [<c10b6588>] ? fget_light+0xf8/0x2f0
      Sep  5 23:52:34 del kernel: [46044.726601]  [<c1241f98>] ? sys_socketcall+0x208/0x2c0
      Sep  5 23:52:34 del kernel: [46044.739140]  [<c10c3eb3>] sys_ioctl+0x63/0x70
      Sep  5 23:52:34 del kernel: [46044.751967]  [<c12fca3d>] syscall_call+0x7/0xb
      Sep  5 23:52:34 del kernel: [46044.764734]  [<c12f0000>] ? cookie_v6_check+0x3d0/0x630
      
      -------------->
      
      This patch fixes the warning:
       ===================================================
       [ INFO: suspicious rcu_dereference_check() usage. ]
       ---------------------------------------------------
       net/ipv4/fib_trie.c:1756 invoked rcu_dereference_check() without protection!
      
       other info that might help us debug this:
      
       rcu_scheduler_active = 1, debug_locks = 0
       1 lock held by pppd/1717:
        #0:  (rtnl_mutex){+.+.+.}, at: [<c125dc1f>] rtnl_lock+0xf/0x20
      
       stack backtrace:
       Pid: 1717, comm: pppd Not tainted 2.6.35.4a #3
       Call Trace:
        [<c12f9aba>] ? printk+0x18/0x1e
        [<c1053969>] lockdep_rcu_dereference+0xa9/0xb0
        [<c12b7235>] trie_firstleaf+0x65/0x70
        [<c12b74d4>] fib_table_flush+0x14/0x170
        ...
      
      Allow trie_firstleaf() to be called either under rcu_read_lock()
      protection or with RTNL held. The same annotation is added to
      node_parent_rcu() to prevent a similar warning a bit later.
      
      Followup of commits 634a4b20 and 4eaa0e3c.
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6b085b6
    • Ben Hutchings's avatar
      niu: Fix kernel buffer overflow for ETHTOOL_GRXCLSRLALL · ee9c5cfa
      Ben Hutchings authored
      niu_get_ethtool_tcam_all() assumes that its output buffer is the right
      size, and warns before returning if it is not.  However, the output
      buffer size is under user control and ETHTOOL_GRXCLSRLALL is an
      unprivileged ethtool command.  Therefore this is at least a local
      denial-of-service vulnerability.
      
      Change it to check before writing each entry and to return an error if
      the buffer is already full.
      
      Compile-tested only.
      Signed-off-by: default avatarBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee9c5cfa
    • Julian Anastasov's avatar
      ipvs: fix active FTP · 6523ce15
      Julian Anastasov authored
      - Do not create expectation when forwarding the PORT
        command to avoid blocking the connection. The problem is that
        nf_conntrack_ftp.c:help() tries to create the same expectation later in
        POST_ROUTING and drops the packet with "dropping packet" message after
        failure in nf_ct_expect_related.
      
      - Change ip_vs_update_conntrack to alter the conntrack
        for related connections from real server. If we do not alter the reply in
        this direction the next packet from client sent to vport 20 comes as NEW
        connection. We alter it but may be some collision happens for both
        conntracks and the second conntrack gets destroyed immediately. The
        connection stucks too.
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6523ce15
    • Jarek Poplawski's avatar
      gro: Re-fix different skb headrooms · 64289c8e
      Jarek Poplawski authored
      The patch: "gro: fix different skb headrooms" in its part:
      "2) allocate a minimal skb for head of frag_list" is buggy. The copied
      skb has p->data set at the ip header at the moment, and skb_gro_offset
      is the length of ip + tcp headers. So, after the change the length of
      mac header is skipped. Later skb_set_mac_header() sets it into the
      NET_SKB_PAD area (if it's long enough) and ip header is misaligned at
      NET_SKB_PAD + NET_IP_ALIGN offset. There is no reason to assume the
      original skb was wrongly allocated, so let's copy it as it was.
      
      bugzilla : https://bugzilla.kernel.org/show_bug.cgi?id=16626
      fixes commit: 3d3be433Reported-by: default avatarPlamen Petrov <pvp-lsts@fs.uni-ruse.bg>
      Signed-off-by: default avatarJarek Poplawski <jarkao2@gmail.com>
      CC: Eric Dumazet <eric.dumazet@gmail.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Tested-by: default avatarPlamen Petrov <pvp-lsts@fs.uni-ruse.bg>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      64289c8e
  9. 07 Sep, 2010 16 commits