Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753991Ab2BFH44 (ORCPT ); Mon, 6 Feb 2012 02:56:56 -0500 Received: from merlin.infradead.org ([205.233.59.134]:58162 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750912Ab2BFH4z (ORCPT ); Mon, 6 Feb 2012 02:56:55 -0500 Message-ID: <4F2F8780.5060207@kernel.dk> Date: Mon, 06 Feb 2012 08:55:44 +0100 From: Jens Axboe MIME-Version: 1.0 To: Shaohua Li CC: lkml , Linus Torvalds , Tejun Heo , Knut Petersen , mroos@linux.ee Subject: Re: [patch]block: fix ioc locking warning References: <1328514611.21268.66.camel@sli10-conroe> In-Reply-To: <1328514611.21268.66.camel@sli10-conroe> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2155 Lines: 48 On 02/06/2012 08:50 AM, Shaohua Li wrote: > Meelis reported a warning: > > WARNING: at kernel/timer.c:1122 run_timer_softirq+0x199/0x1ec() > Hardware name: 939Dual-SATA2 > timer: cfq_idle_slice_timer+0x0/0xaa preempt leak: 00000102 -> 00000103 > Modules linked in: sr_mod cdrom videodev media drm_kms_helper ohci_hcd ehci_hcd v4l2_compat_ioctl32 usbcore i2c_ali15x3 snd_seq drm snd_timer snd_seq > Pid: 0, comm: swapper Not tainted 3.3.0-rc2-00110-gd125666 #176 > Call Trace: > [] warn_slowpath_common+0x7e/0x96 > [] ? cfq_slice_expired+0x1d/0x1d > [] warn_slowpath_fmt+0x41/0x43 > [] ? cfq_idle_slice_timer+0xa1/0xaa > [] ? cfq_slice_expired+0x1d/0x1d > [] run_timer_softirq+0x199/0x1ec > [] ? timekeeping_get_ns+0x12/0x31 > [] ? apic_write+0x11/0x13 > [] __do_softirq+0x74/0xfa > [] call_softirq+0x1a/0x30 > [] do_softirq+0x31/0x68 > [] irq_exit+0x3d/0xa3 > [] smp_apic_timer_interrupt+0x6b/0x77 > [] apic_timer_interrupt+0x69/0x70 > [] ? sched_clock_cpu+0x73/0x7d > [] ? sched_clock_cpu+0x73/0x7d > [] ? default_idle+0x1e/0x32 > [] ? default_idle+0x18/0x32 > [] cpu_idle+0x87/0xd1 > [] rest_init+0x85/0x89 > [] start_kernel+0x2eb/0x2f8 > [] x86_64_start_reservations+0x7e/0x82 > [] x86_64_start_kernel+0xf0/0xf7 > > this_q == locked_q is possible. There are two problems here: > 1. In UP case, there is preemption counter issue as spin_trylock always > successes. > 2. In SMP case, the loop breaks too earlier. Thanks Shaohua, applied! -- Jens Axboe -- 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/