Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 23 1月, 2014 2 次提交
  3. 30 10月, 2013 1 次提交
  5. 18 9月, 2013 1 次提交
  7. 15 7月, 2013 1 次提交
    • P
      MIPS: Delete __cpuinit/__CPUINIT usage from MIPS code · 078a55fc
      由 Paul Gortmaker 提交于 
      commit 3747069b25e419f6b51395f48127e9812abc3596 upstream.

The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications.  For example, the fix in
commit 5e427ec2 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.

After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out.  Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.

Note that some harmless section mismatch warnings may result, since
notify_cpu_starting() and cpu_up() are arch independent (kernel/cpu.c)
and are flagged as __cpuinit  -- so if we remove the __cpuinit from
the arch specific callers, we will also get section mismatch warnings.
As an intermediate step, we intend to turn the linux/init.h cpuinit
related content into no-ops as early as possible, since that will get
rid of these warnings.  In any case, they are temporary and harmless.

Here, we remove all the MIPS __cpuinit from C code and __CPUINIT
from asm files.  MIPS is interesting in this respect, because there
are also uasm users hiding behind their own renamed versions of the
__cpuinit macros.

[1] https://lkml.org/lkml/2013/5/20/589

[ralf@linux-mips.org: Folded in Paul's followup fix.]
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5494/
Patchwork: https://patchwork.linux-mips.org/patch/5495/
Patchwork: https://patchwork.linux-mips.org/patch/5509/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      078a55fc
  9. 17 5月, 2013 1 次提交
  11. 08 5月, 2013 2 次提交
  13. 01 2月, 2013 1 次提交
  15. 12 12月, 2012 2 次提交
  17. 04 12月, 2012 1 次提交
    • D
      MIPS: Avoid mcheck by flushing page range in huge_ptep_set_access_flags() · ac53c4fc
      由 David Daney 提交于 
      Problem:

1) Huge page mapping of anonymous memory is initially invalid.  Will be
   faulted in by copy-on-write mechanism.

2) Userspace attempts store at the end of the huge mapping.

3) TLB Refill exception handler fill TLB with a normal (4K sized)
   invalid page at the end of the huge mapping virtual address range.

4) Userspace restarted, and re-attempts the store at the end of the
   huge mapping.

5) Page from #3 is invalid, we get a fault and go to the hugepage
   fault handler.  This tries to map a huge page and calls
   huge_ptep_set_access_flags() to install the mapping.

6) We just call the generic ptep_set_access_flags() to set up the page
   tables, but the flush there assumes a normal (4K sized) page and
   only tries to flush the first part of the huge page virtual address
   out of the TLB, since the existing entry from step #3 doesn't
   conflict, nothing is flushed.

7) We attempt to load the mapping into the TLB, but because it
   conflicts with the entry from step #3, we get a Machine Check
   exception.

The fix: Flush the entire rage covered by the huge page in
huge_ptep_set_access_flags(), and remove the optimization in
local_flush_tlb_range() so that the flush actually does the correct
thing.
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: Hillf Danton <dhillf@gmail.com>
Patchwork: https://patchwork.linux-mips.org/patch/4661/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
(cherry picked from commit dd617f258cc39d36be26afee9912624a2d23112c)
      ac53c4fc
  19. 17 10月, 2012 1 次提交
  21. 14 9月, 2012 1 次提交
  23. 29 3月, 2012 1 次提交
  25. 11 1月, 2012 2 次提交
  27. 08 12月, 2011 1 次提交
  29. 25 10月, 2011 1 次提交
  31. 06 4月, 2011 1 次提交
  33. 27 2月, 2010 3 次提交
  35. 18 9月, 2009 1 次提交
  37. 25 6月, 2009 1 次提交
  39. 17 6月, 2009 1 次提交
    • D
      MIPS: TLB support for hugetlbfs. · fd062c84
      由 David Daney 提交于 
      The TLB handlers need to check for huge pages and give them special
handling.  Huge pages consist of two contiguous sub-pages of physical
memory.

* Loading entrylo0 and entrylo1 need to be handled specially.

* The page mask must be set for huge pages and then restored after
  writing the TLB entries.

* The PTE for huge pages resides in the PMD, we halt traversal of the
  tables there.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      fd062c84
  41. 21 5月, 2009 1 次提交
    • G
      MIPS: 64-bit: Fix system lockup. · a5e696e5
      由 Greg Ungerer 提交于 
      The address range size calculation inside local_flush_tlb_kernel_range()
is being truncated by a too small size variable holder on 64-bit systems.
The truncated size can result in an erroneous tlbsize check that means we
sit spinning inside a loop trying to flush a hige number of TLB entries.
This is for all intents and purposes a system hang. Fix by using an
appropriately sized valiable to hold the size.

[Ralf: Greg's original patch submission identified the issue and fixed one
instance in tlb-r4k.c but there there were several more.  For consistency
I also modified tlb-r3k.c even though that file is only used on 32-bit.]
Signed-off-by: NGreg Ungerer <gerg@snapgear.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a5e696e5
  43. 11 1月, 2009 1 次提交
  45. 29 4月, 2008 1 次提交
  47. 12 3月, 2008 2 次提交
  49. 12 10月, 2007 1 次提交
  51. 11 7月, 2007 1 次提交
  53. 19 1月, 2007 1 次提交
  55. 27 9月, 2006 1 次提交
  57. 01 7月, 2006 1 次提交
  59. 20 6月, 2006 1 次提交
  61. 19 4月, 2006 1 次提交
  63. 21 3月, 2006 1 次提交
  65. 30 10月, 2005 1 次提交