Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 08 9月, 2012 1 次提交
  3. 25 8月, 2012 7 次提交
    • J
      ARM: 7499/1: mm: Fix vmalloc overlap check for !HIGHMEM · 36418c51
      由 Jonathan Austin 提交于 
      With !HIGHMEM, sanity_check_meminfo checks for banks that completely or
partially overlap the vmalloc region. The test for partial overlap checks
__va(bank->start + bank->size) > vmalloc_min. This is not appropriate if
there is a non-linear translation between virtual and physical addresses,
as bank->start + bank->size is actually in the bank following the one being
interrogated.

In most cases, even when using SPARSEMEM, this is not problematic as the
subsequent bank will start at a higher va than the one in question. However
if the physical to virtual address conversion is not monotonic increasing,
the incorrect test could result in a bank not being truncated when it
should be.

This patch ensures we perform the va-pa conversion on memory from the
bank we are interested in, not the following one.
Reported-by: N??? (Steve) <zhanzhenbo@gmail.com>
Signed-off-by: NJonathan Austin <jonathan.austin@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      36418c51
    • W
      ARM: 7503/1: mm: only flush both pmd entries for classic MMU · df547e08
      由 Will Deacon 提交于 
      LPAE does not use two pmd entries for a pte, so the additional tlb
flushing is not required.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      df547e08
    • W
      ARM: 7502/1: contextidr: avoid using bfi instruction during notifier · ae3790b8
      由 Will Deacon 提交于 
      The bfi instruction is not available on ARMv6, so instead use an and/orr
