From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754906AbcCJWlJ (ORCPT ); Thu, 10 Mar 2016 17:41:09 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:32928 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753486AbcCJWlH (ORCPT ); Thu, 10 Mar 2016 17:41:07 -0500 Date: Thu, 10 Mar 2016 14:41:05 -0800 From: Andrew Morton To: Rasmus Villemoes Cc: linux-kernel@vger.kernel.org, Christian Borntraeger , Konrad Rzeszutek Wilk Subject: Re: [PATCH resend] linux/compiler.h: fix stale comment on {READ,WRITE}_ONCE Message-Id: <20160310144105.a5670cf3e05e308abe24a676@linux-foundation.org> In-Reply-To: <1457569017-13638-1-git-send-email-linux@rasmusvillemoes.dk> References: <1444635981-25552-1-git-send-email-linux@rasmusvillemoes.dk> <1457569017-13638-1-git-send-email-linux@rasmusvillemoes.dk> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 10 Mar 2016 01:16:57 +0100 Rasmus Villemoes wrote: > Commit 7bd3e239d6c6 ("locking: Remove atomicy checks from > {READ,WRITE}_ONCE") removed said warning. > > Acked-by: Christian Borntraeger > Signed-off-by: Rasmus Villemoes > --- > Andrew, can you pick this up please? > > include/linux/compiler.h | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/include/linux/compiler.h b/include/linux/compiler.h > index 48f5aab117ae..062b6ad95276 100644 > --- a/include/linux/compiler.h > +++ b/include/linux/compiler.h > @@ -263,8 +263,7 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s > * In contrast to ACCESS_ONCE these two macros will also work on aggregate > * data types like structs or unions. If the size of the accessed data > * type exceeds the word size of the machine (e.g., 32 bits or 64 bits) > - * READ_ONCE() and WRITE_ONCE() will fall back to memcpy and print a > - * compile-time warning. > + * READ_ONCE() and WRITE_ONCE() will fall back to memcpy. > * > * Their two major use cases are: (1) Mediating communication between > * process-level code and irq/NMI handlers, all running on the same CPU, Conflicts with Konrad's patch in linux-next (from an IngoTree), below. I'll drop your patch - Konrad covers the same info and more. (grammar nazi: s/There's/There are/) commit fed0764fafd8e2e629a033c0f7df4106b0dcb7f0 Author: Konrad Rzeszutek Wilk AuthorDate: Mon Jan 25 16:33:20 2016 -0500 Commit: Ingo Molnar CommitDate: Tue Feb 9 14:50:16 2016 +0100 locking/atomics: Update comment about READ_ONCE() and structures The comment is out of data. Also point out the performance drawback of the barrier();__builtin_memcpy(); barrier() followed by another copy from stack (__u) to lvalue; Signed-off-by: Konrad Rzeszutek Wilk Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Christian Borntraeger Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Sasha Levin Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1453757600-11441-1-git-send-email-konrad.wilk@oracle.com [ Made it a bit more readable. ] Signed-off-by: Ingo Molnar diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 00b042c..4291592 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -263,8 +263,9 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s * In contrast to ACCESS_ONCE these two macros will also work on aggregate * data types like structs or unions. If the size of the accessed data * type exceeds the word size of the machine (e.g., 32 bits or 64 bits) - * READ_ONCE() and WRITE_ONCE() will fall back to memcpy and print a - * compile-time warning. + * READ_ONCE() and WRITE_ONCE() will fall back to memcpy(). There's at + * least two memcpy()s: one for the __builtin_memcpy() and then one for + * the macro doing the copy of variable - '__u' allocated on the stack. * * Their two major use cases are: (1) Mediating communication between * process-level code and irq/NMI handlers, all running on the same CPU,