Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965531AbcCORgZ (ORCPT ); Tue, 15 Mar 2016 13:36:25 -0400 Received: from mail-ig0-f180.google.com ([209.85.213.180]:38487 "EHLO mail-ig0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965132AbcCORgX (ORCPT ); Tue, 15 Mar 2016 13:36:23 -0400 MIME-Version: 1.0 In-Reply-To: <20160315172803.GB5058@lerouge> References: <20160314123200.GA15971@gmail.com> <20160315095337.GC7943@gmail.com> <20160315121525.GA3991@gmail.com> <20160315172803.GB5058@lerouge> Date: Tue, 15 Mar 2016 10:36:21 -0700 X-Google-Sender-Auth: jI3GE0q8rxyb5fChA5j9pQrFlD0 Message-ID: Subject: Re: [PATCH] nohz: Change tick_dep_mask from 'unsigned long' to 'unsigned int' From: Linus Torvalds To: Frederic Weisbecker Cc: Ingo Molnar , Linux Kernel Mailing List , Thomas Gleixner , Peter Zijlstra , Andrew Morton 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: 1046 Lines: 28 On Tue, Mar 15, 2016 at 10:28 AM, Frederic Weisbecker wrote: >> >> And wouldn't it be so nice if "thread_info->flags" would just be >> atomic_t too. Right now we use a mixture of bit-ops and ACCESS_ONCE() >> (and many codepaths then doing neither, and just accessing it >> directly, ignoring any races. >> >> Oh well. > > I can try that too while at it :-) The real problem with thread_info->flags is that it's per-architecture, and people access that thing from assembly code. So changing that is potentially really *very* painful. The patch itself is not likely too bad, but having confidence that everything was caught? Nasty. It would probably be a very good cleanup, but I'm not sure how worthwhile it is considering the pain. (The only good news is that any problem is likely to be *very* obvious. Switching the field to a 32-bit type on a big-endian machine and not catching some case will mean that people will check or modify the wrong flags, and you'd likely get breakage quite quickly) Linus