sequence in the contextidr_notifier. This gets rid of the assembler
error:

  Assembler messages:
  Error: selected processor does not support ARM mode `bfi r3,r2,#0,#8'
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ae3790b8
    • W
      ARM: 7501/1: decompressor: reset ttbcr for VMSA ARMv7 cores · dbece458
      由 Will Deacon 提交于 
      When enabling the MMU for ARMv7 CPUs, the decompressor does not touch
the ttbcr register, assuming that it will be zeroed (N == 0, EAE == 0).
Given that only EAE is defined as 0 for non-secure copies of the
register (and a bootloader such as kexec may leave it set to 1 anyway),
we should ensure that we reset the register ourselves before turning on
the MMU.

This patch zeroes TTBCR.EAE and TTBCR.N prior to enabling the MMU for
ARMv7 cores in the decompressor, configuring us exclusively for 32-bit
translation tables via TTBR0.

Cc: <stable@vger.kernel.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NMatthew Leach <matthew.leach@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      dbece458
    • W
      ARM: 7497/1: hw_breakpoint: allow single-byte watchpoints on all addresses · d968d2b8
      由 Will Deacon 提交于 
      Breakpoint validation currently fails for single-byte watchpoints on
addresses ending in 11b. There is no reason to forbid such a watchpoint,
so extend the validation code to allow it.

Cc: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d968d2b8
    • W
      ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access type · bf880114
      由 Will Deacon 提交于 
      From ARM debug architecture v7.1 onwards, a watchpoint exception causes
the DFAR to be updated with the faulting data address. However, DFSR.WnR
takes an UNKNOWN value and therefore cannot be used in general to
determine the access type that triggered the watchpoint.

This patch forbids watchpoints without an overflow handler from
specifying a specific access type (load/store). Those with overflow
handlers must be able to handle false positives potentially triggered by
a watchpoint of a different access type on the same address. For
SIGTRAP-based handlers (i.e. ptrace), this should have no impact.

Cc: <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bf880114
    • R
      ARM: Fix ioremap() of address zero · a849088a
      由 Russell King 提交于 
      Murali Nalajala reports a regression that ioremapping address zero
results in an oops dump:

Unable to handle kernel paging request at virtual address fa200000
pgd = d4f80000
[fa200000] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0    Tainted: G        W (3.4.0-g3b5f728-00009-g638207a #13)
PC is at msm_pm_config_rst_vector_before_pc+0x8/0x30
LR is at msm_pm_boot_config_before_pc+0x18/0x20
pc : [<c0078f84>]    lr : [<c007903c>]    psr: a0000093
sp : c0837ef0  ip : cfe00000  fp : 0000000d
r10: da7efc17  r9 : 225c4278  r8 : 00000006
r7 : 0003c000  r6 : c085c824  r5 : 00000001  r4 : fa101000
r3 : fa200000  r2 : c095080c  r1 : 002250fc  r0 : 00000000
Flags: NzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel
Control: 10c5387d  Table: 25180059  DAC: 00000015
[<c0078f84>] (msm_pm_config_rst_vector_before_pc+0x8/0x30) from [<c007903c>] (msm_pm_boot_config_before_pc+0x18/0x20)
[<c007903c>] (msm_pm_boot_config_before_pc+0x18/0x20) from [<c007a55c>] (msm_pm_power_collapse+0x410/0xb04)
[<c007a55c>] (msm_pm_power_collapse+0x410/0xb04) from [<c007b17c>] (arch_idle+0x294/0x3e0)
[<c007b17c>] (arch_idle+0x294/0x3e0) from [<c000eed8>] (default_idle+0x18/0x2c)
[<c000eed8>] (default_idle+0x18/0x2c) from [<c000f254>] (cpu_idle+0x90/0xe4)
[<c000f254>] (cpu_idle+0x90/0xe4) from [<c057231c>] (rest_init+0x88/0xa0)
[<c057231c>] (rest_init+0x88/0xa0) from [<c07ff890>] (start_kernel+0x3a8/0x40c)
Code: c0704256 e12fff1e e59f2020 e5923000 (e5930000)

This is caused by the 'reserved' entries which we insert (see
19b52abe - ARM: 7438/1: fill possible PMD empty section gaps)
which get matched for physical address zero.

Resolve this by marking these reserved entries with a different flag.

Cc: <stable@vger.kernel.org>
Tested-by: NMurali Nalajala <mnalajal@codeaurora.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a849088a
  5. 22 8月, 2012 1 次提交
    • M
      mm: hugetlbfs: correctly populate shared pmd · eb48c071
      由 Michal Hocko 提交于 
      Each page mapped in a process's address space must be correctly
accounted for in _mapcount.  Normally the rules for this are
straightforward but hugetlbfs page table sharing is different.  The page
table pages at the PMD level are reference counted while the mapcount
remains the same.

If this accounting is wrong, it causes bugs like this one reported by
Larry Woodman:

  kernel BUG at mm/filemap.c:135!
  invalid opcode: 0000 [#1] SMP
  CPU 22
  Modules linked in: bridge stp llc sunrpc binfmt_misc dcdbas microcode pcspkr acpi_pad acpi]
  Pid: 18001, comm: mpitest Tainted: G        W    3.3.0+ #4 Dell Inc. PowerEdge R620/07NDJ2
  RIP: 0010:[<ffffffff8112cfed>]  [<ffffffff8112cfed>] __delete_from_page_cache+0x15d/0x170
  Process mpitest (pid: 18001, threadinfo ffff880428972000, task ffff880428b5cc20)
  Call Trace:
    delete_from_page_cache+0x40/0x80
    truncate_hugepages+0x115/0x1f0
    hugetlbfs_evict_inode+0x18/0x30
    evict+0x9f/0x1b0
    iput_final+0xe3/0x1e0
    iput+0x3e/0x50
    d_kill+0xf8/0x110
    dput+0xe2/0x1b0
    __fput+0x162/0x240

During fork(), copy_hugetlb_page_range() detects if huge_pte_alloc()
shared page tables with the check dst_pte == src_pte.  The logic is if
the PMD page is the same, they must be shared.  This assumes that the
sharing is between the parent and child.  However, if the sharing is
with a different process entirely then this check fails as in this
diagram:

  parent
    |
    ------------>pmd
                 src_pte----------> data page
                                        ^
  other--------->pmd--------------------|
                  ^
  child-----------|
                 dst_pte

For this situation to occur, it must be possible for Parent and Other to
have faulted and failed to share page tables with each other.  This is
possible due to the following style of race.

  PROC A                                          PROC B
  copy_hugetlb_page_range                         copy_hugetlb_page_range
    src_pte == huge_pte_offset                      src_pte == huge_pte_offset
    !src_pte so no sharing                          !src_pte so no sharing

  (time passes)

  hugetlb_fault                                   hugetlb_fault
    huge_pte_alloc                                  huge_pte_alloc
      huge_pmd_share                                 huge_pmd_share
        LOCK(i_mmap_mutex)
        find nothing, no sharing
        UNLOCK(i_mmap_mutex)
                                                      LOCK(i_mmap_mutex)
                                                      find nothing, no sharing
                                                      UNLOCK(i_mmap_mutex)
      pmd_alloc                                       pmd_alloc
      LOCK(instantiation_mutex)
      fault
      UNLOCK(instantiation_mutex)
                                                  LOCK(instantiation_mutex)
                                                  fault
                                                  UNLOCK(instantiation_mutex)

These two processes are not poing to the same data page but are not
sharing page tables because the opportunity was missed.  When either
process later forks, the src_pte == dst pte is potentially insufficient.
As the check falls through, the wrong PTE information is copied in
(harmless but wrong) and the mapcount is bumped for a page mapped by a
shared page table leading to the BUG_ON.

This patch addresses the issue by moving pmd_alloc into huge_pmd_share
which guarantees that the shared pud is populated in the same critical
section as pmd.  This also means that huge_pte_offset test in
huge_pmd_share is serialized correctly now which in turn means that the
success of the sharing will be higher as the racing tasks see the pud
and pmd populated together.

Race identified and changelog written mostly by Mel Gorman.

{akpm@linux-foundation.org: attempt to make the huge_pmd_share() comment comprehensible, clean up coding style]
Reported-by: NLarry Woodman <lwoodman@redhat.com>
Tested-by: NLarry Woodman <lwoodman@redhat.com>
Reviewed-by: NMel Gorman <mgorman@suse.de>
Signed-off-by: NMichal Hocko <mhocko@suse.cz>
Reviewed-by: NRik van Riel <riel@redhat.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Ken Chen <kenchen@google.com>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      eb48c071
  7. 21 8月, 2012 1 次提交
  9. 19 8月, 2012 10 次提交
  11. 17 8月, 2012 2 次提交
  13. 16 8月, 2012 2 次提交
    • M
      C6X: select GENERIC_ATOMIC64 · 01ddd9a8
      由 Mark Salter 提交于 
      The generic atomic64 support came in 2009 to support the perf subsystem
with the expectation that all architectures would implement atomic64
support. Since then, other optional parts of the generic kernel have
also come to expect atomic64 support. This patch enables generic atomic64
support for C6X architecture.
Signed-off-by: NMark Salter <msalter@redhat.com>
      01ddd9a8
    • M
      C6X: add Lx_CACHE_SHIFT defines · 6330c790
      由 Mark Salter 提交于 
      C6X currently lacks Lx_CACHE_SHIFT defines which are needed in a
few places in the generic kernel. This patch adds _SHIFT defines
for the various caches and bases the Lx_CACHE_BYTES defines on
them.
Signed-off-by: NMark Salter <msalter@redhat.com>
      6330c790
  15. 15 8月, 2012 4 次提交
  17. 14 8月, 2012 4 次提交
  19. 13 8月, 2012 1 次提交
  21. 11 8月, 2012 7 次提交