From owner-freebsd-current@FreeBSD.ORG Fri Apr 17 04:48:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F391065673 for ; Fri, 17 Apr 2009 04:48:23 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 22D6A8FC13 for ; Fri, 17 Apr 2009 04:48:22 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm11 with SMTP id 11so729121fxm.43 for ; Thu, 16 Apr 2009 21:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jNmkPxql8ihugZn/iP2/eaaMSqdouBX+LBHuto/R2+E=; b=tm/vXMogpY1p4/3+6Muble4y2DuxOF9eJxWFhApyB9Bw7ZPae5BvGSLrMA3cFU/hEO Q0zEFCDueW/FKaQylUKzl6fbv25FCnmSndPK9jydRVrDx5kjCa5VMQ6qYFLfDFBgeL1A ee77zWbdSNF67lcy28jmpPPDxXZ1M9ELYmNUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KHGE+vMoV1eirmfLfZzPO0+VD6ABlhGmHq7cJ6DJ2hgzYWsqfPMx2dXU0PFof8i4n+ pUrrT3Gxg54NGpPvca84/zuKSy6Zwfc5zyNirdZc08K2UcwgDMMG1p7e3FPHxnIs2FK+ 7wTI80un+mIhos1Y/+GFo4ieR2nNSclLYX6Kg= MIME-Version: 1.0 Received: by 10.103.222.1 with SMTP id z1mr1124290muq.51.1239943702052; Thu, 16 Apr 2009 21:48:22 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Apr 2009 08:48:22 +0400 Message-ID: From: pluknet To: Maksim Yevmenkin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@freebsd.org Subject: Re: possible bug in the sbappendrecord_locked()? (Was: Re: core dump with bluetooth device) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:48:24 -0000 Sorry for top-posting. This is a fairly old bug. See my investigation http://lists.freebsd.org/pipermail/freebsd-net/2008-August/019345.html 2009/4/17 Maksim Yevmenkin : > On Thu, Apr 16, 2009 at 7:41 PM, Maksim Yevmenkin > wrote: >> On Thu, Apr 16, 2009 at 7:22 PM, Maksim Yevmenkin >> wrote: >>> On Thu, Apr 16, 2009 at 5:39 PM, Maksim Yevmenkin >>> wrote: >>>> On Thu, Apr 16, 2009 at 12:59 PM, Alexander Best >>>> wrote: >>>>> hi there, >>>>> >>>>> i'm running r191076M. when i try to send files from my mobile phone to my >>>>> computer via bt the core dumps. here's a backtrace: >>>>> >>>>> Unread portion of the kernel message buffer: >>>>> sblastmbufchk: sb_mb 0xc8d54d00 sb_mbtail 0 last 0xc8d54d00 >>>>> packet tree: >>>>> 0xc8d54d00 >>>>> panic: sblastmbufchk from /usr/src/sys/kern/uipc_sockbuf.c:797 >>>>> cpuid = 0 >>>> >>>> are you, by change, have "options SOCKBUF_DEBUG" in your kernel? >>> >>> ok, there is something strange going on in the >>> sbappendrecord_locked(). consider the following initial conditions: >>> >>> 1) sockbuf sb is empty, i.e. sb_mb == sb_mbtail == sb_lastrecord == NULL >>> >>> 2) sbappendrecord_locked() is given mbuf m0 with has exactly one mbuf, >>> i.e. m0->m_next == NULL >>> >>> so >>> >>> void >>> sbappendrecord_locked(struct sockbuf *sb, struct mbuf *m0) >>> { >>> struct mbuf *m; >>> >>> SOCKBUF_LOCK_ASSERT(sb); >>> >>> if (m0 == 0) >>> return; >>> m = sb->sb_mb; >>> >>> if (m) >>> while (m->m_nextpkt) >>> m = m->m_nextpkt; >>> >>> --> m is still NULL at this point >>> >>> /* >>> * Put the first mbuf on the queue. Note this permits zero length >>> * records. >>> */ >>> sballoc(sb, m0); >>> SBLASTRECORDCHK(sb); >>> >>> --> passed successfully, because sb_mb == sb_lastrecord == NULL (i.e. >>> sockbuf is empty) >>> >>> SBLINKRECORD(sb, m0); >>> >>> --> at this point sb_mb == sb_lastrecord == m0, _but_ sb_mtail == NULL >>> >>> if (m) >>> m->m_nextpkt = m0; >>> else >>> sb->sb_mb = m0; >>> >>> --> not sure about those lines above, didn't SBLINKRECORD(sb, m0) take >>> care of it already? >>> --> in any case, still, sb_mb == sb_lastrecord == m0 _and_ still >>> sb_mtail == NULL >>> >>> m = m0->m_next; >>> m0->m_next = 0; >>> >>> --> m is still NULL here >>> >>> if (m && (m0->m_flags & M_EOR)) { >>> m0->m_flags &= ~M_EOR; >>> m->m_flags |= M_EOR; >>> } >>> >>> --> sbcompress() is called with m == NULL, which is triggers the panic >>> (read below) >>> >>> sbcompress(sb, m, m0); >>> } >>> >>> =========== >>> >>> void >>> sbcompress(struct sockbuf *sb, struct mbuf *m, struct mbuf *n) >>> { >>> int eor = 0; >>> struct mbuf *o; >>> >>> SOCKBUF_LOCK_ASSERT(sb); >>> >>> while (m) { >>> >>> --> lots of code that never gets executed because m == NULL >>> >>> } >>> if (eor) { >>> KASSERT(n != NULL, ("sbcompress: eor && n == NULL")); >>> n->m_flags |= eor; >>> } >>> >>> --> this where panic happens, because sb_mbtail is still NULL, but >>> sockbuf now contains exactly one record >>> >>> SBLASTMBUFCHK(sb); >>> } >>> >>> so, it looks like, sbcompress() should only be called when m != NULL. >>> also, when m == NULL, m0 should be marked as EOR. >> >> actually, no, EOR should be set (or not set already). >> >>> comments anyone? >> >> i think there is also something strange going on in >> sbappendaddr_locked(), basically, >> >> int >> sbappendaddr_locked(struct sockbuf *sb, const struct sockaddr *asa, >> struct mbuf *m0, struct mbuf *control) >> { >> struct mbuf *m, *n, *nlast; >> int space = asa->sa_len; >> >> SOCKBUF_LOCK_ASSERT(sb); >> >> if (m0 && (m0->m_flags & M_PKTHDR) == 0) >> panic("sbappendaddr_locked"); >> if (m0) >> space += m0->m_pkthdr.len; >> space += m_length(control, &n); >> >> if (space > sbspace(sb)) >> return (0); >> #if MSIZE <= 256 >> if (asa->sa_len > MLEN) >> return (0); >> #endif >> MGET(m, M_DONTWAIT, MT_SONAME); >> if (m == 0) >> return (0); >> m->m_len = asa->sa_len; >> bcopy(asa, mtod(m, caddr_t), asa->sa_len); >> >> --> at this point n is not initialized, or at least i do not see where >> it was initialized. shouldn't be compiler giving a warning here? >> >> if (n) >> n->m_next = m0; /* concatenate data to control */ >> else >> control = m0; >> >> am i missing something obvious here? > > ignore the last one :) i missed m_length(control, &n). ok, need to get > away from the screen :) > > thanks, > max > _______________________________________________ > 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" > -- wbr, pluknet