From owner-freebsd-current Mon Mar 24 10: 8:46 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D765937B401 for ; Mon, 24 Mar 2003 10:08:43 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3870B43F75 for ; Mon, 24 Mar 2003 10:08:43 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.12.8/8.12.8) with SMTP id h2OI8cjK038678; Mon, 24 Mar 2003 13:08:38 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Mon, 24 Mar 2003 13:08:37 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Daniel C. Sobral" Cc: CURRENT Subject: Re: IP stack problem -- possibly mac-related In-Reply-To: <3E7F3F3F.8090902@tcoip.com.br> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-25.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 24 Mar 2003, Daniel C. Sobral wrote: > The messages below are from today's kernel + mac_mls and mac_biba > kld-loaded from loader(8). None of the warning appear if these modules > are not loaded (I haven't tried not loading one and then the other, but > I can do it on request) ... > malloc() of "128" with the following non-sleepablelocks held: > exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ > /usr/src/sys/netinet/udp_usrreq.c:1034 > exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ > /usr/src/sys/netinet/udp_usrreq.c:1027 Hmm. I think there's a witness flag to generate stack traces when giving out these sorts of warnings -- debug.witness_trace I think. Can you try turning that on in loader.conf and see if we get some additional information? The only MAC call in udp_output() is mac_create_mbuf_from_socket(), which isn't supposed to result in memory allocation. That should only happen when the mbuf itself is allocated. A stack trace might narrow down the source of the problem. Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message