Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4255488imm; Mon, 17 Sep 2018 10:39:35 -0700 (PDT) X-Google-Smtp-Source: ANB0Vda3oMYA4vv4tdTa1MtnHxAwhO6dzNajOWbZpM2WD1NF2+bvoVKDPCIgXVoZpcJrJyIyDL6T X-Received: by 2002:a17:902:6845:: with SMTP id f5-v6mr26095681pln.17.1537205975611; Mon, 17 Sep 2018 10:39:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537205975; cv=none; d=google.com; s=arc-20160816; b=A11rdY128LN/vfLySKa5TpkLcQDTQAPjfpu4A3YfV6YmvMQayVsS682QWFUwvnQfl5 25Pk6F4CKHtkVewLY6fHHPUnsbfomM9vk02UjwZ19d/qluvi9jx4TtH87JaH/X7BCgNc aq9bsJwjXDz8KHLcgjD1ol+Kgruz7xe4DHEeBdYmcArtroNl/eOeTAJZgmIyvz/1N07g UMpwMiUtFDTiKvgE9IRTIDJk64d5EY9MPSOT84DkFt4J0L9++33diQTMscKe2Ky0xOa3 c7InvibTnoOVrxUmP6dmkQerovnnjryeFhA7yiLg4X67z15UI+qe42iiNk9r2+wns6Zd R/Dg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature; bh=ZG4+VamlENMt9VXI5cJArl1jtlcvDdKlgVjIv5UykXc=; b=Sg1tbpPym5wR+2ymU6gz8gENQoqA+qVDAeHweeVwMyJlufmQw9cgKhEAUCRmB0s157 6U9xfHEB282VvUD3/6E5+YAduiG9p+SMBCmC9/yrMHnkYumh5ZHhMit1yUM4MP4Avya8 cuigfp1RusXci/CWvce6V4ZXmwkG5wFlYlwr+rc7eQhRHXh3OX+zaKs19O4Uy7tLRJhK 3B4Bs9AHGCQKpZKJCTtZKgO8jwYT7qW7p4XPyB/KR/dPniAK4bLRhBPTMQiHZ8XEdpPp q23CYP5jz5gYBDPKcJVle1GdJ6zMMpmnBhnE5bVJrjke8Id7L+YgwH9/e6+2e4FnOiyC sl6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=QeCZTATU; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 200-v6si15410696pfv.137.2018.09.17.10.39.18; Mon, 17 Sep 2018 10:39:35 -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=@kernel.org header.s=default header.b=QeCZTATU; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728290AbeIQXGo (ORCPT + 99 others); Mon, 17 Sep 2018 19:06:44 -0400 Received: from mail.kernel.org ([198.145.29.99]:42490 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727089AbeIQXGo (ORCPT ); Mon, 17 Sep 2018 19:06:44 -0400 Received: from localhost (unknown [104.132.0.94]) (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 01D4D214DA; Mon, 17 Sep 2018 17:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1537205901; bh=9Bu/NJJ6SANwN8OurcMsJYpZVATMVVJfD3hSyPK2qSY=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=QeCZTATUKt/sz7PsiuDnsCFelj6zutta04D74/TUGoFBudfIrnSX2q0CJU9ze80DV MBLhrn7wJ5RDrLmjgOczE/aA0T2nP6909Ideplqwj8CIWjuGFJT52tVnObU/SPAVPb U4HhiAf200n88gPcuLWq01bU20F3pRCc/N2ERY3Y= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Anton Vorontsov , Arnd Bergmann , Catalin Marinas , Colin Cross , Ingo Molnar , Jason Baron , Jim Cromie , Joe Perches , Joel Fernandes , Kees Cook , Laura Abbott , Masami Hiramatsu , Rob Herring , Sai Prakash Ranjan , Steven Rostedt , Tony Luck , Will Deacon , devicetree@vger.kernel.org From: Stephen Boyd In-Reply-To: <444d7b13-2653-ba0e-e9e6-a448fded2a77@codeaurora.org> Cc: Rajendra Nayak , Vivek Gautam , Sibi Sankar , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Greg Kroah-Hartman , Ingo Molnar , Tom Zanussi , Prasad Sodagudi , tsoni@codeaurora.org, Bryan Huntsman , Tingwei Zhang References: <444d7b13-2653-ba0e-e9e6-a448fded2a77@codeaurora.org> Message-ID: <153720590027.119890.15984895820368075914@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: [PATCH 2/6] pstore: Add event tracing support Date: Mon, 17 Sep 2018 10:38:20 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Sai Prakash Ranjan (2018-09-11 03:46:01) > On 9/9/2018 1:57 AM, Sai Prakash Ranjan wrote: > > +void notrace pstore_event_call(struct trace_event_buffer *fbuffer) > > +{ > > + struct trace_iterator *iter; > > + struct trace_seq *s; > > + struct trace_event_call *event_call; > > + struct pstore_record record; > > + struct trace_event *event; > > + struct seq_buf *seq; > > + unsigned long flags; > > + > > + if (!psinfo) > > + return; > > + > > + if (unlikely(oops_in_progress)) > > + return; > > + > > + pstore_record_init(&record, psinfo); > > + record.type =3D PSTORE_TYPE_EVENT; > > + > > + iter =3D kmalloc(sizeof(*iter), GFP_KERNEL); > > + if (!iter) > > + return; > > + > > + event_call =3D fbuffer->trace_file->event_call; > > + if (!event_call || !event_call->event.funcs || > > + !event_call->event.funcs->trace) > > + goto fail_event; > > + > > + event =3D &fbuffer->trace_file->event_call->event; > > + > > + spin_lock_irqsave(&psinfo->buf_lock, flags); > > + > > + trace_seq_init(&iter->seq); > > + iter->ent =3D fbuffer->entry; > > + event_call->event.funcs->trace(iter, 0, event); > > + trace_seq_putc(&iter->seq, 0); > > + > > + if (seq->size > psinfo->bufsize) > > + seq->size =3D psinfo->bufsize; > > + > > + s =3D &iter->seq; > > + seq =3D &s->seq; > > + > > + record.buf =3D (char *)(seq->buffer); > > + record.size =3D seq->len; > > + psinfo->write(&record); > > + > > + spin_unlock_irqrestore(&psinfo->buf_lock, flags); > > + > > +fail_event: > > + kfree(iter); > > +} > > + > > = > = > When tracing sched events on sdm845 mtp, I hit below bug repeatedly. > Seems like pstore_event_call can be called in atomic context. > I will respin the below fix in next version of the patch. > Reviews on other parts would be appreciated, thanks. > = > diff --git a/fs/pstore/ftrace.c b/fs/pstore/ftrace.c > index d47dc93ac098..a497cf782ee8 100644 > --- a/fs/pstore/ftrace.c > +++ b/fs/pstore/ftrace.c > @@ -73,6 +73,7 @@ void notrace pstore_event_call(struct = > trace_event_buffer *fbuffer) > struct trace_event *event; > struct seq_buf *seq; > unsigned long flags; > + gfp_t gfpflags; > = > if (!psinfo) > return; > @@ -83,7 +84,9 @@ void notrace pstore_event_call(struct = > trace_event_buffer *fbuffer) > pstore_record_init(&record, psinfo); > record.type =3D PSTORE_TYPE_EVENT; > = > - iter =3D kmalloc(sizeof(*iter), GFP_KERNEL); > + gfpflags =3D (in_atomic() || irqs_disabled()) ? GFP_ATOMIC : = > GFP_KERNEL; > + Do you need to allocate at all? Can you throw the iter on the stack? Using in_atomic() and irqs_disabled() to figure out if an atomic or a non-atomic allocation should be used is not a good solution.