Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp700844ybb; Fri, 20 Mar 2020 06:43:31 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvLXiNQKm5VkO/9hVUr1qtzCPxPd9OR3qSxxmpomRuJ25ineKDmgUMkU50I5otvXcjJJNQs X-Received: by 2002:aca:3dd7:: with SMTP id k206mr6565714oia.63.1584711811376; Fri, 20 Mar 2020 06:43:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584711811; cv=none; d=google.com; s=arc-20160816; b=J3ZRSXTOL5jZWRPdUZLslQMEJQRckaanG4myIc6YzyeO1EiQ4wWgOUfH6EMRwhB6dA rJwxV/NkFR/CTwNaFBZhSVMvEfNoedGPfjeBz2xVt2SkeRkwlcd0spiJjbxFXbdBeJiy GxvpsFY4veXA/jZf09tqRpnUZJVGqZt3Ox5ixcSpfLhIV9D6lRZU86cRMY42Oa43BAii XUHkxlz+Tjx+OpV3JJFUqOjsCCcH7wY7X6Whc0c7Dgn587loskLq5/HjnCGhCUuqvoLp 6SDz6paQh/pMctvW/HOnkWE+XLpcbvvQ6qjYvFgEbN2uB5AeJVX43LXYjttbNjqdI2+a oIrw== 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=AwbMOGyy2H6DRsn5Cz+n/+3i2DCJjALeJRuRX8VjO0Y=; b=GrpV7y75Rx8Y3aMVu9yaG5QfwmHOi7KNQhvPHQjNDbGu7ZWG/dDF9sr8JFFbK9jo+T mHlH8YaSsvThRkmWYDJ1W/QwQ61X5Jtjhaa/1OW8J0CKg9KaX/HNLx1qQl76/dLK94C8 PuR2Ndm74puQL+rGV/BaVuGVw7xHFjERjHPu7TrJR1Vdd8g7IbUTKU7vKJmkSQWqAhCq NFgcpLinShv/4/l1NYBYxD3lpCUNE/oUAA+UwP+Lodu2e2rAcPP/QYK7fXytGvGRZ7WE R71TG7GAifERvwR58qc8eQWqgU/ZXddyB7fn/lu23tR1K2kx0dCmCIS3yQgRghqJ1Rpc UUJg== 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 u3si3244897oth.152.2020.03.20.06.43.16; Fri, 20 Mar 2020 06:43:31 -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 S1727128AbgCTNld (ORCPT + 99 others); Fri, 20 Mar 2020 09:41:33 -0400 Received: from foss.arm.com ([217.140.110.172]:49098 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726843AbgCTNlc (ORCPT ); Fri, 20 Mar 2020 09:41:32 -0400 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 878161FB; Fri, 20 Mar 2020 06:41:32 -0700 (PDT) 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 BD3DC3F85E; Fri, 20 Mar 2020 06:41:31 -0700 (PDT) Date: Fri, 20 Mar 2020 13:41:29 +0000 From: Qais Yousef To: Russell King - ARM Linux admin Cc: "Paul E . McKenney" , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Thomas Gleixner Subject: Re: [PATCH v3 04/15] arm: Don't use disable_nonboot_cpus() Message-ID: <20200320134129.5udel4nplzgcfzwc@e107158-lin.cambridge.arm.com> References: <20200223192942.18420-1-qais.yousef@arm.com> <20200223192942.18420-5-qais.yousef@arm.com> <20200320110430.jozfyrqqx272266u@e107158-lin.cambridge.arm.com> <20200320130700.GR25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200320130700.GR25745@shell.armlinux.org.uk> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/20/20 13:07, Russell King - ARM Linux admin wrote: > On Fri, Mar 20, 2020 at 11:04:31AM +0000, Qais Yousef wrote: > > On 02/23/20 19:29, Qais Yousef wrote: > > > disable_nonboot_cpus() is not safe to use when doing machine_down(), > > > because it relies on freeze_secondary_cpus() which in turn is > > > a suspend/resume related freeze and could abort if the logic detects any > > > pending activities that can prevent finishing the offlining process. > > > > > > Beside disable_nonboot_cpus() is dependent on CONFIG_PM_SLEEP_SMP which > > > is an othogonal config to rely on to ensure this function works > > > correctly. > > > > > > Use `reboot_cpu` variable instead of hardcoding 0 as the reboot cpu. > > I think that should be a separate change - you have two separate > changes in this patch: > > 1. to switch to using the new helper. > 2. to change the CPU that we potentially use for the final steps of > shutdown > > These should be two seperate changes, so if (2) causes a regression > it can be reverted independently of (1). Okay will do. Thanks -- Qais Yousef > > > > > > > Signed-off-by: Qais Yousef > > > CC: Russell King > > > CC: linux-arm-kernel@lists.infradead.org > > > CC: linux-kernel@vger.kernel.org > > > --- > > > > Hi Russel > > > > Does the updated version look good to you now? > > > > Thanks > > > > -- > > Qais Yousef > > > > > arch/arm/kernel/reboot.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/arch/arm/kernel/reboot.c b/arch/arm/kernel/reboot.c > > > index bb18ed0539f4..0ce388f15422 100644 > > > --- a/arch/arm/kernel/reboot.c > > > +++ b/arch/arm/kernel/reboot.c > > > @@ -88,11 +88,11 @@ void soft_restart(unsigned long addr) > > > * to execute e.g. a RAM-based pin loop is not sufficient. This allows the > > > * kexec'd kernel to use any and all RAM as it sees fit, without having to > > > * avoid any code or data used by any SW CPU pin loop. The CPU hotplug > > > - * functionality embodied in disable_nonboot_cpus() to achieve this. > > > + * functionality embodied in smp_shutdown_nonboot_cpus() to achieve this. > > > */ > > > void machine_shutdown(void) > > > { > > > - disable_nonboot_cpus(); > > > + smp_shutdown_nonboot_cpus(reboot_cpu); > > > } > > > > > > /* > > > -- > > > 2.17.1 > > > > > > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 10.2Mbps down 587kbps up