1. 20 4月, 2015 1 次提交
  2. 15 4月, 2015 1 次提交
  3. 16 11月, 2014 3 次提交
  4. 10 11月, 2014 1 次提交
    • T
      /dev/mem: Use more consistent data types · 4707a341
      Thierry Reding 提交于
      The xlate_dev_{kmem,mem}_ptr() functions take either a physical address
      or a kernel virtual address, so data types should be phys_addr_t and
      void *. They both return a kernel virtual address which is only ever
      used in calls to copy_{from,to}_user(), so make variables that store it
      void * rather than char * for consistency.
      
      Also only define a weak unxlate_dev_mem_ptr() function if architectures
      haven't overridden them in the asm/io.h header file.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      4707a341
  5. 14 10月, 2014 1 次提交
  6. 06 5月, 2014 1 次提交
  7. 03 5月, 2014 1 次提交
    • R
      x86, ioremap: Speed up check for RAM pages · c81c8a1e
      Roland Dreier 提交于
      In __ioremap_caller() (the guts of ioremap), we loop over the range of
      pfns being remapped and checks each one individually with page_is_ram().
      For large ioremaps, this can be very slow.  For example, we have a
      device with a 256 GiB PCI BAR, and ioremapping this BAR can take 20+
      seconds -- sometimes long enough to trigger the soft lockup detector!
      
      Internally, page_is_ram() calls walk_system_ram_range() on a single
      page.  Instead, we can make a single call to walk_system_ram_range()
      from __ioremap_caller(), and do our further checks only for any RAM
      pages that we find.  For the common case of MMIO, this saves an enormous
      amount of work, since the range being ioremapped doesn't intersect
      system RAM at all.
      
      With this change, ioremap on our 256 GiB BAR takes less than 1 second.
      Signed-off-by: NRoland Dreier <roland@purestorage.com>
      Link: http://lkml.kernel.org/r/1399054721-1331-1-git-send-email-roland@kernel.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      c81c8a1e
  8. 08 4月, 2014 2 次提交
    • M
      x86: use generic early_ioremap · 5b7c73e0
      Mark Salter 提交于
      Move x86 over to the generic early ioremap implementation.
      Signed-off-by: NMark Salter <msalter@redhat.com>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5b7c73e0
    • D
      x86/mm: sparse warning fix for early_memremap · 6b550f6f
      Dave Young 提交于
      This patch series takes the common bits from the x86 early ioremap
      implementation and creates a generic implementation which may be used by
      other architectures.  The early ioremap interfaces are intended for
      situations where boot code needs to make temporary virtual mappings
      before the normal ioremap interfaces are available.  Typically, this
      means before paging_init() has run.
      
      This patch (of 6):
      
      There's a lot of sparse warnings for code like below: void *a =
      early_memremap(phys_addr, size);
      
      early_memremap intend to map kernel memory with ioremap facility, the
      return pointer should be a kernel ram pointer instead of iomem one.
      
      For making the function clearer and supressing sparse warnings this patch
      do below two things:
      1. cast to (__force void *) for the return value of early_memremap
      2. add early_memunmap function and pass (__force void __iomem *) to iounmap
      
      From Boris:
        "Ingo told me yesterday, it makes sense too.  I'd guess we can try it.
         FWIW, all callers of early_memremap use the memory they get remapped
         as normal memory so we should be safe"
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Signed-off-by: NMark Salter <msalter@redhat.com>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6b550f6f
  9. 13 8月, 2013 1 次提交
  10. 28 6月, 2013 1 次提交
  11. 30 4月, 2013 1 次提交
    • J
      mm, vmalloc: change iterating a vmlist to find_vm_area() · ef932473
      Joonsoo Kim 提交于
      This patchset removes vm_struct list management after initializing
      vmalloc.  Adding and removing an entry to vmlist is linear time
      complexity, so it is inefficient.  If we maintain this list, overall
      time complexity of adding and removing area to vmalloc space is O(N),
      although we use rbtree for finding vacant place and it's time complexity
      is just O(logN).
      
      And vmlist and vmlist_lock is used many places of outside of vmalloc.c.
      It is preferable that we hide this raw data structure and provide
      well-defined function for supporting them, because it makes that they
      cannot mistake when manipulating theses structure and it makes us easily
      maintain vmalloc layer.
      
      For kexec and makedumpfile, I export vmap_area_list, instead of vmlist.
      This comes from Atsushi's recommendation.  For more information, please
      refer below link.  https://lkml.org/lkml/2012/12/6/184
      
      This patch:
      
      The purpose of iterating a vmlist is finding vm area with specific virtual
      address.  find_vm_area() is provided for this purpose and more efficient,
      because it uses a rbtree.  So change it.
      Signed-off-by: NJoonsoo Kim <js1304@gmail.com>
      Signed-off-by: NJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Acked-by: NGuan Xuetao <gxt@mprc.pku.edu.cn>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
      Cc: Dave Anderson <anderson@redhat.com>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef932473
  12. 16 12月, 2012 1 次提交
  13. 30 10月, 2012 1 次提交
  14. 11 6月, 2012 1 次提交
  15. 29 4月, 2011 1 次提交
  16. 14 10月, 2010 1 次提交
    • J
      xen: Cope with unmapped pages when initializing kernel pagetable · fef5ba79
      Jeremy Fitzhardinge 提交于
      Xen requires that all pages containing pagetable entries to be mapped
      read-only.  If pages used for the initial pagetable are already mapped
      then we can change the mapping to RO.  However, if they are initially
      unmapped, we need to make sure that when they are later mapped, they
      are also mapped RO.
      
      We do this by knowing that the kernel pagetable memory is pre-allocated
      in the range e820_table_start - e820_table_end, so any pfn within this
      range should be mapped read-only.  However, the pagetable setup code
      early_ioremaps the pages to write their entries, so we must make sure
      that mappings created in the early_ioremap fixmap area are mapped RW.
      (Those mappings are removed before the pages are presented to Xen
      as pagetable pages.)
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      LKML-Reference: <4CB63A80.8060702@goop.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      fef5ba79
  17. 21 7月, 2010 1 次提交
  18. 10 7月, 2010 2 次提交
  19. 30 4月, 2010 1 次提交
    • L
      x86: Fix 'reservetop=' functionality · e67a807f
      Liang Li 提交于
      When specifying the 'reservetop=0xbadc0de' kernel parameter,
      the kernel will stop booting due to a early_ioremap bug that
      relates to commit 8827247f.
      
      The root cause of boot failure problem is the value of
      'slot_virt[i]' was initialized in setup_arch->early_ioremap_init().
      But later in setup_arch, the function 'parse_early_param' will
      modify 'FIXADDR_TOP' when 'reservetop=0xbadc0de' being specified.
      
      The simplest fix might be use __fix_to_virt(idx0) to get updated
      value of 'FIXADDR_TOP' in '__early_ioremap' instead of reference
      old value from slot_virt[slot] directly.
      
      Changelog since v0:
      
      -v1: When reservetop being handled then FIXADDR_TOP get
           adjusted, Hence check prev_map then re-initialize slot_virt and
           PMD based on new FIXADDR_TOP.
      
      -v2: place fixup_early_ioremap hence call early_ioremap_init in
           reserve_top_address  to re-initialize slot_virt and
           corresponding PMD when parse_reservertop
      
      -v3: move fixup_early_ioremap out of reserve_top_address to make
           sure other clients of reserve_top_address like xen/lguest won't
           broken
      Signed-off-by: NLiang Li <liang.li@windriver.com>
      Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Wang Chen <wangchen@cn.fujitsu.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <1272621711-8683-1-git-send-email-liang.li@windriver.com>
      [ fixed three small cleanliness details in fixup_early_ioremap() ]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e67a807f
  20. 02 2月, 2010 2 次提交
  21. 30 12月, 2009 1 次提交
    • J
      x86: Lift restriction on the location of FIX_BTMAP_* · 499a5f1e
      Jan Beulich 提交于
      The early ioremap fixmap entries cover half (or for 32-bit
      non-PAE, a quarter) of a page table, yet they got
      uncondtitionally aligned so far to a 256-entry boundary. This is
      not necessary if the range of page table entries anyway falls
      into a single page table.
      
      This buys back, for (theoretically) 50% of all configurations
      (25% of all non-PAE ones), at least some of the lowmem
      necessarily lost with commit e621bd18.
      Signed-off-by: NJan Beulich <jbeulich@novell.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      LKML-Reference: <4B2BB66F0200007800026AD6@vpn.id2.novell.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      499a5f1e
  22. 10 11月, 2009 1 次提交
    • X
      x86: pat: Remove ioremap_default() · 2fb8f4e6
      Xiaotian Feng 提交于
      Commit:
      
        b6ff32d9: x86, PAT: Consolidate code in pat_x_mtrr_type() and reserve_memtype()
      
      consolidated reserve_memtype() and pat_x_mtrr_type,
      this made ioremap_default() same as ioremap_cache().
      
      Remove the redundant function and change the only caller to use
      ioremap_cache.
      Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      LKML-Reference: <1257845005-7938-1-git-send-email-dfeng@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2fb8f4e6
  23. 08 11月, 2009 1 次提交
  24. 11 9月, 2009 1 次提交
  25. 27 8月, 2009 1 次提交
  26. 11 4月, 2009 1 次提交
  27. 10 4月, 2009 2 次提交
  28. 25 3月, 2009 1 次提交
  29. 22 3月, 2009 1 次提交
  30. 13 3月, 2009 2 次提交
  31. 09 3月, 2009 2 次提交
    • J
      x86-32: make sure virt_addr_valid() returns false for fixmap addresses · 0feca851
      Jeremy Fitzhardinge 提交于
      I found that virt_addr_valid() was returning true for fixmap addresses.
      
      I'm not sure whether pfn_valid() is supposed to include this test,
      but there's no harm in being explicit.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Jiri Slaby <jirislaby@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      LKML-Reference: <49B166D6.2080505@goop.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0feca851
    • W
      x86: don't define __this_fixmap_does_not_exist() · 8827247f
      Wang Chen 提交于
      Impact: improve out-of-range fixmap index debugging
      
      Commit "1b42f516"
      defined the __this_fixmap_does_not_exist() function
      with a WARN_ON(1) in it.
      
      This causes the linker to not report an error when
      __this_fixmap_does_not_exist() is called with a
      non-constant parameter.
      
      Ingo defined __this_fixmap_does_not_exist() because he
      wanted to get virt addresses of fix memory of nest level
      by non-constant index.
      
      But we can fix this and still keep the link-time check:
      
      We can get the four slot virt addresses on link time and
      store them to array slot_virt[].
      
      Then we can then refer the slot_virt with non-constant index,
      in the ioremap-leak detection code.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      LKML-Reference: <49B2075B.4070509@cn.fujitsu.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8827247f
  32. 05 3月, 2009 1 次提交