1. 06 2月, 2008 5 次提交
    • D
      timerfd: new timerfd API · 4d672e7a
      Davide Libenzi 提交于
      This is the new timerfd API as it is implemented by the following patch:
      
      int timerfd_create(int clockid, int flags);
      int timerfd_settime(int ufd, int flags,
      		    const struct itimerspec *utmr,
      		    struct itimerspec *otmr);
      int timerfd_gettime(int ufd, struct itimerspec *otmr);
      
      The timerfd_create() API creates an un-programmed timerfd fd.  The "clockid"
      parameter can be either CLOCK_MONOTONIC or CLOCK_REALTIME.
      
      The timerfd_settime() API give new settings by the timerfd fd, by optionally
      retrieving the previous expiration time (in case the "otmr" parameter is not
      NULL).
      
      The time value specified in "utmr" is absolute, if the TFD_TIMER_ABSTIME bit
      is set in the "flags" parameter.  Otherwise it's a relative time.
      
      The timerfd_gettime() API returns the next expiration time of the timer, or
      {0, 0} if the timerfd has not been set yet.
      
      Like the previous timerfd API implementation, read(2) and poll(2) are
      supported (with the same interface).  Here's a simple test program I used to
      exercise the new timerfd APIs:
      
      http://www.xmailserver.org/timerfd-test2.c
      
      [akpm@linux-foundation.org: coding-style cleanups]
      [akpm@linux-foundation.org: fix ia64 build]
      [akpm@linux-foundation.org: fix m68k build]
      [akpm@linux-foundation.org: fix mips build]
      [akpm@linux-foundation.org: fix alpha, arm, blackfin, cris, m68k, s390, sparc and sparc64 builds]
      [heiko.carstens@de.ibm.com: fix s390]
      [akpm@linux-foundation.org: fix powerpc build]
      [akpm@linux-foundation.org: fix sparc64 more]
      Signed-off-by: NDavide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d672e7a
    • O
      exec: rework the group exit and fix the race with kill · ed5d2cac
      Oleg Nesterov 提交于
      As Roland pointed out, we have the very old problem with exec.  de_thread()
      sets SIGNAL_GROUP_EXIT, kills other threads, changes ->group_leader and then
      clears signal->flags.  All signals (even fatal ones) sent in this window
      (which is not too small) will be lost.
      
      With this patch exec doesn't abuse SIGNAL_GROUP_EXIT.  signal_group_exit(),
      the new helper, should be used to detect exit_group() or exec() in progress.
      It can have more users, but this patch does only strictly necessary changes.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ed5d2cac
    • O
      remove handle_group_stop() in favor of do_signal_stop() · f558b7e4
      Oleg Nesterov 提交于
      Every time we set SIGNAL_GROUP_EXIT or clear SIGNAL_STOP_DEQUEUED we also
      reset ->group_stop_count.
      
      This means that the SIGNAL_GROUP_EXIT check in handle_group_stop() is not
      needed, and do_signal_stop() should check SIGNAL_STOP_DEQUEUED only when
      ->group_stop_count == 0. With these changes handle_group_stop() becomes the
      subset of do_signal_stop(), we can kill it and use do_signal_stop() instead.
      
      Also, a preparation for the next patch.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f558b7e4
    • O
      __group_complete_signal(): fix coredump with group stop race · 198466b4
      Oleg Nesterov 提交于
      When __group_complete_signal() sees sig_kernel_coredump() signal, it starts
      the group stop, but sets ->group_exit_task = t in a hope that "t" will
      actually dequeue this signal and invoke do_coredump().  However, by the
      time "t" enters get_signal_to_deliver() it is possible that the signal was
      blocked/ignored or we have another pending !SIG_KERNEL_COREDUMP_MASK signal
      which will be dequeued first.  This means the task could be stopped but not
      killed.
      
      Remove this code from __group_complete_signal().  Note also this patch
      removes the bogus signal_wake_up(t, 1).  This thread can't be
      STOPPED/TRACED, note the corresponding check in wants_signal().
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Robin Holt <holt@sgi.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      198466b4
    • A
      clone: prepare to recycle CLONE_STOPPED · bdff746a
      Andrew Morton 提交于
      Ulrich says that we never used this clone flags and that nothing should be
      using it.
      
      As we're down to only a single bit left in clone's flags argument, let's add a
      warning to check that no userspace is actually using it.  Hopefully we will
      be able to recycle it.
      
      Roland said:
      
        CLONE_STOPPED was previously used by some NTPL versions when under
        thread_db (i.e.  only when being actively debugged by gdb), but not for a
        long time now, and it never worked reliably when it was used.  Removing it
        seems fine to me.
      
      [akpm@linux-foundation.org: it looks like CLONE_DETACHED is being used]
      Cc: Ulrich Drepper <drepper@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      bdff746a
  2. 04 2月, 2008 1 次提交
  3. 03 2月, 2008 7 次提交
    • J
      kernel/: Spelling fixes · 0b0a3e7b
      Joe Perches 提交于
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      0b0a3e7b
    • P
      Remove one useless extern declaration · 06c93e87
      Pierre Peiffer 提交于
      The file exit.c contains one useless extern declaration of sem_exit().
      Moreover, it refers to nothing.
      
      This trivial patch removes it.
      Signed-off-by: NPierre Peiffer <pierre.peiffer@bull.net>
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      06c93e87
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      init/Kconfig for architecture independent options
        - profiling
        - markers
      
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      Linus:
      
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config KPROBES_SUPPORT
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096
    • M
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers 提交于
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      42d4b839
    • M
      Fix ARM to play nicely with generic Instrumentation menu · c0ffa3a9
      Mathieu Desnoyers 提交于
      The conflicting commit for
      move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch
      is the ARM fix from Linus :
      
      commit 38ad9aeb
      
      He just seemed to agree that my approach (just putting the missing ARM
      config options in arch/arm/Kconfig) works too. The main advantage it has
      is that it is smaller, does not need a cleanup in the future and does
      not break the following patches unnecessarily.
      
      It's just been discussed here
      
      http://lkml.org/lkml/2008/1/15/267
      
      However, Linus might prefer to stay with his own patch and I would
      totally understand it that late in the release cycle. Therefore I submit
      this for the next release cycle.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      CC: Russell King <rmk+lkml@arm.linux.org.uk>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      c0ffa3a9
    • P
      kobject: Always build in kernel/ksysfs.o. · dfacd68e
      Paul Mundt 提交于
      kernel/ksysfs.c seems to be a random dumping group for misc globals
      that the rest of the tree depend on. This has caused problems with
      exports in the past when sysfs is disabled, which can already be
      observed in commit-id 51107301.
      
      The latest one is the kernel_kobj usage, which presently results in:
      
      fs/built-in.o: In function `debugfs_init':
      inode.c:(.init.text+0xc34): undefined reference to `kernel_kobj'
      make: *** [.tmp_vmlinux1] Error 1
      
      kernel/ksysfs.c itself at this point only contains globals and some
      basic sysfs initialization, the sysfs initialization code is optimized
      out when we build with sysfs disabled. Given that, it's easier to just
      build in unconditionally, rather than trying to find some other random
      place to dump and initialize the globals.
      
      Additionally, the current trend seems to be decoupling of kobjects from
      sysfs, in which case it still makes sense to perform the kernel_kobj
      initialization that happens here even if sysfs is disabled, as
      lib/kobject.o is built-in unconditionally.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dfacd68e
  4. 02 2月, 2008 27 次提交