Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756086AbcCOJte (ORCPT ); Tue, 15 Mar 2016 05:49:34 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36102 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755207AbcCOJtZ (ORCPT ); Tue, 15 Mar 2016 05:49:25 -0400 Date: Tue, 15 Mar 2016 10:49:21 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: Linus Torvalds , Linux Kernel Mailing List , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , Thomas Gleixner , Andrew Morton Subject: Re: [GIT PULL] NOHZ updates for v4.6 Message-ID: <20160315094921.GB7943@gmail.com> References: <20160314123200.GA15971@gmail.com> <20160315084220.GR6344@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160315084220.GR6344@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1839 Lines: 45 * Peter Zijlstra wrote: > On Mon, Mar 14, 2016 at 07:44:14PM -0700, Linus Torvalds wrote: > > On Mon, Mar 14, 2016 at 5:32 AM, Ingo Molnar wrote: > > > +/** > > > + * fetch_or - perform *ptr |= mask and return old value of *ptr > > > + * @ptr: pointer to value > > > + * @mask: mask to OR on the value > > > + * > > > + * cmpxchg based fetch_or, macro so it works for different integer types > > > + */ > > > +#ifndef fetch_or > > > +#define fetch_or(ptr, mask) \ > > > +({ typeof(*(ptr)) __old, __val = *(ptr); \ > > > + for (;;) { \ > > > + __old = cmpxchg((ptr), __val, __val | (mask)); \ > > > + if (__old == __val) \ > > > + break; \ > > > + __val = __old; \ > > > + } \ > > > + __old; \ > > > +}) > > > +#endif > > > > This is garbage. > > > > This macro re-uses the "mask" argument potentially many many times, so > > semantically it's very dubious. > > So the below cures that; but do we want to maybe pull this back into > sched.c and expose a version that operates on a fixed type instead? So there are other problems with the macro - see the patch I just sent that tries to fix all of them. > Although with xchg() and cmpxchg() we've already set a precedence for > multi-width operators. Yes, and if we name the new API 'xchg_or()' as I did it in my patch then it all nicely fits into the existing scheme. Thanks, Ingo