[Fwd: cvs commit: src/sys/kern sys_pipe.c]

From: Alan L. Cox (alc_at_imimic.com)
Date: 07/31/03

  • Next message: Kris Kennaway: "Re: [Fwd: cvs commit: src/sys/kern sys_pipe.c]" 
    Date: Wed, 30 Jul 2003 23:15:09 -0500
To: current@freebsd.org, kris@obsecurity.org, jhb@FreeBSD.org

    I believe that the attached commit addresses the "panic: sleeping thread
    owns a mutex" problem reported by Kris and another related problem
    reported a few days earlier. The earlier problem report included the
    following stack trace:

    Sleeping on "objtrm" with the following non-sleepablelocks held:
    exclusive sleep mutex system map r = 0 (0xfffff80067e92098) locked @
    /usr/src/sys/vm/vm_map.c:2192
    lock order reversal
     1st 0xfffff80067e92098 system map (system map) @
    /usr/src/sys/vm/vm_map.c:2192
     2nd 0xc0354d70 Giant (Giant) @ /usr/src/sys/kern/kern_synch.c:312
    Stack backtrace:
    _mtx_lock_flags() at _mtx_lock_flags+0xa0
    msleep() at msleep+0x6a8
    vm_object_pip_wait() at vm_object_pip_wait+0x48
    vm_object_terminate() at vm_object_terminate+0x30
    vm_object_deallocate() at vm_object_deallocate+0x374
    vm_map_entry_delete() at vm_map_entry_delete+0x3c
    vm_map_delete() at vm_map_delete+0x32c
    vm_map_remove() at vm_map_remove+0x44
    kmem_free() at kmem_free+0x20
    pipe_free_kmem() at pipe_free_kmem+0x98
    pipeclose() at pipeclose+0x124
    pipe_close() at pipe_close+0x20
    fdrop_locked() at fdrop_locked+0x134
    fdrop() at fdrop+0x20
    closef() at closef+0x1f8
    close() at close+0x168
    syscall() at syscall+0x2ac
    -- syscall (6, FreeBSD ELF64, close) %o7=0x10706c --

    attached mail follows:

    Date: Wed, 30 Jul 2003 11:55:04 -0700 (PDT)
To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org

    alc 2003/07/30 11:55:04 PDT

      FreeBSD src repository

      Modified files:
        sys/kern sys_pipe.c
      Log:
      The introduction of vm object locking has caused witness to reveal
      a long-standing mistake in the way a portion of a pipe's KVA is
      allocated. Specifically, kmem_alloc_pageable() is inappropriate
      for use in the "direct" case because it allows a preceding vm map entry
      and vm object to be extended to support the new KVA allocation.
      However, the direct case KVA allocation should not have a backing
      vm object. This is corrected by using kmem_alloc_nofault().
      
      Submitted by: tegge (with the above explanation by me)
      
      Revision Changes Path
      1.140 +1 -1 src/sys/kern/sys_pipe.c

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Kris Kennaway: "Re: [Fwd: cvs commit: src/sys/kern sys_pipe.c]"