From owner-freebsd-arch@freebsd.org Fri Sep 30 15:20:13 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5966AC0293F for ; Fri, 30 Sep 2016 15:20:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 E72991D41; Fri, 30 Sep 2016 15:20:12 +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 u8UFK6c1008756 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 30 Sep 2016 18:20:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u8UFK6c1008756 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u8UFK61P008752; Fri, 30 Sep 2016 18:20:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 30 Sep 2016 18:20:06 +0300 From: Konstantin Belousov To: Lewis Donzis Cc: freebsd-arch@freebsd.org, deischen@freebsd.org Subject: Re: mq on kqueue broken after upgrade to FreeBSD 11 Message-ID: <20160930152006.GS38409@kib.kiev.ua> References: <8A6CD0D3-C4D5-40DF-B2AD-4C454CC88AD1@perftech.com> <20160930094544.GP38409@kib.kiev.ua> <19A6EEAA-C68E-4DAD-B98F-4D904734BD8B@perftech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19A6EEAA-C68E-4DAD-B98F-4D904734BD8B@perftech.com> User-Agent: Mutt/1.6.1 (2016-04-27) 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-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 15:20:13 -0000 On Fri, Sep 30, 2016 at 06:52:52AM -0500, Lewis Donzis wrote: > > > On Sep 30, 2016, at 4:45 AM, Konstantin Belousov wrote: > > Where was a discussion about the function presence being the mistake ? > > I think it was here: https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058706.html > > which was just about a year ago. Perhaps I???m reading it wrong, but it seems like the implication is that removing the symbol from being exported was a "fix", where DE says "Why do the tests in tests/sys/mqueue/ try to use non-public APIs?" and then later, "symbol versioning for librt was broken and leaking symbols that shouldn't have been leaked." > I added Daniel to Cc:. I think that the issue you referenced is somewhat different. The r291439 commit restored symbol versioning, i.e. before it, all symbols were accessible. Right now we are discussing the merits of making one symbol accessible, which was removed from the export table as a side effect of the fix. In other words, if at the time of r291439 the symbol was present in the public export list, your code would not note the fix. > > > In r291439, symbol versioning for librt was fixed, and apparently > > __mq_oshandle() is not present in the global symbols list for librt. > > I suspect that this is an erronous ommission, since the function' > > declaration is present in the mqueue.h header and it is used by some > > mqueue tests. > > > > As such, I believe that exporting it is the intended option there. > > The following patch should fix the problem for you. > > That makes sense, and appreciate the patch, but just to be clear, does your change get committed so that we won???t have to re-apply it after future updates/upgrades? > As I stated, my opinion is that this symbol can be usefully exported. Its name is in implementation-private namespace, and there are uses where access to the mqueue fd (or to the timer id) gives more flexibility and significantly reduces the amount of code. Unless there appear strong objections against the export, I will commit the patch, sure.