From owner-freebsd-arch@FreeBSD.ORG Wed Oct 29 18:10:51 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 1A144BBE for ; Wed, 29 Oct 2014 18:10:51 +0000 (UTC) Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CF207FA0 for ; Wed, 29 Oct 2014 18:10:50 +0000 (UTC) Received: by mail-yh0-f41.google.com with SMTP id b6so844656yha.14 for ; Wed, 29 Oct 2014 11:10:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nIKdmnOOMwfqUrS20ZGqYgtwQh6nWRLbukuilCiwNTU=; b=Inwj6hls8aRb0z5VtFP0vBnuOz+qO+dUZp5UlVEiiLUxaY1wuqDaJzym1VBRWIhib3 6Ny3IzGFFtkUNAJ1+GVgiKjLzbHutqHFiEk41pjINDTI5p9jGYZ1sJ2UdHFP6ntOue57 1mqGARiZwN6AnhI19zLOcnHGUy983Pt7AnoHT0vgrXFBBwXS79xtWuUS3UpmwrCZItA0 gFRR85blE79vOSmnhObjKDBi24gal733ChhaEaXuFSuvdWI0auJocmxjQ9Sjjw/ahHmO 0dN3sEDNdv6T6/MF3jgpyVEfOvkvFgTHuhVfQ21GBl99lzUlWs20o7V9KSAMEcGe0bdK tjfA== X-Gm-Message-State: ALoCoQlIreRa3mffVT0Uz+qArCzNpPmGLzQ0R1bxmvnZCdtrOxrU/IWiDLGkSIeAE0fHAuUxr7xg MIME-Version: 1.0 X-Received: by 10.170.233.6 with SMTP id z6mr3559601ykf.101.1414606244246; Wed, 29 Oct 2014 11:10:44 -0700 (PDT) Received: by 10.170.46.203 with HTTP; Wed, 29 Oct 2014 11:10:44 -0700 (PDT) X-Originating-IP: [62.165.198.134] In-Reply-To: <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> <20141029180635.GJ53947@kib.kiev.ua> Date: Wed, 29 Oct 2014 19:10:44 +0100 Message-ID: Subject: Re: RfC: fueword(9) and casueword(9) From: Oliver Pinter To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 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:10:51 -0000 On Wed, Oct 29, 2014 at 7:06 PM, Konstantin Belousov wrote: > 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. Sure. The userland is from Oct. 20 too, and COMPAT_FREEBSD{9,10} was not added to kernel config. Thanks!