Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp838028ybb; Thu, 28 Mar 2019 13:13:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqzqsEk8onl88Il4nHIw50DrwJfpNpuChTLURSh1xLAuiWqs9f/3uucLrJ0d/EDTbRmRLQ3N X-Received: by 2002:a17:902:848c:: with SMTP id c12mr44504626plo.207.1553804013987; Thu, 28 Mar 2019 13:13:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553804013; cv=none; d=google.com; s=arc-20160816; b=na0YyGMBc/DNRzbptcbduQYcvu6Y1O0ZsySxExJjPDusRjJksJqIUe94BPEY0oRKOs XjNMCvYFhQltL2PyCibQ69WzD1ctQmnbRPMupjnZ5+z/WQP6YfnUpT0xPLjE2Ine+alX jmOhFK4R2TMDg0Tlw7BMVb5SjqfH87sDqbSNw35FDVqBlYTjvnWB59WlDsnXlniTZbUL Rc06G/+BhVKQDY5PjHHx+12fKmvcj41rr7YvprrXOrRGEsPGdVruBF7OR5Xh87gfvRxp /mxZqiJ8YPw7i3DzOJj6qTNeB18ua8NdfLr1rtHsSIWZ8ZjluQ0LiImIjbW0ta6WMd+v xdCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=dvXIOd51EasZ1OO2rywIQIP9fZu4Y2XpMOjIB/N8/YY=; b=a5RWjJKQ6WGWoiuECXgCq8TeAHmV7mqlIuk0bx3ny0jBMbDzQfVyQKN5hfcuNxdxDr YwfuOJczDFnLxDahej3g0Uy25xR7lM9ttHdQ2AjfIN/y7bNGUW6eNL9mtBTbMJYqFM41 bUR4WuYQvE0B4fArY/Tea+pFrYioDnNQbuHxxGahOZsYsCT4HpJOMVUpkg4Vn5teMxUR M8z8UR6CJugY1P+XVIqAjvMatpuDvuq23Qa2dgdICInBg82LQ/7qioKl5B1100XlZIGB JP6MA+9JwRE/p4dAWtvQfW3H0zxHHziVRvUZaAF4yVzbkQuNrcNN/9aTIFl4PDyKt+dT KruQ== 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 o61si33965pld.280.2019.03.28.13.13.17; Thu, 28 Mar 2019 13:13:33 -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 S1726250AbfC1UMb (ORCPT + 99 others); Thu, 28 Mar 2019 16:12:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:44006 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726165AbfC1UMb (ORCPT ); Thu, 28 Mar 2019 16:12:31 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 1CEED206BA; Thu, 28 Mar 2019 20:12:30 +0000 (UTC) Date: Thu, 28 Mar 2019 16:12:28 -0400 From: Steven Rostedt To: Doug Anderson Cc: Pavel Machek , Sasha Levin , LKML , stable@vger.kernel.org Subject: Re: [PATCH AUTOSEL 5.0 011/262] tracing: kdb: Fix ftdump to not sleep Message-ID: <20190328161228.24f5aabd@gandalf.local.home> In-Reply-To: References: <20190327180158.10245-1-sashal@kernel.org> <20190327180158.10245-11-sashal@kernel.org> <20190328101342.GD19456@atrey.karlin.mff.cuni.cz> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 28 Mar 2019 12:45:18 -0700 Doug Anderson wrote: > > I see solution is simple, but now we have a loop with GFP_ATOMIC > > allocations inside. How many "tracing spus" is this expected to loop > > over? Will not it exhaust atomically available pages and reliably fail > > in common configurations? > > Pavel > > Each one of these allocations is ~32 bytes and you do one per CPU. > Even with systems with a lot of CPUs that's not going to be tons. > ...and you only do it with GFP_ATOMIC when you're actively dropped > into kdb and debugging. It seems like going for simplicity is the > right call here, but of course if Steven or Daniel say that it has to > be done a different way then they're the true authorities. I really don't care. The code in question is only affected when we have CONFIG_KGDB_KDB enabled. But as it gets called from an atomic context, is it any different than what it was doing before? Except now with GFP_ATOMIC it is actually safer. Now, we could add some helper functions in the ring-buffer code to allow us to pre-allocate the ring_buffer_iter at boot up. Then we could pass in the per-allocated iters and use them here. -- Steve