Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp7804460ybc; Fri, 29 Nov 2019 01:15:18 -0800 (PST) X-Google-Smtp-Source: APXvYqxBb+OfQf1grbW5uSwg8BcQiVa0EBk0e6d7mKACFcT8ls4TzY0m+z9u1QV1e6ogxAgGhVS0 X-Received: by 2002:a50:d0d0:: with SMTP id g16mr37038600edf.75.1575018918809; Fri, 29 Nov 2019 01:15:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575018918; cv=none; d=google.com; s=arc-20160816; b=uXw3bC6pWFEMlEy/Mw0NzrRXT1/FlU8634jFl+n2GHm25bj6S+HlR+6XBgXvOJtN92 vp+6c1dR/Z46Er8hgQBdyNv00guU+BcxUblG58eUQxlgduG05s3iQiGy3EAl9nUZL75R h1V5KEeaPYg+mbxkYoQy0qOHmmoabNXT4iP6OUafba7ibgjXn3OYYviKL4aipCZeC4/n 6hbGFFLRNPf5huyw9rrElbT8n9ZqAyDhPCwtk7I2SKz5mwIMv0NzI4nuXjmDpDtLzhfC dztc8TCkaf+3tAyJIPLbVxTMXZXvxfhFaGoTTK4WLzR6kR9sEHXxU7c40dB+LuS5ZBK5 we4A== 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=YZ0VnpdtKJsmv4HYdvZUe4dzikI1FvfUqoQwEFmSAo4=; b=DJCYJr7G/ECv6TBj/si2TsQR3zI9KOpZIlQBbF64IO4fkd+IPaNceFyMh8ZIuvutkU 2hlG+EFckVgNKyfhvLm1OBBeeOHE26/CJQf4u8N1xfNK8l/PPiohYVpQFmkcpaO3W8aJ IHgPtqBRzuVRphvTkBBDcOusbCvtJ/YHa1lThK3OfkiGVZ7HoZ3PyfXf1bxKDjCXtfq6 GchmCfJQlVlXUSTa4uVV7ll1ZtK78y5MWtHWBc3ETwPfA17WbLgISe2wP7LuLJt41N/g bIxlJUyTUiB3hxxgrttTosie+dwOXCAHko+SrzB6EDvOiyAmtX23ocACNnS7dQwtWEsn dQRg== 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 j27si7106649eja.41.2019.11.29.01.14.55; Fri, 29 Nov 2019 01:15:18 -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 S1726804AbfK2JNt (ORCPT + 99 others); Fri, 29 Nov 2019 04:13:49 -0500 Received: from foss.arm.com ([217.140.110.172]:45060 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725892AbfK2JNt (ORCPT ); Fri, 29 Nov 2019 04:13:49 -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 AB2BE30E; Fri, 29 Nov 2019 01:13:48 -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 C57BB3F68E; Fri, 29 Nov 2019 01:13:47 -0800 (PST) Date: Fri, 29 Nov 2019 09:13:45 +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: <20191129091344.hf5demtjytv5dw5q@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20191128210246.GJ2889@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/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. Thanks! -- Qais Yousef