1. 25 Dec, 2008 5 commits
    • Martin Schwidefsky's avatar
      [S390] arch_setup_additional_pages arguments · fc5243d9
      Martin Schwidefsky authored
      arch_setup_additional_pages currently gets two arguments, the binary
      format descripton and an indication if the process uses an executable
      stack or not. The second argument is not used by anybody, it could
      be removed without replacement.
      
      What actually does make sense is to pass an indication if the process
      uses the elf interpreter or not. The glibc code will not use anything
      from the vdso if the process does not use the dynamic linker, so for
      statically linked binaries the architecture backend can choose not
      to map the vdso.
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      fc5243d9
    • Christian Borntraeger's avatar
      [S390] vmcp: remove BKL · a114a9d6
      Christian Borntraeger authored
      The vmcp driver uses the session->mutex for concurrent access of the data
      structures. Therefore, the BKL in vmcp_open does not protect against any
      other function in the driver.
      The BLK in vmcp_open would protect concurrent access to the module init
      but all necessary steps ave finished before misc_register is called.
      We can safely remove the lock_kernel from vcmp.
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      a114a9d6
    • Heiko Carstens's avatar
      [S390] cpu topology: dont destroy cpu sets on topology change · f414f5f1
      Heiko Carstens authored
      Call rebuild_sched_domains instead of arch_reinit_sched_domains if
      cpu topology changes. This leaves cpu sets alone which otherwise would
      be destroyed.
      If and how it makes sense to define cpu sets on a virtualized
      architecture is another question.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      f414f5f1
    • Al Viro's avatar
      [S390] audit: get s390 ret_from_fork in sync with other architectures · 8f2961c3
      Al Viro authored
      	On s390 we have ret_from_fork jump not to the "do all work we
      normally do on return from syscall" as on x86, ppc, etc., but to the
      "do all such work except audit".  Historical reasons - the codepath
      triggered when we have AUDIT process flag set is separated from the
      normall one and they converge at sysc_return, which is the common
      part of post-syscall work.  And does not include calling audit_syscall_exit() -
      that's done in the end of sysc_tracesys path, just before that path jumps
      to sysc_return.
      
      	IOW, the child returning from fork()/clone()/vfork() doesn't
      call audit_syscall_exit() at all, so no matter what we do with its
      audit context, we are not going to see the audit entry.
      
      	The fix is simple: have ret_from_fork go to the point just past
      the call of sys_.... in the 'we have AUDIT flag set' path.  There we
      have (64bit variant; for 31bit the situation is the same):
      sysc_tracenogo:
              tm      __TI_flags+7(%r9),(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT)
              jz      sysc_return
              la      %r2,SP_PTREGS(%r15)     # load pt_regs
              larl    %r14,sysc_return        # return point is sysc_return
              jg      do_syscall_trace_exit
      which is precisely what we need - check the flag, bugger off to sysc_return
      if not set, otherwise call do_syscall_trace_exit() and bugger off to
      sysc_return.  r9 has just been properly set by ret_from_fork itself,
      so we are fine.
      
      	Tested on s390x, seems to work fine.  WARNING: it's been about
      16 years since my last contact with 3X0 assembler[1], so additional
      review would be very welcome.  I don't think I've managed to screw it
      up, but...
      
      [1] that *was* in another country and besides, the box is dead...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      8f2961c3
    • Heiko Carstens's avatar
      [S390] cpu topology: fix cpu_core_map initialization · 5439050f
      Heiko Carstens authored
      Common code doesn't call arch_update_cpu_topology() anymore on
      cpu hotplug. But our architecture backend relied on that in order to
      update the cpu_core_map. For machines without cpu topology support
      this leads uninitialized cpu_core_maps for later on added cpus.
      
      To solve this just initialize the maps with cpu_possible_map, since
      that will be always valid for machines without topology support.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      5439050f
  2. 24 Dec, 2008 8 commits
  3. 23 Dec, 2008 7 commits
  4. 22 Dec, 2008 7 commits
  5. 20 Dec, 2008 4 commits
  6. 19 Dec, 2008 9 commits