1. 21 10月, 2008 28 次提交
  2. 20 10月, 2008 1 次提交
  3. 17 10月, 2008 2 次提交
  4. 15 10月, 2008 1 次提交
  5. 03 10月, 2008 1 次提交
    • L
      Check mapped ranges on sysfs resource files · b5ff7df3
      Linus Torvalds 提交于
      This is loosely based on a patch by Jesse Barnes to check the user-space
      PCI mappings though the sysfs interfaces.  Quoting Jesse's original
      explanation:
      
        It's fairly common for applications to map PCI resources through sysfs.
        However, with the current implementation, it's possible for an application
        to map far more than the range corresponding to the resourceN file it
        opened.  This patch plugs that hole by checking the range at mmap time,
        similar to what is done on platforms like sparc64 in their lower level
        PCI remapping routines.
      
        It was initially put together to help debug the e1000e NVRAM corruption
        problem, since we initially thought an X driver might be walking past the
        end of one of its mappings and clobbering the NVRAM.  It now looks like
        that's not the case, but doing the check is still important for obvious
        reasons.
      
      and this version of the patch differs in that it uses a helper function
      to clarify the code, and does all the checks in pages (instead of bytes)
      in order to avoid overflows when doing "<< PAGE_SHIFT" etc.
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b5ff7df3
  6. 27 9月, 2008 1 次提交
  7. 26 9月, 2008 1 次提交
    • I
      x86, pci-hotplug, calgary / rio: fix EBDA ioremap() · 15160716
      Ingo Molnar 提交于
      IO resource and ioremap debugging uncovered this ioremap() done
      by drivers/pci/hotplug/ibmphp_ebda.c:
      
      initcall pci_hotplug_init+0x0/0x41 returned 0 after 3 msecs
      calling  ibmphp_init+0x0/0x360 @ 1
      ibmphpd: IBM Hot Plug PCI Controller Driver version: 0.6
      resource map sanity check conflict: 0x9f800 0xaf5e7 0x9f800 0x9ffff reserved
      ------------[ cut here ]------------
      WARNING: at arch/x86/mm/ioremap.c:175 __ioremap_caller+0x5c/0x226()
      Pid: 1, comm: swapper Not tainted 2.6.27-rc7-tip-00914-g347b10f-dirty #36038
       [<c013a72d>] warn_on_slowpath+0x41/0x68
       [<c0156f00>] ? __lock_acquire+0x9ba/0xa7f
       [<c012158c>] ? do_flush_tlb_all+0x0/0x59
       [<c015ac31>] ? smp_call_function_mask+0x74/0x17d
       [<c012158c>] ? do_flush_tlb_all+0x0/0x59
       [<c013b228>] ? printk+0x1a/0x1c
       [<c013f302>] ? iomem_map_sanity_check+0x82/0x8c
       [<c0a773e8>] ? _read_unlock+0x22/0x25
       [<c013f302>] ? iomem_map_sanity_check+0x82/0x8c
       [<c0154e17>] ? trace_hardirqs_off+0xb/0xd
       [<c0127731>] __ioremap_caller+0x5c/0x226
       [<c0156158>] ? trace_hardirqs_on+0xb/0xd
       [<c012767d>] ? iounmap+0x9d/0xa5
       [<c01279dd>] ioremap_nocache+0x15/0x17
       [<c0403c42>] ? ioremap+0xd/0xf
       [<c0403c42>] ioremap+0xd/0xf
       [<c0f1928f>] ibmphp_access_ebda+0x60/0xa0e
       [<c0f17f64>] ibmphp_init+0xb5/0x360
       [<c0101057>] do_one_initcall+0x57/0x138
       [<c0f17eaf>] ? ibmphp_init+0x0/0x360
       [<c0156158>] ? trace_hardirqs_on+0xb/0xd
       [<c0148d75>] ? __queue_work+0x2b/0x30
       [<c0f17eaf>] ? ibmphp_init+0x0/0x360
       [<c0f015a0>] kernel_init+0x17b/0x1e2
       [<c0f01425>] ? kernel_init+0x0/0x1e2
       [<c01178b3>] kernel_thread_helper+0x7/0x10
       =======================
      ---[ end trace a7919e7f17c0a725 ]---
      initcall ibmphp_init+0x0/0x360 returned -19 after 144 msecs
      calling  zt5550_init+0x0/0x6a @ 1
      
      the problem is this code:
      
              io_mem = ioremap (ebda_seg<<4, 65000);
      
      it assumes that the EBDA is 65000 bytes. But BIOS EBDA pointers are
      at most 1K large.
      
      _if_ the Rio code truly extends upon the customary EBDA size it needs
      to iounmap() this memory and ioremap() it larger, once it knows it from
      the generic descriptors that a Rio system is around.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      15160716
  8. 17 9月, 2008 2 次提交
  9. 14 9月, 2008 1 次提交
  10. 13 9月, 2008 1 次提交
  11. 11 9月, 2008 1 次提交