Date: Wed, 29 Oct 2014 18:54:00 +0100 From: Oliver Pinter <oliver.pinter@hardenedbsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-arch@freebsd.org Subject: Re: RfC: fueword(9) and casueword(9) Message-ID: <CAPQ4ffsSPtRyQD==WROCR6Shmm6d=N_6oS8zoJEcio9fCi1Amw@mail.gmail.com> In-Reply-To: <CAPQ4ffsXa4BOHWJt_YhPOSDu5KQpUf0oVcMoiAFCxyR9YVKCdQ@mail.gmail.com> References: <20141021094539.GA1877@kib.kiev.ua> <2048849.GkvWliFbyg@ralph.baldwin.cx> <20141027165557.GC1877@kib.kiev.ua> <201410281146.49370.jhb@freebsd.org> <CAPQ4ffsXa4BOHWJt_YhPOSDu5KQpUf0oVcMoiAFCxyR9YVKCdQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 29, 2014 at 6:50 PM, Oliver Pinter <oliver.pinter@hardenedbsd.org> wrote: > On Tue, Oct 28, 2014 at 4:46 PM, John Baldwin <jhb@freebsd.org> 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 ?? () > > >> _______________________________________________ >> freebsd-arch@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPQ4ffsSPtRyQD==WROCR6Shmm6d=N_6oS8zoJEcio9fCi1Amw>