Received: by 10.192.165.148 with SMTP id m20csp21975imm; Thu, 26 Apr 2018 15:10:20 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+1UjBlbNW70G+mH1OlLebD73vDlJIJJIGIK/SxGoGYL1A4+ZBdBB+Z9S8LUWTJVLS02PpC X-Received: by 2002:a17:902:5ac6:: with SMTP id g6-v6mr34576928plm.262.1524780620917; Thu, 26 Apr 2018 15:10:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524780620; cv=none; d=google.com; s=arc-20160816; b=A9S2avriBHHBXBkI+IGxI7Z+wUF/UZprxE17XiB8y9XmzsPSZpfvuW+6qRkGaB6uBo +n73/sbLBgXUG4/5T0//H8Gfo3vkAE2joS+KRjzhS98WLSfmMErIUpQCwV28K3nvWtJw SXLM0G9yMKJS+0GJjidGjlCsLGZaP5L3Vp7hRxYfgOIE7kqlvNO/UtqXXSyfdsjKgrT6 34GIlDWTkpDuRm09pTFlEIAGe0yd2+8C8qtH48iQIvaZhfBVgg5hwIJSGzzDbP0nqBIT xmpzdHKoRpic7aOojUqJyFeJcwBKdy1yDPX8rF7RPMfY5LZkjSqjDbLpF3N+aZ3RUs1u 5t5A== 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 :arc-authentication-results; bh=w34Y8T5w/Ubc71rB62EP1ijTcmEBfUe8LBk83tgGcp8=; b=vC1rb1w1UDFdMOH3vG805uZlyhY87t1WXVBwDyCD3OZpLXi7Fq7EQqJ/p0fgMqKylB +31z5IWvlnPtxIBQ1ZjGjnfbTLd2ofYFWenjqVlMicB1shzdd6rvbuz4NO5GAX/VSla8 oRp7JtLaRMAZdHeEf2yKDqYwPcZUB9QOimso1JaGdrSIXEvItOLe9ln77xwt4bdpzWAA XXVGgAWpSlivdWte1ZpvYufrbAIN7GGrbVNEI+NKPklmjcPEG5Hrsh9D2cWoNuoUE1JR bK8xwHt27f3nFp3xy6bseVuoAp6PuDQXd24UsYnrRd6ZIjZoN06NITZR3QrZBuOsZZO0 Hp0A== 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 131si18983117pfa.246.2018.04.26.15.10.01; Thu, 26 Apr 2018 15:10:20 -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 S1757111AbeDZWIt (ORCPT + 99 others); Thu, 26 Apr 2018 18:08:49 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:50440 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754777AbeDZWIs (ORCPT ); Thu, 26 Apr 2018 18:08:48 -0400 Received: from p5492e61e.dip0.t-ipconnect.de ([84.146.230.30] helo=nanos.glx-home) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1fBp4H-0004jp-9W; Fri, 27 Apr 2018 00:08:45 +0200 Date: Fri, 27 Apr 2018 00:08:44 +0200 (CEST) From: Thomas Gleixner To: "K. Y. Srinivasan" cc: x86@kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, devel@linuxdriverproject.org, olaf@aepfle.de, apw@canonical.com, jasowang@redhat.com, hpa@zytor.com, sthemmin@microsoft.com, Michael.H.Kelley@microsoft.com, vkuznets@redhat.com Subject: Re: [PATCH 2/5] X86: Hyper-V: Enable IPI enlightenments In-Reply-To: <20180425181250.8740-2-kys@linuxonhyperv.com> Message-ID: References: <20180425181110.8683-1-kys@linuxonhyperv.com> <20180425181250.8740-1-kys@linuxonhyperv.com> <20180425181250.8740-2-kys@linuxonhyperv.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 On Wed, 25 Apr 2018, kys@linuxonhyperv.com wrote: > +static int __send_ipi_mask(const struct cpumask *mask, int vector) > +{ > + int cur_cpu, vcpu; > + struct ipi_arg_non_ex **arg; > + struct ipi_arg_non_ex *ipi_arg; > + int ret = 1; So this indicates whether __send_ipi_mask() can send to @mask or not. So please make it a bool and let it return false when it does not work, true otherwise. If you had used -Exxxx then it would have been more obvious, but this is really a boolean decision. > + unsigned long flags; > + > + if (cpumask_empty(mask)) > + return 0; > + > + if (!hv_hypercall_pg) > + return ret; > + > + if ((vector < HV_IPI_LOW_VECTOR) || (vector > HV_IPI_HIGH_VECTOR)) > + return ret; > + > + local_irq_save(flags); > + arg = (struct ipi_arg_non_ex **)this_cpu_ptr(hyperv_pcpu_input_arg); > + > + ipi_arg = *arg; > + if (unlikely(!ipi_arg)) > + goto ipi_mask_done; > + > + Stray newline > + ipi_arg->vector = vector; > + ipi_arg->reserved = 0; > + ipi_arg->cpu_mask = 0; > + > + for_each_cpu(cur_cpu, mask) { > + vcpu = hv_cpu_number_to_vp_number(cur_cpu); > + if (vcpu >= 64) > + goto ipi_mask_done; This is completely magic and deserves a comment. > + > + __set_bit(vcpu, (unsigned long *)&ipi_arg->cpu_mask); > + } > + > + ret = hv_do_hypercall(HVCALL_SEND_IPI, ipi_arg, NULL); > + > +ipi_mask_done: > + local_irq_restore(flags); > + return ret; > +} .... > static int hv_cpu_init(unsigned int cpu) > { > u64 msr_vp_index; > struct hv_vp_assist_page **hvp = &hv_vp_assist_page[smp_processor_id()]; > + void **input_arg; > + > + input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg); > + *input_arg = page_address(alloc_page(GFP_ATOMIC)); This is called from the cpu hotplug thread and there is no need for an atomic allocation. Please use GFP_KERNEL. > hv_get_vp_index(msr_vp_index); > > @@ -217,6 +224,10 @@ static int hv_cpu_die(unsigned int cpu) > { > struct hv_reenlightenment_control re_ctrl; > unsigned int new_cpu; > + void **input_arg; > + > + input_arg = (void **)this_cpu_ptr(hyperv_pcpu_input_arg); > + free_page((unsigned long)*input_arg); Hrm. Again this is called from the CPU hotplug thread when the cou is about to go down. But you can be scheduled out after free() and before disabling the assist thing below and the pointer persist. There is no guarantee that nothing sends an IPI anymore after this point. So you have two options here: 1) Disable interrupts, get the pointer, set the per cpu pointer to NULL, reenable interruots and free the page 2) Keep the page around and check for it in the CPU UP path and avoid the allocation when the CPU comes online again. > if (hv_vp_assist_page && hv_vp_assist_page[cpu]) > wrmsrl(HV_X64_MSR_VP_ASSIST_PAGE, 0); > @@ -260,6 +271,12 @@ void __init hyperv_init(void) > if ((ms_hyperv.features & required_msrs) != required_msrs) > return; > > + /* Allocate the per-CPU state for the hypercall input arg */ > + hyperv_pcpu_input_arg = alloc_percpu(void *); > + > + if (hyperv_pcpu_input_arg == NULL) > + return; Huch. When that allocation fails, you return and ignore the rest of the function which has been there before. Weird decision. Thanks, tglx