Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755438Ab2BFQhf (ORCPT ); Mon, 6 Feb 2012 11:37:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57657 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755250Ab2BFQha (ORCPT ); Mon, 6 Feb 2012 11:37:30 -0500 Date: Mon, 6 Feb 2012 11:37:21 -0500 From: Vivek Goyal To: Jens Axboe Cc: Shaohua Li , lkml , Linus Torvalds , Tejun Heo , Knut Petersen , mroos@linux.ee Subject: Re: [patch]block: fix ioc locking warning Message-ID: <20120206163721.GF30752@redhat.com> References: <1328514611.21268.66.camel@sli10-conroe> <20120206151219.GC30752@redhat.com> <4F2FFB21.9000202@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F2FFB21.9000202@kernel.dk> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3280 Lines: 75 On Mon, Feb 06, 2012 at 05:09:05PM +0100, Jens Axboe wrote: [..] > > Changlog was not obivious atleast to me. I wished it was little more > > descriptive. Anyway, patch is already committed.. > > We can always amend the changelog, so don't worry about it already being > committed. If you want to add/change something, just send it in. How about something like as follows. block: Do not lock try to lock already locked queue again put_io_context() can be called with one of the request queue lock already held. But if the locked queue's cic is not first in the ioc->ioc_list, then we have two possible issues. - For above condition, current code bails out and schedules the worker thread for freeing up ioc. This can be optimized. - It might happen that we received the queue locked but we still do the trylock on the queue. For SMP case that's not a problem as we will fail to lock already locked queue, but in case of UP, we seem to succeed and in the process increment the preempt count. Once we are done with ioc_exit_icq(), we do not call spin_unlock() on locked queue as we are not supposed to. This leads to imbalance in preemtion count and following warning was reported. This patch fixes both the above issues by making sure we do not try to lock already locked queue again. 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 Signed-off-by: Shaohua Li Reported-by: Meelis Roos Reported-by: Knut Petersen Tested-by: Knut Petersen Thanks Vivek -- 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/