Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 06 2月, 2007 4 次提交
    • G
      [S390] noexec protection · c1821c2e
      由 Gerald Schaefer 提交于 
      This provides a noexec protection on s390 hardware. Our hardware does
not have any bits left in the pte for a hw noexec bit, so this is a
different approach using shadow page tables and a special addressing
mode that allows separate address spaces for code and data.

As a special feature of our "secondary-space" addressing mode, separate
page tables can be specified for the translation of data addresses
(storage operands) and instruction addresses. The shadow page table is
used for the instruction addresses and the standard page table for the
data addresses.
The shadow page table is linked to the standard page table by a pointer
in page->lru.next of the struct page corresponding to the page that
contains the standard page table (since page->private is not really
private with the pte_lock and the page table pages are not in the LRU
list).
Depending on the software bits of a pte, it is either inserted into
both page tables or just into the standard (data) page table. Pages of
a vma that does not have the VM_EXEC bit set get mapped only in the
data address space. Any try to execute code on such a page will cause a
page translation exception. The standard reaction to this is a SIGSEGV
with two exceptions: the two system call opcodes 0x0a77 (sys_sigreturn)
and 0x0aad (sys_rt_sigreturn) are allowed. They are stored by the
kernel to the signal stack frame. Unfortunately, the signal return
mechanism cannot be modified to use an SA_RESTORER because the
exception unwinding code depends on the system call opcode stored
behind the signal stack frame.

This feature requires that user space is executed in secondary-space
mode and the kernel in home-space mode, which means that the addressing
modes need to be switched and that the noexec protection only works
for user space.
After switching the addressing modes, we cannot use the mvcp/mvcs
instructions anymore to copy between kernel and user space. A new
mvcos instruction has been added to the z9 EC/BC hardware which allows
to copy between arbitrary address spaces, but on older hardware the
page tables need to be walked manually.
Signed-off-by: NGerald Schaefer <geraldsc@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c1821c2e
    • G
      [S390] Show loaded DCSS segments under /proc/iomem. · 444f0e54
      由 Gerald Schaefer 提交于 
      Currently loaded DCSS segments are now listed in /proc/iomem with
their name followed by a trailing "(DCSS)".
Signed-off-by: NGerald Schaefer <geraldsc@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      444f0e54
    • H
      [S390] Remove pointless/unreliable kernel messages. · 60383201
      由 Heiko Carstens 提交于 
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      60383201
    • H
      [S390] Get rid of a lot of sparse warnings. · 2b67fc46
      由 Heiko Carstens 提交于 
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2b67fc46
  3. 12 1月, 2007 1 次提交
  5. 09 12月, 2006 1 次提交
  7. 08 12月, 2006 3 次提交
    • H
      [S390] Poison init section before freeing it. · 028d9b3c
      由 Heiko Carstens 提交于 
      The data patterns should allow us to easily tell if somebody accesses
initdata/code after it was freed. Same code as on various other
architectures.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      028d9b3c
    • H
      [S390] Use add_active_range() and free_area_init_nodes(). · 39b742f9
      由 Heiko Carstens 提交于 
      Size zones and holes in an architecture independent manner for s390.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      39b742f9
    • H
      [S390] Virtual memmap for s390. · f4eb07c1
      由 Heiko Carstens 提交于 
      Virtual memmap support for s390. Inspired by the ia64 implementation.

Unlike ia64 we need a mechanism which allows us to dynamically attach
shared memory regions.
These memory regions are accessed via the dcss device driver. dcss
implements the 'direct_access' operation, which requires struct pages
for every single shared page.
Therefore this implementation provides an interface to attach/detach
shared memory:

int add_shared_memory(unsigned long start, unsigned long size);
int remove_shared_memory(unsigned long start, unsigned long size);

The purpose of the add_shared_memory function is to add the given
memory range to the 1:1 mapping and to make sure that the
corresponding range in the vmemmap is backed with physical pages.
It also initialises the new struct pages.

remove_shared_memory in turn only invalidates the page table
entries in the 1:1 mapping. The page tables and the memory used for
struct pages in the vmemmap are currently not freed. They will be
reused when the next segment will be attached.
Given that the maximum size of a shared memory region is 2GB and
in addition all regions must reside below 2GB this is not too much of
a restriction, but there is room for improvement.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f4eb07c1
  9. 04 12月, 2006 4 次提交
  11. 06 11月, 2006 1 次提交
    • H
      [S390] revert add_active_range() usage patch. · bcc8bcb1
      由 Heiko Carstens 提交于 
      Commit 7676bef9 breaks DCSS support on
