From patchwork Thu Oct 1 18:47:55 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 34762 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id 1B801B7BD2 for ; Fri, 2 Oct 2009 04:47:43 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752736AbZJASrg (ORCPT ); Thu, 1 Oct 2009 14:47:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752952AbZJASrg (ORCPT ); Thu, 1 Oct 2009 14:47:36 -0400 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:55081 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752736AbZJASrg (ORCPT ); Thu, 1 Oct 2009 14:47:36 -0400 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 9DABCC8C1EC; Thu, 1 Oct 2009 11:47:55 -0700 (PDT) Date: Thu, 01 Oct 2009 11:47:55 -0700 (PDT) Message-Id: <20091001.114755.132624639.davem@davemloft.net> To: manty@manty.net Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org Subject: Re: kernel BUG at drivers/ide/ide-disk.c:187 (2.6.31) From: David Miller In-Reply-To: <20090930110529.GA3676@dis.manty.net> References: <20090930110529.GA3676@dis.manty.net> X-Mailer: Mew version 6.2.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Sender: linux-ide-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ide@vger.kernel.org From: Santiago Garcia Mantinan Date: Wed, 30 Sep 2009 13:05:29 +0200 > [] ? dequeue_task+x90/0x9e > [] ? schedule+0x2ad/0x2d9 > [] ? __blk_run_queue+0x39/0x60 > [] ? cfq_kick_queue+0x0/0xb > [] ? cfq_kick_queue+0x9/0xb > [] ? worker_thread+0xae/0x11c So it does look like a normal block I/O request to the disk going through the CFQ scheduler. But ->cmd_type of the request is corrupted, but we have no idea in what way. Well, we know it's not a special request, because one layer up the IDE I/O layer driver does special processing for blk_special_request() by calling ide_special_rq(). I suspect the request structure has been freed already and we're referencing free'd memory. Please add this test patch and let us know what messages you end up with in the logs. It won't BUG() any more, so you have to watch for the messages. Thanks! -DaveM (the IDE bug dodger) --- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c index 7f87801..54b9dbc 100644 --- a/drivers/ide/ide-disk.c +++ b/drivers/ide/ide-disk.c @@ -184,7 +184,11 @@ static ide_startstop_t ide_do_rw_disk(ide_drive_t *drive, struct request *rq, ide_hwif_t *hwif = drive->hwif; BUG_ON(drive->dev_flags & IDE_DFLAG_BLOCKED); - BUG_ON(!blk_fs_request(rq)); + if (!blk_fs_request(rq)) { + pr_alert("IDE: Non-FS req in ide_do_rw_disk(), cmd_type %d\n", + rq->cmd_type); + ide_kill_rq(drive, rq); + } ledtrig_ide_activity();