From owner-freebsd-arch@FreeBSD.ORG Wed Oct 29 17:50:29 2014 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E62AD21B for ; Wed, 29 Oct 2014 17:50:29 +0000 (UTC) Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) (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 A9E6CC98 for ; Wed, 29 Oct 2014 17:50:29 +0000 (UTC) Received: by mail-yk0-f177.google.com with SMTP id 79so1505210ykr.8 for ; Wed, 29 Oct 2014 10:50:23 -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=7UNUoQuwZvnxRXz4FABMxYW4GBXDMSDjLiV2waYoVZI=; b=jaouMgRlQgwrCPw4bjja0rjSKJjCjRGBwZlHAcqOrzCnEsHds7LDeXSseJVkMRlZtr LN1XidwKBWJKYf3PBuAxSvnbXeyu/Ka+K//tbk2nAGDrw1p4KMsrojZiQV7zyuqrFrsN g9dffXLpGg90UmytBoqU62dmIKFi8HpngWvhw7V1du5vt2shsH3A66dCh71rkYpo4kan 6ojTUKKtUSzlc/AXaDHJZDKewuCOV5/e41mBnvUSroKYyTYKopGLuCBQ0vTwcjdvDj5V qcpjvQ4Uwy+vzmKxNbxaejTfmfWXeD1LYnNfYQY/HXIEJzAeA1LU/K/g8IAcUwCOvI3Q OsIg== X-Gm-Message-State: ALoCoQntSTM/4ZSgYseEc5bo7QWGwZb+sgB2/Xt4t/2EaZpzmMqdeeHk/RuC4o6Wd+7dSCGtMACd MIME-Version: 1.0 X-Received: by 10.170.233.6 with SMTP id z6mr3453134ykf.101.1414605023070; Wed, 29 Oct 2014 10:50:23 -0700 (PDT) Received: by 10.170.46.203 with HTTP; Wed, 29 Oct 2014 10:50:22 -0700 (PDT) X-Originating-IP: [62.165.198.134] In-Reply-To: <201410281146.49370.jhb@freebsd.org> References: <20141021094539.GA1877@kib.kiev.ua> <2048849.GkvWliFbyg@ralph.baldwin.cx> <20141027165557.GC1877@kib.kiev.ua> <201410281146.49370.jhb@freebsd.org> Date: Wed, 29 Oct 2014 18:50:22 +0100 Message-ID: Subject: Re: RfC: fueword(9) and casueword(9) From: Oliver Pinter To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , 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 17:50:30 -0000 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. > _______________________________________________ > 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"