Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757320Ab2EGVtX (ORCPT ); Mon, 7 May 2012 17:49:23 -0400 Received: from mail-yx0-f174.google.com ([209.85.213.174]:61924 "EHLO mail-yx0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754681Ab2EGVtV convert rfc822-to-8bit (ORCPT ); Mon, 7 May 2012 17:49:21 -0400 MIME-Version: 1.0 In-Reply-To: <1336422144.14207.155.camel@gandalf.stny.rr.com> References: <1335388704-26790-1-git-send-email-vnagarnaik@google.com> <1336096792-25373-1-git-send-email-vnagarnaik@google.com> <1336422144.14207.155.camel@gandalf.stny.rr.com> From: Vaibhav Nagarnaik Date: Mon, 7 May 2012 14:48:50 -0700 Message-ID: Subject: Re: [PATCH v7 1/3] trace: Make removal of ring buffer pages atomic To: Steven Rostedt Cc: Frederic Weisbecker , Ingo Molnar , Laurent Chavey , Justin Teravest , David Sharp , linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2510 Lines: 58 On Mon, May 7, 2012 at 1:22 PM, Steven Rostedt wrote: > After applying this patch, I get this: > > # trace-cmd start -e all > # echo 100 > /debug/tracing/buffer_size_kb > > BUG: scheduling while atomic: trace-cmd/2018/0x00000002 > no locks held by trace-cmd/2018. > Modules linked in: ipt_MASQUERADE iptable_nat nf_nat sunrpc bridge stp llc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 kvm uinput snd_hda_codec_idt > ?snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc i2c_i801 shpchp microcode pata_acpi firewire_ohci firewire_core crc_itu > _t ata_generic i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan] > Pid: 2018, comm: trace-cmd Not tainted 3.4.0-rc2-test+ #2 > Call Trace: > ?[] __schedule_bug+0x66/0x6a > ?[] __schedule+0x93/0x605 > ?[] ? __lock_acquire+0x4dc/0xcf1 > ?[] schedule+0x64/0x66 > ?[] schedule_timeout+0x37/0xf7 > ?[] ? _raw_spin_unlock_irq+0x2d/0x5e > ?[] ? trace_hardirqs_on_caller+0x121/0x158 > ?[] wait_for_common+0x97/0xf1 > ?[] ? try_to_wake_up+0x1ec/0x1ec > ?[] ? call_rcu_bh+0x19/0x19 > ?[] ? tracing_iter_reset+0x8b/0x8b > ?[] wait_for_completion+0x1d/0x1f > ?[] wait_rcu_gp+0x5c/0x77 > ?[] ? wait_rcu_gp+0x77/0x77 > ?[] synchronize_sched+0x25/0x27 > ?[] ring_buffer_reset_cpu+0x4e/0xd1 The following seems to be the culprit. I am guessing you have a preempt kernel? @@ -3662,8 +3808,12 @@ void ring_buffer_reset_cpu(struct ring_buffer *buffer, int cpu) if (!cpumask_test_cpu(cpu, buffer->cpumask)) return; + atomic_inc(&buffer->resize_disabled); atomic_inc(&cpu_buffer->record_disabled); + /* Make sure all commits have finished */ + synchronize_sched(); + raw_spin_lock_irqsave(&cpu_buffer->reader_lock, flags); I guess I can disable resizing in ring_buffer_record_disable(), that seems to be a reasonable assumption. Vaibhav Nagarnaik -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/