1. 23 Apr, 2012 1 commit
  2. 17 Jan, 2012 1 commit
    • Nathaniel Husted's avatar
      Kernel: Audit Support For The ARM Platform · 29ef73b7
      Nathaniel Husted authored
      This patch provides functionality to audit system call events on the
      ARM platform. The implementation was based off the structure of the
      MIPS platform and information in this
      (http://lists.fedoraproject.org/pipermail/arm/2009-October/000382.html
      
      )
      mailing list thread. The required audit_syscall_exit and
      audit_syscall_entry checks were added to ptrace using the standard
      registers for system call values (r0 through r3). A thread information
      flag was added for auditing (TIF_SYSCALL_AUDIT) and a meta-flag was
      added (_TIF_SYSCALL_WORK) to simplify modifications to the syscall
      entry/exit. Now, if either the TRACE flag is set or the AUDIT flag is
      set, the syscall_trace function will be executed. The prober changes
      were made to Kconfig to allow CONFIG_AUDITSYSCALL to be enabled.
      
      Due to platform availability limitations, this patch was only tested
      on the Android platform running the modified "android-goldfish-2.6.29"
      kernel. A test compile was performed using Code Sourcery's
      cross-compilation toolset and the current linux-3.0 stable kernel. The
      changes compile without error. I'm hoping, due to the simple modifications,
      the patch is "obviously correct".
      Signed-off-by: default avatarNathaniel Husted <nhusted@gmail.com>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      29ef73b7
  3. 21 Nov, 2011 1 commit
  4. 02 Oct, 2010 1 commit
  5. 14 May, 2010 1 commit
  6. 15 Feb, 2010 1 commit
  7. 02 Sep, 2009 1 commit
  8. 15 Aug, 2009 1 commit
    • Mikael Pettersson's avatar
      ARM: 5677/1: ARM support for TIF_RESTORE_SIGMASK/pselect6/ppoll/epoll_pwait · 36984265
      Mikael Pettersson authored
      
      
      This patch adds support for TIF_RESTORE_SIGMASK to ARM's
      signal handling, which allows to hook up the pselect6, ppoll,
      and epoll_pwait syscalls on ARM.
      
      Tested here with eabi userspace and a test program with a
      deliberate race between a child's exit and the parent's
      sigprocmask/select sequence. Using sys_pselect6() instead
      of sigprocmask/select reliably prevents the race.
      
      The other arch's support for TIF_RESTORE_SIGMASK has evolved
      over time:
      
      In 2.6.16:
      - add TIF_RESTORE_SIGMASK which parallels TIF_SIGPENDING
      - test both when checking for pending signal [changed later]
      - reimplement sys_sigsuspend() to use current->saved_sigmask,
        TIF_RESTORE_SIGMASK [changed later], and -ERESTARTNOHAND;
        ditto for sys_rt_sigsuspend(), but drop private code and
        use common code via __ARCH_WANT_SYS_RT_SIGSUSPEND;
      - there are now no "extra" calls to do_signal() so its oldset
        parameter is always &current->blocked so need not be passed,
        also its return value is changed to void
      - change handle_signal() to return 0/-errno
      - change do_signal() to honor TIF_RESTORE_SIGMASK:
        + get oldset from current->saved_sigmask if TIF_RESTORE_SIGMASK
          is set
        + if handle_signal() was successful then clear TIF_RESTORE_SIGMASK
        + if no signal was delivered and TIF_RESTORE_SIGMASK is set then
          clear it and restore the sigmask
      - hook up sys_pselect6() and sys_ppoll()
      
      In 2.6.19:
      - hook up sys_epoll_pwait()
      
      In 2.6.26:
      - allow archs to override how TIF_RESTORE_SIGMASK is implemented;
        default set_restore_sigmask() sets both TIF_RESTORE_SIGMASK and
        TIF_SIGPENDING; archs need now just test TIF_SIGPENDING again
        when checking for pending signal work; some archs now implement
        TIF_RESTORE_SIGMASK as a secondary/non-atomic thread flag bit
      - call set_restore_sigmask() in sys_sigsuspend() instead of setting
        TIF_RESTORE_SIGMASK
      
      In 2.6.29-rc:
      - kill sys_pselect7() which no arch wanted
      
      So for 2.6.31-rc6/ARM this patch does the following:
      - Add TIF_RESTORE_SIGMASK. Use the generic set_restore_sigmask()
        which sets both TIF_SIGPENDING and TIF_RESTORE_SIGMASK, so
        TIF_RESTORE_SIGMASK need not claim one of the scarce low thread
        flags, and existing TIF_SIGPENDING and _TIF_WORK_MASK tests need
        not be extended for TIF_RESTORE_SIGMASK.
      - sys_sigsuspend() is reimplemented to use current->saved_sigmask
        and set_restore_sigmask(), making it identical to most other archs
      - The private code for sys_rt_sigsuspend() is removed, instead
        generic code supplies it via __ARCH_WANT_SYS_RT_SIGSUSPEND.
      - sys_sigsuspend() and sys_rt_sigsuspend() no longer need a pt_regs
        parameter, so their assembly code wrappers are removed.
      - handle_signal() is changed to return 0 on success or -errno.
      - The oldset parameter to do_signal() is now redundant and removed,
        and the return value is now also redundant and changed to void.
      - do_signal() is changed to honor TIF_RESTORE_SIGMASK:
        + get oldset from current->saved_sigmask if TIF_RESTORE_SIGMASK
          is set
        + if handle_signal() was successful then clear TIF_RESTORE_SIGMASK
        + if no signal was delivered and TIF_RESTORE_SIGMASK is set then
          clear it and restore the sigmask
      - Hook up sys_pselect6, sys_ppoll, and sys_epoll_pwait.
      Signed-off-by: default avatarMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      36984265
  9. 10 Jul, 2009 1 commit
  10. 12 Feb, 2009 2 commits
  11. 06 Sep, 2008 1 commit
  12. 02 Aug, 2008 1 commit
  13. 25 Jul, 2008 1 commit
  14. 18 Apr, 2008 1 commit
  15. 31 Jul, 2007 1 commit
  16. 20 Jul, 2007 1 commit
  17. 06 May, 2007 1 commit
  18. 13 Dec, 2006 1 commit
    • Rafael J. Wysocki's avatar
      [PATCH] PM: Fix SMP races in the freezer · 8a102eed
      Rafael J. Wysocki authored
      
      
      Currently, to tell a task that it should go to the refrigerator, we set the
      PF_FREEZE flag for it and send a fake signal to it.  Unfortunately there
      are two SMP-related problems with this approach.  First, a task running on
      another CPU may be updating its flags while the freezer attempts to set
      PF_FREEZE for it and this may leave the task's flags in an inconsistent
      state.  Second, there is a potential race between freeze_process() and
      refrigerator() in which freeze_process() running on one CPU is reading a
      task's PF_FREEZE flag while refrigerator() running on another CPU has just
      set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it.  If
      the refrigerator wins the race, freeze_process() will state that PF_FREEZE
      hasn't been set for the task and will set it unnecessarily, so the task
      will go to the refrigerator once again after it's been thawed.
      
      To solve first of these problems we need to stop using PF_FREEZE to tell
      tasks that they should go to the refrigerator.  Instead, we can introduce a
      special TIF_*** flag and use it for this purpose, since it is allowed to
      change the other tasks' TIF_*** flags and there are special calls for it.
      
      To avoid the freeze_process()-refrigerator() race we can make
      freeze_process() to always check the task's PF_FROZEN flag after it's read
      its "freeze" flag.  We should also make sure that refrigerator() will
      always reset the task's "freeze" flag after it's set PF_FROZEN for it.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8a102eed
  19. 30 Nov, 2006 1 commit
    • Paul Gortmaker's avatar
      [ARM] 3911/2: Simplify alloc_thread_info on ARM · 12221442
      Paul Gortmaker authored
      
      
      Remove ARM local cache of 4 struct thread_info.
      Can cause oops under certain circumstances.
      
      Russell indicated the original optimization was
      required on older kernels to avoid thread starvation
      on memory fragmentation, but may no longer be
      required.  I've updated the patch to 19rc4 and
      ensured no <config.h> dain-bramage slipped in this
      time (sorry about that).
      
      Original description follows:
      
      I was given some test results which pointed to an
      Oops in alloc_thread_info (happened 2x), and after
      looking at the code, I see that ARM has its own
      local cache of 4 struct thread_info. There wasn't
      any clear (to me) synchronization between the
      alloc_thread_info and the free_thread_info.
      
      I looked over the other arch, and they all simply
      allocate them on an as needed basis, so I simplified
      the ARM to do the same, based on the other arch
      (e.g. PPC) and the folks doing the testing have
      indicated that this fixed the oops.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      12221442
  20. 01 Jul, 2006 1 commit
  21. 30 Jun, 2006 1 commit
  22. 28 Jun, 2006 1 commit
  23. 12 Mar, 2006 1 commit
  24. 12 Jan, 2006 2 commits
  25. 16 Nov, 2005 1 commit
  26. 23 Jun, 2005 1 commit
    • Jesper Juhl's avatar
      [PATCH] streamline preempt_count type across archs · dcd497f9
      Jesper Juhl authored
      
      
      The preempt_count member of struct thread_info is currently either defined
      as int, unsigned int or __s32 depending on arch.  This patch makes the type
      of preempt_count an int on all archs.
      
      Having preempt_count be an unsigned type prevents the catching of
      preempt_count < 0 bugs, and using int on some archs and __s32 on others is
      not exactely "neat" - much nicer when it's just int all over.
      
      A previous version of this patch was already ACK'ed by Robert Love, and the
      only change in this version of the patch compared to the one he ACK'ed is
      that this one also makes sure the preempt_count member is consistently
      commented.
      Signed-off-by: default avatarJesper Juhl <juhl-lkml@dif.dk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      dcd497f9
  27. 05 May, 2005 1 commit
    • Russell King's avatar
      [PATCH] ARM: Fix kernel stack offset calculations · 4f7a1812
      Russell King authored
      
      
      Various places in the ARM kernel implicitly assumed that kernel
      stacks are always 8K due to hard coded constants.  Replace these
      constants with definitions.
      
      Correct the allowable range of kernel stack pointer values within
      the allocation.  Arrange for the entire kernel stack to be zeroed,
      not just the upper 4K if CONFIG_DEBUG_STACK_USAGE is set.
      Signed-off-by: default avatarRussell King <rmk@arm.linux.org.uk>
      4f7a1812
  28. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4