From owner-freebsd-arch@FreeBSD.ORG Wed Oct 29 18:06:42 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8593B9DA; Wed, 29 Oct 2014 18:06:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 0DF87EC6; Wed, 29 Oct 2014 18:06:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9TI6Z0c023223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 20:06:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9TI6Z0c023223 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9TI6ZVU023222; Wed, 29 Oct 2014 20:06:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 29 Oct 2014 20:06:35 +0200 From: Konstantin Belousov To: Oliver Pinter Subject: Re: RfC: fueword(9) and casueword(9) Message-ID: <20141029180635.GJ53947@kib.kiev.ua> References: <20141021094539.GA1877@kib.kiev.ua> <2048849.GkvWliFbyg@ralph.baldwin.cx> <20141027165557.GC1877@kib.kiev.ua> <201410281146.49370.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 18:06:42 -0000 On Wed, Oct 29, 2014 at 06:54:00PM +0100, Oliver Pinter wrote: > On Wed, Oct 29, 2014 at 6:50 PM, Oliver Pinter > wrote: > > On Tue, Oct 28, 2014 at 4:46 PM, John Baldwin wrote: > >> On Monday, October 27, 2014 12:55:57 pm Konstantin Belousov wrote: > >>> On Mon, Oct 27, 2014 at 11:17:51AM -0400, John Baldwin wrote: > >>> > On Tuesday, October 21, 2014 07:23:06 PM Konstantin Belousov wrote: > >>> > > On Wed, Oct 22, 2014 at 01:41:12AM +1100, Bruce Evans wrote: > >>> > > > A new API should try to fix these __DEVOLATILE() abominations. I think it > >>> > > > is safe, and even correct, to declare the pointers as volatile const void > >>> > > > *, since the functions really can handle volatile data, unlike copyin(). > >>> > > > > >>> > > > Atomic op functions are declared as taking pointers to volatile for > >>> > > > similar reasons. Often they are applied to non-volatile data, but > >>> > > > adding a qualifier is type-safe and doesn't cost efficiency since the > >>> > > > pointer access is is not known to the compiler. (The last point is not > >>> > > > so clear -- the compiler can see things in the functions since they are > >>> > > > inline asm. fueword() isn't inline so its (in)efficiency is not changed.) > >>> > > > > >>> > > > The atomic read functions are not declared as taking pointers to const. > >>> > > > The __DECONST() abomination might be used to work around this bug. > >>> > > > >>> > > I prefer to not complicate the fetch(9) KPI due to the mistakes in the > >>> > > umtx structures definitions. I think that it is bug to mark the lock > >>> > > words with volatile. I want the fueword(9) interface to be as much > >>> > > similar to fuword(9), in particular, volatile seems to be not needed. > >>> > > >>> > I agree with Bruce here. casuword() already accepts volatile. I also > >>> > think umtx is correct in marking the field as volatile. They are subject > >>> > to change without the compiler's knowledge albeit by other threads > >>> > rather than signal handlers. Having them marked volatile doesn't really > >>> > matter for the kernel, but the header is also used in userland and is > >>> > relevant in sem_new.c, etc. > >>> > >>> You agree with making fueword() accept volatile const void * as the > >>> address ? Or do you agree with the existence of the volatile type > >>> qualifier for the lock field of umtx structures ? > >> > >> I agree with both (I thought Bruce only asserted the first). > >> > >>> I definitely do not want to make fueword() different from fuword() in > >>> this aspect. If changing both fueword() and fuword() to take volatile > >>> const * address, this should be different patch. > >> > >> I also agree that fuword() and fueword() should take identical arguments, > >> so if this change is made it should be a separate patch (and should include > >> suword()). > >> > >> -- > >> John Baldwin > > > > Hi Konstantin! > > > > I got this error with clang_complete + vim: > > > > "/usr/data/source/git/opBSD/hardenedBSD.git.opntr/sys/kern/kern_pax.c" > > 286L, 8326Csem_wait: Operation not supported > > > > sem_wait: Operation not > > supported > > > > > > Fatal Python error: PyEval_SaveThread: NULL tstate > > Vim: Caught deadly signal ABRT > > Vim: Finished. > > Abort (core dumped) > > > > It's on recent HEAD + HardenedBSD patches, so I must to inspect that > > this is caused by hbsd's changes or your. > > > > I don't see this problem on HardenedBSD build, which built on Oct. 23: > > [1] FreeBSD 11.0-CURRENT #0 0c61f55(hardened/current/master): Thu Oct > > 23 09:04:50 CEST 2014 > > [1] op@hardenedbsd:/usr/obj/usr/src/sys/HARDENEDBSD amd64 > > > > (currently I build a new kernel, which was based before the fueword changes) > > > > If you need help, please ping me. > > gdb vim > > r ... > > "/usr/data/source/git/opBSD/hardenedBSD.git.opntr/sys/kern/kern_pax.c" > 286L, 8326C(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...(no debugging symbols > found)...(no debugging symbols found)...sem_wait: Operation not > supported > > > sem_wait: Operation not supported > Fatal Python error: PyEval_SaveThread: NULL tstate > > Program received signal SIGABRT, Aborted. > 0x00000009f5bb387a in thr_kill () from /lib/libc.so.7 > (gdb) bt > #0 0x00000009f5bb387a in thr_kill () from /lib/libc.so.7 > #1 0x00000009f5c76849 in abort () from /lib/libc.so.7 > #2 0x00000009f566c031 in Py_FatalError () from /usr/local/lib/libpython2.7.so.1 > #3 0x00000009f56448f1 in PyEval_SaveThread () from > /usr/local/lib/libpython2.7.so.1 > #4 0x00000009f79ceef5 in _PyTime_FloatTime () from > /usr/local/lib/python2.7/lib-dynload/time.so > #5 0x00000009f564a31b in PyEval_EvalFrameEx () from > /usr/local/lib/libpython2.7.so.1 > #6 0x00000009f564cb42 in _PyEval_SliceIndex () from > /usr/local/lib/libpython2.7.so.1 > #7 0x00000009f564862b in PyEval_EvalFrameEx () from > /usr/local/lib/libpython2.7.so.1 > #8 0x00000009f564cb42 in _PyEval_SliceIndex () from > /usr/local/lib/libpython2.7.so.1 > #9 0x00000009f564862b in PyEval_EvalFrameEx () from > /usr/local/lib/libpython2.7.so.1 > #10 0x00000009f56452d4 in PyEval_EvalCodeEx () from > /usr/local/lib/libpython2.7.so.1 > #11 0x00000009f55d63bc in PyFunction_SetClosure () from > /usr/local/lib/libpython2.7.so.1 > #12 0x00000009f55b2d24 in PyObject_Call () from /usr/local/lib/libpython2.7.so.1 > #13 0x00000009f55becc3 in PyMethod_New () from /usr/local/lib/libpython2.7.so.1 > #14 0x00000009f55b2d24 in PyObject_Call () from /usr/local/lib/libpython2.7.so.1 > #15 0x00000009f564c28d in PyEval_CallObjectWithKeywords () from > /usr/local/lib/libpython2.7.so.1 > #16 0x00000009f5681916 in initthread () from /usr/local/lib/libpython2.7.so.1 > #17 0x00000009f59274f5 in pthread_create () from /lib/libthr.so.3 > #18 0x0000000000000000 in ?? () > How could I get a single bit of useful information from this text ? My guess is that you have old libc and new kernel compiled without COMPAT_FREEBSD9 and 10. If this is the cause, it has nothing to do with my changes.