Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp801407ybv; Thu, 20 Feb 2020 07:33:01 -0800 (PST) X-Google-Smtp-Source: APXvYqwO9C/9sZ5azLGY+YccfSYuV3OU8PCbO9ywDSZvMaud83EF3YpNjLycO0YuPLWtw9YlGG5q X-Received: by 2002:a05:6830:140b:: with SMTP id v11mr24088701otp.340.1582212781404; Thu, 20 Feb 2020 07:33:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582212781; cv=none; d=google.com; s=arc-20160816; b=A9d3IjJeGsUiLqEwum0GusLFINWlRJ28EnklbaYX9lGMHHlZuQXB3SWE3J/RdZQiI6 zcVjOHS62cAEbqkzhwl90gmGKXwpWu3EtbyppVjJOGMupSRfIU9sNMluSEEuZ9Fv+fza C8ePJ/32t6rqswjj5fzdrev242uLWTpSpbT3t27lrD92trFLHhG+0mHzFiTGXd7RSlT2 OMIsmz5rIaa5lLeFp32Q+60lq4Lq/eQ9rg94nSj68b6L52kpUC6yu8J352pGGkxFkz3m z2a4bYZpteU/dvjkc4S+TZ1ZzEKpRC9111GiP63dnH58OmF0giaNL/SrkZVgxZTLqEng okdw== 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=osmCSpHIgBb2R1vOYnZa9i/M7Qgge/wRjixy81Ln6R0=; b=NKRYsYQUIrxnuA97t+AMFEAWBwprJNQbldJuKodapImssGa4rqohpMCWZ+TEaX+U9D 6nuYbVO01n0+z2Rb3VfX3t6DO9UEqLJ9t+pyc7YajTgBg1h9nHdAiIJxwTo2tssKQ/4Z 5y2E0hz9DWGfcXnatYWSfTp0G8VtEFCZtwCIo5EM1Ht2eyrS7SET1a+dDIUCTvJ45bSa tsfWnUqx5yiZmu0o+FOp/ArhpSNyTTHCL0/9klANh1gqogho5ZaVeUuUktUc/9fmJre6 yw1/Q01pZyEXpRLhA9fkTVVU7TWgPFvX3LKwWqgpO3exf+0mcsbKI+csa5wgIawLNiiT vKqg== 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 v1si1823803otp.91.2020.02.20.07.32.45; Thu, 20 Feb 2020 07:33:01 -0800 (PST) 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 S1728428AbgBTPcE (ORCPT + 99 others); Thu, 20 Feb 2020 10:32:04 -0500 Received: from foss.arm.com ([217.140.110.172]:44992 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728305AbgBTPcD (ORCPT ); Thu, 20 Feb 2020 10:32:03 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 254ED31B; Thu, 20 Feb 2020 07:32:03 -0800 (PST) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 414323F703; Thu, 20 Feb 2020 07:32:02 -0800 (PST) Date: Thu, 20 Feb 2020 15:31:59 +0000 From: Qais Yousef To: "Paul E. McKenney" Cc: Thomas Gleixner , Greg Kroah-Hartman , Davidlohr Bueso , Josh Triplett , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 12/14] torture: Replace cpu_up/down with device_online/offline Message-ID: <20200220153159.mzpagvbwptxlehvd@e107158-lin.cambridge.arm.com> References: <20191125112754.25223-1-qais.yousef@arm.com> <20191125112754.25223-13-qais.yousef@arm.com> <20191127214725.GG2889@paulmck-ThinkPad-P72> <20191128165611.7lmjaszjl4gbo7u2@e107158-lin.cambridge.arm.com> <20191128170025.ii3vqbj4jpcyghut@e107158-lin.cambridge.arm.com> <20191128210246.GJ2889@paulmck-ThinkPad-P72> <20191129091344.hf5demtjytv5dw5q@e107158-lin.cambridge.arm.com> <20191129203856.GN2889@paulmck-ThinkPad-P72> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191129203856.GN2889@paulmck-ThinkPad-P72> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/29/19 12:38, Paul E. McKenney wrote: > On Fri, Nov 29, 2019 at 09:13:45AM +0000, Qais Yousef wrote: > > On 11/28/19 13:02, Paul E. McKenney wrote: > > > On Thu, Nov 28, 2019 at 05:00:26PM +0000, Qais Yousef wrote: > > > > On 11/28/19 16:56, Qais Yousef wrote: > > > > > On 11/27/19 13:47, Paul E. McKenney wrote: > > > > > > On Mon, Nov 25, 2019 at 11:27:52AM +0000, Qais Yousef wrote: > > > > > > > The core device API performs extra housekeeping bits that are missing > > > > > > > from directly calling cpu_up/down. > > > > > > > > > > > > > > See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and > > > > > > > serialization during LPM") for an example description of what might go > > > > > > > wrong. > > > > > > > > > > > > > > This also prepares to make cpu_up/down a private interface for anything > > > > > > > but the cpu subsystem. > > > > > > > > > > > > > > Signed-off-by: Qais Yousef > > > > > > > CC: Davidlohr Bueso > > > > > > > CC: "Paul E. McKenney" > > > > > > > CC: Josh Triplett > > > > > > > CC: linux-kernel@vger.kernel.org > > > > > > > > > > > > Looks fine from an rcutorture viewpoint, but why not provide an API > > > > > > that pulled lock_device_hotplug() and unlock_device_hotplug() into the > > > > > > online/offline calls? > > > > > > > > > > I *think* the right way to do what you say is by doing lock_device_hotplug() > > > > > inside device_{online, offline}() - which affects all drivers not just the CPU. > > > > > > Or there could be a CPU-specific wrapper function that did the needed > > > locking. (Whether this is worth it or not of course depends on the > > > number of invocations.) > > > > Okay I see what you mean now. driver/base/memory.c have {add,remove}_memory() > > that does what you say. I think we can replicate this in driver/base/cpu.c too. > > > > I can certainly do that, better as an improvement on top as I need to audit the > > code to make sure the critical sections weren't relying on this lock to protect > > something else beside the online/offline operation. > > Works for me! I'm taking that as reviewed-by, which I'll add to v3. Please shout if you still need to have a look further. Once this is taken I'll add the suggested API! Thanks -- Qais Yousef