From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762553AbXGQGZ1 (ORCPT ); Tue, 17 Jul 2007 02:25:27 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752144AbXGQGZN (ORCPT ); Tue, 17 Jul 2007 02:25:13 -0400 Received: from brick.kernel.dk ([80.160.20.94]:24691 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751858AbXGQGZL (ORCPT ); Tue, 17 Jul 2007 02:25:11 -0400 Date: Tue, 17 Jul 2007 08:24:35 +0200 From: Jens Axboe To: Rene Herman Cc: Chuck Ebbert , pomac@vapor.com, Linux-kernel@vger.kernel.org, Nick Piggin Subject: Re: [BUG] AS io-scheduler. Message-ID: <20070717062435.GX5195@kernel.dk> References: <1184512821.10630.26.camel@localhost> <469B9D6B.60101@redhat.com> <469C1EE0.1090808@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <469C1EE0.1090808@gmail.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 17 2007, Rene Herman wrote: > On 07/16/2007 06:31 PM, Chuck Ebbert wrote: > >>> BUG: unable to handle kernel paging request at virtual address ea86ac54 >>> printing eip: >>> c022dfec >>> *pde = 00000000 >>> Oops: 0000 [#1] >>> Modules linked in: eeprom i2c_viapro vt8231 i2c_isa skge >>> CPU: 0 >>> EIP: 0060:[] Not tainted VLI >>> EFLAGS: 00010082 (2.6.22.1 #26) >>> EIP is at as_can_break_anticipation+0xc/0x190 >>> eax: dfcdaba0 ebx: dfcdaba0 ecx: 0035ff95 edx: cb296844 >>> esi: cb296844 edi: dfcdaba0 ebp: 00000000 esp: ceff6a70 >>> ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068 >>> Process rsync (pid: 1667, ti=ceff6000 task=d59cf5b0 task.ti=ceff6000) >>> Stack: cb296844 00000001 cb296844 dfcdaba0 00000000 c022efc8 cb296844 >>> 00000000 dfcffb9c c0227a76 dfcffb9c 00000000 c016e96e cb296844 >>> 00000000 >>> dfcffb9c 00000000 c022af64 00000000 dfcffb9c 00000008 00000000 >>> 08ff6b30 >>> c04d1ec0 Call Trace: >>> [] as_add_request+0xa8/0xc0 >>> [] elv_insert+0xa6/0x150 >>> [] bio_phys_segments+0xe/0x20 >>> [] __make_request+0x384/0x490 >>> [] ide_do_request+0x6ee/0x890 >>> [] generic_make_request+0x18b/0x1c0 >>> [] submit_bio+0xa6/0xb0 >>> [] mempool_alloc+0x28/0xa0 >>> [] __find_get_block+0xf6/0x130 >>> [] bio_alloc_bioset+0x8c/0xf0 >>> [] submit_bh+0xb7/0xe0 >>> [] ll_rw_block+0x78/0x90 >>> [] search_by_key+0xdd/0xd20 >>> [] ll_rw_block+0x81/0x90 >>> [] irq_exit+0x40/0x60 >>> [] do_IRQ+0x94/0xb0 >>> [] common_interrupt+0x23/0x30 >>> [] reiserfs_read_locked_inode+0x6a/0x490 >>> [] reiserfs_find_actor+0x0/0x20 >>> [] reiserfs_iget+0x4b/0x80 >>> [] reiserfs_init_locked_inode+0x0/0x10 >>> [] reiserfs_lookup+0xa4/0xf0 >>> [] do_lookup+0xa3/0x140 >>> [] __link_path_walk+0x615/0xa20 >>> [] __mark_inode_dirty+0x28/0x150 >>> [] mntput_no_expire+0x11/0x50 >>> [] link_path_walk+0x42/0xb0 >>> [] do_path_lookup+0x130/0x150 >>> [] __user_walk_fd+0x30/0x50 >>> [] vfs_lstat_fd+0x16/0x40 >>> [] sys_lstat64+0xf/0x30 >>> [] syscall_call+0x7/0xb >>> ======================= >> static int as_can_break_anticipation(struct as_data *ad, struct request >> *rq) >> { >> struct io_context *ioc; >> struct as_io_context *aic; >> ioc = ad->io_context; <======== ad is bogus >> BUG_ON(!ioc); >> Call chain is: >> as_add_request >> as_update_rq: >> if (ad->antic_status == ANTIC_WAIT_REQ >> || ad->antic_status == ANTIC_WAIT_NEXT) { >> if (as_can_break_anticipation(ad, rq)) >> as_antic_stop(ad); >> } >> So somehow 'ad' became invalid between the time ad->antic_status was >> checked and as_can_break_anticipation() tried to access ad->io_context? > > Is this similar to: > > http://lkml.org/lkml/2007/6/4/50 Nope -- Jens Axboe