From nobody Thu May 25 10:57:28 2023 X-Original-To: freebsd-arch@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 4QRlQ325hHz4TLgc for ; Thu, 25 May 2023 10:57:47 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-54.consmr.mail.gq1.yahoo.com (sonic308-54.consmr.mail.gq1.yahoo.com [98.137.68.30]) (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 4QRlQ26dkWz3sX3 for ; Thu, 25 May 2023 10:57:46 +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=1685012265; bh=T+TPnnTQtype5qxN+R05NfVty8+ujDn4eYZtVF8xWRs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=DCt4K1Cl9hj+Az91gdVV5Uiw4ulA66WTk5vDGWwzAN+njw8PymiFziUcE6fwor4FERkVeD6JwZbr9Sa5K0I7eLy+hNF9FopT/kxmpxHgEzAKK66051WxOYJmwgkiJS3W37Qaa39/h6iu1T0eJbONTE+a1i4PrwNu6q3AuAwLmC30cuurD/tpYuFxc2100pz4dMERIBJsogkhAx5sYrioAzo4euiGS9upn6KqBfFIy/aHporc3Z1A4iDuS0kxqmQmgtoYJHq28Hv8a6NqC8Xt01AGR9ljFJL7D8iVM5G7DOH/+zBol4Karu1oRFo5iDZBzLszJ3RiMoWTtFdBjbu/Sw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1685012265; bh=2zheGI1Oewyg+K3KrrYITxi/Lf9tS0xmu4bAuknsLqO=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=OXmzicivUKVWo7bgqlT5isubeL9YOup7Tz0P6L1oc2IKQOd7Z2NvIn6yGn6PuCkVD9j06A9kxDxGO88cSbNhiHgms/YZqEa/165dYPvu3dqOSPCGjhzVvz5VvTtaXseH73UWnTSQ7dQuiiAqx6CClqHn6WUQnB2nrJn1jrBrElYid3/1frP5eIhFCspEVebZvypJJQtvejAQzr4IGMbGo/gi6Ub3bhMHsjJWykdEimqibmpArnFwmRq2vA+pL88evGe2yKglI5obypGzzu1a7G+iVVA/m/Gh8YEhSAVaUd2C1YrtDwkrjGQR614DaHYVBTl0x96H9ILA3q9RrlSKJw== X-YMail-OSG: EJSxiV0VM1n4W9SnHhQivW342YOFCieHK44EHeAKzgl7twybW94VBrd9AYX1FhI nyE_gfScQ7ZMqkHQlq2rW8yzhXAZ3xAxWRSjeRfCZ1aMYnUd2Ti7ukgX3n4spUbk2KvcxtHinS8u HMYg1zxW8N6.M6t6SWfePlrf2t.nkAUNJSOcvgSbMoFzIKj2wb6wOizwJqkOfzVWTUtkYpRfQlYe cLzg7jQYB_kgugjjfL6dn6lebYjU2ReilO6VxiIcyi.TBGJLmLyOxulQzt_a6xWaXzWZ7hanCrJG 88Z5mKknEj0rxFFHOHDFOwRbXCksgLYW48mXtZODBS8ezGA.1eJc0km1Vkjlsr9pB7QIvQkfkKPP YRQbBCPmA94NRF6r045XYuoCIiwvZ90wys8kgU9RbDyt13H_Cl6z38PkWQlA8n1yWU.LtsQBwQHn 3nchY6XO3zYniIMN6rHbHnKg4ty49wPMvMfq5hAWAi0bua.QwE7B_4j6osIWKCbnPrrVfFLX1xsa T9EknHDXdIh9.y9ml8KNnT_jvtY_0O.u3.MTR0OCXM82pbGPL4qEK.kGaKdjEaZ5yfqirjXysHdB fiPq.76oIEygfLmGL9vhFNzZFTh.egAgofhOBkJAHLn3te9ALSViiUfzLztUcZ_v9Tqz7eYI_glz WXkwpbQ7WWu0OEmly7zLOOf59NjtTD2i80b7uunXyyfJIkF.9g1la_Pg5fW53ue0NbcAvT0YOnRR Y_b8yYzIJuZd3TCc6yHR7SUwT6W4pbMvMOlOaqkee0Dax_Xq6Gy7ITB2KC0NTk0t8dfLSoa1FFys ObqJh60Cads5IiqdOhBqNaPVyXcIhlwQeRrRQfSMGwycvZSL4mlx3ydITv8L85DYJ1DQYVrkKiqy b7i2I6BFljY211z.eyyjJyK.6hC1S1e87dpbkWs4kg1UhrQK2NYuZV7z2Lr89_efVXOwNDuKjKNb JCAnychpW75G09Uh8R4uKsXlDHa8zdhP2lxyT7K61xV_VWW.b6Gc_yVfnn7PVGKqtW30NcwCLHc8 5nHN9l7iymXeCDq3_CIs1MHpDpkfMSBYmAUez.kmql3NXRzLhEno1lfK0dU_NLmC2PLNLiVZXRkf rpjJ_mFbZf.pqwiLUT9YA.63JkCEFIgqPUqSuvX47ln7WgvBJhfhGzyRk0j1rLOxh2LrO0.frWms 6NnETr_XPUvBiFgXWXSVge9n79z.gRiKGtzrqAisblAU1SamsCN1X03ORPQUfdVF3mLoFvUgpB2q i.LJ_BRb4beuLmCq5dgZ6c1BEVdbZcZZ2UW84CdVbTOSqnkxUAyG6f_nyUvLBIqeJ5RLth.oOBB0 4whzRSQDsRUv_Pj1GWf1kyXKvUAvBdjfAYRsnXSp4Uba1VobT5PMFM1vXPoSiQ_pLpiCR_yM843r GjilrBfse1C41SbLxW4cI30fDCQgHAWsxrD4mA_b.EaG9gxwR5.2kODlhG_QXp1hP7gknQ_r8dI_ mXc8b.MZcWzLmEKnu14ERm6dr6uDxtfvaV.w_MYUQ4v89IbRLCFfibmGXbuSM4e.MDF2G6dLdxIl GocLJ2qRlbz24wJC838bf5exqUjLxFNsz4trpseBYZSJJPv4Wp2WhiPWLbfti2k6xf3BXp1248IX yfj2TP2YbXrJUQDSaxrwsySk61tYOKfr.RdV9SUY6ze4De3kXz9Hz_xSBETxyeEEN8zXldYImiJ2 RcGriAKPhlOlf_jhSHX_cxDqKwA_Bw5PysXyWh.wTeA_TRsk4O4DEH4aV.Y_TEuhFrnWSXVqf27O _x7JvtRRVuG14uaM5lhWA8JrHldNaWgdxSj8opTd50rEeMcg6kOcbTbuTWhEyfJr6cPLAXE_Pbam oBB68.sRivjfhRnrlVx6BgUW3LR5RUPDhU9DB5VU6uV_yPnFne_4I4KMfWpGTLB3mQlOB88oUqn8 z9_DYz0Pt9IGHsySyMdDhf3oIS59wJhrOV00Jgk2yqqY.MfpfXiRcDzC7VW7fdYxh0orEuujiHJe q0GgOFLqZSkGfyZjgxoxx4P_ZjFAUTkhKk8DAVhZBzeSIl009alMrMg7SYEXtIF_W0s2NR_sMYzA b0bS0c3YGskbluoo713og7bbNURt2SgiKy_gyrArvsFmN19A0MhNBj1uiSwxaY2pDanrxyy5sktk NeZR8lcDdKLRHczsTec5k6hQ7dX3JHm8kgXZQTovQCvf6wqS568z7zx8tgr02M1Y4G.AetyTBVTv Z42UWRywfSBSpPS2FVDd4gwwHhE0YibsgCzvTvusx473Mi3R4Lhi8SMfQYyHWSlp.2OBcdrUNo4F 5 X-Sonic-MF: X-Sonic-ID: 8c23ee93-cbdc-47cd-9fe7-37cd8dae6ba4 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Thu, 25 May 2023 10:57:45 +0000 Received: by hermes--production-bf1-54475bbfff-xzdff (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dacfc5aff3eeca25e3ff256479d15d31; Thu, 25 May 2023 10:57:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD From: Mark Millard In-Reply-To: Date: Thu, 25 May 2023 03:57:28 -0700 Cc: Jessica Clarke , freebsd-arch Content-Transfer-Encoding: quoted-printable Message-Id: <738F6620-E4FA-4960-87D2-61B93921593C@yahoo.com> References: <2EDDC5DC-81C2-4EB8-B729-66F03A8854E4.ref@yahoo.com> <2EDDC5DC-81C2-4EB8-B729-66F03A8854E4@yahoo.com> <6293f06b-927f-432a-3911-808b1d99441b@selasky.org> <9C0CE0A5-150D-4FE1-A838-F1E6A39960F6@yahoo.com> <204FCA67-3FCD-48BA-A373-ABE8AD915D40@yahoo.com> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4QRlQ26dkWz3sX3 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 On May 24, 2023, at 22:34, Hans Petter Selasky wrote: > On 5/25/23 02:00, Mark Millard wrote: >> I took a look at a . . ./sys/modules/mlx4/mlx4_main.o via nm >> and it showed a different convention for creating uniqueness >> for the type of context involved: >> static ssize_t set_port_type(struct device *dev, >> struct device_attribute *attr, >> const char *buf, size_t count) >> { >> . . . >> static DEFINE_MUTEX(set_port_type_mutex); >> . . . >> ended up with the static routine's name prefixed, >> with a "." separator: >> 0000000000006da0 t set_port_type >> 0000000000000018 d = set_port_type.__set_sysinit_set_sym_set_port_type_mutex_sx_sysinit_sys_ini= t >> 0000000000000008 d = set_port_type.__set_sysuninit_set_sym_set_port_type_mutex_sx_sysuninit_sys= _uninit >> 0000000000000020 b set_port_type.set_port_type_mutex >> 00000000000004a8 d set_port_type.set_port_type_mutex_args >> 00000000000004c0 d = set_port_type.set_port_type_mutex_sx_sysinit_sys_init >> 00000000000004d8 d = set_port_type.set_port_type_mutex_sx_sysuninit_sys_uninit >=20 > Hi, >=20 > That makes sense. If the set_port_type function is optimized out, the = sysinit goes away aswell. Like function garbage collection in the = linker. Also I see a sysuninit call there, which is not done in Linux. = Technically, that leaves room, this mutex may be used after it is = destroyed, depending on how the set_port_type function is used. >=20 > For my patchset, the change to move those sysinits structures and the = mutex variable outside the function, is correct. >=20 > Looking at LINT for AMD64, this is so to speak the only place in the = whole of FreeBSD, where a (static) SYSINIT() is placed inside a = function: >=20 > # nm /usr/obj/vol/freebsd-src/amd64.amd64/sys/LINT/kernel | > # grep -F "." | grep __set_sysinit > ffffffff83908638 d = set_port_type.__set_sysinit_set_sym_set_port_type_mutex_sx_sysinit_sys_ini= t >=20 > Even though the commit message for = 805d759338a2be939fffc8bf3f25cfaab981a9be may be interpreted differently, = my good feeling about is was right. We have one place in the kernel = where we do things differently than other places, and that means a bug = due to this variable being declared in a different way, may go = unnoticed, because this is not the most common use-case being tested. The pre-existing code expresses explicitly that no other routine is allowed to have its own use of the mutex, a design choice enforced by the compiler as things are written. (The purpose of the limitation to block scope.) Your proposed change removes the compiler enforcement of that design, allowing use of the mutex by other code in mlx4_main.c without any notification by the compiler. Your proposal has a direction of being more fragile for bad changes without having to be explicit in code updates about the change of status. > Jess, even though I may not always be able to exactly explain things = to others, like you demand, why is this change made, explain or revert, = I see I have a talent to fix things ahead of time, and get problems out = of the way, before the storm hits. A mutex being removed based on = optimization flags passed to the linker and compiler, causing a = synchronization bug, may take a long time to detect, figure out and = resolve. And it might end you never figure out the reason for a bug, and = give up simply. >=20 >=20 > Regarding the sysinits at compile time issue. As long as the sysinits = are all done in the same way, and the committer takes responsibility for = fixing and handling bugs that show up, I don't see any problem about the = added complexity. >=20 >=20 >=20 > A good place to work, is not where the workers are considered = replacable, like when you request my changes to be understood by = yourself, so in case I die, someone else can take over. Every FreeBSD = developer is uniq and important to the project. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com