From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751120AbdHVP7L (ORCPT ); Tue, 22 Aug 2017 11:59:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36340 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750812AbdHVP7K (ORCPT ); Tue, 22 Aug 2017 11:59:10 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com D87D57EA94 Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=oleg@redhat.com Date: Tue, 22 Aug 2017 17:59:06 +0200 From: Oleg Nesterov To: Peter Zijlstra Cc: Byungchul Park , mingo@kernel.org, linux-kernel@vger.kernel.org, kernel-team@lge.com, Arnaldo Carvalho de Melo , Dave Chinner , Tejun Heo , johannes@sipsolutions.net Subject: Re: [PATCH v3 1/3] lockdep: Make LOCKDEP_CROSSRELEASE configs all part of PROVE_LOCKING Message-ID: <20170822155906.GA6824@redhat.com> References: <1502960261-16206-1-git-send-email-byungchul.park@lge.com> <20170821154600.asyzqs2zg6w6o4pg@hirez.programming.kicks-ass.net> <20170822051438.GD20323@X58A-UD3R> <20170822075238.uyfmhgxeal2bwcdg@hirez.programming.kicks-ass.net> <20170822085100.GH20323@X58A-UD3R> <20170822092141.fjmr74xhfid7vu7h@hirez.programming.kicks-ass.net> <20170822093337.GJ20323@X58A-UD3R> <20170822100840.eababgjcu76iois5@hirez.programming.kicks-ass.net> <20170822134922.m2g6kqsqo2eojrg7@hirez.programming.kicks-ass.net> <20170822144602.uh5jzkkchvdgzs3s@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170822144602.uh5jzkkchvdgzs3s@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 22 Aug 2017 15:59:10 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter, I'll read your email tomorrow, just one note... On 08/22, Peter Zijlstra wrote: > > Also^2, TJ, what's the purpose of using atomic_long_t for work->data? > All it ever seems to do is atomic_long_read() and atomic_long_set(), plust set/clear bit, for example test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work)); commit a08727bae727fc2ca3a6ee9506d77786b71070b3 Author: Linus Torvalds Date: Sat Dec 16 09:53:50 2006 -0800 Make workqueue bit operations work on "atomic_long_t" On architectures where the atomicity of the bit operations is handled by external means (ie a separate spinlock to protect concurrent accesses), just doing a direct assignment on the workqueue data field (as done by commit 4594bf159f1962cec3b727954b7c598b07e2e737) can cause the assignment to be lost due to lack of serialization with the bitops on the same word. So we need to serialize the assignment with the locks on those architectures (notably older ARM chips, PA-RISC and sparc32). So rather than using an "unsigned long", let's use "atomic_long_t", which already has a safe assignment operation (atomic_long_set()) on such architectures. This requires that the atomic operations use the same atomicity locks as the bit operations do, but that is largely the case anyway. Sparc32 will probably need fixing. Architectures (including modern ARM with LL/SC) that implement sane atomic operations for SMP won't see any of this matter. Oleg.