From owner-freebsd-arm@FreeBSD.ORG Tue Aug 27 14:57:45 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 136E41E9; Tue, 27 Aug 2013 14:57:45 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D9FB52D76; Tue, 27 Aug 2013 14:57:44 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VEKi9-000ENG-P7; Tue, 27 Aug 2013 14:57:37 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r7REvZoN053205; Tue, 27 Aug 2013 08:57:35 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18RprrW0s8eih+vtyKfEZTs Subject: Re: ARM network trouble after recent mbuf changes From: Ian Lepore To: Andre Oppermann In-Reply-To: <521CB66B.9020806@freebsd.org> 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> Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 2013 08:57:35 -0600 Message-ID: <1377615455.1111.180.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port 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 14:57:45 -0000 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): --- 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. -- Ian