From owner-freebsd-hackers@freebsd.org Sun Oct 28 00:30:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A283310D9B94 for ; Sun, 28 Oct 2018 00:30:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-21.consmr.mail.ne1.yahoo.com (sonic315-21.consmr.mail.ne1.yahoo.com [66.163.190.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2628183CC7 for ; Sun, 28 Oct 2018 00:30:15 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OEMWsQcVM1lWi4g61I3uZncfQz5SEybKgdEFO7Ow1fwENYX96V4Rgz4FjTx_OFl XS.hbl5RmmqCeRzRTvStUI9wmDspHEyKi.BugIWw.A433S6sHU6tCy.uKX35J6yEylJR9maXwP36 JS0.dgJwXhb6LLGw3L.BLZjU98tKFf7v7k3r56TB8ruQLu8Ez0JpWGdtAIG013KE0GLMWke9KHNO gEqI_nuJ3sPY7wKiuTO2Oh0aLAxM.s8tYLYxXIIQTI6D89e.eOt.oADz9Ri_yqYrcQPaWxq62NQz XqRPhqYO1WkKqMSDoOjGgl8D9b3756CT_4wvyrrHsADTudUbYusIDMV8SHM1JZoU2Og4MzPGCmTO 36U4d8NXJ3BhRfMGYC1fUnnuT6cWlbMTxwRktHik6LfcTXwRv.5yVFCvZrjxBPVL0qPSueDP6yd0 9eQW8QBpWNEzl953bH_oUhUeJpTP50vZDlDNeZu3WtVi2JBMMi9KV646zHZHWuUNO9Py1XZZucWF DKenoWbWjJQOfXOGn83356xXplz88sGkrhbrIseThMQSez.9xOZviSHsmRbDxUNN09nZkiMw6A0N 1JRO5r40dJuR3p.oYq3EEUyEaSBFtxHA8fN_rarGS0RtOIt6zdfwYN6Nd0ZWVtVIMXMLqnoyWHF5 cq_RDLR64lUIxPSDdZcAL9Gssskk1O9NFA1VIB5sonpO4UfF6f3cyqeKABJSk25HrlADDqyrvSVu _zfVw7lEq8rVm1NfGWLgCyG6IGRH_vsdrJLwrsydAWQ65sSScMI.Xe7VvssImPNMjAoalyLqZpoe dQLW1yfK3.at4uYEs0O7c1FhNeLhkZgPK3tuJPJ4gaDZtvvu8c2liMXNqchxijmaHhFBYUEIybAF 4dKqxNVFeljcxv671UU.5itmYXmW4Pzz8OFRTK1G32M7xo6OPsLxCm0UQ7Idf0GVQQxgw4k1O.C7 3i047jw0SoHqrqqTf1Bgg9OGO82C1P7ubtkHzpUsgqYmm.889swSBItiBh2f54IR8lcEK1Drpc1F .VFN3aHAQfhj_.XJvFkB6WrZrDz5O7Ifdvpw3ADMQqhHrHl9MFZ0WCulu51av3OlC8A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Sun, 28 Oct 2018 00:30:08 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp418.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4eb8cde05fb14896ea9e161e83c54e2e; Sun, 28 Oct 2018 00:30:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait) From: Mark Millard In-Reply-To: Date: Sat, 27 Oct 2018 17:30:03 -0700 Cc: FreeBSD Toolchain , freeBSD , FreeBSD Ports ML Content-Transfer-Encoding: quoted-printable Message-Id: <220332B7-0B5E-4378-AD48-FDFB8F135A50@yahoo.com> References: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> To: =?utf-8?Q?Mika=C3=ABl_Urankar?= , Sean Bruno X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 00:30:15 -0000 [Just the __packed removal patch was sufficient to no longer have the hang problem that I originally reported for the print/texinfo build in poudriere.] On 2018-Oct-27, at 4:33 PM, Mark Millard wrote: > [Some of this discussion occurred off list. The point here > is not specific to the hang that I originally reported.] >=20 > On 2018-Oct-27, at 3:03 PM, Mark Millard wrote: >>=20 Mika=C3=ABl Urankar is being quoted below: >>> . . . >>>=20 >>>> There are bugs in qemu that can cause such deadlock, you can try = these >>>> 2 patches: >>>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6= baa45fdbe0dbb56a7371 >>>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d= 499d8e465d4d2026c52b Back to me: >>> I'll try those later. Thanks. (I need to get back to sleep.) >>>=20 >>> It was interesting that attach/detach to the ld process >>> caused it to progress. The rest of the build completed >>> just fine. But that one spot consistently hung up before >>> trying gdb to look at the back trace. >>>=20 >>=20 >> Looking at the qemu code related to the 2nd patch: the >> structure of the field copies (via __get_user) seems >> very sensitive to the ABI rules for the target and >> how things align and such, given that the structure >> description and code are host code. __packed vs. not >> is possibly not sufficient control to always make things >> match right across all the potential combinations of >> host and target from what I can see. >>=20 >> Lack of __packed may prove sufficient for my specific >> context (amd64 host and armv7 target) but it seems >> non-obvious what to do in general. >>=20 >> There would also seem to be big endian vs. little endian >> issues on the individual __get_user styles of copies >> when the host and target do not match for a multi-byte >> numeric encoding. >=20 > Well, I get the following for: >=20 > #include "/usr/include/sys/event.h" // kevent > #include // offsetof > #include // printf >=20 > int > main() > { > printf("%lu\n", (unsigned long) sizeof(struct kevent)); > printf("ident %lu\n", (unsigned long) offsetof(struct kevent, = ident)); > printf("filter %lu\n", (unsigned long) offsetof(struct kevent, = filter)); > printf("flags %lu\n", (unsigned long) offsetof(struct kevent, = flags)); > printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, = fflags)); > printf("data %lu\n", (unsigned long) offsetof(struct kevent, = data)); > printf("udata %lu\n", (unsigned long) offsetof(struct kevent, = udata)); > printf("ext %lu\n", (unsigned long) offsetof(struct kevent, = ext)); > return 0; > } >=20 > (This code avoided warnings for type mismatches with the > printf strings and such.) >=20 > amd64 native [host of qemu use] (comments hand added): >=20 > # ./a.out > 64 > ident 0 > filter 8 // NOTE! > flags 10 // NOTE! > fflags 12 // NOTE! > data 16 > udata 24 > ext 32 >=20 > (The above is not particularly important but I > include it for completeness.) >=20 > armv7 native [target in qemu use] (comments hand added): >=20 > # ./a.out > 64 // NOTE vs. below! > ident 0 > filter 4 // NOTE vs. above! > flags 6 // NOTE vs. above! > fflags 8 // NOTE vs. above! > data 16 // NOTE vs. below! > udata 24 // NOTE vs. below! > ext 32 // NOTE vs. below! >=20 > /usr/include/sys/event.h lacks __packed in both cases. >=20 > With __packed in qemu-arm-static's source code > for target_freebsd_kevent I confirm that via > gdb for the qemu-arm-static: >=20 > p/d sizeof(struct target_freebsd_kevent) > p/d &((struct target_freebsd_kevent *)0)->ident > p/d &((struct target_freebsd_kevent *)0)->filter > p/d &((struct target_freebsd_kevent *)0)->flags > p/d &((struct target_freebsd_kevent *)0)->fflags > p/d &((struct target_freebsd_kevent *)0)->data > p/d &((struct target_freebsd_kevent *)0)->udata > p/d &((struct target_freebsd_kevent *)0)->ext >=20 > reports as the 2nd patch's problem-report > material reports (56,0,4,6,8,12,20,24): not > even the right size. >=20 > I also confirm that removing __packed in qemu's > code and rebuilding and then checking with gdb > reported a match to the above armv7 native report > (64,0,4,6,8,16,24,32). >=20 > I have not verified __packed used vs. not for any > other combination of host and target platforms. Removing the 2 examples of __packed, including the 1 for target_freebsd_kevent, as in Mika=C3=ABl Urankar's 2nd listed patch, was sufficient to avoid the hang that I originally reported. (Technically FreeBSD 11 is not involved and so one of the __packed removals is not relevant to my example.) I have not applied Mika=C3=ABl Urankar's first listed patch at all. It did not prove necessary for my context. Again: the only tested context is amd64 -> armv7 (host -> target) under a head -r339076 based build. (So still 12.) I'm doing a larger amd64 -> armv7 rebuild (around 210 ports overall) that originally included the problematical hang and a full-bootstrap build of lang/gcc8 (so extensive emulation use after the clang-based stages). Prior to the patch, all smaller attempts also hung at the same place for print/texinfo. But I'll only report if this larger test has a problem. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sun Oct 28 01:00:45 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED20610DAA7F for ; Sun, 28 Oct 2018 01:00:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-14.consmr.mail.bf2.yahoo.com (sonic315-14.consmr.mail.bf2.yahoo.com [74.6.134.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F1EC8527C for ; Sun, 28 Oct 2018 01:00:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: eqXV0d0VM1nnbUIn5c.TMF5hI6nfHdHGJv36YbvJeRnW0YjTZDDgYfkXJ8G27kI vrNHPcWsddMYXb.1hNGUpI4jA70.cwqGr6Ds03YOWMHiX._h1QhjCHycfmaPNUD8kkPQ9xGc0iYE BUidC3_YFwymt1BG7u4wikQQ2u83hXyN2tfNmMbLkbbD9UCpX0Kec44UQ0qpjNl93hi7_y0JVkbz xInhJo32qkBcdTIv59l_z_9Rg4ctEQUuZsfmP.nSG_TvysNJPuj9KJeQNw2q24tBMzpIR9ltt3rS mz4uZZrvtSnphZMxoVqes_MedTaj2LEVisif7zwco2xjkM84NzMIP9Pl53AyLo1CIbRMwTGZi_rw wYqqEaKh3Und2p5pVRScKgsvOVKOF7LBgMIGnFEiqoJz2duFfOPfQWl3saO7JW9mqLL0HXzBtC45 SHyvNJrNXtbfFEmnyKSWRyV3ED_u8Yg9fevpMya_njhf8ZQuRvhgq445sdXVt80nuX8Gi3mhe3Vg H95OY.EhyzQLeiduxXM4v3RiDmn2r.nfQ1Z0Y9_uvXo5Cl1o_I13ysgTgrHonkqpPRWa7HKkgyZt .pyf3.Lc7atGa5gK3fOfps87TLInasjxaloDB1o9QapFG3JACwp5INyX2IbZU.zTH5oEOO24Bx.F Get.5Nqn3YHyb4jB21DD.0w8JF_eLAVOi9gYR3KSL76iB9s96cmPVd6iPnomb1n9Lglcukv9v2w1 fWl50PE29e.l7EI02v6S5pxDS34aF6lK97QjzfnnZBsu0reARZVv3bPHw99iUi2DKkj7eIjWS7qo Z9Vz_3Rp7yPJaQKZ1.j8FVn6uZdivr73J5OSwwEuYL.xbYruMubW9UB38ZpPxNWcHew_k.r0Srw6 IbDBEUK6eA9ggOXyoF0yKUg2LS2u2p445XGF3DbljPOMadFifJg9i6puXrEF5MtF9GLD_fmfG8QT v9HzaYL4wP3XgqC9m3Jgepsfy2dTWJoBemtlk5W4pbYWE3BfQvFCALElpjyBNWdNMeLjPSD9hepl 7M5xmW35gDUtn2hB6Nb8bX2cR8mxGzcuq6tGXt.asB3rIM4wj35RzhC9Wj3XhKrsd Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Sun, 28 Oct 2018 01:00:37 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp426.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9624598178b30c9fbdfbfdd2fdeac5c0; Sun, 28 Oct 2018 01:00:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait) From: Mark Millard In-Reply-To: <220332B7-0B5E-4378-AD48-FDFB8F135A50@yahoo.com> Date: Sat, 27 Oct 2018 18:00:34 -0700 Cc: FreeBSD Toolchain , freeBSD , FreeBSD Ports ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> <220332B7-0B5E-4378-AD48-FDFB8F135A50@yahoo.com> To: =?utf-8?Q?Mika=C3=ABl_Urankar?= , Sean Bruno X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 01:00:45 -0000 [The bigger test still hung up.] On 2018-Oct-27, at 5:30 PM, Mark Millard wrote: > [Just the __packed removal patch was sufficient to no longer > have the hang problem that I originally reported for the > print/texinfo build in poudriere.] >=20 > On 2018-Oct-27, at 4:33 PM, Mark Millard wrote: >=20 >> [Some of this discussion occurred off list. The point here >> is not specific to the hang that I originally reported.] >>=20 >> On 2018-Oct-27, at 3:03 PM, Mark Millard = wrote: >>>=20 >=20 > Mika=C3=ABl Urankar is being quoted below: >=20 >>>> . . . >>>>=20 >>>>> There are bugs in qemu that can cause such deadlock, you can try = these >>>>> 2 patches: >>>>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6= baa45fdbe0dbb56a7371 >>>>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d= 499d8e465d4d2026c52b >=20 > Back to me: >=20 >>>> I'll try those later. Thanks. (I need to get back to sleep.) >>>>=20 >>>> It was interesting that attach/detach to the ld process >>>> caused it to progress. The rest of the build completed >>>> just fine. But that one spot consistently hung up before >>>> trying gdb to look at the back trace. >>>>=20 >>>=20 >>> Looking at the qemu code related to the 2nd patch: the >>> structure of the field copies (via __get_user) seems >>> very sensitive to the ABI rules for the target and >>> how things align and such, given that the structure >>> description and code are host code. __packed vs. not >>> is possibly not sufficient control to always make things >>> match right across all the potential combinations of >>> host and target from what I can see. >>>=20 >>> Lack of __packed may prove sufficient for my specific >>> context (amd64 host and armv7 target) but it seems >>> non-obvious what to do in general. >>>=20 >>> There would also seem to be big endian vs. little endian >>> issues on the individual __get_user styles of copies >>> when the host and target do not match for a multi-byte >>> numeric encoding. >>=20 >> Well, I get the following for: >>=20 >> #include "/usr/include/sys/event.h" // kevent >> #include // offsetof >> #include // printf >>=20 >> int >> main() >> { >> printf("%lu\n", (unsigned long) sizeof(struct kevent)); >> printf("ident %lu\n", (unsigned long) offsetof(struct kevent, = ident)); >> printf("filter %lu\n", (unsigned long) offsetof(struct kevent, = filter)); >> printf("flags %lu\n", (unsigned long) offsetof(struct kevent, = flags)); >> printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, = fflags)); >> printf("data %lu\n", (unsigned long) offsetof(struct kevent, = data)); >> printf("udata %lu\n", (unsigned long) offsetof(struct kevent, = udata)); >> printf("ext %lu\n", (unsigned long) offsetof(struct kevent, = ext)); >> return 0; >> } >>=20 >> (This code avoided warnings for type mismatches with the >> printf strings and such.) >>=20 >> amd64 native [host of qemu use] (comments hand added): >>=20 >> # ./a.out >> 64 >> ident 0 >> filter 8 // NOTE! >> flags 10 // NOTE! >> fflags 12 // NOTE! >> data 16 >> udata 24 >> ext 32 >>=20 >> (The above is not particularly important but I >> include it for completeness.) >>=20 >> armv7 native [target in qemu use] (comments hand added): >>=20 >> # ./a.out >> 64 // NOTE vs. below! >> ident 0 >> filter 4 // NOTE vs. above! >> flags 6 // NOTE vs. above! >> fflags 8 // NOTE vs. above! >> data 16 // NOTE vs. below! >> udata 24 // NOTE vs. below! >> ext 32 // NOTE vs. below! >>=20 >> /usr/include/sys/event.h lacks __packed in both cases. >>=20 >> With __packed in qemu-arm-static's source code >> for target_freebsd_kevent I confirm that via >> gdb for the qemu-arm-static: >>=20 >> p/d sizeof(struct target_freebsd_kevent) >> p/d &((struct target_freebsd_kevent *)0)->ident >> p/d &((struct target_freebsd_kevent *)0)->filter >> p/d &((struct target_freebsd_kevent *)0)->flags >> p/d &((struct target_freebsd_kevent *)0)->fflags >> p/d &((struct target_freebsd_kevent *)0)->data >> p/d &((struct target_freebsd_kevent *)0)->udata >> p/d &((struct target_freebsd_kevent *)0)->ext >>=20 >> reports as the 2nd patch's problem-report >> material reports (56,0,4,6,8,12,20,24): not >> even the right size. >>=20 >> I also confirm that removing __packed in qemu's >> code and rebuilding and then checking with gdb >> reported a match to the above armv7 native report >> (64,0,4,6,8,16,24,32). >>=20 >> I have not verified __packed used vs. not for any >> other combination of host and target platforms. >=20 > Removing the 2 examples of __packed, including the > 1 for target_freebsd_kevent, as in Mika=C3=ABl Urankar's > 2nd listed patch, was sufficient to avoid the hang > that I originally reported. (Technically FreeBSD 11 > is not involved and so one of the __packed removals > is not relevant to my example.) >=20 > I have not applied Mika=C3=ABl Urankar's first listed > patch at all. It did not prove necessary for my > context. >=20 > Again: the only tested context is amd64 -> armv7 > (host -> target) under a head -r339076 based > build. (So still 12.) >=20 > I'm doing a larger amd64 -> armv7 rebuild (around > 210 ports overall) that originally included the > problematical hang and a full-bootstrap build > of lang/gcc8 (so extensive emulation use after > the clang-based stages). Prior to the patch, > all smaller attempts also hung at the same > place for print/texinfo. >=20 > But I'll only report if this larger test has > a problem. The bigger test still hung up in the same old place. A gdb attach/detach sequence against the qemu-arm-static for the ld again let it continue from there. Drat. But good to know. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Sun Oct 28 13:58:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2017310D1A45 for ; Sun, 28 Oct 2018 13:58:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-22.consmr.mail.gq1.yahoo.com (sonic303-22.consmr.mail.gq1.yahoo.com [98.137.64.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9E19385482 for ; Sun, 28 Oct 2018 13:58:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: zoFnuvAVM1mZUfQrPQcXwTDWeh_CkHZaQK_CXgY4I_1t1nMYmFUOIDoqPMoiTS6 tYOPUXQVV0A.ta62JcS6B3PI1hd9ZCbKiyYbcHutTqKIR3XVitCRSyT9yLpx8J.YiCqX2PA2AkvP m9HIVpVapI6qo.rULBBM9pfYIwq77vkLGHzZ_pvG4qTpf5yFWQ62FZoRlvevvLH5X.QZAvfsLgqq SicbPbi7SnR5jc422Z_MP0HQLltct0tifyKcT5dbieJlMNuznbXuOmpbVClh_h7bkUMpX.ebGMw4 Q4rh94SC5uwrGnvL7WtQ5O6BCdJw3Iw4wJXr6PGXbOHP8OaPv.wrTIVb5M.cFZQ7hE1.g_JLfAVZ l9WgGHXhWmtdJpwpYjY48rgljCobe5iFzXGVhb_8fSMZmVR8Ia_sKVoXiUnBpgQo_Y9QVyrSMKxt Ko8AIcv4jBpCo_dj5Q4edTY9LlieaeThvIRQvkmfCtS.WY0eGCWOcEzJzk8_CIibyGXSIoaccIWF 246s4KIZbrKEh2jvRHZ6ztvmvDRiXBLO314O0ZtuvA6ZNLyupWA9rFaiFszrNlZRmxCGeKeFby0S qaxKIskMfItH5Gyrbky6YSVeBHSIv5f7ELU_GNAmv6VJzfsNqkjRy_tFTV8IF5wB5ZNou0_iR9DB dTosYamrBtmW_rWzEdv9JWwVK802OBwEWC59Wi3xuE807hOhNScTdimpXbP5Ylfx4J4TzG9pCEWP 6_Say2cQ8YBLaKZ1dx6trRvI_bLTp6xNxHViUI3M.F3ibsfb3E3FOQ.1ELGA8RxpQ4wF3R_3VAmK BVzewVQUBlaKkAiBJBAt1UHrhqJPiqywLPDLbYyzEX3.cF_IdKwypLBGP9xNNy5Mlbk0NpxHtQdI OA648emVASgtn6WgnFnb5KykusQaOF5xLLavEsn4Ekbl.fJ11mPJCpKc_i0SDcMPhgiE4msz7eQ2 kSZ7aglSOtJlNHPFZ_kb6IOdCEBHVeTFeIlmybPxiv9cDYyr4B82gph56gL.lPgGKdozug5xAtXQ _jKqHSrjOIWV5kVnjuBIc8jipS7BNDjHbhpZbxP0tmwujmRM_sfmBC.vw1A-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sun, 28 Oct 2018 13:58:16 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp428.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fef59226e7a8c8d85910decefd040bb7; Sun, 28 Oct 2018 13:58:14 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: head -r339076 amd64 -> armv7 port cross build attempt with native tools involved: hangs between a cc (wait) and its child ld (uwait) From: Mark Millard In-Reply-To: Date: Sun, 28 Oct 2018 06:58:13 -0700 Cc: FreeBSD Toolchain , freeBSD , FreeBSD Ports ML Content-Transfer-Encoding: quoted-printable Message-Id: <324BD0F0-4017-4395-9B59-B7A8558EA6FD@yahoo.com> References: <33C58480-1E76-4748-83B4-CB39FAD8584A@yahoo.com> <220332B7-0B5E-4378-AD48-FDFB8F135A50@yahoo.com> To: =?utf-8?Q?Mika=C3=ABl_Urankar?= , Sean Bruno X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2018 13:58:26 -0000 [I have a work around for the specific activity to avoid the hang.] On 2018-Oct-27, at 6:00 PM, Mark Millard wrote: > [The bigger test still hung up.] >=20 > On 2018-Oct-27, at 5:30 PM, Mark Millard wrote: >=20 >> [Just the __packed removal patch was sufficient to no longer >> have the hang problem that I originally reported for the >> print/texinfo build in poudriere.] >>=20 >> On 2018-Oct-27, at 4:33 PM, Mark Millard = wrote: >>=20 >>> [Some of this discussion occurred off list. The point here >>> is not specific to the hang that I originally reported.] >>>=20 >>> On 2018-Oct-27, at 3:03 PM, Mark Millard = wrote: >>>>=20 >>=20 >> Mika=C3=ABl Urankar is being quoted below: >>=20 >>>>> . . . >>>>>=20 >>>>>> There are bugs in qemu that can cause such deadlock, you can try = these >>>>>> 2 patches: >>>>>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/9424a5ffde4de2768ab6= baa45fdbe0dbb56a7371 >>>>>> = https://github.com/MikaelUrankar/qemu-bsd-user/commit/d6f65a7f07d280b6906d= 499d8e465d4d2026c52b >>=20 >> Back to me: >>=20 >>>>> I'll try those later. Thanks. (I need to get back to sleep.) >>>>>=20 >>>>> It was interesting that attach/detach to the ld process >>>>> caused it to progress. The rest of the build completed >>>>> just fine. But that one spot consistently hung up before >>>>> trying gdb to look at the back trace. >>>>>=20 >>>>=20 >>>> Looking at the qemu code related to the 2nd patch: the >>>> structure of the field copies (via __get_user) seems >>>> very sensitive to the ABI rules for the target and >>>> how things align and such, given that the structure >>>> description and code are host code. __packed vs. not >>>> is possibly not sufficient control to always make things >>>> match right across all the potential combinations of >>>> host and target from what I can see. >>>>=20 >>>> Lack of __packed may prove sufficient for my specific >>>> context (amd64 host and armv7 target) but it seems >>>> non-obvious what to do in general. >>>>=20 >>>> There would also seem to be big endian vs. little endian >>>> issues on the individual __get_user styles of copies >>>> when the host and target do not match for a multi-byte >>>> numeric encoding. >>>=20 >>> Well, I get the following for: >>>=20 >>> #include "/usr/include/sys/event.h" // kevent >>> #include // offsetof >>> #include // printf >>>=20 >>> int >>> main() >>> { >>> printf("%lu\n", (unsigned long) sizeof(struct kevent)); >>> printf("ident %lu\n", (unsigned long) offsetof(struct kevent, = ident)); >>> printf("filter %lu\n", (unsigned long) offsetof(struct kevent, = filter)); >>> printf("flags %lu\n", (unsigned long) offsetof(struct kevent, = flags)); >>> printf("fflags %lu\n", (unsigned long) offsetof(struct kevent, = fflags)); >>> printf("data %lu\n", (unsigned long) offsetof(struct kevent, = data)); >>> printf("udata %lu\n", (unsigned long) offsetof(struct kevent, = udata)); >>> printf("ext %lu\n", (unsigned long) offsetof(struct kevent, = ext)); >>> return 0; >>> } >>>=20 >>> (This code avoided warnings for type mismatches with the >>> printf strings and such.) >>>=20 >>> amd64 native [host of qemu use] (comments hand added): >>>=20 >>> # ./a.out >>> 64 >>> ident 0 >>> filter 8 // NOTE! >>> flags 10 // NOTE! >>> fflags 12 // NOTE! >>> data 16 >>> udata 24 >>> ext 32 >>>=20 >>> (The above is not particularly important but I >>> include it for completeness.) >>>=20 >>> armv7 native [target in qemu use] (comments hand added): >>>=20 >>> # ./a.out >>> 64 // NOTE vs. below! >>> ident 0 >>> filter 4 // NOTE vs. above! >>> flags 6 // NOTE vs. above! >>> fflags 8 // NOTE vs. above! >>> data 16 // NOTE vs. below! >>> udata 24 // NOTE vs. below! >>> ext 32 // NOTE vs. below! >>>=20 >>> /usr/include/sys/event.h lacks __packed in both cases. >>>=20 >>> With __packed in qemu-arm-static's source code >>> for target_freebsd_kevent I confirm that via >>> gdb for the qemu-arm-static: >>>=20 >>> p/d sizeof(struct target_freebsd_kevent) >>> p/d &((struct target_freebsd_kevent *)0)->ident >>> p/d &((struct target_freebsd_kevent *)0)->filter >>> p/d &((struct target_freebsd_kevent *)0)->flags >>> p/d &((struct target_freebsd_kevent *)0)->fflags >>> p/d &((struct target_freebsd_kevent *)0)->data >>> p/d &((struct target_freebsd_kevent *)0)->udata >>> p/d &((struct target_freebsd_kevent *)0)->ext >>>=20 >>> reports as the 2nd patch's problem-report >>> material reports (56,0,4,6,8,12,20,24): not >>> even the right size. >>>=20 >>> I also confirm that removing __packed in qemu's >>> code and rebuilding and then checking with gdb >>> reported a match to the above armv7 native report >>> (64,0,4,6,8,16,24,32). >>>=20 >>> I have not verified __packed used vs. not for any >>> other combination of host and target platforms. >>=20 >> Removing the 2 examples of __packed, including the >> 1 for target_freebsd_kevent, as in Mika=C3=ABl Urankar's >> 2nd listed patch, was sufficient to avoid the hang >> that I originally reported. (Technically FreeBSD 11 >> is not involved and so one of the __packed removals >> is not relevant to my example.) >>=20 >> I have not applied Mika=C3=ABl Urankar's first listed >> patch at all. It did not prove necessary for my >> context. >>=20 >> Again: the only tested context is amd64 -> armv7 >> (host -> target) under a head -r339076 based >> build. (So still 12.) >>=20 >> I'm doing a larger amd64 -> armv7 rebuild (around >> 210 ports overall) that originally included the >> problematical hang and a full-bootstrap build >> of lang/gcc8 (so extensive emulation use after >> the clang-based stages). Prior to the patch, >> all smaller attempts also hung at the same >> place for print/texinfo. >>=20 >> But I'll only report if this larger test has >> a problem. >=20 >=20 > The bigger test still hung up in the same old place. > A gdb attach/detach sequence against the qemu-arm-static > for the ld again let it continue from there. >=20 > Drat. But good to know. Having lld use -Wl,--no-threads avoids the problem. Without the option, lld for N "cpus" creates N or so extra worker threads (besides the thread for main) plus one more that does something different. Having only the thread for main (and possibly one more) avoids the hangups. In my context, N=3D=3D28 (Hyper-V) or N=3D=3D32 (native FreeBSD boot) was in use. Also: The hangups when there were around N+2 threads total only happened when lld was executed as emulated code instead of as host-native code. Some autoconfig activity does not use ${CC} or the like and so some lld use ends up emulated even when most of the clang/llvm activity in the poudriere bulk run is host-native. Side note: The ports infrastructure does not have LINKER_TYPE in use like buildworld buildkernel does, so I did not use LDFLAGS.lld+=3D-Wl,--no-threads like I do for buildworld buildkernel . For now I'm using LDFLAGS.clang+=3D-Wl,--no-threads with LDFLAGS+=3D${LDFLAGS.${CHOSEN_COMPILER_TYPE}} in order to select the option when lld is more likely to be in use. I also avoid the LDFLAGS.clang assignment for powerpc* families, because lld is not used in that context (so far). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-hackers@freebsd.org Mon Oct 29 22:45:30 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B93B010EC881 for ; Mon, 29 Oct 2018 22:45:30 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 381AB894D5; Mon, 29 Oct 2018 22:45:30 +0000 (UTC) (envelope-from robert.ayrapetyan@gmail.com) Received: by mail-pf1-x432.google.com with SMTP id h4-v6so4747480pfi.10; Mon, 29 Oct 2018 15:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=j2PTZBPryYKgKYdVZ0bILYsrxqd2a9MjLrCTs8re2Ak=; b=c9PTGzA3fIMm8mu6b+ui4QOlgsh0IhjlvMn05HK6HA7Whhv5i/DuP8pM8Xb7CBdZo8 YsJQRSDrWo3DNVaAG51txTH6HJuNFhSACBbSAbUEhyV1zerVrlOyPzx/yU8IB7eOTuCW tKLbN4xltou16KcyErhtzwuKaDZI22dvRKcpaRVKHQGVs0eCUCT4Ca4CrDIY0HBNRSsg nmAuOCYaAqeT4h1AM59Mffe8kDEIV/7KYXN/5bru+ZBZesQSts8EnrBk2hn81jTR2X2d L7y73qarQ+VDTyvL8YU6hz4l+sBUQLvmR+6lxE58kNSvBmtWOA454cBkAmFJCxPstb3h AuWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=j2PTZBPryYKgKYdVZ0bILYsrxqd2a9MjLrCTs8re2Ak=; b=AK+UGBUVYKZ4+5gCz6d2cLEz/sjKdty/eTQco4Coy2hGccNzc7H1Y9QSCQbFD9UXWG gf4YJ8mJVUOKTK7sKx/Y1rdsQgg+e3nkz6K3uCq1JkqK4wbcv1L3el4SkLKrG3gXU1oI jEqP7G6oImYDdU6kAfx8S0SDxJJGjzAg8ZxgTj6CE9Ha6IizKuWToKvJj18uq6kGnoIM hhXaHZHvRm9h4lMIZw1S8fvXvd8RE/C9iUB6vz3CAW4WzxAd6oHovZ3+i7RrnZz0ep+K 9sYGMq1/JbjgBC/Kt3612gor+ym0fT7OjxVrqS56dqye/bIwIQQ38tBliyubjW2aCBIS ytbA== X-Gm-Message-State: AGRZ1gLyTPEVSFX5oGdnFKUinlx+qnNdMv5GNbODb2Sn0LZDl+CRVJFV pjdk1sCv4Ts/7DZ0Pxu4eQ== X-Google-Smtp-Source: AJdET5cJeKpi0fw/rXStIDA+6UWBtJm4bNZ3OSCxNlaiyh5MndIcYsryI0cvHDaH39lkXftFVHfDNg== X-Received: by 2002:a62:8145:: with SMTP id t66-v6mr290886pfd.246.1540853128622; Mon, 29 Oct 2018 15:45:28 -0700 (PDT) Received: from [192.168.1.113] (c-73-202-42-181.hsd1.ca.comcast.net. [73.202.42.181]) by smtp.gmail.com with ESMTPSA id f22-v6sm27451190pff.29.2018.10.29.15.45.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 15:45:26 -0700 (PDT) Subject: Re: Sudden grow of memory in "Laundry" state To: Konstantin Belousov Cc: Mark Millard , FreeBSD , Mark Johnston , Rozhuk Ivan References: <20180911150849.GD92634@raichu> <104be96a-c16b-7e7c-7d0d-00338ab5a106@gmail.com> <20180928152550.GA3609@raichu> <20181024211237.302b72d9@gmail.com> <981C887D-78EB-46D2-AEE5-877E269AF066@yahoo.com> <42f6544f-830c-18c5-e1a8-0acc4c3f09cc@gmail.com> <20181027043819.GX5335@kib.kiev.ua> From: Robert Message-ID: Date: Mon, 29 Oct 2018 15:45:25 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181027043819.GX5335@kib.kiev.ua> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 22:45:31 -0000 Hi Konstantin, thanks for your reply. As per your response, both active and inactive regions are actually allocated to the user app, means my app allocated (and haven't freed) more than available amount of RAM... Does that mean there is basically a memory leak in the app code? Could you recommend a good instrument to find and catch a memory leak in a FreeBSD? Thanks. On 10/26/18 9:38 PM, Konstantin Belousov wrote: > On Fri, Oct 26, 2018 at 03:07:07PM -0700, Robert wrote: >> Sorry, let me be more specific. >> >> Please look into: >> https://docs.google.com/spreadsheets/d/152qBBNokl4mJUc6T6wVTcxaWOskT4KhcvdpOL68gEUM/edit?usp=sharing >> (wait until charts fully loaded). >> >> These are all memory states and mmap\munmap stats collected. Y axis is >> in MBs, X is a timeline. >> >> It's not a problem to understand which process produces allocations and >> is being swapped. I know this for sure. >> >> The issue is: I strongly believe that by some reason FreeBSD kernel >> fails to reuse deallocated memory properly. >> >> Looking into graphs we can see following: >> >> 1. When process allocates memory (mmap), "Active" memory increases, >> "Free" memory decreases (that's expected). > No, mmap(2) call only causes some small amount of the kernel memory > allocation, to track the mmaped region. > > Pages are allocated on the first touch, lets ignore the prefaulting > mechanism which is not too relevant for the discussion. Mapped page > can be either active or inactive, this is determined by the usage > history. > >> 2. When process deallocates memory (munmap), "Inactive" memory >> increases, "Active" memory decreases. > Again no. Unmapped pages does not get active references from userspace > which touch them, so eventually pagedaemon moves active unmapped memory > to inactive. > >> Memory never returns into "Free" state. That's kind of expected as well. > When the last mapping of the anonymous swap-backed page is destroyed, > there is no point in retaining the page content, so it is freed. > For the pages backed by the file, there is no point to drop content > which we already paid for by read. > >> 3. At some point, when sum of "Active" and "Inactive" memory exceeds >> some upper memory limits, >> >> OS starts to push "Inactive" memory into "Laundry" and "Swap". This >> happens very quick and unexpectedly. > So this is the pattern of behaviour of your applications. > >> Now why OS doesn't reuse huge amounts of "Inactive" memory when calling >> mmap? > Because typically active and inactive pages carry some useful content, > which cannot be lost. Before reusing the page, pagedaemon must ensure > that the page is written to file for file-backed mappings, or to swap > for anonymous mappings, so its data can be restored when needed again. > > If the page content is synced with the permanent storage, it is called > clean, otherwise dirty. Reuse of dirty page requires changing its state > to clean by write-out. Laundry is the queue where the dirty pages > sit waiting for write, this is done to not clog inactive queue since > the page was already processed by the page daemon and decided for laundry. > >> Or my assumption about availability of "Inactive" memory is wrong? Which >> one is free for allocations then? > Yes, you assumptions are wrong. Active/inactive represent the > usage/reference history, not the reusability (clean/dirty) state. > >> Thanks. >> >> >> On 10/24/18 11:58 AM, Mark Millard wrote: >>> On 2018-Oct-24, at 1:25 PM, Robert wrote: >>> >>>> Sorry, that wasn't my output, mine (related to the screenshot I've sent earlier) is: >>> No screen shot made it through the list back out to those that >>> get messages from the freebsd-hackers at freebsd.org reference >>> in the CC. The list limits itself to text as I understand. >>> >>>> Mem: 1701M Active, 20G Inact, 6225M Laundry, 2625M Wired, 280M Free >>>> ARC: 116M Total, 6907K MFU, 53M MRU, 544K Anon, 711K Header, 55M Other >>>> 6207K Compressed, 54M Uncompressed, 8.96:1 Ratio >>>> Swap: 32G Total, 15G Used, 17G Free, 46% Inuse >>> Relative to my limited point: I do not know the status of >>> mutually-exclusive categorizations vs. not for ZFS ARC and >>> Mem. >>> >>> Unfortunately, as I understand things, it is questionable if >>> adding -S to the top command gives you swap information that >>> can point to what makes up the 15G swapped out by totaling >>> the sizes listed. But you might at least be able to infer >>> what processes became swapped out even if you can not get >>> a good size for the swap space use for each. >>> >>> Using -ores does seem like it puts the top users of resident >>> memory at the top of top's process list. >>> >>> Sufficient Active RAM use by processes that stay active will >>> tend to cause inactive processes to be swapped out. FreeBSD >>> does not swap out processes that stay active: it pages those >>> as needed instead of swapping. >>> >>> So using top -Sores might allow watching what active >>> process(es) grow and stay active and what inactive processes >>> are swapped out at the time of the activity. >>> >>> I do infer that the 15G Used for Swap is tied to processes >>> that were not active when swapped out. >>> >>>> I'm OK with a low "Free" memory if OS can effectively allocate from "Inactive", >>>> >>>> but I'm worrying about a sudden move of a huge piece of memory into "Swap" without any relevant mmap calls. >>>> >>>> >>>> My question is: what else (except mmap) may reduce "Free" memory and increase "Laundry"\"Swap" in the system? >>>> >>>> Thanks. >>>> >>>> >>>> On 10/24/18 9:34 AM, Mark Millard wrote: >>>>> On 2018-Oct-24, at 11:12 AM, Rozhuk Ivan wrote: >>>>> >>>>>> On Wed, 24 Oct 2018 10:19:20 -0700 >>>>>> Robert wrote: >>>>>> >>>>>>> So the issue is still happening. Please check attached screenshot. >>>>>>> The green area is "inactive + cached + free". >>>>>>> >>>>>>> . . . >>>>>> +1 >>>>>> Mem: 845M Active, 19G Inact, 4322M Laundry, 6996M Wired, 1569M Buf, 617M Free >>>>>> Swap: 112G Total, 19M Used, 112G Free >>>>> Just a limited point based on my understanding of "Buf" in >>>>> top's display . . . >>>>> >>>>> If "cached" means "Buf" in top's output, my understanding of Buf >>>>> is that it is not a distinct memory area. Instead it totals the >>>>> buffer space that is spread across multiple states: Active, >>>>> Inactive, Laundry, and possibly Wired(?). >>>>> >>>>> In other words: TotalMemory = Active+Inact+Laundry+Wired+Free. >>>>> If Buf is added to that then there is double counting of >>>>> everything included in Buf and the total will be larger >>>>> than the TotalMemory. >>>>> >>>>> Also Inact+Buf+Free may double count some of the Inact space, >>>>> the space that happens to be inactive buffer space. >>>>> >>>>> I may be wrong, but that is my understanding. >>>>> >>> === >>> Mark Millard >>> marklmi at yahoo.com >>> ( dsl-only.net went >>> away in early 2018-Mar) >>> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Tue Oct 30 01:20:26 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C027210F115A for ; Tue, 30 Oct 2018 01:20:26 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 A0C298F14A; Tue, 30 Oct 2018 01:20:25 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w9U1KC8E014828 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Oct 2018 03:20:15 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w9U1KC8E014828 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w9U1KCgE014827; Tue, 30 Oct 2018 03:20:12 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Tue, 30 Oct 2018 03:20:12 +0200 From: Konstantin Belousov To: Robert Cc: Mark Millard , FreeBSD , Mark Johnston , Rozhuk Ivan Subject: Re: Sudden grow of memory in "Laundry" state Message-ID: <20181030012012.GL5335@kib.kiev.ua> References: <104be96a-c16b-7e7c-7d0d-00338ab5a106@gmail.com> <20180928152550.GA3609@raichu> <20181024211237.302b72d9@gmail.com> <981C887D-78EB-46D2-AEE5-877E269AF066@yahoo.com> <42f6544f-830c-18c5-e1a8-0acc4c3f09cc@gmail.com> <20181027043819.GX5335@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 01:20:26 -0000 On Mon, Oct 29, 2018 at 03:45:25PM -0700, Robert wrote: > Hi Konstantin, thanks for your reply. > > As per your response, both active and inactive regions are actually > allocated to the user app, Not necessary. E.g. the pages which hold the data for some files are accounted there. > > means my app allocated (and haven't freed) more than available amount of > RAM... > > Does that mean there is basically a memory leak in the app code? It is too far reaching to state that there is a leak only seeing the the large number of pages becoming dirty. Leak means that memory is consumed and not recycled after becoming useless. From owner-freebsd-hackers@freebsd.org Wed Oct 31 14:04:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A04410DA2A9 for ; Wed, 31 Oct 2018 14:04:58 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A5F7D76670 for ; Wed, 31 Oct 2018 14:04:57 +0000 (UTC) (envelope-from jacques.fourie@gmail.com) Received: by mail-io1-xd2d.google.com with SMTP id h19-v6so1068025iog.9 for ; Wed, 31 Oct 2018 07:04:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=6X774KJg4vh3nenklHtnjnW7Vjy+XN5/wKSjw689CQk=; b=O7LbP3KQ4YJpuY4SEMpzAYYDRoRVOrWqB++24NYoBUZSBFOn/7nCeQAGbE6ZultwhX 5zjwdxBqXopwhrw/Q1Kkr3el171HFKrd3+acynWocZmBhUS+sE/OoRSOLixoq7LNggqB hee5v05kPI2R631mw/n6DcCpanl2FkzD42S+ZnWzLdjWN7srAm7pgptW+4Irvc+zJ1Gh ioNXm9d9v+r0N1t8adkPkBMVeQvstA4MdsnSKXEPrUj/ZAbuxpprtQg1Y9LTyJmY0Lf/ 4mQ9lx93GH/zugzd/pmxb19O9z1rq7wmTsLNmObpSSeQbljUoZM36Qn+IcbugtO1HmC7 LVog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6X774KJg4vh3nenklHtnjnW7Vjy+XN5/wKSjw689CQk=; b=VoDx9L4Qw+wP6kbL4JejHMQW1er2/0njR4+801esDcyuUhYvHp9B5TbXPuC/yehOFD 9RmMxTeW7VjG+suFY00K/MU2/+v0TL3M5SO9rCyEgOFrZqi50UUAW4eHdLsBJsDsjpP0 X3pPTRUU8FcY+DxpguXpIhnGKIyvn2wBeVQzzgv0sDtIZjHMv66xJhroOVjGRNvLkAI1 joJLMurtIqRa5jIFxhYyO4LYNigNG1EnZ7kJH0Xxpb4YCQS2OjcWQxZVg7GOZauPiQlp opDER++rIibjJgeJSzkQlyhXhwpWTFZCAI2zLwm4WqX7eX38vLlyR7DmY77uAt6cyz2I uk7g== X-Gm-Message-State: AGRZ1gJkyCIWlgfCIaM8+oSUmGcfSmqJgt6UQMPdczhw85vo/7J5jd01 zyRULNAx/23Lr6vWSyxm7ntlsS5Vo1O+mROZQ654b3KN X-Google-Smtp-Source: AJdET5eL21xnD+3yWE7OxxtMcqDI++i4nKOXetcUBEY3YQ9KQCxrYzZXCLn3FeWxAchV4pBpeTBj83TNNPtUVzx/2EQ= X-Received: by 2002:a6b:c5c1:: with SMTP id v184-v6mr2314808iof.164.1540994696681; Wed, 31 Oct 2018 07:04:56 -0700 (PDT) MIME-Version: 1.0 From: Jacques Fourie Date: Wed, 31 Oct 2018 10:04:44 -0400 Message-ID: Subject: TCP RTT estimate for connections not using timestamps To: Hackers freeBSD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 14:04:58 -0000 Hi, While testing with traffic generators that don=E2=80=99t enable the TCP tim= estamp option I noticed a couple of cases where tcp_xmit_timer() was called with a 0 value for rtt with the current smoothed rtt (t_srtt) non zero. This leads to a left shift of -1 which is undefined. Looking at the code for the case where timestamps are enabled I see that tcp_xmit_timer() is always called with TCP_TS_TO_TICKS(t) + 1 for the rtt. Do we need a +1 in the non timestamp case as well? Thanks, Jacques From owner-freebsd-hackers@freebsd.org Wed Oct 31 14:12:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75F2B10DAB45; Wed, 31 Oct 2018 14:12:03 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 133A776DA9; Wed, 31 Oct 2018 14:12:03 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id DEAAD8D4A241; Wed, 31 Oct 2018 14:12:01 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E7B25D1F878; Wed, 31 Oct 2018 14:12:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id viR00HixoCVJ; Wed, 31 Oct 2018 14:11:59 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 80E7FD1F874; Wed, 31 Oct 2018 14:11:59 +0000 (UTC) From: "Bjoern A. Zeeb" To: freebsd-transport@freebsd.org Cc: "Hackers freeBSD" Subject: Re: TCP RTT estimate for connections not using timestamps Date: Wed, 31 Oct 2018 14:11:58 +0000 Reply-To: freebsd-transport@freebsd.org X-Mailer: MailMate (2.0BETAr6125) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 14:12:03 -0000 On 31 Oct 2018, at 14:04, Jacques Fourie wrote: Copying to transport@ please respect Reply-To to there. > Hi, > > > While testing with traffic generators that don’t enable the TCP timestamp > option I noticed a couple of cases where tcp_xmit_timer() was called with a > 0 value for rtt with the current smoothed rtt (t_srtt) non zero. This leads > to a left shift of -1 which is undefined. Looking at the code for the case > where timestamps are enabled I see that tcp_xmit_timer() is always called > with TCP_TS_TO_TICKS(t) + 1 for the rtt. Do we need a +1 in the non > timestamp case as well? > > > Thanks, > > Jacques > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Thu Nov 1 15:13:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A33810F5665 for ; Thu, 1 Nov 2018 15:13:43 +0000 (UTC) (envelope-from jbondc@gdesolutions.com) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820125.outbound.protection.outlook.com [40.107.82.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D381A7A593 for ; Thu, 1 Nov 2018 15:13:42 +0000 (UTC) (envelope-from jbondc@gdesolutions.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gdesolutions.onmicrosoft.com; s=selector1-gdesolutions-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+YwMd2UfNmxIM9M7I0N2AS2N/W5RHa2ItpA9XdpPF/A=; b=CO9b6uDs8Gix5bhcj+B3GjN0Vkiqhcwm9qHbs2vJgzOM369NY5bDHHR/k+vnniIMwZUySqcp2Gv2QoWb8llvv7/KiU1lKszYqaFnZe0jQ41MkuDh1+9mjS6sEmbaLzi3o+Da9hYdw3OApBMuRC3LRC9a1I63FxBlgqFgOJunoLI= Received: from DM5PR17MB1625.namprd17.prod.outlook.com (10.175.222.149) by DM5PR17MB1098.namprd17.prod.outlook.com (10.168.116.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Thu, 1 Nov 2018 15:13:40 +0000 Received: from DM5PR17MB1625.namprd17.prod.outlook.com ([fe80::9ad:7392:cb:e804]) by DM5PR17MB1625.namprd17.prod.outlook.com ([fe80::9ad:7392:cb:e804%2]) with mapi id 15.20.1273.027; Thu, 1 Nov 2018 15:13:39 +0000 From: Jonathan Bond-Caron To: "freebsd-hackers@freebsd.org" Subject: vidcontrol -i with vt? Thread-Topic: vidcontrol -i with vt? Thread-Index: AdRx9QTFqZFhP0B0Q5C1K8u/AW9ofw== Date: Thu, 1 Nov 2018 15:13:39 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jbondc@gdesolutions.com; x-originating-ip: [96.20.150.93] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR17MB1098; 6:WahfTXUPbXxPZcP/KAYd9yr8CXIEB+TgFyAKh4Q03UHgZiNXG9na1UQ1pAQ6l9N5cCjHLi9c94iOU/OgQcIeVdjXW9PD7NKvpY63qD0fEmbqKOY6tilY3SZzB6A+5Bz8KOQ3mh0XdDm0/9a+sFL0XdeMNH70U/kFrwwxnV2hNBcEo0BJTKPr3Heob92eshSL68n3oWKxDaPW+At1Uc3Kq/BuLXLsPk7xk1sn2gYN6+iEhpBg+w7UmOYCvgaabbG88PkACp8vzjT63xcdUS1zFZ1zvSXdHQMnVSeRMuqw4MD8abF2O1FtlDh2SgX27AIAOtYv4RfZk/7QUHyAokqG0Gd/6gwd75i4am8dogPI/P8hSOzJEndEL+uQW68L7VcWNSlbO0+V/Y8AZmDOY47p33evoFJEsepYJ7Ao5DnK7tM9xe1wvFP9DAMQFjOO8Iyp152vmRBvngXGcZ/gB/Qz4g==; 5:7ru/ZkV9lSfvjGTdkysWwX7F3JBMomjV7SR9iM2xkuX54nSoMqvvJW1wttmFq+Qo8f6rsSVOZ2jR1E15TT0iR4mRNtXpj13/HdSRT9y9LaIcreUbUWlEOZxjOadQ55P147RN7mNFZ4Van69ULkoqicHCLiOqMSiiVGW1vwie1w8=; 7:ni7PQbBfb5r5hh4YEEBLhMJnBTpELfGXqVuon5ussrRA5eVQs6F3CR7XllwiepmQy1duREBLjqmXtROlt4czoFj/IBmIkx/9upaYJoMMv5GzCc5462rL6Km9nWD6UxLr5ymAWNCOY26EMfwqAeu4xA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 927522cf-a315-4ff2-4a34-08d6400c9aa7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021145)(8989299)(5600074)(711020)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7153060)(7193020); SRVR:DM5PR17MB1098; x-ms-traffictypediagnostic: DM5PR17MB1098: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(158342451672863)(21748063052155)(28532068793085)(190501279198761)(227612066756510); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231382)(944501410)(52105095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123560045)(2016111802025)(20161123564045)(20161123562045)(20161123558120)(6043046)(201708071742011)(7699051)(76991095); SRVR:DM5PR17MB1098; BCL:0; PCL:0; RULEID:; SRVR:DM5PR17MB1098; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39830400003)(396003)(366004)(376002)(346002)(199004)(189003)(81156014)(8676002)(6436002)(8936002)(508600001)(966005)(9326002)(5630700001)(5250100002)(2906002)(2351001)(790700001)(6116002)(3846002)(53936002)(66066001)(14454004)(102836004)(6306002)(236005)(54896002)(9686003)(55016002)(81166006)(71190400001)(71200400001)(5640700003)(7696005)(99286004)(6506007)(6916009)(97736004)(33656002)(606006)(5660300001)(7736002)(256004)(14444005)(2900100001)(74316002)(68736007)(86362001)(316002)(25786009)(26005)(106356001)(2501003)(105586002)(486006)(186003)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR17MB1098; H:DM5PR17MB1625.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: gdesolutions.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YVtLAks2ducG8l7jtHpC0+VP2ihEbr+XXcVd1vBzy6d98+unRaKpCS9BEpYE+G9NxBcEXT+bB6NJah5m4heL9t1+voM8Imk77sxv1raBa8TFyL55h6MxQL2juKyY9R9pRbYRlf83i8q8wnYbnOdLQdCwL83HcZIbpm5U5kducGpLE6GoS90oDDPeVuuIX6lLU+trRXsx70ISne04A1+zVBwr1G67eVWvd31CbZ4iXpmRlAXIAbElh06jlESXWQkopPQ/ZDS2YoK2oOodRh9h63tWBdyWDlHzonqhCK6ewg/u9JYTCuv7WHlyGtpm5TDeH+UT3Jw4HyIi1siuSgLiX1yd4ImeZzaSfHmpQcWWreE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: gdesolutions.com X-MS-Exchange-CrossTenant-Network-Message-Id: 927522cf-a315-4ff2-4a34-08d6400c9aa7 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2018 15:13:39.5341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6942206e-827e-4487-a23d-4a96c873f8cd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR17MB1098 X-Mailman-Approved-At: Thu, 01 Nov 2018 15:28:32 +0000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 15:13:43 -0000 Hi, After looking at upgrading from FreeBSD 10.4 to 11.2, I noticed vidcontrol = -I no longer works: root@freebsd11:~ # vidcontrol -i adapter vidcontrol: getting adapter information: Inappropriate ioctl for device See here for screenshots, the text just looks way too small on a 4k screen: https://1drv.ms/u/s!AjH3xH9IR1AphexUlPprBBQB2TBGOw After some digging I found 'CONS_MODEINFO' https://github.com/freebsd/freebsd/blob/master/usr.sbin/vidcontrol/vidcontr= ol.c#L1137 Which is implemented in 'syscons': https://github.com/freebsd/freebsd/blob/master/sys/dev/syscons/scvidctl.c#L= 571 But not in 'vt': https://github.com/freebsd/freebsd/blob/master/sys/dev/vt/vt_core.c#L2324 That's also explained in: https://wiki.freebsd.org/Newcons "No support for several vidcontrol(1) features." Think appropriate patch to vt would be to add VESA mode support too: https://github.com/freebsd/freebsd/commit/653c2af6aea50955f84c98c164cfd99ed= b197426 Is anyone working on adding vidcontrol support to vt? Think I might explore= it in the upcoming months. Currently, can the mode/resolution of FreeBSD 11 be changed in vt without a= graphics card? I'm running FreeBSD as a VM in Hyper-V Server, Best, Jonathan From owner-freebsd-hackers@freebsd.org Thu Nov 1 19:00:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D57010FBD8B; Thu, 1 Nov 2018 19:00:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4984785D9E; Thu, 1 Nov 2018 19:00:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-2.local (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id C443910B476; Thu, 1 Nov 2018 15:00:17 -0400 (EDT) Subject: =?UTF-8?Q?Re:_cryptodev_/_softcrypto_=e2=80=94_are_here_any_plans_t?= =?UTF-8?Q?o_cleanup_it=3f?= To: lev@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-security@freebsd.org References: From: John Baldwin Message-ID: Date: Thu, 1 Nov 2018 12:00:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 01 Nov 2018 15:00:18 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 19:00:19 -0000 On 10/16/18 11:59 AM, Lev Serebryakov wrote: > > To be honest, I'm surprised by inconsistency of our kernel crypto > infrastructure. > > "struct enc_xform" contains context size, but "struct auth_hash" doesn't. > > Memory management is different for auth algorithms and encryption > algorithms. > > There is Setkey for auth algorithms, but it is mostly unused. > > There is no way to re-key encryption without re-allocating context > ("key" or "schedule", even naming is not consistent). Ouch. > > As I could see by commits, there was some simplifications , but, > maybe, here is project to cleanup this subsystem? I have some WIP to rework the interface between OCF and backend drivers including cryptosoft. However, it doesn't really address any of the issues you raised. I would actually prefer it if we removed rekeying from OCF sessions (requiring new sessions for new keys). geli(4) is the only OCF consumer that changes keys on existing sessions. It would make some of the framework simpler (and would make the code that tries to migrate existing ops to a new session less fragile) if we bound keys to sessions and required keys during session creation. You can see my WIP here: https://github.com/freebsd/freebsd/compare/master...bsdjhb:ocf_rework -- John Baldwin                                                                              From owner-freebsd-hackers@freebsd.org Fri Nov 2 09:14:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3879310EEC12 for ; Fri, 2 Nov 2018 09:14:19 +0000 (UTC) (envelope-from shreyankfbsd@gmail.com) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 99E0D7EA98; Fri, 2 Nov 2018 09:14:18 +0000 (UTC) (envelope-from shreyankfbsd@gmail.com) Received: by mail-pl1-x636.google.com with SMTP id t6-v6so723308plo.9; Fri, 02 Nov 2018 02:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=in-reply-to:to:cc:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=0540tA0OjY6RxSYZrclse35U9zBxqAoWHJvLOC7hGaM=; b=aAJOyGmp7foZc+k0lzP1Qr7jDRfDKaAzMgMw6s9HYzAr1ivysEhW65fBvAoRd1HCxR QIBRknw4JDnh2/uzNDlpBgL11xLGg+yqM4uAfj4DTMJ12NKoNxuEwEUNi8zPpTscZofQ 5d5+F0Y1UCr8dbEqP7rjn1U3lgo38e+u3/xaZpLdDdM6Uafn3f6CAUF5JXuR2ophQpPF 3HXlFM+bmDTwt3OEVmBPdQc9brH17a8Kt0qKeHlsKOLKpz0UaaK+oqr7HNJhSm0kb1e9 +V1zqOLHB66BYswj8yolgsvl8P7/wN3KfqxsU1cV8qeyb9QmSmVtZRQZIQSf/FiMPrs+ ZeHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:in-reply-to:to:cc:from:subject:message-id:date :user-agent:mime-version:content-transfer-encoding:content-language; bh=0540tA0OjY6RxSYZrclse35U9zBxqAoWHJvLOC7hGaM=; b=blb+LHhVwmOr3zQTslPQtx1/RS+q5hvb+5+bnjmTT282HaTf/9YIJoJh0QDQTS9mW5 5D8p+ARpxP234uxWx6p8SmOj9NBFH+kSnywwGUHgbizkl0uJwjHZLUTmoOHEVpDEGrSB XY9wIZuRUxYhpcmgovaf0bMZdbtZxwJ1zHEYxd+bItBIRygbizx0eSTP+4pTG7DUp10u 2hBcHgwd2swgjT3yM044lSDIJ30pNvwPuPcVBq4ZXlXpjwN3O6jcuHQiTG5TS+n/eND8 lq8jX0zPBcQbtY0/BxWNAou31Iyzz2HX2MmF4fgClyTg5drybwvgQKRCXXamaZXA0N1F X1fA== X-Gm-Message-State: AGRZ1gLMCtUrj66gj/4e7E82pEwNZ5ZD1rkkq9niRt8DsSh1po6tG0mF WlYqEGEvw8NMcrRgXw1veDDgFrc= X-Google-Smtp-Source: AJdET5cggte95Iq0hOyhxhqvBIqXhAVtUQJOGD/hjxg0TstmenmqoFBH5iqbYO4yd+RimHvYco5g+g== X-Received: by 2002:a17:902:3341:: with SMTP id a59-v6mr10980933plc.138.1541150057351; Fri, 02 Nov 2018 02:14:17 -0700 (PDT) Received: from [10.136.129.217] ([202.56.249.162]) by smtp.gmail.com with ESMTPSA id d143-v6sm31706975pfd.58.2018.11.02.02.14.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Nov 2018 02:14:16 -0700 (PDT) In-Reply-To: To: marius@freebsd.org Cc: freebsd-hackers@freebsd.org From: "Amartya, Shreyank" Subject: Re: Re: FW: eMMC AMD platform Message-ID: Date: Fri, 2 Nov 2018 14:44:13 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailman-Approved-At: Fri, 02 Nov 2018 10:15:22 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 09:14:19 -0000 Hi, So I was able to get the performance numbers up by increasing the default SDMA boundary value from 4k up to 512K (which is the default in linux). With the increased boundary size I saw an increase in HS200 (141 MB/s) as well as HS400 (193 MB/s) throughput as compared to earlier with both the modes (~105 MB/s). Going over the code I understand that an increase in size causes less DMA interrupts. Any specific reason to use 4K as default value? If not, is it okay to switch to 512K? Thanks Shreyank From owner-freebsd-hackers@freebsd.org Fri Nov 2 23:25:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 81AE410DE97C for ; Fri, 2 Nov 2018 23:25:48 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F39A583DC1; Fri, 2 Nov 2018 23:25:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CD0418D4A217; Fri, 2 Nov 2018 23:25:45 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 79912D1F873; Fri, 2 Nov 2018 23:25:44 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id vovIOyPqSXN3; Fri, 2 Nov 2018 23:25:42 +0000 (UTC) Received: from [192.168.1.88] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 99A16D1F867; Fri, 2 Nov 2018 23:25:41 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Mark Johnston" Cc: freebsd-hackers@freebsd.org Subject: Re: [CFT] capsicum patches for rtsol(8) and rtsold(8) Date: Fri, 02 Nov 2018 23:25:40 +0000 X-Mailer: MailMate (2.0BETAr6125) Message-ID: In-Reply-To: <20181024195627.GI45118@raichu> References: <20181015194212.GA2751@spy> <20181016165308.GB5066@raichu> <86D87437-BD34-489A-87B7-33F1089080EE@lists.zabbadoz.net> <20181016200414.GD5066@raichu> <2A564C8A-FB64-4D2A-9E3E-392F1FCA66BD@lists.zabbadoz.net> <20181024195627.GI45118@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 23:25:48 -0000 On 24 Oct 2018, at 19:56, Mark Johnston wrote: Hi, sorry I lost track on this. > Yes, I just uploaded a new version of the patch to > https://people.freebsd.org/~markj/patches/rtsold_capsicum.diff and = > would > appreciate any further testing that you can do. The rtsol Makefile does not cleanly apply to my HEAD. Also there seems to be an empty .else case in both rtsold and rtsol = Makefiles. Also I couldn=E2=80=99t get rtsol to link until I realised that it was re= scue = which didn=E2=80=99t want to link (-j24 output can be confusing). I gues= s = with -DSMALL gone and MK_CASPER not turned off for rescue or whatever it = is the result is not what we expect? Just a few lines for you. =2E. 15229 = ^ 15230 1 warning generated. 15231 iscsid_stub.c:1:70: warning: implicit declaration of function = 'main' is invalid in C99 [-Wimplicit-function-declaration] 15232 int _crunched_iscsid_stub(int argc, char **argv, char = **envp){return main(argc,argv,envp);} 15233 = ^ 15234 1 warning generated. 15235 = /tank/users/bz/obj/tank/users/bz/git_bz_experimental_v6only/amd64.amd64/t= mp/usr/bin/ld: = error: undefined symbol: cap_init 15236 >>> referenced by _$$hide$$ rtsol.lo rtsock.c 15237 >>> rtsol.lo:(_$$hide$$ rtsol.lo main) 15238 15239 = /tank/users/bz/obj/tank/users/bz/git_bz_experimental_v6only/amd64.amd64/t= mp/usr/bin/ld: = error: undefined symbol: cap_service_open 15240 >>> referenced by _$$hide$$ rtsol.lo rtsock.c 15241 >>> rtsol.lo:(_$$hide$$ rtsol.lo main) 15242 15243 = /tank/users/bz/obj/tank/users/bz/git_bz_experimental_v6only/amd64.amd64/t= mp/usr/bin/ld: = error: undefined symbol: cap_service_open 15244 >>> referenced by _$$hide$$ rtsol.lo rtsock.c 15245 >>> rtsol.lo:(_$$hide$$ rtsol.lo main) 15246 15247 = /tank/users/bz/obj/tank/users/bz/git_bz_experimental_v6only/amd64.amd64/t= mp/usr/bin/ld: = error: undefined symbol: cap_service_open 15248 >>> referenced by _$$hide$$ rtsol.lo rtsock.c 15249 >>> rtsol.lo:(_$$hide$$ rtsol.lo main) 15250 15251 = /tank/users/bz/obj/tank/users/bz/git_bz_experimental_v6only/amd64.amd64/t= mp/usr/bin/ld: = error: undefined symbol: nvlist_create 15252 >>> referenced by _$$hide$$ rtsol.lo rtsock.c 15253 >>> rtsol.lo:(_$$hide$$ rtsol.lo main) 15254 =2E. >>> resolvconf -a will only update /etc/resolv.conf if the info in >>> /var/run/resolvconf/interfaces/vtnet0 has changed, I believe. Try >>> deleting that file too, and then try running rtsol. >> >> When I deleted /etc/resolv.conf and then rtsol manually it had >> re-appeared. Unclear to me what was in /var/run; I just wanted to = >> point >> out the difference in behaviour; maybe you are right; I=E2=80=99ll g= o and >> check if deleting in /var/run/ as well makes a difference. > > I don't observe that behaviour with either the stock or patched > rtsol(8): for resolvconf(8) to update /etc/resolv.conf (or re-generate > it), something under /var/run/resolvconf/interfaces needs to have > changed. So, in my case, deleting /etc/resolv.conf *and* > /var/run/resolvconf/interfaces/re0:slaac will cause resolv.conf to be > regenerated once rtsold(8) decides to re-run resolvconf(8), but > deleting resolv.conf on its own will not. I wonder if that=E2=80=99s a bug (unrelated to yours). I also noticed th= at = when my nameservers changed /etc/resolv.conf did not always reflect = this. /bz From owner-freebsd-hackers@freebsd.org Sat Nov 3 14:52:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E94B10FFF19 for ; Sat, 3 Nov 2018 14:52:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 031FE857B4 for ; Sat, 3 Nov 2018 14:52:14 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1gIxHK-000M79-Qv for freebsd-hackers@FreeBSD.org; Sat, 03 Nov 2018 16:51:58 +0200 From: Daniel Braniss Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: help with dl module and clang Message-Id: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> Date: Sat, 3 Nov 2018 16:51:58 +0200 To: freebsd-hackers@FreeBSD.org X-Mailer: Apple Mail (2.3445.100.39) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 14:52:15 -0000 Hi, I have a program that loads some modules via dlopen(), these modules = call some routines which are in the main program, this works when using gcc, but with cc it = does not. when compiling the main program I use -export-dynamic, and the modules = link fine when compiled with gcc, but when compiling with clang/cc i get dlerror: ...Undefined symbol = =E2=80=A6 BTW, when linking the main program with cc I get /usr/bin/ld: warning: cannot find entry symbol xport-dynamic; = defaulting to 0000000000402140 thanks, danny PS: I=E2=80=99m running FreeBSD 11.2 From owner-freebsd-hackers@freebsd.org Sat Nov 3 15:47:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 262E010DB731 for ; Sat, 3 Nov 2018 15:47:50 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B908986EB1 for ; Sat, 3 Nov 2018 15:47:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::d46f:9b92:e1e6:6d2f] (unknown [IPv6:2001:470:7a58:0:d46f:9b92:e1e6:6d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0A8F01524A; Sat, 3 Nov 2018 16:47:41 +0100 (CET) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AB3D4540-AD0E-41C2-927C-E4E172DB92E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: help with dl module and clang Date: Sat, 3 Nov 2018 16:47:37 +0100 In-Reply-To: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> Cc: freebsd-hackers@FreeBSD.org To: Daniel Braniss References: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 15:47:50 -0000 --Apple-Mail=_AB3D4540-AD0E-41C2-927C-E4E172DB92E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 3 Nov 2018, at 15:51, Daniel Braniss wrote: >=20 > I have a program that loads some modules via dlopen(), these modules = call some routines > which are in the main program, this works when using gcc, but with cc = it does not. >=20 > when compiling the main program I use -export-dynamic, and the = modules link fine when compiled with > gcc, but when compiling with clang/cc i get dlerror: ...Undefined = symbol =E2=80=A6 > BTW, when linking the main program with cc I get > /usr/bin/ld: warning: cannot find entry symbol xport-dynamic; = defaulting to 0000000000402140 Instead of using -export-dynamic (which is a linker flag) as a flag to cc, try using -Wl,-export-dynamic instead. Now, the linker interprets this as the -e flag, which is something totally different. I think this will also help with the exporting of the symbols of your main program. -Dimitry --Apple-Mail=_AB3D4540-AD0E-41C2-927C-E4E172DB92E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW93DGQAKCRCwXqMKLiCW o9O0AJ9tC96/mSUaHKoTaHuqd4Ar0Ss+NgCg6zU4kLcbNNKUgIbJm8zNw3dqlZQ= =nIL3 -----END PGP SIGNATURE----- --Apple-Mail=_AB3D4540-AD0E-41C2-927C-E4E172DB92E3-- From owner-freebsd-hackers@freebsd.org Sat Nov 3 15:58:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33FAD10DBDDE for ; Sat, 3 Nov 2018 15:58:24 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C2FC88757D; Sat, 3 Nov 2018 15:58:23 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1gIyJV-0000nb-Pj; Sat, 03 Nov 2018 17:58:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: help with dl module and clang From: Daniel Braniss In-Reply-To: Date: Sat, 3 Nov 2018 17:58:17 +0200 Cc: freebsd-hackers@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E58B6A3-B3E4-4266-9B40-5F3D64433460@cs.huji.ac.il> References: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> To: Dimitry Andric X-Mailer: Apple Mail (2.3445.100.39) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 15:58:24 -0000 > On 3 Nov 2018, at 17:47, Dimitry Andric wrote: >=20 > On 3 Nov 2018, at 15:51, Daniel Braniss wrote: >>=20 >> I have a program that loads some modules via dlopen(), these modules = call some routines >> which are in the main program, this works when using gcc, but with cc = it does not. >>=20 >> when compiling the main program I use -export-dynamic, and the = modules link fine when compiled with >> gcc, but when compiling with clang/cc i get dlerror: ...Undefined = symbol =E2=80=A6 >> BTW, when linking the main program with cc I get >> /usr/bin/ld: warning: cannot find entry symbol xport-dynamic; = defaulting to 0000000000402140 >=20 > Instead of using -export-dynamic (which is a linker flag) as a flag to > cc, try using -Wl,-export-dynamic instead. Now, the linker interprets > this as the -e flag, which is something totally different. >=20 i had tried that before but i had -WI (upper case i) but re-reading the = manual it should be-Wl (lower case l as in lima :-))!!!!! thanks!!!!!! and now have to try profiling (gprof) which started this mess, thanks again!! danny > I think this will also help with the exporting of the symbols of your > main program. >=20 > -Dimitry >=20 From owner-freebsd-hackers@freebsd.org Sat Nov 3 16:11:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C107B10DC3E3 for ; Sat, 3 Nov 2018 16:11:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59DDC8860D; Sat, 3 Nov 2018 16:11:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1gIyW8-00025j-35; Sat, 03 Nov 2018 18:11:20 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: help with dl module and clang From: Daniel Braniss In-Reply-To: <2E58B6A3-B3E4-4266-9B40-5F3D64433460@cs.huji.ac.il> Date: Sat, 3 Nov 2018 18:11:19 +0200 Cc: freebsd-hackers@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <08A14290-0A6E-4002-892E-D4254EB23076@cs.huji.ac.il> References: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> <2E58B6A3-B3E4-4266-9B40-5F3D64433460@cs.huji.ac.il> To: Dimitry Andric X-Mailer: Apple Mail (2.3445.100.39) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 16:11:25 -0000 > On 3 Nov 2018, at 17:58, Daniel Braniss wrote: >=20 >=20 >=20 >> On 3 Nov 2018, at 17:47, Dimitry Andric wrote: >>=20 >> On 3 Nov 2018, at 15:51, Daniel Braniss wrote: >>>=20 >>> I have a program that loads some modules via dlopen(), these = modules call some routines >>> which are in the main program, this works when using gcc, but with = cc it does not. >>>=20 >>> when compiling the main program I use -export-dynamic, and the = modules link fine when compiled with >>> gcc, but when compiling with clang/cc i get dlerror: ...Undefined = symbol =E2=80=A6 >>> BTW, when linking the main program with cc I get >>> /usr/bin/ld: warning: cannot find entry symbol xport-dynamic; = defaulting to 0000000000402140 >>=20 >> Instead of using -export-dynamic (which is a linker flag) as a flag = to >> cc, try using -Wl,-export-dynamic instead. Now, the linker = interprets >> this as the -e flag, which is something totally different. >>=20 >=20 > i had tried that before but i had -WI (upper case i) but re-reading = the manual > it should be-Wl (lower case l as in lima :-))!!!!! >=20 > thanks!!!!!! >=20 > and now have to try profiling (gprof) which started this mess, >=20 > thanks again!! >=20 > danny >=20 >=20 >> I think this will also help with the exporting of the symbols of your >> main program. >>=20 >> -Dimitry >>=20 >=20 ok, new problem, it also happens with gcc: when compiling the main program with flag -pg (gprof) dlopen fails with dlerror: Service unavailable what magic is needed now? danny > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sat Nov 3 16:22:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE50110DCB55 for ; Sat, 3 Nov 2018 16:22:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5F0F188C28 for ; Sat, 3 Nov 2018 16:22:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::d46f:9b92:e1e6:6d2f] (unknown [IPv6:2001:470:7a58:0:d46f:9b92:e1e6:6d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BEA3115250; Sat, 3 Nov 2018 17:22:56 +0100 (CET) From: Dimitry Andric Message-Id: <71B23784-3BA5-4FB8-A3A0-A72BC2BC3A26@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B858BDE2-259A-4CFE-A493-6CCC3212C605"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: help with dl module and clang Date: Sat, 3 Nov 2018 17:22:52 +0100 In-Reply-To: <08A14290-0A6E-4002-892E-D4254EB23076@cs.huji.ac.il> Cc: freebsd-hackers@FreeBSD.org To: Daniel Braniss References: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> <2E58B6A3-B3E4-4266-9B40-5F3D64433460@cs.huji.ac.il> <08A14290-0A6E-4002-892E-D4254EB23076@cs.huji.ac.il> X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 16:22:58 -0000 --Apple-Mail=_B858BDE2-259A-4CFE-A493-6CCC3212C605 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 3 Nov 2018, at 17:11, Daniel Braniss wrote: ... > ok, new problem, it also happens with gcc: > > when compiling the main program with flag -pg (gprof) > dlopen fails with dlerror: Service unavailable > > what magic is needed now? Usually, this occurs when you attempt to dlopen from a statically linked executable. Is this executable statically linked? -Dimitry --Apple-Mail=_B858BDE2-259A-4CFE-A493-6CCC3212C605 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCW93LXAAKCRCwXqMKLiCW oxnwAKChVroTJp9sMvR5xMr5in18UEiybACgxMMpeyBlPZU0OnRcDtqHCRvVNBY= =RzyA -----END PGP SIGNATURE----- --Apple-Mail=_B858BDE2-259A-4CFE-A493-6CCC3212C605-- From owner-freebsd-hackers@freebsd.org Sat Nov 3 16:35:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0FE210DD1F3 for ; Sat, 3 Nov 2018 16:35:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 4BA5C893A0; Sat, 3 Nov 2018 16:35:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wA3GZ8mY068859 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 3 Nov 2018 18:35:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wA3GZ8mY068859 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wA3GZ8Ht068858; Sat, 3 Nov 2018 18:35:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 3 Nov 2018 18:35:08 +0200 From: Konstantin Belousov To: Daniel Braniss Cc: Dimitry Andric , freebsd-hackers@FreeBSD.org Subject: Re: help with dl module and clang Message-ID: <20181103163508.GS5335@kib.kiev.ua> References: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> <2E58B6A3-B3E4-4266-9B40-5F3D64433460@cs.huji.ac.il> <08A14290-0A6E-4002-892E-D4254EB23076@cs.huji.ac.il> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <08A14290-0A6E-4002-892E-D4254EB23076@cs.huji.ac.il> User-Agent: Mutt/1.10.1 (2018-07-13) 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=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 16:35:28 -0000 On Sat, Nov 03, 2018 at 06:11:19PM +0200, Daniel Braniss wrote: > > > > On 3 Nov 2018, at 17:58, Daniel Braniss wrote: > > > > > > > >> On 3 Nov 2018, at 17:47, Dimitry Andric wrote: > >> > >> On 3 Nov 2018, at 15:51, Daniel Braniss wrote: > >>> > >>> I have a program that loads some modules via dlopen(), these modules call some routines > >>> which are in the main program, this works when using gcc, but with cc it does not. > >>> > >>> when compiling the main program I use -export-dynamic, and the modules link fine when compiled with > >>> gcc, but when compiling with clang/cc i get dlerror: ...Undefined symbol … > >>> BTW, when linking the main program with cc I get > >>> /usr/bin/ld: warning: cannot find entry symbol xport-dynamic; defaulting to 0000000000402140 > >> > >> Instead of using -export-dynamic (which is a linker flag) as a flag to > >> cc, try using -Wl,-export-dynamic instead. Now, the linker interprets > >> this as the -e flag, which is something totally different. > >> > > > > i had tried that before but i had -WI (upper case i) but re-reading the manual > > it should be-Wl (lower case l as in lima :-))!!!!! > > > > thanks!!!!!! > > > > and now have to try profiling (gprof) which started this mess, > > > > thanks again!! > > > > danny > > > > > >> I think this will also help with the exporting of the symbols of your > >> main program. > >> > >> -Dimitry > >> > > > ok, new problem, it also happens with gcc: > > when compiling the main program with flag -pg (gprof) > dlopen fails with dlerror: Service unavailable This means that your binary is linked statically. dlopen(3) is not supported for static linking, ld-elf.so.1 is required for dynamic loading to work. > > what magic is needed now? > > danny > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sat Nov 3 17:31:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDC0610DF04B for ; Sat, 3 Nov 2018 17:31:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B9098B0D6; Sat, 3 Nov 2018 17:31:45 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1gIzln-0009qG-82; Sat, 03 Nov 2018 19:31:35 +0200 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: help with dl module and clang Date: Sat, 3 Nov 2018 19:31:33 +0200 In-Reply-To: <20181103163508.GS5335@kib.kiev.ua> Cc: Dimitry Andric , freebsd-hackers@FreeBSD.org To: Konstantin Belousov References: <4B8101F4-9A89-4486-8DF3-93DC799EF6D4@cs.huji.ac.il> <2E58B6A3-B3E4-4266-9B40-5F3D64433460@cs.huji.ac.il> <08A14290-0A6E-4002-892E-D4254EB23076@cs.huji.ac.il> <20181103163508.GS5335@kib.kiev.ua> X-Mailer: Apple Mail (2.3445.100.39) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 17:31:46 -0000 > On 3 Nov 2018, at 18:35, Konstantin Belousov = wrote: >=20 > On Sat, Nov 03, 2018 at 06:11:19PM +0200, Daniel Braniss wrote: >>=20 >>=20 >>> On 3 Nov 2018, at 17:58, Daniel Braniss wrote: >>>=20 >>>=20 >>>=20 >>>> On 3 Nov 2018, at 17:47, Dimitry Andric wrote: >>>>=20 >>>> On 3 Nov 2018, at 15:51, Daniel Braniss = wrote: >>>>>=20 >>>>> I have a program that loads some modules via dlopen(), these = modules call some routines >>>>> which are in the main program, this works when using gcc, but with = cc it does not. >>>>>=20 >>>>> when compiling the main program I use -export-dynamic, and the = modules link fine when compiled with >>>>> gcc, but when compiling with clang/cc i get dlerror: ...Undefined = symbol =E2=80=A6 >>>>> BTW, when linking the main program with cc I get >>>>> /usr/bin/ld: warning: cannot find entry symbol xport-dynamic; = defaulting to 0000000000402140 >>>>=20 >>>> Instead of using -export-dynamic (which is a linker flag) as a flag = to >>>> cc, try using -Wl,-export-dynamic instead. Now, the linker = interprets >>>> this as the -e flag, which is something totally different. >>>>=20 >>>=20 >>> i had tried that before but i had -WI (upper case i) but re-reading = the manual >>> it should be-Wl (lower case l as in lima :-))!!!!! >>>=20 >>> thanks!!!!!! >>>=20 >>> and now have to try profiling (gprof) which started this mess, >>>=20 >>> thanks again!! >>>=20 >>> danny >>>=20 >>>=20 >>>> I think this will also help with the exporting of the symbols of = your >>>> main program. >>>>=20 >>>> -Dimitry >>>>=20 >>>=20 >> ok, new problem, it also happens with gcc: >>=20 >> when compiling the main program with flag -pg (gprof) >> dlopen fails with dlerror: Service unavailable > This means that your binary is linked statically. > dlopen(3) is not supported for static linking, ld-elf.so.1 is required > for dynamic loading to work. as far as I can tell, it=E2=80=99s NOT statically linked: l e-kots-b# ldd /vol/src/libexec/idng/idngd/idngd=20 /vol/src/libexec/idng/idngd/idngd: libpq.so.5 =3D> /usr/local/lib/libpq.so.5 (0x800932000) libcrypto.so.8 =3D> /lib/libcrypto.so.8 (0x800c00000) libldap-2.4.so.2 =3D> /usr/local/lib/libldap-2.4.so.2 = (0x801070000) libthr.so.3 =3D> /lib/libthr.so.3 (0x8012b7000) libintl.so.8 =3D> /usr/local/lib/libintl.so.8 (0x8014df000) libssl.so.8 =3D> /usr/lib/libssl.so.8 (0x8016ea000) libc.so.7 =3D> /lib/libc.so.7 (0x80195d000) liblber-2.4.so.2 =3D> /usr/local/lib/liblber-2.4.so.2 = (0x801d18000) e-kots-b# file !$ file /vol/src/libexec/idng/idngd/idngd /vol/src/libexec/idng/idngd/idngd: ELF 64-bit LSB executable, x86-64, = version 1 (FreeBSD), dynamically linked, interpreter = /libexec/ld-elf.so.1, for FreeBSD 11.2 (1102501 ), = FreeBSD-style, not stripped >=20 >>=20 >> what magic is needed now? >>=20 >> danny >>=20 >>> _______________________________________________ >>> freebsd-hackers@freebsd.org = mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers = >>> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org = " >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org = mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers = >> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org = "