Bug 7258
Summary: | XFS on dm_crypt Oops | ||
---|---|---|---|
Product: | File System | Reporter: | KatagiriWayou (kpr-ee) |
Component: | XFS | Assignee: | Christophe Saout (christophe) |
Status: | CLOSED CODE_FIX | ||
Severity: | high | CC: | christophe, cw, protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.18�@and 2.6.17-1.2187_FC5 and 2.6.15-1.2054_FC5 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
KatagiriWayou
2006-10-03 19:06:18 UTC
I have the same problem. device structure: /dev/md0 : software RAID 5 /dev/mapper/md0-aes : (software RAID 5) with dm_crypt /dev/mapper/lnvg-store : ((software RAID 5) with dm_crypt) (((software RAID 5) with dm_crypt) LVM) XFS Distribution: Gentoo Hardware Environment: ------[lspci output]--------------------------------------------------------- 00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 00:01.0 ISA bridge: nVidia Corporation Unknown device 0050 (rev a3) 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) 00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) 00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) 00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2) 00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) 00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) 00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) 00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control 01:00.0 VGA compatible controller: ATI Technologies Inc Unknown device 5b63 01:00.1 Display controller: ATI Technologies Inc Unknown device 5b73 05:06.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80) 05:07.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) 05:08.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) ----[CPU]------------------------------------------------------------------ processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Athlon(tm) 64 Processor 3200+ stepping : 2 cpu MHz : 2015.031 cache size : 512 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm bogomips : 4032.47 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc ----------------lsmod-------------------------------------------------------- Module Size Used by aes_x86_64 27688 0 sha256 10816 0 dm_crypt 11664 0 iptable_nat 8388 1 ip_nat 17452 1 iptable_nat ip_conntrack 48356 2 iptable_nat,ip_nat iptable_filter 4864 1 ip_tables 19112 2 iptable_nat,iptable_filter x_tables 14792 2 iptable_nat,ip_tables pppoe 14848 2 pppox 5200 1 pppoe ppp_async 11136 0 ppp_generic 21728 7 pppoe,pppox,ppp_async slhc 7936 1 ppp_generic crc_ccitt 4160 1 ppp_async i2c_nforce2 8896 0 it87 23844 0 hwmon_vid 4544 1 it87 i2c_isa 6656 1 it87 i2c_core 19904 3 i2c_nforce2,it87,i2c_isa dm_snapshot 15032 0 dm_mirror 18560 0 dm_mod 48464 2 dm_snapshot,dm_mirror The Oops message is following ------------------------------------------------------------------------------ Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: <ffffffff802520dc>{page_to_pfn+0} PGD 2ace1067 PUD cb85067 PMD 0 Oops: 0000 [1] SMP CPU 0 Modules linked in: aes_x86_64 sha256 dm_crypt capability commoncap iptable_nat ip_nat ip_conntrack iptable_filter ip_tables x_tables pppoe pppox ppp_async ppp_generic slhc crc_ccitt serial_cs pcmcia firmware_class yenta_socket rsrc_nonstatic pcmcia_core i2c_nforce2 it87 hwmon_vid i2c_isa i2c_core dm_snapshot dm_mirror dm_mod Pid: 30349, comm: pdflush Not tainted 2.6.17-gentoo-r7 #32 RIP: 0010:[<ffffffff802520dc>] <ffffffff802520dc>{page_to_pfn+0} RSP: 0018:ffff810021af56b0 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff810033ff54c0 RCX: 0000000000000000 RDX: 000000000000000d RSI: ffff810033ff54c0 RDI: 0000000000000000 RBP: ffff8100276b2c00 R08: 0000000000000000 R09: ffff81003f00f850 R10: 0000000000000282 R11: ffff81003f6c7de8 R12: ffff810033ff54c0 R13: 0000000000000000 R14: 0000000000000000 R15: ffff81003f7e5350 FS: 00002ae66af90f30(0000) GS:ffffffff8076d000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000026fff000 CR4: 00000000000006e0 Process pdflush (pid: 30349, threadinfo ffff810021af4000, task ffff81003f00f850) Stack: ffffffff8038a880 ffff81003f00f850 0000000000001840 0000000000000000 ffff810000000001 0000000000000001 ffff810033ff54c0 ffff81003f7e5350 ffff81001fb3e1c0 ffff8100276b1d28 Call Trace: <ffffffff8038a880>{blk_recount_segments+126} <ffffffff80275d52>{__bio_clone+113} <ffffffff80275ea3>{bio_clone+53} <ffffffff8809e731>{:dm_crypt:crypt_map+205} <ffffffff880022b6>{:dm_mod:__map_bio+71} <ffffffff88002b3c>{:dm_mod:__split_bio+370} <ffffffff8038a919>{blk_recount_segments+279} <ffffffff88003349>{:dm_mod:dm_request+257} <ffffffff8038b716>{generic_make_request+342} <ffffffff880022b6>{:dm_mod:__map_bio+71} <ffffffff88002b3c>{:dm_mod:__split_bio+370} <ffffffff8039755d>{__up_read+19} <ffffffff88003349>{:dm_mod:dm_request+257} <ffffffff8038b716>{generic_make_request+342} <ffffffff8038d3ae>{submit_bio+184} <ffffffff80275c30>{__bio_add_page+340} <ffffffff80376de3>{xfs_submit_ioend_bio+30} <ffffffff8037781b>{xfs_page_state_convert+2607} <ffffffff80377b8a>{xfs_vm_writepage+167} <ffffffff802916d0>{mpage_writepages+437} <ffffffff80377ae3>{xfs_vm_writepage+0} <ffffffff80254234>{do_writepages+41} <ffffffff8028ff61>{__writeback_single_inode+436} <ffffffff88002963>{:dm_mod:dm_any_congested+56} <ffffffff880043a3>{:dm_mod:dm_table_any_congested+70} <ffffffff802903b3>{sync_sb_inodes+469} <ffffffff80240bfb>{keventd_create_kthread+0} <ffffffff80290923>{writeback_inodes+125} <ffffffff8025454a>{background_writeout+118} <ffffffff80254b5a>{pdflush+0} <ffffffff80254c9c>{pdflush+322} <ffffffff802544d4>{background_writeout+0} <ffffffff80240eb6>{kthread+212} <ffffffff8020a4da>{child_rip+8} <ffffffff80240bfb>{keventd_create_kthread+0} <ffffffff80240de2>{kthread+0} <ffffffff8020a4d2>{child_rip+0} Code: 48 8b 07 48 c1 e8 3a 48 8b 14 c5 a0 66 77 80 48 b8 b7 6d db RIP <ffffffff802520dc>{page_to_pfn+0} RSP <ffff810021af56b0> CR2: 0000000000000000 Does this also happen on non-XFS-filesystems? No,this don't happen on only XFS. I tryed to use JFS,but this don't happen. We have finally found out, why there are strange problems with dm-crypt sometimes. If readaheads are cancelled by the underlying block device, the buffer/page cache could be populated by bogus data. Unfortunately this was showing itself very rarely and under strange and hard to reproduce circumstances, and apparently only on top of software raid5. Anyway, that bug is fixed in 2.6.19 and will be in 2.6.18.6 (missed .5 by some hours). The patch can be found here: http://marc.theaimsgroup.com/?l=linux-kernel&m=116503133222152&w=2 The problem would typically show up as metadata corruption, which not all filesystems can gracefully handle (i.e. without oopsing). Yikes. The page_to_pfn used with sparse memory barfs when hitting freed pages while cloning writeout bios under memory pressure. bio_clone shouldn't look at these pages anyway. I see four possibilities: - don't set bv_page to NULL (ugly) - before freeing the pages change bi_idx (atomically?) so that nobody ever looks at the freed bv_page? (strange) - implement own bio_clone (ugly) - Since bio_clone doesn't share the bv array any more, another possibility would be to not use bio_clone at all and go with bio_set_alloc all the way. Probably the last solution. What is the status on this bug, has it been resolved? |