Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp817060ybb; Thu, 28 Mar 2019 12:46:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwZMGYKgGYg3oK5fzBcBbK02TcPtPVHEDNHFhixy2saTEwDVZ56dSIuE6KSEnza9pSxRrTv X-Received: by 2002:a63:5149:: with SMTP id r9mr3082888pgl.177.1553802394271; Thu, 28 Mar 2019 12:46:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553802394; cv=none; d=google.com; s=arc-20160816; b=c5V+Q8V81EP6qHpl+tV6PncKwGcruemGFNVXR3w5G8gQXagp+S9N7i3VM5bqvz6pEY ckKUVax/13Vxkc+uSQLhBVeCY3+qQUaCniYUKfTottQGbfTJ3HKsFMfdXVt5XoMpoeFQ lKkI9BY8FNbxpSvBloqhAukr4vED98TkYN2IqPz2Z89jHguu+T5S+t8IPfwNSlR7zZoh VcXivwzMCaXMmjSiHvlICDodS8rHTKB5nUok6LtQzueZjHQiwffBwDOwzJHbYB1rJ9O7 bzVhgB95J5RwhBn9OLdaIIiZ3A9ej2sJVN9ZlSbKElEhT5KRpCk+s8zm3WA/7+9aEl+Z 4VUw== 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=wrXcdpv8taoXdWmbhLrlOXzqdUnvgbeHD1ossKIFdic=; b=JrO5UZff27wbz5q+pPsRickuiddAcqpIrpbRIHNHx58QRkI7LuNYEubran4o16vP+X CpTTtJrt0GS4Lu1/rgUwiLckxQogYtkfKzg05ZAgvgiGI8/U5bZuGLpEJ/K8IFUHQ4Ed hJFYfUVfDPt5ZziA2iV7ZVzquLBMcE1o3hYZTNH0jDDg+DYmXdwV8UYuJf4QJ7Kd53vq HjO9Qpfa2qx87k62gGyDloD0IVRNU/+2XMFlw+tEqW+OHd6HjUzYD3ekfBtt7iLg4Wp9 SoWNRetiPzWcnzaHKc1hnT74Ckh9+h7SCH7B9iMCTS8t7HnTZ6HGBL4EfqSgzV2glh1t xR2g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=dqhrWjND; 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 31si22900227plg.364.2019.03.28.12.46.18; Thu, 28 Mar 2019 12:46:34 -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=dqhrWjND; 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 S1726214AbfC1Tpd (ORCPT + 99 others); Thu, 28 Mar 2019 15:45:33 -0400 Received: from mail-vs1-f66.google.com ([209.85.217.66]:38584 "EHLO mail-vs1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726076AbfC1Tpd (ORCPT ); Thu, 28 Mar 2019 15:45:33 -0400 Received: by mail-vs1-f66.google.com with SMTP id s2so11547218vsi.5 for ; Thu, 28 Mar 2019 12:45:32 -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=wrXcdpv8taoXdWmbhLrlOXzqdUnvgbeHD1ossKIFdic=; b=dqhrWjNDnpsE7owK5JQ52vNZ8OplZf/F+F4FvCy/ejeRSdm/dA4DfhJcQWIiV05ILp nSnNVnDYERrMWnFAxtXJ23SVhdFf5ettkKq4RhfAAOGt0dA3f/e4HeJOD8+DPSEuxyyT TQKMONB6Lsr+tjtV3cckmKpU54EcAW+GBffgY= 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=wrXcdpv8taoXdWmbhLrlOXzqdUnvgbeHD1ossKIFdic=; b=OKxim143FdBK3S8s5Na3d12PYNPNBSrkrEL9i7ZtJijCmeVL5b9/RA7F8LK3EIyDdK y/mzNJbxNgCVISog8JrE7SdeRV9OMbgHvC9WZFOW1XjV5PbNWDNIHjvUBOaDVZLURYJ1 YwgMjTzoZVDF+yXS3EZqpAbshBaGZE3PnsdqyixM4B+sgNoC24TDuVA+N3KhMUPWFF4g jF+Ry+jnn8Co88Ai9/vdiKfop8uwVxcK/zzj1xBN/I7+uueV5Ipts2E7AZ7Z6bctAlQy BBZh1MUfmdiyaNt4w9VnJ+cPEIPxZOG/hDbM4Y9gRgqm6R8LxyhbjTfPJA8wskWjhCcj /BQw== X-Gm-Message-State: APjAAAWUY2H4C5glsMR4Jaaq2Tul6tHZ9lNU0Kp5xR2L3iuML/+vrXVG QYfSz6yjt3b+GXUSmhC4xcltyUSfYM0= X-Received: by 2002:a67:f714:: with SMTP id m20mr25973645vso.211.1553802331669; Thu, 28 Mar 2019 12:45:31 -0700 (PDT) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com. [209.85.217.54]) by smtp.gmail.com with ESMTPSA id e135sm3258967vsd.27.2019.03.28.12.45.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 12:45:30 -0700 (PDT) Received: by mail-vs1-f54.google.com with SMTP id e1so12858702vsp.2 for ; Thu, 28 Mar 2019 12:45:30 -0700 (PDT) X-Received: by 2002:a67:ffce:: with SMTP id w14mr27494508vsq.111.1553802329700; Thu, 28 Mar 2019 12:45:29 -0700 (PDT) MIME-Version: 1.0 References: <20190327180158.10245-1-sashal@kernel.org> <20190327180158.10245-11-sashal@kernel.org> <20190328101342.GD19456@atrey.karlin.mff.cuni.cz> In-Reply-To: <20190328101342.GD19456@atrey.karlin.mff.cuni.cz> From: Doug Anderson Date: Thu, 28 Mar 2019 12:45:18 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH AUTOSEL 5.0 011/262] tracing: kdb: Fix ftdump to not sleep To: Pavel Machek Cc: Sasha Levin , LKML , stable@vger.kernel.org, Steven Rostedt 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 Thu, Mar 28, 2019 at 3:13 AM Pavel Machek wrote: > > > From: Douglas Anderson > > > > [ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ] > > > > As reported back in 2016-11 [1], the "ftdump" kdb command triggers a > > BUG for "sleeping function called from invalid context". > > > > kdb's "ftdump" command wants to call ring_buffer_read_prepare() in > > atomic context. A very simple solution for this is to add allocation > > flags to ring_buffer_read_prepare() so kdb can call it without > > triggering the allocation error. This patch does that. > > 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. -Doug