s390. DCSS needs initialized struct pages to work. With the usage of
add_active_range() only the struct pages for physically present pages
are initialized.
This could be fixed if the DCSS driver would initiliaze the struct pages
itself, but this doesn't work too. This is because the mem_map array
does not include holes after the last present memory area and therefore
there is nothing that could be initialized.
To fix this and to avoid some dirty hacks revert this patch for now.
Will be added later when we move to a virtual mem_map.

Cc: Carsten Otte <cotte@de.ibm.com>
Cc: Adrian Bunk <bunk@stusta.de>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      bcc8bcb1
  13. 06 10月, 2006 1 次提交
  15. 05 10月, 2006 2 次提交
  17. 30 9月, 2006 1 次提交
  19. 28 9月, 2006 2 次提交
  21. 26 9月, 2006 2 次提交
  23. 20 9月, 2006 3 次提交
  25. 16 8月, 2006 1 次提交
  27. 12 7月, 2006 1 次提交
  29. 02 7月, 2006 1 次提交
  31. 01 7月, 2006 1 次提交
  33. 28 4月, 2006 1 次提交
  35. 24 3月, 2006 1 次提交
  37. 22 3月, 2006 1 次提交
  39. 08 2月, 2006 1 次提交
  41. 07 1月, 2006 1 次提交
  43. 09 11月, 2005 1 次提交
  45. 07 11月, 2005 2 次提交
  47. 30 10月, 2005 1 次提交
    • H
      [PATCH] mm: init_mm without ptlock · 872fec16
      由 Hugh Dickins 提交于 
      First step in pushing down the page_table_lock.  init_mm.page_table_lock has
been used throughout the architectures (usually for ioremap): not to serialize
kernel address space allocation (that's usually vmlist_lock), but because
pud_alloc,pmd_alloc,pte_alloc_kernel expect caller holds it.

Reverse that: don't lock or unlock init_mm.page_table_lock in any of the
architectures; instead rely on pud_alloc,pmd_alloc,pte_alloc_kernel to take
and drop it when allocating a new one, to check lest a racing task already
did.  Similarly no page_table_lock in vmalloc's map_vm_area.

Some temporary ugliness in __pud_alloc and __pmd_alloc: since they also handle
user mms, which are converted only by a later patch, for now they have to lock
differently according to whether or not it's init_mm.

If sources get muddled, there's a danger that an arch source taking
init_mm.page_table_lock will be mixed with common source also taking it (or
neither take it).  So break the rules and make another change, which should
break the build for such a mismatch: remove the redundant mm arg from
pte_alloc_kernel (ppc64 scrapped its distinct ioremap_mm in 2.6.13).

Exceptions: arm26 used pte_alloc_kernel on user mm, now pte_alloc_map; ia64
used pte_alloc_map on init_mm, now pte_alloc_kernel; parisc had bad args to
pmd_alloc and pte_alloc_kernel in unused USE_HPPA_IOREMAP code; ppc64
map_io_page forgot to unlock on failure; ppc mmu_mapin_ram and ppc64 im_free
took page_table_lock for no good reason.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      872fec16
  49. 05 9月, 2005 1 次提交
    • M
      [PATCH] s390: pfault interrupt race · b6d09449
      由 Martin Schwidefsky 提交于 
      There is a race in pfault_interrupt.  That function gets called two times for
each pfault notification.  Once with a subcode of 0 to indicate that a real
page is not available and once with a subcode of 0x80 to indicate that the
page is present again.

Since the two external interrupts can be delivered on two different cpus the
order in which the two calls are made is unpredictable.  It is possible that
the subcode 0x80 interrupt is completed before the subcode 0x00 interrupt has
done the wake_up() call.

To avoid calling wake_up() on an already removed task structure proper task
structure reference counting is needed.  Increase the reference counter in the
subcode 0x00 interrupt before setting pfault_wait to zero and return the
reference after the wake_up call.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b6d09449
  51. 26 6月, 2005 1 次提交