From owner-freebsd-stable@freebsd.org Sun Sep 23 07:35:59 2018 Return-Path: Delivered-To: freebsd-stable@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 6771A10B0006 for ; Sun, 23 Sep 2018 07:35:59 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 0EF6593DFE for ; Sun, 23 Sep 2018 07:35:58 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1g3yvr-0005vs-R1; Sun, 23 Sep 2018 07:35:56 +0000 Date: Sun, 23 Sep 2018 09:35:55 +0200 Message-ID: From: Randy Bush To: Charles Sprickman Cc: Pete Wright , freebsd-stable@freebsd.org Subject: Re: bad hash in repo In-Reply-To: References: <40cbc4e4-c0c8-e9f7-ba88-48dc226b032a@nomadlogic.org> <8C150C27-844D-4F32-907B-8ABD7D711846@bway.net> <1D6718B0-829B-4E81-B7FD-41E4B37D6B01@bway.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 07:35:59 -0000 this problem seems to have magically cleared up, he said suspiciously randy From owner-freebsd-stable@freebsd.org Sun Sep 23 09:13:48 2018 Return-Path: Delivered-To: freebsd-stable@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 D4CEC10B154D for ; Sun, 23 Sep 2018 09:13:48 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gilb.zs64.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E291960C1 for ; Sun, 23 Sep 2018 09:13:48 +0000 (UTC) (envelope-from stb@lassitu.de) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 605842000F3 for ; Sun, 23 Sep 2018 09:13:46 +0000 (UTC) From: Stefan Bethke Content-Type: multipart/signed; boundary="Apple-Mail=_31FDEA5D-08EF-49E1-8449-FF2D6285DFDE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: if_bridge and CARP causes hangs Message-Id: Date: Sun, 23 Sep 2018 11:13:35 +0200 To: FreeBSD Stable X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 09:13:49 -0000 --Apple-Mail=_31FDEA5D-08EF-49E1-8449-FF2D6285DFDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ve just stumbled on this problem, which seems to be quite old = and still unresolved. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200319 As a quick summary: if you configure CARP on an if_bridge interface, the = CARP state changes will (always/with a high probability) create a = deadlock between CARP and the if_bridge code, leading to the machine = becoming unresponsive. There is a suggested patch, but work on it seems to be very slow: https://reviews.freebsd.org/D3133 I would love to see a fix in 11-stable or 12.0. Is there something I can = do to help move this forward? Regards, Stefan -- Stefan Bethke Fon +49 151 14070811 --Apple-Mail=_31FDEA5D-08EF-49E1-8449-FF2D6285DFDE 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----- Comment: GPGTools - https://gpgtools.org iQEzBAEBCgAdFiEEJ+hF98o4r3eU/HiPD885WK4W4sEFAlunWT8ACgkQD885WK4W 4sFOQAf/ZjMbkRtiXV9wCnfwbvy9R9+U7JrmjNy/ZV4rI7H7eEiCW2+YxEcfQsoM be7SDgcH3zAKXvWPWseVm/gIPCaHJNVq4dOr+xn0w6z2VoT0Y6gcpqgkddiuxQjF mNm8QQM+E34PmhIoL2HG6VWkvQvDAZqLMnrWSzorFZrJM9eFI95SCxxVFfuWGZ5e kpKjayAM+R7ocKbNOaZXu9ZzN8wDVj0uJzYULtEd7UDKKjhQEBLlvgGffWtqtMNW WzjycEILQfYtFXMEgsCnZSsiGm5P7L7u1I3MIUZdIJmIM7oqgh6ed50BKuUxo0JR Hjae78qyBoO2nRK+2r9B0vnyavErlg== =QmB8 -----END PGP SIGNATURE----- --Apple-Mail=_31FDEA5D-08EF-49E1-8449-FF2D6285DFDE-- From owner-freebsd-stable@freebsd.org Sun Sep 23 21:00:36 2018 Return-Path: Delivered-To: freebsd-stable@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 520E21097C22 for ; Sun, 23 Sep 2018 21:00:36 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E659482838 for ; Sun, 23 Sep 2018 21:00:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id A90E21097C14; Sun, 23 Sep 2018 21:00:35 +0000 (UTC) Delivered-To: stable@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 9808C1097C13 for ; Sun, 23 Sep 2018 21:00:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F08382833 for ; Sun, 23 Sep 2018 21:00:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 9BB281C742 for ; Sun, 23 Sep 2018 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w8NL0Ya0019737 for ; Sun, 23 Sep 2018 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w8NL0YRm019734 for stable@FreeBSD.org; Sun, 23 Sep 2018 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201809232100.w8NL0YRm019734@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: stable@FreeBSD.org Subject: Problem reports for stable@FreeBSD.org that need special attention Date: Sun, 23 Sep 2018 21:00:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2018 21:00:36 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 230620 | "install -d" issue Open | 227213 | FreeBSD 10.4 kernel deadlocks on sysctlmemlock 2 problems total for which you should take action. From owner-freebsd-stable@freebsd.org Mon Sep 24 13:51:28 2018 Return-Path: Delivered-To: freebsd-stable@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 85C1510ACBC4 for ; Mon, 24 Sep 2018 13:51:28 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr [80.12.242.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 060DF8178F for ; Mon, 24 Sep 2018 13:51:27 +0000 (UTC) (envelope-from clbuisson@orange.fr) Received: from localhost ([92.134.114.191]) by mwinf5d56 with ME id fRrR1y01B47q9Nc03RrSsW; Mon, 24 Sep 2018 15:51:26 +0200 X-ME-Helo: localhost X-ME-Auth: Y2xidWlzc29uQHdhbmFkb28uZnI= X-ME-Date: Mon, 24 Sep 2018 15:51:26 +0200 X-ME-IP: 92.134.114.191 To: FreeBSD-STABLE Mailing List , oshogbo@FreeBSD.org From: Claude Buisson Subject: traceroute -n difference between STABLE-11 and CURRENT Message-ID: <4c75a92e-e107-9a77-aff5-fd914c7527b9@orange.fr> Date: Mon, 24 Sep 2018 15:51:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 13:51:28 -0000 Hello, On systems with STABLE-11 @ r338696, I found that traceroute -n ... led to: traceroute: cap_enter: Function not implemented I rebuilt the systems with WITHOUT_CASPER commented in /etc/src.conf and (to be safe ?) CAPABILITY_MODE CAPABILITIES uncommented in the kernel definitions And traceroute -n can now be successfully used. Being curious, I traced this behaviour to r338475 by oshogbo, which is documented as a MFC of r314000 BUT i NEVER met this problem on my CURRENT systems which are now at r338331 (so after r314000), and are built WITHOUT_CASPER and without CAPABILITY_MODE nor CAPABILITIES in their kernel definitions. What am I missing (my only hint being the change from HAVE_LIBCASPER to WITH_CASPER) ? CBu From owner-freebsd-stable@freebsd.org Mon Sep 24 14:38:14 2018 Return-Path: Delivered-To: freebsd-stable@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 B262A10ADE51; Mon, 24 Sep 2018 14:38:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [IPv6:2607:f3e0:80:80::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smarthost2.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 504CF8360B; Mon, 24 Sep 2018 14:38:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5:0:0:0:11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id w8OEcDk4072040 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Sep 2018 10:38:13 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id w8OEcBec053821; Mon, 24 Sep 2018 10:38:12 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: Good motherboard for Ryzen (first-gen) To: Eric van Gyzen , freebsd-stable@FreeBSD.org, freebsd-current@freebsd.org References: <205656c3-52a5-a75f-c352-8bf923b47b1f@vangyzen.net> From: Mike Tancsa Openpgp: preference=signencrypt Autocrypt: addr=mike@sentex.net; prefer-encrypt=mutual; keydata= xsBNBEzcA24BCACpwI/iqOrs0GfQSfhA1v6Z8AcXVeGsRyKEKUpxoOYxXWc2z3vndbYlIP6E YJeifzKhS/9E+VjhhICaepLHfw865TDTUPr5D0Ed+edSsKjlnDtb6hfNJC00P7eoiuvi85TW F/gAxRY269A5d856bYrzLbkWp2lKUR3Bg6NnORtflGzx9ZWAltZbjYjjRqegPv0EQNYcHqWo eRpXilEo1ahT6nmOU8V7yEvT2j4wlLcQ6qg7w+N/vcBvyd/weiwHU+vTQ9mT61x5/wUrQhdw 2gJHeQXeDGMJV49RT2EEz+QVxaf477eyWsdQzPVjAKRMT3BVdK8WvpYAEfBAbXmkboOxABEB AAHNHG1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5jYT7CwHgEEwECACIFAkzcA24CGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEJXHwM2kc8rX+sMH/2V6pTBKsQ5mpWWLgs6wVP2k BC+6r/YKNXv9Rw/PrC6+9hTbgA+sSjJ+8gxsCbJsOQXZrxF0x3l9oYdYfuKcwdwXFX1/FS8p HfBeDkmlH+dI709xT9wgrR4dS5aMmKp0scPrXPIAKiYVOHjOlNItcLYTEEWEFBepheEVsgmk GrNbcrHwOx/u4igUQ8vcpyXPyUki+BsftPw8ZQvBU887igh0OxaCR8AurJppQ5UQd63r81cX E1ZjoFoWCaGK/SjPb/OhpYpu5swoZIhOxQbn7OtakYPsDd5t2A5KhvjI8BMTnd5Go+2xsCmr jlIEq8Bi29gCcfQUvNiClevi13ifmnnOwE0ETNwDbgEIALWGNJHRAhpd0A4vtd3G0oRqMBcM FGThQr3qORmEBTPPEomTdBaHcn+Xl+3YUvTBD/67/mutWBwgp2R5gQOSqcM7axvgMSHbKqBL 9sd1LsLw0UT2O5AYxv3EwzhG84pwRg3XcUqvWA4lA8tIj/1q4Jzi5qOkg1zxq4W9qr9oiYK5 bBR638JUvr3eHMaz/Nz+sDVFgwHmXZj3M6aE5Ce9reCGbvrae7H5D5PPvtT3r22X8SqfVAiO TFKedCf/6jbSOedPN931FJQYopj9P6b3m0nI3ZiCDVSqeyOAIBLzm+RBUIU3brzoxDhYR8pz CJc2sK8l6YjqivPakrD86bFDff8AEQEAAcLAXwQYAQIACQUCTNwDbgIbDAAKCRCVx8DNpHPK 1+iQB/99aqNtez9ZTBWELj269La8ntuRx6gCpzfPXfn6SDIfTItDxTh1hrdRVP5QNGGF5wus N4EMwXouskva1hbFX3Pv72csYSxxEJXjW16oV8WK4KjKXoskLg2RyRP4uXqL7Mp2ezNtVY5F 9nu3fj4ydpHCSaqKy5xd70A8D50PfZsFgkrsa5gdQhPiGGEdxhq/XSeAAnZ4uVLJKarH+mj5 MEhgZPEBWkGrbDZpezl9qbFcUem/uT9x8FYT/JIztMVh9qDcdP5tzANW5J7nvgXjska+VFGY ryZK4SPDczh74mn6GI/+RBi7OUzXXPgpPBrhS5FByjwCqjjsSpTjTds+NGIY Organization: Sentex Communications Message-ID: <6aff1e34-d9b6-0c1a-bb23-ff64c81a7082@sentex.net> Date: Mon, 24 Sep 2018 10:38:12 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <205656c3-52a5-a75f-c352-8bf923b47b1f@vangyzen.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.83 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 14:38:14 -0000 On 9/21/2018 10:53 PM, Eric van Gyzen wrote: > I would like to build a Ryzen desktop.  Can anyone recommend a good > motherboard? I like the ASUS X370-PRO (currently BIOS 04/19/2018). igb0 for the onboard nic igb0@pci0:7:0:0: class=0x020000 card=0x85f01043 chip=0x15398086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I211 Gigabit Network Connection' and its been VERY stable since the various microcode updates and OS updates went in. (0x8001137) CPU: AMD Ryzen 5 1600X Six-Core Processor (3593.34-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 Features=0x178bfbff Features2=0x7ed8320b AMD Features=0x2e500800 AMD Features2=0x35c233ff Structured Extended Features=0x209c01a9 XSAVE Features=0xf AMD Extended Feature Extensions ID EBX=0x1007 SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33226657792 (31687 MB) ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada From owner-freebsd-stable@freebsd.org Mon Sep 24 22:03:47 2018 Return-Path: Delivered-To: freebsd-stable@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 86A601093431 for ; Mon, 24 Sep 2018 22:03:47 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F29CB747A9 for ; Mon, 24 Sep 2018 22:03:46 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 477A8139B9; Tue, 25 Sep 2018 00:03:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 5Qb9-9Ya995X; Tue, 25 Sep 2018 00:03:33 +0200 (CEST) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 38E47139B3; Tue, 25 Sep 2018 00:03:33 +0200 (CEST) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 16AAE111; Tue, 25 Sep 2018 00:03:33 +0200 (CEST) Message-ID: <5BA95F34.9070300@incore.de> Date: Tue, 25 Sep 2018 00:03:32 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-stable@freebsd.org Subject: Re: Constraints in libmap(32).conf do not work as expected, possible bug in rtld-elf References: <5B89C1E7.4090002@incore.de> <20180902120603.GI2340@kib.kiev.ua> <5B9829FE.10700@incore.de> <20180921134833.GU3161@kib.kiev.ua> In-Reply-To: <20180921134833.GU3161@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2018 22:03:47 -0000 > > Can you try this instead ? > Yes I did on a server running FreeBSD 12.0-CURRENT (GENERIC) #0 r337452 and - after a trivial adaptation of your patch - on FreeBSD 10.4-STABLE #0 r337823 and everything works correct. My simple libmap32.conf now is: ## php52 [/usr/local/php52/] /usr/local/lib /usr/local/lib32 /usr/local/lib/mysql /usr/local/lib32/mysql [libc-client4.so.9] libssl.so.8 libssl.so.6 libcrypto.so.8 libcrypto.so.6 My test command "/usr/local/php52/bin/php -i" loads also all the shared objects in /usr/local/php52/lib/php/20060613: gettext.so iconv.so imap.so mbstring.so mcrypt.so mysql.so pcre.so session.so xml.so. Further ldd gives correct output for every mentioned file. I like to mention one thing concerning the source libmap.c. With the patch (yours or mine) and the libmap32.conf given above I see the following lmp_list when lm_fini() is called: lm_fini("1, $DEFAULT$" lml-Adresse 0x2826c208) lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") lm_fini("f=libssl.so.8, t=libssl.so.6") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("1, libc-client4.so.9" lml-Adresse 0x2826c168) lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") lm_fini("f=libssl.so.8, t=libssl.so.6") lm_fini("2, /usr/local/php52/" lml-Adresse 0x2826c068) lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") So for $DEFAULTS we have a lot of identical entries. This comes from the TAILQ_INSERT_HEAD statement in lm_add(). I am not sure if this can be accepted or a check to avoid double entries in the list is better. One annotation to the script /etc/rc.d/ldconfig: I had expected that this script during boot creates clean files ld-elf(32).so.hints in /var/run. For 64 bit this is true, but for 32 bit not because ldconfig with flag -32 also has flag -m. Is this intended behaviour ? Andreas Longwitz From owner-freebsd-stable@freebsd.org Tue Sep 25 15:54:29 2018 Return-Path: Delivered-To: freebsd-stable@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 B539A10B4F45 for ; Tue, 25 Sep 2018 15:54:29 +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 EECB2768CD for ; Tue, 25 Sep 2018 15:54:28 +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 w8PFsHBg051057 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Sep 2018 18:54:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w8PFsHBg051057 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w8PFsHU8051056; Tue, 25 Sep 2018 18:54:17 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Sep 2018 18:54:17 +0300 From: Konstantin Belousov To: Andreas Longwitz Cc: freebsd-stable@freebsd.org Subject: Re: Constraints in libmap(32).conf do not work as expected, possible bug in rtld-elf Message-ID: <20180925155417.GA5335@kib.kiev.ua> References: <5B89C1E7.4090002@incore.de> <20180902120603.GI2340@kib.kiev.ua> <5B9829FE.10700@incore.de> <20180921134833.GU3161@kib.kiev.ua> <5BA95F34.9070300@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BA95F34.9070300@incore.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 15:54:29 -0000 On Tue, Sep 25, 2018 at 12:03:32AM +0200, Andreas Longwitz wrote: > > > > Can you try this instead ? > > > Yes I did on a server running FreeBSD 12.0-CURRENT (GENERIC) #0 r337452 > and - after a trivial adaptation of your patch - on FreeBSD 10.4-STABLE > #0 r337823 and everything works correct. > > My simple libmap32.conf now is: > > ## php52 > [/usr/local/php52/] > /usr/local/lib /usr/local/lib32 > /usr/local/lib/mysql /usr/local/lib32/mysql > > [libc-client4.so.9] > libssl.so.8 libssl.so.6 > libcrypto.so.8 libcrypto.so.6 > > My test command "/usr/local/php52/bin/php -i" loads also all the shared > objects in /usr/local/php52/lib/php/20060613: gettext.so iconv.so > imap.so mbstring.so mcrypt.so mysql.so pcre.so session.so xml.so. > Further ldd gives correct output for every mentioned file. Thanks. > > I like to mention one thing concerning the source libmap.c. With the > patch (yours or mine) and the libmap32.conf given above I see the > following lmp_list when lm_fini() is called: > > lm_fini("1, $DEFAULT$" lml-Adresse 0x2826c208) > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") > lm_fini("f=libssl.so.8, t=libssl.so.6") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > lm_fini("1, libc-client4.so.9" lml-Adresse 0x2826c168) > lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") > lm_fini("f=libssl.so.8, t=libssl.so.6") > lm_fini("2, /usr/local/php52/" lml-Adresse 0x2826c068) > lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") > lm_fini("f=/usr/local/lib, t=/usr/local/lib32") > > So for $DEFAULTS we have a lot of identical entries. This comes from the > TAILQ_INSERT_HEAD statement in lm_add(). I am not sure if this can be > accepted or a check to avoid double entries in the list is better. Yes, this is mostly cosmetics. It is not clear is it better to avoid duplicates and pay the cost at insertion, or leave them and pay at the list traversal. I think there is slight preference to avoid dups, but this should be not measureable. There is a second caller of lm_add(), but there the dup should be user-caused. > > One annotation to the script /etc/rc.d/ldconfig: I had expected that > this script during boot creates clean files ld-elf(32).so.hints in > /var/run. For 64 bit this is true, but for 32 bit not because ldconfig > with flag -32 also has flag -m. Is this intended behaviour ? This seems to be from the beginning when ldconfig_local32 was introduced in r154114. Combined patch below. diff --git a/libexec/rtld-elf/libmap.c b/libexec/rtld-elf/libmap.c index 592b7664eea..33c824a65af 100644 --- a/libexec/rtld-elf/libmap.c +++ b/libexec/rtld-elf/libmap.c @@ -353,6 +353,7 @@ lm_add(const char *p, const char *f, const char *t) { struct lm_list *lml; struct lm *lm; + const char *t1; if (p == NULL) p = "$DEFAULT$"; @@ -362,11 +363,14 @@ lm_add(const char *p, const char *f, const char *t) if ((lml = lmp_find(p)) == NULL) lml = lmp_init(xstrdup(p)); - lm = xmalloc(sizeof(struct lm)); - lm->f = xstrdup(f); - lm->t = xstrdup(t); - TAILQ_INSERT_HEAD(lml, lm, lm_link); - lm_count++; + t1 = lml_find(lml, f); + if (t1 == NULL || strcmp(t1, t) != 0) { + lm = xmalloc(sizeof(struct lm)); + lm->f = xstrdup(f); + lm->t = xstrdup(t); + TAILQ_INSERT_HEAD(lml, lm, lm_link); + lm_count++; + } } char * diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c index dfd0388478f..83d5e28e287 100644 --- a/libexec/rtld-elf/rtld.c +++ b/libexec/rtld-elf/rtld.c @@ -125,7 +125,7 @@ static void objlist_remove(Objlist *, Obj_Entry *); static int open_binary_fd(const char *argv0, bool search_in_path); static int parse_args(char* argv[], int argc, bool *use_pathp, int *fdp); static int parse_integer(const char *); -static void *path_enumerate(const char *, path_enum_proc, void *); +static void *path_enumerate(const char *, path_enum_proc, const char *, void *); static void print_usage(const char *argv0); static void release_object(Obj_Entry *); static int relocate_object_dag(Obj_Entry *root, bool bind_now, @@ -140,7 +140,8 @@ static int rtld_dirname(const char *, char *); static int rtld_dirname_abs(const char *, char *); static void *rtld_dlopen(const char *name, int fd, int mode); static void rtld_exit(void); -static char *search_library_path(const char *, const char *, int *); +static char *search_library_path(const char *, const char *, const char *, + int *); static char *search_library_pathfds(const char *, const char *, int *); static const void **get_program_var_addr(const char *, RtldLockState *); static void set_program_var(const char *, const void *); @@ -1576,8 +1577,7 @@ gnu_hash(const char *s) static char * find_library(const char *xname, const Obj_Entry *refobj, int *fdp) { - char *pathname; - char *name; + char *name, *pathname, *refobj_path; bool nodeflib, objgiven; objgiven = refobj != NULL; @@ -1597,6 +1597,7 @@ find_library(const char *xname, const Obj_Entry *refobj, int *fdp) } dbg(" Searching for \"%s\"", name); + refobj_path = objgiven ? refobj->path : NULL; /* * If refobj->rpath != NULL, then refobj->runpath is NULL. Fall @@ -1605,52 +1606,61 @@ find_library(const char *xname, const Obj_Entry *refobj, int *fdp) * nodeflib. */ if (objgiven && refobj->rpath != NULL && ld_library_path_rpath) { - pathname = search_library_path(name, ld_library_path, fdp); + pathname = search_library_path(name, ld_library_path, + refobj_path, fdp); if (pathname != NULL) return (pathname); if (refobj != NULL) { - pathname = search_library_path(name, refobj->rpath, fdp); + pathname = search_library_path(name, refobj->rpath, + refobj_path, fdp); if (pathname != NULL) return (pathname); } pathname = search_library_pathfds(name, ld_library_dirs, fdp); if (pathname != NULL) return (pathname); - pathname = search_library_path(name, gethints(false), fdp); + pathname = search_library_path(name, gethints(false), + refobj_path, fdp); if (pathname != NULL) return (pathname); - pathname = search_library_path(name, ld_standard_library_path, fdp); + pathname = search_library_path(name, ld_standard_library_path, + refobj_path, fdp); if (pathname != NULL) return (pathname); } else { nodeflib = objgiven ? refobj->z_nodeflib : false; if (objgiven) { - pathname = search_library_path(name, refobj->rpath, fdp); + pathname = search_library_path(name, refobj->rpath, + refobj->path, fdp); if (pathname != NULL) return (pathname); } if (objgiven && refobj->runpath == NULL && refobj != obj_main) { - pathname = search_library_path(name, obj_main->rpath, fdp); + pathname = search_library_path(name, obj_main->rpath, + refobj_path, fdp); if (pathname != NULL) return (pathname); } - pathname = search_library_path(name, ld_library_path, fdp); + pathname = search_library_path(name, ld_library_path, + refobj_path, fdp); if (pathname != NULL) return (pathname); if (objgiven) { - pathname = search_library_path(name, refobj->runpath, fdp); + pathname = search_library_path(name, refobj->runpath, + refobj_path, fdp); if (pathname != NULL) return (pathname); } pathname = search_library_pathfds(name, ld_library_dirs, fdp); if (pathname != NULL) return (pathname); - pathname = search_library_path(name, gethints(nodeflib), fdp); + pathname = search_library_path(name, gethints(nodeflib), + refobj_path, fdp); if (pathname != NULL) return (pathname); if (objgiven && !nodeflib) { pathname = search_library_path(name, - ld_standard_library_path, fdp); + ld_standard_library_path, refobj_path, fdp); if (pathname != NULL) return (pathname); } @@ -1845,8 +1855,9 @@ gethints(bool nostdlib) hargs.request = RTLD_DI_SERINFOSIZE; hargs.serinfo = &hmeta; - path_enumerate(ld_standard_library_path, fill_search_info, &sargs); - path_enumerate(hints, fill_search_info, &hargs); + path_enumerate(ld_standard_library_path, fill_search_info, NULL, + &sargs); + path_enumerate(hints, fill_search_info, NULL, &hargs); SLPinfo = xmalloc(smeta.dls_size); hintinfo = xmalloc(hmeta.dls_size); @@ -1864,8 +1875,9 @@ gethints(bool nostdlib) hargs.serpath = &hintinfo->dls_serpath[0]; hargs.strspace = (char *)&hintinfo->dls_serpath[hmeta.dls_cnt]; - path_enumerate(ld_standard_library_path, fill_search_info, &sargs); - path_enumerate(hints, fill_search_info, &hargs); + path_enumerate(ld_standard_library_path, fill_search_info, NULL, + &sargs); + path_enumerate(hints, fill_search_info, NULL, &hargs); /* * Now calculate the difference between two sets, by excluding @@ -2974,7 +2986,8 @@ rtld_exit(void) * callback on the result. */ static void * -path_enumerate(const char *path, path_enum_proc callback, void *arg) +path_enumerate(const char *path, path_enum_proc callback, + const char *refobj_path, void *arg) { const char *trans; if (path == NULL) @@ -2986,7 +2999,7 @@ path_enumerate(const char *path, path_enum_proc callback, void *arg) char *res; len = strcspn(path, ":;"); - trans = lm_findn(NULL, path, len); + trans = lm_findn(refobj_path, path, len); if (trans) res = callback(trans, strlen(trans), arg); else @@ -3045,7 +3058,8 @@ try_library_path(const char *dir, size_t dirlen, void *param) } static char * -search_library_path(const char *name, const char *path, int *fdp) +search_library_path(const char *name, const char *path, + const char *refobj_path, int *fdp) { char *p; struct try_library_args arg; @@ -3059,7 +3073,7 @@ search_library_path(const char *name, const char *path, int *fdp) arg.buflen = PATH_MAX; arg.fd = -1; - p = path_enumerate(path, try_library_path, &arg); + p = path_enumerate(path, try_library_path, refobj_path, &arg); *fdp = arg.fd; free(arg.buffer); @@ -3776,12 +3790,12 @@ do_search_info(const Obj_Entry *obj, int request, struct dl_serinfo *info) _info.dls_size = __offsetof(struct dl_serinfo, dls_serpath); _info.dls_cnt = 0; - path_enumerate(obj->rpath, fill_search_info, &args); - path_enumerate(ld_library_path, fill_search_info, &args); - path_enumerate(obj->runpath, fill_search_info, &args); - path_enumerate(gethints(obj->z_nodeflib), fill_search_info, &args); + path_enumerate(obj->rpath, fill_search_info, NULL, &args); + path_enumerate(ld_library_path, fill_search_info, NULL, &args); + path_enumerate(obj->runpath, fill_search_info, NULL, &args); + path_enumerate(gethints(obj->z_nodeflib), fill_search_info, NULL, &args); if (!obj->z_nodeflib) - path_enumerate(ld_standard_library_path, fill_search_info, &args); + path_enumerate(ld_standard_library_path, fill_search_info, NULL, &args); if (request == RTLD_DI_SERINFOSIZE) { @@ -3801,25 +3815,25 @@ do_search_info(const Obj_Entry *obj, int request, struct dl_serinfo *info) args.strspace = (char *)&info->dls_serpath[_info.dls_cnt]; args.flags = LA_SER_RUNPATH; - if (path_enumerate(obj->rpath, fill_search_info, &args) != NULL) + if (path_enumerate(obj->rpath, fill_search_info, NULL, &args) != NULL) return (-1); args.flags = LA_SER_LIBPATH; - if (path_enumerate(ld_library_path, fill_search_info, &args) != NULL) + if (path_enumerate(ld_library_path, fill_search_info, NULL, &args) != NULL) return (-1); args.flags = LA_SER_RUNPATH; - if (path_enumerate(obj->runpath, fill_search_info, &args) != NULL) + if (path_enumerate(obj->runpath, fill_search_info, NULL, &args) != NULL) return (-1); args.flags = LA_SER_CONFIG; - if (path_enumerate(gethints(obj->z_nodeflib), fill_search_info, &args) + if (path_enumerate(gethints(obj->z_nodeflib), fill_search_info, NULL, &args) != NULL) return (-1); args.flags = LA_SER_DEFAULT; - if (!obj->z_nodeflib && - path_enumerate(ld_standard_library_path, fill_search_info, &args) != NULL) + if (!obj->z_nodeflib && path_enumerate(ld_standard_library_path, + fill_search_info, NULL, &args) != NULL) return (-1); return (0); } diff --git a/sbin/init/rc.d/ldconfig b/sbin/init/rc.d/ldconfig index 3af9562d3bf..4dabe03e28c 100755 --- a/sbin/init/rc.d/ldconfig +++ b/sbin/init/rc.d/ldconfig @@ -58,7 +58,7 @@ ldconfig_start() done check_startmsgs && echo '32-bit compatibility ldconfig path:' ${_LDC} - ${ldconfig} -32 -m ${_ins} ${_LDC} + ${ldconfig} -32 ${_ins} ${_LDC} ;; esac From owner-freebsd-stable@freebsd.org Tue Sep 25 19:01:34 2018 Return-Path: Delivered-To: freebsd-stable@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 7913710B8A73 for ; Tue, 25 Sep 2018 19:01:34 +0000 (UTC) (envelope-from andrea.jones@impulsive-search-level.com) Received: from mars.pam.lflink.com (mars.pam.lflink.com [80.211.80.63]) (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 0D13B7D20D for ; Tue, 25 Sep 2018 19:01:33 +0000 (UTC) (envelope-from andrea.jones@impulsive-search-level.com) Received: from WS58 (unknown [106.201.22.112]) by mars.pam.lflink.com (Postfix) with ESMTPA id A5B1D5124 for ; Tue, 25 Sep 2018 15:01:23 -0400 (EDT) From: "Andrea Jones" To: Subject: Pay only when you get Results... Date: Wed, 26 Sep 2018 00:31:18 +0530 Message-ID: <1e9d801d45502$2d296490$877c2db0$@impulsive-search-level.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdRUw4ZIidKuqO9hTlqTGsl5Yn6VNg== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 19:01:34 -0000 Hi, Another summer has gone, and you are still waiting to see your website on the top of search results. Before you take another season to decide, I want to help you reach a conclusion. If you're not ranking on search, your business is losing 74 % customers that are using a search engine for consideration and purchasing. We are a trusted Digital marketing company with a decade-and-a-half of experience, can help your success graphs go off the charts. We have a unique Pay-For-Performance model, as you PAY ONLY WHEN YOUR KEYWORDS RANK. - No monthly fee / No contractual payout - FREE website analysis report. - Dedicated 24*7 support. - Only one time set up fee Reply to this email along with your contact details and we will hop on a call to get things going. Thanks & Regards, Andrea Jones Marketing Manager Head Office: San Jose, CA 95120 Disclaimer: We are using this domain for marketing. If you are interested and want to know about us, just reply to this email, if we have offended you by sending this to you by mistake, we apologize. Please reply "NO" or "UNSUBSCRIBE" to this email if not interested, so that we shall add you to our "Do Not Contact Again" list. From owner-freebsd-stable@freebsd.org Wed Sep 26 15:05:07 2018 Return-Path: Delivered-To: freebsd-stable@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 D143E10AF2E8 for ; Wed, 26 Sep 2018 15:05:06 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F9F28155B for ; Wed, 26 Sep 2018 15:05:06 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 778F6139DA; Wed, 26 Sep 2018 17:04:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id 1gAFL0NtHvQf; Wed, 26 Sep 2018 17:04:56 +0200 (CEST) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id C2273139BB; Wed, 26 Sep 2018 17:04:55 +0200 (CEST) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.local.incore (Postfix) with ESMTP id A0EED108; Wed, 26 Sep 2018 17:04:55 +0200 (CEST) Message-ID: <5BABA017.9090509@incore.de> Date: Wed, 26 Sep 2018 17:04:55 +0200 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-stable@freebsd.org Subject: Re: Constraints in libmap(32).conf do not work as expected, possible bug in rtld-elf References: <5B89C1E7.4090002@incore.de> <20180902120603.GI2340@kib.kiev.ua> <5B9829FE.10700@incore.de> <20180921134833.GU3161@kib.kiev.ua> <5BA95F34.9070300@incore.de> <20180925155417.GA5335@kib.kiev.ua> In-Reply-To: <20180925155417.GA5335@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 15:05:07 -0000 >> I like to mention one thing concerning the source libmap.c. With the >> patch (yours or mine) and the libmap32.conf given above I see the >> following lmp_list when lm_fini() is called: >> >> lm_fini("1, $DEFAULT$" lml-Adresse 0x2826c208) >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") >> lm_fini("f=libssl.so.8, t=libssl.so.6") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> lm_fini("1, libc-client4.so.9" lml-Adresse 0x2826c168) >> lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") >> lm_fini("f=libssl.so.8, t=libssl.so.6") >> lm_fini("2, /usr/local/php52/" lml-Adresse 0x2826c068) >> lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") >> lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> >> So for $DEFAULTS we have a lot of identical entries. This comes from the >> TAILQ_INSERT_HEAD statement in lm_add(). I am not sure if this can be >> accepted or a check to avoid double entries in the list is better. > Yes, this is mostly cosmetics. It is not clear is it better to avoid > duplicates and pay the cost at insertion, or leave them and pay at the > list traversal. I think there is slight preference to avoid dups, but > this should be not measureable. With your patch for libmap.c the output in lm_fini() now looks fine: lm_fini("1, $DEFAULT$" lml-Adresse 0x2826c208) lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") lm_fini("f=libssl.so.8, t=libssl.so.6") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") lm_fini("1, libc-client4.so.9" lml-Adresse 0x2826c168) lm_fini("f=libcrypto.so.8, t=libcrypto.so.6") lm_fini("f=libssl.so.8, t=libssl.so.6") lm_fini("2, /usr/local/php52/" lml-Adresse 0x2826c068) lm_fini("f=/usr/local/lib/mysql, t=/usr/local/lib32/mysql") lm_fini("f=/usr/local/lib, t=/usr/local/lib32") >> One annotation to the script /etc/rc.d/ldconfig: I had expected that >> this script during boot creates clean files ld-elf(32).so.hints in >> /var/run. For 64 bit this is true, but for 32 bit not because ldconfig >> with flag -32 also has flag -m. Is this intended behaviour ? > > This seems to be from the beginning when ldconfig_local32 was > introduced in r154114. Ok Andreas Longwitz From owner-freebsd-stable@freebsd.org Wed Sep 26 21:39:35 2018 Return-Path: Delivered-To: freebsd-stable@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 2B9FB10B7141 for ; Wed, 26 Sep 2018 21:39:35 +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 8CCDF8F6E2 for ; Wed, 26 Sep 2018 21:39:34 +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 w8QLdJAh063480 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Sep 2018 00:39:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w8QLdJAh063480 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w8QLdJAi063479; Thu, 27 Sep 2018 00:39:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 27 Sep 2018 00:39:19 +0300 From: Konstantin Belousov To: Andreas Longwitz Cc: freebsd-stable@freebsd.org Subject: Re: Constraints in libmap(32).conf do not work as expected, possible bug in rtld-elf Message-ID: <20180926213919.GO5335@kib.kiev.ua> References: <5B89C1E7.4090002@incore.de> <20180902120603.GI2340@kib.kiev.ua> <5B9829FE.10700@incore.de> <20180921134833.GU3161@kib.kiev.ua> <5BA95F34.9070300@incore.de> <20180925155417.GA5335@kib.kiev.ua> <5BABA017.9090509@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5BABA017.9090509@incore.de> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 21:39:35 -0000 On Wed, Sep 26, 2018 at 05:04:55PM +0200, Andreas Longwitz wrote: > >> One annotation to the script /etc/rc.d/ldconfig: I had expected that > >> this script during boot creates clean files ld-elf(32).so.hints in > >> /var/run. For 64 bit this is true, but for 32 bit not because ldconfig > >> with flag -32 also has flag -m. Is this intended behaviour ? > > > > This seems to be from the beginning when ldconfig_local32 was > > introduced in r154114. See https://reviews.freebsd.org/D17331 From owner-freebsd-stable@freebsd.org Thu Sep 27 20:09:36 2018 Return-Path: Delivered-To: freebsd-stable@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 71A6010B7EDB for ; Thu, 27 Sep 2018 20:09:36 +0000 (UTC) (envelope-from ldowney@ccsd.k12.wy.us) Received: from district2.ccsd.k12.wy.us (district2.ccsd.k12.wy.us [146.166.180.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Barracuda/emailAddress=sales@barracuda.com", Issuer "Barracuda/emailAddress=sales@barracuda.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D12274D22 for ; Thu, 27 Sep 2018 20:09:35 +0000 (UTC) (envelope-from ldowney@ccsd.k12.wy.us) X-ASG-Debug-ID: 1538078966-09ab0b132825fa90001-BIHDGU Received: from district.ccsd.k12.wy.us (FCIS.ccsd.k12.wy.us [146.166.180.102]) by district2.ccsd.k12.wy.us with ESMTP id 2pCluqUFMNc9UAKc for ; Thu, 27 Sep 2018 14:09:26 -0600 (MDT) X-Barracuda-Envelope-From: ldowney@ccsd.k12.wy.us X-Barracuda-Effective-Source-IP: FCIS.ccsd.k12.wy.us[146.166.180.102] X-Barracuda-Apparent-Source-IP: 146.166.180.102 Message-id: X-FC-Thread-ID: 3b9aca00-29a3ff0e Date: Thu, 27 Sep 2018 14:09:25 -0600 Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-18:12.mem X-Mailer: FirstClass 16.1 (build 16.106) X-ASG-Orig-Subj: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-18:12.mem X-FC-Icon-ID: 2032 X-FC-SERVER-TZ: 9175780 X-FC-MachineGenerated: true To: freebsd-stable@freebsd.org From: "Lyla Downey" MIME-Version: 1.0 X-Barracuda-Connect: FCIS.ccsd.k12.wy.us[146.166.180.102] X-Barracuda-Start-Time: 1538078966 X-Barracuda-URL: https://146.166.180.100:443/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at ccsd.k12.wy.us X-Barracuda-Scan-Msg-Size: 857 X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.58494 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 20:09:36 -0000 Lyla has retired from CCSD#1. You can stop sending her emails. Thank you. From owner-freebsd-stable@freebsd.org Thu Sep 27 20:31:16 2018 Return-Path: Delivered-To: freebsd-stable@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 5D9A810B94BB for ; Thu, 27 Sep 2018 20:31:16 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 009E676547 for ; Thu, 27 Sep 2018 20:31:15 +0000 (UTC) (envelope-from jonc@chen.org.nz) Received: by mail-vk1-xa31.google.com with SMTP id q184-v6so913496vke.7 for ; Thu, 27 Sep 2018 13:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chen-org-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KjvGNCmgLROH6W5Y4mMeEPQ30y+YqbIEMZaYW3VGYik=; b=ZrcuOsCkYUG9wDM9pru6GKZ9aVuoKalJ94U6H2xtPqLMbBKpl9BNWWRDMB+sGUNZ/S bIowBn9jubT7JkWZKenVOsrQlXa11QWlEZjqHptwIJrA59E9iW3xGsaSSMDXbHRVTi8v VEmx4BqiLqkOMwqIethlYOPHZIm6lvdU7sMZnZyIyvpPsT9b6WwcSFeGFC4tEbFhWed8 /+ZO8Kj4Y+YKPcf1k+YIo6RCzpJnwVPOO4jmeiE8M1a4+cc5jipdcpbnwcfY2CfXlN6I hDVEuXdJQTFK8LkLtkyPiUzF0Pn0yHIyUHhDTm7i42m8urA47aL98htCZfp/dpVoW1Yo rMeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KjvGNCmgLROH6W5Y4mMeEPQ30y+YqbIEMZaYW3VGYik=; b=gK1rr8U8YjWHJYjeGbGqqz8wFPUWGOF9NFcoz5/XsafB4hNRvRXH72YF7cqVP3r+Xh bRQYu8/KBYuY4tjlXw6TeDuCRSlui6H1YE7mS5IaFazl8xViFPZHay49UcaftoAFZKo/ q7Nf/flD5zTb8l7As0ZjR60HMSKLPUQpq3vtmhrDMcT0rzvpwuzM13zkU6frrGbBag2N nsW+lZeT4sWZ5KlouP+CelU1huOvbxGRm7zLilwzA3k1satUONo2lD7+7umnWV6MNuFc Sf/6ai+V1J+WIb2wJ38QEt3E0ceudewLaIW96QZtDzhuzvgvU8d0gKGuU6SpryaqNtM/ J3MA== X-Gm-Message-State: ABuFfogsntjXCFfoecR/BNG2AwiRa548VSe7nZEflOyJUppMnA7Qncts OkbNRQ/b9h/WuC1glsF7vF3NK9FAZLAw2FDwxJLlZlyrsHI= X-Google-Smtp-Source: ACcGV63wvY/QNPegjuDE4COKgQr0rpxdywpCPyTobjVfsiy2peyhIdtBOX6/YIurxujAReqRCG43O6akAvxwitjONa4= X-Received: by 2002:a1f:9704:: with SMTP id z4-v6mr4348018vkd.3.1538080274561; Thu, 27 Sep 2018 13:31:14 -0700 (PDT) MIME-Version: 1.0 References: <20180927200857.7609714B80@freefall.freebsd.org> In-Reply-To: <20180927200857.7609714B80@freefall.freebsd.org> From: Jonathan Chen Date: Fri, 28 Sep 2018 08:31:03 +1200 Message-ID: Subject: Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-18:12.mem To: freebsd-stable@freebsd.org Cc: errata-notices@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 20:31:16 -0000 On Fri, 28 Sep 2018 at 08:19, FreeBSD Errata Notices wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-EN-18:12.mem Errata Notice > The FreeBSD Project > > Topic: Small kernel memory disclosures in two system calls [...] > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/10/ r339984 > releng/10.4/ r338981 > stable/11/ r339983 > releng/11.1/ r338981 > releng/11.2/ r338981 > - ------------------------------------------------------------------------- Actually, the commit on the stable/11 appears to be 338983 and not 339983. Cheers. -- Jonathan Chen