Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp71361imd; Wed, 31 Oct 2018 14:51:57 -0700 (PDT) X-Google-Smtp-Source: AJdET5cX2QnZ61ySKcnztVh0H7vs+BvhdOG+I7DC9ALorIWd5tY+kvQEHOP82W4WVC/EBvHnx6tU X-Received: by 2002:a62:5cc4:: with SMTP id q187-v6mr5033508pfb.47.1541022717739; Wed, 31 Oct 2018 14:51:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541022717; cv=none; d=google.com; s=arc-20160816; b=Mavt0ixcgzSd3WqJmM97gjoDsYaCGPuvXP+VQn9x6at++TRM4yWXpDw6Z4W5Kvof0t Licq6i3kXRoXVCBiiX27fUHDK/NMY1gTK3uTJ12617RUwCeeO/320NSTLMVA84LWRkuW zMGIwjzImbL/onuBdCPJfY3TmguwPnsB9+hCENihngMIdP7ohJYTZe86q1+qRxv7ZAwz DUX0O3qlF+74ENrGyXGitAWzLpkbeahmxnoeyyyHLoyJ/7qM+xWhPnOaszm2nurdauWb eyh8z46cs4ZAyYafYVtdHFlAB7PQFqwVx2l1kfk438cmSh9QCNaPu7fcrHzTvcPiVIF7 mpSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=9OZBU7xBbZRq91LmWRsKb1e+HamrGUSqJjfkZGsW5iY=; b=KIlBcoiLoscNGquYbH9fWWIJZo7/c0wDksk5uVOWoZVaIcyWfkA+8XEKtg5cKJLwlj 7p2YI6C3J4P5cCoZhK0321qVhrdpI7dczqAXdjrWG7wZ8z7dYtRQvWuhcif/R6wRS5hO fLtxeIktDVd8JhS3yXCglRlTZVWOIePxzifuGFFeoKZoHB0U0q+nd10veP9MJQeZXoGm pKWO/wT3qCZU2w7ZSLKrUEG95aUD/5H1pucMgjjL5qVUA/WwqG6qCaADw0OTVcs9XDBR TyRbha2zjbgTHJL1D1SdHDvefTOO2oEObQCdyAZ+J9J5SHJuNuUfQITKtKKYqK+tpk5C E2Ug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=hRfi3Kd5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n1si119502pgh.172.2018.10.31.14.51.42; Wed, 31 Oct 2018 14:51:57 -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; dkim=pass header.i=@chromium.org header.s=google header.b=hRfi3Kd5; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726329AbeKAGt3 (ORCPT + 99 others); Thu, 1 Nov 2018 02:49:29 -0400 Received: from mail-vk1-f193.google.com ([209.85.221.193]:43407 "EHLO mail-vk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725919AbeKAGt3 (ORCPT ); Thu, 1 Nov 2018 02:49:29 -0400 Received: by mail-vk1-f193.google.com with SMTP id g144so2847918vke.10 for ; Wed, 31 Oct 2018 14:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9OZBU7xBbZRq91LmWRsKb1e+HamrGUSqJjfkZGsW5iY=; b=hRfi3Kd5G9/BLYolaPFaixRBSy8QElOUfTm0fyNwi5G2el/3A087MYoMPAXTtCvmr6 aqtzB3yUpqwbaMtfyXn9KPe/xCBryhqzS5lXRDQiilI7KlDKS9tpNMeE3EhIpseZtToC y5ZSqIZ1fBG/MJmna3J4vq+E8lJ01mfbgfTEg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9OZBU7xBbZRq91LmWRsKb1e+HamrGUSqJjfkZGsW5iY=; b=T2Lys1QeezHoBxc4f0qTBGM1w7UHv6W+Nzm/FaRe8uceg5VSIbLw7orWI7CwZN+Lcl NbwfUfnELos0jxNv5n3h8C3Nz+DcfBVfz6vDMh+te2Z2dt92nCgHHOiZVOPakQZzDnAn Lvsu5/JNOIYvkpKzaGduBOdEHfJLPI/eReGyMv00OYkCDmz9/eIDNmwytLD7KUIm59TJ daDKIZRarXW1YJswe7ugzCbNjS/Gip4dXNUN9DyBI+58BuKUr4D/xx66qavhRZIyKYRF YnhNkRfboKClR/IOXeQ0EbZh5bBkFnpH63wd1bY1NLfue28zyGmTu8uuW82K+KnMClcC ozsA== X-Gm-Message-State: AGRZ1gJ1kIrPUacasSbcm1fs7IzhZOlEqgaNlwUTL5zdjXY7yaOqW/20 zzNfWDlyPAaZC3rs+8DGkbcBKs+cwbI= X-Received: by 2002:a1f:1d4b:: with SMTP id d72-v6mr2130600vkd.34.1541022573666; Wed, 31 Oct 2018 14:49:33 -0700 (PDT) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com. [209.85.217.47]) by smtp.gmail.com with ESMTPSA id p191-v6sm4337622vkd.23.2018.10.31.14.49.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Oct 2018 14:49:33 -0700 (PDT) Received: by mail-vs1-f47.google.com with SMTP id q15so11063341vso.1 for ; Wed, 31 Oct 2018 14:49:33 -0700 (PDT) X-Received: by 2002:a67:6642:: with SMTP id a63mr2174631vsc.42.1541022087194; Wed, 31 Oct 2018 14:41:27 -0700 (PDT) MIME-Version: 1.0 References: <20181030221843.121254-1-dianders@chromium.org> <20181030221843.121254-3-dianders@chromium.org> <20181031184050.sd5opni3mznaapkv@holly.lan> In-Reply-To: <20181031184050.sd5opni3mznaapkv@holly.lan> From: Doug Anderson Date: Wed, 31 Oct 2018 14:41:14 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/2] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() To: Daniel Thompson Cc: Jason Wessel , kgdb-bugreport@lists.sourceforge.net, Peter Zijlstra , linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Greg Kroah-Hartman , Catalin Marinas , jhogan@kernel.org, linux-hexagon@vger.kernel.org, Vineet Gupta , Thomas Gleixner , Philippe Ombredanne , Kate Stewart , dalias@libc.org, Ralf Baechle , linux-snps-arc@lists.infradead.org, Yoshinori Sato , Benjamin Herrenschmidt , Will Deacon , paulus@samba.org, Russell King - ARM Linux , Linux ARM , christophe.leroy@c-s.fr, mpe@ellerman.id.au, paul.burton@mips.com, LKML , rkuo@codeaurora.org, linuxppc-dev Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wed, Oct 31, 2018 at 11:40 AM Daniel Thompson wrote: > > On Tue, Oct 30, 2018 at 03:18:43PM -0700, Douglas Anderson wrote: > > diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c > > index f3cadda45f07..9a3f952de6ed 100644 > > --- a/kernel/debug/debug_core.c > > +++ b/kernel/debug/debug_core.c > > @@ -55,6 +55,7 @@ > > #include > > #include > > #include > > +#include > > > > #include > > #include > > @@ -220,6 +221,39 @@ int __weak kgdb_skipexception(int exception, struct pt_regs *regs) > > return 0; > > } > > > > +/* > > + * Default (weak) implementation for kgdb_roundup_cpus > > + */ > > + > > +static DEFINE_PER_CPU(call_single_data_t, kgdb_roundup_csd); > > + > > +void __weak kgdb_call_nmi_hook(void *ignored) > > +{ > > + kgdb_nmicallback(raw_smp_processor_id(), get_irq_regs()); > > +} > > + > > +void __weak kgdb_roundup_cpus(void) > > +{ > > + call_single_data_t *csd; > > + int cpu; > > + > > + for_each_cpu(cpu, cpu_online_mask) { > > + csd = &per_cpu(kgdb_roundup_csd, cpu); > > + smp_call_function_single_async(cpu, csd); > > + } > > smp_call_function() automatically skips the calling CPU but this code does > not. It isn't a hard bug since kgdb_nmicallback() does a re-entrancy > check but I'd still prefer to skip the calling CPU. I'll incorporate this into the next version. > As mentioned in another part of the thread we can also add robustness > by skipping a cpu where csd->flags != 0 (and adding an appropriately > large comment regarding why). Doing the check directly is abusing > internal knowledge that smp.c normally keeps to itself so an accessor > of some kind would be needed. Sure. I could add smp_async_func_finished() that just looked like: int smp_async_func_finished(call_single_data_t *csd) { return !(csd->flags & CSD_FLAG_LOCK); } My understanding of all the mutual exclusion / memory barrier concepts employed by smp.c is pretty weak, though. I'm hoping that it's safe to just access the structure and check the bit directly. ...but do you think adding a generic accessor like this is better than just keeping track of this in kgdb directly? I could avoid the accessor by adding a "rounding_up" member to "struct debuggerinfo_struct" and doing something like this in roundup: /* If it didn't round up last time, don't try again */ if (kgdb_info[cpu].rounding_up) continue kgdb_info[cpu].rounding_up = true smp_call_function_single_async(cpu, csd); ...and then in kgdb_nmicallback() I could just add: kgdb_info[cpu].rounding_up = false In that case we're not adding a generic accessor to smp.c that most people should never use. I'll wait to hear back from you if you think the accessor is OK. It seems like it might be nice not to have to add something to smp.c just for this one use case. > > +} > > + > > +static void kgdb_generic_roundup_init(void) > > +{ > > + call_single_data_t *csd; > > + int cpu; > > + > > + for_each_possible_cpu(cpu) { > > + csd = &per_cpu(kgdb_roundup_csd, cpu); > > + csd->func = kgdb_call_nmi_hook; > > + } > > +} > > I can't help noticing this code is very similar to kgdb_roundup_cpus. Do > we really gain much from ahead-of-time initializing csd->func? Oh! Right... At first I thought about just trying to put the "csd" on the stack in kgdb_roundup_cpus() but then I realized that it needed to persist past the end of kgdb_roundup_cpus(). ...and once I gave up on the idea of putting it on the stack I decided I needed the init. ...but you're right that I don't really. The only thing I'm initting is the function pointer and it totally wouldn't hurt to just init that over and over again every time kgdb_roundup_cpus() is called. -Doug