Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965132Ab3DHPHq (ORCPT ); Mon, 8 Apr 2013 11:07:46 -0400 Received: from mail-vb0-f46.google.com ([209.85.212.46]:43237 "EHLO mail-vb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965063Ab3DHPHm (ORCPT ); Mon, 8 Apr 2013 11:07:42 -0400 MIME-Version: 1.0 In-Reply-To: <1365433142.2733.18.camel@fedora> References: <1364998282-21437-1-git-send-email-vgupta@synopsys.com> <20130404152808.GB15261@ab42.lan> <515E54BD.2090300@synopsys.com> <51602459.3040105@synopsys.com> <51624591.4010303@synopsys.com> <1365428274.2609.160.camel@laptop> <1365431470.2733.16.camel@fedora> <1365433142.2733.18.camel@fedora> Date: Mon, 8 Apr 2013 08:07:41 -0700 X-Google-Sender-Auth: XbFHBJ1agVDlnefW_uOy7jJHbiQ Message-ID: Subject: Re: [PATCH] [PATCH] Gaurantee spinlocks implicit barrier for !PREEMPT_COUNT From: Linus Torvalds To: Steven Rostedt Cc: Peter Zijlstra , Vineet Gupta , Thomas Gleixner , Christian Ruppert , Pierrick Hascoet , Frederic Weisbecker , Ingo Molnar , Linux Kernel Mailing List 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: 1302 Lines: 31 On Mon, Apr 8, 2013 at 7:59 AM, Steven Rostedt wrote: >> +/* This is only a barrier to other asms. Notably get_user/put_user */ > > Probably should add in the comment: > > " or anything else that can cause a hidden schedule. " > Fair enough. And I just remembered why I thought UP was special - we need to do the same thing about spinlocks, for the same reasons. So that "asm_barrier()" should probably be in along with the "normal" barrier() definition. *AND* somebody should re-check the gcc documentation on "volatile asm". I'm pretty sure it used to say "not moved significantly, including against each other" or something like that, but the gcc asm docs have changed over time. I'd hate to have to add a memory clobber to the get_user/put_user asms, because that would *really* hurt. But maybe we could add some other clobber ("cc" or similar) to make sure they can't be re-ordered if the "volatile" isn't sufficient to make sure asms don't get re-ordered wrt each other. Linus -- 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/