RfC: fueword(9) and casueword(9)

[Oliver Pinter]

On Wed, Oct 29, 2014 at 7:06 PM, Konstantin Belousov
<kostikbel at gmail.com> 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
>> <oliver.pinter at hardenedbsd.org> wrote:
>> > On Tue, Oct 28, 2014 at 4:46 PM, John Baldwin <jhb at 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 at 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!