From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S934711AbcCOQaw (ORCPT <rfc822;w@1wt.eu>);
	Tue, 15 Mar 2016 12:30:52 -0400
Received: from mail-io0-f173.google.com ([209.85.223.173]:36247 "EHLO
	mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751048AbcCOQau (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Tue, 15 Mar 2016 12:30:50 -0400
MIME-Version: 1.0
In-Reply-To: <20160315121525.GA3991@gmail.com>
References: <20160314123200.GA15971@gmail.com>
	<CA+55aFyqG0xriTOus7wu527rdYHeLX3Qidt9ZzggL+MsR=_iQQ@mail.gmail.com>
	<20160315095337.GC7943@gmail.com>
	<20160315121525.GA3991@gmail.com>
Date: Tue, 15 Mar 2016 09:30:49 -0700
X-Google-Sender-Auth: rhUKV4jrYUoxyH6ENW9Fz7jfCno
Message-ID: <CA+55aFzW1eSZGSC7gQdTOHqPHq5UEVR+_OvdxbAhGiCFSPcf7g@mail.gmail.com>
Subject: Re: [PATCH] nohz: Change tick_dep_mask from 'unsigned long' to
 'unsigned int'
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        =?UTF-8?B?RnLDqWTDqXJpYyBXZWlzYmVja2Vy?= <fweisbec@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Andrew Morton <akpm@linux-foundation.org>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Mar 15, 2016 at 5:15 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> Hm, so the problem I did not consider is the following:
>
>  triton:~/tip> git grep tick_dep_mask kernel | grep _bit
>  kernel/time/tick-sched.c:       clear_bit(bit, &ts->tick_dep_mask);
>  kernel/time/tick-sched.c:       clear_bit(bit, &tsk->tick_dep_mask);
>  kernel/time/tick-sched.c:       clear_bit(bit, &sig->tick_dep_mask);

Ahh. I missed that too.

Ok, leave the 64-bit field for now, while we think about this. But one
option is to just use "atomic_andnot()" instead of clear_bit().

That would imply using an "atomic_t", which would be fairly natural
(and would be 32-bit).

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.

                Linus