From patchwork Wed Feb 20 15:49:04 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bart Van Assche X-Patchwork-Id: 2168331 Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by patchwork2.kernel.org (Postfix) with ESMTP id 2AB55DF230 for ; Wed, 20 Feb 2013 15:52:35 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1KFnJ4t007815; Wed, 20 Feb 2013 10:49:20 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r1KFnJON001615 for ; Wed, 20 Feb 2013 10:49:19 -0500 Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com [10.5.110.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r1KFnIkV000968 for ; Wed, 20 Feb 2013 10:49:19 -0500 Received: from gerard.telenet-ops.be (gerard.telenet-ops.be [195.130.132.48]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r1KFn6hV014307 for ; Wed, 20 Feb 2013 10:49:08 -0500 Received: from [192.168.1.101] ([178.119.235.68]) by gerard.telenet-ops.be with bizsmtp id 2fp51l00Q1VD9XW0Hfp5my; Wed, 20 Feb 2013 16:49:05 +0100 Message-ID: <5124F070.9060001@acm.org> Date: Wed, 20 Feb 2013 16:49:04 +0100 From: Bart Van Assche User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130105 Thunderbird/17.0.2 MIME-Version: 1.0 To: device-mapper development References: <5123C8CD.9010207@acm.org> In-Reply-To: <5123C8CD.9010207@acm.org> X-RedHat-Spam-Score: -2.311 (BAYES_00, DCC_REPUT_00_12, RCVD_IN_DNSWL_NONE, SPF_PASS) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Scanned-By: MIMEDefang 2.68 on 10.5.110.19 X-loop: dm-devel@redhat.com Cc: Jens Axboe , Alasdair G Kergon Subject: Re: [dm-devel] v3.8-rc7: Kernel oops in end_clone_bio() X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk Reply-To: device-mapper development List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com On 02/19/13 19:47, Bart Van Assche wrote: > general protection fault: 0000 [#1] SMP > RIP: 0010:[] [] mempool_free+0x24/0xb0 > Call Trace: > > [] bio_put+0x97/0xc0 > [] end_clone_bio+0x35/0x90 [dm_mod] > [] bio_endio+0x1d/0x30 > [] req_bio_endio.isra.51+0xa3/0xe0 > [] blk_update_request+0x118/0x520 > [] blk_update_bidi_request+0x27/0xa0 > [] blk_end_bidi_request+0x2c/0x80 > [] blk_end_request+0x10/0x20 > [] scsi_io_completion+0xfb/0x6c0 [scsi_mod] > [] scsi_finish_command+0xbd/0x120 [scsi_mod] > [] scsi_softirq_done+0x13f/0x160 [scsi_mod] > [] blk_done_softirq+0x80/0xa0 > [] __do_softirq+0xf1/0x250 > [] call_softirq+0x1c/0x30 > [] do_softirq+0x8d/0xc0 > [] irq_exit+0xd5/0xe0 > [] do_IRQ+0x63/0xe0 > [] common_interrupt+0x6f/0x6f > > [] srp_queuecommand+0x8c/0xcb0 [ib_srp] > [] scsi_dispatch_cmd+0x148/0x310 [scsi_mod] > [] scsi_request_fn+0x31e/0x520 [scsi_mod] > [] __blk_run_queue+0x37/0x50 > [] blk_delay_work+0x29/0x40 > [] process_one_work+0x1c3/0x5c0 > [] worker_thread+0x15e/0x440 > [] kthread+0xdb/0xe0 > [] ret_from_fork+0x7c/0xb0 (replying to my own e-mail) Any opinions about the patch below ? It seems to fix the kernel oops mentioned above. [PATCH] Avoid destroying a dm device before request processing finished --- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel diff --git a/block/blk-core.c b/block/blk-core.c index c973249..77f4ea8 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -304,10 +304,18 @@ EXPORT_SYMBOL(blk_sync_queue); * This variant runs the queue whether or not the queue has been * stopped. Must be called with the queue lock held and interrupts * disabled. See also @blk_run_queue. + * + * Note: + * Request handling functions that unlock and relock the queue lock + * internally are allowed to invoke blk_run_queue(). This will not result + * in a recursive call of the request handler. However, such request + * handling functions must, before they return, either reexamine the + * request queue or invoke blk_delay_queue() to avoid that queue processing + * stops. */ inline void __blk_run_queue_uncond(struct request_queue *q) { - if (unlikely(blk_queue_dead(q))) + if (unlikely(blk_queue_dead(q) || q->request_fn_active)) return; /* diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 314a0e2..28b7ad4 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -728,14 +728,8 @@ static void rq_completed(struct mapped_device *md, int rw, int run_queue) if (!md_in_flight(md)) wake_up(&md->wait); - /* - * Run this off this callpath, as drivers could invoke end_io while - * inside their request_fn (and holding the queue lock). Calling - * back into ->request_fn() could deadlock attempting to grab the - * queue lock again. - */ if (run_queue) - blk_run_queue_async(md->queue); + blk_run_queue(md->queue); /* * dm_put() must be at the end of this function. See the comment above