Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp445525imd; Sat, 3 Nov 2018 03:45:54 -0700 (PDT) X-Google-Smtp-Source: AJdET5exd4wPn4BpzSDT/Y10lqiA9+zx96QBej62QARmqpUi4RCrrRj4IBuHRWKO/uMl9QDZ+S1+ X-Received: by 2002:a17:902:e101:: with SMTP id cc1-v6mr15138343plb.165.1541241954504; Sat, 03 Nov 2018 03:45:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541241954; cv=none; d=google.com; s=arc-20160816; b=jm65/9rUPgtZFkCiO9A8j79hDqkF0qzfLPOlZKF3nNKsOy87TaJvoz8cxMnpsh8dfM yLnkisbIM4of9d4SOwlWhYXauvKecixEve+yXDG5FXT3FcUtwBs7L+VHa4keVteBIFzb BASRM1uY7GQf2LBehfJZ605AGcaWMaUvz0P4DVGkr/h0XoFWSJ6p7Fdvh5wMaKztc/Zq 0J972Tm9RK2POFAJuap1wAk2h5dpvD2icBBusdScgx51RR4ohnmBscJjXErcMvHF4eqp zfVpryC62ngtTcRC/iHo4+kZezZjvrMR+cVza3tCKSKPVlrv7oQwktSKjbE9aUeNi3gl yxUg== 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:dkim-signature; bh=YmQq90FRkqBQp0/v6HvhwKCbNPsiefsFk4oklN2EcKs=; b=jQethq9akUrrlVPTqcll7cGpZ/UtCS6rF0/D9q5QQdiJWQ3zjnKXOx1s3rO7+I10xX J4uCf7IhhCrZXXrdRf/Pv/SLMRW8XVEYCbq2iK96rDm6l0pnoLkCWe7MpizSG74srrjW DFHDe4896cCbxCtxkWHgN1H4vtxXMlFepdHfbaajzt2Dc95DkpRQJYi/xMVWIKSWeax6 ZQF1f2zyMaFWymqNzDn+2Za4ReVBm3N0uyW2iciPX9kz0HMGlZU6xp4IT/2yN118wS1T nblZ7dl4BuSLGHD3mTdQj64FIn2IpUDglvcYtJe2ZQomqxw/YY1wkPBFMOsXLjDsWZqO Qc+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=MHB0y0Ya; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s17si201413pgi.513.2018.11.03.03.45.39; Sat, 03 Nov 2018 03:45:54 -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=@linaro.org header.s=google header.b=MHB0y0Ya; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728444AbeKCT4L (ORCPT + 99 others); Sat, 3 Nov 2018 15:56:11 -0400 Received: from mail-wm1-f65.google.com ([209.85.128.65]:35040 "EHLO mail-wm1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727007AbeKCT4K (ORCPT ); Sat, 3 Nov 2018 15:56:10 -0400 Received: by mail-wm1-f65.google.com with SMTP id q12-v6so3844777wmq.0 for ; Sat, 03 Nov 2018 03:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=YmQq90FRkqBQp0/v6HvhwKCbNPsiefsFk4oklN2EcKs=; b=MHB0y0YaXByvjwLMoonMq5QIjx9CsU+rAU+j5poaVTafUlBxWYiuUEF8m8kd6fUby4 QmIDj233bXRVK/YHOYnKiwKvCqqeDu+b+pcNNyGTzoUDVA4Y5GFMOGiovxZt7wz4jmyt xJjWXL3cZPHkutGq/DuKCnwo4rBDuc8nFlcaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=YmQq90FRkqBQp0/v6HvhwKCbNPsiefsFk4oklN2EcKs=; b=swtXKW26EaT/AsaStrUW2UZMu3sWl8iO4Wd9aSnRselvIEluZmVoHw2S/FO86rRf7g Bs/kBglGz5B0HWaKiLk9RrMTkUAj5xGPKjzHHFtk1STDpKWHMNLLPYKMqvaQiGIIEB+n bFBSHzZdEORD+IGNxxt8NrQZpmdeSrgr2ZHh3ALOqVxhqwmytXx7Xwpao42g7fL0Hju7 /3DCtWKQWbuhpb82dZtPWZ+33rY3H2CeNa+R+xEtNDpZLGXua67pNsIt8EuZypqKGtFQ 0O723bq44iaCuiDFcQoygzTh7OS/C0TWhoRcMi1j7zZKCzbk6NxaMSvVg/J/6bptXLpl 6HYw== X-Gm-Message-State: AGRZ1gI5va3c8h4jZOfJx7dYF9S9pPu0Ya9rkpftUZo4G+CEi/fRTX88 dC/ise5uhITPxE82v3FGa6WzJQ== X-Received: by 2002:a1c:2283:: with SMTP id i125-v6mr601230wmi.42.1541241914508; Sat, 03 Nov 2018 03:45:14 -0700 (PDT) Received: from holly.lan (82-132-212-57.dab.02.net. [82.132.212.57]) by smtp.gmail.com with ESMTPSA id o9-v6sm44092322wra.42.2018.11.03.03.45.11 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 03 Nov 2018 03:45:13 -0700 (PDT) Date: Sat, 3 Nov 2018 10:45:03 +0000 From: Daniel Thompson To: Doug Anderson 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 Subject: Re: [PATCH v2 2/2] kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function() Message-ID: <20181103104503.eftn5btx7otgufro@holly.lan> References: <20181030221843.121254-1-dianders@chromium.org> <20181030221843.121254-3-dianders@chromium.org> <20181031184050.sd5opni3mznaapkv@holly.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 31, 2018 at 02:41:14PM -0700, Doug Anderson wrote: > > 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. Whilst it is very tempting to make a sarcastic reply here ("Of course! What kgdb really needs is yet another set of condition variables") I can't because I actually agree with the proposal. I don't really want kgdb to be too "special" especially when it doesn't need to be. Only thing to note is that rounding_up will not be manipulated within a common spin lock so you might have to invest a bit of thought to make sure any races between the master and slave as the slave CPU clears the flag are benign. Daniel.