From owner-freebsd-current Sun Feb 4 08:05:51 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA12530 for current-outgoing; Sun, 4 Feb 1996 08:05:51 -0800 (PST) Received: from marble.eps.nagoya-u.ac.jp (marble.eps.nagoya-u.ac.jp [133.6.57.68]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA12525 for ; Sun, 4 Feb 1996 08:05:46 -0800 (PST) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by marble.eps.nagoya-u.ac.jp (8.7.3+2.6Wbeta5/3.3W9) with ESMTP id BAA00550 for ; Mon, 5 Feb 1996 01:05:44 +0900 (JST) Message-Id: <199602041605.BAA00550@marble.eps.nagoya-u.ac.jp> To: current@freebsd.org Subject: kmem_malloc called at splimp X-Mailer: Mew beta version 0.96 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 05 Feb 1996 01:05:41 +0900 From: KATO Takenori Sender: owner-current@freebsd.org Precedence: bulk The function kmem_malloc() is called at splimp when mbuffer is initialized. Is it safe? 1. The function mbinit() calls m_clalloc() at splimp. 2. The function m_clalloc() calls kmem_malloc() without changing software interruption mask. 3. Therefore, kmem_malloc() is called at splimp. 4. The comment of kmem_malloc says that `this still only works in a uni-processor environment and when called at splhigh().' ^^^^^^^^^^^^^^^^^^^^^^^^ Because splimp of FreeBSD doesn't block disk I/O, above operation may clobber vm map IF disk I/O interruption occurs. (I have not checked whether it occurs or not, yet.) ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya 464-01 Voice: +81-52-789-2529 Fax: +81-52-789-3033