1. 08 May, 2007 1 commit
    • Christoph Hellwig's avatar
      move die notifier handling to common code · 1eeb66a1
      Christoph Hellwig authored
      
      
      This patch moves the die notifier handling to common code.  Previous
      various architectures had exactly the same code for it.  Note that the new
      code is compiled unconditionally, this should be understood as an appel to
      the other architecture maintainer to implement support for it aswell (aka
      sprinkling a notify_die or two in the proper place)
      
      arm had a notifiy_die that did something totally different, I renamed it to
      arm_notify_die as part of the patch and made it static to the file it's
      declared and used at.  avr32 used to pass slightly less information through
      this interface and I brought it into line with the other architectures.
      
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: fix vmalloc_sync_all bustage]
      [bryan.wu@analog.com: fix vmalloc_sync_all in nommu]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: default avatarBryan Wu <bryan.wu@analog.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      1eeb66a1
  2. 13 Feb, 2007 2 commits
  3. 07 Dec, 2006 1 commit
    • Masami Hiramatsu's avatar
      [PATCH] kprobes: enable booster on the preemptible kernel · b4c6c34a
      Masami Hiramatsu authored
      
      
      When we are unregistering a kprobe-booster, we can't release its
      instruction buffer immediately on the preemptive kernel, because some
      processes might be preempted on the buffer.  The freeze_processes() and
      thaw_processes() functions can clean most of processes up from the buffer.
      There are still some non-frozen threads who have the PF_NOFREEZE flag.  If
      those threads are sleeping (not preempted) at the known place outside the
      buffer, we can ensure safety of freeing.
      
      However, the processing of this check routine takes a long time.  So, this
      patch introduces the garbage collection mechanism of insn_slot.  It also
      introduces the "dirty" flag to free_insn_slot because of efficiency.
      
      The "clean" instruction slots (dirty flag is cleared) are released
      immediately.  But the "dirty" slots which are used by boosted kprobes, are
      marked as garbages.  collect_garbage_slots() will be invoked to release
      "dirty" slots if there are more than INSNS_PER_PAGE garbage slots or if
      there are no unused slots.
      
      Cc: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: "bibo,mao" <bibo.mao@intel.com>
      Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
      Cc: Yumiko Sugita <yumiko.sugita.yf@hitachi.com>
      Cc: Satoshi Oshima <soshima@redhat.com>
      Cc: Hideo Aoki <haoki@redhat.com>
      Signed-off-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b4c6c34a
  4. 09 Nov, 2006 1 commit
  5. 02 Oct, 2006 2 commits
  6. 31 Jul, 2006 1 commit
  7. 30 Jun, 2006 1 commit
  8. 26 Jun, 2006 2 commits
    • mao, bibo's avatar
      [PATCH] Kprobe: multi kprobe posthandler for booster · 36721656
      mao, bibo authored
      
      
      If there are multi kprobes on the same probepoint, there will be one extra
      aggr_kprobe on the head of kprobe list.  The aggr_kprobe has
      aggr_post_handler/aggr_break_handler whether the other kprobe
      post_hander/break_handler is NULL or not.  This patch modifies this, only
      when there is one or more kprobe in the list whose post_handler is not
      NULL, post_handler of aggr_kprobe will be set as aggr_post_handler.
      
      [soshima@redhat.com: !CONFIG_PREEMPT fix]
      Signed-off-by: default avatarbibo, mao <bibo.mao@intel.com>
      Cc: Masami Hiramatsu <hiramatu@sdl.hitachi.co.jp>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>
      Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Yumiko Sugita <sugita@sdl.hitachi.co.jp>
      Cc: Hideo Aoki <haoki@redhat.com>
      Signed-off-by: default avatarSatoshi Oshima <soshima@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      36721656
    • Masami Hiramatsu's avatar
      [PATCH] kprobe: boost 2byte-opcodes on i386 · 585deaca
      Masami Hiramatsu authored
      
      
      Previous kprobe-booster patch has not handled any 2byte opcodes and
      prefixes.  I checked whole IA32 opcode map and classified it.
      
      This patch enables kprobe to boost those 2byte opcodes and prefixes.
      Signed-off-by: default avatarMasami Hiramatsu <hiramatu@sdl.hitachi.co.jp>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>
      Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Yumiko Sugita <sugita@sdl.hitachi.co.jp>
      Cc: Satoshi Oshima <soshima@redhat.com>
      Cc: Hideo Aoki <haoki@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      585deaca
  9. 23 Jun, 2006 1 commit
  10. 28 Apr, 2006 2 commits
  11. 19 Apr, 2006 1 commit
  12. 26 Mar, 2006 5 commits
    • Prasanna S Panchamukhi's avatar
      [PATCH] kprobes: fix broken fault handling for i386 · b4026513
      Prasanna S Panchamukhi authored
      
      
      Provide proper kprobes fault handling, if a user-specified pre/post handlers
      tries to access user address space, through copy_from_user(), get_user() etc.
      
      The user-specified fault handler gets called only if the fault occurs while
      executing user-specified handlers.  In such a case user-specified handler is
      allowed to fix it first, later if the user-specifed fault handler does not fix
      it, we try to fix it by calling fix_exception().
      
      The user-specified handler will not be called if the fault happens when single
      stepping the original instruction, instead we reset the current probe and
      allow the system page fault handler to fix it up.
      Signed-off-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b4026513
    • bibo,mao's avatar
      [PATCH] kprobe handler: discard user space trap · 2326c770
      bibo,mao authored
      
      
      Currently kprobe handler traps only happen in kernel space, so function
      kprobe_exceptions_notify should skip traps which happen in user space.
      This patch modifies this, and it is based on 2.6.16-rc4.
      Signed-off-by: default avatarbibo mao <bibo.mao@intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: "Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>
      Cc: <hiramatu@sdl.hitachi.co.jp>
      Signed-off-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      2326c770
    • Masami Hiramatsu's avatar
      [PATCH] kretprobe: kretprobe-booster · c9becf58
      Masami Hiramatsu authored
      
      
      In normal operation, kretprobe makes a target function return to trampoline
      code.  A kprobe (called trampoline_probe) has been inserted in the trampoline
      code.  When the kernel hits this kprobe, it calls kretprobe's handler and it
      returns to the original return address.
      
      Kretprobe-booster removes the trampoline_probe.  It allows the trampoline code
      to call kretprobe's handler directly instead of invoking kprobe.  The
      trampoline code returns to the original return address.
      
      (changelog from Chuck Ebbert <76306.1226@compuserve.com> - thanks ;))
      Signed-off-by: default avatarMasami Hiramatsu <hiramatu@sdl.hitachi.co.jp>
      Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Chuck Ebbert <76306.1226@compuserve.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c9becf58
    • Masami Hiramatsu's avatar
      [PATCH] x86: kprobes-booster · 311ac88f
      Masami Hiramatsu authored
      
      
      Current kprobe copies the original instruction at the probe point and replaces
      it with a breakpoint instruction (int3).  When the kernel hits the probe
      point, kprobe handler is invoked.  And the copied instruction is single-step
      executed on the copied buffer (not on the original address) by kprobe.  After
      that, the kprobe checks registers and modify it (if need) as if the
      instructions was executed on the original address.
      
      My proposal is based on the fact there are many instructions which do NOT
      require the register modification after the single-step execution.  When the
      copied instruction is a kind of them, kprobe just jumps back to the next
      instruction after single-step execution.  If so, why don't we execute those
      instructions directly?
      
      With kprobe-booster patch, kprobes will execute a copied instruction directly
      and (if need) jump back to original code.  This direct execution is executed
      when the kprobe don't have both post_handler and break_handler, and the copied
      instruction can be executed directly.
      
      I sorted instructions which can be executed directly or not;
      
      - Call instructions are NG(can not be executed directly).
        We should correct the return address pushed into top of stack.
      - Indirect instructions except for absolute indirect-jumps
        are NG. Those instructions changes EIP randomly. We should
        check EIP and correct it.
      - Instructions that change EIP beyond the range of the
        instruction buffer are NG.
      - Instructions that change EIP to tail 5 bytes of the
        instruction buffer (it is the size of a jump instruction).
        We must write a jump instruction which backs to original
        kernel code in the instruction buffer.
      - Break point instruction is NG. We should not touch EIP and
        pass to other handlers.
      - Absolute direct/indirect jumps are OK.- Conditional Jumps are NG.
      - Halt and software-interruptions are NG. Because it will stay on
        the instruction buffer of kprobes.
      - Prefixes are NG.
      - Unknown/reserved opcode is NG.
      - Other 1 byte instructions are OK. But those instructions need a
        jump back code.
      - 2 bytes instructions are mapped sparsely. So, in this release,
        this patch don't boost those instructions.
      
      >From Intel's IA-32 opcode map described in IA-32 Intel Architecture Software
      Developer's Manual Vol.2 B, I determined that following opcodes are not
      boostable.
      
      - 0FH (2byte escape)
      - 70H - 7FH (Jump on condition)
      - 9AH (Call) and 9CH (Pushf)
      - C0H-C1H (Grp 2: includes reserved opcode)
      - C6H-C7H (Grp11: includes reserved opcode)
      - CCH-CEH (Software-interrupt)
      - D0H-D3H (Grp2: includes reserved opcode)
      - D6H (Reserved)
      - D8H-DFH (Coprocessor)
      - E0H-E3H (loop/conditional jump)
      - E8H (Call)
      - F0H-F3H (Prefixes and reserved)
      - F4H (Halt)
      - F6H-F7H (Grp3: includes reserved opcode)
      - FEH-FFH(Grp4,5: includes reserved opcode)
      
      Kprobe-booster checks whether target instruction can be boosted (can be
      executed directly) at arch_copy_kprobe() function.  If the target instruction
      can be boosted, it clears "boostable" flag.  If not, it sets "boostable" flag
      -1.  This is disabled status.  In resume_execution() function, If "boostable"
      flag is cleared, kprobe-booster measures the size of the target instruction
      and sets "boostable" flag 1.
      
      In kprobe_handler(), kprobe checks the "boostable" flag.  If the flag is 1, it
      resets current kprobe and executes instruction buffer directly instead of
      single stepping.
      
      When unregistering a boosted kprobe, it calls synchronize_sched()
      after "int3" is removed. So we can ensure followings after
      the synchronize_sched() called.
      - interrupt handlers are finished on all CPUs.
      - instruction buffer is not executed on all CPUs.
      And we can release the boosted kprobe safely.
      
      And also, on preemptible kernel, the booster is not enabled where the kernel
      preemption is enabled.  So, there are no preempted threads on the instruction
      buffer.
      
      The description of kretprobe-booster:
      ====================================
      
      In the normal operation, kretprobe make a target function return to trampoline
      code.  And a kprobe (called trampoline_probe) have been inserted at the
      trampoline code.  When the kernel hits this kprobe, it calls kretprobe's
      handler and it returns to original return address.
      
      Kretprobe-booster patch removes the trampoline_probe.  It allows the
      trampoline code to call kretprobe's handler directly instead of invoking
      kprobe.  And tranpoline code returns to original return address.
      
      This new trampoline code stores and restores registers, so the kretprobe
      handler is still able to access those registers.
      
      Current kprobe has about 1.3 usec/probe(*) overhead, and kprobe-booster patch
      reduces it to 0.6 usec/probe(*).  Also current kretprobe has about 2.0
      usec/probe(*) overhead.  Kprobe-booster patch reduces it to 1.3 usec/probe(*),
      and the combination of both kprobe-booster patch and kretprobe-booster patch
      reduces it to 0.9 usec/probe(*).
      
      I expect the combination of both patches can reduce half of a probing
      overhead.
      
      Performance numbers strongly depend on the processor model.
      
      Andrew Morton wrote:
      > These preempt tricks look rather nasty.  Can you please describe what the
      > problem is, precisely?  And how this code avoids it?  Perhaps we can find
      > something cleaner.
      
      The problem is how to remove the copied instructions of the
      kprobe *safely* on the preemptable kernel (CONFIG_PREEMPT=y).
      
      Kprobes basically executes the following actions;
      
      (1)int3
      (2)preempt_disable()
      (3)kprobe_prehandler()
      (4)copied instructioin(single step)
      (5)kprobe_posthandler()
      (6)preempt_enable()
      (7)return to the original code
      
      During the execution of copied instruction, preemption is
      disabled (from step (2) to (6)).
      When unregistering the probes, Kprobe waits for RCU
      quiescent state by using synchronize_sched() after removing
      int3 instruction.
      Thus we can ensure the copied instruction is not executed.
      
      On the other hand, kprobe-booster executes the following actions;
      
      (1)int3
      (2)preempt_disable()
      (3)kprobe_prehandler()
      (4)preempt_enable()             <-- this one is added by my patch
      (5)copied instruction(direct execution)
      (6)jmp back to the original code
      
      The problem is that we have no way to prevent preemption on
      step (5) or (6). We cannot call preempt_disable() after step (6),
      because there are no rooms to do that. Thus, some other
      processes may be preempted at step(5) or (6) on preemptable kernel.
      And I couldn't find the easy way to ensure that other processes'
      stack do *not* have the address of them. (I thought some way
      to do that, but those are very costly.)
      
      So currently, I simply boost the kprobe only when the probe
      point is already preemption disabled.
      
      > Also, the patch adds a preempt_enable() but I don't see a corresponding
      > preempt_disable().  Am I missing something?
      
      It is corresponding to the preempt_disable() in the top of
      kprobe_handler().
      I copied the code of kprobe_handler() here:
      
      static int __kprobes kprobe_handler(struct pt_regs *regs)
      {
              struct kprobe *p;
              int ret = 0;
              kprobe_opcode_t *addr = NULL;
              unsigned long *lp;
              struct kprobe_ctlblk *kcb;
      
              /*
               * We don't want to be preempted for the entire
               * duration of kprobe processing
               */
              preempt_disable();             <-- HERE
              kcb = get_kprobe_ctlblk();
      Signed-off-by: default avatarMasami Hiramatsu <hiramatu@sdl.hitachi.co.jp>
      Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      311ac88f
    • Masami Hiramatsu's avatar
      [PATCH] kprobes: clean up resume_execute() · b50ea74c
      Masami Hiramatsu authored
      
      
      Clean up kprobe's resume_execute() for i386 arch.
      Signed-off-by: default avatarMasami Hiramatsu <hiramatu@sdl.hitachi.co.jp>
      Cc: Prasanna S Panchamukhi <prasanna@in.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b50ea74c
  13. 23 Mar, 2006 1 commit
  14. 24 Feb, 2006 1 commit
  15. 12 Jan, 2006 1 commit
  16. 10 Jan, 2006 2 commits
  17. 12 Dec, 2005 1 commit
  18. 07 Nov, 2005 4 commits
  19. 07 Sep, 2005 3 commits
  20. 06 Jul, 2005 1 commit
  21. 27 Jun, 2005 1 commit
  22. 23 Jun, 2005 4 commits
    • Prasanna S Panchamukhi's avatar
      [PATCH] kprobes: Temporary disarming of reentrant probe for i386 · 417c8da6
      Prasanna S Panchamukhi authored
      
      
      This patch includes i386 architecture specific changes to support temporary
      disarming on reentrancy of probes.
      Signed-of-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      417c8da6
    • Hien Nguyen's avatar
      [PATCH] kprobes: moves lock-unlock to non-arch kprobe_flush_task · 0aa55e4d
      Hien Nguyen authored
      
      
      This patch moves the lock/unlock of the arch specific kprobe_flush_task()
      to the non-arch specific kprobe_flusk_task().
      Signed-off-by: default avatarHien Nguyen <hien@us.ibm.com>
      Acked-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0aa55e4d
    • Rusty Lynch's avatar
      [PATCH] Move kprobe [dis]arming into arch specific code · 7e1048b1
      Rusty Lynch authored
      
      
      The architecture independent code of the current kprobes implementation is
      arming and disarming kprobes at registration time.  The problem is that the
      code is assuming that arming and disarming is a just done by a simple write
      of some magic value to an address.  This is problematic for ia64 where our
      instructions look more like structures, and we can not insert break points
      by just doing something like:
      
      *p->addr = BREAKPOINT_INSTRUCTION;
      
      The following patch to 2.6.12-rc4-mm2 adds two new architecture dependent
      functions:
      
           * void arch_arm_kprobe(struct kprobe *p)
           * void arch_disarm_kprobe(struct kprobe *p)
      
      and then adds the new functions for each of the architectures that already
      implement kprobes (spar64/ppc64/i386/x86_64).
      
      I thought arch_[dis]arm_kprobe was the most descriptive of what was really
      happening, but each of the architectures already had a disarm_kprobe()
      function that was really a "disarm and do some other clean-up items as
      needed when you stumble across a recursive kprobe." So...  I took the
      liberty of changing the code that was calling disarm_kprobe() to call
      arch_disarm_kprobe(), and then do the cleanup in the block of code dealing
      with the recursive kprobe case.
      
      So far this patch as been tested on i386, x86_64, and ppc64, but still
      needs to be tested in sparc64.
      Signed-off-by: default avatarRusty Lynch <rusty.lynch@intel.com>
      Signed-off-by: default avatarAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7e1048b1
    • Hien Nguyen's avatar
      [PATCH] kprobes: function-return probes · b94cce92
      Hien Nguyen authored
      This patch adds function-return probes to kprobes for the i386
      architecture.  This enables you to establish a handler to be run when a
      function returns.
      
      1. API
      
      Two new functions are added to kprobes:
      
      	int register_kretprobe(struct kretprobe *rp);
      	void unregister_kretprobe(struct kretprobe *rp);
      
      2. Registration and unregistration
      
      2.1 Register
      
        To register a function-return probe, the user populates the following
        fields in a kretprobe object and calls register_kretprobe() with the
        kretprobe address as an argument:
      
        kp.addr - the function's address
      
        handler - this function is run after the ret instruction executes, but
        before control returns to the return address in the caller.
      
        maxactive - The maximum number of instances of the probed function that
        can be active concurrently.  For example, if the function is non-
        recursive and is called with a spinlock or mutex held, maxactive = 1
        should be enough.  If the function is non-recursive and can never
        relinquish the CPU (e.g., via a semaphore or preemption), NR_CPUS should
        be enough.  maxactive is used to determine how many kretprobe_instance
        objects to allocate for this particular probed function.  If maxactive <=
        0, it is set to a default value (if CONFIG_PREEMPT maxactive=max(10, 2 *
        NR_CPUS) else maxactive=NR_CPUS)
      
        For example:
      
          struct kretprobe rp;
          rp.kp.addr = /* entrypoint address */
          rp.handler = /*return probe handler */
          rp.maxactive = /* e.g., 1 or NR_CPUS or 0, see the above explanation */
          register_kretprobe(&rp);
      
        The following field may also be of interest:
      
        nmissed - Initialized to zero when the function-return probe is
        registered, and incremented every time the probed function is entered but
        there is no kretprobe_instance object available for establishing the
        function-return probe (i.e., because maxactive was set too low).
      
      2.2 Unregister
      
        To unregiter a function-return probe, the user calls
        unregister_kretprobe() with the same kretprobe object as registered
        previously.  If a probed function is running when the return probe is
        unregistered, the function will return as expected, but the handler won't
        be run.
      
      3. Limitations
      
      3.1 This patch supports only the i386 architecture, but patches for
          x86_64 and ppc64 are anticipated soon.
      
      3.2 Return probes operates by replacing the return address in the stack
          (or in a known register, such as the lr register for ppc).  This may
          cause __builtin_return_address(0), when invoked from the return-probed
          function, to return the address of the return-probes trampoline.
      
      3.3 This implementation uses the "Multiprobes at an address" feature in
          2.6.12-rc3-mm3.
      
      3.4 Due to a limitation in multi-probes, you cannot currently establish
          a return probe and a jprobe on the same function.  A patch to remove
          this limitation is being tested.
      
      This feature is required by SystemTap (http://sourceware.org/systemtap
      
      ),
      and reflects ideas contributed by several SystemTap developers, including
      Will Cohen and Ananth Mavinakayanahalli.
      Signed-off-by: default avatarHien Nguyen <hien@us.ibm.com>
      Signed-off-by: default avatarPrasanna S Panchamukhi <prasanna@in.ibm.com>
      Signed-off-by: default avatarFrederik Deweerdt <frederik.deweerdt@laposte.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b94cce92
  23. 05 May, 2005 1 commit