Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5445510ybi; Tue, 4 Jun 2019 06:50:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwTCp4uZbzbIaTSnwj5Tij8fPg5VhkwKxzt7Bqme8Eq0hOBXF1rpHVxtxHvwmUcfnSodwKF X-Received: by 2002:a17:902:b691:: with SMTP id c17mr14505486pls.107.1559656243874; Tue, 04 Jun 2019 06:50:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559656243; cv=none; d=google.com; s=arc-20160816; b=QtUWn57Z5YzY+Sc/OTshKl9kq6uUFzoPwePY1cwJmDrYQL1uyY93VLDK7RH8eHW/iW WNIzZAeCVT9eHYnYQ2g73i/TzN4cs69zp1R/UswtBpqn8sOQ20vbtTG1aQXAwGBw1SNm LDc8OJuKamtsqGqmg1rdcgQGQbGST0ZIJgfr/Uj5pssx29u6bSHZTII4pSkWImk7IzkS YEeYznq1kvBiAMZQZOl6qPt4RGa/ys0zKKx3YXuvTDxsWaj3pvo+8iUO+riT1Wfg53Ef HLt+ME61weP1qdZDQbfCIgo6bU18nKSDDqRO9j5aCIS0A51kIR0aF93o60RcLQzoqWMe MsNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=6LQU/9ucfwpiZiU8CNB13XNiRj4MZ8HHGOkhrmqFcbA=; b=dlVbhrxrdga1L2fs3D5IqZsy7fqzK82zDNQmtIgD4wjxilYBU48HdnYifbNBChrluV VhpBwqiXx1Rsw9lQid1uaqK0PK6+aGK5ixDqXGOOTBqRxemXfTc+w0J8z2epkPo3cxhq IAV41qsyqXeqeABcZ99qmF5G0A1YoA0vCM4/ngE7v+UsRIvTHi3Sry7KfCgaEhg9mqAt xx3wQ6hOEOSIF4OI67pWGrGFwNHdP1yaxnZKs/OvrOUu4Q8qK32PoCTLdSSadyc92P1R 6Dm2Yvy7/n0BhVlrp++ndfs+zCZG7xepeGt/3oTITugDuBBdWQ9wJQlLCSoq2AamJ1O7 EUIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a11si22751616pgj.537.2019.06.04.06.50.25; Tue, 04 Jun 2019 06:50:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727450AbfFDNtH (ORCPT + 99 others); Tue, 4 Jun 2019 09:49:07 -0400 Received: from foss.arm.com ([217.140.101.70]:44428 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727033AbfFDNtG (ORCPT ); Tue, 4 Jun 2019 09:49:06 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 46D20341; Tue, 4 Jun 2019 06:49:06 -0700 (PDT) Received: from arrakis.emea.arm.com (arrakis.cambridge.arm.com [10.1.196.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 790F53F690; Tue, 4 Jun 2019 06:49:04 -0700 (PDT) Date: Tue, 4 Jun 2019 14:49:01 +0100 From: Catalin Marinas To: Julien Grall Cc: linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, rostedt@goodmis.org, bigeasy@linutronix.de, suzuki.poulose@arm.com, will.deacon@arm.com, dave.martin@arm.com Subject: Re: [PATCH] arm64/cpufeature: Convert hook_lock to raw_spin_lock_t in cpu_enable_ssbs() Message-ID: <20190604134901.GE6610@arrakis.emea.arm.com> References: <20190530113058.1988-1-julien.grall@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190530113058.1988-1-julien.grall@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 30, 2019 at 12:30:58PM +0100, Julien Grall wrote: > cpu_enable_ssbs() is called via stop_machine() as part of the cpu_enable > callback. A spin lock is used to ensure the hook is registered before > the rest of the callback is executed. > > On -RT spin_lock() may sleep. However, all the callees in stop_machine() > are expected to not sleep. Therefore a raw_spin_lock() is required here. > > Given this is already done under stop_machine() and the work done under > the lock is quite small, the latency should not increase too much. > > Signed-off-by: Julien Grall Queued for 5.3. Thanks. -- Catalin