Re: hfsplus BUG: Bad page state in process du pfn:07759 (Re: hfsplus corruption, failed fsck, journalling and zero'ing extent record on delete)

[Vyacheslav Dubeyko <slava@dubeyko.com>]

Hi Hin-Tak,

Could you describe the way of issue reproduction in more details?

I need to know:
1. What kernel version do you use?
2. Do you have some special configuration of the system ([103022.536649]
SELinux: initialized (dev sdb5, type hfsplus), uses genfs_contexts)?
3. How did you generate small files? How small is it (I mean size)?

Sorry, but currently I haven't clear understanding how to reproduce this
issue from your description.

With the best regards,
Vyacheslav Dubeyko.

On Mon, 2012-09-24 at 08:30 +0100, 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
> ============================
> 
> --- On Mon, 24/9/12, Hin-Tak Leung <htl10@users.sourceforge.net> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html