Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765193AbZDAAVY (ORCPT ); Tue, 31 Mar 2009 20:21:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1764914AbZDAAU0 (ORCPT ); Tue, 31 Mar 2009 20:20:26 -0400 Received: from sous-sol.org ([216.99.217.87]:55731 "EHLO x200.localdomain" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1765439AbZDAAUZ (ORCPT ); Tue, 31 Mar 2009 20:20:25 -0400 Message-Id: <20090331231628.798612700@sous-sol.org> User-Agent: quilt/0.47-1 Date: Tue, 31 Mar 2009 16:11:12 -0700 From: Chris Wright To: linux-kernel@vger.kernel.org, stable@kernel.org Cc: Justin Forbes , Zwane Mwaikambo , "Theodore Ts'o" , Randy Dunlap , Dave Jones , Chuck Wolber , Chris Wedgwood , Michael Krufky , Chuck Ebbert , Domenico Andreoli , Willy Tarreau , Rodrigo Rubira Branco , Jake Edge , Eugene Teo , torvalds@linux-foundation.org, akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, FUJITA Tomonori , Douglas Gilbert , James Bottomley Subject: [patch 27/45] SCSI: sg: avoid blk_put_request/blk_rq_unmap_user in interrupt References: <20090331231045.719396245@sous-sol.org> Content-Disposition: inline; filename=scsi-sg-avoid-blk_put_request-blk_rq_unmap_user-in-interrupt.patch Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3052 Lines: 84 -stable review patch. If anyone has any objections, please let us know. --------------------- From: FUJITA Tomonori upstream commit: c96952ed7031e7c576ecf90cf95b8ec099d5295a This fixes the following oops: http://marc.info/?l=linux-kernel&m=123316111415677&w=2 You can reproduce this bug by interrupting a program before a sg response completes. This leads to the special sg state (the orphan state), then sg calls blk_put_request in interrupt (rq->end_io). The above bug report shows the recursive lock problem because sg calls blk_put_request in interrupt. We could call __blk_put_request here instead however we also need to handle blk_rq_unmap_user here, which can't be called in interrupt too. In the orphan state, we don't need to care about the data transfer (the program revoked the command) so adding 'just free the resource' mode to blk_rq_unmap_user is a possible option. I prefer to avoid complicating the blk mapping API when possible. I change the orphan state to call sg_finish_rem_req via execute_in_process_context. We hold sg_fd->kref so sg_fd doesn't go away until keventd_wq finishes our work. copy_from_user/to_user fails so blk_rq_unmap_user just frees the resource without the data transfer. Signed-off-by: FUJITA Tomonori Acked-by: Douglas Gilbert Signed-off-by: James Bottomley Signed-off-by: Chris Wright --- drivers/scsi/sg.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -138,6 +138,7 @@ typedef struct sg_request { /* SG_MAX_QU volatile char done; /* 0->before bh, 1->before read, 2->read */ struct request *rq; struct bio *bio; + struct execute_work ew; } Sg_request; typedef struct sg_fd { /* holds the state of a file descriptor */ @@ -1234,6 +1235,15 @@ sg_mmap(struct file *filp, struct vm_are return 0; } +static void sg_rq_end_io_usercontext(struct work_struct *work) +{ + struct sg_request *srp = container_of(work, struct sg_request, ew.work); + struct sg_fd *sfp = srp->parentfp; + + sg_finish_rem_req(srp); + kref_put(&sfp->f_ref, sg_remove_sfp); +} + /* * This function is a "bottom half" handler that is called by the mid * level when a command is completed (or has failed). @@ -1312,10 +1322,9 @@ static void sg_rq_end_io(struct request */ wake_up_interruptible(&sfp->read_wait); kill_fasync(&sfp->async_qp, SIGPOLL, POLL_IN); + kref_put(&sfp->f_ref, sg_remove_sfp); } else - sg_finish_rem_req(srp); /* call with srp->done == 0 */ - - kref_put(&sfp->f_ref, sg_remove_sfp); + execute_in_process_context(sg_rq_end_io_usercontext, &srp->ew); } static struct file_operations sg_fops = { -- 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/