From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 20:51:40 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C64CB503 for ; Tue, 27 Aug 2013 20:51:40 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 330742196 for ; Tue, 27 Aug 2013 20:51:39 +0000 (UTC) Received: (qmail 15651 invoked from network); 27 Aug 2013 21:33:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2013 21:33:36 -0000 Message-ID: <521D1156.9030708@freebsd.org> Date: Tue, 27 Aug 2013 22:51:34 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ian Lepore Subject: Re: ARM network trouble after recent mbuf changes References: <1377550636.1111.156.camel@revolution.hippie.lan> <521BC472.7040804@freebsd.org> <521BD531.4090104@sbcglobal.net> <521C4CD9.4050308@freebsd.org> <0E0536B2-2B7F-4EED-9EFD-4B9E2C2D729A@freebsd.org> <521C87FF.8010100@freebsd.org> <521CB66B.9020806@freebsd.org> <1377615455.1111.180.camel@revolution.hippie.lan> In-Reply-To: <1377615455.1111.180.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 20:51:40 -0000 On 27.08.2013 16:57, Ian Lepore wrote: > On Tue, 2013-08-27 at 16:23 +0200, Andre Oppermann wrote: >> On 27.08.2013 15:29, Michael Tuexen wrote: >>> On Aug 27, 2013, at 1:05 PM, Andre Oppermann wrote: >>>> Thanks. I've changed the test accordingly. >>>> >>>> While doing the CTASSERTs to prevent such an incident in the future I stumbled >>>> across a bit of evil name space pollution in mbuf.h. It is impossible to take >>>> sizeof(struct m_ext) because "m_ext" is redefined to point into struct mbuf. >>>> >>>> In addition to the alignment fix I've solved the namespace issues with m_ext >>>> and the stupidly named struct pkthdr as well and properly prefixed them. The >>>> fallout from LINT was zero (as it should be). >>>> >>>> http://people.freebsd.org/~andre/m_hdr-alignment-20130827.diff >>>> >>>> Please test. >> > >>> Done. r254954 with your patch applied runs fine on a RPi. >> >> Does the CTASSERT trigger if the padding in m_hdr is not there? >> > > Yes: > > --- uipc_mbuf.o --- > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:91:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(sizeof(struct mbuf) == MSIZE); > > > Since the MLEN and MHLEN macros are used to size the data arrays based > on the assumption that they begin at a given offset within the struct, > these asserts more directly express that: > > CTASSERT(MSIZE - offsetof(struct mbuf, m_dat) == MLEN); > CTASSERT(MSIZE - offsetof(struct mbuf, m_pktdat) == MHLEN); > > With these added you get all 3 asserts and somewhat more of a clue about > why things are wrong (other than just sizeof mbuf being wrong): Excellent. I exchanged them for the struct mbuf member asserts. > --- uipc_mbuf.o --- > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:91:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(sizeof(struct mbuf) == MSIZE); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' > #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") > ^ > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:97:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(MSIZE - offsetof(struct mbuf, m_dat) == MLEN); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' > #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") > ^ ~ > /local/build/staging/freebsd/bb/src/sys/kern/uipc_mbuf.c:98:1: error: static_assert failed "compile-time assertion failed" > CTASSERT(MSIZE - offsetof(struct mbuf, m_pktdat) == MHLEN); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /local/build/staging/freebsd/bb/src/sys/sys/systm.h:100:21: note: expanded from macro 'CTASSERT' > #define CTASSERT(x) _Static_assert(x, "compile-time assertion failed") > ^ ~ > > > IMO, it would be great if MLEN and MHLEN could be #define'd in terms of > offsetof() expressions, but the compiler is unhappy about asking for > offsetof an incomplete struct, even though it has all the info it needs > at the point the expression is encountered. Yeah, I couldn't find a way either to solve this nasty circular dependency. -- Andre