Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jul 2003 23:15:09 -0500
From:      "Alan L. Cox" <alc@imimic.com>
To:        current@freebsd.org, kris@obsecurity.org, jhb@FreeBSD.org
Subject:   [Fwd: cvs commit: src/sys/kern sys_pipe.c]
Message-ID:  <3F2897CD.5855158@imimic.com>

next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
--------------D4D880772F95C4A1E5B7203A
Content-Type: text/plain; charset=x-user-defined
Content-Transfer-Encoding: 7bit

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 --
--------------D4D880772F95C4A1E5B7203A
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from mx2.freebsd.org (216.136.204.119)2-0515771307
	for <alc@imimic.com>; Wed, 30 Jul 2003 14:55:07 -0400 (EDT)
Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18])
	by mx2.freebsd.org (Postfix) with ESMTP id E9C52578EF
	for <alc@imimic.com>; Wed, 30 Jul 2003 11:55:08 -0700 (PDT)
	(envelope-from owner-src-committers@FreeBSD.org)
Received: by hub.freebsd.org (Postfix)
	id B038037B407; Wed, 30 Jul 2003 11:55:08 -0700 (PDT)
Delivered-To: alc@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 538)
	id 67FCF37B404; Wed, 30 Jul 2003 11:55:08 -0700 (PDT)
Delivered-To: src-committers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 0C7C537B401; Wed, 30 Jul 2003 11:55:06 -0700 (PDT)
Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 95D6343F93; Wed, 30 Jul 2003 11:55:05 -0700 (PDT)
	(envelope-from alc@FreeBSD.org)
Received: from repoman.freebsd.org (localhost [127.0.0.1])
	by repoman.freebsd.org (8.12.6/8.12.6) with ESMTP id h6UIt50U063437;
	Wed, 30 Jul 2003 11:55:05 -0700 (PDT)
	(envelope-from alc@repoman.freebsd.org)
Received: (from alc@localhost)
	by repoman.freebsd.org (8.12.6/8.12.6/Submit) id h6UIt4Mr063436;
	Wed, 30 Jul 2003 11:55:04 -0700 (PDT)
Message-Id: <200307301855.h6UIt4Mr063436@repoman.freebsd.org>
From: Alan Cox <alc@FreeBSD.org>
Date: Wed, 30 Jul 2003 11:55:04 -0700 (PDT)
To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org,
	cvs-all@FreeBSD.org
Subject: cvs commit: src/sys/kern sys_pipe.c
X-FreeBSD-CVS-Branch: HEAD
Sender: owner-src-committers@FreeBSD.org
Precedence: bulk
X-Loop: FreeBSD.ORG
X-Loop-Detect: 1
X-Mozilla-Status2: 00000000

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

--------------D4D880772F95C4A1E5B7203A--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F2897CD.5855158>