From mboxrd@z Thu Jan 1 00:00:00 1970
From: bugzilla-daemon@bugzilla.kernel.org
Subject: [Bug 27652] 38-rc1: umount+rmmod cause ext4 error.
Date: Fri, 28 Jan 2011 17:15:02 GMT
Message-ID: <201101281715.p0SHF2uK028041@demeter2.kernel.org>
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
To: linux-ext4@vger.kernel.org
Return-path:
Received: from demeter2.kernel.org ([140.211.167.42]:60424 "EHLO
demeter2.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
with ESMTP id S1752793Ab1A1RPE (ORCPT
); Fri, 28 Jan 2011 12:15:04 -0500
Received: from demeter2.kernel.org (localhost.localdomain [127.0.0.1])
by demeter2.kernel.org (8.14.4/8.14.3) with ESMTP id p0SHF2Wf028042
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for ; Fri, 28 Jan 2011 17:15:02 GMT
In-Reply-To:
Sender: linux-ext4-owner@vger.kernel.org
List-ID:
https://bugzilla.kernel.org/show_bug.cgi?id=27652
--- Comment #3 from Tao Ma 2011-01-28 09:51:52 ---
Just tested with 37+the 2 patches. Still the same error.
So it isn't a 38 problem really.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: [] _raw_spin_lock_irqsave+0x11/0x22
PGD 122b58067 PUD 122594067 PMD 0
Oops: 0002 [#1] SMP
last sysfs file: /sys/devices/virtual/misc/autofs/dev
CPU 1
Modules linked in: ext4(-) jbd2 ipv6 autofs4 hidp rfcomm l2cap crc16 bluetooth
rfkill ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue
configfs cpufreq_ondemand acpi_cpufreq dm_mirror video output sbs sbshc battery
acpi_memhotplug ac lp sg snd_hda_codec_analog snd_hda_intel snd_hda_codec
snd_seq_dummy snd_seq_oss option usb_wwan snd_seq_midi_event snd_seq
snd_seq_device snd_pcm_oss usbserial snd_mixer_oss snd_pcm snd_timer rtc_cmos
snd rtc_core tpm_tis tpm i2c_i801 shpchp parport_pc parport serio_raw button
soundcore rtc_lib tpm_bios pcspkr dcdbas e1000e i2c_core snd_page_alloc
dm_region_hash dm_log dm_mod usb_storage ahci libahci libata sd_mod scsi_mod
ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 4717, comm: rmmod Not tainted 2.6.37+ #2 0V4W66/OptiPlex 780
RIP: 0010:[] []
_raw_spin_lock_irqsave+0x11/0x22
RSP: 0018:ffff88011f7ade48 EFLAGS: 00010046
RAX: 0000000000000246 RBX: ffff88011f7ade98 RCX: 00000000c0000100
RDX: 0000000000000100 RSI: ffff88011f7ade98 RDI: 0000000000000020
RBP: ffff88011f7ade48 R08: ffff88011f7ac000 R09: ffff8800cfa0da70
R10: ffff8800cfa51a00 R11: ffff88011f7add48 R12: 0000000000000020
R13: 0000000000000002 R14: 00007fff3d3ad400 R15: 0000000000000880
FS: 00007fe07ff0e6e0(0000) GS:ffff8800cfa40000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000020 CR3: 000000011ee14000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process rmmod (pid: 4717, threadinfo ffff88011f7ac000, task ffff88012358f8d0)
Stack:
ffff88011f7ade88 ffffffff82056d4e ffffffff8206a6e4 ffff88011f7ade98
ffff88011f7ade98 ffffffffa0441500 0000000000000880 00007fff3d3ad400
ffff88011f7aded8 ffffffffa0433428 0000000000000000 ffff88012358f8d0
Call Trace:
[] prepare_to_wait+0x25/0x7b
[] ? __try_stop_module+0x0/0x3d
[] ext4_exit_fs+0x94/0x112 [ext4]
[] ? autoremove_wake_function+0x0/0x3d
[] sys_delete_module+0x1b5/0x218
[] ? do_munmap+0x2e2/0x318
[] ? audit_syscall_entry+0x1d6/0x209
[] system_call_fastpath+0x16/0x1b
Code: 1f 44 00 00 b8 00 01 00 00 f0 66 0f c1 07 38 e0 74 06 f3 90 8a 07 eb f6
c9 c3 55 48 89 e5 0f 1f 44 00 00 9c 58 fa ba 00 01 00 00 66 0f c1 17 38 f2
74 06 f3 90 8a 17 eb f6 c9 c3 55 48 89 e5
RIP [] _raw_spin_lock_irqsave+0x11/0x22
RSP
CR2: 0000000000000020
---[ end trace e0bdca5906fdcbe6 ]---
--- Comment #4 from Eric Sandeen 2011-01-28 17:15:01 ---
Is that last oops with or without the patches I pointed at?
That might be in here:
static void ext4_destroy_lazyinit_thread(void)
{
/*
* If thread exited earlier
* there's nothing to be done.
*/
if (!ext4_li_info)
return;
ext4_clear_request_list();
while (ext4_li_info->li_task) {
wake_up(&ext4_li_info->li_wait_daemon);
wait_event(ext4_li_info->li_wait_task,
ext4_li_info->li_task == NULL);
}
}
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
li_wait_task is 0x20 into the ext4_lazy_init struct... did ext4_li_info go
away?
It does get freed and set to NULL when the lazyinit thread exits. I'm guessing
we need a little judicial application of ext4_li_mtx in the teardown thread.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.