Date: Tue, 03 Sep 2019 14:07:28 -0000 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Kyle Evans <kevans@freebsd.org>, Cy Schubert <cy@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r346341 - head/tools/build Message-ID: <3E54A972-27CE-498F-B0B9-B65A6E87F213@cschubert.com> In-Reply-To: <CANCZdfqz4uueMc3qyXeyoODS%2BEyrf4GvNJVc7A4mftim%2BKdPig@mail.gmail.com> References: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net> <3095E422-7865-4EA5-BF13-6A48CB542AEE@cschubert.com> <CANCZdfrkON8J_6ZHt1UKa95G0=JLwZ8KoebspZzF0%2BeQ71BY4A@mail.gmail.com> <AA719490-5A6F-4218-90B8-FB7FA724C94E@cschubert.com> <CANCZdfqz4uueMc3qyXeyoODS%2BEyrf4GvNJVc7A4mftim%2BKdPig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On April 18, 2019 9:59:50 AM PDT, Warner Losh <imp@bsdimp=2Ecom> wrote: >On Thu, Apr 18, 2019 at 10:26 AM Cy Schubert ><Cy=2ESchubert@cschubert=2Ecom> >wrote: > >> On April 18, 2019 8:11:49 AM PDT, Warner Losh <imp@bsdimp=2Ecom> wrote: >>> >>> >>> >>> On Thu, Apr 18, 2019 at 8:44 AM Cy Schubert ><Cy=2ESchubert@cschubert=2Ecom> >>> wrote: >>> >>>> On April 18, 2019 7:22:53 AM PDT, "Rodney W=2E Grimes" < >>>> freebsd@gndrsh=2Ednsmgr=2Enet> wrote: >>>> >> On Thu, Apr 18, 2019 at 8:46 AM Rodney W=2E Grimes >>>> >> <freebsd@gndrsh=2Ednsmgr=2Enet> wrote: >>>> >> > >>>> >> > > In message <201904180107=2Ex3I17QDc002945@gndrsh=2Ednsmgr=2Ene= t>, >>>> >"Rodney W=2E >>>> >> > > Grimes" >>>> >> > > writes: >>>> >> > > > > Author: cy >>>> >> > > > > Date: Thu Apr 18 01:02:00 2019 >>>> >> > > > > New Revision: 346341 >>>> >> > > > > URL: https://svnweb=2Efreebsd=2Eorg/changeset/base/346341 >>>> >> > > > > >>>> >> > > > > Log: >>>> >> > > > > As an interim measure until a more permanent solution >is >>>> >implemented >>>> >> > > > > workaround the following error: >>>> >> > > > > >>>> >> > > > > =20 >/usr/src/contrib/elftoolchain/strings/strings=2Ec:198:55: >>>> >error: use of >>>> >> > > > > undeclared identifier >>>> >> > > > > 'FA_OPEN' fa =3D fileargs_init(argc, argv, O_RDONLY, 0, >>>> >&rights, FA_OPEN); >>>> >> > > > > >>>> >> > > > > Reported by: O=2E Hartmann <ohartmann@walstatt=2Eorg> >>>> >> > > > > Reported by: Michael Butler ><imb@protected-networks=2Enet> >>>> >> > > > > Reported by: gjb@ & cy@ (implicit) >>>> >> > > > > Reviewed by: emaste@ >>>> >> > > > > Noted by: rgrimes@ >>>> >> > > > > >>>> >> > > > > Modified: >>>> >> > > > > head/tools/build/Makefile >>>> >> > > > > >>>> >> > > > > Modified: head/tools/build/Makefile >>>> >> > > > > >>>> >>>> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>> >> > > > =3D=3D=3D >>>> >> > > > > --- head/tools/build/Makefile Thu Apr 18 00:38:54 >2019 >>>> > (r34634 >>>> >> > > > 0) >>>> >> > > > > +++ head/tools/build/Makefile Thu Apr 18 01:02:00 >2019 >>>> > (r34634 >>>> >> > > > 1) >>>> >> > > > > @@ -59,9 +59,7 @@ INCS+=3D capsicum_helpers=2Eh >>>> >> > > > > INCS+=3D libcasper=2Eh >>>> >> > > > > =2Eendif >>>> >> > > > > >>>> >> > > > > -=2Eif !exists(/usr/include/casper/cap_fileargs=2Eh) >>>> >> > > > > CASPERINC+=3D >>>> >${SRCTOP}/lib/libcasper/services/cap_fileargs/cap_filea >>>> >> > > > rgs=2Eh >>>> >> > > > > -=2Eendif >>>> >> > > > >>>> >> > > > As a further note, we should probably hunt for any thing >>>> >> > > > that is explicity looking at /usr/include/=2E=2E=2E in a >Makefile, >>>> >> > > > as that is minimally missing a ${DESTDIR} argument=2E >>>> >> > > > >>>> >> > > > The above may of actually worked if it had been written: >>>> >> > > > =2Eif !exists(${DESTDIR}/usr/include/casper/cap_fileargs=2Eh= ) >>>> >> > > > someone may wish to test that=2E >>>> >> > > > >>>> >> > > > Also a pathname rooted at / without ${DESTDIR} is almost >>>> >certainly a mistake=2E >>>> >> > > >>>> >> > > This is a better solution=2E I tested this in a tree with a >>>> >duplicated >>>> >> > > environment: Problem solved=2E Before this is committed it >should >>>> >be >>>> >> > > tested on one of the universe machines=2E >>>> >> > >>>> >> > From what Ed just said this would also be wrong, >>>> >> > as well as CASPERINC+=3D above being wrong, if this >>>> >> > is being built for the host we should not be using >>>> >> > any headers from ${SRCTOP} at all=2E >>>> >> > >>>> >> > if capfileargs=2Eh does not exist on the host that functionality >>>> >> > must not be compiled into the buildtool as the host does not >>>> >> > have this feature and attempting to use it from SRCTOP is >wrong=2E >>>> >> > >>>> >> >>>> >> Keep in mind that this is bootstrap; it's being built for the >host >>>> >> system, but it will link against a version of libcasper that's >been >>>> >> built in an earlier stage with the proper featureset=2E >>>> > >>>> >Ok, flip flop again, if infact this is linked against a >>>> >library that implements the stuff from cap_fileargs=2Eh then >>>> >infact the ${DESTDIR} addition so that the build peaks into >>>> >the cross build tree is correct, or what ever the equivelent >>>> >to DESTDIR is for that ? BUILDDIR? The point is it should >>>> >be picking this header up from the object tree, NOT from >>>> >the running system=2E >>>> >>>> Yes, this was my conclusion when working on kerberos and ntp=2E This >is >>>> also true of libraries, else one would need to installworld and >buildworld >>>> again to get a properly built library/binary=2E >>>> >>>> IIRC ngie@ fixed a number of these across the tree a couple of >years >>>> ago=2E >>> >>> >>> OK=2E There's a number of different issues going on=2E As the original >author >>> of libegacy (which is what we're seeing fail), let me address the >design >>> generically and comment on different things that have come up in >this >>> thread=2E >>> >>> Since this is going into the libegacy that we're using to build the >>> system, the check for file is bogus, for reasons I'll discuss below=2E > When >>> we add new includes to the system, it is appropriate to do it this >way=2E And >>> when this file was added to the system, the check was correct=2E >>> >>> First off, DESTDIR is absolutely not correct since this is to build >the >>> legacy library and legacy includes which augment the host's sources >on >>> legacay system, hence the name=2E It's never the correct thing to use= =2E >>> >>> The problem that we have here is not that the file is missing (which >is >>> why it was added the way it was a long time ago), but rather missing >>> functionality in a file that's been around for a long time=2E >>> >>> So, since it is that class of problem, the canonical way we've dealt >with >>> it in the past is to do something like create a file foo=2Eh that >looks >>> something like >>> >>> #include_next <foo=2Eh> >>> >>> #ifndev SOMETHING_NEW >>> #define SOMETHING_NEW 0 /* Or other values that are fail-safe on the >old >>> system */ >>> #endif >>> >>> and that's the change that needs to be made here=2E Sometimes, more >>> extensive things need to be done when the old library can't work at >all >>> with the new code=2E In those cases, the pattern is for foo=2Eh to >include >>> #define problem_fn my_problem_fn and then write a my_problem_fn that >wraps >>> problem_fn in a way that works on the old system=2E Kinda a poor man's >symbol >>> versioning, in a way (note: we can't use symbol version for this >since >>> we're building new binaries)=2E >>> >>> The "stop gap" gets things compiling, and maybe OK for the moment, >unless >>> the SOMETHING_NEW variable that's used (in this case FA_OPEN) causes >the >>> old library to do the wrong thing=2E I've not done the deep dive to >see if >>> this is the case or not=2E >>> >>> So, does that make sense? >>> >>> Warner >>> >> >> This solves one problem but what about the cases when a new krb5, >ntp, or >> amd is imported but fails to build because it is using the old >headers in >> /usr/include and linking against old libraries on the running system? >> >> These examples BTW have been fixed=2E My concern is there could be >other >> examples in contrib, yet to be discovered, that might also have the >same >> issues=2E >> > >That's the whole point if libegacy: to provide the glue that's needed >for >the bootstrap process=2E I'm surprised that ntp or amd are involved with >libegacy at all since they aren't bootstrap tools=2E Are you sure you >aren't >confusing two different problem domains? I know kerberos is, but it >kinda >needs to be=2E > >Warner Maybe I am conflating the two issues=2E I'll look again the next time I ge= t to a keyboard=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert <Cy=2ESchubert@cschubert=2Ecom> FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-svn-src-head@freebsd.org Tue Sep 3 14:07:38 2019 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5D53ADD8D4; Tue, 3 Sep 2019 14:07:20 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N80R59HBz4QVN; Tue, 3 Sep 2019 14:07:19 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 36B701B48F; Tue, 3 Sep 2019 14:06:36 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id F084B9922; Mon, 22 Apr 2019 08:11:01 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3FBE4774ED; Mon, 22 Apr 2019 08:11:01 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 0CB949902; Mon, 22 Apr 2019 08:11:01 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id CAC259900 for <src-committers@localmail.freebsd.org>; Mon, 22 Apr 2019 08:10:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78D11774DF; Mon, 22 Apr 2019 08:10:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [176.74.212.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 282F02601C2; Mon, 22 Apr 2019 10:10:56 +0200 (CEST) Subject: Re: svn commit: r346530 - in head/sys: netinet netinet6 To: Enji Cooper <yaneurabeya@gmail.com> Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head@freebsd.org References: <201904220727.x3M7ROpR009729@repo.freebsd.org> <2F3D6B17-AF4F-4B0F-B20E-5EF41DE851F9@gmail.com> From: Hans Petter Selasky <hps@selasky.org> Message-ID: <87917500-0381-79d8-a34b-819848abed32@selasky.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <2F3D6B17-AF4F-4B0F-B20E-5EF41DE851F9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 3FBE4774ED X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.967,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/> List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> Date: Tue, 03 Sep 2019 14:07:39 -0000 X-Original-Date: Mon, 22 Apr 2019 10:10:27 +0200 X-List-Received-Date: Tue, 03 Sep 2019 14:07:39 -0000 On 4/22/19 9:52 AM, Enji Cooper wrote: > >> On Apr 22, 2019, at 12:27 AM, Hans Petter Selasky <hselasky@FreeBSD.org> wrote: >> >> Author: hselasky >> Date: Mon Apr 22 07:27:24 2019 >> New Revision: 346530 >> URL: https://svnweb.freebsd.org/changeset/base/346530 >> >> Log: >> Fix panic in network stack due to memory use after free in relation to >> fragmented packets. >> >> When sending IPv4 and IPv6 fragmented packets and a fragment is lost, >> the mbuf making up the fragment will remain in the temporary hashed >> fragment list for a while. If the network interface departs before the >> so-called slow timeout clears the packet, the fragment causes a panic >> when the timeout kicks in due to accessing a freed network interface >> structure. >> >> Make sure that when a network device is departing, all hashed IPv4 and >> IPv6 fragments belonging to it, get freed. >> >> Backtrace: >> panic() >> icmp6_reflect() >> >> hlim = ND_IFINFO(m->m_pkthdr.rcvif)->chlim; >> ^^^^ rcvif->if_afdata[AF_INET6] is NULL. >> >> icmp6_error() >> frag6_freef() >> frag6_slowtimo() >> pfslowtimo() >> softclock_call_cc() >> softclock() >> ithread_loop() >> >> Differential Revision: https://reviews.freebsd.org/D19622 >> Reviewed by: bz (network), adrian >> MFC after: 1 week >> Sponsored by: Mellanox Technologies > > This commit broke the build on mips, etc: > > 07:36:06 > --- ip_reass.o --- > > 07:36:06 > /usr/src/sys/netinet/ip_reass.c:641: error: expected ')' before '(' token > > 07:36:06 *** [ip_reass.o] Error code 1 > > EVENTHANDLER_DEFINE looks like it doesn’t work with gcc? I'm looking into it. Thank you! --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E54A972-27CE-498F-B0B9-B65A6E87F213>