From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862AbdJESxg (ORCPT ); Thu, 5 Oct 2017 14:53:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:36482 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751525AbdJESxe (ORCPT ); Thu, 5 Oct 2017 14:53:34 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 76B3D21908 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=acme@kernel.org Date: Thu, 5 Oct 2017 15:53:30 -0300 From: Arnaldo Carvalho de Melo To: Julia Cartwright Cc: bigeasy@linutronix.de, linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Clark Williams , Dean Luick , Dennis Dalessandro , Doug Ledford , Kaike Wan , Leon Romanovsky , linux-rdma@vger.kernel.org, Peter Zijlstra , Sebastian Andrzej Siewior , Sebastian Sanchez , Steven Rostedt , Thomas Gleixner Subject: Re: [PATCH 1/2] IB/hfi1: Use preempt_{dis,en}able_nort() Message-ID: <20171005185330.GP25388@kernel.org> References: <20171003154920.31566-1-acme@kernel.org> <20171003154920.31566-2-acme@kernel.org> <20171005141744.GC21185@jcartwri.amer.corp.natinst.com> <20171005165305.GN25388@kernel.org> <20171005182900.GK647@jcartwri.amer.corp.natinst.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171005182900.GK647@jcartwri.amer.corp.natinst.com> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Thu, Oct 05, 2017 at 01:29:00PM -0500, Julia Cartwright escreveu: > On Thu, Oct 05, 2017 at 01:53:05PM -0300, Arnaldo Carvalho de Melo wrote: > > So __this_cpu_inc() checks preemption but this_cpu_inc() doesn't and > > thus we're ok here? Or am I getting lost in this maze of defines? :-) > I think I was the one lost in the maze. You are correct. Sorry for the > confusion. > My mind expected that the __ prefixed versions would be the "raw" > versions that are free of checks, with the checks made in the non > prefixed versions, but it is the other way around. > I'm happy to accept that the bug is within my mind. :-) Ok, now I'm taking the opportunity to read more about local locks, as Sebastian thinks are needed in this case, which I'm not entirely convinced from the discussion that took place here, and as you took part in that discussion and suggested using the nort variants of preempt_disable, do you still think this is the way to go? - Arnaldo