From nobody Sun Apr 23 11:47:01 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q462D09SFz45Jb6 for ; Sun, 23 Apr 2023 11:47:32 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "vtr.rulingia.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q462B4vk5z3xhb for ; Sun, 23 Apr 2023 11:47:30 +0000 (UTC) (envelope-from peter@rulingia.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com; dmarc=pass (policy=quarantine) header.from=rulingia.com Received: from server.rulingia.com (2001-44b8-31fc-0d00-593b-ba5f-4612-4edb.static.ipv6.internode.on.net [IPv6:2001:44b8:31fc:d00:593b:ba5f:4612:4edb]) by vtr.rulingia.com (8.16.1/8.16.1) with ESMTPS id 33NBlBAX032397 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Sun, 23 Apr 2023 21:47:18 +1000 (AEST) (envelope-from peter@rulingia.com) DKIM-Filter: OpenDKIM Filter v2.10.3 vtr.rulingia.com 33NBlBAX032397 X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.16.1/8.16.1) with ESMTPS id 33NBl16x092387 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 23 Apr 2023 21:47:01 +1000 (AEST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.16.1/8.16.1/Submit) id 33NBl1CI092386 for current@freebsd.org; Sun, 23 Apr 2023 21:47:01 +1000 (AEST) (envelope-from peter) Date: Sun, 23 Apr 2023 21:47:01 +1000 From: Peter Jeremy To: current@freebsd.org Subject: ntpd fails on recent -current/arm64 Message-ID: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0qGyOudtw1C7AOBZ" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp X-Spamd-Result: default: False [-2.51 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_SPAM_LONG(0.97)[0.967]; NEURAL_HAM_SHORT(-0.85)[-0.850]; DMARC_POLICY_ALLOW(-0.50)[rulingia.com,quarantine]; NEURAL_SPAM_MEDIUM(0.27)[0.274]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MLMMJ_DEST(0.00)[current@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[peter]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4Q462B4vk5z3xhb X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --0qGyOudtw1C7AOBZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, some change in the kernel has made ntpd stop working on my arm64 test box. (My amd64 test box is a couple of days behind so I'm not sure if it's arm-specific). What I've identified so far: * The problem is in the kernel, not userland. * The impact seems to be limited to ntpd (in particular, ntpdate works). * ntpd appears to be correctly exchanging NTP packets with peers. * ntpd is not responding to "ntpq -p" queries * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime I've looked through the commits and, beyond much of netinet being roto-tilled, I can't see anything obvious. Is anyone else seeing anything similar? Can anyone suggest where to look next? --=20 Peter Jeremy --0qGyOudtw1C7AOBZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmRFGq9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQ2Ng//SLlrU+ieIOj3eRyiwjsLL8mfZcXIUOD8wO4foTdKy9QfJkJM/MBX5yEW S4EP1p+fAG/a24Iz1i+bX3Q46DSCK5zj5S2LvwYIc7Ub4ujpHXOZ52IKHW6cFunT 8e6r5tFt69CltmVWv4FWwm3VHDpwh3oduR5S6wjZxtlhjwIvek60DAcxP0OwisUY 69MgrKF6p58a7hlCsng2kwxC2ntWqlSrY2krvj+dqmbVQvYMpxzyaO0tRZauaX3D n1gb09isI0B7G5EnmsfZ+P736hHtdkPr4/1gcOiN6XSGdY4yjyWTfHyNdXCYmTlj l7K9MnP1bWl3HkwgFdKZ4yAkAvgPES2YLa0XstkItzOtJcjQQcRCi5Lj/0bdNEXv cr2UoV9z47I7m2WetTu8GcF0es0cOEamV45knKptjy06dKB2QqMgaEGWu7WmDIAB opNrGQC6ByhxUlrYI+nwHzsCWCgYr+OYGfHRWviQXjqBPTWciuZ+8Hz0uk0eqQwD rCF5lrjnBdec4bk/InoLV8ALWPHE+xnjC4yXCbf71AMn0/D2gCMALZ3WKDx81psr 0XNsFufEE6eKDOmnERkYlCG1GveqQjcfjbmWlk7ttVWMfWHtEbSZ9GjfCgJ2bWYV OoIvBcrgwIlxCImvc7Ie73aPKfp1wxmqS8LRh0UiczU6GXEcupM= =PSgK -----END PGP SIGNATURE----- --0qGyOudtw1C7AOBZ-- From nobody Sun Apr 23 12:29:01 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q46yT5K1xz45LvD for ; Sun, 23 Apr 2023 12:29:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-19.consmr.mail.gq1.yahoo.com (sonic306-19.consmr.mail.gq1.yahoo.com [98.137.68.82]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q46yS1YPwz46Ln for ; Sun, 23 Apr 2023 12:29:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=NcB2zEFw; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.82 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682252958; bh=Fc3ys4ECbyj6vCz6QQAZ1MHbzOChkvr04uvRIDpbnd0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=NcB2zEFwDmZhl9qHJc/IOdYgx7QjqLQfaUSZIWccVmG8hyCw8SrII1QHzA8DGQA864W3t7VZGayYILOaH/8XJdXFHQ77TQHCjKWL9KWcwW38BgNQlGOgB97YbIaWgKCy+hWPMGmVhP0k3DlLNvNvep70LhAsA4fndPZF3JeLvnveJjMAX5PelFHivgdAuEUCU2LBymoUDIrEYA+O4D9+e6sDwzN174NlPHfXTGvTeVog8yqlnaFN6XxtTfGJFewv4pXHMmHmowDbXfsUiyPn7Vap4jK6slqrEBBlbmcuCZmyPXmjlbTTIaSnuStslrNGkktJJHbSG2suOLzCV8DRvw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682252958; bh=kvluOEYorHhWFWHWq7FfOabYxEPOtHTVASwzPImrmuH=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=BbGc/LWDK10NgWFX8Nb6HdGHIVXevyoeLXSv8FOqueco5FnRIeXf7O9MmXLCXvnKhBdlUmDTdVttBIwH7D6eJC5U+6MVoKj33DaeEnCo9j3RTTheAM5mFz3xJepNQmVEMqvreUGjy3aBgDTPdeZv/Jao5G/6hCxbs3sxz5NGh1141zVp5sXtAwz3meln7dSgKg7CT5zXfro6Re4L+grlT0rHm+s9INF4c6/LEG9Gxeca34GIHS6A41QHOjdfftVjeTTqO8Zb1dEIdaefrk2N/Tz/wWgtpM8D/rBr5tZ8GyMAkN7IPFfEFC7upKAeOlyACgl6EsBW9h9sQ9RumHGNng== X-YMail-OSG: 6tOtXoUVM1n.tq6vzt762_B5CotBf0WXzrG7BiLufICquFrwrLvpY_YqRguutA1 onPPXD4Xq_LHgf923AXOVeDLZympw6xZY5iQSBcZQcXOlBNTMcwqE.95zxJSgUbjRP5hDCfJsAJz 8a_Crn7.IYYfRgXlcIhY8QH.ZUdH9DfcQseqrma.eFawWIEQqyAnh3J4qKQLtrgtcXl6NmV5JdIO Y8AjJ3WUj0McyrPQTJnkCUJppwEHKxVbpWaI_rPQgVmTInMRLkZEMfVt5BMAeQ0HCLAh4ALG4XG2 ZI9joRyx25f5Zgmsr10tWwVc92VTuPCyX_3Dqh48DR9N__UUDo5HToddwjkxUZxpmibNudHEQSmz KIQv3hrHezL6frYu_JSTfDj7xKbg0qX7PIX7FTTuIBW.hQd4aPye13YclnEFYSQStXNTSO28trh_ xFlfhCKNA0n0TH3gPY5Nc2Fmxho2OCR8lbK8rxIEtnzP2xfeDkzyq8TZt8.DaPLFaGUt9l6lpT7S dQj7C2O4fWZy2Vb_izQZSO6TtIhLlnTVeELTe5QZECOnwztCN4KBzWU3riXQmQu4yRS6MXqtrDz1 7pr0nv7PRyh7CjykAAyw9ds7itoUSpn9sXghqQCmGAnKXWq0X0oD2labu_Fe6mSw2HZ7rQTHVZ1a BkMe.bqHf.LAIu0xYNmA7glfJMnCE_3L5F4xs98XifMZ5m.ZlwO_Vgc_JVBEJt8sh5iV85b_GtAd fwyZTJVnyXIFTE7nPNM7xdNv5cV..2F2ToAB7YOmiosoy6_62UErdeySYUfT56VEGkxPF_KxcrUC H6qS4Yk2Y7VlOQV748fvIEaNy8QHL4kursHjPvJBHK1WtutpLU7_bkRwwybQ4iU9eC81iLZUnEIU .hnbYzLx8c3tO28beFq0__h9IqO0PBcqIU8RqZ_RUOd1f6zPRHrHepYM0jWQIp2IoSnlBDMsVqv9 Xkodp9WfdBZGBJAZYwIRnSDSvhrF8lZ09ZSoaUPQZoshgos7VOICxvS4bvEE57H23Cxy2sNCVGIf VgkQnTz8r60AmQR9P5hutx_oIaOJMjvHS3kwZW0ME8RtuivVpfvEsOWgHoPXPIYRtWV58i5S1_Uk gJtj_mG8BueuuyXJNr.7oEfIODdcO42Z0i4d8W.0BBquvDTcDt9vcjFyEfmhSS38LUjCcBTlZtOC lXL61IVjmcJj1glie.dD_O5wyBXjBAAcd3ORVwuzn2UpQh.zwUwsiO57VXjC.FTN2X.8yEqfjQf9 s7ClbYkTbiVjSMIOJ6ytWMp2Oq8Mf3l3ldm6MMXqu15AzpvHEjNhqPSS.g.BLtc1Iiws5sNhRC5x xNXBfpbr.jYEmJcBCcehgkDVczMRxo5HJhhqN_vCIvLYM9qbUmAaL0oRm0BJfvkI_Cdzf7FVKoD6 9XODybt1d27.rzp6skqyLdG5R.4jtTAtnDb18dD4.Hsn0v3Xrbp.rEsewdiSPn0PcSknRN8TwvNI H7X17nLSPY5dRjPc17eHrUGxjy9jbGI8rjV52z_jNRlDHVT4V4lyyb5NQu6sMKJMrceYZoy4yQlZ UmqzKreBvs7s8.2lLit21.IXH0DzS46GyyW7sOsGK2PZSKsAYeQXzc_1O9Pw6xWDp_pFrwZSZP5Y cw_A2VhwqravuwY6fJF_ccZK_YKe7vNfiycw.huG8N0IayoV92CJe_Hj4_j2roWTEdV_fHO5t9.x bTFF_.R4J9oI9qRvFuqS922AR5S9AzT_l5qqU4gj9IvU6qSI4qm_tXL8jQIwlyrIJwZzKr_R59K3 krPPKxGc9im0Be9a1OTfbcfyyfpRT.SMG731rLBZ.xPlslkBCL4jieRkyb6naMWZmiKqyC3z5M0t Fdyc8tesiSwOzYK4ZwJyowUT0MvXmu3pkksOlrF0rNRhviFK8oTfPkhOiJ3RbRt2knr7hNox4jFW 2yOreZZZRM_mCKg88trQPvWEn4iNvW9fThu_WN2XTHnStUCgaFbLG5QF6Rhx9xg8sspVNKnF5ukl _3mCL8kTAU5N42kxgqbxINO9Bj1JlPDB5AM91VBPgLBQyqyqu5mSzzyyUzscQHr_CIvYQa3KaR3T Y.Vd2AQ6M_DJvokRn48khKSIVxnhXgdh.u5Js2lKkrOddlDUJSkOEUE6Mi_bZgUgdYzrdqo8zSUd TTDu04HWrLQV2BNnQmqa9.8kmhG8shd5AHaXp97VQTJzN3N1Wyhn2xL_wqZiSwgrcq2ZmlNWJd2J K4C2I_UOyg5qv3ExarFB8lv72fEF8vO462qbSlQ75EZzS.p163GwjCRTOBJPGMd0snHys7j..G.w - X-Sonic-MF: X-Sonic-ID: f8445c28-384e-4257-84f7-c04364a3d7f1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Apr 2023 12:29:18 +0000 Received: by hermes--production-bf1-5f9df5c5c4-84ds6 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 40f8fa5d7a432aef331124b2902928d3; Sun, 23 Apr 2023 12:29:13 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: RE: ntpd fails on recent -current/arm64 Message-Id: Date: Sun, 23 Apr 2023 05:29:01 -0700 To: peter@rulingia.com, Current FreeBSD X-Mailer: Apple Mail (2.3731.400.51.1.1) References: X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.82:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.82:from] X-Rspamd-Queue-Id: 4Q46yS1YPwz46Ln X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Peter Jeremy write on Date: Sun, 23 Apr 2023 11:47:01 UTC : > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, I see the problem at main-n262371-72ef722b2a34-dirty (aarch64), in the middle of your range. So in the smaller range is: Thu, 20 Apr 2023 . . . =E2=80=A2 git: 607bc91d90a3 - main - vmrun.sh: Fix a typo in usage() = Mateusz Piotrowski=20 =E2=80=A2 Re: git: 373b95976bce - main - netstat: document that PCB = information can't be read from corefiles tuexen_at_freebsd.org =E2=80=A2 git: de1dde5dfea4 - main - network.subr: adjust regex for = wlans_xxxxx rc.conf entries Bjoern A. Zeeb =E2=80=A2 Re: git: 8dcf3a82c54c - main - libc: Implement bsort(3) a = bitonic type of sorting algorithm. Brooks Davis=20 =E2=80=A2 git: 7db7bfe1a7b9 - main - iwlwifi: quieten more compiler = warnings Bjoern A. Zeeb =E2=80=A2 git: 35f7fa4ac1ae - main - LinuxKPI: 802.11: improve = assertion and tkip code Bjoern A. Zeeb =E2=80=A2 git: fdb987bebddf - main - inpcb: Split PCB hash tables = Mark Johnston=20 =E2=80=A2 git: 3e98dcb3d574 - main - inpcb: Move inpcb matching = logic into separate functions Mark Johnston=20 =E2=80=A2 git: 7b92493ab1d4 - main - inpcb: Avoid inp_cred = dereferences in SMR-protected lookup Mark Johnston=20 =E2=80=A2 git: 5fd1a67e885e - main - inpcb: Release the inpcb cred = reference before freeing the structure Mark Johnston=20 =E2=80=A2 git: dd9059b3e9a1 - main - makefs: set cd9660 Rock Ridge = timestamps for . and .. Ed Maste=20 =E2=80=A2 git: 0df4d8ad7a1b - main - Add jobs.mk to allow for = target-jobs Simon J. Gerraty =E2=80=A2 git: d1f4c44aa8af - main - x86: Move i386 ppireg.h to x86 = Dmitry Chagin=20 =E2=80=A2 git: de4da6cd04bf - main - x86: Move i386 timerreg.h to = x86 Dmitry Chagin=20 =E2=80=A2 git: 8fe4f8f7a75f - main - Fix building host tools for = host Simon J. Gerraty =E2=80=A2 git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Jessica Clarke=20 =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Brooks Davis=20 =E2=80=A2 git: 1a149d65baed - main - dtrace: get rid of uchar_t = types Mark Johnston=20 =E2=80=A2 git: 080e56a6c98c - main - dtrace: expose = dtrace_instr_size() to userland and implement it for riscv Mark Johnston=20= =E2=80=A2 git: 75081b9ed8e6 - main - dtrace: use dtrace_instr_size() = in the riscv dtrace_subr.c Mark Johnston=20 =E2=80=A2 git: 1fef7abdc76b - main - dtrace: add register bindings = for RISC-V Mark Johnston=20 =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 =E2=80=A2 git: 47e888f8363d - main - Remove a few more references to = riscv64sf. John Baldwin=20 =E2=80=A2 git: 048606bec11f - main - perfmon(4): Use a C89 function = definition for a SYSINIT. John Baldwin=20 =E2=80=A2 git: bf043855213c - main - arm: Use C89 function = declaration for db_read_bytes. John Baldwin=20 =E2=80=A2 Re: git: c1e813d12309 - main - hwpmc: Correct selection of = Intel fixed counters. Alexander Motin=20 =E2=80=A2 git: 72ef722b2a34 - main - dpaa2: add console support for = FDT based systems Bjoern A. Zeeb . . . > some change in the kernel has made ntpd stop working on my arm64 test > box. (My amd64 test box is a couple of days behind so I'm not sure if > it's arm-specific). >=20 > What I've identified so far: > * The problem is in the kernel, not userland. See below for the truss output oddity of doing 2 sendto's (no recvfrom) instead of sendto then recvfrom. =46rom an machine with an older context that works: . . . socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 1 (0x1) recvfrom(3,"\^V\M^A\0\^A\^F\^X\0\0\0\0\0\^X"...,516,0,NULL,0x0) =3D 36 = (0x24) fstat(1,{ mode=3Dcrw--w---- ,inode=3D138,size=3D0,blksize=3D4096 }) =3D = 0 (0x0) ioctl(1,TIOCGETA,0x735a71d98c58) =3D 0 (0x0) >=20 > * The impact seems to be limited to ntpd (in particular, ntpdate = works). > * ntpd appears to be correctly exchanging NTP packets with peers. > * ntpd is not responding to "ntpq -p" queries I noticed that "ntpq -c as" end up doing: . . . open("/etc/services",O_RDONLY|O_CLOEXEC,0666) =3D 3 (0x3) fstat(3,{ mode=3D-rw-r--r-- ,inode=3D14579,size=3D72600,blksize=3D72704 = }) =3D 0 (0x0) lseek(3,0x0,SEEK_CUR) =3D 0 (0x0) lseek(3,0x0,SEEK_SET) =3D 0 (0x0) read(3,"#\n# Network services, Internet "...,72704) =3D 72600 (0x11b98) close(3) =3D 0 (0x0) socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) localhost: timed out, nothing received write(2,"localhost: timed out, nothing re"...,39) =3D 39 (0x27) ***Request timed out write(2,"***Request timed out\n",21) =3D 21 (0x15) exit(0x0) process exit, rval =3D 0 Note the: socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) I've no use of PF set up. Your "ntpq -p" also gets such: socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) localhost: timed out, nothing received write(2,"localhost: timed out, nothing re"...,39) =3D 39 (0x27) ***Request timed out write(2,"***Request timed out\n",21) =3D 21 (0x15) exit(0x0) process exit, rval =3D 0 > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime >=20 > I've looked through the commits and, beyond much of netinet being > roto-tilled, I can't see anything obvious. >=20 > Is anyone else seeing anything similar? Yes. I noticed via systems without a RTC that I'd set up to have ntpd fix the times on. The times stopped being fixed. > Can anyone suggest where > to look next? See the truss output above? (I'm no expert in the area. I'm just noting the odd sendto sendto sequence without any recvfrom.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Apr 23 12:34:45 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q474r6Bqwz45Mt9 for ; Sun, 23 Apr 2023 12:34:52 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q474r4dZhz4HqS for ; Sun, 23 Apr 2023 12:34:52 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 33NCYkgm013220; Sun, 23 Apr 2023 07:34:46 -0500 (CDT) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1682253286; bh=cZx/0xFbmbov91lf0pVlYYzHByErIRikCECmXGTJNwU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=qNckYW6f0PD1x6dNxO3w111yJTLsfTmlRnFCXb5ZRCVIhLkNXQ2tipfyKPsMnAYC5 VcKvsRR6QjUPD91qq6PkszoMK/oVKhfEhZ2LUsdigtMXzue4c6FjiMaP0WjmrE/7NN AXGUehR8GVaWsMMLjjwVprhny8Xs015UD8FvLa6z2zyJfvwJippTpsPao1u9KEHth3 1SuFquq83lZvnRcJwn5wi6Fi7BPFSJwXTKXsRfhDN6tUmjijySZjM3tDkamX8r4jVN 0zOufLd1t/9aP2aDJJqroybn9v63XzdrCy/5ePC9sxiR728765aPb7lYBqV9kXHUWU qIZpTy5oztkMA== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id kgs1C+YlRWSiMwAAs/W3XQ (envelope-from ); Sun, 23 Apr 2023 07:34:46 -0500 From: Mike Karels To: Peter Jeremy Cc: current@freebsd.org Subject: Re: ntpd fails on recent -current/arm64 Date: Sun, 23 Apr 2023 07:34:45 -0500 X-Mailer: MailMate (1.14r5964) Message-ID: <33479649-394F-429D-A71B-12B3BC379149@karels.net> In-Reply-To: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Q474r4dZhz4HqS X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.16.0.0/14, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 23 Apr 2023, at 6:47, Peter Jeremy wrote: > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > some change in the kernel has made ntpd stop working on my arm64 test > box. (My amd64 test box is a couple of days behind so I'm not sure if > it's arm-specific). > > What I've identified so far: > * The problem is in the kernel, not userland. > * The impact seems to be limited to ntpd (in particular, ntpdate works). > * ntpd appears to be correctly exchanging NTP packets with peers. > * ntpd is not responding to "ntpq -p" queries > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime I updated an amd64 system yesterday, and it is broken too. > I've looked through the commits and, beyond much of netinet being > roto-tilled, I can't see anything obvious. The netinet changes seem likely to be the culprit. ntpd seems to be receiving the requests but isn’t responding. Trivial testing indicates that named is working, so UDP isn’t completely broken. > Is anyone else seeing anything similar? Can anyone suggest where > to look next? Mark may have an idea. Finding a simpler example would be helpful, but I’m not sure what we’re looking for. Mike From nobody Sun Apr 23 12:42:54 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q47GV5y9lz45NZr for ; Sun, 23 Apr 2023 12:43:14 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-20.consmr.mail.gq1.yahoo.com (sonic310-20.consmr.mail.gq1.yahoo.com [98.137.69.146]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q47GS5HHKz4WDf for ; Sun, 23 Apr 2023 12:43:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=A6Q+AwcI; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682253790; bh=6AqhNPoQoutZG7yu0ofNDUcs/vjdTvWJDBOD0JhejVU=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=A6Q+AwcI6u9Y49DagJLROwDEnAopE++mIegPFe2CZUrmeomZbjaKsGBdnXz8o00Nr93tmayaaA9dM0VzD7Y9yMlmzQB5iyiqfg6mys09hNv/NpH3hmq7+adcU01y+sH1kfSOQ7Q/6FClQ3LTlx3WpDFHDk4dIMREXlP0VhjacTeN/jeqrVlkqWywN8gnYGE1NmYzJqncWcXpcR+LKX1QOE9t4I+7D2eE04PwSwHiP4/eF10PqWgGZG81xyVl7w5qHuPVl0m3NlQAWdmNdqa2/keMyDFH7+BdDqZU3cvs9qc96EExAdWbAI78/wXTynDLSt6zAv8V86Y7LbDOnWnxNg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682253790; bh=w4Wn2eI00kVYRSZzQ3BYotoSdnDNIPHtTABHJFADykl=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=JpJG3AKewmU4H35pZ0W0ndlp9FnL5ylm3DjfcfYkfQlJycHaso/IvSqGliMIiwaZjsrfmPsVnAYfg5MjWUO/iOmRWq/2AtefU0uXCWNeT+YMgrz+EOZkFdU2PPGeuZ1Adt7fxkEV1MbJ/+/HZbucoyvvdV47/Sm430n/ovAMR95hEmooiKnlB+zenPKBw9M61AgUtn78UcqOmRbKydw2QcdvIxQYkS/sBxJxC85E7rnZmVgOCAu6vp4OZo92N9K6VSQQvtKDWG8BL+PLUPhgK0SKywU+yijKmQENvfiQeA0vI3FWFUFcHExqWqico6JM/vsbxP4Il3ROPNcnA+tD7g== X-YMail-OSG: h2pw5MMVM1k67PjtEu.pcR74vueq5iwmU0slZqAqImgxJjxUdC0hWrMqkKqGqw4 VqNECUTEUDH5M5Qwre44QzFlHN4GPxVljIh6sh75T3iFiAyayiAuusyKaNdQKXcKqs0FSbuQjl9j 0jhSkfXrYzrPLnM_LBIMR5Sv0_5wn9n8_Fnf2UjB7GtCm4ysQ_ONFNkTO4LFOiwanJ3WGnhTH4xE Wo6hi2VanCbAz3EgtaKYOS_PDsAm4Nyoq6VxBqWmpVNs2rvqqvcBHTin0NtgZpGmeusevx2B3bLy mDk35TyD0hl0037U5Z3l80q5K4rHTWF22zbz2SrTLD8BqWqVJqzXWx4x2ex3bkZf._tcatsPcOH6 NeHaKCXBZMIprbZ4wkBqJkcPF3B4b3vsGc.iIU36jFeGph_K1ig89yO5Rl2g5VPri2nIBxd5ahPy O.aiIJq_sttbcrU0y.niyG8s4xJ.nfT9iF_lwsHyBA2ectp1DNcOOkz0bSEnrv490mEjtvcS7fxt .9hDUSHjHQRdcrcJUBOjKmDMqspzRibvvr0LgS3g0Vf3H8YySHh0z1KoKB0k1ZeKCfMXvbXzKrlf t3G.apr4aoDkpyfD3f0VuIFhHPo0i9OaXbYKSUGvnMs5C7Fd1aodrbG7VudDJ6Of4iG9tx.Q166p byVR4lL92ynMAQxx1buGpl2dOIg9uGXUOPVeoIzKDmUlexh.9_VbB6.4hYTLk7kR1L6fg8mSIdL1 3hnWEVKRg5VDjatR_wsrAvK..obGcDLNX.VUME4LZzHPyDg_d.tz2R1N82NR9KtvMTTEZyTjSgfC XIl.JRXj9cVj9syUjnQjc7GqA2hwTi6zmqAS7tw0bmGUpaB_lK9pRhK9DFdQ_FiyvNCXCkLANMrP CePokNUJdJc6MmYhLqtKmz.ROGVHkSRdkZRNPMlQiOTV.v02CxR90p3va3Ffp4LpIOpM0YNMcnN_ 4E.xro3iE8acqloz733nwpt9pLhyFiJgy_6HTygDR758Cph2FR6GGJ9yODP9rSTBlBhYKz0EDxr1 zGHnTzMqdh3_2r1ky0IweTf94kKYR854RkuXht5Mp5Zqn6W0VSU38QZhu1jWugXF15aGpEqTlP9b KQYoW8H0CaDxd8qD_Myh7qEcbipTL5tasrqO0X1EkNnioBhN6UHWqE0pJpkpLzIaPgr7UeAL.HsK Cr_oWjPwstj_M.uUVfBQCaHe7B3.ReAmFNxaCbm3QR0F_v3PYs_3jvWx8gbgw_io2HEAFkjLHU.d HG7GLvkVIlC0ftFbmcjiWog4tp0QkinEiMDfYNZqr46OklEVH1D8PGu0fHPu4NAL8mCBPh3o_1vI qiGnVnJlhWXpxYnSsDu_buhVXC0yQ9IVD_8u5X6XcXVTSphK0M90gu_3jgR3nsqwz6HGEog_EElM dh_PnPipVLLSBsAkb03S0kYNmhnZuMNALP6g0hIhORbc2ZD.wXxzcL2TCTKRt3ip9QRWD0XHHq8V E4fwEBOpL0sNEJfnw3GMe.0DxDGUk5rOiJ55.4nwCdlkU4XEuEdlpy65Kg_tQbYzZ5Y7uSUXoleY 6t0gObXFZmiu273jln1VgCZ0cj5xSsWsSUNnsz8xIqHUMvrU5zZdIVplhbK4CnYOmn4Cr63ky.8t FJP5OUIH_cSsdefYc9tE2Rm0m6oIidSSEsqzyO.opj8_e4iLD07WWJshghvDU5ghVwV_hU_1.NJW yNDM8NIdcT19YWor3T1Xkyqt6Xc1az51lfNHDdzLBLIxGUznAu2.2ipjADYs0Lr6z4xrji7P1aty 0YZ9HylBlrUqaGNf7ZrQgxxqjcGTMgdPx9TPi0RueRMmDrJDPec1u1CrgFVCI5olCIs_VgWfEvzB 2.xWrizRzxmUrwLz4Ht6pM8X5fd7hBXOSboXHMwsYjzIrvOe0xcd.hKBq7DwPd.SB0eDzyBBpe8I jIBYUItL_b8ik_8j_wgcpD7XGxXTHAXVmAZMJ.g7JHPXndQ_rububNJ3jmSNAOP6QNYFVuBvBLJS 72WC5lUUcVaK3FnDDT16qjwe9KUL5wM_.4ib4K71hfojj4_9j4_Dfudijnrnv6CGb7J4QIWLmRJk bkbTcqXmK4CC4FP1JafixQSTnoSkE7VfcsXXqSwFmdeUTssRrT29RkvIN07z.1qWHJEBxcmFnm6n ne1ECv6ksFSb2fOpvT6L66G8cIY8cac3t87roaMsLyke2LRTmgc8FCXBtMnDIKQbT76HaapB7gSM fWRk32qYw9KiJmS4.nD2s71elssr2zAKV5x2wapf3OouEcsb.wB4plTYhP1ZKBkzElzeMXSoFfEq T X-Sonic-MF: X-Sonic-ID: db8d2018-09cb-477c-9401-2da3d1a621c6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Apr 2023 12:43:10 +0000 Received: by hermes--production-ne1-7dbd98dd99-gdhzk (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 47a26aba6789bb49b1c1f5602c88b19c; Sun, 23 Apr 2023 12:43:06 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: ntpd fails on recent -current/arm64 Date: Sun, 23 Apr 2023 05:42:54 -0700 References: To: peter@rulingia.com, Current FreeBSD In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spamd-Result: default: False [-2.71 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-0.21)[-0.209]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.146:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4Q47GS5HHKz4WDf X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N On Apr 23, 2023, at 05:29, Mark Millard wrote: > Peter Jeremy write on > Date: Sun, 23 Apr 2023 11:47:01 UTC : >=20 >> Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, >=20 > I see the problem at main-n262371-72ef722b2a34-dirty (aarch64), > in the middle of your range. So in the smaller range is: >=20 > Thu, 20 Apr 2023 > . . . > =E2=80=A2 git: 607bc91d90a3 - main - vmrun.sh: Fix a typo in = usage() Mateusz Piotrowski=20 > =E2=80=A2 Re: git: 373b95976bce - main - netstat: document that PCB = information can't be read from corefiles tuexen_at_freebsd.org > =E2=80=A2 git: de1dde5dfea4 - main - network.subr: adjust regex for = wlans_xxxxx rc.conf entries Bjoern A. Zeeb > =E2=80=A2 Re: git: 8dcf3a82c54c - main - libc: Implement bsort(3) a = bitonic type of sorting algorithm. Brooks Davis=20 > =E2=80=A2 git: 7db7bfe1a7b9 - main - iwlwifi: quieten more compiler = warnings Bjoern A. Zeeb > =E2=80=A2 git: 35f7fa4ac1ae - main - LinuxKPI: 802.11: improve = assertion and tkip code Bjoern A. Zeeb > =E2=80=A2 git: fdb987bebddf - main - inpcb: Split PCB hash tables = Mark Johnston=20 > =E2=80=A2 git: 3e98dcb3d574 - main - inpcb: Move inpcb matching = logic into separate functions Mark Johnston=20 > =E2=80=A2 git: 7b92493ab1d4 - main - inpcb: Avoid inp_cred = dereferences in SMR-protected lookup Mark Johnston=20 > =E2=80=A2 git: 5fd1a67e885e - main - inpcb: Release the inpcb cred = reference before freeing the structure Mark Johnston=20 > =E2=80=A2 git: dd9059b3e9a1 - main - makefs: set cd9660 Rock Ridge = timestamps for . and .. Ed Maste=20 > =E2=80=A2 git: 0df4d8ad7a1b - main - Add jobs.mk to allow for = target-jobs Simon J. Gerraty > =E2=80=A2 git: d1f4c44aa8af - main - x86: Move i386 ppireg.h to x86 = Dmitry Chagin=20 > =E2=80=A2 git: de4da6cd04bf - main - x86: Move i386 timerreg.h to = x86 Dmitry Chagin=20 > =E2=80=A2 git: 8fe4f8f7a75f - main - Fix building host tools for = host Simon J. Gerraty > =E2=80=A2 git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Jessica Clarke=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Brooks Davis=20 > =E2=80=A2 git: 1a149d65baed - main - dtrace: get rid of uchar_t = types Mark Johnston=20 > =E2=80=A2 git: 080e56a6c98c - main - dtrace: expose = dtrace_instr_size() to userland and implement it for riscv Mark Johnston=20= > =E2=80=A2 git: 75081b9ed8e6 - main - dtrace: use = dtrace_instr_size() in the riscv dtrace_subr.c Mark Johnston=20 > =E2=80=A2 git: 1fef7abdc76b - main - dtrace: add register bindings = for RISC-V Mark Johnston=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 > =E2=80=A2 Re: git: bb8e8e230d94 - main - Revert "libc: Implement = bsort(3) a bitonic type of sorting algorithm." Hans Petter Selasky=20 > =E2=80=A2 git: 47e888f8363d - main - Remove a few more references = to riscv64sf. John Baldwin=20 > =E2=80=A2 git: 048606bec11f - main - perfmon(4): Use a C89 function = definition for a SYSINIT. John Baldwin=20 > =E2=80=A2 git: bf043855213c - main - arm: Use C89 function = declaration for db_read_bytes. John Baldwin=20 > =E2=80=A2 Re: git: c1e813d12309 - main - hwpmc: Correct selection = of Intel fixed counters. Alexander Motin=20 > =E2=80=A2 git: 72ef722b2a34 - main - dpaa2: add console support for = FDT based systems Bjoern A. Zeeb > . . . >=20 >> some change in the kernel has made ntpd stop working on my arm64 test >> box. (My amd64 test box is a couple of days behind so I'm not sure if >> it's arm-specific). >>=20 >> What I've identified so far: >> * The problem is in the kernel, not userland. >=20 > See below for the truss output oddity of doing > 2 sendto's (no recvfrom) instead of sendto then > recvfrom. =46rom an machine with an older context > that works: >=20 > . . . > socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) > connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 1 (0x1) > recvfrom(3,"\^V\M^A\0\^A\^F\^X\0\0\0\0\0\^X"...,516,0,NULL,0x0) =3D 36 = (0x24) > fstat(1,{ mode=3Dcrw--w---- ,inode=3D138,size=3D0,blksize=3D4096 }) =3D = 0 (0x0) > ioctl(1,TIOCGETA,0x735a71d98c58) =3D 0 (0x0) >=20 >>=20 >> * The impact seems to be limited to ntpd (in particular, ntpdate = works). >> * ntpd appears to be correctly exchanging NTP packets with peers. >> * ntpd is not responding to "ntpq -p" queries >=20 > I noticed that "ntpq -c as" end up doing: >=20 > . . . > open("/etc/services",O_RDONLY|O_CLOEXEC,0666) =3D 3 (0x3) > fstat(3,{ mode=3D-rw-r--r-- ,inode=3D14579,size=3D72600,blksize=3D72704 = }) =3D 0 (0x0) > lseek(3,0x0,SEEK_CUR) =3D 0 (0x0) > lseek(3,0x0,SEEK_SET) =3D 0 (0x0) > read(3,"#\n# Network services, Internet "...,72704) =3D 72600 = (0x11b98) > close(3) =3D 0 (0x0) > socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) > connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > localhost: timed out, nothing received > write(2,"localhost: timed out, nothing re"...,39) =3D 39 (0x27) > ***Request timed out > write(2,"***Request timed out\n",21) =3D 21 (0x15) > exit(0x0) process exit, rval =3D 0 I should not have written: > Note the: socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) >=20 > I've no use of PF set up. It just confuses things because the older context also makes that call. It is really what follows (sendto->sendto vs. sendto->recvfrom) that matters from what I can tell. Sorry for the misdirection. > Your "ntpq -p" also gets such: >=20 > socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) > connect(3,{ AF_INET 127.0.0.1:123 },16) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > sendto(3,"\^V\^A\0\^A\0\0\0\0\0\0\0\0",12,0,NULL,0) =3D 12 (0xc) > select(4,{ 3 },0x0,0x0,{ 5.000000 }) =3D 0 (0x0) > localhost: timed out, nothing received > write(2,"localhost: timed out, nothing re"...,39) =3D 39 (0x27) > ***Request timed out > write(2,"***Request timed out\n",21) =3D 21 (0x15) > exit(0x0) process exit, rval =3D 0 >=20 >=20 >=20 >> * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime >>=20 >> I've looked through the commits and, beyond much of netinet being >> roto-tilled, I can't see anything obvious. >>=20 >> Is anyone else seeing anything similar? >=20 > Yes. I noticed via systems without a RTC that I'd set up > to have ntpd fix the times on. The times stopped being > fixed. >=20 >> Can anyone suggest where >> to look next? >=20 > See the truss output above? (I'm no expert in the area. > I'm just noting the odd sendto sendto sequence without > any recvfrom.) >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Sun Apr 23 13:45:33 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q48fW5kBPz45y06 for ; Sun, 23 Apr 2023 13:45:39 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q48fT11T9z3Ltl for ; Sun, 23 Apr 2023 13:45:37 +0000 (UTC) (envelope-from imb@protected-networks.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=h78UaWj0; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net; dmarc=pass (policy=reject) header.from=protected-networks.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:content-language:references :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1682257533; bh=Hs8F6qOxarrMR0mFfLYr70caNwad5Yq4nQTp xDb5SAI=; b=h78UaWj0YUeboEXgWYx4N97srNlv2W6wxP6cL7dikJmWuOacNJyT 4vwjjQx0iufdKBdCK6hqemjQPy6frGkpbFA7OJ9Ew1n5qGpfjsTFZTSMvGNwGwjT kvdd56+cf7z+kNyZTmNDfm5W1ZnoCFmhkvYq7wGfrsHC4VeJ9dWQ4ZA= Received: from [IPV6:2001:470:8d59:2:f21f:afff:fe66:957e] (toshi.auburn.protected-networks.net [IPv6:2001:470:8d59:2:f21f:afff:fe66:957e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id AF101327F4 for ; Sun, 23 Apr 2023 09:45:33 -0400 (EDT) Message-ID: Date: Sun, 23 Apr 2023 09:45:33 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: ntpd fails on recent -current/arm64 To: freebsd-current@freebsd.org References: Content-Language: en-NZ From: Michael Butler In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2001:470:8d59:2:f21f:afff:fe66:957e:server fail,202.12.127.228:server fail]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[protected-networks.net:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Q48fT11T9z3Ltl X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 4/23/23 07:47, Peter Jeremy wrote: > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > some change in the kernel has made ntpd stop working on my arm64 test > box. (My amd64 test box is a couple of days behind so I'm not sure if > it's arm-specific). [ .. snip .. ] While I can't suggest a fix, I discovered this workaround until one is found; edit /etc/ntp.conf to include .. interface ignore wildcard interface listen lo0 interface listen em0 .. or whichever interfaces are required on the host, Michael From nobody Sun Apr 23 13:48:02 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q48jL4hB4z45yDW for ; Sun, 23 Apr 2023 13:48:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q48jL1fPRz3QGL for ; Sun, 23 Apr 2023 13:48:06 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-760f29073b4so106378239f.2 for ; Sun, 23 Apr 2023 06:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682257685; x=1684849685; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :from:to:cc:subject:date:message-id:reply-to; bh=CsCKgDCkTc30M5ZRyumaccGbsm8TSHCjr8st8tjRn5I=; b=AuoQIFOHNNX/6KPrkIBBZ+581UEmzOWeyWvbXGCsujsBhG9erLKSkxV7p3BrF6KGsR uv94uFCQqzpCth6T77w4qy6V5V+pWRlweAV9mLoyLv2NH7aG+VMFA+QZ3hKzFJhBUnHH Pfh4S+8+feLeP5dLaGoJnYS7ZKlSkOdCbMu4N+ZDVmO3GfuaZCkxsPB4gJWEatIk9hti uDJqfGSNwgWdnRsTLFcopHFX+l9Y6qEPFUCbiM34jd02v6U/2YoLCt4aL92Tq5yhqOVy 6sh6DtoJuc4dlwsOJJXxwU1emux4zBvlLYb98IfNcVpErA4pGkeHPl/Dh3/yHgyaPch8 Ws8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682257685; x=1684849685; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CsCKgDCkTc30M5ZRyumaccGbsm8TSHCjr8st8tjRn5I=; b=SB3lnO3lRHCZH+O6pcroKMqD/2LWSSlX3cQICL3NvvmKq+/rAJAYCYFVN1ci6FMgWD ju9zImGrQMr3NT1eoFv8OzHd5UH/qz/SqD6FoTQHYOzPCkk4BDjr0NHG0huaqiYQT6pD IxSCXRrmv5lXcKnxkIJzedYQd8ZgmEmIETuXb4DN8+Efr7T+xhgyAYhJ/ee7fxNxRL3+ 90DO44t6wcq4mZqiYVUIIk0YOddfRfBfYl5kN8MgjYJqzyIlQGu9ue2H8w0n0PSr7jKp X0E+KATmsTOI4FOiEe10i6CYV8NrV0oB4wLekny0hITY2iK7yy27w4OeHPANxczrghVP fSMw== X-Gm-Message-State: AAQBX9dn2XIX5VdQmKXAj5ElaMawHhvySQ4EgKvuKMwqyLVKzYbY6gpx 5VhdZU5e9Jeqr9zNjwod2H37mt3HQ4g= X-Google-Smtp-Source: AKy350ZRB9X0670ku9uQzY6dVESVgLdp4XtIf+XdeHEv0sOfl/zKIwKL8DeYjjrZ8YxCwKmQJ5dZag== X-Received: by 2002:a05:6e02:109:b0:328:a112:f981 with SMTP id t9-20020a056e02010900b00328a112f981mr3325154ilm.4.1682257684908; Sun, 23 Apr 2023 06:48:04 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id r20-20020a92c5b4000000b0032addae8ab1sm2474866ilt.69.2023.04.23.06.48.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Apr 2023 06:48:04 -0700 (PDT) Date: Sun, 23 Apr 2023 09:48:02 -0400 From: Mark Johnston To: Mike Karels Cc: Peter Jeremy , current@freebsd.org Subject: Re: ntpd fails on recent -current/arm64 Message-ID: References: <33479649-394F-429D-A71B-12B3BC379149@karels.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <33479649-394F-429D-A71B-12B3BC379149@karels.net> X-Rspamd-Queue-Id: 4Q48jL1fPRz3QGL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 23, 2023 at 07:34:45AM -0500, Mike Karels wrote: > On 23 Apr 2023, at 6:47, Peter Jeremy wrote: > > > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > > some change in the kernel has made ntpd stop working on my arm64 test > > box. (My amd64 test box is a couple of days behind so I'm not sure if > > it's arm-specific). > > > > What I've identified so far: > > * The problem is in the kernel, not userland. > > * The impact seems to be limited to ntpd (in particular, ntpdate works). > > * ntpd appears to be correctly exchanging NTP packets with peers. > > * ntpd is not responding to "ntpq -p" queries > > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime > > I updated an amd64 system yesterday, and it is broken too. > > > I've looked through the commits and, beyond much of netinet being > > roto-tilled, I can't see anything obvious. > > The netinet changes seem likely to be the culprit. ntpd seems to > be receiving the requests but isn’t responding. Trivial testing > indicates that named is working, so UDP isn’t completely broken. > > > Is anyone else seeing anything similar? Can anyone suggest where > > to look next? > > Mark may have an idea. Finding a simpler example would be helpful, > but I’m not sure what we’re looking for. I can reproduce the problem. A small example would still be useful, so that we can turn it into a regression test case. From nobody Sun Apr 23 15:14:43 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4BdL41R3z463tx for ; Sun, 23 Apr 2023 15:14:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4BdL3Xlvz3hB1 for ; Sun, 23 Apr 2023 15:14:46 +0000 (UTC) (envelope-from markjdb@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-qt1-x82b.google.com with SMTP id d75a77b69052e-3ef6e8493ebso3096101cf.2 for ; Sun, 23 Apr 2023 08:14:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682262885; x=1684854885; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=C0GA8RZTlrR30oFVXBA2rLgd8yoOo+xVlgB3CB5aqcs=; b=OvjxNMBhUDpQ0/aTsPdpeJz6dyN/WkT6tpN8INq0PFugzFcZQe11SWJIXvH/0rWbd3 Hurq7qdE0CTZVWDc5nP+bzYyuOmHq35Gmn7NXbLHL3p7Dc3aOjAsINHRF10hpFFW4kLq FcHKWxYXRVARjP860naMyLsJLxzwfQuUYD2EdNUMnReCTMfcdoihpiYdGARIwF+V8I+/ 2lSlMiufF1DMDYknkcoJDae72OLZuT7z1fYZDNlpo4Kr7MNkcA1IEkQyN503rUazzL6J XyFaNjWuBiQvu1mFYNFYXOZy0zU8E+6t4LRDkowg2TvRI1r1moCRnr5IxlzEs5mn99Rt Nmug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682262885; x=1684854885; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C0GA8RZTlrR30oFVXBA2rLgd8yoOo+xVlgB3CB5aqcs=; b=LQgQM3NNKAyMK32+Sb2OlVTElpoH98jliSJis/C8QJW3ojgTol4ef549uIXZwRN63J YZhbxEm/Ae92JEthJcZslxG6+8MXTNw8eSmDZGeiByHUmVotMuORaox7U8VPlE4nRLUv bKqo0Lmgxw7YQTOFGiO45GD1LV9r+jU6YuSQYCVnPOhg1tgMy0O7a/Xe6nkJm3a2bXrP buqhdhJTLtX276dWa1dlWda5y19YaUtZD3HBD801ViR4TwkDSJa/eIns05FgmehOA99I VgJalT6uAGc2kK7LYA2GjEkiDCuiYT9H7RdHc4Fs5nzYe/hC/vNmGWSIUm0z6bTS/Z9a g7nw== X-Gm-Message-State: AAQBX9dJwukPmPtiRZTY8G8nIdQdHt78ngQ9IpZyoIYAtxvburxuqbUn AcATDoGTMsqIWHanIavpBsrdLqgBCn0= X-Google-Smtp-Source: AKy350aA6RXL42RE+EMsIcMm6HY1KdsSWygc2KIsDhu8nhVEJ/yXZgxnz98CBBqgLHsnNUcORLzMug== X-Received: by 2002:ac8:7fd6:0:b0:3e4:d1c0:36a9 with SMTP id b22-20020ac87fd6000000b003e4d1c036a9mr15222247qtk.48.1682262885517; Sun, 23 Apr 2023 08:14:45 -0700 (PDT) Received: from nuc (192-0-220-237.cpe.teksavvy.com. [192.0.220.237]) by smtp.gmail.com with ESMTPSA id ee27-20020a05620a801b00b0073b878e3f30sm2085244qkb.59.2023.04.23.08.14.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 23 Apr 2023 08:14:45 -0700 (PDT) Date: Sun, 23 Apr 2023 11:14:43 -0400 From: Mark Johnston To: Peter Jeremy Cc: current@freebsd.org Subject: Re: ntpd fails on recent -current/arm64 Message-ID: References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4Q4BdL3Xlvz3hB1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sun, Apr 23, 2023 at 09:47:01PM +1000, Peter Jeremy wrote: > Somewhere between c283016-g607bc91d90a3 and c283077-g7f658f99f7ed, > some change in the kernel has made ntpd stop working on my arm64 test > box. (My amd64 test box is a couple of days behind so I'm not sure if > it's arm-specific). > > What I've identified so far: > * The problem is in the kernel, not userland. > * The impact seems to be limited to ntpd (in particular, ntpdate works). > * ntpd appears to be correctly exchanging NTP packets with peers. > * ntpd is not responding to "ntpq -p" queries > * ntp_gettime and ntp_adjtime both return TIME_ERROR to ntptime > > I've looked through the commits and, beyond much of netinet being > roto-tilled, I can't see anything obvious. > > Is anyone else seeing anything similar? Can anyone suggest where > to look next? This patch fixes the problem for me: https://reviews.freebsd.org/D39771 From nobody Mon Apr 24 03:08:33 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4VTH0Q2bz46smJ for ; Mon, 24 Apr 2023 03:08:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4VTF5Gk1z45dv for ; Mon, 24 Apr 2023 03:08:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=P45oLZ87; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682305727; bh=0mgmbwcwvExVUWuypTkoIneTO9B6YZ229wwjKJC0i2E=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=P45oLZ87IvlBeXRBNQNbM0Ds8KvTD8V4mOkrmq/yJ+B8fJsqFE1D5YUC8TJxZtl3Ov9y1QtHH6XmKLChdoeqCw8+shidSzyHs4/hc07gN7aw4QTs+OeaHNRTtpm9iMD3q74/IFXVxtChbaPGEQ/c8N10U5cfNF3skUuncbxwjn6knG627YRV+V4rZvMIxGmTCv0TvavfIOjT8eCd7WQAr+9pARpMEIcNiCbZ8VWPTPRU8qw0ypfGuCPcqFb1l6MqTO3zhx32oWwZe6bRlT+MC318BdAM2xFDKiGM791K4IdQZ1s94ca6uNee2CGPzsRvfzfn/JwuUYzgri168GgeXA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682305727; bh=Sa0UB1w8hQX1UXCbgIzolpdyv+W/FuMLp/Jln+DvmiC=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=IezTA57qO32LFK8+8QXnv7r+jJOFqF66S7SKmRwxHWqYH/DWfaBsFARk9pm76QBkrG+6Xa0GJ5KYzTbO441LuQgqX1PYSEswcKTDFjy97QZc4nCmKgbmFauC/CzBsKot3xJr5VWHutRwz1sGnNX/iQZN2DnzCUND0tB3Pb/yxbZSCd7UHXEjmeeSxmdBh6al/qrURWPaxZYp6hxHH60UZo50Cf/pnSjFKC//NTa+T7yvD8GNcPrWmqkWR1mmB0KP8o3UfiLEqwLQ8J3/in7X4a3x1UHtAmvPqKcMi/BH6S+rpWjNTc/4axwWUWw5H7L/KQRyjkHbGysYbuTkg2OSlQ== X-YMail-OSG: 1yjGH_cVM1mArm6aO5qnA54CO43nypnZ_uRi0bHjQPqaLDBrhlcnYUV81HnlTB4 W9046prtiDOxZj7yBaj2BBVYJ48SXRiRQV565q7KvLpio94rXw1fFepxoHpSxaAXhbYvOcExF0F5 yRLVmwQPElwGR6SbW0Y7rNiayGVDBtKwwC3lpDanrLvpKxHrVnVIG7sdmBfghhxSJR_mHjmbENN_ R9qfHPxB_fmv_r9bObWXfVq8hSHrMcVtOLoGqQVqg5yj8W2m3RstnmP6OOcfWZS5sO9ZSnFtsMyO seNRDNRHZO1cx0oz4aYLIvHoH4ZOS7o1SgEX.zOCNr_FNAx_VhQAYNDLKJLi5ghUOm4YsP0y.P7H LtxErBVg9tu_BTJPlSl7yf9NI6L70IZZNHVaksQB95SPEcAAqZ2_LoYX0mnK5bwVkP6uUK_tqgpD OuQ4S18StwiOJuDOpL7jEww1rjNw72FJVMI9E65rozHLMBf9Dtjp6WSwh2pTO12e1b3LYxkWAwTC 2tRL9jfodhfDWazLggleypgEK08n_rR9y.y8PgfBvIZATrvd1ReDP_XF_mL3kb_l0V25LFc4S.2A jZQMG9Y3GuCP9H8bwDnTH5pW3OLcdvN1hAkzx7JrGjuOkhaag.1VTE8wKPdxa9TXKsrgWdcMBuG4 j3p.SKBktuR1u0VV1x_PDJk9901bm3ckVK0TpQXQNid0tpl0iaPWU0hEHRFqJv_4xGtEGq5xwoTI _YyGFtFa468qcYhbYQwV3jb8hCRDx22gfFqK9B_Rhf_IZ2T3W10bx7g7EdVJp06ZodzPVrSx9WtY Wh.Ck2OyfkfAuf6Ym48fp033KqJ7V_8CrtXIuqfBD6.Vbcrms4Zlf9GG0GHWAwvbFWOhQMJtYi7s 2f5YpLjK2fUgH8A4ujsCE7FEf_g97EB_iQuRKaxsOjbm4PNk5qyiVTRUZMduNbE2iW27M_IP7EKf cBQ2.fN9752ZK2bxF1QBQ8.mLnvfHC.VnmQ4cTNZfGrCoFZ5pNA4kHQWt_XG.NA4.wN4zVKjymBb d9IPmc8RwsoobZMBj5lrs7evkggEcLwGiqfENCAUT5G8RCfAzrU7UfNh0oc8FvgBtCiry.YQkzYI PPH.F6PL2ViUZDALjR.NxPGHwty4GjMitVaorfQ4izlqc_E3.W_jo8hJWPgepJDlPPRIoa_R1JEs TxtztGlJydR3T3GAZkFDOiSgD6uDpe37mm7MDaDelZNescCBOcn6dkTueINM27pggAL9j_PLYRZP SCfMKaA2WP7Esg2YDfjSWPLPDG0iivsaKt6glaKjDT1NLAeiX9_Hh.ibDsefMzQ8r4HSdHRhcl7t bLMScP1wCZUqdTeRvD3dfNY1azAOw1QOmsdBAXStI4Dtn9CEF9qEqcLo69_Z38_bY.HeH3HnjqoH HqYGGgQmP.lv5Hsz.U6sm3S8n7HwttpHFNsJxvT7K.rSM4XKLob6uIM6Lkg1Nk0Kz4jKGLTPEluE HgtI8TpWdSskMx.lP5.C_54idjS4hSlZAd9Uq0us9ngo3Q5_Mn6A9RxIN4RxOAumRwFWifNR4K3P NjhqxMoToF3zJ04YF9yOjSDmDbis6Nkrf1UXiAl.PtidjDtheLiSB9KkskPJ1mDkN6GlKNn5oDmO o7VwrmUsGOsKfLt7uunkuHawv7hgUMdcZPCcfiNbBUvKPh.WsGpQ4HTWMjclSU0UFpuBHHA5jaDU MryufX9ktTqEvdPIPu3LMMiaK_qbFNXCkLW3dNTmcHFkvvjIONOMCwdtLo6eu_DXfHTzwwwTIO7w HETrB47FB2NegYAMG1GyxmKDldCwFd7zEer9fwrNBnp2HSNzfRyO6QuQOs2Hfa4j2.wUbk.BMPMt _ZkPjgUu9qEjHhxTK0np3pHO3naZV0TKTpBVSj4U8agtze2tdkHB96s9cgGZx6d4JgSas4uDjENh sbE7imKpetFaWv21Mv8QZBCnlmeG111PEVMqPIqsB2pAqG38QUYzcEGSzor7yCOSjVuSmJ8y3XPR DrNPDSb7R4bGMLy.AjzB3N9O6Tzure0gC7..5BcPWptw0Qpb9TaCOVMc4_nyURYbJX1poDZlE9rF thj5R_a2BF.8Rr0vtwk2uNcBorGN9hyuOPVo38Q_zQJcEEKRFoVJ.GNp6dqhlo9e8sD1BcnXIN5M yPPyozmgah5o7XQqHxKFjH4U7C2QYDBCT5qSMxziTkwxe_mw7F78lOmLPmQvVESHW9YvJ2Qi8a1M G8dGEsWyuP9jjFOOlW3cQSPuBNHA_Tjk3LNifw1Oygz.lL6PWsmFVBMvWdf9XLBo2GUd4d0yKF.n 0 X-Sonic-MF: X-Sonic-ID: 60bb8586-1ecf-4679-b272-dbbabc06d7a7 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 Apr 2023 03:08:47 +0000 Received: by hermes--production-bf1-5f9df5c5c4-p5s6l (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 31a3fbc236dfd3434ca16e069300a270; Mon, 24 Apr 2023 03:08:45 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? Message-Id: <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> Date: Sun, 23 Apr 2023 20:08:33 -0700 To: FreeBSD Toolchain , Current FreeBSD X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> X-Spamd-Result: default: False [-2.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.84:from]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4Q4VTF5Gk1z45dv X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N I will not get into why, but I executed a git built for 1400082 in a 1400081 world context and got what was to me a surprise, given that /lib/libc.so.7 is part of 13.2-RELEASE : ld-elf.so.1: /usr/local/bin/git: Undefined symbol = "__libc_start1@FBSD_1.7" Does this mean that a /lib/libc.so.8 is pending? Or do the criteria for the likes of /lib/libc.so.7 allow for new symbols over time without a name change, even after a release contains a /lib/libc.so.7 ? Just curious about the criteria. Executing newer on older is not my normal type of activity: usually avoided. FYI: Checking 13.2-RELEASE shows it is using /lib/libc.so.7 : # uname -apKU FreeBSD generic 13.2-RELEASE FreeBSD 13.2-RELEASE = releng/13.2-n254617-525ecfdad597 GENERIC arm64 aarch64 1302001 1302001 # ldd -a `which git` /usr/local/bin/git: libpcre2-8.so.0 =3D> /usr/local/lib/libpcre2-8.so.0 = (0x6a226ba02000) libz.so.6 =3D> /lib/libz.so.6 (0x6a226c8fb000) libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x6a226cc81000) libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d429000) libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) /usr/local/lib/libpcre2-8.so.0: libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d429000) libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) /lib/libz.so.6: libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) /usr/local/lib/libintl.so.8: libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) /lib/libthr.so.3: libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 24 03:39:44 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4W9f3rwkz46vTg; Mon, 24 Apr 2023 03:40:22 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4W9f2DNVz3LPj; Mon, 24 Apr 2023 03:40:22 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33NMCo5Q021526; Sun, 23 Apr 2023 20:40:21 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=hnn/FyjUqsF+Ofk4itc2247Nqf9Y1UoE0HIkFaZ43Xo=; b=KsndWqXgEbMprmeq4L50EmVqpgrY1P/4wJdsEr0gcu39y64X9bOEudqrjqsrWZ9vTpuW a2k+aVncMj53qGJVf4oh4zppV0lUFjIaTGo+KOD5DBo416ScTnOEv2RI/CEDmodGmlOs KHkO9atxhiayfzDUcUP9JzO1kIR6/Pzstgzbjn9dDIgA4s/GWWRvUIRsHNlIJk9a3MsX 3C5pWg1naneJ3il5R6xo68YDd4wmunkjx1jtCaVz4e1Z/nP+eWJ+mZD1M9fVgfHOqM9d AMNIv0ivdJTfiCIHNatG38neiRLNNKu7gSRKDPPUKCafcfni7msAUhnPjDdxaejlPfQa Mg== Received: from cy4pr02cu008.outbound.protection.outlook.com (mail-westcentralusazlp17012028.outbound.protection.outlook.com [40.93.6.28]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3q4duaj61c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 23 Apr 2023 20:40:21 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JhHqu8FRan1CANPaFyH6nrPyNH4/2mz4bZNamNuTDfXrNs3s/ZSyVUR0w05mXfxN1kv+9hNWlxMxcRCFgSqq0KqyaV1XvBll4EjyBWzBeQV0u9Y4Tc4w05d5a16d8edYBrQR5XWmMQQECNuwttar0SpNI849OJGWwvWleEC/6OZYzXxOEyekzJ5DcqcBHI2gw8Gf+tHkxBF8ftIQIhQwHA94xr86jAWCowJymwHDTTHEi1mpJTWJ1E/p6Yx1DqmrIRsxQnnCFMkWQr3nCorytJU7Wx0ONoYuvkLMQrYBHyPreUeV2vbjxZfKksVDNy1Pz1DrqUmuRQLEFsF1xce/PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hnn/FyjUqsF+Ofk4itc2247Nqf9Y1UoE0HIkFaZ43Xo=; b=OZAyC6yaqyaA8Z2BWN1wUK+0ke+jLUAwGsdvkZ1gC8BgLJ+FG4dMdmPzDRnitgFHqRm+KIgGFTitWFk3uvMeRrljAcmGNQ5GtPpWiUucuqZtIMUfRwaAkEb6gmwFqwXYF8Jpc98JTWT0IOdIOMDeYkEoglgyjIP/tGlujRNYraNiJD10LCYu99yv/ks9tyvDyapf0v30rBXEDQNHO1iLoEJsdX7zAOuC5adIOvWhzmGQTON6RgqQR9RvioSQDr/vslzwmKxHntjVLCeHNYc2O1ICZ886VcLNS/jNl+EpwuvhP0qVeeYVThvGGiyOo0U5zksFGoP5fJxM7tR3J7akcA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hnn/FyjUqsF+Ofk4itc2247Nqf9Y1UoE0HIkFaZ43Xo=; b=JPI+p7KpOK+ldP+iznL4r8877JREVZJ8UOk/IJ761ONbNTZa4MXWnHoFuhOOTQHjjuRU+7OKYZxF7VeMRr3aRE3v78iDe+A4W/jVatZDV5XzY3rmAp8dgYNtBBESUa2pLtEkGHgEFR+A9+LE/jNtlEqwO1VjUZBqLYFhVTM9gow= Received: from BN1PR13CA0011.namprd13.prod.outlook.com (2603:10b6:408:e2::16) by BLAPR05MB7217.namprd05.prod.outlook.com (2603:10b6:208:29e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.33; Mon, 24 Apr 2023 03:40:17 +0000 Received: from BN8NAM12FT096.eop-nam12.prod.protection.outlook.com (2603:10b6:408:e2:cafe::4a) by BN1PR13CA0011.outlook.office365.com (2603:10b6:408:e2::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.19 via Frontend Transport; Mon, 24 Apr 2023 03:40:17 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by BN8NAM12FT096.mail.protection.outlook.com (10.13.182.174) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.19 via Frontend Transport; Mon, 24 Apr 2023 03:40:17 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Sun, 23 Apr 2023 22:40:16 -0500 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Sun, 23 Apr 2023 22:40:16 -0500 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7 via Frontend Transport; Sun, 23 Apr 2023 22:40:16 -0500 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 33O3eFR2023354; Sun, 23 Apr 2023 20:40:15 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id C94FD8660C; Sun, 23 Apr 2023 20:39:44 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id C81E886525; Sun, 23 Apr 2023 20:39:44 -0700 (PDT) To: Mark Millard CC: FreeBSD Toolchain , Current FreeBSD , Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? In-Reply-To: <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> Comments: In-reply-to: Mark Millard message dated "Sun, 23 Apr 2023 20:08:33 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <88091.1682307584.1@kaos.jnpr.net> Date: Sun, 23 Apr 2023 20:39:44 -0700 Message-ID: <90353.1682307584@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BN8NAM12FT096:EE_|BLAPR05MB7217:EE_ X-MS-Office365-Filtering-Correlation-Id: d3b442c4-d660-4fd2-a76b-08db44759ef2 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LSxN+1tf0DwtjQZuw7ktWQkOqAWD4CG/pMzX1oJQey5l8MA0uJuCFFx4WFmza2an6hiRv9bMUX2Wz0ICxUPazwEZKS5v6OnLPVFpp3FfVtoT8HWGtEcFUz6ijDtO/wVFu6rd3NYJ1KFaKKXU+F03zTP5StSsbJ6lTKsJwrN6OfD5VkR/Q37j+AOk8CYMRGyiTDqmKhhHwfyFYFV8k9QcNAQZi7s5x31bjXBTWqA4O3wCr+fFIE1zxOD4h9MR9QibC2fSxS4R5TqEdjDYk7l/OvJCOze2TRu83FB3MBxjU+CzNGFaeCgRBTKxjBc/oVICHtH5Tj6XLKx1dA6lKYOYBck3JsXAJh0q2gZWE43rzB4ONCdvi9t4hpIO+HipicH9O8SIjfN3Z2Xkf1KxNJXxU5pVXDAg6Xd61tZOVxuK91YRyJ7Nd6jaQjtG5NNRb3pN3LpQp0N/Yp+Yd8ozbgSSCep6UB4iS4Dq1Ldl+kf/VAL18BJkBuE8OTucrAwH9JR5OLhJnmhjPLb50Pofe6oTqfiJ8KpM0bFjOgaEwHOL0QQP7r6GWYt6nTAY4yQxMaF2ZRAB9LrTgQ+tSVOHGyAUhK8GGl1VQoEAnm8Voi0PBbcvBFPmWrV1nbIMNUX03o+G09Vq49OOTpU1c80SucP/xoPXLAT1Hpn9iqK8kf3IMgjTsnRC4UapCPcKOJ/K4T0qj+0Gnokw7Il1ejBYyZ/SlCttAJbvhZtqz9qBH5ns4aCV8o3dqs8HhAjE3x7nRDjcFQdbH/+C62ZDOEmkDkG0y5HsWr/aa5XaVsAY1U8ceRs= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(4636009)(136003)(39860400002)(396003)(346002)(376002)(451199021)(36840700001)(46966006)(40470700004)(2906002)(7696005)(107886003)(55016003)(7126003)(6266002)(9686003)(26005)(186003)(40480700001)(70586007)(70206006)(8676002)(8936002)(316002)(41300700001)(6916009)(4326008)(478600001)(5660300002)(54906003)(82740400003)(356005)(81166007)(82310400005)(86362001)(40460700003)(36860700001)(47076005)(336012)(83380400001)(66899021)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2023 03:40:17.0372 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d3b442c4-d660-4fd2-a76b-08db44759ef2 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: BN8NAM12FT096.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7217 X-Proofpoint-GUID: sENA-2bqD3bw5k3ighK2cnNZ-yrZVB-b X-Proofpoint-ORIG-GUID: sENA-2bqD3bw5k3ighK2cnNZ-yrZVB-b X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-24_01,2023-04-21_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 phishscore=0 suspectscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 spamscore=0 lowpriorityscore=0 mlxlogscore=933 adultscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304240033 X-Rspamd-Queue-Id: 4Q4W9f2DNVz3LPj X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Mark Millard wrote: > I will not get into why, but I executed a git built for 1400082 > in a 1400081 world context and got what was to me a surprise, > given that /lib/libc.so.7 is part of 13.2-RELEASE : > > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1.7" This is a symptom of trying to run a prog built for target on a host which is not the same. I hit this a lot recently while updating Makefile.depend files for userland. There are a number of makefiles (eg for sh, csh, awk) which need to run a tool on the host to generate something. When trying to build 14.0 on a 13.1 host each of those tools failed with the above issue until actually built for the host. AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tree to do the target build-tools to build these things. The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such things, ideally those tools would be built in a subdirectory of sh, csh etc, so that one can choose to build only that tool if desired - sometimes you want to build the app (eg awk) for the host as well but usually not. --sjg From nobody Mon Apr 24 03:57:06 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4WYF1V2Pz46wYM for ; Mon, 24 Apr 2023 03:57:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4WYC6nVhz3sqL for ; Mon, 24 Apr 2023 03:57:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x92c.google.com with SMTP id a1e0cc1a2514c-77259202d1dso897153241.1 for ; Sun, 23 Apr 2023 20:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682308638; x=1684900638; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OR8Ew9m+sVQZq/TB1Sll3UQ3zTbig0mDLWXr6/K7C8E=; b=Z2bjChUeJ4t0nPx1Bs0ABh++UzEF7ymXY7Nfg2MzuFh2VU+UgcSXASp/8x8br3LAhZ mHOG37S53G4NQswJsgDodWTIzY4w0J/4XWR9a2NfV+vDb0Yd8qIUYz6G6jrV7R+Dh65K jSZzTyNF8xumwjqANo0wd6LCStQXvH3hYAWhDoFwThW/EgCyxNnT/25qym31Oc0kJBKd SgigefjZ4yfab/JHDEht4SwfrZmBb//RkQVMqv0tq6Ryd4gcYSAHc2ZelaJlXCxE1+T+ gVWaSkFsKDkkriZ0JStcyq6Vyxjy9uYNFYBqCrgrRIsk1oLaUK9wregwUJ4klGt6UITp 7JsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682308639; x=1684900639; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OR8Ew9m+sVQZq/TB1Sll3UQ3zTbig0mDLWXr6/K7C8E=; b=IzDyYreFE8UiB3P1/1VF/h0sZ3jdxGk+lBbgPR8fRusDnohw3xesoA0p04mNRARyyk 4EQsj4cpa3SMBH7bkUJkHPDMBX5uLWKFTh9RUu+4yC8phfIjvL7QzzwLJXzox4Dh+/d5 9asx/jv9QBFjYo5/sdi+VpjKttP4nbpWYqoLZqvRBOpsVaH2QBmmJxnBiZ15G6ADSRNq g4MrrSDr2X48CZN98ikGgDagU3gATEe+1SUicv4RU3IRAXaqruh7yvn0Gt0Mxsp5HrZt g6dqSBgXsefB38swiaUNi/DkeIUbUxxiG1YM0e5qhdIXCW8k5eU4nPNlv8QsM1QEyNmb N8Xg== X-Gm-Message-State: AAQBX9d9t1gofkj2MBuYXK7rmQbPJiNQP/yv1T6/3IW2pnDJANSXn62u 70AYMqq0i8xcpDcXePYW9DDoPBxRtYg1hhrReEqOlw== X-Google-Smtp-Source: AKy350bUUf+y/xKomVF9YXMbBEqUWBYJUJiFbnW0Hq1y+3Cd9nW/MPXewI5RUx+VXHa8feAdpy0CHvxv0e5p4kACnUU= X-Received: by 2002:a1f:d4c2:0:b0:43f:c71d:f027 with SMTP id l185-20020a1fd4c2000000b0043fc71df027mr2888968vkg.12.1682308638669; Sun, 23 Apr 2023 20:57:18 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> <90353.1682307584@kaos.jnpr.net> In-Reply-To: <90353.1682307584@kaos.jnpr.net> From: Warner Losh Date: Sun, 23 Apr 2023 21:57:06 -0600 Message-ID: Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? To: "Simon J. Gerraty" Cc: Mark Millard , FreeBSD Toolchain , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000cf90b005fa0d0062" X-Rspamd-Queue-Id: 4Q4WYC6nVhz3sqL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000cf90b005fa0d0062 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty = wrote: > Mark Millard wrote: > > I will not get into why, but I executed a git built for 1400082 > > in a 1400081 world context and got what was to me a surprise, > > given that /lib/libc.so.7 is part of 13.2-RELEASE : > > > > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1= .7 > " > > This is a symptom of trying to run a prog built for target on a host > which is not the same. > > I hit this a lot recently while updating Makefile.depend files for > userland. > > There are a number of makefiles (eg for sh, csh, awk) which need to run > a tool on the host to generate something. > When trying to build 14.0 on a 13.1 host each of those tools failed with > the above issue until actually built for the host. > Your path is messed up then. We always run (a copy of) the host's binaries for these tools. If you were running the 14 binaries on 13 as part of the build process, the path is messed up. I'm not surprised for dirdep since it doesn't do all the staging activities that buildworld. > AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tree > to do the target build-tools to build these things. > Yes and no... We copy the host's tools when we can, and build a matched set of binary and libraries when the host one isn't good enough. I think it's a path issue you are seeing... Also, "copy" isn't a physical copy because macos hates copied binaries due to security concerns. > The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such things, > ideally those tools would be built in a subdirectory of sh, csh etc, so > that one can choose to build only that tool if desired - sometimes you > want to build the app (eg awk) for the host as well but usually not. > Yea, buildworld deals with this by creating new binaries and installing them in a special directory, which is somewhat similar (though we always build them rather than on demand like dirdep hopes to do). Warner --000000000000cf90b005fa0d0062 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 23, 2023 at 9:40=E2=80=AF= PM Simon J. Gerraty <sjg@juniper.net> wrote:
Mark Millard <marklmi@yahoo.com> wrote:
> I will not get into why, but I executed a git built for 1400082
> in a 1400081 world context and got what was to me a surprise,
> given that /lib/libc.so.7 is part of 13.2-RELEASE :
>
> ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@= FBSD_1.7"

This is a symptom of trying to run a prog built for target on a host
which is not the same.

I hit this a lot recently while updating Makefile.depend files for
userland.

There are a number of makefiles (eg for sh, csh, awk) which need to run
a tool on the host to generate something.
When trying to build 14.0 on a 13.1 host each of those tools failed with the above issue until actually built for the host.
Your path is messed up then. We always run (a copy of) the host= 's binaries
for these tools. If you were running the 14 binar= ies on 13 as part of the
build process, the path is messed up. I&= #39;m not surprised for dirdep
since it doesn't do all the st= aging activities that buildworld.
=C2=A0
AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tree
to do the target build-tools to build these things.
Yes and no... We copy the host's tools when we can, and build a= matched set of
binary and libraries when t= he host one isn't good enough. I think it's a path
issue you are seeing...
Also, "copy" isn't a physi= cal copy because macos hates copied binaries due to security concerns.
<= /div>
=C2=A0
The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such = things,
ideally those tools would be built in a subdirectory of sh, csh etc, so
that one can choose to build only that tool if desired - sometimes you
want to build the app (eg awk) for the host as well but usually not.

Yea, buildworld deals with this by creating n= ew binaries and installing them in
a special directory, which is = somewhat similar (though we always build
them rather than on dema= nd like dirdep hopes to do).=C2=A0

Warner
--000000000000cf90b005fa0d0062-- From nobody Mon Apr 24 04:02:01 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4Wft5ZK8z45xTt for ; Mon, 24 Apr 2023 04:02:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4Wft0zNgz42Pl for ; Mon, 24 Apr 2023 04:02:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-4436189d2a9so1581464e0c.1 for ; Sun, 23 Apr 2023 21:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682308933; x=1684900933; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RVpXm0/fGiXnIlhWmz7XpyuzFFAICEpNzBBis90bilw=; b=CPoKUQTF18f4qQjq+oamkzq1TMkOqzIN8aMjohwoMnREKwOQaVw+KCLDDsPmowl99q buERs4D4Zi94Oob+WXvc6NaL8d1BQCpRpxS6CJIpl+dSvBAX2adAMZjeAKl5AclhI8GE MlyqFzrrcUJWNIlau34sA4P5RS49uXbbnRRNhNeykCTldnpBBibCHkcxOep6G4fHrvNl FwkA0yPmgyJtwGEl1UdDc8GTzzVihA7Ew3Zq9dCXdcPjCQ/P+R9aMb9QkLEtt+2AiqSB V51frnTQV34ryDJPVQdvNEhoCHVNO+mSZ3M2c1arD/wq5P9/NpC4288a33fbLwJKysnW G0DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682308933; x=1684900933; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RVpXm0/fGiXnIlhWmz7XpyuzFFAICEpNzBBis90bilw=; b=Ts1cq51+Z3g5EL7Dgmr3uabXslixJV8WOk7hlBHhs+99hpooej3cbgghsolbRUr+rF LqKImMuLy2CpTkP0ReLCXH8KU5DDFqjGSJdfjPbgdnLKPZ/Yd/U+dZP/1NkUwqhd4q8b XUa0ERVa+xaWEb0Dqf4GHkX2sH/z7z6HmZlAMCLI3Okc80B4kFYfOUHGAGQQVSWveF1P P1lpXd3Fh8+8TaXpfp8B2XZnMeCbLoqfkj4k8tPF9OQOTe7JakVFUppkj3j5gP5IXE7s sNyn1wMLiEvoS0M7GakMny51sjx6KOwyDrU1IXHjr9jFJOfcuOt1627p+XROPONGUJJC LfHA== X-Gm-Message-State: AAQBX9cztKERMXknps3PFbstZGx5o26Zi6Y65Xmn+7JmR7LbC+dim1G5 qy4CLFdr6YTEGaDdG0mXOuEcZzzkLSd1pSjKVEy9Og== X-Google-Smtp-Source: AKy350be4n3AoJR7bJ2wY1Ol/PGjaApErR4gaN0CH16C6lKnBqWv3R6sEUA6PdOLLHS492UY9E6Yjtu+m87W/3JAdGA= X-Received: by 2002:a1f:4a45:0:b0:440:2c18:faf with SMTP id x66-20020a1f4a45000000b004402c180fafmr2737580vka.16.1682308933173; Sun, 23 Apr 2023 21:02:13 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> In-Reply-To: <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> From: Warner Losh Date: Sun, 23 Apr 2023 22:02:01 -0600 Message-ID: Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? To: Mark Millard Cc: FreeBSD Toolchain , Current FreeBSD Content-Type: multipart/alternative; boundary="0000000000005d57a805fa0d129d" X-Rspamd-Queue-Id: 4Q4Wft0zNgz42Pl X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000005d57a805fa0d129d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2023 at 9:09=E2=80=AFPM Mark Millard wr= ote: > I will not get into why, but I executed a git built for 1400082 > in a 1400081 world context and got what was to me a surprise, > given that /lib/libc.so.7 is part of 13.2-RELEASE : > > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1.7= " > > Does this mean that a /lib/libc.so.8 is pending? Or do the > criteria for the likes of /lib/libc.so.7 allow for new > symbols over time without a name change, even after a > release contains a /lib/libc.so.7 ? > We offer backwards compatibility in libc (so new libc will work with an old binary) but not forward compatibility (so new binary old libc may not work). This policy allows us to add symbols to libc, but never delete them. It also lets us have new versions of old symbols (like stat). > Just curious about the criteria. Executing newer on older is > not my normal type of activity: usually avoided. > Yea. New binary on old libc isn't supported. Similar rules apply to the kernel, but there's a "window" for forward compat when it impacts the upgrade path. Warner > FYI: Checking 13.2-RELEASE shows it is using /lib/libc.so.7 : > > # uname -apKU > FreeBSD generic 13.2-RELEASE FreeBSD 13.2-RELEASE > releng/13.2-n254617-525ecfdad597 GENERIC arm64 aarch64 1302001 1302001 > > # ldd -a `which git` > /usr/local/bin/git: > libpcre2-8.so.0 =3D> /usr/local/lib/libpcre2-8.so.0 (0x6a226ba020= 00) > libz.so.6 =3D> /lib/libz.so.6 (0x6a226c8fb000) > libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x6a226cc81000) > libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libpcre2-8.so.0: > libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d429000) > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /lib/libz.so.6: > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /usr/local/lib/libintl.so.8: > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > /lib/libthr.so.3: > libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa000) > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --0000000000005d57a805fa0d129d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 23, 2023 at 9:09=E2=80=AF= PM Mark Millard <marklmi@yahoo.com<= /a>> wrote:
I= will not get into why, but I executed a git built for 1400082
in a 1400081 world context and got what was to me a surprise,
given that /lib/libc.so.7 is part of 13.2-RELEASE :

ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_= 1.7"

Does this mean that a /lib/libc.so.8 is pending? Or do the
criteria for the likes of /lib/libc.so.7 allow for new
symbols over time without a name change, even after a
release contains a /lib/libc.so.7 ?


Just curious about the criteria. Executing newer on older is
not my normal type of activity: usually avoided.

<= /div>
Yea. New binary on old libc isn't supported.

Similar rules apply to the kernel, but there's a "window&= quot; for forward
compat when it impacts the upgrade path.
<= div>
Warner
=C2=A0
FYI: Checking 13.2-RELEASE shows it is using /lib/libc.so.7 :

# uname -apKU
FreeBSD generic 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ec= fdad597 GENERIC arm64 aarch64 1302001 1302001

# ldd -a `which git`
/usr/local/bin/git:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libpcre2-8.so.0 =3D> /usr/local/lib/libpcre2= -8.so.0 (0x6a226ba02000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libz.so.6 =3D> /lib/libz.so.6 (0x6a226c8fb00= 0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libintl.so.8 =3D> /usr/local/lib/libintl.so.= 8 (0x6a226cc81000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d4= 29000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/usr/local/lib/libpcre2-8.so.0:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libthr.so.3 =3D> /lib/libthr.so.3 (0x6a226d4= 29000)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/lib/libz.so.6:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/usr/local/lib/libintl.so.8:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)
/lib/libthr.so.3:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 libc.so.7 =3D> /lib/libc.so.7 (0x6a226dbfa00= 0)

=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--0000000000005d57a805fa0d129d-- From nobody Mon Apr 24 04:22:01 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4X65149lz45ygD for ; Mon, 24 Apr 2023 04:22:21 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4X642CVtz3Kl0 for ; Mon, 24 Apr 2023 04:22:20 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682310138; bh=AiKxJyjYErjXS12Yg7EBLRdOodmPyKcf+9JZ9aoHRrQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mhKgsJx49O0Dj/0K2OzfgnOBAY721OX0oIsXoliv5hXISDpEnPRqFXEdIkmBD2DtlI5aNU/lBIQ30+ENpQMmqje8eK3B4Bmk+iWVevWDph/kkrkNTY9rUlrjhe4ddcIw611viRnfMrs+Gf98U47m3vC8PRhav+s9DhrRj4WplkuVTvFlfb8ya10CZl8za89FNJTeAzEExYAPQTROOPPU+KhIiKyBcM0WGuzmo/R8wBrSf6BDzS0LftSSx3tuwyk+42QWv7l3v3p1aMnWlyjv8m/S2v7fm3Xaxgpe8JnPN3WZKez7dIO6YFTPVGsDp6jJd9zKM6yl61a88KqGo5OBjA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682310138; bh=2f1eqLNhm2IHF2DWcjYINvw14BXC1rjhMrEnak47bp6=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=B/hza3kQfANAXHogUzjMt6OIFukzdfy9xiKhCcwbXIabo4KbMf3+zZNfcdaw2SvA8ih5+JvQYpacwRpknUjwebioDvscvBGBBl6pIFRxvcp380ZvlISt578XN3DERmGozJmgTtRhuRaxh/fD5Vy/5hMXHpGRljRy41xaEyXqlyLfakpGDYzFyGZiO3oXWfKAl7XtBAykCZa8/16c+9EjNvqSwvFA8mF91yObQrBQ6SVr0luAk2SUd1G3ypiwKFXWZLSi2Ucr04acqycX7a87W2O9H4cUBj2SzsSX1jroSgFuhNvtBvNUrOscFGasxlexXQ4YYLI5JJSHyJkKebKfHg== X-YMail-OSG: o_5MK3EVM1mzlalzsSEVynevwGqm.obgXHKXHKgLugb8.VBmPhEO2JssxUt1DIB x4A2qpIOOuNeWVuIuDAYqX40G7wuAe_MWgu749nemVT4aBYncrptZ3Po7UFPDTgOdg3GDHa4Iuc0 l1W.jFlGUYb6fE__5MXqEqQqnMjDPun_.a41WzIrRUjHl.LiROt1hi8ANkcrHssjQUXPZOvtv.UW 8q.1eB75GlriHkbW3dW104IMKeRmDVTbkkgqt0e.dOaGFYYfYIk_f37YzE.Z.WItaQANXLgrQ6Dz YIj_c52LRP3ikDPcLFc06HaHW0Eq1jiZDX0JWyAcp_1EWpkhthWZc4SDKUX3rX4LPkL6ezbfRDXQ _cebZ1f0g8oy.4pCeoB.ZR6KjzfkPBWCgK2xiUw3svQ2FruKmBs539Fo643eWlaM7cjKQz.k4UMx KlPrg6FJXB3NmpWOU28.wzKgJ_p7lU4MUcTtjrjKhKX6u6Yg614OGLauKXs_o7A7sg.c7dZtI9KW PatPJXPH4LjhC92OPPUV36ohcueODL4Ps5Oc.uD2cC3lGP.nEyn8ik6pYJfMtf283YBzTA2u.tCZ OY0l7WLluyct1BwLZLEIfBOSMagcg1OLmc1aSHuj1vAVskZoYvAZc9Bm2PLoq8ZjNImti6.o.njD tkkBjC6pbKBxlMI0WLI0RMWL3FnOpmMNz1ei745ZP22LllSNBfq81pm20spR01VfB9xUiIrgxrZ. mgsthKrfac3UIWT3Iun.v4hxVxTNRJD30a_Zj5HHwmViKr0lLMat3.f5zMGQ6L58EAJ8mYJkqwHQ HUYBYlFAScNudsGQ_8RGbiNqipG9BNrrdv5Nk6RSVcjEkE8LqLzbG26oike8OVbtL3TvapEdLQ0b byGcT66c8mcBuEhHmYmv77dTvoPbEwJow_pC4ILaylcFnZIfWG1uLxcEHn3zQzE6VYABcD3GIlkp gNBGH6GUsZ5p8l1Zxtd1sRFdFhchupUpgo1PFf2KqTMmaApZVKHMtBKlEp3rWfYd.g5m5tb589AM gryEqkNTV5506.frqhigaf360rzcWyG.9tvGm6xf4TlekIrIDv41R4oZ4qzs13RVC5wdLSHINxKj kzKNU7EcXXqxzxkw4oScDw9tXvNOodWMvnkEM3SvxZQOWQJ9LmsHUxp4Yeyq3bXxBY7jwuMISG3k _aWgcPp38ldzdoP06pg8RBWURke.LuI.gMXdLjThsA1ewwWZ3P41VguvcnXmYr3qiy.4UcOiH77H T4FOyfKqxI8IAZ0LqImmIjoyBghKO_DVl0fn3E91PnOdsuKNIDKQzjCmm8.Fm.HQhiMZBvDYrISM l0v0Jlrrgtcwk7AByVhm6sFkdTHeYaHPudd5qb3WWXsTeSht9Iyd2PP8h1fNLzqmnmLWI9uY3JNu EFxsGbJH.04C16cIZMD._JSMEiHoXVWQI4uXKsTEI2kqF7ru60Bc3gUG1.Xs1Dy9wYKjc3ESy1Yc 2_83TeymOalJ1yelZ16hLzq6JqQKlJyCjK5SbE3H0lv1z3gx83KrpdAOMAHfbyaP35XrEIJNJGQs 3_eG983fcxDe0wy92udEqZVe7l2rxH_gWFVj00v212GnIwA0Lq1HIumDLmmOyOWo2SuvDDPAyECP 2ZEDt2moBzVbdSUh28sUau3j20.xZ6DQ8YsY7iNqjFaNjV38cNstZNbIKb.kgMmh48Mk858aos5P Iv9T3rmb.Y2GUxczSqDJBtan_PtWOIuSeHzKtlGyd_JTzBxDBQJNAi8sdxaQ4SZyepDX3cH5AGDH G.dE4N0O8YxuKbWuAcUfx5nSdYKvPfjXI8dvcKJtqDXmzyHYcE9IHShZi3Q._1_wiE0X0CetyBlE WE7sjwtpkrsb.a.jgi_es3Ian3kfeec5RtDvZibuc6S9pXeioWtgXp.itqs7A8Bi09FrBaLKzZAp M_ICDwVzieOnkXy7Gx.FT6cDh4S8lGn2iMx01JzkD7_kwV2PiqYYf38bSK4KFgEy2m7c0WOn.8sV pcgWIeL4EuX0c8wONKF4ROpQVnUNxYdzosRbaPZX0d9lqTviEnUjUm1FQw7Spg4WOglCnIuoKIZA nBGK6TqG9MEcwSNa3kh5MmnNC_0Z4DPNqOs6TJomsF3zm0tJKA43lKVYaROKkQBFk79Xpu8WVNbf Upz31PezUk5QqB3rjYdBjZc.0dGvQkxlgb_9LKuibZx3kkx8t2PS1xaAfI7XIyt2_BdZmFeK4cfo i4IKjEZ3CGbC0WQkg_1ONKzJeuNGbadX8GC8YR6YmnelLIZEVsFvvRyBPTtmkXZ56_bwczhRq.Gs - X-Sonic-MF: X-Sonic-ID: 16c1dba0-2e60-4b51-abb7-dc2e9fdc44d2 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Mon, 24 Apr 2023 04:22:18 +0000 Received: by hermes--production-ne1-7dbd98dd99-vd22t (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 026806350805b931e5a78eaa9ebb77a1; Mon, 24 Apr 2023 04:22:13 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? From: Mark Millard In-Reply-To: Date: Sun, 23 Apr 2023 21:22:01 -0700 Cc: "Simon J. Gerraty" , FreeBSD Toolchain , Current FreeBSD Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> <90353.1682307584@kaos.jnpr.net> To: Warner Losh X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4Q4X642CVtz3Kl0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N [Warner answered my specific question separately. This is about something else.] On Apr 23, 2023, at 20:57, Warner Losh wrote: > On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty = wrote: >> Mark Millard wrote: >> > I will not get into why, but I executed a git built for 1400082 >> > in a 1400081 world context and got what was to me a surprise, >> > given that /lib/libc.so.7 is part of 13.2-RELEASE : >> >=20 >> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol = "__libc_start1@FBSD_1.7" >>=20 >> This is a symptom of trying to run a prog built for target on a host >> which is not the same. >>=20 >> I hit this a lot recently while updating Makefile.depend files for >> userland. >>=20 >> There are a number of makefiles (eg for sh, csh, awk) which need to = run >> a tool on the host to generate something. >> When trying to build 14.0 on a 13.1 host each of those tools failed = with >> the above issue until actually built for the host. >=20 > Your path is messed up then. We always run (a copy of) the host's = binaries > for these tools. For the kernel's vers.c generation, git is used but does not get a build of its own under buildworld or buildkernel as far as I know: not a bootstrap or staged tool. > If you were running the 14 binaries on 13 as part of the > build process, the path is messed up. I'm not surprised for dirdep > since it doesn't do all the staging activities that buildworld. git use is not covered by buildworld or kernel-toolchain staging activities as far as I know. Is git the only example of such for things used by buildworld or buildkernel ? >> AFAIK the non-DIRDEPS_BUILD build does a separate pass through the = tree >> to do the target build-tools to build these things. >=20 > Yes and no... We copy the host's tools when we can, and build a = matched set of > binary and libraries when the host one isn't good enough. I think it's = a path > issue you are seeing... >=20 > Also, "copy" isn't a physical copy because macos hates copied binaries = due to security concerns. > =20 >>=20 >> The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such = things, >> ideally those tools would be built in a subdirectory of sh, csh etc, = so >> that one can choose to build only that tool if desired - sometimes = you >> want to build the app (eg awk) for the host as well but usually not. >=20 > Yea, buildworld deals with this by creating new binaries and = installing them in > a special directory, which is somewhat similar (though we always build > them rather than on demand like dirdep hopes to do).=20 =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Mon Apr 24 06:03:42 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4ZMm3MW6z465V2; Mon, 24 Apr 2023 06:04:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4ZMm1c5tz4DD1; Mon, 24 Apr 2023 06:04:20 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33O1JW15010647; Sun, 23 Apr 2023 23:04:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=dE2BOHjbkWJ6vsMAjUlETDsbDBWZqw1+Dl1/L1RW6vY=; b=tc4uZid/jNu9JkW5JLgMuxnTO7x8fJJ6VvOYPGkOVYH/0lrQladF4zsjKxnOgjtoOYOa +/UOmy0XeUX/gOEULXaqEbAOp9REikWPsqvi/iILI5Ggo6wqdVpuTSrbiFRN3Zq6y+1v 4UofmE27WaKZ12EN/RqBiko5sqcPTpMtc5G3tSlfHI2s1l1PX8m02NnzqS2lN54WArLR WXaki+dkodMPYwxCJYPvSmYMLWsjYjNI3UTvks7t/M9xtkxLXGXoZWJzWbwGubrhxFu+ 5op3rnsv4RD/OjaSIzykr5HeY89uSQzEqehadhO+gjIeaekYwDvKyxrpnTNnR1i7mRO/ 8w== Received: from dm4pr02cu001.outbound.protection.outlook.com (mail-centralusazlp17012020.outbound.protection.outlook.com [40.93.13.20]) by mx0b-00273201.pphosted.com (PPS) with ESMTPS id 3q4dgj2cke-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 23 Apr 2023 23:04:17 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZZeP8MibCm0t/udAmBvl/+UtCXykjbrO0MFt8NKLGTWHqF93DmyRh6h7p1pWNEoQssr3IMVFmLDzUlZFhREnP4F6zOi3H+lvcGOA+3DFEhzKz06Zdu2aqz6cOfmJgcOGWfjF3OrXO3Y+AudCzxnd5bBOljIa+UlZ8i3mBj3RIAEdv8suPDWiL/dprFZjBkhV/uMmKYrjxhlz4KpNBTQtt09kaq0LQH2UeObzAz1BPgbIZ+1v606SHCQfbG0aTBDzEF2wrsvqIY3wM7d2b7/EkIqx2nu+ifIECG1JE6Kd54B+i/PBU96OSFd8GfIghaNabgXYEkMNVy4HMtOt4X6YWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=dE2BOHjbkWJ6vsMAjUlETDsbDBWZqw1+Dl1/L1RW6vY=; b=c5iJf7uV9m3xGkDHt+WubncoNE/L5Y3tzj9ERwZEMT4PoaWnMWZBp+n8s7GCHlAM1bR0C+JxERzSB7d2lLIH1+aW1DwtJdlUS97ffRdKQWjJzWvYeCiwvnFb9QT3oFuQ+RdsnkP03KQcUt85Z3Yn3Aogqc4PaGhG1rsQWJiSraSxN92k09zkD1go0VEJXSUSAufPCJ/DdTnilaOYRTFTKLR8m4iE73Ny41hviLXof4xtS8PoMda9d0I5W0P2CWIuJM2LZrF+eTyAoon7Asl5DHFHAo1xMTiDmaDOowXoz7PjHoMkozPQ2A7zdfI61TDE3K/YNDFjeOXsb6dkw1PenA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=yahoo.com smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dE2BOHjbkWJ6vsMAjUlETDsbDBWZqw1+Dl1/L1RW6vY=; b=O7Kx91loZ6f/2ZFPq2kWrrgPMTZ/mX1LuCq0PtROchHPdnJPCnaVs6xBX/doZmdazCYp8Bae0yXuaSHwvKzb2ai4wa+iY76nSlizUzH6QNC3ka7rUtE3r6TEOgTpZyR7tyHv6omBfy+kxpt5KEKno7DgOPtooh0pl0GBJoIEJ0I= Received: from DM6PR02CA0156.namprd02.prod.outlook.com (2603:10b6:5:332::23) by SJ0PR05MB8151.namprd05.prod.outlook.com (2603:10b6:a03:399::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.32; Mon, 24 Apr 2023 06:04:15 +0000 Received: from DM6NAM12FT005.eop-nam12.prod.protection.outlook.com (2603:10b6:5:332:cafe::d6) by DM6PR02CA0156.outlook.office365.com (2603:10b6:5:332::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6319.33 via Frontend Transport; Mon, 24 Apr 2023 06:04:15 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by DM6NAM12FT005.mail.protection.outlook.com (10.13.178.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.19 via Frontend Transport; Mon, 24 Apr 2023 06:04:15 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Mon, 24 Apr 2023 01:04:14 -0500 Received: from p-exchbe-eqx-02.jnpr.net (10.104.9.15) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Mon, 24 Apr 2023 01:04:14 -0500 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-02.jnpr.net (10.104.9.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7 via Frontend Transport; Mon, 24 Apr 2023 01:04:14 -0500 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 33O64DYH010160; Sun, 23 Apr 2023 23:04:14 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id CCFC086613; Sun, 23 Apr 2023 23:03:42 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id C9CB78652B; Sun, 23 Apr 2023 23:03:42 -0700 (PDT) To: Warner Losh CC: Mark Millard , FreeBSD Toolchain , Current FreeBSD , Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? In-Reply-To: References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> <90353.1682307584@kaos.jnpr.net> Comments: In-reply-to: Warner Losh message dated "Sun, 23 Apr 2023 21:57:06 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.2 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <99232.1682316222.1@kaos.jnpr.net> Date: Sun, 23 Apr 2023 23:03:42 -0700 Message-ID: <27.1682316222@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT005:EE_|SJ0PR05MB8151:EE_ X-MS-Office365-Filtering-Correlation-Id: e53e20ae-e48c-4354-2131-08db4489bb9b X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HWCdMltgehTtWbWSoo5M7/SXA1stHNljKaFKLgtKKTY56zV8TC99Rdep+LtLIfA3PYb3oWcgnxZuh+VT3cDV+vytPF6eWKECa3i0YlqTfH+i/2r65reZAycKHD9neTk4xDxGX+fwFxm1PBrABDDmEMDCH943pmBHP+C5DrbrLXIqMlBlshBhcf0WHAJbQgOt8Qgkw3/yN5aIKc6gECFAbQPOdHsmeZR9AjyKXDAUUPCtugkNowfApBcqjLDPg30YF71w7CMuLNyroSdE7nbn+GTuWg9p5pL2HrrcXWdnmyg8Msk5CG+INGOE8efEYxU1Ru1urF2VMXMitzFuXS4xis35gFjl8X56joMemiW7XH7XSFLlEOWWrPewQWI1Ob6BprkFUIkBc7Ri+tUi4Zkn6g318+gkOmMgXS7Nk+w9UZoHSXP7+6lKNMF7mjRzKT4G8kSFhiL9tP93s+JqpPjRieSKnmbfY8SLycp/3tIBo6H6DwKKWFoOGslVEvTDJypsI+JOyTeyybaB2IbwarpqjsMA26ZXnhJeNJ1Y8Yk3J8EtQTrSjqvOayHXV02UnrLFJXCcgWvUPeOG25zYB8P3x09zlSPa9q/V+aVG888wKLCeaXr+g6HYqU+xGrEPLymeiKxK9+IDQvY/G3pQg2l5oNbpiAUlkheCcLshJ7Bmn4Fk33gy/MkUyvUDKBtQMvtMTCxqH8w3+KFZqnxAAJAXSSblpVceLNUmiYkLXG4U+GKQgQZng+mzHYQX/gK+5XNJSgKRwZCS6oX3fGHmlvoArUJPUNBvinnE1kztE0p3H6w= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(4636009)(136003)(396003)(39860400002)(346002)(376002)(451199021)(46966006)(40470700004)(36840700001)(107886003)(9686003)(26005)(8676002)(8936002)(4326008)(6916009)(70206006)(70586007)(54906003)(316002)(41300700001)(478600001)(40460700003)(7696005)(55016003)(5660300002)(40480700001)(36860700001)(47076005)(81166007)(356005)(82740400003)(86362001)(2906002)(4744005)(7126003)(6266002)(186003)(82310400005)(336012)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2023 06:04:15.0834 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e53e20ae-e48c-4354-2131-08db4489bb9b X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT005.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR05MB8151 X-Proofpoint-ORIG-GUID: c8oypAG8vRZASURBexfhweOiXs4Vpeqg X-Proofpoint-GUID: c8oypAG8vRZASURBexfhweOiXs4Vpeqg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-24_03,2023-04-21_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 phishscore=0 mlxlogscore=704 impostorscore=0 adultscore=0 lowpriorityscore=0 mlxscore=0 clxscore=1015 priorityscore=1501 spamscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304240057 X-Rspamd-Queue-Id: 4Q4ZMm1c5tz4DD1 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:22843, ipnet:67.231.152.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__libc_start1@FBSD_1.7" > > This is a symptom of trying to run a prog built for target on a host > which is not the same. > Your path is messed up then. We always run (a copy of) the host's binaries I wasn't using the targets you are refering to. But the point I was making was that trying to run a target binary on a host which is not the same, will result in the errror observed, and is thus a likely explaination. --sjg From nobody Mon Apr 24 07:02:04 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4bfl6Lxsz468pF for ; Mon, 24 Apr 2023 07:02:23 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4bfd6XXSz3Dg4 for ; Mon, 24 Apr 2023 07:02:17 +0000 (UTC) (envelope-from lizbethmutterhunt@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=Pq5RyzXR; spf=pass (mx1.freebsd.org: domain of lizbethmutterhunt@gmail.com designates 2a00:1450:4864:20::629 as permitted sender) smtp.mailfrom=lizbethmutterhunt@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-94ef8b88a5bso577758166b.2 for ; Mon, 24 Apr 2023 00:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682319735; x=1684911735; h=to:references:message-id:subject:date:mime-version:from :content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=XPZGz7kL5DY5PKkFDxW2ZK23O3jxFdX5tE6/Znf1b/g=; b=Pq5RyzXRF1IYQ5Dklfcju7Gw3riagLoD92oucRalLLEeKbpVmWRDnkuVNucVqNpz2s 8jdyzQxuHRAIYCsKD0HYsrVz5LwzPU0Lj3BOCwIPkHUH5bqd8Xj+nBZL1S9BGYY8IF1x fcbE/7te0nX/wECmz2Q+Izjy/YmvvtdDYbHXf+uroBnXFgP5rVHRmAuHe5VbSwhgKQE9 rwcJkC5cpMKLHLjxkZIokpJ3XJ3Uo+t5+Wlu2XRMDAL6DAu2kxG5sYd0LyTjoBNWtf/8 87egM/Y9tNR14CUBePOih8beytQXVgTpwxSMJlm//WRCaNhxuoddTs+vuup/8iwDu4/A m3Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682319735; x=1684911735; h=to:references:message-id:subject:date:mime-version:from :content-transfer-encoding:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=XPZGz7kL5DY5PKkFDxW2ZK23O3jxFdX5tE6/Znf1b/g=; b=Oi3O7Gqh2tvPSfos/T/Xkb/mpq9YIp1lwF889S4wOjbYZ8g+Gj/IXQioU1Uy2G4mrm JdIS+ObWxHhoV7pc5kqkazlXH7ZIKpeo92kXupRQM7bKMT943PQpCmjmJ/kDQQHZDS03 +bth+e9PRLjd8YCH596tM9Fb/fs5k8l0Pe5YmSrVUGg8gYb+ZQWtihoRrlc72IfFOLBn 7iuYDLy8EYvPLOj5CNjrLhl/QO7lB8opMcZmrJoQhGmDpjuN3YE9D30KzQK+cqB5p1ze 6cnRhaaRUJoY7xzEzR7LdDjkZvbv+xpvOio+E7LT/jiAbMiqLcR5v3dvqFD1m68y/0KY eZ7A== X-Gm-Message-State: AAQBX9dlEU9GNiV+0XYXj7onR2pEot5kxH1yNjOoSlnEQkrWZEe+frGp gYaN4/HoU3A8toWC3Xez3REElxb6dZGR9g== X-Google-Smtp-Source: AKy350bsWJ4h//6susqTWi4hjfc2nkfqRf0IzIvlvsyk9VdQGC5u8E/ks2GXiuU6xGwHt2jkumCWwQ== X-Received: by 2002:a17:907:8887:b0:959:a9a1:5885 with SMTP id rp7-20020a170907888700b00959a9a15885mr1187245ejc.31.1682319735450; Mon, 24 Apr 2023 00:02:15 -0700 (PDT) Received: from smtpclient.apple (2a02-8388-e106-6e00-6d39-5db7-567a-1c94.cable.dynamic.v6.surfer.at. [2a02:8388:e106:6e00:6d39:5db7:567a:1c94]) by smtp.gmail.com with ESMTPSA id n2-20020a1709065e0200b00951755d0c79sm5216257eju.104.2023.04.24.00.02.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Apr 2023 00:02:15 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-B10BA0AC-17A0-4398-9484-DDD8F8099BAB Content-Transfer-Encoding: 7bit From: "Lizbeth Mutterhunt, Ph.D" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (1.0) Date: Mon, 24 Apr 2023 09:02:04 +0200 Subject: Fwd: dbus broken? Message-Id: <6B360991-034F-4DE9-B771-27EC745D2A19@gmail.com> References: <4BE7C00E-BEBA-4653-8405-DEFA890EE103@gmail.com> To: freebsd-current@freebsd.org X-Mailer: iPhone Mail (20F5039e) X-Spamd-Result: default: False [-2.49 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2a00:1450:4864:20::629:query timed out,2a02:8388:e106:6e00:6d39:5db7:567a:1c94:query timed out]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::629:from]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4Q4bfd6XXSz3Dg4 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail-B10BA0AC-17A0-4398-9484-DDD8F8099BAB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Wenn einem gar niets meer einf=C3=A4llt, schreit man auch nix. Mijn mute re= minder! Begin doorgestuurd bericht: > Van: "Lizbeth Mutterhunt, Ph.D" > Datum: 24 april 2023 om 08:58:54 CEST > Aan: current-users@freebsd.org > Onderwerp: dbus broken? >=20 > =EF=BB=BFAs I tried the CURRENT Image from Aor., 4th, I recognised the dbu= s Package is broken, Even in Building from Ports. >=20 > The Image from 20th Apr. is ok again. Something went wrong on Apr. 4th (mi= ssing dbus config). >=20 > Just for information purpose, now everything is fine again on my Acer Vhro= mebook 314! >=20 > Thx for patience! >=20 > Liz=20 >=20 > Wenn einem gar niets meer einf=C3=A4llt, schreit man auch nix. Mijn mute r= eminder! --Apple-Mail-B10BA0AC-17A0-4398-9484-DDD8F8099BAB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Wenn einem gar nie= ts  meer einf=C3=A4llt, schreit man auch nix. Mijn mute reminder!
=

Begin doorgestuurd bericht:

Van: "Lizbeth Mutterhunt, Ph.D" <lizb= ethmutterhunt@gmail.com>
Datum: 24 april 2023 om 08:58:54 CEST<= br>Aan: current-users@freebsd.org
Onderwerp: dbus broken= ?

=EF= =BB=BFAs I tried the CURRENT Image from Aor., 4th, I recognised the db= us Package is broken, Even in Building from Ports.
The Image from 20th Apr. is ok again. Something went wrong on Apr. 4= th (missing dbus config).

Just for informat= ion purpose, now everything is fine again on my Acer Vhromebook 314!<= br>
Thx for patience!

Liz

Wenn einem gar niets  meer einf=C3= =A4llt, schreit man auch nix. Mijn mute reminder!
<= /body>= --Apple-Mail-B10BA0AC-17A0-4398-9484-DDD8F8099BAB-- From nobody Mon Apr 24 15:53:58 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4qSQ6VYyz471N5 for ; Mon, 24 Apr 2023 15:54:14 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4qSP3wLLz40fY for ; Mon, 24 Apr 2023 15:54:13 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=m84f0sZv; spf=pass (mx1.freebsd.org: domain of gkontos.mail@gmail.com designates 2a00:1450:4864:20::12d as permitted sender) smtp.mailfrom=gkontos.mail@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lf1-x12d.google.com with SMTP id 2adb3069b0e04-4edc7cc6f46so4875568e87.1 for ; Mon, 24 Apr 2023 08:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682351650; x=1684943650; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6Sg2qggQELnqRHRWx8M3580NFQflZPOlsutV9bh9siI=; b=m84f0sZv9mpRFjUJHwjwXisvS+qeLLOHaCkF/qNqg9LR7JcLcmkvHVS1XhUGL7t9W0 eUHfDUK9ry5NE3zNUwLdmxqAvrsnAlNLaH0iClsdKwZfoGf2WmRpF96Zz1Ms8j5NAjGE Lsg+5d5IKmpd6LImdHzuT8dfa3iCI1Z0HHsf4QUyM+fhQIQk/boOgTOkuVzqR8bzD6nL KlxYs0xYCiy2ekDmV7z6iTvx8ZQPIMMXXLDisqRiMZAchcjpEqFMK+YfTWf/ONawHuGi 5HqtGKoLIoOGHRftyMi//Hpt1BldYfYAmgvTs1HBdolhDzjhzOH3IfKt/30PAk1MB3Hy Tv9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682351650; x=1684943650; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6Sg2qggQELnqRHRWx8M3580NFQflZPOlsutV9bh9siI=; b=aNWROJsyPBNaGLsEKMLjKp6c+vvl7MZK2IwMtujXmMRV2zkoIh/EJ6VNZl5N2q+d2P OQl57+gwCJF+gtT2wO/NhADv4pLw8BcFfYYhmGmsgLa2GxRTeNCnfxX+S0auwkqOSKO3 vmWapZKLmKdjRBNKT1IOzfW3xOhEsV/arKOhzdypU4+ooMN1SFlPi1nrgZYhroIaQsyy e1RXayKdJddcQYoPSobYRPsubHTOZ2bsntBNjag+pHCrmtiu58+QVIqDZE9BW4DrzffV vAreUNJwzZVlD/io/8918NVQod78An8ziQCd17OmmickHVw7PEHd92T+iP9K3+GRjpy7 ESnQ== X-Gm-Message-State: AAQBX9dDF0ipKeoWwgQXxCigfUHm6s/aLLSJH6fbByKM26D5OudNLXGd uLufIuSo1QAP2BL/+cU/jsQKX9tXrpghlgkkpUFOX2sk X-Google-Smtp-Source: AKy350bANsUeEgq1DjFsG8CY5WbkWliZM+EyKKCwKZc/HJ8zHe9Vy/nCltSpBhFvABqQheejLkEg9zCw1NYzC/YhJd0= X-Received: by 2002:a05:6512:20e:b0:4de:290:1c0a with SMTP id a14-20020a056512020e00b004de02901c0amr3253738lfo.57.1682351649868; Mon, 24 Apr 2023 08:54:09 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <4BE7C00E-BEBA-4653-8405-DEFA890EE103@gmail.com> <6B360991-034F-4DE9-B771-27EC745D2A19@gmail.com> In-Reply-To: <6B360991-034F-4DE9-B771-27EC745D2A19@gmail.com> From: George Kontostanos Date: Mon, 24 Apr 2023 18:53:58 +0300 Message-ID: Subject: Re: dbus broken? To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.98 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.983]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12d:from]; FREEMAIL_FROM(0.00)[gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4Q4qSP3wLLz40fY X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N unsubscribe On Mon, Apr 24, 2023 at 10:02=E2=80=AFAM Lizbeth Mutterhunt, Ph.D wrote: > > > > Wenn einem gar niets meer einf=C3=A4llt, schreit man auch nix. Mijn mute= reminder! > > Begin doorgestuurd bericht: > > Van: "Lizbeth Mutterhunt, Ph.D" > Datum: 24 april 2023 om 08:58:54 CEST > Aan: current-users@freebsd.org > Onderwerp: dbus broken? > > =EF=BB=BFAs I tried the CURRENT Image from Aor., 4th, I recognised the db= us Package is broken, Even in Building from Ports. > > The Image from 20th Apr. is ok again. Something went wrong on Apr. 4th (m= issing dbus config). > > Just for information purpose, now everything is fine again on my Acer Vhr= omebook 314! > > Thx for patience! > > Liz > > Wenn einem gar niets meer einf=C3=A4llt, schreit man auch nix. Mijn mute= reminder! --=20 George Kontostanos --- From nobody Mon Apr 24 17:15:10 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4sFr2Qkqz476Rc for ; Mon, 24 Apr 2023 17:15:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4sFq5TcSz4J0L; Mon, 24 Apr 2023 17:15:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=M0yrtyrC; spf=pass (mx1.freebsd.org: domain of mjguzik@gmail.com designates 2607:f8b0:4864:20::c35 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-541f2112f82so1604062eaf.1; Mon, 24 Apr 2023 10:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682356511; x=1684948511; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Bh3opW7OlofBJWUpCV5f4vMCQteiXVZJutkR99B8lPQ=; b=M0yrtyrCVH2dvHcwUONIjY2aeU8+mlgXkN2PJZboz/hYgqPYsxMPCFAMeOpkCQgrwg 2O79L4tuRahXslO/CTY9Fvl6GS2SnUfyksZRnJkY6taocjFCA2QVHVEVj1tGORWOIDDp 6eH7wzyfVl5CjSL5UO6KIF1KcCMcjMve/7G2MwiqthejP95LXTY8W57AGy2zD0C1iJ9g mpoZ4V2avzf+cGUqf3ni7vRfAgKDOTDYxgroBWzp8j3nK/l5wfR48t7cLnSDnO1GUuN3 QSLQugvYtO8BQEnP9teCGCwlTiyDltIwN5u1ybcAfwIteW33UhvfwxpEZvLz2OxgAiCq M7Zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682356511; x=1684948511; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Bh3opW7OlofBJWUpCV5f4vMCQteiXVZJutkR99B8lPQ=; b=cF4ZoJGUITdYgDuYOg1Lu43mjHROS/dKm5WJ733WSLwzI1FWkXBTLGX2y9Yugxp7he tbXCydwA5ChOKBU8X6/6NXqesUv3hzUSX/20a3P0srib2/jGSwYMG7WNrFAbmJiEI2L2 pO51gS/bjxIPvU4whry0R5tagTtBlaAAwdhXGT5BFkG5IN/h9OqbESDVXe/cQ46WSyyW GUatBRF7CNcqn7xb1zPQaGqTmVX4SMLWUyNHbG5CbKG0TXkJfCf2vIvXzXIEU9hIwpTN Ua+lBk/E0Y7zUe5foSuwBO+lFFHrEw31Hp+29za3CJrDfQEpvdtKawCMOJkF6uVnhgtT CNSg== X-Gm-Message-State: AAQBX9eveJLPcV9Z9PcIAXFNNXtQQ2WMPXn8evLeBKokgtYcPUTEi7Uu wwr5W8d8UHCcx+UFo+/IOHkcSmmmMk/9dvIy0i0tIYXS X-Google-Smtp-Source: AKy350az/6wvzNJtGt7kkIYGSck/8stfAlsG4UeRZVXgP8WLznIvQyEFG8F6z2QWtZRdhEJLBaPM/T+6/l7OkTolPXQ= X-Received: by 2002:a4a:a584:0:b0:546:d2db:ff9d with SMTP id d4-20020a4aa584000000b00546d2dbff9dmr5537085oom.1.1682356510719; Mon, 24 Apr 2023 10:15:10 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:588e:0:b0:4d4:94b:7266 with HTTP; Mon, 24 Apr 2023 10:15:10 -0700 (PDT) In-Reply-To: References: <48e02888-c49f-ab2b-fc2d-ad6db6f0e10b@dawidek.net> From: Mateusz Guzik Date: Mon, 24 Apr 2023 19:15:10 +0200 Message-ID: Subject: Re: another crash and going forward with zfs To: Pawel Jakub Dawidek Cc: freebsd-current@freebsd.org, Glen Barber Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-3.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.96)[-0.960]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::c35:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-Rspamd-Queue-Id: 4Q4sFq5TcSz4J0L X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 4/18/23, Pawel Jakub Dawidek wrote: > On 4/18/23 05:14, Mateusz Guzik wrote: >> On 4/17/23, Pawel Jakub Dawidek wrote: >>> Correct me if I'm wrong, but from my understanding there were zero >>> problems with block cloning when it wasn't in use or now disabled. >>> >>> The reason I've introduced vfs.zfs.bclone_enabled sysctl, was to exactly >>> avoid mess like this and give us more time to sort all the problems out >>> while making it easy for people to try it. >>> >>> If there is no plan to revert the whole import, I don't see what value >>> removing just block cloning will bring if it is now disabled by default >>> and didn't cause any problems when disabled. >>> >> >> The feature definitely was not properly stress tested and what not and >> trying to do it keeps running into panics. Given the complexity of the >> feature I would expect there are many bug lurking, some of which >> possibly related to the on disk format. Not having to deal with any of >> this is can be arranged as described above and is imo the most >> sensible route given the timeline for 14.0 > > Block cloning doesn't create, remove or modify any on-disk data until it > is in use. > > Again, if we are not going to revert the whole merge, I see no point in > reverting block cloning as until it is enabled, its code is not > executed. This allow people who upgraded the pools to do nothing special > and it will allow people to test it easily. > Some people will zpool upgrade out of habit or whatever after moving to 14.0, which will then make them unable to go back to 13.x if woes show up. Woes don't even have to be zfs-related. This is a major release, one has to suspect there will be some breakage and it maybe the best way forward for some of the users will be to downgrade (e.g., with boot envinronments). As is they wont be able to do it if they zpool upgrade. If someone *does* zpool upgrade and there is further data corruption due to block cloning (which you really can't rule out given that the feature so far did not survive under load), telephone game is going to turn this into "14.0 corrupts data" and no amount of clarifying about an optional feature is going to help the press. If anything the real question is how come the feature got merged upstream, when: 1. FreeBSD CI for the project is offline 2. There is no Linux support 3. ... basic usage showed numerous bugs Should the feature get whipped into shape, it can be a 14.1 candidate. -- Mateusz Guzik From nobody Mon Apr 24 21:05:16 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q4yMc5NzDz47M8B for ; Mon, 24 Apr 2023 21:05:32 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q4yMb165wz3nFy for ; Mon, 24 Apr 2023 21:05:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x930.google.com with SMTP id a1e0cc1a2514c-77858d8dcb5so21097003241.1 for ; Mon, 24 Apr 2023 14:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682370330; x=1684962330; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+UGUkCPx6ChSPrMaNyHtE2UNs6d3QPbE7SaWjF02JAg=; b=yY4TxTI4EHWotsQbz9zRsxAoJR21r06bML4Xt+N057PlvegPLze7raG9JTQSwpzOI4 ITtZcpdXKslt612MlgZnH1pcdoul12GAYwcerYGcyZR+iBcfcJ5fvzXef2nyOgeLVy4u Xabf98RmD2/jNIMYzPq6rVUSRaxAMl5PBMarnQzOiLAZzsza6+y4OVMaG89VUqZQ32b7 lIbTqs6ZlFjeuJEsy9STymZOT8ZDA6mIQDV9ti8nq/M7kvD1BFRqB5y+Evf3N3QsDIPI BXDOh0OGKny068J6YOgbtPkViyP775IY+j2x96oW5gCV9owidHp4d/2tMQV0G2dNZml4 24iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682370330; x=1684962330; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+UGUkCPx6ChSPrMaNyHtE2UNs6d3QPbE7SaWjF02JAg=; b=Qc2FNzqk08euYEXvVda+H7qUG7Fu2zK+D+12Utb+Umz68qJUq8+3egdCG0HwK9jvk9 CgbnWxk0MSrON2Ep4GyndP9mRWSGRS4z4bOIl+olcz7QwsSgBOQS0w2B2dIFdpTFzsah V2tDtXbK68CYpvApHajdzVMx6mn7VNyHMPkIE1VfPdWiT9a81+gnu3wd/688pmmzuODw 5upQrPh++Z2Zs5Tgz1GpQ1R5Jbg+vvYNWl03KpE7/P1e3oMFyMJRDP40hNHZuU8+OLuu h4E0un8MmKmRa6D/jsIYjZtD/bPGUkIiH5J/BjPCjQNzn5MK2q6/BIu5rGYqeaVFxQBx se7w== X-Gm-Message-State: AAQBX9eyoYMxwR8J9HccxuGHuQSp734L077ZVxatz17tPnMRE0pTSOdr 8gJHlvJUxbH+6vXNhHY3rfo707ZjhkFUq8zGczcKaA== X-Google-Smtp-Source: AKy350ZVDooxuJ0YtFMQ+uxgIvT4g6hYgOpSJADc3PD7vsMUAC9Qzuz9zsuOjzyEGMngkLkDi6vvFwq1xAM8kUuaIn0= X-Received: by 2002:a05:6122:179a:b0:443:7204:786e with SMTP id o26-20020a056122179a00b004437204786emr5827198vkf.0.1682370329757; Mon, 24 Apr 2023 14:05:29 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <5B26AB25-075F-4630-86C1-886E6082CDCF.ref@yahoo.com> <5B26AB25-075F-4630-86C1-886E6082CDCF@yahoo.com> <90353.1682307584@kaos.jnpr.net> In-Reply-To: From: Warner Losh Date: Mon, 24 Apr 2023 15:05:16 -0600 Message-ID: Subject: Re: /lib/libc.so.7 vs. __libc_start1@FBSD_1.7 in main [so: 14] recently ? To: Mark Millard Cc: "Simon J. Gerraty" , FreeBSD Toolchain , Current FreeBSD Content-Type: multipart/alternative; boundary="000000000000e2e31b05fa1b5d05" X-Rspamd-Queue-Id: 4Q4yMb165wz3nFy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000e2e31b05fa1b5d05 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 23, 2023 at 10:22=E2=80=AFPM Mark Millard w= rote: > [Warner answered my specific question separately. This is about > something else.] > > On Apr 23, 2023, at 20:57, Warner Losh wrote: > > > On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty > wrote: > >> Mark Millard wrote: > >> > I will not get into why, but I executed a git built for 1400082 > >> > in a 1400081 world context and got what was to me a surprise, > >> > given that /lib/libc.so.7 is part of 13.2-RELEASE : > >> > > >> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol > "__libc_start1@FBSD_1.7" > >> > >> This is a symptom of trying to run a prog built for target on a host > >> which is not the same. > >> > >> I hit this a lot recently while updating Makefile.depend files for > >> userland. > >> > >> There are a number of makefiles (eg for sh, csh, awk) which need to ru= n > >> a tool on the host to generate something. > >> When trying to build 14.0 on a 13.1 host each of those tools failed wi= th > >> the above issue until actually built for the host. > > > > Your path is messed up then. We always run (a copy of) the host's > binaries > > for these tools. > > For the kernel's vers.c generation, git is used but > does not get a build of its own under buildworld or > buildkernel as far as I know: not a bootstrap or > staged tool. > Correct. The host's git is assumed to always be good and always executing in a sane env. And you can just remove / take git out of the path if you hit problems here= . > > If you were running the 14 binaries on 13 as part of the > > build process, the path is messed up. I'm not surprised for dirdep > > since it doesn't do all the staging activities that buildworld. > > git use is not covered by buildworld or kernel-toolchain > staging activities as far as I know. > > Is git the only example of such for things used by buildworld > or buildkernel ? > buildkernel is the only place I know that git is used to get the tip of git branch for messages. I think that reproducible builds omit this. Warner > >> AFAIK the non-DIRDEPS_BUILD build does a separate pass through the tre= e > >> to do the target build-tools to build these things. > > > > Yes and no... We copy the host's tools when we can, and build a matched > set of > > binary and libraries when the host one isn't good enough. I think it's = a > path > > issue you are seeing... > > > > Also, "copy" isn't a physical copy because macos hates copied binaries > due to security concerns. > > > >> > >> The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal with such thing= s, > >> ideally those tools would be built in a subdirectory of sh, csh etc, s= o > >> that one can choose to build only that tool if desired - sometimes you > >> want to build the app (eg awk) for the host as well but usually not. > > > > Yea, buildworld deals with this by creating new binaries and installing > them in > > a special directory, which is somewhat similar (though we always build > > them rather than on demand like dirdep hopes to do). > > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > > > --000000000000e2e31b05fa1b5d05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 23, 2023 at 10:22=E2=80= =AFPM Mark Millard <marklmi@yahoo.c= om> wrote:
imp@bsdimp.com> wrote:

> On Sun, Apr 23, 2023 at 9:40=E2=80=AFPM Simon J. Gerraty <sjg@juniper.net> wrote= :
>> Mark Millard <marklmi@yahoo.com> wrote:
>> > I will not get into why, but I executed a git built for 14000= 82
>> > in a 1400081 world context and got what was to me a surprise,=
>> > given that /lib/libc.so.7 is part of 13.2-RELEASE :
>> >
>> > ld-elf.so.1: /usr/local/bin/git: Undefined symbol "__lib= c_start1@FBSD_1.7"
>>
>> This is a symptom of trying to run a prog built for target on a ho= st
>> which is not the same.
>>
>> I hit this a lot recently while updating Makefile.depend files for=
>> userland.
>>
>> There are a number of makefiles (eg for sh, csh, awk) which need t= o run
>> a tool on the host to generate something.
>> When trying to build 14.0 on a 13.1 host each of those tools faile= d with
>> the above issue until actually built for the host.
>
> Your path is messed up then. We always run (a copy of) the host's = binaries
> for these tools.

For the kernel's vers.c generation, git is used but
does not get a build of its own under buildworld or
buildkernel as far as I know: not a bootstrap or
staged tool.

Correct. The host's gi= t is assumed to always be good and always executing in a sane env.
And you can just remove / take git out of the path if you hit problems he= re.
=C2=A0
> If you were running the 14 binaries on 13 as part of the
> build process, the path is messed up. I'm not surprised for dirdep=
> since it doesn't do all the staging activities that buildworld.
git use is not covered by buildworld or kernel-toolchain
staging activities as far as I know.

Is git the only example of such for things used by buildworld
or buildkernel ?

buildkernel is the onl= y place I know that git is used to get the tip of git branch for messages. = I think that reproducible builds omit this.

Warner=
=C2=A0
>> AFAIK the non-DIRDEPS_BUILD build does a separate pass through the= tree
>> to do the target build-tools to build these things.
>
> Yes and no... We copy the host's tools when we can, and build a ma= tched set of
> binary and libraries when the host one isn't good enough. I think = it's a path
> issue you are seeing...
>
> Also, "copy" isn't a physical copy because macos hates c= opied binaries due to security concerns.
>=C2=A0
>>
>> The DIRDEPS_BUILD uses a pseudo MACHINE "host" to deal w= ith such things,
>> ideally those tools would be built in a subdirectory of sh, csh et= c, so
>> that one can choose to build only that tool if desired - sometimes= you
>> want to build the app (eg awk) for the host as well but usually no= t.
>
> Yea, buildworld deals with this by creating new binaries and installin= g them in
> a special directory, which is somewhat similar (though we always build=
> them rather than on demand like dirdep hopes to do).


=3D=3D=3D
Mark Millard
marklmi at yahoo.com


--000000000000e2e31b05fa1b5d05-- From nobody Mon Apr 24 22:46:24 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q50c81SL4z45ym8 for ; Mon, 24 Apr 2023 22:46:32 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q50c616Wsz4155 for ; Mon, 24 Apr 2023 22:46:29 +0000 (UTC) (envelope-from pete@nomadlogic.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=brvf8ibB; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org; dmarc=pass (policy=quarantine) header.from=nomadlogic.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1682376385; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=B7M9O9i7+ruSBGZDRGI7oFwuTpLjs2dkZhEszxxaC2Y=; b=brvf8ibBoacyL7IfCOqdCIYv70FMbIy18/XgKM9C65ipzdxja+2vC+y/xlFXVVmkyb2k/y XBQJ4JIXOEg0i0R4DtDLvlgHf8fOatH0OG8O++6NTnDxxvWIWivM4mSGBKu7zqbG09HtKy cHYHGEZ1hqhxSdfzxZJUF7kJws8GiZY= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 3a68de43 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Mon, 24 Apr 2023 22:46:25 +0000 (UTC) Message-ID: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> Date: Mon, 24 Apr 2023 15:46:24 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: FreeBSD Current From: Pete Wright Subject: current status of zfs block_cloning on CURRENT? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; DKIM_TRACE(0.00)[nomadlogic.org:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Q50c616Wsz4155 X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N hi everyone, i've seen a few threads about the block_cloning feature causing data corruption issues on CURRENT and have been keen to avoid enabling it until the dust settles.  i was under the impression that we either reverted or disabled block_cloning on CURRENT, but when i ran "zpool upgrade" on a pool today it reported block_cloning was enabled.  this is on a system i rebuilt yesterday. i was hoping to get some clarity on the effect of having this feature enabled, is this enough to trigger the data corruption bug or does something on the zfs filesystem itself have to be enabled to trigger this? i also noticed there is no entry for this feature in zpool-features(7), hence i thought i was safe to upgrade my pool. thanks in advance, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From nobody Tue Apr 25 03:41:02 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q57821nb4z46YkR for ; Tue, 25 Apr 2023 03:41:06 +0000 (UTC) (envelope-from vishwin@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q57821Lxcz4TrR; Tue, 25 Apr 2023 03:41:06 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682394066; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lcPy/0aIk3S3DDQadjI+3n/v+M7gyZTjvIYKu3/eKSk=; b=YJJpIz6F+/KlHyI31At10N5dGEA4F+xWYfg6tGI2zSWoQIfjNWMaQUOdMScMtNtfNs0bvf Vfq0sPNvLJlxxGrfoSrepwXC+ggzxv2AdDrdqgw3skMlQDhQENUF7lZB/eHOYijiMuhvI8 bpP2cJYd0Y37Y1O9IqUrHzExM4zPBYGBUjxhHW6Z9erV5IY7W+nWUwrcOSE3uxG31pJgFn jqGaS0mTMUrDm2MmdRpdvMPpQIdTJbPN5yd+2JX//EvpRDwLMldS6xiMm5d4WwKxbQdouZ J5h2bce5WZooPB6sqgyIyDWG7XslKp5uOXN5C9XjF+Qqy1s43xCL+oVosmgPMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682394066; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lcPy/0aIk3S3DDQadjI+3n/v+M7gyZTjvIYKu3/eKSk=; b=D47kId/MbC7swYjU8kNjOAKLj0dJBaU30JJ0Xsmj2RpbEjXWiSv5wdRCW138lI8zgkSPyf aCvwFB5eYyPEk16luzq0AiKjVI+juq5q8FwfVOfi1WYVQgtt2UuKrqz21VdlOHkBnWQyI4 gjC0NG5mDA0i0ZI2q6+zfJb4Oye5VCdcX4FZsz5u+RLmeLeUsNyivFEV0J6cS2JXozI+XW FXvLWyXcpjiCvj6wAaLV4ZDc96zfIbhEaCnUWzaWmAz6HytFnCyKh4o2/3C6dEvNAvlmE6 Ga3FdAT+r59Zw2vHqOikW0J0hMNb1ZgmeThzN0XirUy0yIiUZs7UsvZp+SVerw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682394066; a=rsa-sha256; cv=none; b=DP8yDlsTh9FQik1tQYf0n1uFcF4wcZ6YMUr2Kaeb0OEnl9qbOr+P6qOFbzFWKySjqIgrlk V4Fw3oibX6HHK41XI6KM90e8AZq57uXKw0P+IQp2RyNawJ2gkvfOUeeiCNJS84VIls2aTd dclwC7XoX30JQKW0IXKxOhTT8d8dqFVMP3/MBWn6xgKKLRbzOR8Ssmm0LUfGXtlc1usm9r R8PSC8KKcWu8may5xMwgTj6cJdqdVB6LMFWBo2HW6FwnJThWvTZfxdABxqtt/robGyqphP J7Qpd16CjOBn2WnMbY/dtb5VPRp2x8a2xSMyzwxHZ0Ix+UI9gG1fBqeqMLE4Bw== Received: from [IPV6:2601:98a:602:da0:56ee:75ff:fe50:69b5] (unknown [IPv6:2601:98a:602:da0:56ee:75ff:fe50:69b5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q57816XdfzxPM; Tue, 25 Apr 2023 03:41:05 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> Date: Mon, 24 Apr 2023 23:41:02 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Content-Language: en-GB To: Pete Wright , FreeBSD Current References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> From: Charlie Li Organization: FreeBSD Project Subject: Re: current status of zfs block_cloning on CURRENT? In-Reply-To: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------RAWnS9qRy91Daxj0QRcH1sLN" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------RAWnS9qRy91Daxj0QRcH1sLN Content-Type: multipart/mixed; boundary="------------vseNvC6SsUxgHQqumvKtxR0G"; protected-headers="v1" From: Charlie Li To: Pete Wright , FreeBSD Current Message-ID: <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> Subject: Re: current status of zfs block_cloning on CURRENT? References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> In-Reply-To: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> --------------vseNvC6SsUxgHQqumvKtxR0G Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UGV0ZSBXcmlnaHQgd3JvdGU6DQo+IGkndmUgc2VlbiBhIGZldyB0aHJlYWRzIGFib3V0IHRo ZSBibG9ja19jbG9uaW5nIGZlYXR1cmUgY2F1c2luZyBkYXRhIA0KPiBjb3JydXB0aW9uIGlz c3VlcyBvbiBDVVJSRU5UIGFuZCBoYXZlIGJlZW4ga2VlbiB0byBhdm9pZCBlbmFibGluZyBp dCANCj4gdW50aWwgdGhlIGR1c3Qgc2V0dGxlcy7CoCBpIHdhcyB1bmRlciB0aGUgaW1wcmVz c2lvbiB0aGF0IHdlIGVpdGhlciANCj4gcmV2ZXJ0ZWQgb3IgZGlzYWJsZWQgYmxvY2tfY2xv bmluZyBvbiBDVVJSRU5ULCBidXQgd2hlbiBpIHJhbiAienBvb2wgDQo+IHVwZ3JhZGUiIG9u IGEgcG9vbCB0b2RheSBpdCByZXBvcnRlZCBibG9ja19jbG9uaW5nIHdhcyBlbmFibGVkLsKg IHRoaXMgaXMgDQo+IG9uIGEgc3lzdGVtIGkgcmVidWlsdCB5ZXN0ZXJkYXkuDQo+IA0KVGhl IGR1c3QgaGFzIHNldHRsZWQuDQo+IGkgd2FzIGhvcGluZyB0byBnZXQgc29tZSBjbGFyaXR5 IG9uIHRoZSBlZmZlY3Qgb2YgaGF2aW5nIHRoaXMgZmVhdHVyZSANCj4gZW5hYmxlZCwgaXMg dGhpcyBlbm91Z2ggdG8gdHJpZ2dlciB0aGUgZGF0YSBjb3JydXB0aW9uIGJ1ZyBvciBkb2Vz IA0KPiBzb21ldGhpbmcgb24gdGhlIHpmcyBmaWxlc3lzdGVtIGl0c2VsZiBoYXZlIHRvIGJl IGVuYWJsZWQgdG8gdHJpZ2dlciB0aGlzPw0KPiANClRoZSBpbml0aWFsIHByb2JsZW0gd2l0 aCBibG9ja19jbG9uaW5nIFswXVsxXSB3YXMgZml4ZWQgaW4gY29tbWl0cyANCmUwYmIxOTk5 MjU1NjVhMzc3MDczM2FmZDFhNGQ4YmIyZDRkMGNlMzEgYW5kIA0KMTk1OWUxMjJkOTMyOGIz MWE2MmZmNzUwOGUxNzQ2ZGYyODU3YjU5Miwgd2l0aCBhIHN5c2N0bCBhZGRlZCBpbiBjb21t aXQgDQowNjg5MTNlNGJhM2RkOWIzMDY3MDU2ZTgzMmNlZmM1ZWQyNjRiNWNjLiBBIGRpZmZl cmVudCBkYXRhIGNvcnJ1cHRpb24gDQpwcm9ibGVtIFsyXVszXSB3YXMgZml4ZWQgaW4gY29t bWl0IA0KNjNlZTc0N2ZlYmJmMDI0YmUwYWFjZTYxMTYxMjQxYjUzMjQ1NDQ5ZS4gQWxsIHdl cmUgY29tbWl0dGVkIGJldHdlZW4gDQoxNS0xNyBBcHJpbC4NCg0KWzBdIGh0dHBzOi8vZ2l0 aHViLmNvbS9vcGVuemZzL3pmcy9wdWxsLzEzMzkyI2lzc3VlY29tbWVudC0xNTA0MjM5MTAz DQpbMV0gaHR0cHM6Ly9naXRodWIuY29tL29wZW56ZnMvemZzL3B1bGwvMTQ3MzkNClsyXSBo dHRwczovL2dpdGh1Yi5jb20vb3Blbnpmcy96ZnMvaXNzdWVzLzE0NzUzDQpbM10gaHR0cHM6 Ly9naXRodWIuY29tL29wZW56ZnMvemZzL3B1bGwvMTQ3NjENCg0KLS0gDQpDaGFybGllIExp DQrigKZub3BlLCBzdGlsbCBkb24ndCBoYXZlIGFuIGV4aXQgbGluZS4NCg0K --------------vseNvC6SsUxgHQqumvKtxR0G-- --------------RAWnS9qRy91Daxj0QRcH1sLN Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmRHS84FAwAAAAAACgkQ/reFK+KbPoeT ExAAltIo2AR0XKsF/rcLsdppCvvmtmQwNN2tSwiClMf1K3aWlwBArgWm4gDmaU8aHxR31sYVAx0F TxQPSZ6xGOpwWxihW5LHBul8j7dnGkmPasFt7d4MjhV3vAfaVwE5VfT9J5oDjL2hf5SOAhJRMttr MXOXIoiE/abDcqghKCMR2F4NBgsFgSRfBl2VADJfRGTRLtjhs5/eElh0JO31SZhq0G2op8lYyenr NzucPoFxuQM17MqQMZeOufXaSx6kcRQ5utpqwObhtLcUtXLdn+eG+jkrmLZG5RTIv2TbzgIhIB58 lCuaZ3AX2OkZtGDNJrJTtLtnKHulGpzEM9UE162RuuRSPxx2LZ8b808o8VLeGRaUU1+1mld425m2 8g0lWFZ1V5ll0KaGdV80HZ1Sw6nSsl7Ak5pmnSrAI/55ifIPIfemyyiTrD1twN0Q0/NvKDvt1i9R S5WfKMod/1CeMo4b/kQ4MTE2ehh64QeWEfl4EhwhiFu0RFlNrJpfOEaWDEpcmQFM6oThDv+dVbKa Dj4jUgDXcdK4INOF1Z1NFb5+R69O6M2Sjgru7z1mvCjEuk0+JGcAmfBNqLU1bPagG+xUG0hYtWa3 X8OYjOez/xjyJJOTYAZp4rRJ/8Hdv1jdQWwYjHZGHwIC5NrFKWg3t3EI9BvQVbA0EYZO+JjvB4NC PYA= =Tz4C -----END PGP SIGNATURE----- --------------RAWnS9qRy91Daxj0QRcH1sLN-- From nobody Tue Apr 25 03:48:57 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q57K80cQMz46YwR for ; Tue, 25 Apr 2023 03:49:00 +0000 (UTC) (envelope-from vishwin@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q57K770Yrz4WWf; Tue, 25 Apr 2023 03:48:59 +0000 (UTC) (envelope-from vishwin@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682394540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7HmpS+ukJQ9iOH923XIfMvocBK6xUBL4iMkmHmooZeg=; b=UQmhLjo5hAtvYFNFpzW7Pj7ZN7OODOIGKfFblsDsXwOuNNAZPdgz3oGT8a/YqLQHTWrIMo 0bmBDTo/qZDYEuOOTvWBozox4YLkV24D8zsJiuVpQaON2zzLv5xHMSOhuPetxLT0bWj0VT f6TJLKhl21nwq3iy7+uA/IUDK5G4a1lh7HmBOHbd8h42/kozsxB2Ld9CjDFX2qDWNJtoee SIEVYr4y5KkDZMGm1NbrwxjrcDnlYrJ9DIP0GnZdmJepjQCLLn8JT3+vczx+nhTb+pxRRh lMGXKemov7miqO7JhRo8gPeUxbK3XfO2IKiAhtvLtwEad/A//ArYV53jEL9Xig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682394540; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7HmpS+ukJQ9iOH923XIfMvocBK6xUBL4iMkmHmooZeg=; b=IvSmQXb0myal7bR5UUQvATDJVuajQLywHd5u11t9ajXDNAjZHIU2Yk9+pTlC8WFszmHdSE xezr2d153eHQHf7ZOv/ALfmAB8H4b+sVNhgsJBhOfapKGeejUq+Dn1F2HrV0bWExc9zb8l 4yoVBdJJXSuHuXFkTwZFUsDKh4FDT6BG1cdyrFzln85aggvuH+xdWpRcW9LsAFve0iwQCL 3MjELMNCN7gya0CdAFRsAaxbCGRBO0Iqk+LjVBUcVcgu5z2xO+ncSjwKxLYRa2GQBp1do3 3+WVEvvJrh+u4QvvAZKAwLw3reYPZ9GbhUrRIUxqQv/NfJjJXt+paPfRfwCqDA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682394540; a=rsa-sha256; cv=none; b=kT5vVXlfAXDaUPpxajGvvvyarPqpoQZe7rmYDQFKHthoJ5NKlRPPYylJHc/q6WLWsIGvv/ dGSvGtPpyaytquAqYRsv6sT+JWEVDzHkn9zyoQT+7dysTMfNWTIUQCgYWFqHw0H/YGJTOc 4Vy+ukJ4qoO1MdZxzgEY/P7WuSuNo9mdzm6yCZlYtVi1v1ChPi2FhgbLF52slUdrHG0nN3 hnHdwbmLYQ+0Zoroc8lXH5yAU0f8gQ1DTzB7bwDnw0sDNFJ06aI3e8XxIKbwOycVy2/zog QlDaYbawlOKfXeN2FncmPEtP9P97lTd69arsqXcQkqAfKL0tEqH3rwpw/d65qQ== Received: from [IPV6:2601:98a:602:da0:56ee:75ff:fe50:69b5] (unknown [IPv6:2601:98a:602:da0:56ee:75ff:fe50:69b5]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: vishwin/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q57K74yq9zwyK; Tue, 25 Apr 2023 03:48:59 +0000 (UTC) (envelope-from vishwin@freebsd.org) Message-ID: <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org> Date: Mon, 24 Apr 2023 23:48:57 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: current status of zfs block_cloning on CURRENT? Content-Language: en-GB From: Charlie Li To: Pete Wright , FreeBSD Current References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> Organization: FreeBSD Project In-Reply-To: <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FtciCWZGKsn2ou2FuuZH0NcR" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FtciCWZGKsn2ou2FuuZH0NcR Content-Type: multipart/mixed; boundary="------------3bMYiU9p0eCrK0U6DkWtQWkl"; protected-headers="v1" From: Charlie Li To: Pete Wright , FreeBSD Current Message-ID: <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org> Subject: Re: current status of zfs block_cloning on CURRENT? References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> In-Reply-To: <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> --------------3bMYiU9p0eCrK0U6DkWtQWkl Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Q2hhcmxpZSBMaSB3cm90ZToNCj4gUGV0ZSBXcmlnaHQgd3JvdGU6DQo+PiBpJ3ZlIHNlZW4g YSBmZXcgdGhyZWFkcyBhYm91dCB0aGUgYmxvY2tfY2xvbmluZyBmZWF0dXJlIGNhdXNpbmcg ZGF0YSANCj4+IGNvcnJ1cHRpb24gaXNzdWVzIG9uIENVUlJFTlQgYW5kIGhhdmUgYmVlbiBr ZWVuIHRvIGF2b2lkIGVuYWJsaW5nIGl0IA0KPj4gdW50aWwgdGhlIGR1c3Qgc2V0dGxlcy7C oCBpIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB0aGF0IHdlIGVpdGhlciANCj4+IHJldmVy dGVkIG9yIGRpc2FibGVkIGJsb2NrX2Nsb25pbmcgb24gQ1VSUkVOVCwgYnV0IHdoZW4gaSBy YW4gInpwb29sIA0KPj4gdXBncmFkZSIgb24gYSBwb29sIHRvZGF5IGl0IHJlcG9ydGVkIGJs b2NrX2Nsb25pbmcgd2FzIGVuYWJsZWQuwqAgdGhpcyANCj4+IGlzIG9uIGEgc3lzdGVtIGkg cmVidWlsdCB5ZXN0ZXJkYXkuDQo+Pg0KPiBUaGUgZHVzdCBoYXMgc2V0dGxlZC4NCkJhcmVs eS4uLg0KPj4gaSB3YXMgaG9waW5nIHRvIGdldCBzb21lIGNsYXJpdHkgb24gdGhlIGVmZmVj dCBvZiBoYXZpbmcgdGhpcyBmZWF0dXJlIA0KPj4gZW5hYmxlZCwgaXMgdGhpcyBlbm91Z2gg dG8gdHJpZ2dlciB0aGUgZGF0YSBjb3JydXB0aW9uIGJ1ZyBvciBkb2VzIA0KPj4gc29tZXRo aW5nIG9uIHRoZSB6ZnMgZmlsZXN5c3RlbSBpdHNlbGYgaGF2ZSB0byBiZSBlbmFibGVkIHRv IHRyaWdnZXIgDQo+PiB0aGlzPw0KPj4NCj4gVGhlIGluaXRpYWwgcHJvYmxlbSB3aXRoIGJs b2NrX2Nsb25pbmcgWzBdWzFdIHdhcyBmaXhlZCBpbiBjb21taXRzIA0KPiBlMGJiMTk5OTI1 NTY1YTM3NzA3MzNhZmQxYTRkOGJiMmQ0ZDBjZTMxIGFuZCANCj4gMTk1OWUxMjJkOTMyOGIz MWE2MmZmNzUwOGUxNzQ2ZGYyODU3YjU5Miwgd2l0aCBhIHN5c2N0bCBhZGRlZCBpbiBjb21t aXQgDQo+IDA2ODkxM2U0YmEzZGQ5YjMwNjcwNTZlODMyY2VmYzVlZDI2NGI1Y2MuIEEgZGlm ZmVyZW50IGRhdGEgY29ycnVwdGlvbiANCj4gcHJvYmxlbSBbMl1bM10gd2FzIGZpeGVkIGlu IGNvbW1pdCANCj4gNjNlZTc0N2ZlYmJmMDI0YmUwYWFjZTYxMTYxMjQxYjUzMjQ1NDQ5ZS4g QWxsIHdlcmUgY29tbWl0dGVkIGJldHdlZW4gDQo+IDE1LTE3IEFwcmlsLg0KPiANCj4gWzBd IGh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuemZzL3pmcy9wdWxsLzEzMzkyI2lzc3VlY29tbWVu dC0xNTA0MjM5MTAzDQo+IFsxXSBodHRwczovL2dpdGh1Yi5jb20vb3Blbnpmcy96ZnMvcHVs bC8xNDczOQ0KPiBbMl0gaHR0cHM6Ly9naXRodWIuY29tL29wZW56ZnMvemZzL2lzc3Vlcy8x NDc1Mw0KPiBbM10gaHR0cHM6Ly9naXRodWIuY29tL29wZW56ZnMvemZzL3B1bGwvMTQ3NjEN Cj4gDQpHaXZlbiBtamdAJ3MgdGhyZWFkIHJlcG9ydGluZyBmdXJ0aGVyIGNyYXNoZXMvcGFu aWNzLCB5b3UgbWF5IHdhbnQgdG8gDQprZWVwIHRoZSBzeXNjdGwgZGlzYWJsZWQgaWYgeW91 IHVwZ3JhZGVkIHRoZSBwb29sIGFscmVhZHkuDQoNCi0tIA0KQ2hhcmxpZSBMaQ0K4oCmbm9w ZSwgc3RpbGwgZG9uJ3QgaGF2ZSBhbiBleGl0IGxpbmUuDQoNCg== --------------3bMYiU9p0eCrK0U6DkWtQWkl-- --------------FtciCWZGKsn2ou2FuuZH0NcR Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEJXd5utNNhpeHcBMx/reFK+KbPocFAmRHTaoFAwAAAAAACgkQ/reFK+KbPofj 5w//aoIRineJB4aifnronwSCIKEox4IlHmrIwGwWX5h3r2nPWG9ss6szlv2A5X1NzY6rpRpiMHyF UbW/mmoWANLhX/mH4ZN0x6kVBo6hSsRSoq6oRUFMhppnUmDZRVAf5qdMxIpezMcO77HkmalrJ5kb vfaBBD8ipU8U3VCQU+L2cqe6ww1fZTc+zkkmXyh/OR1pKlFzrzN7K686c8EjRtmJPpEf9cg3dJ/Y tl46V16KWKjsSU483Y999viDZtQOVdJ8Ivb+Q2mL5yGGzZrXYO9X18VRgdqNUJgEFXVqqra+6bc7 mi3dptc01hoJqJCWmwT3mB2hp6jllv8R6D+JgUaTDv/iOzuJ7UOe1JQ/806ufWdBN85LmbFdRcwf ubZ8WBheS463EHOMBEUU1NUL8EyIrJY1bmy9XW177cAzDo9HlpcQTYqxiEhl0LYdfOMLV227j0ch e+kaXVHMzM032oHMWd/f2Dog2/px5iRzC9tkj6engWpL29/VHjAAQ/hryV7TjoRBGE/j6Tk8SJEs XcA04x+KZl5oydMds7sESsXlYP1UgM/e9wd/+HV18CK01L6ng99IeYJ6kP50GMWb0WGxgYMUxgmn QdRpOm1YoSm9NRug7EsNMRA3GkxYE5sy13NnIcBUb0qPvipykOPIbJuQZGieeI8/igMfZjURVwvV b1A= =lCGL -----END PGP SIGNATURE----- --------------FtciCWZGKsn2ou2FuuZH0NcR-- From nobody Tue Apr 25 04:30:26 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q58FD4494z46bg3 for ; Tue, 25 Apr 2023 04:30:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q58FC6fJZz4ZYZ for ; Tue, 25 Apr 2023 04:30:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-506bdf29712so39505827a12.0 for ; Mon, 24 Apr 2023 21:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682397038; x=1684989038; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OojdO4RQuddAigwsgM3PihdIVQARkmEm4mG/hYBF2XU=; b=ygJ/AYxDH0M/uMMTcl/caEbRqDyqgJRXnqnIPFTMw8/sxUQi/JcaVrX6m+2BV/Hyb+ YT4h26mZ+GlS0cCHHODhCB2AXtm1mjbIuZGHTuNjIR9kpZAS50k9aDqozB3W3NsNfLIv jQTk+peR6GRrcpo5aTm/vGAs4ca6OAKVkFUvoF4TNr3nPPIcPs46gttr3+nx7v1ip6WG PhuQ4uD9wzzZDrKvozX46cfV55fzxL1+yAOLS9o51mAwjmvjbha9fwCQrM+djzH4J0lQ GURdAz3VifOtV2ct532+C2+Q+Fbw7gLiH0xw7M71rhjGnOvS47vh65IHkDzPlEG5ugjn bBLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682397038; x=1684989038; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OojdO4RQuddAigwsgM3PihdIVQARkmEm4mG/hYBF2XU=; b=fTEhe0fm4Bagx2L1l38aSR8SXqTx//kwKmCwz+Me/fwLM6EjgB/02t0x73gIGj/F5z z9eUS/xPjzk/Ej2ch3mWRQh6GTsAtXjDkSuWL9YdEBD7YHojbWra3tmcxWwlYG1XzxHG NDZmK3EOYOWN5FJWcYm1CbStZDn0J14asTUlwNXFLriAevPQs03KEmUe238Tu/MlRUy1 Dx9V35zrG5KdKpguwrzgpYftRdp3FiAC82ymNV6vSj8KVqEHthTSSo2U+hTNc2CYGSC8 Poytb2FR1519qW6b4RxXsYzKEjtjQIkyoneeZSkV55f/k0RHv24T3+CC7KhakcRF/1MJ EItQ== X-Gm-Message-State: AAQBX9cHCq0uzJfEFzpHvRS/Mxn5a/uoaZexehoQIeM6kROJEbSBD6Gl aBTH1NpD3TMqJhOyu9mCG4gzZz60O8LvTUwzrlYelmcqB14XRMMp X-Google-Smtp-Source: AKy350arPX1OZEbvmCmIUgJ1Y5d3T2G5EBznATDQJYVn3hL6w8cISh62GiTkZqNHSAiPEIlB+278s4cem3bXOaFsevk= X-Received: by 2002:aa7:cd11:0:b0:4ad:738b:6706 with SMTP id b17-20020aa7cd11000000b004ad738b6706mr15338159edw.2.1682397037584; Mon, 24 Apr 2023 21:30:37 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org> In-Reply-To: <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org> From: Warner Losh Date: Mon, 24 Apr 2023 22:30:26 -0600 Message-ID: Subject: Re: current status of zfs block_cloning on CURRENT? To: Charlie Li Cc: Pete Wright , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000cbfd0105fa2195c9" X-Rspamd-Queue-Id: 4Q58FC6fJZz4ZYZ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000cbfd0105fa2195c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 24, 2023 at 9:49=E2=80=AFPM Charlie Li wr= ote: > Charlie Li wrote: > > Pete Wright wrote: > >> i've seen a few threads about the block_cloning feature causing data > >> corruption issues on CURRENT and have been keen to avoid enabling it > >> until the dust settles. i was under the impression that we either > >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool > >> upgrade" on a pool today it reported block_cloning was enabled. this > >> is on a system i rebuilt yesterday. > >> > > The dust has settled. > Barely... > >> i was hoping to get some clarity on the effect of having this feature > >> enabled, is this enough to trigger the data corruption bug or does > >> something on the zfs filesystem itself have to be enabled to trigger > >> this? > >> > > The initial problem with block_cloning [0][1] was fixed in commits > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption > > problem [2][3] was fixed in commit > > 63ee747febbf024be0aace61161241b53245449e. All were committed between > > 15-17 April. > > > > [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > [1] https://github.com/openzfs/zfs/pull/14739 > > [2] https://github.com/openzfs/zfs/issues/14753 > > [3] https://github.com/openzfs/zfs/pull/14761 > > > Given mjg@'s thread reporting further crashes/panics, you may want to > keep the sysctl disabled if you upgraded the pool already. > I thought the plan was to keep it disabled until after 14. And even then, when it comes back in, it will be a new feature It should never be enabled. Warner --000000000000cbfd0105fa2195c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 24, 2023 at 9:49=E2=80=AF= PM Charlie Li <vishwin@freebsd.or= g> wrote:
Charlie Li wrote:
> Pete Wright wrote:
>> i've seen a few threads about the block_cloning feature causin= g data
>> corruption issues on CURRENT and have been keen to avoid enabling = it
>> until the dust settles.=C2=A0 i was under the impression that we e= ither
>> reverted or disabled block_cloning on CURRENT, but when i ran &quo= t;zpool
>> upgrade" on a pool today it reported block_cloning was enable= d.=C2=A0 this
>> is on a system i rebuilt yesterday.
>>
> The dust has settled.
Barely...
>> i was hoping to get some clarity on the effect of having this feat= ure
>> enabled, is this enough to trigger the data corruption bug or does=
>> something on the zfs filesystem itself have to be enabled to trigg= er
>> this?
>>
> The initial problem with block_cloning [0][1] was fixed in commits > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and
> 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commi= t
> 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption =
> problem [2][3] was fixed in commit
> 63ee747febbf024be0aace61161241b53245449e. All were committed between <= br> > 15-17 April.
>
> [0] https://github.com/openzfs= /zfs/pull/13392#issuecomment-1504239103
> [1] https://github.com/openzfs/zfs/pull/14739
> [2] https://github.com/openzfs/zfs/issues/14753<= br> > [3] https://github.com/openzfs/zfs/pull/14761
>
Given mjg@'s thread reporting further crashes/panics, you may want to <= br> keep the sysctl disabled if you upgraded the pool already.
=

I thought the plan was to keep it disabled until after = 14. And even then,
when it comes back in, it will be a new featur= e It should never be enabled.

Warner
--000000000000cbfd0105fa2195c9-- From nobody Tue Apr 25 07:35:29 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5DLs1Kc9z46ngw for ; Tue, 25 Apr 2023 07:35:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-23.consmr.mail.gq1.yahoo.com (sonic303-23.consmr.mail.gq1.yahoo.com [98.137.64.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5DLq3b7dz3R6n for ; Tue, 25 Apr 2023 07:35:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=mVtRG8g2; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.204 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682408144; bh=NAJq8d7U3NLGB9nR0eVUBfdL6cY/rsBEj1h9izmT9Mk=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=mVtRG8g2F1PkHT0mmWM+kiqeWZQUoaR0rmtuwmeNIRm90xOwRwFruw4EDTzqLq1+q4f9DmVtuIgr0z8JKUl2+vR+xMc8Eem2wpj7sDrr97xfOXZpwtKYDCCiAQ/DIY6WNBof0m460x25b2vibm6VqOsN+kJ+K1f4eXK6qFv7cfsBDZrayux1fdJzqyRg/81crN5YruxuntOtwMSmdNugng7BwvqPo5OaOrQWiGPn02g4Z2oVHG30MlcTFwKEHy67y6lM7IlCvXyFjoHEUlfBpowHUOCsQ1CYpkT5wisg1B7kPKzbmwDnXQ1M4vl88I6WZ6qBMd0zJmvIx0KEf4mtFw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1682408144; bh=y+CNSf+5LXXYS0OPfuyj17DKhaVVESDvvD4dlXMOCdR=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=UPVKDKOpBQEEmXMKAi/y8IchzvOGuI54+1VnIdkmD3NuOyAL+qBlYd9G0dkXOXqcs3vbs72Lh/AYiYMDdfq4Q5eQrmZk8ZoXJR04FZGBUNDtofHIOtdM3Wnik4cWihdmitZbdgEhTUtLyrQ0PbCFGSj0n9GNHz3qW9zpRFf2y12fri7tTuk2UuJ/v60fiiabjIX5iUkO/G7a/34x7ObxmqH46E95PyfUAsbgMTU4uNd4QYBv3m/11UB+1a1qfyxr2DgI0R7IblbQkGChVeZ+h4ULOTaF/6CHk7zfRvBQY0wQTl5PXN0jPhudAupGKnNRbnXsgDqar7utjwvW8SYjEg== X-YMail-OSG: pUJugscVM1kgNePik8_gvzw8BCgfn1vuahhClLjPhmq2p0Pn0VRI7u8ihVjAouQ YBuxA7cK4xrt_1TW6.GeUP5CwDiwz1Iw0N5wPm64cD.Z0mbktI8lAQ6Zmt9UIQTjAzaOwX_97jJV _Sx_k1qk.Hwq9UOeRCdDTBB3LmPbb3rnjGUlqLEPhzA5oFq9FfLAxtgUKhRXTsvvTqaH5VMxfcA. Gi6hZkYQ87XjgQfYWcZ9Zcfj1vAnglu1FpS8AIODNW0NTseMFHGC49x9_xfoztVLi3yxp8i0eH7d wgHaeD5EgbHa5X5gmsQa.I_wTG2e1fDIe2COUUgmgpTENtvW_wTe4W2SWYqlBLYODRfYQu3b90Iq _KD8.kCLh0rGmy8e9cFoz1wUdi6BiFqvo7w.hGtpgzrdAoxkzjDcV9wL6QpN36ztGFr8aTZT7N7. 0umYf.ouVwkt0Jq.rggI8.F6EGWP4beM8JkbjNHso_oMddNCvOnleS0KkQUewU1un6_8FaJF4cyb _BE3khWG__L2c5bqvrDYMzOGv7Z6.hvGnx5HohXcmhwF8AvTJUEMbRJlfVcIv8mTMsbQwlRtzUic sG_lsBBQHAXkC_3lvqu6phw1UOkMn56tsGOOPmsAR3LW05VncpJKZi9iCc5U_kDQRwhoo7ymkYDb Qb4VNhXMKSAx4Kpts7CBvgRtM.FdBCU_wFNkCIWi8PACoqD7W2L8qnUMhQ9x1RK5.ShRqCjT5YOY nJ1cCHjCt.UB9LQ4eKwYgU9od8bF_VKlQrMAsbpIDQkcE92ltPmkODXuLXaknwRalfdX2.k4bBvA gemCrsKf0ukitMpDW24BE_0FBfjTqNIgTTExC8sPJgiY5zsrTwuHCml5mh.mbjDw2w0jHFEphjTD GowCyGCFc561q4_0CMJ4DNcQIz0lkr8m3rXGErWbAr4ErMCl1Rognhd3lV3AbJP4cU6V.kAQACnU W461E.twI_XMxcVKD4ruKS6idJgaru.2xak.39BcTgfdP8d0ayRICFL4pgUNnhMwwF_woeFh585W mnBVU89w3x5GIPW.oSxdlBt3HERSCHznByCtMXFOGrTccOAUveosUikIgRaBtBBzYj17nq_rphzQ 4CV4wDreR_pZvkiTr_hkDCr.XeEzCWDcD3FsjvrvBecnbHnefcbQRk3yHmZ5wrtQzlMKxAkDZLix KeYmg2Bctw_2S73cN5211O4M4linPYO5s7k_K7NVt1ai5X8_Ii7fHSJQGnpYiJ4xPiSZ9rdPFKIz wLPJWUrJ5qIHowNITfiy992AsQ9Thgg1fKY2RvBuFNcG8FrTKatI2ybEq8R4pVxQwt0weA8YVO5s Kgh_l.4rRMm74JjWLL9EHbqHFhSnzEXI8NckfbQfc0P5k7Y2Io5o080Vv32NDh9Dbyz1P6cvzsS. ihVSBkLO32UFfP2z9eCW_tKo9GI1ubZHZfk4d805c48Dk_.d78nyeLXg5MjhZE_qE.Ulzx4VKoB9 zMoMZToK5viNrSE1dV6did2yGk2tiLlOnJvlanpNu.rjiqWOPhIRBI9Cx3it..AURPuClHvrHcXm wB_XuwLfMgx051VHBI0FVgXSv9X5YcsAZdXS27Y3qEw4I6F9TypgAuRFIpoxolHx8vNg66M0u6QA 9wT9SjnNT5isGOjyZHEgCi8xHRNyzNQrYqFhiZZa7RO7KCBqbFl_OqpKV0d.aYoGz5tCIfPrEId_ A1atfH8DCifC0Rdv.4YQZktKZkw7f13gc9FCsmQ7PX6jb_f2BwGABufTvzHWA6dLejg9sfXxzskL IBkk7r2fhm2YHbDeHzWoId_OH4x_Ks1LZZ.W0Xop_6WSXgv8RSam87szMcH7j3iMuOvVB0Y3T5Ri aukfz94C1gUusFoAfRDz_1wogkVSloVzF8_731KYreR4LGbAieIlsI2_7fzzlUwDMQbjfiJk3KKd 2UyhaAFX6m5rNAr2UoeN_XnuKt6lU8Z13WNSwn8N3FSYwwB9Bp4Xcqvlcg4o.YLuBv5NDeVVhDFt pJA3aKx1Z81pZw1SrWx_C3Ce1otArzB8POKfch6P7crvxdriVZmyJCCBi2sAgUqReeex5Fexmlb6 5cur2EYNioD.jEPH4PDxifORWK0v7NdoNeSANQzwmeAIFUoF8NIiuTtv3NUYoCVyFdtnTVqORDMl jpGZqO_MWSTE.urYDn4fRHEbiqpCYSsWGmfMT9r7AXFi6kq5DkW.O8quzoh2glNf69wXlSwAhqBn 0n23j4WMJSc6YS8lYVKPFPIFy3_WZw0POXFnrw7f5XoJ8uYm5Dl_Sg1SjMa7efPDXojmKC46c2u0 - X-Sonic-MF: X-Sonic-ID: 8f38454d-a12c-4a7d-940d-a29281bf6744 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 25 Apr 2023 07:35:44 +0000 Received: by hermes--production-ne1-7dbd98dd99-zgnmj (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 23fe8ebff53bf8ddba1854cf0e45ed8f; Tue, 25 Apr 2023 07:35:41 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: current status of zfs block_cloning on CURRENT? Message-Id: <6F5B60BD-C5D2-4145-813D-263C52E05A02@yahoo.com> Date: Tue, 25 Apr 2023 00:35:29 -0700 To: Warner Losh , Current FreeBSD X-Mailer: Apple Mail (2.3731.400.51.1.1) References: <6F5B60BD-C5D2-4145-813D-263C52E05A02.ref@yahoo.com> X-Spamd-Result: default: False [-1.99 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.991]; SUBJECT_ENDS_SPACES(0.50)[]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; TO_DN_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.64.204:from]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org] X-Rspamd-Queue-Id: 4Q5DLq3b7dz3R6n X-Spamd-Bar: - X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote on Date: Tue, 25 Apr 2023 04:30:26 UTC : > On Mon, Apr 24, 2023 at 9:49=E2=80=AFPM Charlie Li = wrote: >=20 > > Charlie Li wrote: > > > Pete Wright wrote: > > >> i've seen a few threads about the block_cloning feature causing = data > > >> corruption issues on CURRENT and have been keen to avoid enabling = it > > >> until the dust settles. i was under the impression that we either > > >> reverted or disabled block_cloning on CURRENT, but when i ran = "zpool > > >> upgrade" on a pool today it reported block_cloning was enabled. = this > > >> is on a system i rebuilt yesterday. > > >> > > > The dust has settled. > > Barely... > > >> i was hoping to get some clarity on the effect of having this = feature > > >> enabled, is this enough to trigger the data corruption bug or = does > > >> something on the zfs filesystem itself have to be enabled to = trigger > > >> this? > > >> > > > The initial problem with block_cloning [0][1] was fixed in commits > > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in = commit > > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data = corruption > > > problem [2][3] was fixed in commit > > > 63ee747febbf024be0aace61161241b53245449e. All were committed = between > > > 15-17 April. > > > > > > [0] = https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > > [1] https://github.com/openzfs/zfs/pull/14739 > > > [2] https://github.com/openzfs/zfs/issues/14753 > > > [3] https://github.com/openzfs/zfs/pull/14761 > > > > > Given mjg@'s thread reporting further crashes/panics, you may want = to > > keep the sysctl disabled if you upgraded the pool already. > > >=20 > I thought the plan was to keep it disabled until after 14. And even = then, > when it comes back in, it will be a new feature It should never be = enabled. = https://lists.freebsd.org/archives/freebsd-current/2023-April/003514.html had Pawel Jakub Dawidek reporting adding a sysctl vfs.zfs.bclone_enabled to allow the feature to be actually in use in 14, with a default that would not have it in use. (Any cases of previously enable but not "in use" here is wording simplification as I understand: special handling if active from a previous pool upgrade and later activity so that it cleans itself up, or something like that.) Presuming no ability to have the feature actually in use ( so no ability to set vfs.zfs.bclone_enabled ), there also is then the question of reverting the block_cloning related code in the source vs. just blocking its (non-cleanup) activity. Also, there are folks that ended up with block_cloning enabled and a question is what is intended for 14.0-RELEASE for them: Require them to create a new pool that is not upgraded but has the content transfered? Allow them to use the pools in 14.0-RELELASE? I think all 3 of those are showing up in the exchanges that are happening. Sometimes it can be unclear for one or more of those what the status intended is --but they are not fully independent issues. (My wording is likely a simplification in various ways.) =3D=3D=3D Mark Millard marklmi at yahoo.com From nobody Tue Apr 25 14:56:33 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5Q7h1pT4z47HpL for ; Tue, 25 Apr 2023 14:56:48 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5Q7g5Dtbz3Mg4; Tue, 25 Apr 2023 14:56:47 +0000 (UTC) (envelope-from pete@nomadlogic.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1682434596; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=pdZnZ5WlTrkQSK1YmaVjRvwKV/TuAAUONtK1kEavhB0=; b=A9AvdWu0h/Sa3ntERY5Bm2lGILlkEkQOhOk8HW5Q/YexRobtjJu5kYi24YwUxEW7wi7/tm pXHuTXUaOvgTkvxkiq6upgO5asNvez7vGVwc5IjjLJLMUixKuP/lS1RWCVmmf+QnCZDStc PtVdEA/+TiHC7zSPnMVPCwU5F03p+NE= Received: from [192.168.1.160] (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 286ffed3 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 25 Apr 2023 14:56:35 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------MkHvJs0pwSFTDOLkNx7PlcZm" Message-ID: <6052c5c7-cc32-c1ea-6943-aaebd0b9b02f@nomadlogic.org> Date: Tue, 25 Apr 2023 07:56:33 -0700 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: current status of zfs block_cloning on CURRENT? Content-Language: en-US To: Warner Losh , Charlie Li Cc: FreeBSD Current References: <4f9470a0-4f14-a31b-52a9-7746d6fa09e6@nomadlogic.org> <5ee4d2ec-a09f-00ee-17f2-c1593aaf365c@freebsd.org> <9c55271b-e2cf-85b7-cc99-00ddcb76f98e@freebsd.org> From: Pete Wright In-Reply-To: X-Rspamd-Queue-Id: 4Q5Q7g5Dtbz3Mg4 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------MkHvJs0pwSFTDOLkNx7PlcZm Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 4/24/23 21:30, Warner Losh wrote: > > > On Mon, Apr 24, 2023 at 9:49 PM Charlie Li wrote: > > Charlie Li wrote: > > Pete Wright wrote: > >> i've seen a few threads about the block_cloning feature causing > data > >> corruption issues on CURRENT and have been keen to avoid > enabling it > >> until the dust settles.  i was under the impression that we either > >> reverted or disabled block_cloning on CURRENT, but when i ran > "zpool > >> upgrade" on a pool today it reported block_cloning was > enabled.  this > >> is on a system i rebuilt yesterday. > >> > > The dust has settled. > Barely... > >> i was hoping to get some clarity on the effect of having this > feature > >> enabled, is this enough to trigger the data corruption bug or does > >> something on the zfs filesystem itself have to be enabled to > trigger > >> this? > >> > > The initial problem with block_cloning [0][1] was fixed in commits > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in > commit > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data > corruption > > problem [2][3] was fixed in commit > > 63ee747febbf024be0aace61161241b53245449e. All were committed > between > > 15-17 April. > > > > [0] > https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > [1] https://github.com/openzfs/zfs/pull/14739 > > [2] https://github.com/openzfs/zfs/issues/14753 > > [3] https://github.com/openzfs/zfs/pull/14761 > > > Given mjg@'s thread reporting further crashes/panics, you may want to > keep the sysctl disabled if you upgraded the pool already. > > > I thought the plan was to keep it disabled until after 14. And even then, > when it comes back in, it will be a new feature It should never be > enabled. > that was my reading of things too - thanks for the tip on disabling the sysctl knob Charlie, I'll do that. if this is really intended to be live i'd like to suggest we update zpool-features(7) at the least so others aren't caught by surprise. i'd propose a PR myself, but I'm not %100 clear on what its intent is. -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA --------------MkHvJs0pwSFTDOLkNx7PlcZm Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

On 4/24/23 21:30, Warner Losh wrote:


On Mon, Apr 24, 2023 at 9:49 PM Charlie Li <vishwin@freebsd.org> wrote:
Charlie Li wrote:
> Pete Wright wrote:
>> i've seen a few threads about the block_cloning feature causing data
>> corruption issues on CURRENT and have been keen to avoid enabling it
>> until the dust settles.  i was under the impression that we either
>> reverted or disabled block_cloning on CURRENT, but when i ran "zpool
>> upgrade" on a pool today it reported block_cloning was enabled.  this
>> is on a system i rebuilt yesterday.
>>
> The dust has settled.
Barely...
>> i was hoping to get some clarity on the effect of having this feature
>> enabled, is this enough to trigger the data corruption bug or does
>> something on the zfs filesystem itself have to be enabled to trigger
>> this?
>>
> The initial problem with block_cloning [0][1] was fixed in commits
> e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and
> 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit
> 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption
> problem [2][3] was fixed in commit
> 63ee747febbf024be0aace61161241b53245449e. All were committed between
> 15-17 April.
>
> [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103
> [1] https://github.com/openzfs/zfs/pull/14739
> [2] https://github.com/openzfs/zfs/issues/14753
> [3] https://github.com/openzfs/zfs/pull/14761
>
Given mjg@'s thread reporting further crashes/panics, you may want to
keep the sysctl disabled if you upgraded the pool already.

I thought the plan was to keep it disabled until after 14. And even then,
when it comes back in, it will be a new feature It should never be enabled.


that was my reading of things too - thanks for the tip on disabling the sysctl knob Charlie, I'll do that.

if this is really intended to be live i'd like to suggest we update zpool-features(7) at the least so others aren't caught by surprise.  i'd propose a PR myself, but I'm not %100 clear on what its intent is.

-pete

-- 
Pete Wright
pete@nomadlogic.org
@nomadlogicLA
--------------MkHvJs0pwSFTDOLkNx7PlcZm-- From nobody Tue Apr 25 15:15:48 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5QYf5QdQz47K1C for ; Tue, 25 Apr 2023 15:15:50 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5QYf4rbGz3Qh6 for ; Tue, 25 Apr 2023 15:15:50 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682435750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cf9J0MwHYZ6Wleg6mCcnGOQ/fWsd7YScJseGNCVoxzE=; b=nYaPo+Pwj11R2vTZBTMyjApqCrG7dtKrnf1QFNHc0Xgj8WCzlmXOGsVGJK+m36Z3WdVUzp ypWJvo7t/bzpCSacX+Bu7KjzFggADwn2hZN4KQTH9hbOqC1ZNuMiij1xOtDW/GZ43PQpy6 JfXNlYK+22peRZ52y68Nt/6DJiYAdWT0aWv6DnomW4se97k+5BHp1lXXDfMmkOIDmLtprn MYxQgxDnPDC82GY1ZbkWHaVpbRHiQVKGYZ5UBIAMF7S9GoI+6k3jflzJKWQgxenDUoy2nX 5oUJCL9bfshxDKyaJo6KaN9Ar595bJU9iwGFD0lOrK7nasSi9Pe3zwbS2Itszw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682435750; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cf9J0MwHYZ6Wleg6mCcnGOQ/fWsd7YScJseGNCVoxzE=; b=mAIrKcwVqev6MH84N0i6lObyiLtokPO2BoWEhSerVyBbrasbcCLZY/4HbjQrYbGiv9fM2o aQORH3FhIuHjjPfItfv9Pof4sl118e+vMz9/fFt+PPwr3GmrSptUnkgo7jXgI4K/ZD1wnz kxM3fH3wvHhqzsLHqRMxXuLda/TRS4FdEWJOReOFvSvr11+FjTTPiCMwq5DzPedhZWEUWW qoJQ3P/VSlR2eHbqtEiTV0V+yeZkyP30CC+IehG3mJJHiEFgfmChd5iksISZrwkftpB/kX 12d8FcEyGWCpve/Bi3ZRipJOknwz2hrKt3gCu92h/Ih0qybFWnAzKgtX6et29A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682435750; a=rsa-sha256; cv=none; b=CXBOUCRUiS0ZZ/zAotTKkU+t8s5R/KGOHgBUceS5H5yMOGAgZt4xn8yLeRxb8rgMWkqmsL m7rL/6KPF5AyBkSqVubLHBhhGeUlxUlowYgm/EjubMSqeacQ4NkmaJU7CFFvoSci2cYO5t A7UZJgqlprPOVzDnlPGzjVgTjQhQkSVrWDlmank1/inhe6IxzKMw1go6ynsrCGZSffTiol mGh+L9JBQhjjscAds96yvFRlK2W7RrQ/U+FNoLASElsTnAzQn+3IOqIArl/fZNBPKDvyqI /psZwF4qDdDeVaeAuhNwatXY2azjK8theYLw8iRWy2uBvv/8cR8fKrATZQllxg== Received: from [192.168.0.101] (unknown [88.201.168.234]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: fluffy) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q5QYf295Jz19cD for ; Tue, 25 Apr 2023 15:15:50 +0000 (UTC) (envelope-from fluffy@FreeBSD.org) Message-ID: <9d4154bd-5e08-97c3-f55d-63c78d4b0eac@FreeBSD.org> Date: Tue, 25 Apr 2023 18:15:48 +0300 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 Content-Language: ru, en-GB, en-US To: freebsd-current@freebsd.org References: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> From: Dima Panov Organization: FreeBSD.org In-Reply-To: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------X0rb0hHA8kX11XF1fBlpSY14" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------X0rb0hHA8kX11XF1fBlpSY14 Content-Type: multipart/mixed; boundary="------------vBnUsZSFPY00ULydNYLCcMQ9"; protected-headers="v1" From: Dima Panov To: freebsd-current@freebsd.org Message-ID: <9d4154bd-5e08-97c3-f55d-63c78d4b0eac@FreeBSD.org> Subject: Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8 References: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> In-Reply-To: <165db247-be0e-fc9f-1269-e09fe1b8b977@FreeBSD.org> --------------vBnUsZSFPY00ULydNYLCcMQ9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TW9pbi1tb2luIQ0KDQoNClNvbWUgYWRkaXRpb25hbCBpbmZvLg0KDQpXaXRoIGp1c3QtY29v a2VkIC1jdXJyZW50IChGcmVlQlNEIDE0LjAtQ1VSUkVOVCAjMSA4ODNhNDllNWE6IFR1ZSBB cHIgMjUgMTM6NDM6NTYgTVNLIDIwMjMgIGFybTY0IDE0MDAwODgpDQphbGwgc3RhYmxlIHJl bGVhc2VzIG9mIEdDQyBhcmUgdW5hYmxlIHRvIGJ1aWxkIHdpdGggc2FtZSBlcnJvciAoZ2Nj MTAsIGdjYzExLCBnY2MxMikgOigNCg0KQnV0ISBnY2MqLWRldmVsIHBvcnRzIGJ1aWxkcyBm aW5lLCBhbmQgZmluYWxseSBJIGNhbiBidWlsZCBhbm4gZ2NjLWRlcGVuZGVkIHN0dWZmIG9u IG15IGJveC4NClRlc3RlZCBnY2MxMS1kZXZlbCwgZ2NjMTItZGV2ZWwsIGdjYzEzLWRldmVs DQoNCg0KDQpPbiAxNC4wNC4yMDIzIDAwOjQyLCBEaW1hIFBhbm92IHdyb3RlOg0KPiBNb2lu LW1vaW4hDQo+IA0KPiBTb21ldGhpbmdzIGNoYW5nZWQgaW4gbWFpbiBicmFuY2ggYmV0d2Vl biBNYXIsIDI4IGFuZCBBcHIsIDggd2hpY2ggY2F1c2VzIHBlcm1hbmVudCBidWlsZCBlcnJv ciBmb3IgbGFuZy9nY2MxWzAxMl0gb24gYWFyY2g2NCAoZXhhY3RseSBWTVdhcmUgY29udGFp bmVyIG9uIE0xUHJvIG1hYykNCj4gDQo+IGR1cmluZyBSVEwgcGFzczogc2NoZWQxDQo+IGdp bXBsZS1tYXRjaC5jYzogSW4gZnVuY3Rpb24gJ2Jvb2wgZ2ltcGxlX25vcF9hdG9taWNfYml0 X3Rlc3RfYW5kX3AodHJlZSwgdHJlZV9ub2RlKiosIHRyZWVfbm9kZSogKCopKHRyZWUpKSc6 DQo+IGdpbXBsZS1tYXRjaC5jYzozOTIxNToxOiBpbnRlcm5hbCBjb21waWxlciBlcnJvcjog U2VnbWVudGF0aW9uIGZhdWx0DQo+IDM5MjE1IHwgfQ0KPiAgwqDCoMKgwqDCoCB8IF4NCj4g bW1hcDogSW52YWxpZCBhcmd1bWVudA0KPiBQbGVhc2Ugc3VibWl0IGEgZnVsbCBidWcgcmVw b3J0LCB3aXRoIHByZXByb2Nlc3NlZCBzb3VyY2UgKGJ5IHVzaW5nIC1mcmVwb3J0LWJ1Zyku DQo+IFNlZSA8aHR0cHM6Ly9nY2MuZ251Lm9yZy9idWdzLz4gZm9yIGluc3RydWN0aW9ucy4N Cj4gZ21ha2VbNF06ICoqKiBbTWFrZWZpbGU6MTE0NTogZ2ltcGxlLW1hdGNoLm9dIEVycm9y IDENCj4gZ21ha2VbNF06ICoqKiBXYWl0aW5nIGZvciB1bmZpbmlzaGVkIGpvYnMuLi4uDQo+ IHJtIGdjYy5wb2QgZ2ZvcnRyYW4ucG9kDQo+IA0KPiANCg0KLS0gDQpTaW5jZXJlbHksDQpE aW1hIChmbHVmZnlARnJlZUJTRC5vcmcsIGh0dHBzOi8vdC5tZS9GbHVmZnlCU0QpDQooZGVz a3RvcCwga2RlLCB4MTEsIG9mZmljZSwgcG9ydHMtc2VjdGVhbSlARnJlZUJTRCB0ZWFtDQo= --------------vBnUsZSFPY00ULydNYLCcMQ9-- --------------X0rb0hHA8kX11XF1fBlpSY14 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEELTAsy5mEEwxvh7r8+4ugndU5jykFAmRH7qQFAwAAAAAACgkQ+4ugndU5jyk4 Mw/+N+gw+0fzRYtRV6r6r0WwZxdrXZYuzcsoGbBarN/J1pbdtZcAM+/wr9l9T9XdhingWqJ/ztDc QkXCZR8UvWX3yNzPY3GqpY+wZ/pAmbj8jclEPEks7pfkKqbJkqX2OQe8UEG9mZQ4LQ7SAlKpAE3Y XXSOYgFe9BCtCZpyxck389r3brTO2gzK+WBZcmrnIX8tH9QXUQQdx2Ts0j/kEHfOa7dVxW9jjfIw pOdP0pZQoQJh8xtv5HVWj2NeO2dDiR2OFMIvl30LL6KuWUxsb4A2/hfzY4aG7kgGMl8dYOz1/kWM DNpY17c+0ajRrr42Q/QuM0EEM6t4DS9pfzm+4MA87YYjOq/UNgJzPtJm/qbifWEzGFwvT++/WHCk sZbJ4woozPlPDSVomPTwp9mKwP7xev8x7NOvhJBowEXVmNK0VekhmiT6PAtPgul4SW37kf4uR5YR cmAs4YIRs4uKM+CNzGlCdAPDzYXSSdxVUbGzioneud7Hfx+B21pQrKygmsCZTRzodf4VcztHhSzf AKRWzWH9r09dOZcHN+mtaMBMXMjAey9u3Qr3zEcIMhPN6Joc8kRt0NU6DKzAnPttg5+AINOuDOrW XdP3taJsgpyVEFxG3YYu1xrajXV3KdT83Gq1e0weKBoX6f39MZ60qmlD++Luzh+qwp8py1149CGR dbA= =SPOt -----END PGP SIGNATURE----- --------------X0rb0hHA8kX11XF1fBlpSY14-- From nobody Tue Apr 25 23:10:42 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5d5k1dpDz46rx3 for ; Tue, 25 Apr 2023 23:10:50 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5d5j5xVzz3rgQ for ; Tue, 25 Apr 2023 23:10:49 +0000 (UTC) (envelope-from pete@nomadlogic.org) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1682464246; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+UgAWGMAfYvKQurkSxVVKR+PSuOBqua5+FB2PM1GAqI=; b=MKJIg8ep4aPbdQ1BxhiDCLHH1WVRBJEecMDL+mk1g4+cCt++X9dANsKozWz902m7SHopHt GGWFyyQkWsuV5VtHF0lcWoy+Epi1KZg/l+MW/H4lD3HwJlPeEdzaVMNvlafGKehhWqNbKM uijPVHgY+Y7e/vZ+1LbJ40a700+88WQ= Received: from topanga (cpe-24-24-168-214.socal.res.rr.com [24.24.168.214]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 0ea50c58 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 25 Apr 2023 23:10:43 +0000 (UTC) Date: Tue, 25 Apr 2023 16:10:42 -0700 From: Pete Wright To: Mark Millard Cc: Warner Losh , Current FreeBSD Subject: Re: current status of zfs block_cloning on CURRENT? Message-ID: References: <6F5B60BD-C5D2-4145-813D-263C52E05A02.ref@yahoo.com> <6F5B60BD-C5D2-4145-813D-263C52E05A02@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6F5B60BD-C5D2-4145-813D-263C52E05A02@yahoo.com> X-Rspamd-Queue-Id: 4Q5d5j5xVzz3rgQ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, Apr 25, 2023 at 12:35:29AM -0700, Mark Millard wrote: > Warner Losh wrote on > Date: Tue, 25 Apr 2023 04:30:26 UTC : > > > On Mon, Apr 24, 2023 at 9:49 PM Charlie Li wrote: > > > > > Charlie Li wrote: > > > > Pete Wright wrote: > > > >> i've seen a few threads about the block_cloning feature causing data > > > >> corruption issues on CURRENT and have been keen to avoid enabling it > > > >> until the dust settles. i was under the impression that we either > > > >> reverted or disabled block_cloning on CURRENT, but when i ran "zpool > > > >> upgrade" on a pool today it reported block_cloning was enabled. this > > > >> is on a system i rebuilt yesterday. > > > >> > > > > The dust has settled. > > > Barely... > > > >> i was hoping to get some clarity on the effect of having this feature > > > >> enabled, is this enough to trigger the data corruption bug or does > > > >> something on the zfs filesystem itself have to be enabled to trigger > > > >> this? > > > >> > > > > The initial problem with block_cloning [0][1] was fixed in commits > > > > e0bb199925565a3770733afd1a4d8bb2d4d0ce31 and > > > > 1959e122d9328b31a62ff7508e1746df2857b592, with a sysctl added in commit > > > > 068913e4ba3dd9b3067056e832cefc5ed264b5cc. A different data corruption > > > > problem [2][3] was fixed in commit > > > > 63ee747febbf024be0aace61161241b53245449e. All were committed between > > > > 15-17 April. > > > > > > > > [0] https://github.com/openzfs/zfs/pull/13392#issuecomment-1504239103 > > > > [1] https://github.com/openzfs/zfs/pull/14739 > > > > [2] https://github.com/openzfs/zfs/issues/14753 > > > > [3] https://github.com/openzfs/zfs/pull/14761 > > > > > > > Given mjg@'s thread reporting further crashes/panics, you may want to > > > keep the sysctl disabled if you upgraded the pool already. > > > > > > > I thought the plan was to keep it disabled until after 14. And even then, > > when it comes back in, it will be a new feature It should never be enabled. > > > https://lists.freebsd.org/archives/freebsd-current/2023-April/003514.html > > had Pawel Jakub Dawidek reporting adding a sysctl vfs.zfs.bclone_enabled > to allow the feature to be actually in use in 14, with a default that > would not have it in use. (Any cases of previously enable but not "in > use" here is wording simplification as I understand: special handling > if active from a previous pool upgrade and later activity so that > it cleans itself up, or something like that.) ah ok thanks for that insight. on my system where i did upgrade the pool i have this sysctl: $ sysctl vfs.zfs.bclone_enabled vfs.zfs.bclone_enabled: 0 which seems to jive with the statement above. thanks! -p -- Pete Wright pete@nomadlogic.org From nobody Wed Apr 26 07:01:00 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5qXl1n9zz47LS0 for ; Wed, 26 Apr 2023 07:01:27 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4Q5qXj1nW1z4VgR for ; Wed, 26 Apr 2023 07:01:25 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=alvermark.net header.s=x header.b="f3/smck6"; spf=pass (mx1.freebsd.org: domain of jakob@alvermark.net designates 185.34.136.138 as permitted sender) smtp.mailfrom=jakob@alvermark.net; dmarc=none Received: from c-bc4d235c.06-431-73746f70.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1prZ9Q-0002bq-Pp for freebsd-current@freebsd.org; Wed, 26 Apr 2023 09:01:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:Subject:From: To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/yFrBpY291/GMLRXST9vW0eWjOaDaCS5LU/D9v3G/Pw=; b=f3/smck67VxMg7OhIK5vvxyUt4 mb5hSQq+dUWGdhb1rB5DDIv4YKbwJKxoI1+zZzfzfYZdu1YXNA8chuZGr8zPmd9E3Zs/UWCKwsnKL 7yYA6K+e1FvtwDFfivzQO+rivq62xpX7Fh6k/HRKjXE5WZyvYR+JqxQd9Dk9KUJBLp1iFBmRbwLJI ZJSpyQFtnqtpfUESZORxqUsmRPlt20YMzenM1Srhxkub9Xp3ObY0L4rSrgQAkwjSOa98AhnF7Brar 3+VLonJEhCwcSktlDURYxhyVbuUHzNqTzlc3WaEnBoWTtXggtaPBTviPkjMMK4TVH9Go0t54G5oc8 YCG1joUg==; Received: from [192.168.67.27] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1prZ9B-00016C-1E for freebsd-current@freebsd.org; Wed, 26 Apr 2023 09:01:01 +0200 Message-ID: <12cb8ced-8f80-1682-594a-63b402013768@alvermark.net> Date: Wed, 26 Apr 2023 09:01:00 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: freebsd-current From: Jakob Alvermark Subject: change in compat/linux breaking net/citrix_ica Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.49 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.994]; R_SPF_ALLOW(-0.20)[+ip4:185.34.136.138]; R_DKIM_ALLOW(-0.20)[alvermark.net:s=x]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; BLOCKLISTDE_FAIL(0.00)[92.35.77.188:server fail,185.34.136.138:server fail]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/24, country:IT]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[alvermark.net:+]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; DMARC_NA(0.00)[alvermark.net: no valid DMARC record]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4Q5qXj1nW1z4VgR X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi, I use net/citrix_ica for work. After a recent change to -current in compat/linux it no longer works. The binary just segfaults. I have bisected and it happened after this commit: commit 40c36c4674eb9602709cf9d0483a4f34ad9753f6 Author: Dmitry Chagin Date:   Sat Apr 22 22:17:17 2023 +0300     linux(4): Export the AT_RANDOM depending on the process osreldata     AT_RANDOM has appeared in the 2.6.30 Linux kernel first time.     Reviewed by:            emaste     Differential Revision:  https://reviews.freebsd.org/D39646     MFC after:              1 month  sys/compat/linux/linux_elf.c | 3 ++-  sys/compat/linux/linux_mib.h | 1 +  2 files changed, 3 insertions(+), 1 deletion(-) If I revert the change, citrix_ica works again. Thanks, Jakob Alvermark From nobody Wed Apr 26 08:39:30 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5sk50KLXz47hDW for ; Wed, 26 Apr 2023 08:39:41 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (bastille.leidinger.net [89.238.82.207]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5sk44jxFz3F7n for ; Wed, 26 Apr 2023 08:39:40 +0000 (UTC) (envelope-from Alexander@leidinger.net) Authentication-Results: mx1.freebsd.org; none Date: Wed, 26 Apr 2023 10:39:30 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1682498373; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=RjvGX0zl5i25hX1KFyBhTBXXla0PVze1I8y2mFJp8GY=; b=g1NWe/kOsaTdz3nK3/aGIg7w6R0jmhuydNk8RG887vuwzDJbOO0ue1NQ8UBnAJQqX3RPcQ +hUttm9vj1WBwz3szZMs78yCngMcEE5TIVQHH9Bx0eORefoB6ajbJfYcaTSQ/4Du43iP31 k8tUTTChSWa8L63c27NZMSW9p4mKMpdvrjjKRidLI8tI2v6rrr6w+Mzw76PAfKVHcpTveo 4w5uvB6VpLozrG/hioOi5cjUwF456Srn1c+TqKmQkFuTQ+lgiJCN1/X37G/HdaItvgD/zw GQhOpWUL+Ds5djd1t7ia/irOdZuaHbF9VG7vF53GbnFUBMQuqVuNl2pDHqtIZg== Message-ID: <20230426103930.Horde.rzTJQWjErPZ63XaLSZqtDYD@webmail.leidinger.net> From: Alexander Leidinger To: Jakob Alvermark Cc: freebsd-current Subject: Re: change in compat/linux breaking net/citrix_ica In-Reply-To: <12cb8ced-8f80-1682-594a-63b402013768@alvermark.net> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_jrWTNHXEr8Yx-qvyjWFfYHC"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Q5sk44jxFz3F7n X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:89.238.64.0/18, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_jrWTNHXEr8Yx-qvyjWFfYHC Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Jakob Alvermark (from Wed, 26 Apr 2023=20=20 09:01:00=20+0200): > Hi, > > > I use net/citrix_ica for work. > > After a recent change to -current in compat/linux it no longer=20=20 >=20works. The binary just segfaults. What does "sysctl compat.linux.osrelease" display? If it is not 2.6.30=20= =20 or=20higher, try to set it to 2.6.30 or higher. Bye, Alexander. > I have bisected and it happened after this commit: > > commit 40c36c4674eb9602709cf9d0483a4f34ad9753f6 > Author: Dmitry Chagin > Date:=C2=A0=C2=A0 Sat Apr 22 22:17:17 2023 +0300 > > =C2=A0=C2=A0=C2=A0 linux(4): Export the AT_RANDOM depending on the proces= s osreldata > > =C2=A0=C2=A0=C2=A0 AT_RANDOM has appeared in the 2.6.30 Linux kernel firs= t time. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_jrWTNHXEr8Yx-qvyjWFfYHC Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmRI40IACgkQEg2wmwP4 2IYWww/8CGE7CykBvfUx2v7VqcEBFEcDJ0SCrdF8IFaIcfvN/VeuxCWvMXzTwLV9 OZu/ceMcZhsN6cNMnfJuYcNbh6BjNRoI90DFrQQTVcw3tJrCHp90HRhSqLQT7rzv OZ0dUWJL4hTJ+l2BVWxgkCv/cbcWaRAe7XN3+PRugCkXvRMklVoQn7frFAOQkS3O erKFniYmXmvRMj5NJcW2ND+oOGhdwv86N0KGMot4l0zI/XnTh4fGf2ZIL5B9BwQP BxaOOeteAyqNcweBdu4FTnPqUgNlkKTOm/ww57LEgUNtYC0v0cA8wLtFZ0qI75jg OzMy3GalzLzDKyhYLLWCV7gi3qlT/de+O7iiJEoO2ouikjk/KvprCTQxgi34t0zi 9RD4JNfPgNpHKP7HNiLZ+0pJHuYcBoksw0RACqWdODb/oMs1xUm+HY3UCcVmf4tD 5IuLH+5k6wLAm/6j0ipK5czd5j0cSvJFT5esa68dwiq/amLDljakRzxaxibKtZSs yvIYn4sBDNwFfHwoMUooLLGD+/DCV8BhqitWsmtf0qT32bxy+055YiWhxg6iNuk/ zhdYoz9WsLKxDfUOpF1A3XEM4d5wQvC4D3WAUf482USYORs3tPyHGaNZen5yDQbd 2SWxGNZOc6cVmKvKvMxUm/78WvLzwVwFQv0z5KFj8AEPpjA/qwM= =oJ/T -----END PGP SIGNATURE----- --=_jrWTNHXEr8Yx-qvyjWFfYHC-- From nobody Wed Apr 26 08:57:15 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5t6X2lbGz47j6L for ; Wed, 26 Apr 2023 08:57:24 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Received: from heemeyer.club (heemeyer.club [195.93.173.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5t6W5PBYz3HPc for ; Wed, 26 Apr 2023 08:57:23 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Authentication-Results: mx1.freebsd.org; none Received: from heemeyer.club (localhost [127.0.0.1]) by heemeyer.club (8.17.1/8.16.1) with ESMTP id 33Q8vFfc002432; Wed, 26 Apr 2023 11:57:15 +0300 (MSK) (envelope-from dchagin@heemeyer.club) Received: (from dchagin@localhost) by heemeyer.club (8.17.1/8.16.1/Submit) id 33Q8vF7d002431; Wed, 26 Apr 2023 11:57:15 +0300 (MSK) (envelope-from dchagin) Date: Wed, 26 Apr 2023 11:57:15 +0300 From: Dmitry Chagin To: Jakob Alvermark Cc: freebsd-current Subject: Re: change in compat/linux breaking net/citrix_ica Message-ID: References: <12cb8ced-8f80-1682-594a-63b402013768@alvermark.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12cb8ced-8f80-1682-594a-63b402013768@alvermark.net> X-Rspamd-Queue-Id: 4Q5t6W5PBYz3HPc X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:61400, ipnet:195.93.173.0/24, country:RU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 26, 2023 at 09:01:00AM +0200, Jakob Alvermark wrote: > Hi, > > > I use net/citrix_ica for work. > > After a recent change to -current in compat/linux it no longer works. > The binary just segfaults. > > I have bisected and it happened after this commit: > > commit 40c36c4674eb9602709cf9d0483a4f34ad9753f6 > Author: Dmitry Chagin > Date:   Sat Apr 22 22:17:17 2023 +0300 > >     linux(4): Export the AT_RANDOM depending on the process osreldata > >     AT_RANDOM has appeared in the 2.6.30 Linux kernel first time. > >     Reviewed by:            emaste >     Differential Revision:  https://reviews.freebsd.org/D39646 >     MFC after:              1 month > >  sys/compat/linux/linux_elf.c | 3 ++- >  sys/compat/linux/linux_mib.h | 1 + >  2 files changed, 3 insertions(+), 1 deletion(-) > > > If I revert the change, citrix_ica works again. > Hi, thanks, I'll commit fix today after some testing > > Thanks, > > Jakob Alvermark > From nobody Wed Apr 26 10:36:20 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5wJr3bPCz47nl6 for ; Wed, 26 Apr 2023 10:36:28 +0000 (UTC) (envelope-from zlei@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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5wJr37sqz3hSX; Wed, 26 Apr 2023 10:36:28 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682505388; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=1GSH51sXxehPFRppLnUkwF3I2PQjNrjohpW5rA7wUaw=; b=Cy2pr8ZBIIFzO8wNbrpyHXCkMF292Sp17fKMY4OzbWE89FMGsA2ymj+upyx3tzmMiiuV53 V4T6gfYMb8Wyq91BejwQHtIXZZbC5XqkvxhyFjSGEOdeOQc066bPbVX/gL4DvTx2w3VPpY ms1oHSxTqWk90kEEH5weRihWZ3X9EWkrQun6XgAa/tjbnUu9f58djU3nYQAtcZyDxPgi8G TIsIzW6Lcxhcq2ufISmNXYPmpiiM/ZAuk4NsUiltWzku7h2jvdjf1DlSZ3ROLMPE9D8/5e JNMKqDFURDw8jwbkshZqq1zWNZC3ewgih6U1QvKvC62vAGOaQjwCI33c1k0g4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682505388; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=1GSH51sXxehPFRppLnUkwF3I2PQjNrjohpW5rA7wUaw=; b=Cx3IF3U1ncWMFW4CU1fyGA1CsrKrP8pW2tD7GgBErqSSz7Iuz85XRant9Hfg9KSMd/HwjC JUGgtvGDCLFe/VvijFa0yf4VHeAInZADzSaR68lWJengRmA1YpUhXRMPEXFR6BoGu9GxVH eDbCDFJrmL9kDIofKCPGWJXBgiL0nxiDbnV/+lvn2WlonmXeCqwabb7TcEOvftIvaY0wQh 2afPhN1lNWYDjyBjHEFCfqUJIEZHOaSHnCNDZ8eKm26PPwyjnGUQiXilIEnEbtyyuEXqKt pMmQ+MleHn31FpVSYX5NKQnYKcj1qBWPZpH04Fj1mY/eCJZquArdBbn5NKYZ7w== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682505388; a=rsa-sha256; cv=none; b=PthyGhSUr3YWfsRG4Qv6YKU8Kp29gsl5ZRhDBqRlwsH2M8Buj7TEfXOB7rAlYmg+eefNpj oCnVknVr0Inqo15yKJgI6iry6JD4pSaqfV7SbwlK+QMn/8e66MCEHrK2k8Zbx/edx9WNmm 4M3TPG6zc+IScTu7UBMWqqqmWprbBffxrS6mSvj4Jf0mybk034HgxVX1GTiuMDX+o2Tc57 kKi3oGRpx5qbm9xixpZ5uUcE1ZlVDjYNNre/3BkRL/g1VFyUqUT/6jhUjLkb14KtWEpqXb j1eBZX1O1sg2kUyGzPfYQe9MHEV3yZufu1qcso0IvxDXfTAx7NsaHyU413SlaQ== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q5wJq1jGvzX1G; Wed, 26 Apr 2023 10:36:26 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) Subject: Link modules to DYN type Message-Id: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> Date: Wed, 26 Apr 2023 18:36:20 +0800 Cc: Hans Petter Selasky , Gleb Smirnoff To: FreeBSD CURRENT X-Mailer: Apple Mail (2.3696.120.41.1.2) X-ThisMailContainsUnwantedMimeParts: N Hi, I'm recently working on https://reviews.freebsd.org/D39638 (sysctl(9): = Enable vnet sysctl variables be loader tunable), the changes to `sys/kern/link_elf_obj.c` are runtime tested, but not = those to `sys/kern/link_elf.c` . After some hacking I realized that `link_elf.c` is for EXEC (Executable = file) or DYN (Shared object file), and `link_elf_obj.c` is for REL (Relocatable file). ``` /* link_elf.c */ static int link_elf_load_file(linker_class_t cls, const char* filename, linker_file_t* result) { ... if (hdr->e_type !=3D ET_EXEC && hdr->e_type !=3D ET_DYN) { error =3D ENOSYS; goto out; } ... } /* link_elf_obj.c */ static int link_elf_load_file(linker_class_t cls, const char *filename, linker_file_t *result) { ... if (hdr->e_type !=3D ET_REL) { error =3D ENOSYS; goto out; } ... } ``` Run the following snip: ``` # find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | grep = Type ``` shows that all the kernel modules' types are `REL (Relocatable file)`. I guess if some module such as if_bridge is linked to DYN type, then I = can do runtime for the changes to `sys/kern/link_elf.c`. I'm not familiar with elf and linkers, is that ( compile module and link = it to DYN type ) possible ? Best regards, Zhenlei From nobody Wed Apr 26 10:55:02 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5wkR12FSz47ps4 for ; Wed, 26 Apr 2023 10:55:11 +0000 (UTC) (envelope-from hselasky@freebsd.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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5wkQ4kChz3kFn; Wed, 26 Apr 2023 10:55:10 +0000 (UTC) (envelope-from hselasky@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.36.2.154] (unknown [46.212.121.255]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D3DE2261CF7; Wed, 26 Apr 2023 12:55:01 +0200 (CEST) Message-ID: <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> Date: Wed, 26 Apr 2023 12:55:02 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Link modules to DYN type To: Zhenlei Huang , FreeBSD CURRENT Cc: Gleb Smirnoff References: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> Content-Language: en-US From: Hans Petter Selasky In-Reply-To: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Q5wkQ4kChz3kFn X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/26/23 12:36, Zhenlei Huang wrote: > Hi, > > I'm recently working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable vnet sysctl variables be loader tunable), > the changes to `sys/kern/link_elf_obj.c` are runtime tested, but not those to `sys/kern/link_elf.c` . > > After some hacking I realized that `link_elf.c` is for EXEC (Executable file) or DYN (Shared object file), and `link_elf_obj.c` is > for REL (Relocatable file). > > ``` > /* link_elf.c */ > static int > link_elf_load_file(linker_class_t cls, const char* filename, > linker_file_t* result) > { > ... > if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN) { > error = ENOSYS; > goto out; > } > ... > } > > > /* link_elf_obj.c */ > static int > link_elf_load_file(linker_class_t cls, const char *filename, > linker_file_t *result) > { > ... > if (hdr->e_type != ET_REL) { > error = ENOSYS; > goto out; > } > ... > } > ``` > > Run the following snip: > ``` > # find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | grep Type > ``` > shows that all the kernel modules' types are `REL (Relocatable file)`. > > I guess if some module such as if_bridge is linked to DYN type, then I can do runtime for the changes to `sys/kern/link_elf.c`. > > I'm not familiar with elf and linkers, is that ( compile module and link it to DYN type ) possible ? > Hi, I don't have an answer for you either, but I have seen in the past, loading kernel modules behaves a bit like libraries, in the following regard: If two kernel modules define the same global symbol, then no warning is given and the first loaded symbol definition (I think) is used to resolve that symbol for all kernel modules, regardless of the prototype. Probably we should not allow this. That's why building LINT is a good thing, to avoid this issue. Even if we don't have C++ support in the FreeBSD kernel, defining symbol names the way C++ does for C could be nice for the kernel too, also with regards to debugging systems. Many times when I don't know what is going on, I do like this: #include .... if (not too fast or my sysctl debug) { printf("My tracer\n"); kdb_backtrace(); } Dtrace can also do this, but not during boot. Just track who is calling those functions, and you'll probably find the answer to your question! --HPS > > Best regards, > Zhenlei > From nobody Wed Apr 26 11:12:40 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5x6n6DNPz47qbv for ; Wed, 26 Apr 2023 11:12:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5x6m50M7z3nJy; Wed, 26 Apr 2023 11:12:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 33QBCeur017043 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 26 Apr 2023 14:12:43 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 33QBCeur017043 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 33QBCe9Q017042; Wed, 26 Apr 2023 14:12:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Apr 2023 14:12:40 +0300 From: Konstantin Belousov To: Hans Petter Selasky Cc: Zhenlei Huang , FreeBSD CURRENT , Gleb Smirnoff Subject: Re: Link modules to DYN type Message-ID: References: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4Q5x6m50M7z3nJy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 26, 2023 at 12:55:02PM +0200, Hans Petter Selasky wrote: > On 4/26/23 12:36, Zhenlei Huang wrote: > > Hi, > > > > I'm recently working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable vnet sysctl variables be loader tunable), > > the changes to `sys/kern/link_elf_obj.c` are runtime tested, but not those to `sys/kern/link_elf.c` . > > > > After some hacking I realized that `link_elf.c` is for EXEC (Executable file) or DYN (Shared object file), and `link_elf_obj.c` is > > for REL (Relocatable file). > > > > ``` > > /* link_elf.c */ > > static int > > link_elf_load_file(linker_class_t cls, const char* filename, > > linker_file_t* result) > > { > > ... > > if (hdr->e_type != ET_EXEC && hdr->e_type != ET_DYN) { > > error = ENOSYS; > > goto out; > > } > > ... > > } > > > > > > /* link_elf_obj.c */ > > static int > > link_elf_load_file(linker_class_t cls, const char *filename, > > linker_file_t *result) > > { > > ... > > if (hdr->e_type != ET_REL) { > > error = ENOSYS; > > goto out; > > } > > ... > > } > > ``` > > > > Run the following snip: > > ``` > > # find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | grep Type > > ``` > > shows that all the kernel modules' types are `REL (Relocatable file)`. > > > > I guess if some module such as if_bridge is linked to DYN type, then I can do runtime for the changes to `sys/kern/link_elf.c`. > > > > I'm not familiar with elf and linkers, is that ( compile module and link it to DYN type ) possible ? Module file type (shared object vs. object file) depends on architecture. For amd64 modules are objects, while kernel is shared library. For arm64 (and all other arches, I believe) modules and kernels are shared libraries. I think you can link amd64 module as shared object, but this require enough hacking of the build infrastructure. At least I am not aware of a simple knob to switch the produced type. > > > > Hi, > > I don't have an answer for you either, but I have seen in the past, loading > kernel modules behaves a bit like libraries, in the following regard: > > If two kernel modules define the same global symbol, then no warning is > given and the first loaded symbol definition (I think) is used to resolve > that symbol for all kernel modules, regardless of the prototype. Probably we > should not allow this. That's why building LINT is a good thing, to avoid > this issue. No, in-kernel linker does not behave this way. Modules need to contain explicit reference to all modules they depend upon, using the MODULE_DEPEND() macro. Only symbols from the dependencies are resolved. All modules get an implicit reference to kernel. > > Even if we don't have C++ support in the FreeBSD kernel, defining symbol > names the way C++ does for C could be nice for the kernel too, also with > regards to debugging systems. > > Many times when I don't know what is going on, I do like this: > > #include > > .... > > if (not too fast or my sysctl debug) { > printf("My tracer\n"); > kdb_backtrace(); > } > > Dtrace can also do this, but not during boot. Just track who is calling > those functions, and you'll probably find the answer to your question! > > --HPS > > > > > Best regards, > > Zhenlei > > > From nobody Wed Apr 26 11:38:32 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5xhW0YT0z47sZM for ; Wed, 26 Apr 2023 11:38:35 +0000 (UTC) (envelope-from hselasky@freebsd.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) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5xhV49dRz3sNJ; Wed, 26 Apr 2023 11:38:34 +0000 (UTC) (envelope-from hselasky@freebsd.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.36.2.154] (unknown [46.212.121.255]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5341426167D; Wed, 26 Apr 2023 13:38:33 +0200 (CEST) Message-ID: Date: Wed, 26 Apr 2023 13:38:32 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: Link modules to DYN type Content-Language: en-US To: Konstantin Belousov Cc: Zhenlei Huang , FreeBSD CURRENT , Gleb Smirnoff References: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Q5xhV49dRz3sNJ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/26/23 13:12, Konstantin Belousov wrote: > No, in-kernel linker does not behave this way. > Modules need to contain explicit reference to all modules they depend upon, > using the MODULE_DEPEND() macro. Only symbols from the dependencies are > resolved. > > All modules get an implicit reference to kernel. Hi Konstantin, Maybe I wasn't so clear. Trying again: > diff --git a/sys/tests/ktest.c b/sys/tests/ktest.c > index 495fedf95dde..eb42cf062487 100644 > --- a/sys/tests/ktest.c > +++ b/sys/tests/ktest.c > @@ -409,6 +409,12 @@ static moduledata_t ktestmod = { > 0 > }; > > +int > +printf(const char *fmt, ...) > +{ > + return (0); > +} > + > DECLARE_MODULE(ktestmod, ktestmod, SI_SUB_PSEUDO, SI_ORDER_ANY); > MODULE_VERSION(ktestmod, 1); > MODULE_DEPEND(ktestmod, netlink, 1, 1, 1); Then kldload ktest.ko . Which printf() function will be used if ktest.c calls printf() ? I would expect a warning from the kernel at least ... --HPS From nobody Wed Apr 26 12:03:19 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5yF71BLcz47tqY for ; Wed, 26 Apr 2023 12:03:23 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5yF66lfBz3wXy for ; Wed, 26 Apr 2023 12:03:22 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=wnv5IP02; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="Q/jBib/y"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.25 as permitted sender) smtp.mailfrom=yuri@aetern.org Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C64B85C0051 for ; Wed, 26 Apr 2023 08:03:22 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 26 Apr 2023 08:03:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to; s=fm3; t=1682510602; x=1682597002; bh=b2 dLkQ0o0Q5SwbowSa/ChyAZBjVhn+QKyYxU994H7UM=; b=wnv5IP02ociiqUN1im GfkKHTLEa0jr76hYxtSFA2Y3XPFKdBfAUoC0ByGt7ybk7c1MuSADO/i5fCY3gk6F vKaN+41JucCraFAxe+7xC+tjuWh/U5+avxJ0U2If1gZtx1UcVa4eC+ofwBiQOFiP riSf04o693r12RvZZbKK1z5qMzLNcPq6120ZBmTINWMY+lJZGXk//hXeCX2KaubT FoxuX2607eISLKu3UGV9kG88LtJwiAi15yktVHLq3B/UM7UXzdOlkO8kQWV828tF sqAQi3m9KA9zU1ib4p5FGDu/+nuOVTYG3pLTU1qNcXyhBb5EQiHwjIi/iMy+3XO8 MCAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1682510602; x=1682597002; bh=b2dLkQ0o0Q5Sw bowSa/ChyAZBjVhn+QKyYxU994H7UM=; b=Q/jBib/y7xL7ncNrGnPUfHTs/oaGe nANasnXoEObaKQRsGl8pEmFhkasNmNYa+0gj7V0nkwAKhTfMD+aDxNNioJihIfq4 vnFHpgAt6rQR6cjBPNBdBAHdwKbgTh2RblmpSc1ZsgfVlgTJ2VbiAO2ZCqvesRuE bFMWHvV4H+4oXBy/3axHlb5Yes3A1lPh0rvu1xcm8zFDZZowIguF/FTJPgnAkDcf 56PTn/s7b+2k3abcjsFaON35FLtUyx8KVsWQYF173vCeT/Ax5PFFbMF5xWxSV/S+ hH9akd0wBI6KxzJxVUqjS7l6DekwSjIjQk1A1acWvno8FX/uPQp77SueQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedugedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfvhffutgfgsehtkeertd dtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeenucgg tffrrghtthgvrhhnpeejiedvueelgeefffeuteefieekkeeggfffgfelfeduffeufeehfe fftdegueevjeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvghrnhdroh hrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 26 Apr 2023 08:03:21 -0400 (EDT) Message-ID: Date: Wed, 26 Apr 2023 14:03:19 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: current@freebsd.org From: Yuri Subject: github CI failures related to tzsetup Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Q5yF66lfBz3wXy X-Spamd-Bar: / X-Spamd-Result: default: False [-0.40 / 15.00]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; local_wl_from(0.00)[yuri@aetern.org]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-ThisMailContainsUnwantedMimeParts: N Looking at the CI jobs on github, all seem to fail in tzsetup while making kernel-toolchain target. Obviously this build for me locally, FreeBSD's CI is fine with it, it's only ubuntu and macos jobs reporting the errors, and I don't see why; any hints? https://github.com/freebsd/freebsd-src/actions/runs/4808074516/jobs/8557602371#step:7:878 ===> usr.sbin/tzsetup (obj,all,install) /home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c: In function ‘dump_zonetab’: /home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c:809:12: error: ‘countries’ undeclared (first use in this function); did you mean ‘country’? 809 | for (cp = countries; cp->name != NULL; cp++) { | ^~~~~~~~~ | country From nobody Wed Apr 26 12:14:12 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5yTf6zQDz47vNh for ; Wed, 26 Apr 2023 12:14:14 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5yTf4Hcsz3yyv for ; Wed, 26 Apr 2023 12:14:14 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=h64DiRHX; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="V D3ahyd"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.25 as permitted sender) smtp.mailfrom=yuri@aetern.org; dmarc=none Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 54B3D5C00EF for ; Wed, 26 Apr 2023 08:14:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 26 Apr 2023 08:14:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1682511254; x=1682597654; bh=0nNrKf73iRXZ7ahe4VRsgwBwGh4kXahyr3p uonh87eg=; b=h64DiRHX19DXkiqrNFblRUrED19bF+Mo8kowLFcnsOQAMQE43Ul yyQp7o5wmMV3PGSvRDGvchkcfh60ibguODjVierqcMiDTKBqofy74Q3FU4ffWCbI NH069R7Lyiy3GVspgxGtMQyWwEaCehhpqfHmXh/2GaYwqzWa9tlW5m/0Ij5ZPQ7r 9+7qPWUJJNZYSF4krTO5t4ZIxf4XHuh1iiJRT8KFvK0TjxSwfKcOB42EoEbUvKPX 14pq1JRgX8R/u+wWMIbR32r6lnB4QH82o+KcLsUCb0JkSTzPjsWc7KfNoCy6jXjr DoI4WCvLihzmhI+EQ2+z9rzQ+u/KD0OGA7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1682511254; x= 1682597654; bh=0nNrKf73iRXZ7ahe4VRsgwBwGh4kXahyr3puonh87eg=; b=V D3ahydZafwBXdXSAWnonI9WkediGNeGWiSaIw/BbkViMTS92jkH4nQ6m40CK/0aJ NNijKhJA6DKuu+tn5jbCVPysDGJ3tlx/KnPMHFrLsuN+Ik8Fjp9FlaUAuemrKyXk qRfqgptWIrz/EmHBXcVaUEWPZz/VLKsE3jhS39dcyuySQPM7oKZuIO8DB3tCksE6 HXFwZe8ur+n62VvjLphyaW00JyzDgJnqTNRpFkqFwXLYnyzKo/n1S6xD5R6OAfgD 4g3FQ1+AxkIO7fRogaQyC1xzfbCvH0fL3yyq5AvUzlfa7MW+G7I7zcgITRVGlups z4OB8ZOPx2IBhS/GRt6RQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedugedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuhffvfhgjtgfgsehtke ertddtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeen ucggtffrrghtthgvrhhnpeekheduudeujeevtdethfekteevtdeugeelhedtvdduudekvd ejgeehgedthedvfeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhephihurhhisegrvghtvghrnh drohhrgh X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 26 Apr 2023 08:14:13 -0400 (EDT) Message-ID: <3066e5a8-f52f-ff78-7b60-1c0d916babe6@aetern.org> Date: Wed, 26 Apr 2023 14:14:12 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: github CI failures related to tzsetup Content-Language: en-US From: Yuri To: current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Q5yTf4Hcsz3yyv X-Spamd-Bar: - X-Spamd-Result: default: False [-1.60 / 15.00]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm3]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.25:c]; RWL_MAILSPIKE_GOOD(-0.10)[66.111.4.25:from]; RCVD_IN_DNSWL_LOW(-0.10)[66.111.4.25:from]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; local_wl_from(0.00)[yuri@aetern.org]; DMARC_NA(0.00)[aetern.org] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-ThisMailContainsUnwantedMimeParts: N Yuri wrote: > Looking at the CI jobs on github, all seem to fail in tzsetup while > making kernel-toolchain target. Obviously this build for me locally, > FreeBSD's CI is fine with it, it's only ubuntu and macos jobs reporting > the errors, and I don't see why; any hints? > > https://github.com/freebsd/freebsd-src/actions/runs/4808074516/jobs/8557602371#step:7:878 > > ===> usr.sbin/tzsetup (obj,all,install) > /home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c: In > function ‘dump_zonetab’: > /home/runner/work/freebsd-src/freebsd-src/usr.sbin/tzsetup/tzsetup.c:809:12: > error: ‘countries’ undeclared (first use in this function); did you mean > ‘country’? > 809 | for (cp = countries; cp->name != NULL; cp++) { > | ^~~~~~~~~ > | country > Got it, the definition is hidden under the ifdef BSDDIALOG, will fix. From nobody Wed Apr 26 12:15:09 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5yVt4hznz47vMf for ; Wed, 26 Apr 2023 12:15:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5yVs6bDnz414K; Wed, 26 Apr 2023 12:15:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 33QCFANk032806 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 26 Apr 2023 15:15:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 33QCFANk032806 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 33QCF9l5032787; Wed, 26 Apr 2023 15:15:09 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 26 Apr 2023 15:15:09 +0300 From: Konstantin Belousov To: Hans Petter Selasky Cc: Zhenlei Huang , FreeBSD CURRENT , Gleb Smirnoff Subject: Re: Link modules to DYN type Message-ID: References: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Rspamd-Queue-Id: 4Q5yVs6bDnz414K X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 26, 2023 at 01:38:32PM +0200, Hans Petter Selasky wrote: > On 4/26/23 13:12, Konstantin Belousov wrote: > > No, in-kernel linker does not behave this way. > > Modules need to contain explicit reference to all modules they depend upon, > > using the MODULE_DEPEND() macro. Only symbols from the dependencies are > > resolved. > > > > All modules get an implicit reference to kernel. > > Hi Konstantin, > > Maybe I wasn't so clear. Trying again: > > > diff --git a/sys/tests/ktest.c b/sys/tests/ktest.c > > index 495fedf95dde..eb42cf062487 100644 > > --- a/sys/tests/ktest.c > > +++ b/sys/tests/ktest.c > > @@ -409,6 +409,12 @@ static moduledata_t ktestmod = { > > 0 > > }; > > +int > > +printf(const char *fmt, ...) > > +{ > > + return (0); > > +} > > + > > DECLARE_MODULE(ktestmod, ktestmod, SI_SUB_PSEUDO, SI_ORDER_ANY); > > MODULE_VERSION(ktestmod, 1); > > MODULE_DEPEND(ktestmod, netlink, 1, 1, 1); > > Then kldload ktest.ko . Which printf() function will be used if ktest.c > calls printf() ? My best guess is that printf is resolved locally by the static linker, even before the module is loaded. In other words, it would be ktest.c printf. > > I would expect a warning from the kernel at least ... This is not how ELF behaves, even in such not fully compliant env as kernel. From nobody Wed Apr 26 12:19:18 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q5yc05h4dz47vZv for ; Wed, 26 Apr 2023 12:19:44 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 4Q5ybz6NbMz42Hs for ; Wed, 26 Apr 2023 12:19:43 +0000 (UTC) (envelope-from janm@transactionware.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 25638 invoked by uid 907); 26 Apr 2023 12:19:35 -0000 Received: from i5E86410A.versanet.de (HELO smtpclient.apple) (94.134.65.10) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-GCM-SHA384 encrypted) ESMTPSA; Wed, 26 Apr 2023 22:19:35 +1000 From: Jan Martin Mikkelsen Message-Id: <72A678C8-4293-4D50-BCCC-AFE92DB1DA76@transactionware.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E0EC44FA-60CE-4567-819A-9C1C99260C8E" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\)) Subject: Re: Link modules to DYN type Date: Wed, 26 Apr 2023 14:19:18 +0200 In-Reply-To: Cc: Konstantin Belousov , Zhenlei Huang , FreeBSD CURRENT , Gleb Smirnoff To: Hans Petter Selasky References: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> X-Mailer: Apple Mail (2.3731.500.231) X-Rspamd-Queue-Id: 4Q5ybz6NbMz42Hs X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:17559, ipnet:203.14.245.0/24, country:AU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_E0EC44FA-60CE-4567-819A-9C1C99260C8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26. Apr 2023, at 13:38, Hans Petter Selasky = wrote: >=20 > On 4/26/23 13:12, Konstantin Belousov wrote: >> No, in-kernel linker does not behave this way. >> Modules need to contain explicit reference to all modules they depend = upon, >> using the MODULE_DEPEND() macro. Only symbols from the dependencies = are >> resolved. >> All modules get an implicit reference to kernel. >=20 > Hi Konstantin, >=20 > Maybe I wasn't so clear. Trying again: >=20 >> diff --git a/sys/tests/ktest.c b/sys/tests/ktest.c >> index 495fedf95dde..eb42cf062487 100644 >> --- a/sys/tests/ktest.c >> +++ b/sys/tests/ktest.c >> @@ -409,6 +409,12 @@ static moduledata_t ktestmod =3D { >> 0 >> }; >> +int >> +printf(const char *fmt, ...) >> +{ >> + return (0); >> +} >> + >> DECLARE_MODULE(ktestmod, ktestmod, SI_SUB_PSEUDO, SI_ORDER_ANY); >> MODULE_VERSION(ktestmod, 1); >> MODULE_DEPEND(ktestmod, netlink, 1, 1, 1); >=20 > Then kldload ktest.ko . Which printf() function will be used if = ktest.c calls printf() ? >=20 > I would expect a warning from the kernel at least =E2=80=A6 Hi, This looks similar to this: https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082751.html https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082760.html The =E2=80=9Cnot knowing=E2=80=9D about how symbols are going to be = resolved has bothered me for a while. Regards, Jan M. --Apple-Mail=_E0EC44FA-60CE-4567-819A-9C1C99260C8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 26. = Apr 2023, at 13:38, Hans Petter Selasky <hselasky@freebsd.org> = wrote:

On 4/26/23 = 13:12, Konstantin Belousov wrote:
No, = in-kernel linker does not behave this way.
Modules need to contain = explicit reference to all modules they depend upon,
using the = MODULE_DEPEND() macro.  Only symbols from the dependencies = are
resolved.
All modules get an implicit reference to = kernel.

Hi Konstantin,

Maybe I wasn't so = clear. Trying again:

diff --git = a/sys/tests/ktest.c b/sys/tests/ktest.c
index = 495fedf95dde..eb42cf062487 100644
--- a/sys/tests/ktest.c
+++ = b/sys/tests/ktest.c
@@ -409,6 +409,12 @@ static moduledata_t ktestmod = =3D {
        0
};
= +int
+printf(const char *fmt, ...)
+{
+ =       return (0);
+}
+
= DECLARE_MODULE(ktestmod, ktestmod, SI_SUB_PSEUDO, SI_ORDER_ANY);
= MODULE_VERSION(ktestmod, 1);
MODULE_DEPEND(ktestmod, netlink, 1, 1, = 1);

Then kldload ktest.ko . Which printf() function = will be used if ktest.c calls printf() ?

I would expect a warning = from the kernel at least = =E2=80=A6

Hi,

<= div>This looks similar to this:



The =E2=80=9Cnot knowing=E2=80=9D = about how symbols are going to be resolved has bothered me for a = while.

Regards,

Jan = M.

= --Apple-Mail=_E0EC44FA-60CE-4567-819A-9C1C99260C8E-- From nobody Wed Apr 26 14:00:09 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q60qy5hHtz46YHG for ; Wed, 26 Apr 2023 14:00:14 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Received: from heemeyer.club (heemeyer.club [195.93.173.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q60qx424Hz4K7Q for ; Wed, 26 Apr 2023 14:00:13 +0000 (UTC) (envelope-from dchagin@heemeyer.club) Authentication-Results: mx1.freebsd.org; none Received: from heemeyer.club (localhost [127.0.0.1]) by heemeyer.club (8.17.1/8.16.1) with ESMTP id 33QE09uD003905; Wed, 26 Apr 2023 17:00:09 +0300 (MSK) (envelope-from dchagin@heemeyer.club) Received: (from dchagin@localhost) by heemeyer.club (8.17.1/8.16.1/Submit) id 33QE09kG003904; Wed, 26 Apr 2023 17:00:09 +0300 (MSK) (envelope-from dchagin) Date: Wed, 26 Apr 2023 17:00:09 +0300 From: Dmitry Chagin To: Jakob Alvermark Cc: freebsd-current Subject: Re: change in compat/linux breaking net/citrix_ica Message-ID: References: <12cb8ced-8f80-1682-594a-63b402013768@alvermark.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12cb8ced-8f80-1682-594a-63b402013768@alvermark.net> X-Rspamd-Queue-Id: 4Q60qx424Hz4K7Q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:61400, ipnet:195.93.173.0/24, country:RU] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, Apr 26, 2023 at 09:01:00AM +0200, Jakob Alvermark wrote: > Hi, > > > I use net/citrix_ica for work. https://cgit.FreeBSD.org/src/commit/?id=76f8584e49cf7eedaa2e1312593bf46c7225d79a > > After a recent change to -current in compat/linux it no longer works. > The binary just segfaults. > > I have bisected and it happened after this commit: > > commit 40c36c4674eb9602709cf9d0483a4f34ad9753f6 > Author: Dmitry Chagin > Date:   Sat Apr 22 22:17:17 2023 +0300 > >     linux(4): Export the AT_RANDOM depending on the process osreldata > >     AT_RANDOM has appeared in the 2.6.30 Linux kernel first time. > >     Reviewed by:            emaste >     Differential Revision:  https://reviews.freebsd.org/D39646 >     MFC after:              1 month > >  sys/compat/linux/linux_elf.c | 3 ++- >  sys/compat/linux/linux_mib.h | 1 + >  2 files changed, 3 insertions(+), 1 deletion(-) > > > If I revert the change, citrix_ica works again. > > > Thanks, > > Jakob Alvermark > From nobody Wed Apr 26 18:33:03 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q66tp1hQ5z4776R for ; Wed, 26 Apr 2023 18:33:06 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 4Q66tn6lT2z43VC; Wed, 26 Apr 2023 18:33:05 +0000 (UTC) (envelope-from jakob@alvermark.net) Authentication-Results: mx1.freebsd.org; none Received: from c-bc4d235c.06-431-73746f70.bbcust.telenor.se ([92.35.77.188] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1prjwt-0003fn-Pm; Wed, 26 Apr 2023 20:33:03 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alvermark.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=T/feHl5/s0Rbsjg1NMjPnG3sMjvxCXP1/TjeBNxok8s=; b=dz6zWFTamE9mRiqxk7JZaEW03h sIC5pBPTEYKHPFGoOgrLZRCFgO2SfHJvH6gXbdTfj46SxSQxrTiPu+UWSSrAlKpZdh6NRFlJBu9aU UK9cDnux0DQgPswzh6QJLixLgRRvV9Uk9LQhaVUFzXFNQiO0Netvnz7eBVz8tr5H8x8u/6uaKcdFK 1FWNXM/XIT8H4zAf9acgM5UYGLyGjBhP5zPbCgf4qnzIlV41WSiu0vaCrFgVfCzM8NZ5t0oGyk80e qrRgYyQ6SnCpSp0HIO1rziGTc4Cjc5krGwZ8gJF8MeCH+aBXYqx2CudU+45WL2TfEaOIPUXWKRKjy F5knYZDA==; Received: from [192.168.67.27] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91 (FreeBSD)) (envelope-from ) id 1prjwt-0009jz-9d; Wed, 26 Apr 2023 20:33:03 +0200 Message-ID: <06e48531-aa6b-2d78-ac0b-474e4106de9a@alvermark.net> Date: Wed, 26 Apr 2023 20:33:03 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: change in compat/linux breaking net/citrix_ica To: Dmitry Chagin Cc: freebsd-current References: <12cb8ced-8f80-1682-594a-63b402013768@alvermark.net> Content-Language: en-US From: Jakob Alvermark In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4Q66tn6lT2z43VC X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34971, ipnet:185.34.136.0/24, country:IT] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 4/26/23 16:00, Dmitry Chagin wrote: > On Wed, Apr 26, 2023 at 09:01:00AM +0200, Jakob Alvermark wrote: >> Hi, >> >> >> I use net/citrix_ica for work. > https://cgit.FreeBSD.org/src/commit/?id=76f8584e49cf7eedaa2e1312593bf46c7225d79a Yes, this works. Thanks for the quick response! >> After a recent change to -current in compat/linux it no longer works. >> The binary just segfaults. >> >> I have bisected and it happened after this commit: >> >> commit 40c36c4674eb9602709cf9d0483a4f34ad9753f6 >> Author: Dmitry Chagin >> Date:   Sat Apr 22 22:17:17 2023 +0300 >> >>     linux(4): Export the AT_RANDOM depending on the process osreldata >> >>     AT_RANDOM has appeared in the 2.6.30 Linux kernel first time. >> >>     Reviewed by:            emaste >>     Differential Revision:  https://reviews.freebsd.org/D39646 >>     MFC after:              1 month >> >>  sys/compat/linux/linux_elf.c | 3 ++- >>  sys/compat/linux/linux_mib.h | 1 + >>  2 files changed, 3 insertions(+), 1 deletion(-) >> >> >> If I revert the change, citrix_ica works again. >> >> >> Thanks, >> >> Jakob Alvermark >> From nobody Thu Apr 27 10:22:10 2023 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q6Wy06hnmz46xVY for ; Thu, 27 Apr 2023 10:22:16 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6Wy01f4Rz3LBT for ; Thu, 27 Apr 2023 10:22:16 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm3 header.b=J9GYjKUY; dkim=pass header.d=messagingengine.com header.s=fm3 header.b="Q mecxLC"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 64.147.123.20 as permitted sender) smtp.mailfrom=yuri@aetern.org Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 8EEFA32006F5 for ; Thu, 27 Apr 2023 06:22:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 27 Apr 2023 06:22:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1682590933; x=1682677333; bh=MjJNRDfg2ov2Jn1FnKXzYxy7ThCzHrlaCdZ bvSyqWMY=; b=J9GYjKUYVQy6iwbYWNMVAxTjasPG5gvOl6KVfw8r+XBUiWP+yDf JtUs+iEck0g+MibfRwxaeGONhDPgBL5aN7ny2OIWulA6BQkBpWRl+NRU0dmkO3Hd uJ3SFif/9UbrQk6dkH0lik5/D1GBSAOc3y4COtidUM8xWwD8Wq9FpG2Ue+o11C0q +Zy/eInteoVp5Tdwr+lmKGh0pOrCpooWHrhowLqI+Uo///M4QvtIzgRyENj11JCN QJRjyp7IqhN0cbSo7NHUOEkc31A6r4JTocjHKv4VnxATDM2i8PRPnQUOKwk8hCrS vAj7SICeVT5DhaSfLPka59uOlyQyynjlDlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1682590933; x= 1682677333; bh=MjJNRDfg2ov2Jn1FnKXzYxy7ThCzHrlaCdZbvSyqWMY=; b=Q mecxLCh9H9VQZXVBpJgO4BO/E50fx3DaXM6t+qWdmAIfk4a5W5ze+/X1tHHqi1aQ kNb7+LWAoRodFDDCyoW/GGXvB5zIGj0gAQySQrytDs09oh6Fyji0G98NYhq6MPju JogXouTC/i/j3QvCBvElROGNun9AL8LGB/QusD8aip615tlLqGaldC0FQ81A1OJ/ AyFgHWXSF7YG4B0GGmCNVLx5wkOCPCtnZzsKRX0+JhgkqOST7c3oxmm+BxPNMV3H T3nLjt2tKip/L4UmbFl3NIs8tO46PEpM3W6SkiW5HYoK9/BFCU0Ezw9dZMw28TbJ jD6p2dHQcDTkfRfZEp/NQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeduiedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuhffvfhgjtgfgsehtje ertddtfeejnecuhfhrohhmpegjuhhrihcuoeihuhhrihesrggvthgvrhhnrdhorhhgqeen ucggtffrrghtthgvrhhnpedujeeufeduhfeffeefkedtudehffeggeejheevjeelfffhke efhffhieetiefhteenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpeihuhhrihesrggvthgvrh hnrdhorhhg X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Thu, 27 Apr 2023 06:22:12 -0400 (EDT) Message-ID: <7d47a1a9-069d-5817-6648-48dc542227f9@aetern.org> Date: Thu, 27 Apr 2023 12:22:10 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: adopting zone1970.tab changes in tzsetup Content-Language: en-US From: Yuri To: current@freebsd.org References: <4d4af609-e835-a702-0e7d-1d44fd0b686f@aetern.org> In-Reply-To: <4d4af609-e835-a702-0e7d-1d44fd0b686f@aetern.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4Q6Wy01f4Rz3LBT X-Spamd-Bar: / X-Spamd-Result: default: False [-0.40 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.20]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm3,messagingengine.com:s=fm3]; ASN(0.00)[asn:29838, ipnet:64.147.123.0/24, country:US]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; local_wl_from(0.00)[yuri@aetern.org] X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-ThisMailContainsUnwantedMimeParts: N Yuri wrote: > Hi, > > After tzsetup was switched to use zone1970.tab in 513419f4047 it mostly > works, but there are some content changes compared to zone.tab that was > used previously which need to be taken care of (would like to do so > before 14.0). If you have spare time, please take a look at the reviews > below. > > https://reviews.freebsd.org/D39634 - add baseline to tzsetup to check > that zone1970.tab changes don't break the assumptions of file format we > make in tzsetup (and tzsetup changes itself don't have unintended effects) This one is integrated. > https://reviews.freebsd.org/D39606 - adopt zone1970.tab changes > - assumption that single-zone countries do not have description is no > longer correct; do not try to optimize this case as it's only going to > make the code more confusing and we now have menus with a single zone > selection because of this > - remove the single-country continent short cut, it also only serves to > confuse users as we now have such a continent > - instead add a single-zone contry short cut (see above), now all > single-zone countries fall here > - use the @# continent overrides that zone1970.tab introduces (this is > visible at least fixing Iceland being currently listed under Africa) > - add Arctic Ocean "continent" coming only from the overrides at the > moment > - update baseline with the changes And this one is waiting for review :) From nobody Thu Apr 27 16:32:12 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Q6h9J1d0Dz47P2t for ; Thu, 27 Apr 2023 16:32:36 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q6h9H6g69z3QfW; Thu, 27 Apr 2023 16:32:35 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682613155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U9jY42HEYQle5CmpRu9MeEAFk9PjKfpJgDGXL3EF9jg=; b=D9ojLU1V7HkvtEEgGDPsdFeBq3DRwg36KvN5BF80rQosQYuUHb94TkNycE+COPLH/qUX7P 055MFqTZlUzhF+yDS/3MXfkvYtHfyxez4IUzFwwinyHaS1eaQXD/gFeTnU9vNTH52aJwZp LXqLiEap1hp8na71VN+SmF8rJ2uExaxkuW57UbQkDeh2Womtx92by3/vrakUHTcgBP+iO5 4dt6lKNiqqXTHxjTQKipMNLOj3LMFcLF8wM2dIOtiqL7Wnr0q/QAJfXdMPIgYq7OXoil5J Yseqr6vkHDjJ0Z5Uk7nxvLPtKOVB+WoMWAhZJDLHGDKHbl3LFQPIJjxUEVBMGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682613155; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=U9jY42HEYQle5CmpRu9MeEAFk9PjKfpJgDGXL3EF9jg=; b=azLTVPZJQYaqOPMd8quRXto6coDrCvdNTX9jcizqRE0cjZphKMT6jfGAeDzJIjmu7tnkwc RC2Cwg9FeakBv/hCN8MImM6DZYMhe8krGnfPl+k4rSorDy8OmZjOA+uGf9rXWrDVV1eCsU dJE6/I177iGyiRFoN7eWccqSd/2O/aZ/e34mJcvd7dVnxky3rAqb/B6t+YlzhqFXyhlLwr YM9vWgiNx1U5HexPX5Juzu9PEr9aH3LkqGAQ5SIBEBWnYQqNOcRH06dsJZi5HGUVoa0Qj+ kULhMLJ1JMoRnfTpDqCG0DX32ysTvTbpLmrW3iSXtoR/AYgcyClk5cMIBLgmIw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682613155; a=rsa-sha256; cv=none; b=CV+Q2gOiTTzzJ1p+rs/W/k9GyBq+8lnHIoP0DsbJ8O9uggmJMkDY0Kr+1bYrlMUbzcPjEL lV9Fu4mdCU1/wgmfspKHKSTTcJ1sbONDCUWcvWcgNxdtoGkkNaQ9TuV4XveU9XacFCd2T6 yoYBbaTa6o90LHmi/6cZxBojyZI86kDarAZ4WRi2JbsNgC8fU6z1V475ZnRK18qhuDX5JX HFqL9XKgTeICaS5RwKhyjV+i52TMoNXHg/rgSaJGT7nQKpNNbHwHHN48siEUcGO4xdrrkO CYQjUu336mYK3s5Bo4TfiW1pNyirYOlkw204fY2Mhxia4lFWeTwkCUeEIfiZqA== Received: from smtpclient.apple (unknown [IPv6:2409:8a5e:aa7c:b2d4:f9bf:6c35:340b:f54a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q6h9F392dz18QG; Thu, 27 Apr 2023 16:32:33 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: <86DC0C8E-56E8-49B9-8441-D64C690FA5F0@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_6539C631-52D9-4A0E-99A2-AF236413CF40" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) Subject: Re: Link modules to DYN type Date: Fri, 28 Apr 2023 00:32:12 +0800 In-Reply-To: Cc: Hans Petter Selasky , FreeBSD CURRENT , Gleb Smirnoff To: Konstantin Belousov References: <97390FE1-1DF5-43A1-A3F4-2B945D681437@FreeBSD.org> <2bb66cac-c7f1-e45b-693a-8afbda05cfa6@freebsd.org> X-Mailer: Apple Mail (2.3696.120.41.1.2) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_6539C631-52D9-4A0E-99A2-AF236413CF40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 26, 2023, at 7:12 PM, Konstantin Belousov = wrote: >=20 > On Wed, Apr 26, 2023 at 12:55:02PM +0200, Hans Petter Selasky wrote: >> On 4/26/23 12:36, Zhenlei Huang wrote: >>> Hi, >>>=20 >>> I'm recently working on https://reviews.freebsd.org/D39638 = (sysctl(9): Enable vnet sysctl variables be loader tunable), >>> the changes to `sys/kern/link_elf_obj.c` are runtime tested, but not = those to `sys/kern/link_elf.c` . >>>=20 >>> After some hacking I realized that `link_elf.c` is for EXEC = (Executable file) or DYN (Shared object file), and `link_elf_obj.c` is >>> for REL (Relocatable file). >>>=20 >>> ``` >>> /* link_elf.c */ >>> static int >>> link_elf_load_file(linker_class_t cls, const char* filename, >>> linker_file_t* result) >>> { >>> ... >>> if (hdr->e_type !=3D ET_EXEC && hdr->e_type !=3D ET_DYN) { >>> error =3D ENOSYS; >>> goto out; >>> } >>> ... >>> } >>>=20 >>>=20 >>> /* link_elf_obj.c */ >>> static int >>> link_elf_load_file(linker_class_t cls, const char *filename, >>> linker_file_t *result) >>> { >>> ... >>> if (hdr->e_type !=3D ET_REL) { >>> error =3D ENOSYS; >>> goto out; >>> } >>> ... >>> } >>> ``` >>>=20 >>> Run the following snip: >>> ``` >>> # find /boot/kernel -type f -name "*.ko" -exec readelf -h {} \; | = grep Type >>> ``` >>> shows that all the kernel modules' types are `REL (Relocatable = file)`. >>>=20 >>> I guess if some module such as if_bridge is linked to DYN type, then = I can do runtime for the changes to `sys/kern/link_elf.c`. >>>=20 >>> I'm not familiar with elf and linkers, is that ( compile module and = link it to DYN type ) possible ? >=20 > Module file type (shared object vs. object file) depends on = architecture. > For amd64 modules are objects, while kernel is shared library. > For arm64 (and all other arches, I believe) modules and kernels are = shared > libraries. >=20 > I think you can link amd64 module as shared object, but this require = enough > hacking of the build infrastructure. At least I am not aware of a = simple > knob to switch the produced type. I did some hack on `sys/conf/kmod.mk` and finally produced DYN kernel = modules. The good news is I do some basic sysctl tests, but the bad news is the = module does not function correctly. For exampe the if_disc.c ``` static void vnet_disc_init(const void *unused __unused) { /* Reference V_disc_cloner will immediately trigger page fault = panic */ V_disc_cloner =3D if_clone_simple(discname, disc_clone_create, disc_clone_destroy, 0); } VNET_SYSINIT(vnet_disc_init, SI_SUB_PSEUDO, SI_ORDER_ANY, vnet_disc_init, NULL); ``` I suspect the relocation is not done correctly for DYN elf kmod on = amd64. My local patch to kmod.mk: ``` diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk index 134b150af1d9..1fc5386204a5 100644 --- a/sys/conf/kmod.mk +++ b/sys/conf/kmod.mk @@ -84,6 +84,7 @@ __KLD_SHARED=3Dyes .else __KLD_SHARED=3Dno .endif +__KLD_SHARED=3Dyes =20 .if !empty(CFLAGS:M-O[23s]) && empty(CFLAGS:M-fno-strict-aliasing) CFLAGS+=3D -fno-strict-aliasing @@ -167,6 +168,7 @@ CFLAGS+=3D -fno-omit-frame-pointer = -mno-omit-leaf-frame-pointer ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -fPIC .endif +CFLAGS+=3D -fPIC =20 # Temporary workaround for PR 196407, which contains the fascinating = details. # Don't allow clang to use fpu instructions or registers in kernel = modules. ``` As for https://reviews.freebsd.org/D39638 = , for other platform such as arm, I = think the `link_elf_propagate_vnets()` should work if `parse_vnet()` = works. I'll appreciate if someone can test it on platforms those have DYN type = kernel modules.=20 >=20 >=20 >>>=20 >>=20 >> Hi, >>=20 >> I don't have an answer for you either, but I have seen in the past, = loading >> kernel modules behaves a bit like libraries, in the following regard: >>=20 >> If two kernel modules define the same global symbol, then no warning = is >> given and the first loaded symbol definition (I think) is used to = resolve >> that symbol for all kernel modules, regardless of the prototype. = Probably we >> should not allow this. That's why building LINT is a good thing, to = avoid >> this issue. > No, in-kernel linker does not behave this way. > Modules need to contain explicit reference to all modules they depend = upon, > using the MODULE_DEPEND() macro. Only symbols from the dependencies = are > resolved. >=20 > All modules get an implicit reference to kernel. >=20 >>=20 >> Even if we don't have C++ support in the FreeBSD kernel, defining = symbol >> names the way C++ does for C could be nice for the kernel too, also = with >> regards to debugging systems. >>=20 >> Many times when I don't know what is going on, I do like this: >>=20 >> #include >>=20 >> .... >>=20 >> if (not too fast or my sysctl debug) { >> printf("My tracer\n"); >> kdb_backtrace(); >> } >>=20 >> Dtrace can also do this, but not during boot. Just track who is = calling >> those functions, and you'll probably find the answer to your = question! >>=20 >> --HPS >>=20 >>>=20 >>> Best regards, >>> Zhenlei --Apple-Mail=_6539C631-52D9-4A0E-99A2-AF236413CF40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 26, 2023, at 7:12 PM, Konstantin Belousov <kostikbel@gmail.com>= wrote:

On Wed, Apr 26, 2023 at 12:55:02PM +0200, Hans Petter Selasky = wrote:
On = 4/26/23 12:36, Zhenlei Huang wrote:
Hi,

I'm recently = working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable = vnet sysctl variables be loader tunable),
the changes to = `sys/kern/link_elf_obj.c` are runtime tested, but not those to = `sys/kern/link_elf.c` .

After some hacking = I realized that `link_elf.c` is for EXEC (Executable file) or DYN = (Shared object file), and `link_elf_obj.c` is
for REL = (Relocatable file).

```
/* = link_elf.c */
static int
link_elf_load_file(linker_class_t cls, const char* = filename,
    linker_file_t* = result)
{
...
if = (hdr->e_type !=3D ET_EXEC && hdr->e_type !=3D ET_DYN) {
= = error =3D ENOSYS;
goto out;
}
...
}


/* link_elf_obj.c */
static int
link_elf_load_file(linker_class_t cls, const char = *filename,
    linker_file_t = *result)
{
...
if = (hdr->e_type !=3D ET_REL) {
error =3D = ENOSYS;
goto out;
}
...
}
```

Run the = following snip:
```
# find /boot/kernel = -type f -name "*.ko" -exec readelf -h {} \; | grep Type
```
shows that all the kernel modules' types = are `REL (Relocatable file)`.

I guess if = some module such as if_bridge is linked to DYN type, then I can do = runtime for the changes to `sys/kern/link_elf.c`.

I'm not familiar with elf and linkers, is that ( compile = module and link it to DYN type ) possible ?

Module file type (shared object vs. object file) depends on = architecture.
For amd64 = modules are objects, while kernel is shared library.
For arm64 = (and all other arches, I believe) modules and kernels are = shared
libraries.

I think you can link amd64 module as shared object, but this = require enough
hacking of the build infrastructure.  At least I am not = aware of a simple
knob to switch the produced type.

I did some = hack on `sys/conf/kmod.mk` and finally produced DYN kernel = modules.
The good news is I do some basic sysctl tests, but the bad news is = the module does not function correctly.

For exampe the = if_disc.c

```
static = void
vnet_disc_init(const = void *unused __unused)
{
/* Reference V_disc_cloner will immediately trigger page = fault panic */
= V_disc_cloner =3D if_clone_simple(discname, = disc_clone_create,
  =  disc_clone_destroy, 0);
}
VNET_SYSINIT(vnet_disc_init, SI_SUB_PSEUDO, = SI_ORDER_ANY,
  =   vnet_disc_init, NULL);
```

I suspect the relocation is not done = correctly for  DYN elf kmod on amd64.

My local patch to = kmod.mk:

```
diff = --git a/sys/conf/kmod.mk = b/sys/conf/kmod.mk
index = 134b150af1d9..1fc5386204a5 100644
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -84,6 +84,7 @@ = __KLD_SHARED=3Dyes
 .else
 __KLD_SHARED=3Dno
 .endif
+__KLD_SHARED=3Dyes
 
 .if= !empty(CFLAGS:M-O[23s]) && = empty(CFLAGS:M-fno-strict-aliasing)
 CFLAGS+=3D       = -fno-strict-aliasing
@@ = -167,6 +168,7 @@ CFLAGS+=3D    -fno-omit-frame-pointer = -mno-omit-leaf-frame-pointer
     ${MACHINE_CPUARCH} =3D=3D = "powerpc"
 CFLAGS+=3D   =     -fPIC
 .endif
+CFLAGS+=3D=       -fPIC
 
 # = Temporary workaround for PR 196407, which contains the fascinating = details.
 # Don't allow = clang to use fpu instructions or registers in kernel = modules.
```


As for https://reviews.freebsd.org/D39638, for other platform = such as arm, I think the `link_elf_propagate_vnets()` should work if = `parse_vnet()` works.

I'll = appreciate if someone can test it on platforms those have DYN type = kernel modules. 





Hi,

I don't have an answer for you either, but I = have seen in the past, loading
kernel modules behaves a = bit like libraries, in the following regard:

If two kernel modules define the same global symbol, then no = warning is
given and the first loaded symbol definition (I = think) is used to resolve
that symbol for all kernel = modules, regardless of the prototype. Probably we
should = not allow this. That's why building LINT is a good thing, to avoid
this issue.
No, in-kernel = linker does not behave this way.
Modules need to contain explicit reference to all modules = they depend upon,
using the MODULE_DEPEND() macro.  Only symbols from the = dependencies are
resolved.

All modules get an implicit reference to kernel.


Even if we don't have C++ support in the FreeBSD kernel, = defining symbol
names the way C++ does for C could be nice = for the kernel too, also with
regards to debugging = systems.

Many times when I don't know what = is going on, I do like this:

#include = <sys/kdb.h>

....

if (not too fast or my sysctl debug) {
 printf("My tracer\n");
 kdb_backtrace();
}

Dtrace can also do this, but not during boot. Just track who = is calling
those functions, and you'll probably find the = answer to your question!

--HPS


Best regards,
Zhenlei



= --Apple-Mail=_6539C631-52D9-4A0E-99A2-AF236413CF40--