Date: Tue, 03 Sep 2019 14:07:58 -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: <AA719490-5A6F-4218-90B8-FB7FA724C94E@cschubert.com> In-Reply-To: <CANCZdfrkON8J_6ZHt1UKa95G0=JLwZ8KoebspZzF0%2BeQ71BY4A@mail.gmail.com> References: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net> <3095E422-7865-4EA5-BF13-6A48CB542AEE@cschubert.com> <CANCZdfrkON8J_6ZHt1UKa95G0=JLwZ8KoebspZzF0%2BeQ71BY4A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=2Eco= m> >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=2Enet>= , >> >"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: >> >> > > > > >> >> > > > > /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 Makef= ile, >> >> > > > 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 e= xamples in contrib, yet to be discovered, that might also have the same iss= ues=2E=20 --=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-all@freebsd.org Tue Sep 3 14:07:58 2019 Return-Path: <owner-svn-src-all@freebsd.org> Delivered-To: svn-src-all@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 620E8DD4A3; Tue, 3 Sep 2019 14:07:06 +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 46N8096N3Xz4QDn; Tue, 3 Sep 2019 14:07:05 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 28FDB1B0A6; Tue, 3 Sep 2019 14:06:28 +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 7EC4CF861; Thu, 18 Apr 2019 23:21:29 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 428E084FFC; Thu, 18 Apr 2019 23:21:29 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1AAD6F860; Thu, 18 Apr 2019 23:21:29 +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 DB486F85E for <src-committers@localmail.freebsd.org>; Thu, 18 Apr 2019 23:21:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FACD84FEF; Thu, 18 Apr 2019 23:21:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8615F25FA4; Thu, 18 Apr 2019 23:21:26 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x3INLQK0054164; Thu, 18 Apr 2019 23:21:26 GMT (envelope-from jhb@FreeBSD.org) Received: (from jhb@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x3INLQYs054163; Thu, 18 Apr 2019 23:21:26 GMT (envelope-from jhb@FreeBSD.org) Message-Id: <201904182321.x3INLQYs054163@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: jhb set sender to jhb@FreeBSD.org using -f From: John Baldwin <jhb@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r346360 - head/sys/netinet X-SVN-Group: head X-SVN-Commit-Author: jhb X-SVN-Commit-Paths: head/sys/netinet X-SVN-Commit-Revision: 346360 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 428E084FFC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.977,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" <svn-src-all.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>; List-Post: <mailto:svn-src-all@freebsd.org> List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=subscribe> Date: Tue, 03 Sep 2019 14:07:58 -0000 X-Original-Date: Thu, 18 Apr 2019 23:21:26 +0000 (UTC) X-List-Received-Date: Tue, 03 Sep 2019 14:07:58 -0000 Author: jhb Date: Thu Apr 18 23:21:26 2019 New Revision: 346360 URL: https://svnweb.freebsd.org/changeset/base/346360 Log: Push down INP_WLOCK slightly in tcp_ctloutput. The inp lock is not needed for testing the V6 flag as that flag is set once when the inp is created and never changes. For non-TCP socket options the lock is immediately dropped after checking that flag. This just pushes the lock down to only be acquired for TCP socket options. This isn't a hot-path, more a cosmetic cleanup I noticed while reading the code. Reviewed by: bz MFC after: 1 month Sponsored by: Netflix Differential Revision: https://reviews.freebsd.org/D19740 Modified: head/sys/netinet/tcp_usrreq.c Modified: head/sys/netinet/tcp_usrreq.c ============================================================================== --- head/sys/netinet/tcp_usrreq.c Thu Apr 18 22:52:12 2019 (r346359) +++ head/sys/netinet/tcp_usrreq.c Thu Apr 18 23:21:26 2019 (r346360) @@ -1578,11 +1578,9 @@ tcp_ctloutput(struct socket *so, struct sockopt *sopt) error = 0; inp = sotoinpcb(so); KASSERT(inp != NULL, ("tcp_ctloutput: inp == NULL")); - INP_WLOCK(inp); if (sopt->sopt_level != IPPROTO_TCP) { #ifdef INET6 if (inp->inp_vflag & INP_IPV6PROTO) { - INP_WUNLOCK(inp); error = ip6_ctloutput(so, sopt); /* * In case of the IPV6_USE_MIN_MTU socket option, @@ -1627,12 +1625,12 @@ tcp_ctloutput(struct socket *so, struct sockopt *sopt) #endif #ifdef INET { - INP_WUNLOCK(inp); error = ip_ctloutput(so, sopt); } #endif return (error); } + INP_WLOCK(inp); if (inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) { INP_WUNLOCK(inp); return (ECONNRESET);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA719490-5A6F-4218-90B8-FB7FA724C94E>