From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43110) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dXbwx-0004q6-AG for qemu-devel@nongnu.org; Tue, 18 Jul 2017 19:30:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dXbws-0000CU-Ca for qemu-devel@nongnu.org; Tue, 18 Jul 2017 19:30:43 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:35607) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dXbwr-0000CE-U9 for qemu-devel@nongnu.org; Tue, 18 Jul 2017 19:30:38 -0400 Date: Tue, 18 Jul 2017 19:30:35 -0400 From: "Emilio G. Cota" Message-ID: <20170718233035.GA10731@flamenco> References: <1500235468-15341-1-git-send-email-cota@braap.org> <1500235468-15341-11-git-send-email-cota@braap.org> <92056605-c95b-b19b-0216-5d83be64e13d@twiddle.net> <20170718002700.GA7414@flamenco> <5382470b-120c-1cdd-32f3-d246d75059d2@twiddle.net> <20170718045458.GB12960@flamenco> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2 10/45] translate-all: guarantee that tb_hash only holds valid TBs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: qemu-devel@nongnu.org On Mon, Jul 17, 2017 at 19:29:57 -1000, Richard Henderson wrote: > On 07/17/2017 06:54 PM, Emilio G. Cota wrote: > >What threw me off was that in lookup_tb_ptr we're not checking tb->invalid, > >and that biased me into thinking that it's not needed. But I should have > >tried harder. Also, that's a bug, and yet another reason to have tb_lookup, > >so that we fix these things at once in one place. > > Yes, me as well. Quite right we need only one copy of this code. > > >> (tb->flags & (CF_HASH_MASK | CF_INVALID)) == cf_mask > >> > >>So that we continue to check CF_INVALID each time we lookup a TB, but now we > >>get it for free as a part of the other flags check. > > > >With the annoying atomic_read thrown in there :-) but yes, will do. > > Yes of course. ;-) Gaah, we'll need to update all readers of tb->cflags, of which we have plenty (~145, mostly in target code) to avoid C11 undefined behaviour and make Paolo happy. Should I do those updates in the same patch where tb->invalid is brought over to cflags? Alternatives: have a later patch where all readers are converted to atomic_read, or keep tb->invalid as a separate field (we could use that 4-byte hole in struct tb_tc..) E.