Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp10913741ybi; Thu, 25 Jul 2019 07:01:12 -0700 (PDT) X-Google-Smtp-Source: APXvYqwVw3hevV2B5L3dfKW9KJ/48f67oLQf2mP7dYitsuMeXj4XzR9A0/QJpag/Deg8m4GfMtXO X-Received: by 2002:a63:5a4d:: with SMTP id k13mr83887380pgm.174.1564063272259; Thu, 25 Jul 2019 07:01:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564063272; cv=none; d=google.com; s=arc-20160816; b=WBUaSm64ZZhrOzKTIB+BaVXJ88pZvDY9zeLKh4V/rlVdc+RGJGUtN1X8Dy8VjP7JMC GlORJYdOCvu0N2llnw+Uq0ApAqzhg2CfswTOG/u3q9wUCuvWfRw/mKUSoKUqD1XMoXIj cWVOMR2q0FDuFt8W4wFRENujhkj3tM6ll7ivlEXcX6foCgovYnym8CYgKYIQOYWCYHsv ThcyEMn2xMNhP66u+O+2QDGJq2a+S8mGxwVcr6PTNSd5UrqNFzO1OGzZtrA64UPgugzq U/+YoezQBVjMb5UvYeuOhxHawBXTnrQX58xyxKfDBnectyjfDx6J2Bpva2QqE2adUL+R IKHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=zU4fMLfanrZVzej9pJoZjnY5+aK/lvuN4gbv7A5Lq4I=; b=yL1/+ZCiKcC2vQx/0bTsaxQGdh+mvgVA+/hdGKdnpZuqs4Q0Edf6SJAbF65Djy+Is+ gHkUhWGCeez7/MO0Hu9pcBdwjcOfFspNnXNEhAsODt26duolSKS9QYPGinVCBGWHbi4o pD7cnIIhDUnW3Zw9lPKpvjfbc2m+OxingJzehuGuVCDpZDdLvzayRjTjSR6kzkq2KsHf scuWtdvd2SYYBsH8v0J+ix/PmsG9AuPPqkkdLj/VFT7Gs5bOqjaTenzKzBNeNeI67+9u gBdEhHHCdaqPgV4oVJ71vWpuNAxIplFr6B2YxiYTmyaigGgxORaLe1O/ekWPIHCLgTcg 52Xw== 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 g10si16365313pjp.74.2019.07.25.07.00.55; Thu, 25 Jul 2019 07:01:12 -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 S2387820AbfGYMg1 (ORCPT + 99 others); Thu, 25 Jul 2019 08:36:27 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:46288 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729381AbfGYMg0 (ORCPT ); Thu, 25 Jul 2019 08:36:26 -0400 Received: from pd9ef1cb8.dip0.t-ipconnect.de ([217.239.28.184] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hqcyn-0004iy-7h; Thu, 25 Jul 2019 14:36:17 +0200 Date: Thu, 25 Jul 2019 14:36:15 +0200 (CEST) From: Thomas Gleixner To: Nadav Amit cc: Peter Zijlstra , Andy Lutomirski , Dave Hansen , the arch/x86 maintainers , LKML , Ingo Molnar , Rik van Riel , Josh Poimboeuf Subject: Re: [PATCH v3 1/9] smp: Run functions concurrently in smp_call_function_many() In-Reply-To: <93A98E8B-764F-4E9F-B0B6-FDAABE822B2D@vmware.com> Message-ID: References: <20190719005837.4150-1-namit@vmware.com> <20190719005837.4150-2-namit@vmware.com> <20190722182159.GB6698@worktop.programming.kicks-ass.net> <91940019-826C-4F33-904B-0767D95A5E21@vmware.com> <93A98E8B-764F-4E9F-B0B6-FDAABE822B2D@vmware.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323329-1554082241-1564058177=:1791" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1554082241-1564058177=:1791 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Mon, 22 Jul 2019, Nadav Amit wrote: > > On Jul 22, 2019, at 11:51 AM, Thomas Gleixner wrote: > > void on_each_cpu(void (*func) (void *info), void *info, int wait) > > { > > unsigned long flags; > > > > preempt_disable(); > > smp_call_function(func, info, wait); > > > > smp_call_function() has another preempt_disable as it can be called > > separately and it does: > > > > preempt_disable(); > > smp_call_function_many(cpu_online_mask, func, info, wait); > > > > Your new on_each_cpu() implementation does not. So there is a > > difference. Whether it matters or not is a different question, but that > > needs to be explained and documented. > > Thanks for explaining - so your concern is for CPUs being offlined. > > But unless I am missing something: on_each_cpu() calls __on_each_cpu_mask(), > which disables preemption and calls __smp_call_function_many(). > > Then __smp_call_function_many() runs: > > cpumask_and(cfd->cpumask, mask, cpu_online_mask); > > … before choosing which remote CPUs should run the function. So the only > case that I was missing is if the current CPU goes away and the function is > called locally. > > Can it happen? I can add documentation and a debug assertion for this case. I don't think it can happen: on_each_cpu() on_each_cpu_mask(....) preempt_disable() __smp_call_function_many() So if a CPU goes offline between on_each_cpu() and preempt_disable() then there is no damage. After the preempt_disable() it can't go away anymore and the task executing this cannot be migrated either. So yes, it's safe, but please add a big fat comment so future readers won't be puzzled. Thanks, tglx --8323329-1554082241-1564058177=:1791--