Red Hat Bugzilla – Bug 862616
[abrt]: WARNING: at fs/inode.c:280 drop_nlink+0x46/0x50()
Last modified: 2013-03-13 12:12:25 EDT
Additional info: libreport version: 2.0.14 abrt_version: 2.0.13 cmdline: BOOT_IMAGE=/vmlinuz-3.5.4-2.fc17.x86_64 root=UUID=7b54b043-ae92-49d5-a8f5-b74bf43d6a3f ro rd.lvm=0 rd.dm=0 SYSFONT=True rd.md.uuid=9b2dcd74:2b6208d6:9bf99824:cad2695c rd.md.uuid=d0e4af5f:50f3e205:1c49e1ff:692c379f KEYTABLE=pl2 rd.luks=0 LANG=en_US.UTF-8 rhgb quiet kernel: 3.5.4-2.fc17.x86_64 backtrace: :WARNING: at fs/inode.c:280 drop_nlink+0x46/0x50() :Hardware name: Precision T1650 :Modules linked in: vfat fat fuse ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle bridge stp llc lockd sunrpc bnep bluetooth rfkill be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq coretemp snd_seq_device lpc_ich microcode snd_pcm snd_page_alloc snd_timer snd soundcore e1000e mei mfd_core serio_raw i2c_i801 dcdbas vhost_net tun macvtap macvlan kvm_intel kvm binfmt_misc uinput raid1 crc32c_intel ghash_clmulni_intel usb_storage i915 video i2c_algo_bit drm_kms_helper drm i2c_core [last unloaded: scsi_wait_scan] :Pid: 3316, comm: mc Not tainted 3.5.4-2.fc17.x86_64 #1 :Call Trace: : [<ffffffff8105864f>] warn_slowpath_common+0x7f/0xc0 : [<ffffffff810586aa>] warn_slowpath_null+0x1a/0x20 : [<ffffffff811a08d6>] drop_nlink+0x46/0x50 : [<ffffffffa057aef7>] fuse_unlink+0xe7/0x130 [fuse] : [<ffffffff81193a8e>] vfs_unlink+0x9e/0x110 : [<ffffffff81197023>] do_unlinkat+0x183/0x1c0 : [<ffffffff810d36cc>] ? __audit_syscall_entry+0xcc/0x300 : [<ffffffff810d3cec>] ? __audit_syscall_exit+0x3ec/0x450 : [<ffffffff81197dc6>] sys_unlink+0x16/0x20 : [<ffffffff81614ee9>] system_call_fastpath+0x16/0x1b
Not sure if it could help somehow but at the time it happened I actually traversed some directories in fuse mounted file-system.
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?
On a machine I usually observed it I'm using: $ uname -r 3.7.4-104.fc17.x86_64 and hopefully since: $ uptime 16:59:25 up 42 days, 7:11, 14 users, load average: 1.05, 0.79, 0.59 I don't observe this issue nor any other similar problem with the kernel: $ grep -e "Call Trace:" -e :WARNING: -e warn_slow /var/log/messages* | wc -l 0 Thus it seems to got fixed and can be closed.
Thanks for letting us know.