1. 15 7月, 2011 18 次提交
  2. 14 7月, 2011 6 次提交
  3. 13 7月, 2011 2 次提交
    • T
      x86, numa: Implement pfn -> nid mapping granularity check · 1e01979c
      Tejun Heo 提交于
      SPARSEMEM w/o VMEMMAP and DISCONTIGMEM, both used only on 32bit, use
      sections array to map pfn to nid which is limited in granularity.  If
      NUMA nodes are laid out such that the mapping cannot be accurate, boot
      will fail triggering BUG_ON() in mminit_verify_page_links().
      
      On 32bit, it's 512MiB w/ PAE and SPARSEMEM.  This seems to have been
      granular enough until commit 2706a0bf (x86, NUMA: Enable
      CONFIG_AMD_NUMA on 32bit too).  Apparently, there is a machine which
      aligns NUMA nodes to 128MiB and has only AMD NUMA but not SRAT.  This
      led to the following BUG_ON().
      
       On node 0 totalpages: 2096615
         DMA zone: 32 pages used for memmap
         DMA zone: 0 pages reserved
         DMA zone: 3927 pages, LIFO batch:0
         Normal zone: 1740 pages used for memmap
         Normal zone: 220978 pages, LIFO batch:31
         HighMem zone: 16405 pages used for memmap
         HighMem zone: 1853533 pages, LIFO batch:31
       BUG: Int 6: CR2   (null)
            EDI   (null)  ESI 00000002  EBP 00000002  ESP c1543ecc
            EBX f2400000  EDX 00000006  ECX   (null)  EAX 00000001
            err   (null)  EIP c16209aa   CS 00000060  flg 00010002
       Stack: f2400000 00220000 f7200800 c1620613 00220000 01000000 04400000 00238000
                (null) f7200000 00000002 f7200b58 f7200800 c1620929 000375fe   (null)
              f7200b80 c16395f0 00200a02 f7200a80   (null) 000375fe 00000002   (null)
       Pid: 0, comm: swapper Not tainted 2.6.39-rc5-00181-g2706a0bf #17
       Call Trace:
        [<c136b1e5>] ? early_fault+0x2e/0x2e
        [<c16209aa>] ? mminit_verify_page_links+0x12/0x42
        [<c1620613>] ? memmap_init_zone+0xaf/0x10c
        [<c1620929>] ? free_area_init_node+0x2b9/0x2e3
        [<c1607e99>] ? free_area_init_nodes+0x3f2/0x451
        [<c1601d80>] ? paging_init+0x112/0x118
        [<c15f578d>] ? setup_arch+0x791/0x82f
        [<c15f43d9>] ? start_kernel+0x6a/0x257
      
      This patch implements node_map_pfn_alignment() which determines
      maximum internode alignment and update numa_register_memblks() to
      reject NUMA configuration if alignment exceeds the pfn -> nid mapping
      granularity of the memory model as determined by PAGES_PER_SECTION.
      
      This makes the problematic machine boot w/ flatmem by rejecting the
      NUMA config and provides protection against crazy NUMA configurations.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/20110712074534.GB2872@htj.dyndns.org
      LKML-Reference: <20110628174613.GP478@escobedo.osrc.amd.com>
      Reported-and-Tested-by: NHans Rosenfeld <hans.rosenfeld@amd.com>
      Cc: Conny Seidel <conny.seidel@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      1e01979c
    • T
      x86, mm: s/PAGES_PER_ELEMENT/PAGES_PER_SECTION/ · d0ead157
      Tejun Heo 提交于
      DISCONTIGMEM on x86-32 implements pfn -> nid mapping similarly to
      SPARSEMEM; however, it calls each mapping unit ELEMENT instead of
      SECTION.  This patch renames it to SECTION so that PAGES_PER_SECTION
      is valid for both DISCONTIGMEM and SPARSEMEM.  This will be used by
      the next patch to implement mapping granularity check.
      
      This patch is trivial constant rename.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Link: http://lkml.kernel.org/r/20110712074422.GA2872@htj.dyndns.org
      Cc: Hans Rosenfeld <hans.rosenfeld@amd.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      d0ead157
  4. 12 7月, 2011 11 次提交
  5. 11 7月, 2011 3 次提交
    • E
      hp-wmi: fix use after free · 0401846c
      Eric Dumazet 提交于
      [  191.310008] WARNING: kmemcheck: Caught 32-bit read from freed memory (f0d25f14)
      [  191.310011] c056d2f088000000105fd2f00000000050415353040000000000000000000000
      [  191.310020]  i i i i f f f f f f f f f f f f f f f f f f f f f f f f f f f f
      [  191.310027]                                          ^
      [  191.310029]
      [  191.310032] Pid: 737, comm: modprobe Not tainted 3.0.0-rc5+ #268 Hewlett-Packard HP Compaq 6005 Pro SFF PC/3047h
      [  191.310036] EIP: 0060:[<f80b3104>] EFLAGS: 00010286 CPU: 0
      [  191.310039] EIP is at hp_wmi_perform_query+0x104/0x150 [hp_wmi]
      [  191.310041] EAX: f0d25601 EBX: f0d25f00 ECX: 000121cf EDX: 000121ce
      [  191.310043] ESI: f0d25f10 EDI: f0f97ea8 EBP: f0f97ec4 ESP: c173f34c
      [  191.310045]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  191.310046] CR0: 8005003b CR2: f540c000 CR3: 30f30000 CR4: 000006d0
      [  191.310048] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [  191.310050] DR6: ffff4ff0 DR7: 00000400
      [  191.310051]  [<f80b317b>] hp_wmi_dock_state+0x2b/0x40 [hp_wmi]
      [  191.310054]  [<f80b6093>] hp_wmi_init+0x93/0x1a8 [hp_wmi]
      [  191.310057]  [<c10011f0>] do_one_initcall+0x30/0x170
      [  191.310061]  [<c107ab9f>] sys_init_module+0xef/0x1a60
      [  191.310064]  [<c149f998>] sysenter_do_call+0x12/0x28
      [  191.310067]  [<ffffffff>] 0xffffffff
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      0401846c
    • J
      dell-laptop - using buffer without mutex_lock · b486742a
      Jose Alonso 提交于
      Using buffer->output[1] without mutex_lock()
      Signed-off-by: NJose Alonso <joalonsof@gmail.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      b486742a
    • K
      Revert: "dell-laptop: Toggle the unsupported hardware killswitch" · be65dde8
      Keng-Yu Lin 提交于
      This reverts commit a3d77411,
      
      as it causes a mess in the wireless rfkill status on some models.
      It is probably a bad idea to toggle the rfkill for all dell models
      without the respect to the claim that it is hardware-controlled.
      
      Cc: stable@kernel.org
      Signed-off-by: NKeng-Yu Lin <kengyu@canonical.com>
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      be65dde8