From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4612C11D00 for ; Fri, 21 Feb 2020 00:26:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9E320206EF for ; Fri, 21 Feb 2020 00:26:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582244778; bh=CLYAumZ3ce877LEKU8KuyZT0P7iDSwE2QUSVz1GNFmM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:List-ID: From; b=wbG+TsFZSBljvQqcEmiiOAwD9rvsOJWd0Zcf/whBPpns+3tMxRZ3Jswf3daLad3RE hZxcXAUTaJRjJHncIds1uhCyszOwDfTef2IGLSYApnU9YL1jbn28HxDZCbCKZYOw0/ wmyvuj8K9DUM+CCkwrQr2v5eI7Z3TFALULqNxO9c= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729456AbgBUA0R (ORCPT ); Thu, 20 Feb 2020 19:26:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:42486 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729413AbgBUA0R (ORCPT ); Thu, 20 Feb 2020 19:26:17 -0500 Received: from paulmck-ThinkPad-P72.home (50-39-105-78.bvtn.or.frontiernet.net [50.39.105.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 63626206DB; Fri, 21 Feb 2020 00:26:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582244776; bh=CLYAumZ3ce877LEKU8KuyZT0P7iDSwE2QUSVz1GNFmM=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=KeM+GMOrFH0n1PDQaAaKJVEmwkr8BcF9DGfFI+EPltjB9CHzUP7QgrtOqXtKJOOMm MSVIbFT50LSv7gohTO2bWZZlV0Oan38a4+Hv3VIUjygW/j32V8ZiWPs/AJ7VkLmaI/ 1RTH8iHrL38P00ggHONkXWowfvqAD4up3nzE9/ak= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 385CC35208E2; Thu, 20 Feb 2020 16:26:16 -0800 (PST) Date: Thu, 20 Feb 2020 16:26:16 -0800 From: "Paul E. McKenney" To: Qais Yousef 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: <20200221002616.GB2935@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org 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> <20200220153159.mzpagvbwptxlehvd@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200220153159.mzpagvbwptxlehvd@e107158-lin.cambridge.arm.com> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 20, 2020 at 03:31:59PM +0000, Qais Yousef wrote: > 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! OK, I will bite... Why not right now? Thanx, Paul