--- On Mon, 1/10/12, Vyacheslav Dubeyko <slava@xxxxxxxxxxx> wrote: > From: Vyacheslav Dubeyko <slava@xxxxxxxxxxx> > Subject: Re: hfsplus BUG: Bad page state in process du pfn:07759 (Re: hfsplus corruption, failed fsck, journalling and zero'ing extent record on delete) > To: "Hin-Tak Leung" <hintak_leung@xxxxxxxxxxx> > Cc: linux-fsdevel@xxxxxxxxxxxxxxx, "Till Kamppeter" <till.kamppeter@xxxxxxxxx>, "Naohiro Aota" <naota@xxxxxxxxx>, "Matthew Garrett" <mjg@xxxxxxxxxx> > Date: Monday, 1 October, 2012, 20:09 > Hi Hin-Tak, > > On Sep 24, 2012, at 11:30 AM, Hin-Tak Leung wrote: > > > Argh, the BUG() seems to be a genuine bug - running du > on the recently "fsck.hfsplus -f" clean disk, mounting > read-only with unmod'ed distro hfsplus driver: (see, "not > Tainted"...) > > > > ================= > > [103022.493765] hfs: write access to a journaled > filesystem is not supported, use the force option at your > own risk, mounting read-only. > > [103022.536649] SELinux: initialized (dev sdb5, type > hfsplus), uses genfs_contexts > > [111015.478171] BUG: Bad page state in process du > pfn:07759 > > [111015.478182] page:ffffea00001dd640 count:0 > mapcount:0 mapping: (null) > index:0x1935 > > [111015.478185] page flags: > 0x20000000000004(referenced) > > [111015.478189] Modules linked in: usb_storage tcp_lp > nls_utf8 hfsplus fuse ip6table_filter ip6_tables ebtable_nat > ebtables ipt_MASQUERADE > > iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge > stp llc xt_LOG xt_physdev nf_conntrack_ipv4 nf_defrag_ipv4 > xt_state nf_conntrack arc4 > > rtl8187 eeprom_93cx6 mac80211 cfg80211 > snd_hda_codec_realtek joydev vhost_net tun macvtap macvlan > kvm_amd kvm edac_core edac_mce_amd k8temp > > r592 memstick sp5100_tco snd_hda_intel snd_hda_codec > snd_hwdep snd_pcm snd_page_alloc snd_timer snd soundcore > i2c_piix4 r8169 mii shpchp t > > oshiba_acpi sparse_keymap rfkill wmi ecryptfs > sha256_generic encrypted_keys nfsd nfs_acl auth_rpcgss lockd > sunrpc uinput binfmt_misc truste > > d tpm tpm_bios ata_generic pata_acpi firewire_ohci > sdhci_pci sdhci firewire_core crc_itu_t mmc_core pata_atiixp > video radeon i2c_algo_bit d > > rm_kms_helper ttm drm i2c_core [last unloaded: > scsi_wait_scan] > > [111015.478274] Pid: 23364, comm: du Not tainted > 3.5.4-1.fc17.x86_64 #1 > > [111015.478277] Call Trace: > > [111015.478291] [<ffffffff81604213>] > bad_page+0xe6/0xfb > > [111015.478299] [<ffffffff8112dd8e>] > get_page_from_freelist+0x77e/0x940 > > [111015.478305] [<ffffffff8112e0fd>] > __alloc_pages_nodemask+0x1ad/0x970 > > [111015.478318] [<ffffffffa05e5719>] ? > hfsplus_bnode_read+0x89/0x100 [hfsplus] > > [111015.478324] [<ffffffffa05e5775>] ? > hfsplus_bnode_read+0xe5/0x100 [hfsplus] > > [111015.478329] [<ffffffff811699e0>] > alloc_pages_current+0xb0/0x120 > > [111015.478334] [<ffffffff811721b8>] > new_slab+0x268/0x320 > > [111015.478339] [<ffffffff8160546e>] > __slab_alloc+0x36e/0x4c8 > > [111015.478344] [<ffffffffa05df11a>] ? > hfsplus_alloc_inode+0x1a/0x40 [hfsplus] > > [111015.478349] [<ffffffffa05df11a>] ? > hfsplus_alloc_inode+0x1a/0x40 [hfsplus] > > [111015.478354] [<ffffffff811733f8>] > kmem_cache_alloc+0x108/0x160 > > [111015.478359] [<ffffffffa05e7d40>] ? > __hplusfs_brec_find+0xa0/0x180 [hfsplus] > > [111015.478364] [<ffffffffa05df11a>] > hfsplus_alloc_inode+0x1a/0x40 [hfsplus] > > [111015.478371] [<ffffffff811a0606>] > alloc_inode+0x26/0xa0 > > [111015.478375] [<ffffffff811a1c78>] > iget_locked+0xb8/0x190 > > [111015.478380] [<ffffffffa05df715>] > hfsplus_iget+0x15/0x230 [hfsplus] > > [111015.478386] [<ffffffffa05e7c8f>] ? > hfsplus_find_exit+0x2f/0x40 [hfsplus] > > [111015.478391] [<ffffffffa05e467f>] > hfsplus_lookup+0x20f/0x2d0 [hfsplus] > > [111015.478397] [<ffffffff8119ed84>] ? > __d_alloc+0x34/0x180 > > [111015.478402] [<ffffffffa05d701a>] ? > char2uni+0x1a/0x50 [nls_utf8] > > [111015.478406] [<ffffffff81173321>] ? > kmem_cache_alloc+0x31/0x160 > > [111015.478410] [<ffffffff8119ed84>] ? > __d_alloc+0x34/0x180 > > [111015.478413] [<ffffffff8119ee9c>] ? > __d_alloc+0x14c/0x180 > > [111015.478419] [<ffffffff811928e1>] > __lookup_hash+0x61/0x120 > > [111015.478423] [<ffffffff81194b49>] ? > lookup_fast+0x219/0x310 > > [111015.478427] [<ffffffff81605959>] > lookup_slow+0x47/0xab > > [111015.478431] [<ffffffff81196ac6>] > path_lookupat+0x716/0x750 > > [111015.478436] [<ffffffff81173321>] ? > kmem_cache_alloc+0x31/0x160 > > [111015.478440] [<ffffffff81196b31>] > do_path_lookup+0x31/0xc0 > > [111015.478444] [<ffffffff81192b33>] ? > getname_flags+0x53/0xf0 > > [111015.478448] [<ffffffff8119787d>] > user_path_at_empty+0x5d/0xa0 > > [111015.478454] [<ffffffff8127973a>] ? > inode_has_perm.isra.31.constprop.61+0x2a/0x30 > > [111015.478459] [<ffffffff8127d835>] ? > selinux_inode_getattr+0x45/0x50 > > [111015.478464] [<ffffffff8118c910>] ? > cp_new_stat+0x120/0x140 > > [111015.478468] [<ffffffff811978d1>] > user_path_at+0x11/0x20 > > [111015.478472] [<ffffffff8118cba5>] > vfs_fstatat+0x35/0x70 > > [111015.478475] [<ffffffff8118ceaa>] > sys_newfstatat+0x1a/0x40 > > [111015.478482] [<ffffffff81614e29>] > system_call_fastpath+0x16/0x1b > > [111015.478485] Disabling lock debugging due to kernel > taint > > ============================ > > Unless I state otherwise (I wouldn't post such things against tainted modules with experimental patches anyway), these are against one of the fedora distro kernels. The above shows "3.5.4-1.fc17.x86_64", which you could look up on fedora's compile farm for exact configs: http://koji.fedoraproject.org/koji/packageinfo?packageID=8 If you are brave enough, you could even unpack one of those and graft it on a non-fedora system, I suppose... So I have been able to consistently get BUG() by running du on a particular directory on a USB drive (which is fsck-clean), just using one of the distro kernel packages. I know I probably should file this first with Fedora, but then I reckon it would probably get referred to linux-fsdevel anyway. > I am analyzing this call trace. I think that strace output > under "du" can be very helpful for investigation the issue. > Could you share such strace output? > > Also, if I correct, you wrote about dmesg calling also. > Could you share strace output for dmesg command also? I'll get you those soon. the du trace would be quite big (since it is du'ing a 6 kernel trees, etc). Hin-Tak > > --- On Mon, 24/9/12, Hin-Tak Leung <htl10@xxxxxxxxxxxxxxxxxxxxx> > wrote: > > > > <snipped> > >> I mentioned briefly some days ago that I managed to > corrupt > >> an HFS+ paritition while experimenting with the > journalling > >> code, to the extent that fsck_hfs/fsck.hfsplus > (Apple's > >> diskdev_cmds tool) refuses to fix. And that > partition, with > >> the unmodified module used ready-only can get the > kernel to > >> BUG() "reliably" by just doing "du" on it (and I > was > >> thinking whether BUG()'ing on corrupted disk is a > bug to > >> file...). > > > > > > -- > > To unsubscribe from this list: send the line > "unsubscribe linux-fsdevel" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
