Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752610AbbGQWpl (ORCPT ); Fri, 17 Jul 2015 18:45:41 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:36305 "EHLO mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbbGQWpk (ORCPT ); Fri, 17 Jul 2015 18:45:40 -0400 MIME-Version: 1.0 In-Reply-To: <20150717212244.GA581@linux.vnet.ibm.com> References: <20150717042907.GZ3717@linux.vnet.ibm.com> <20150717044921.GA18298@linux.vnet.ibm.com> <20150717201214.GJ3717@linux.vnet.ibm.com> <20150717211943.GK3717@linux.vnet.ibm.com> <20150717212244.GA581@linux.vnet.ibm.com> From: Andy Lutomirski Date: Fri, 17 Jul 2015 15:45:18 -0700 Message-ID: Subject: Re: Reconciling rcu_irq_enter()/rcu_nmi_enter() with context tracking To: Paul McKenney Cc: Sasha Levin , =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= , "linux-kernel@vger.kernel.org" , Peter Zijlstra , X86 ML , Rik van Riel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2923 Lines: 70 On Fri, Jul 17, 2015 at 2:22 PM, Paul E. McKenney wrote: > And please see attached for an in-process LWN article on RCU's requirements. > If you get a chance to look it over, I would value any feedback that you > might have. > Sure. Nice article! I found the add_gp_buggy thing a bit confusing. What's the rcu reader doing? What's the rcu_access_pointer for? You have a spinlock for the updater. You reference remove_gp_synchronous before you define it. You say: Quick Quiz 4: Without the rcu_dereference() or the rcu_access_pointer(), what destructive optimizations might the compiler make use of? Answer: It could reuse a value formerly fetched from this same pointer. It could also fetch the pointer from gp in a byte-at-a-time manner, resulting in load tearing, in turn resulting a bytewise mash-up of two distince pointer values. It might even use value-speculation optimizations, where it makes a wrong guess, but by the time it gets around to checking the value, an update has changed the pointer to match the wrong guess. Too bad about any dereferences that returned pre-initialization garbage in the meantime! Doesn't the spinlock protect against that? Requirement #2: you say "Each CPU that has an RCU read-side critical section that ends after synchronize_rcu() returns is guaranteed to execute a full memory barrier between the time that synchronize_rcu() begins and the time that the RCU read-side critical section begins. " Don't you mean an RCU read-side critical section that *starts* after synchronize_rcu() returns? Having read it: on x86 right now with nohz_full, a cpu can go into user mode and come back without executing a full barrier (I think). Certainly there's no such barrier in the entry code. I don't know what user_enter and user_exit do. Is that okay? The issue here is that a SYSRET/SYSCALL pair doesn't serialize or enforce any ordering whatsoever. I got Intel to promise that SYSCALL will always force a TSX abort [1], but that's about it. For timer-driven idle/user detection, we're fine: IRET is serializing. However, there are a couple of kernels in which we don't promise to IRET after an IRQ. This also reminds me: we really really need task switches to be full barriers in general. Otherwise store forwarding can bite otherwise-correct code on x86. s/Guaranteed Unconditional/Guaranteed Unconditionally/ [1] Because of an amusing possible attack. If you attempt a TSX transaction and it fails, you get to leak at least 8 bits out of the aborted transaction. If you manage to read /dev/urandom in a transaction, you can abort the read and still know the random number. Whoops! --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/