From owner-freebsd-hackers@freebsd.org Tue Aug 6 16:56:18 2019 Return-Path: Delivered-To: freebsd-hackers@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 D1308C570A; Tue, 6 Aug 2019 16:56:18 +0000 (UTC) (envelope-from gjb@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 46314L595Rz4CZk; Tue, 6 Aug 2019 16:56:18 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id E4DA4CA38; Tue, 6 Aug 2019 16:56:17 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Tue, 6 Aug 2019 16:56:14 +0000 From: Glen Barber To: John Baldwin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk Message-ID: <20190806165614.GA41295@FreeBSD.org> References: <201908030106.x7316Ibx078529@repo.freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <201908030106.x7316Ibx078529@repo.freebsd.org> User-Agent: Mutt/1.12.1 (2019-06-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 16:56:18 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > Author: jhb > Date: Sat Aug 3 01:06:17 2019 > New Revision: 350550 > URL: https://svnweb.freebsd.org/changeset/base/350550 >=20 > Log: > Flip REPRODUCIBLE_BUILD back to off by default in head. > =20 > Having the full uname output can be useful on head even with > unmodified trees or trees that newvers.sh fails to recognize as > modified. > =20 > Reviewed by: emaste > Differential Revision: https://reviews.freebsd.org/D20895 >=20 I would like to request this commit be reverted. While the original commit message to enable this knob stated the commit would be reverted after stable/12 branched, I have seen no public complaints about enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see the benefit of disabling it by default -- why wouldn't we want reproducibility?). To me, this feels like a step backwards, with no tangible benefit. Note, newvers.sh does properly detect a modified tree if it can find the VCS metadata directory (i.e., .git, .svn) -- I know this because I personally helped with it. In my opinion, those that want the non-reproducible metadata included in output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their src.conf. Turning off a sane default for the benefit of what I suspect is likely a short list of use cases feels like a step in the wrong direction. Glen --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAl1JsSkACgkQAxRYpUeP 4pP1iQ/9HRagGOeEniZZhcv+PYAPG3x5PGj2Jw7x6XAG36wFAGGsPDtOl5T4It0x OFtfhiMWOAIE6BOlG1/7FRfldQq7HiZRanMjp8fPwSEooDJGDs97Rfw2y3iyjUaf mBi90XjF8oKmnQVMDnv3bcXNII2pt79VaDDryvLhpRMuH4fYALinu9I8DU7W+anh EN2PXq8lCR5EdzasZh45Sa+987uhX2zyhUfQsM7Q+Sgfbxc5rrCP8IJkjtmoE6Bu w27/7dQbGuAtygl8Zl8iEYdnfm2yv3uY/05cnjwLK85VBlWaPEEZiV6Dq2iGurtw yrrQQczrlXuv8pzjT43p3IScWU+3kDd0mD5EUYSVpBbaVcFuCEEcyMmn/bYh75nr EvkWzYgrveFupykpgF9k0EsqGViEt8SQNRAf3KihJhpAN4kl7q+hEXZardIcwoz7 pLqMA6rRMB5leOPXwEpLtZxPDHq4MX+GbmtaEOQtuPyJKlbMQ/ieDrfFQZ/Hv8pP EaWiPn7w2iuUliRCHTWsggVgdF/7kEMTfIMNfae/KYmD7fSXC2BHi5wOgKLJGs7H dZibtfqBgGTs8/prHyhBHy7ptSjhknTATfPnUVQ1rkWnpSMvyekoaR8QPM9mfVLR Iv7n30+QiMmhkSvR2CY2GbzI9DDgXdz9SkbwdnQagodV4h7MLmo= =tIoZ -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf-- From owner-freebsd-hackers@freebsd.org Wed Aug 7 05:34:10 2019 Return-Path: Delivered-To: freebsd-hackers@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 994DDBF520; Wed, 7 Aug 2019 05:34:10 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463Ktn2yhCz4GBG; Wed, 7 Aug 2019 05:34:08 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id BC8561AF112; Wed, 7 Aug 2019 05:34:00 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x775Y0DP063283 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 05:34:00 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x775Y0SF063282; Wed, 7 Aug 2019 05:34:00 GMT (envelope-from phk) To: Glen Barber cc: John Baldwin , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk In-reply-to: <20190806165614.GA41295@FreeBSD.org> From: "Poul-Henning Kamp" References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <63280.1565156040.1@critter.freebsd.dk> Date: Wed, 07 Aug 2019 05:34:00 +0000 Message-ID: <63281.1565156040@critter.freebsd.dk> X-Rspamd-Queue-Id: 463Ktn2yhCz4GBG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of phk@critter.freebsd.dk designates 130.225.244.222 as permitted sender) smtp.mailfrom=phk@critter.freebsd.dk X-Spamd-Result: default: False [-0.66 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.76)[-0.757,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; NEURAL_HAM_LONG(-0.85)[-0.852,0]; NEURAL_SPAM_SHORT(0.90)[0.903,0]; RCVD_COUNT_THREE(0.00)[3]; IP_SCORE(0.05)[ip: (0.09), ipnet: 130.225.0.0/16(0.04), asn: 1835(0.12), country: EU(-0.00)]; RCPT_COUNT_SEVEN(0.00)[7]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 05:34:10 -0000 -------- In message <20190806165614.GA41295@FreeBSD.org>, Glen Barber writes: >In my opinion, those that want the non-reproducible metadata included in >output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >src.conf. Turning off a sane default for the benefit of what I suspect >is likely a short list of use cases feels like a step in the wrong >direction. Seconded. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@freebsd.org Wed Aug 7 09:11:48 2019 Return-Path: Delivered-To: freebsd-hackers@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 558E7C3FFB for ; Wed, 7 Aug 2019 09:11:48 +0000 (UTC) (envelope-from brightiup.zhuo@gmail.com) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463Qjv1zw9z4RdZ for ; Wed, 7 Aug 2019 09:11:47 +0000 (UTC) (envelope-from brightiup.zhuo@gmail.com) Received: by mail-ot1-x329.google.com with SMTP id l15so101504780otn.9 for ; Wed, 07 Aug 2019 02:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OG+HE4rIZwho1uojBOIh96XLzh/T1wSKhDALKZGV8C8=; b=Hg8Vd5kbllb2NDTpEUpbhs+qqKaTu16mJ/ePB/R34U5JRPc2apix9kznug1808wttj DiWK5ctzoeFFO0GNZX19mZLXf0aClGPvkthnTmE64hH3mMoEcqr0rR3hFp7byq70K+Fm zb+h7BE7/NkE/a+O9Bo+bqvp1L8H8uFvNGMPhFfHLE2wUejhiOVLVO79r99cJFeD2UO7 eAZneyOkMlN3qnz+WzO3Ie7lsR1+IBwIhmM8lgCdaie0VMRWSMiFd47oUmqsm5IBTp+n lOTaJSA3f8MQRXfIsi3iogYG1t6MqC03xUON7Gpru/k89BdpF5DMmTL9dvBFwdwYPFsT pRCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OG+HE4rIZwho1uojBOIh96XLzh/T1wSKhDALKZGV8C8=; b=czAFv1CLeREL52PbYW3X+B1tc28MZ1aKplT0WPQAjxAQ/s26pkKxXlhvbG5Rt4UT84 L1Lb+7nmS2ukfVNa5DzsYANSEP/C/VPRj6vG1z+UfipmhhiG0uShVfHUS8lnx67rahrt aF4bLlx0tkiAjCtJZVAoizFHxgYu2jCBPRjpF9T58vdED4Xt762vsmS2mGTbWTUUR312 kDVRqLVkk110A5eXVzHMkQGqVDZ+9+UOirHxd3E9kNJHldE/RptrssAwvDMqGzEVAv3k HPeBe6CkZl3kan3435x7VOu5rcxWS5MZEKhLEzXGgOuEolawdoEkbAqmt/lpvNrTZuE9 gO8A== X-Gm-Message-State: APjAAAXgkOrjCMf7fyrI1IaEw/V/R700N2SWmFJ/JAFyYAFvF3tcve7L 464UZ7JbLTn/80a8NqoeKrF5ZJt2cOJmSrCcsByXGniBHpnMbA== X-Google-Smtp-Source: APXvYqwr30TUIpvVBz5c5Vp/h8JgaUQ3aHgmSO1kWT6E6ZX9dRUgg+V7Jzfxk+CnCCVn16ufqt5oaV2MxRtUHS7nJlk= X-Received: by 2002:a6b:6505:: with SMTP id z5mr8120989iob.295.1565169105499; Wed, 07 Aug 2019 02:11:45 -0700 (PDT) MIME-Version: 1.0 From: Liang Zhuo Date: Wed, 7 Aug 2019 17:11:34 +0800 Message-ID: Subject: Force kernel epoch calls To: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 463Qjv1zw9z4RdZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Hg8Vd5kb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of brightiupzhuo@gmail.com designates 2607:f8b0:4864:20::329 as permitted sender) smtp.mailfrom=brightiupzhuo@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.53), ipnet: 2607:f8b0::/32(-3.04), asn: 15169(-2.45), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[9.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 09:11:48 -0000 Hi list, I have a problem with *epoch* while I am trying to write an exploit of a FreeBSD kernel bug. Specifically, many schedules are managed by epoch system, like *if_d\* *estroy()* which destroys a *struct ifnet* object, and *in_pcbfree_**defered()* which destroys a *struct inpcb* object. My question is that these schedules will only be called just before the process exits by *epoch_call_task() *as follow: fork_exit() -> gtaskqueue_thread_loop() -> gtaskqueue_run_locked() -> epoch_call_task() -> if_destroy()/in_pcbfree_defered() But I need to control the time of freeing of those objects as better as synchronization. Do do I have any methods to force these calls in epoch system to be called in userspace? Thanks, Brightiup From owner-freebsd-hackers@freebsd.org Wed Aug 7 09:36:51 2019 Return-Path: Delivered-To: freebsd-hackers@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 92FEFC483F for ; Wed, 7 Aug 2019 09:36:51 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463RGp3DLjz4Sww for ; Wed, 7 Aug 2019 09:36:49 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D4A36260E17; Wed, 7 Aug 2019 11:36:46 +0200 (CEST) Subject: Re: Force kernel epoch calls To: Liang Zhuo , freebsd-hackers@freebsd.org References: From: Hans Petter Selasky Message-ID: Date: Wed, 7 Aug 2019 11:36:07 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 463RGp3DLjz4Sww X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.84 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.966,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-2.57)[ip: (-9.09), ipnet: 2a01:4f8::/29(-1.94), asn: 24940(-1.81), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 09:36:51 -0000 On 2019-08-07 11:11, Liang Zhuo wrote: > But I need to control the time of freeing > of those objects as better as synchronization. > Do do I have any methods to force these calls > in epoch system to be called in userspace? Did you have a look at the recently added epoch_drain_callbacks() function? --HPS From owner-freebsd-hackers@freebsd.org Wed Aug 7 09:56:59 2019 Return-Path: Delivered-To: freebsd-hackers@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 D5DCAC5045 for ; Wed, 7 Aug 2019 09:56:59 +0000 (UTC) (envelope-from brightiup.zhuo@gmail.com) Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463Rk23kXTz4V9B for ; Wed, 7 Aug 2019 09:56:58 +0000 (UTC) (envelope-from brightiup.zhuo@gmail.com) Received: by mail-ot1-x344.google.com with SMTP id d17so102008793oth.5 for ; Wed, 07 Aug 2019 02:56:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1GwVQYoBwGu/Oh4jMae3dTid4Xk+7vnj7vzKCWHuDT8=; b=Es+pDBExsRJ0fMdT+i5vYqzhPTiFYCNJINDdPQJLqcuFqkiOR3N/nEAkkxALdlUfgm VYU1LoIW6b3bFFjS56OO2mCTOwmRFBQg+mEmp7PCvRnObDu86MuDDadbjwvD30Y5AuQx kNP151/mTSj+GnXLjveHrrWQbhKQoPcY9bneitn0qFWcVklU+8fy2WsGS5BEOgYpCPI+ kjg6DEr8Ma7BmSXqGk7OhZlfcLfmyd6ELmqeh1E65Hz/j9xdOWuaIz9lrNkHahz27WUj eAOypcaa7Hx2K/JqNRC02XglBFini97vZT23Q9VpSwmzI2/f5T42VVvczfSk8RgdES6p kDeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1GwVQYoBwGu/Oh4jMae3dTid4Xk+7vnj7vzKCWHuDT8=; b=Y6/7BKij9HsdE2T9VsYPpEg6VCI9bcpb0wTB7RtAd2k3fT+/SSXAZBX7qU2svQAflB i/mxwlwhDXklHyKFWT/McljLR/D8xHnUYYO7S93jDRAF3Vl9mCAEH1WlPWOxGEAmup5H Xuu6wHAeb86vjQf2nqUCUmK3zyOrz1i8j7ZwO42PgjvV1tSOoGnSu+wmPCOZNct+5sz1 lwum1WE6Uit7xMK4Cx96h3QTK2hWuOltQGdEskS6Es5np3RBkgEhlMrHfkuaFa14Bhh6 GaXmIiy7DMcn2yN+45UOaEM5rybdqsmc2L3HxlBg1+URdgbr9GcVR1P5Oeyaqs+pff7x Gn9w== X-Gm-Message-State: APjAAAXPRsmrTR6P6h1AEoPMO1xJR0sedLF7PWic/7LDKKJXGrpRNDFY 1mYUAMJOx/bVgFcZJstp/XWigVh73y/RHjBdQH4= X-Google-Smtp-Source: APXvYqzQmWaUMmgkxvEQ8fVqWsR7FYndHwjBOmGwJpXQswWUmpPA1LBkt48UAO+R9b66IfB1wE90LL7Uk5Bwr8cWFZ0= X-Received: by 2002:a6b:6505:: with SMTP id z5mr8277824iob.295.1565171817149; Wed, 07 Aug 2019 02:56:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Liang Zhuo Date: Wed, 7 Aug 2019 17:56:46 +0800 Message-ID: Subject: Re: Force kernel epoch calls To: Hans Petter Selasky Cc: freebsd-hackers@freebsd.org X-Rspamd-Queue-Id: 463Rk23kXTz4V9B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Es+pDBEx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of brightiupzhuo@gmail.com designates 2607:f8b0:4864:20::344 as permitted sender) smtp.mailfrom=brightiupzhuo@gmail.com X-Spamd-Result: default: False [-3.99 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.99)[-0.989,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.30), ipnet: 2607:f8b0::/32(-3.04), asn: 15169(-2.44), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 09:56:59 -0000 Thanks for the quick reply. Actually, I just need some tricks in *userspace *to force the kernel to call those callbacks or some methods which could inform the kernel to call the callbacks. I am not writing a driver or kernel patch, it's just a userspace program which could escalate privilege to root. Thanks, Brightiup Hans Petter Selasky =E4=BA=8E2019=E5=B9=B48=E6=9C=887=E6= =97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=885:36=E5=86=99=E9=81=93=EF=BC=9A > On 2019-08-07 11:11, Liang Zhuo wrote: > > But I need to control the time of freeing > > of those objects as better as synchronization. > > Do do I have any methods to force these calls > > in epoch system to be called in userspace? > > Did you have a look at the recently added epoch_drain_callbacks() functio= n? > > --HPS > From owner-freebsd-hackers@freebsd.org Wed Aug 7 16:01:01 2019 Return-Path: Delivered-To: freebsd-hackers@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 20E48AE3AE; Wed, 7 Aug 2019 16:01:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463bp506H1z3Mt2; Wed, 7 Aug 2019 16:01:01 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 30A0A15377; Wed, 7 Aug 2019 16:01:00 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: Glen Barber Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Date: Wed, 7 Aug 2019 09:00:58 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <20190806165614.GA41295@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:01:01 -0000 On 8/6/19 9:56 AM, Glen Barber wrote: > On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >> Author: jhb >> Date: Sat Aug 3 01:06:17 2019 >> New Revision: 350550 >> URL: https://svnweb.freebsd.org/changeset/base/350550 >> >> Log: >> Flip REPRODUCIBLE_BUILD back to off by default in head. >> >> Having the full uname output can be useful on head even with >> unmodified trees or trees that newvers.sh fails to recognize as >> modified. >> >> Reviewed by: emaste >> Differential Revision: https://reviews.freebsd.org/D20895 >> > > I would like to request this commit be reverted. While the original > commit message to enable this knob stated the commit would be reverted > after stable/12 branched, I have seen no public complaints about > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > the benefit of disabling it by default -- why wouldn't we want > reproducibility?). > > To me, this feels like a step backwards, with no tangible benefit. > Note, newvers.sh does properly detect a modified tree if it can find > the VCS metadata directory (i.e., .git, .svn) -- I know this because > I personally helped with it. > > In my opinion, those that want the non-reproducible metadata included in > output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > src.conf. Turning off a sane default for the benefit of what I suspect > is likely a short list of use cases feels like a step in the wrong > direction. My arguments for flipping this in head (and head only) are that the data provided in uname -a when this is disabled is useful for development, and that in head we do tailor settings towards development (e.g. GENERIC in head vs GENERIC in stable). The logic to handle modified trees has an inherent assumption that I think is false, at least for my workflow and I suspect many others. I do builds and tests of kernels on separate machines (VMs or bare metal) from where I use VCS to manage sources so that a kernel crash doesn't toast my source tree. The trees are then shared to the build/test machines via NFS. As a result, the build/test machines are not always able to detect that the tree is modified either because a subset of the checkout is exported via NFS, or the VCS tool isn't installed on the build/test machines because they are generally barebones systems with only a base installed. This does mean that flipping the knob off doesn't provide all of the same info, but it does provide the path, and the path matters because 'kgdb -n last' uses it, and because if you use separate directories for separate projects (e.g. git worktrees), then the path tells you which test kernel you booted. (It is not uncommon for me to have several test projects in flight on a single test machine for different branches.) In the original discussion on arch, we collectively recognized that developer builds vs release builds were different and needed different defaults. The compromise reached at that time was to depend on the VCS to detect developer builds to choose the policy. What I have found is that in practice for at least my workflow that doesn't actually work. I posit that the majority of kernels built from head are developer builds, not releases, and that the default should cater to that. You could also always patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I think would give a more accurate sense of when builds are releases or not. However, I will yield to whatever the consensus is. -- John Baldwin From owner-freebsd-hackers@freebsd.org Wed Aug 7 16:24:28 2019 Return-Path: Delivered-To: freebsd-hackers@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 89730AF1DC for ; Wed, 7 Aug 2019 16:24:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463cK764vLz3QHB for ; Wed, 7 Aug 2019 16:24:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id y26so88960184qto.4 for ; Wed, 07 Aug 2019 09:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n/Fm0FCS2HN/Egvw1tVv9mTzTn+zuyiqDM0UJqSx95U=; b=KSwI6alfRd194gxkmaG1kk+I9U26/37IuXj5dRlnju7BtJ6UrZY8+lRHornhgVPL4o or6umLNauDh9MCLGjzTMq60mq5PxDu+JnqEa9Pddt5AuBjtv5Ti3cTY533Y0nKDF6G3o SC4xy3m/K0/gOKLY9ilKOCvfzVYba9XfO5f0/oMwF+uN2uJ2AjSnCHkvHZopRRg1IlOG C5TOi6uKPcNF0I1sErXlQh7ko+KC7vD6PysgiIXTxkQRZbx6HO53RHLPfggSu0kMT9dy 5UIWhqJsiUJLHqonyqLMNr0qTRdOP4semacgm4snwCy5/hBhjn82vr4BMprfg6IJmAt1 8oog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n/Fm0FCS2HN/Egvw1tVv9mTzTn+zuyiqDM0UJqSx95U=; b=IQtVaot6R9y0lXpoSlcDw3i6GRdq8Tx8mMR50cEZkxifAZm5Ttbhy2fmoRxYStuGpm XtVyOriNv0B67eQuVsNwblkQrfxYend9yDZyh7cR8pvNV8xjyZuPDq4+yOEXIaOUMhWl v1xlg/2Cqpk6NroOImAIuHFTMNQx+w0Vg+2fZLK5dHtJigDk40Mo00nOGyHprKh5n64R 7D/yqgF3jfpIOdPpc116aQTOVg4JdK03IRfTdY52Pqtq2Z7XeW8k+RNEZFMYTlLU/ykr nM4/LaYk2smMhf6ylBSvdVpGqlX263ldI8mEdpr2UKXRZqUTNdEc7MnBt1qpTLFU6qD9 0wbQ== X-Gm-Message-State: APjAAAXcNP2iktubLNPvpCQLQrDG3UaUEewaOCD5zU9OQjgakcqtPPYe ZRCl+fsOyMiYlrhC6xJ3VXykQYekcKXtfMD4Klvh9A== X-Google-Smtp-Source: APXvYqwPIS5Fu8qMlm+LvPNDUCqwirihb14S3rYhnkP7sFwj7QAWzcdjATO32i8RnBDgu5xmXkNYSo0ZL3aVlVU9gd8= X-Received: by 2002:ac8:2baa:: with SMTP id m39mr9005043qtm.242.1565195066321; Wed, 07 Aug 2019 09:24:26 -0700 (PDT) MIME-Version: 1.0 References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> In-Reply-To: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> From: Warner Losh Date: Wed, 7 Aug 2019 10:24:15 -0600 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: John Baldwin Cc: Glen Barber , svn-src-head , "freebsd-hackers@freebsd.org" , svn-src-all , src-committers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 463cK764vLz3QHB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=KSwI6alf; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::844) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.57 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.980,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.61)[ip: (2.49), ipnet: 2607:f8b0::/32(-3.03), asn: 15169(-2.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:24:28 -0000 On Wed, Aug 7, 2019 at 10:01 AM John Baldwin wrote: > On 8/6/19 9:56 AM, Glen Barber wrote: > > On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >> Author: jhb > >> Date: Sat Aug 3 01:06:17 2019 > >> New Revision: 350550 > >> URL: https://svnweb.freebsd.org/changeset/base/350550 > >> > >> Log: > >> Flip REPRODUCIBLE_BUILD back to off by default in head. > >> > >> Having the full uname output can be useful on head even with > >> unmodified trees or trees that newvers.sh fails to recognize as > >> modified. > >> > >> Reviewed by: emaste > >> Differential Revision: https://reviews.freebsd.org/D20895 > >> > > > > I would like to request this commit be reverted. While the original > > commit message to enable this knob stated the commit would be reverted > > after stable/12 branched, I have seen no public complaints about > > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > > the benefit of disabling it by default -- why wouldn't we want > > reproducibility?). > > > > To me, this feels like a step backwards, with no tangible benefit. > > Note, newvers.sh does properly detect a modified tree if it can find > > the VCS metadata directory (i.e., .git, .svn) -- I know this because > > I personally helped with it. > > > > In my opinion, those that want the non-reproducible metadata included in > > output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > > src.conf. Turning off a sane default for the benefit of what I suspect > > is likely a short list of use cases feels like a step in the wrong > > direction. > > My arguments for flipping this in head (and head only) are that the data > provided in uname -a when this is disabled is useful for development, and > that in head we do tailor settings towards development (e.g. GENERIC in > head vs GENERIC in stable). > > The logic to handle modified trees has an inherent assumption that I think > is false, at least for my workflow and I suspect many others. I do builds > and tests of kernels on separate machines (VMs or bare metal) from where I > use VCS to manage sources so that a kernel crash doesn't toast my source > tree. The trees are then shared to the build/test machines via NFS. As > a result, the build/test machines are not always able to detect that the > tree is modified either because a subset of the checkout is exported via > NFS, or the VCS tool isn't installed on the build/test machines because > they are generally barebones systems with only a base installed. This > does mean that flipping the knob off doesn't provide all of the same info, > but it does provide the path, and the path matters because 'kgdb -n last' > uses it, and because if you use separate directories for separate projects > (e.g. git worktrees), then the path tells you which test kernel you booted. > (It is not uncommon for me to have several test projects in flight on a > single test machine for different branches.) > > In the original discussion on arch, we collectively recognized that > developer builds vs release builds were different and needed different > defaults. The compromise reached at that time was to depend on the VCS > to detect developer builds to choose the policy. What I have found is that > in practice for at least my workflow that doesn't actually work. I posit > that the majority of kernels built from head are developer builds, not > releases, and that the default should cater to that. You could also always > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > think would give a more accurate sense of when builds are releases or not. > > However, I will yield to whatever the consensus is. > I'm with John here: the dirty tree stuff is too fragile for the diversity of development environments that are typical on -current, but not typical on -stable. We should not revert this. Warner From owner-freebsd-hackers@freebsd.org Wed Aug 7 16:51:29 2019 Return-Path: Delivered-To: freebsd-hackers@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 A9B86B070F; Wed, 7 Aug 2019 16:51:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 463cwJ11Jdz40Dw; Wed, 7 Aug 2019 16:51:27 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id vP9nh4MQlIhW9vP9ohW99b; Wed, 07 Aug 2019 10:51:26 -0600 X-Authority-Analysis: v=2.3 cv=FcFJO626 c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=8nJEP1OIZ-IA:10 a=FmdZ9Uzk2mMA:10 a=-o65W9qwAAAA:8 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=N3yCi80q97NF-fv9y40A:9 a=wPNLvfGTeEIA:10 a=1tiFkAoI0pxFi1YEbzhn:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 32E1030D; Wed, 7 Aug 2019 09:51:22 -0700 (PDT) Received: from slippy.cwsent.com (localhost [127.0.0.1]) by slippy.cwsent.com (8.15.2/8.15.2) with ESMTP id x77GpLho055590; Wed, 7 Aug 2019 09:51:21 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Received: from slippy (cy@localhost) by slippy.cwsent.com (8.15.2/8.15.2/Submit) with ESMTP id x77GpLBR055551; Wed, 7 Aug 2019 09:51:21 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <201908071651.x77GpLBR055551@slippy.cwsent.com> X-Authentication-Warning: slippy.cwsent.com: cy owned process doing -bs X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Scott Long cc: John Baldwin , Glen Barber , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk In-reply-to: References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Comments: In-reply-to Scott Long message dated "Wed, 07 Aug 2019 10:22:24 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 07 Aug 2019 09:51:21 -0700 X-CMAE-Envelope: MS4wfD3GEMNYB235v89UuPrZvPA9ooszLwKhIXaveTtUWgl+RCuKVOeL/pE9e45rnZRgsgWD7g4Vag8Zu15QptSiER7CC9YU86hVxP4C1p05p6yOQY+FJs+L OYzvjmcQRTuIHCYZrECAI2PusblOheyxMT+Av9pKt2VygOcB4Lwh03mrJC26ocgCGAJlEow363Ir8uj7pOV0gQr8wxnqMdN8kHpPq6LKP1Iv6kqv3CWUtHsK 1RVTU4ImPrOsDiaCjHmpF9kYMq8wNlvNiuRa+Gq4XGQPHucaFvJIbk58XqQoKUZKkFeuQxXgcECrtY8vuz5devsZx3Dt2jkJm1kgZQcmpV8TF4LqpFirNuro KUWBf3Q/gBHttAZIFON7Z9vP2bmgiW8riW0zc5cKGeHpiJLwjYoz6RdZkSh9eTC8C6C1/ZEI X-Rspamd-Queue-Id: 463cwJ11Jdz40Dw X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 64.59.136.138) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-5.02 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLYTO_EQ_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998,0]; RCVD_IN_DNSWL_NONE(0.00)[138.136.59.64.list.dnswl.org : 127.0.5.0]; RCPT_COUNT_SEVEN(0.00)[8]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.42)[ip: (-6.37), ipnet: 64.59.128.0/20(-3.18), asn: 6327(-2.48), country: CA(-0.09)]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:51:29 -0000 In message , Scott Long writes : > > > > On Aug 7, 2019, at 10:00 AM, John Baldwin wrote: > > > > On 8/6/19 9:56 AM, Glen Barber wrote: > >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >>> Author: jhb > >>> Date: Sat Aug 3 01:06:17 2019 > >>> New Revision: 350550 > >>> URL: https://svnweb.freebsd.org/changeset/base/350550 > >>> > >>> Log: > >>> Flip REPRODUCIBLE_BUILD back to off by default in head. > >>> > >>> Having the full uname output can be useful on head even with > >>> unmodified trees or trees that newvers.sh fails to recognize as > >>> modified. > >>> > >>> Reviewed by: emaste > >>> Differential Revision: https://reviews.freebsd.org/D20895 > >>> > >> > >> I would like to request this commit be reverted. While the original > >> commit message to enable this knob stated the commit would be reverted > >> after stable/12 branched, I have seen no public complaints about > >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > >> the benefit of disabling it by default -- why wouldn't we want > >> reproducibility?). > >> > >> To me, this feels like a step backwards, with no tangible benefit. > >> Note, newvers.sh does properly detect a modified tree if it can find > >> the VCS metadata directory (i.e., .git, .svn) -- I know this because > >> I personally helped with it. > >> > >> In my opinion, those that want the non-reproducible metadata included in > >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > >> src.conf. Turning off a sane default for the benefit of what I suspect > >> is likely a short list of use cases feels like a step in the wrong > >> direction. > > > > My arguments for flipping this in head (and head only) are that the data > > provided in uname -a when this is disabled is useful for development, and > > that in head we do tailor settings towards development (e.g. GENERIC in > > head vs GENERIC in stable). > > I’m in favor of how this works at the moment. It was a bit jarring to me w > hen > the reproducible build flag was turned on and I lost all of the metadata that > I subconsciously use during development. I think that what John has done > is an appropriate compromise and is in line with how we’ve treated similar > development-facilitating features in the past, i.e. WITNESS/INVARIANTS, > malloc-debug. Agreed. As with John, I have a combination of git and svn trees on various machines. Some install to different partitions on physical hardware while others are tested in VMs. The extra information is handy in keeping track of what is installed where. End users who are concerned about reproducible builds in what we might call pseudo-production will probably not use WITNESS or INVARIANTS either. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. From owner-freebsd-hackers@freebsd.org Wed Aug 7 16:58:10 2019 Return-Path: Delivered-To: freebsd-hackers@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 8AC9FB0D77; Wed, 7 Aug 2019 16:58:10 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463d4239F0z40xL; Wed, 7 Aug 2019 16:58:10 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.5] (unknown [181.52.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id C031315A91; Wed, 7 Aug 2019 16:58:09 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: src-committers@freebsd.org Cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> From: Pedro Giffuni Organization: FreeBSD Message-ID: <86621ce5-3a8d-2e22-f146-3b0cc8252124@FreeBSD.org> Date: Wed, 7 Aug 2019 11:58:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:58:10 -0000 On 07/08/2019 11:00, John Baldwin wrote: > On 8/6/19 9:56 AM, Glen Barber wrote: >> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >>> Author: jhb >>> Date: Sat Aug 3 01:06:17 2019 >>> New Revision: 350550 >>> URL: https://svnweb.freebsd.org/changeset/base/350550 >>> >>> Log: >>> Flip REPRODUCIBLE_BUILD back to off by default in head. >>> >>> Having the full uname output can be useful on head even with >>> unmodified trees or trees that newvers.sh fails to recognize as >>> modified. >>> >>> Reviewed by: emaste >>> Differential Revision: https://reviews.freebsd.org/D20895 >>> >> I would like to request this commit be reverted. While the original >> commit message to enable this knob stated the commit would be reverted >> after stable/12 branched, I have seen no public complaints about >> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >> the benefit of disabling it by default -- why wouldn't we want >> reproducibility?). >> >> To me, this feels like a step backwards, with no tangible benefit. >> Note, newvers.sh does properly detect a modified tree if it can find >> the VCS metadata directory (i.e., .git, .svn) -- I know this because >> I personally helped with it. >> >> In my opinion, those that want the non-reproducible metadata included in >> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >> src.conf. Turning off a sane default for the benefit of what I suspect >> is likely a short list of use cases feels like a step in the wrong >> direction. > My arguments for flipping this in head (and head only) are that the data > provided in uname -a when this is disabled is useful for development, and > that in head we do tailor settings towards development (e.g. GENERIC in > head vs GENERIC in stable). > > The logic to handle modified trees has an inherent assumption that I think > is false, at least for my workflow and I suspect many others. I do builds > and tests of kernels on separate machines (VMs or bare metal) from where I > use VCS to manage sources so that a kernel crash doesn't toast my source > tree. The trees are then shared to the build/test machines via NFS. As > a result, the build/test machines are not always able to detect that the > tree is modified either because a subset of the checkout is exported via > NFS, or the VCS tool isn't installed on the build/test machines because > they are generally barebones systems with only a base installed. This > does mean that flipping the knob off doesn't provide all of the same info, > but it does provide the path, and the path matters because 'kgdb -n last' > uses it, and because if you use separate directories for separate projects > (e.g. git worktrees), then the path tells you which test kernel you booted. > (It is not uncommon for me to have several test projects in flight on a > single test machine for different branches.) > > In the original discussion on arch, we collectively recognized that > developer builds vs release builds were different and needed different > defaults. The compromise reached at that time was to depend on the VCS > to detect developer builds to choose the policy. What I have found is that > in practice for at least my workflow that doesn't actually work. I posit > that the majority of kernels built from head are developer builds, not > releases, and that the default should cater to that. You could also always > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > think would give a more accurate sense of when builds are releases or not. > > However, I will yield to whatever the consensus is. +1 keeping metadata in head. From owner-freebsd-hackers@freebsd.org Wed Aug 7 16:58:12 2019 Return-Path: Delivered-To: freebsd-hackers@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 58C87B0DA7 for ; Wed, 7 Aug 2019 16:58:12 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 463d4324wzz40xM for ; Wed, 7 Aug 2019 16:58:10 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 46669260195; Wed, 7 Aug 2019 18:58:07 +0200 (CEST) Subject: Re: Force kernel epoch calls To: Liang Zhuo Cc: freebsd-hackers@freebsd.org References: From: Hans Petter Selasky Message-ID: Date: Wed, 7 Aug 2019 18:57:27 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 463d4324wzz40xM X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.87 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.999,0]; RCPT_COUNT_TWO(0.00)[2]; IP_SCORE(-2.57)[ip: (-9.10), ipnet: 2a01:4f8::/29(-1.94), asn: 24940(-1.82), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:58:12 -0000 On 2019-08-07 11:56, Liang Zhuo wrote: > Thanks for the quick reply. > > Actually, I just need some tricks > in *userspace *to force the kernel to > call those callbacks or some methods > which could inform the kernel to call > the callbacks. > > I am not writing a driver or kernel patch, > it's just a userspace program which could > escalate privilege to root. > > Thanks, > Brightiup Hi, If you want to force these callbacks, you'll need to iterate over all the CPU's and do: GROUPTASK_ENQUEUE(DPCPU_PTR(epoch_cb_task)); --HPS From owner-freebsd-hackers@freebsd.org Wed Aug 7 20:27:50 2019 Return-Path: Delivered-To: freebsd-hackers@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 738B9B6BA6; Wed, 7 Aug 2019 20:27:50 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463jjy2YpKz4HkD; Wed, 7 Aug 2019 20:27:50 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.5] (unknown [181.52.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id 59B6A17353; Wed, 7 Aug 2019 20:27:49 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: svn commit: r350550 - head/share/mk To: rgrimes@freebsd.org Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org References: <201908072012.x77KCObt089132@gndrsh.dnsmgr.net> From: Pedro Giffuni Organization: FreeBSD Message-ID: Date: Wed, 7 Aug 2019 15:27:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <201908072012.x77KCObt089132@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:27:50 -0000 On 07/08/2019 15:12, Rodney W. Grimes wrote: >> On 07/08/2019 11:00, John Baldwin wrote: >>> On 8/6/19 9:56 AM, Glen Barber wrote: >>>> On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: >>>>> Author: jhb >>>>> Date: Sat Aug 3 01:06:17 2019 >>>>> New Revision: 350550 >>>>> URL: https://svnweb.freebsd.org/changeset/base/350550 >>>>> >>>>> Log: >>>>> Flip REPRODUCIBLE_BUILD back to off by default in head. >>>>> >>>>> Having the full uname output can be useful on head even with >>>>> unmodified trees or trees that newvers.sh fails to recognize as >>>>> modified. >>>>> >>>>> Reviewed by: emaste >>>>> Differential Revision: https://reviews.freebsd.org/D20895 >>>>> >>>> I would like to request this commit be reverted. While the original >>>> commit message to enable this knob stated the commit would be reverted >>>> after stable/12 branched, I have seen no public complaints about >>>> enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see >>>> the benefit of disabling it by default -- why wouldn't we want >>>> reproducibility?). >>>> >>>> To me, this feels like a step backwards, with no tangible benefit. >>>> Note, newvers.sh does properly detect a modified tree if it can find >>>> the VCS metadata directory (i.e., .git, .svn) -- I know this because >>>> I personally helped with it. >>>> >>>> In my opinion, those that want the non-reproducible metadata included in >>>> output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their >>>> src.conf. Turning off a sane default for the benefit of what I suspect >>>> is likely a short list of use cases feels like a step in the wrong >>>> direction. >>> My arguments for flipping this in head (and head only) are that the data >>> provided in uname -a when this is disabled is useful for development, and >>> that in head we do tailor settings towards development (e.g. GENERIC in >>> head vs GENERIC in stable). >>> >>> The logic to handle modified trees has an inherent assumption that I think >>> is false, at least for my workflow and I suspect many others. I do builds >>> and tests of kernels on separate machines (VMs or bare metal) from where I >>> use VCS to manage sources so that a kernel crash doesn't toast my source >>> tree. The trees are then shared to the build/test machines via NFS. As >>> a result, the build/test machines are not always able to detect that the >>> tree is modified either because a subset of the checkout is exported via >>> NFS, or the VCS tool isn't installed on the build/test machines because >>> they are generally barebones systems with only a base installed. This >>> does mean that flipping the knob off doesn't provide all of the same info, >>> but it does provide the path, and the path matters because 'kgdb -n last' >>> uses it, and because if you use separate directories for separate projects >>> (e.g. git worktrees), then the path tells you which test kernel you booted. >>> (It is not uncommon for me to have several test projects in flight on a >>> single test machine for different branches.) >>> >>> In the original discussion on arch, we collectively recognized that >>> developer builds vs release builds were different and needed different >>> defaults. The compromise reached at that time was to depend on the VCS >>> to detect developer builds to choose the policy. What I have found is that >>> in practice for at least my workflow that doesn't actually work. I posit >>> that the majority of kernels built from head are developer builds, not >>> releases, and that the default should cater to that. You could also always >>> patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I >>> think would give a more accurate sense of when builds are releases or not. >>> >>> However, I will yield to whatever the consensus is. >> +1 keeping metadata in head. > I am conflicted on this one, and I think there is a reasonable argument > on both sides, but from what I have read here this appears to be mostly > the kernel that is at issue, loss of the meta data from newvers.sh in > the kernel is infact a PITA, even on stable or production release > systems. > > I propose a compromise, add 2 knobs: > WITHOUT_REPRODUCIBLE_KERNEL (aka get your metadata in uname) > WITH_REPRODUCIBLE_USERLAND (aka reproducible userland) > > WITH{,OUT}_REPRODUCIBLE_BUILD overrides both, for backwards compat, > and neither should be defined by default. Too complex IMHO. Either the system is reproducible or it isn't. > Somehow set WITH_REPRODUCIBLE_KERNEL for builds of GENERIC > for releases/snapshots, but do not ship the system with it > set (I can here a growl from Glen on this) Thus we build > a reproducible kernel and ship it with the system but if > the user builds a kernel it gets meta data to indicate it > is no longer a stock kernel. > FYI, upon finding I could not figure out what kernel I was running > after installing 12.0 release I turnd off REPRODUCIBLE on my kernel > build VM for 12.0. I do leave it on if I am building userland. > > Thoughts? Among other things, reproducible builds implies that pkg upgrades are smaller. I see it makes sense to make releases, and in fact -stable, completely reproducible. For -current I am fine with it not being reproducible, All just IMHO. Pedro. From owner-freebsd-hackers@freebsd.org Fri Aug 9 03:35:15 2019 Return-Path: Delivered-To: freebsd-hackers@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 CCD14BB021; Fri, 9 Aug 2019 03:35:15 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [IPv6:2001:19f0:300:2185:123::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 464W8f2hssz40Jv; Fri, 9 Aug 2019 03:35:14 +0000 (UTC) (envelope-from jamie@catflap.org) Received: from donotpassgo.dyslexicfish.net (donotpassgo.dyslexicfish.net [104.207.135.49]) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5) with ESMTP id x793Z6as074460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Aug 2019 04:35:07 +0100 (BST) (envelope-from jamie@donotpassgo.dyslexicfish.net) Received: (from jamie@localhost) by donotpassgo.dyslexicfish.net (8.14.5/8.14.5/Submit) id x793Z5WP074456; Fri, 9 Aug 2019 04:35:05 +0100 (BST) (envelope-from jamie) From: Jamie Landeg-Jones Message-Id: <201908090335.x793Z5WP074456@donotpassgo.dyslexicfish.net> Date: Fri, 09 Aug 2019 04:35:05 +0100 Organization: Dyslexic Fish To: jhb@freebsd.org, gjb@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org Subject: Re: svn commit: r350550 - head/share/mk References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> In-Reply-To: <20190806165614.GA41295@FreeBSD.org> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [104.207.135.49]); Fri, 09 Aug 2019 04:35:07 +0100 (BST) X-Rspamd-Queue-Id: 464W8f2hssz40Jv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=catflap.org; spf=pass (mx1.freebsd.org: domain of jamie@catflap.org designates 2001:19f0:300:2185:123::1 as permitted sender) smtp.mailfrom=jamie@catflap.org X-Spamd-Result: default: False [-3.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:dyslexicfish.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_SHORT(-0.71)[-0.710,0]; DMARC_POLICY_ALLOW(-0.50)[catflap.org,none]; RCPT_COUNT_SEVEN(0.00)[7]; IP_SCORE(-0.40)[ipnet: 2001:19f0::/38(-1.74), asn: 20473(-0.18), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0::/38, country:US]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 03:35:15 -0000 Glen Barber wrote: > after stable/12 branched, I have seen no public complaints about > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > the benefit of disabling it by default -- why wouldn't we want > reproducibility?). I track stable. I had no need to complain because I could edit src.conf and add WITHOUT_REPRODUCIBLE_BUILD=YES Please don't remove this ability thinking no-one minds reproducible builds.. I personally think they are pointless. Cheers, Jamie