1. 14 2月, 2013 17 次提交
  2. 13 2月, 2013 17 次提交
  3. 12 2月, 2013 5 次提交
    • J
      Merge branch 'master' of... · 318d86db
      John W. Linville 提交于
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      318d86db
    • J
      drm/radeon: enforce use of radeon_get_ib_value when reading user cmd · de0babd6
      Jerome Glisse 提交于
      When ever parsing cmd buffer supplied by userspace we need to use
      radeon_get_ib_value rather than directly accessing the ib as the user
      cmd might not yet be copied into the ib thus the parser might read
      value that does not correspond to what user is sending and possibly
      allowing user to send malicious command undected.
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      de0babd6
    • J
      mwl8k: fix band for supported channels · d786f67e
      Jonas Gorski 提交于
      The band field for the supported channels were left unpopulated, making
      them default to 0 == IEEE80211_BAND_2GHZ, even for the 5GHz channels.
      
      This resulted in null pointer accesses if anything tries to access
      wiphy->bands[channel->band] of a 5GHz channel on 5GHz only cards, since
      wiphy->bands[2GHZ] is NULL for them (e.g. cfg80211_chandef_usable does).
      
      Example kernel OOPS:
      
      [  665.669993] Unable to handle kernel NULL pointer dereference at virtual address 00000016
      [  665.678194] pgd = c6d58000
      [  665.680941] [00000016] *pgd=06f8a831, *pte=00000000, *ppte=00000000
      [  665.687303] Internal error: Oops: 17 [#1]
      (...)
      [  666.116373] Backtrace:
      [  666.118866] [<bf0368dc>] (cfg80211_chandef_usable+0x0/0x1bc [cfg80211]) from [<bf025e64>] (nl80211_leave_mesh+0x244/0x264 [cfg80211])
      [  666.130919]  r7:c6d12100 r6:0000143c r5:c0611c48 r4:c0611b98
      [  666.136668] [<bf025d84>] (nl80211_leave_mesh+0x164/0x264 [cfg80211]) from [<bf02634c>] (nl80211_remain_on_channel+0x2a0/0x358 [cfg80211])
      [  666.149074]  r7:c6d12000 r6:c6d12000 r5:c6f4f368 r4:00000003
      [  666.154814] [<bf0262ec>] (nl80211_remain_on_channel+0x240/0x358 [cfg80211]) from [<bf02ddb0>] (nl80211_set_wiphy+0x264/0x560 [cfg80211])
      [  666.167150] [<bf02db4c>] (nl80211_set_wiphy+0x0/0x560 [cfg80211]) from [<c01f94e0>] (genl_rcv_msg+0x1b8/0x1f8)
      [  666.177205] [<c01f9328>] (genl_rcv_msg+0x0/0x1f8) from [<c01f89a0>] (netlink_rcv_skb+0x58/0xb4)
      [  666.185949] [<c01f8948>] (netlink_rcv_skb+0x0/0xb4) from [<c01f931c>] (genl_rcv+0x20/0x2c)
      [  666.194251]  r6:c6f70780 r5:0000002c r4:c6f70780 r3:00000001
      [  666.199973] [<c01f92fc>] (genl_rcv+0x0/0x2c) from [<c01f8418>] (netlink_unicast+0x154/0x1f4)
      [  666.208449]  r4:c785ea00 r3:c01f92fc
      [  666.212057] [<c01f82c4>] (netlink_unicast+0x0/0x1f4) from [<c01f8790>] (netlink_sendmsg+0x230/0x2b0)
      [  666.221240] [<c01f8560>] (netlink_sendmsg+0x0/0x2b0) from [<c01cccf8>] (sock_sendmsg+0x90/0xa4)
      [  666.229986] [<c01ccc68>] (sock_sendmsg+0x0/0xa4) from [<c01cdcb0>] (__sys_sendmsg+0x290/0x298)
      [  666.238637]  r9:00000000 r8:c0611ec8 r6:0000002c r5:c0610000 r4:c0611f64
      [  666.245411] [<c01cda20>] (__sys_sendmsg+0x0/0x298) from [<c01cf52c>] (sys_sendmsg+0x44/0x6c)
      [  666.253897] [<c01cf4e8>] (sys_sendmsg+0x0/0x6c) from [<c00090a0>] (ret_fast_syscall+0x0/0x2c)
      [  666.262460]  r6:00000000 r5:beeff96c r4:00000005
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d786f67e
    • J
    • S
      bridge: set priority of STP packets · 547b4e71
      Stephen Hemminger 提交于
      Spanning Tree Protocol packets should have always been marked as
      control packets, this causes them to get queued in the high prirority
      FIFO. As Radia Perlman mentioned in her LCA talk, STP dies if bridge
      gets overloaded and can't communicate. This is a long-standing bug back
      to the first versions of Linux bridge.
      Signed-off-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      547b4e71
  4. 11 2月, 2013 1 次提交
    • S
      x86/apic: Work around boot failure on HP ProLiant DL980 G7 Server systems · cb214ede
      Stoney Wang 提交于
      When a HP ProLiant DL980 G7 Server boots a regular kernel,
      there will be intermittent lost interrupts which could
      result in a hang or (in extreme cases) data loss.
      
      The reason is that this system only supports x2apic physical
      mode, while the kernel boots with a logical-cluster default
      setting.
      
      This bug can be worked around by specifying the "x2apic_phys" or
      "nox2apic" boot option, but we want to handle this system
      without requiring manual workarounds.
      
      The BIOS sets ACPI_FADT_APIC_PHYSICAL in FADT table.
      As all apicids are smaller than 255, BIOS need to pass the
      control to the OS with xapic mode, according to x2apic-spec,
      chapter 2.9.
      
      Current code handle x2apic when BIOS pass with xapic mode
      enabled:
      
      When user specifies x2apic_phys, or FADT indicates PHYSICAL:
      
      1. During madt oem check, apic driver is set with xapic logical
         or xapic phys driver at first.
      
      2. enable_IR_x2apic() will enable x2apic_mode.
      
      3. if user specifies x2apic_phys on the boot line, x2apic_phys_probe()
         will install the correct x2apic phys driver and use x2apic phys mode.
         Otherwise it will skip the driver will let x2apic_cluster_probe to
         take over to install x2apic cluster driver (wrong one) even though FADT
         indicates PHYSICAL, because x2apic_phys_probe does not check
         FADT PHYSICAL.
      
      Add checking x2apic_fadt_phys in x2apic_phys_probe() to fix the
      problem.
      Signed-off-by: NStoney Wang <song-bo.wang@hp.com>
      [ updated the changelog and simplified the code ]
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Cc: stable@kernel.org
      Link: http://lkml.kernel.org/r/1360263182-16226-1-git-send-email-yinghai@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      cb214ede