| Summary: | [abrt] kernel: WARNING: at fs/inode.c:346 inc_nlink+0x36/0x50() | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Tom <thomasbelvin> |
| Component: | kernel | Assignee: | Zach Brown <zab> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | AppelonD, dzansolov, gansalmon, itamar, jforbes, jonathan, josef, kernel-maint, madhu.chinakonda, mevsspam, pal666, sweil |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | abrt_hash:bd6d66a4e824fd66f662bf021f569eadf62aae4d | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-04-12 15:00:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Tom
2012-02-24 21:37:11 UTC
This is:
void inc_nlink(struct inode *inode)
{
if (WARN_ON(inode->i_nlink == 0))
atomic_long_dec(&inode->i_sb->s_remove_count);
Seems the fixup dir is created and the inode is supposed to have it's nlink incremented. However, with commit 7ada4db8 we do the WARN_ON above.
Josef, should btrfs be using set_nlink(inode, 1); in btrfs/tree-log.c:link_to_fixup_dir instead, or is the 0 i_nlink normal for this kind of recovery operation?
(In reply to comment #1) > This is: > > void inc_nlink(struct inode *inode) > { > if (WARN_ON(inode->i_nlink == 0)) > atomic_long_dec(&inode->i_sb->s_remove_count); > > > Seems the fixup dir is created and the inode is supposed to have it's nlink > incremented. However, with commit 7ada4db8 we do the WARN_ON above. > > Josef, should btrfs be using set_nlink(inode, 1); in > btrfs/tree-log.c:link_to_fixup_dir instead, or is the 0 i_nlink normal for this > kind of recovery operation? Er, I meant "is the 0 i_nlink actually _abnormal_ for this kind of recovery operation". Cheese webcam program, causes this problem, and I see the same problem when I try to do a Google Plus Hangout, with dual monitor setup. Package: kernel OS Release: Fedora release 16 (Verne) Jul 29 18:30:22 laptop kernel: [ 304.100251] ------------[ cut here ]------------ Jul 29 18:30:22 laptop kernel: [ 304.100261] WARNING: at kernel/watchdog.c:241 watchdog_overflow_callback+0x9a/0xc0() Jul 29 18:30:22 laptop kernel: [ 304.100264] Hardware name: 4391DL3 Jul 29 18:30:22 laptop kernel: [ 304.100266] Watchdog detected hard LOCKUP on cpu 5 Jul 29 18:30:22 laptop kernel: [ 304.100268] Modules linked in: fuse be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser lockd sunrpc tpm_bios rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rfcomm bnep ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_hdmi binfmt_misc arc4 snd_hda_codec_conexant coretemp microcode i7core_edac edac_core uvcvideo videobuf2_vmalloc i2c_i801 videobuf2_memops videobuf2_core videodev media qcserial usb_wwan wacom snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_device usblp btusb bluetooth vhost_net tun macvtap macvlan kvm_intel kvm iTCO_wdt iTCO_vendor_support uinput iwlwifi mac80211 cfg80211 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc e1000e snd_timer thinkpad_acpi snd soundcore rfkill xts gf128mul dm_crypt btrfs libcrc32c zlib_deflate crc32c_intel firewire_ohci f Jul 29 18:30:22 laptop kernel: irewire_core sdhci_pci crc_itu_t sdhci mmc_core nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm drm i2c_core [last unloaded: scsi_wait_scan] Jul 29 18:30:22 laptop kernel: [ 304.100359] Pid: 0, comm: swapper/5 Not tainted 3.4.6-2.fc17.x86_64 #1 Jul 29 18:30:22 laptop kernel: [ 304.100362] Call Trace: Jul 29 18:30:22 laptop kernel: [ 304.100364] <NMI> [<ffffffff81056ecf>] warn_slowpath_common+0x7f/0xc0 Jul 29 18:30:22 laptop kernel: [ 304.100374] [<ffffffff81056fc6>] warn_slowpath_fmt+0x46/0x50 Jul 29 18:30:22 laptop kernel: [ 304.100379] [<ffffffff810df580>] ? touch_nmi_watchdog+0x80/0x80 Jul 29 18:30:22 laptop kernel: [ 304.100383] [<ffffffff810df61a>] watchdog_overflow_callback+0x9a/0xc0 Jul 29 18:30:22 laptop kernel: [ 304.100388] [<ffffffff811181ed>] __perf_event_overflow+0x9d/0x230 Jul 29 18:30:22 laptop kernel: [ 304.100394] [<ffffffff81024147>] ? x86_perf_event_set_period+0xd7/0x160 Jul 29 18:30:22 laptop kernel: [ 304.100398] [<ffffffff81118be4>] perf_event_overflow+0x14/0x20 Jul 29 18:30:22 laptop kernel: [ 304.100402] [<ffffffff81029307>] intel_pmu_handle_irq+0x197/0x320 Jul 29 18:30:22 laptop kernel: [ 304.100409] [<ffffffff815f684d>] perf_event_nmi_handler+0x1d/0x20 Jul 29 18:30:22 laptop kernel: [ 304.100413] [<ffffffff815f6029>] nmi_handle.isra.0+0x49/0x80 Jul 29 18:30:22 laptop kernel: [ 304.100417] [<ffffffff815f6148>] do_nmi+0xe8/0x320 Jul 29 18:30:22 laptop kernel: [ 304.100421] [<ffffffff815f567c>] end_repeat_nmi+0x1a/0x1e Jul 29 18:30:22 laptop kernel: [ 304.100428] [<ffffffff8142cb69>] ? iso_sched_free+0x39/0x40 Jul 29 18:30:22 laptop kernel: [ 304.100436] [<ffffffffa0602c61>] ? uvc_video_decode_start+0x401/0x800 [uvcvideo] Jul 29 18:30:22 laptop kernel: [ 304.100443] [<ffffffffa0602c61>] ? uvc_video_decode_start+0x401/0x800 [uvcvideo] Jul 29 18:30:22 laptop kernel: [ 304.100450] [<ffffffffa0602c61>] ? uvc_video_decode_start+0x401/0x800 [uvcvideo] Jul 29 18:30:22 laptop kernel: [ 304.100452] <<EOE>> <IRQ> [<ffffffff8142e68a>] ? ehci_urb_done+0x8a/0xc0 Jul 29 18:30:22 laptop kernel: [ 304.100462] [<ffffffffa05e9494>] ? vb2_buffer_done+0xc4/0xc30 [videobuf2_core] Jul 29 18:30:22 laptop kernel: [ 304.100468] [<ffffffffa0603db7>] uvc_video_decode_isoc+0x107/0x1b0 [uvcvideo] Jul 29 18:30:22 laptop kernel: [ 304.100475] [<ffffffffa0604476>] uvc_video_complete+0xd6/0x100 [uvcvideo] Jul 29 18:30:22 laptop kernel: [ 304.100480] [<ffffffff81417825>] usb_hcd_giveback_urb+0x65/0xf0 Jul 29 18:30:22 laptop kernel: [ 304.100484] [<ffffffff8142e682>] ehci_urb_done+0x82/0xc0 Jul 29 18:30:22 laptop kernel: [ 304.100487] [<ffffffff81431353>] ehci_work+0x993/0xa70 Jul 29 18:30:22 laptop kernel: [ 304.100491] [<ffffffff814316d4>] ehci_irq+0x234/0x460 Jul 29 18:30:22 laptop kernel: [ 304.100496] [<ffffffff812c6ff0>] ? rb_insert_color+0x110/0x150 Jul 29 18:30:22 laptop kernel: [ 304.100500] [<ffffffff812c9704>] ? timerqueue_add+0x74/0xc0 Jul 29 18:30:22 laptop kernel: [ 304.100505] [<ffffffff8107c559>] ? enqueue_hrtimer+0x29/0x90 Jul 29 18:30:22 laptop kernel: [ 304.100509] [<ffffffff8141684c>] usb_hcd_irq+0x3c/0x60 Jul 29 18:30:22 laptop kernel: [ 304.100514] [<ffffffff810e0404>] handle_irq_event_percpu+0x54/0x200 Jul 29 18:30:22 laptop kernel: [ 304.100518] [<ffffffff810e05f1>] handle_irq_event+0x41/0x70 Jul 29 18:30:22 laptop kernel: [ 304.100522] [<ffffffff810e37d9>] handle_fasteoi_irq+0x59/0x100 Jul 29 18:30:22 laptop kernel: [ 304.100527] [<ffffffff8101514f>] handle_irq+0xbf/0x150 Jul 29 18:30:22 laptop kernel: [ 304.100531] [<ffffffff815f8b02>] ? __atomic_notifier_call_chain+0x12/0x20 Jul 29 18:30:22 laptop kernel: [ 304.100535] [<ffffffff815f8b26>] ? atomic_notifier_call_chain+0x16/0x20 Jul 29 18:30:22 laptop kernel: [ 304.100539] [<ffffffff815fe92a>] do_IRQ+0x5a/0xe0 Jul 29 18:30:22 laptop kernel: [ 304.100544] [<ffffffff815f506a>] common_interrupt+0x6a/0x6a Jul 29 18:30:22 laptop kernel: [ 304.100546] <EOI> [<ffffffff8131c5fa>] ? intel_idle+0xea/0x150 Jul 29 18:30:22 laptop kernel: [ 304.100554] [<ffffffff8131c5db>] ? intel_idle+0xcb/0x150 Jul 29 18:30:22 laptop kernel: [ 304.100560] [<ffffffff814a6009>] cpuidle_enter+0x19/0x20 Jul 29 18:30:22 laptop kernel: [ 304.100564] [<ffffffff814a6629>] cpuidle_idle_call+0xa9/0x240 Jul 29 18:30:22 laptop kernel: [ 304.100568] [<ffffffff8101c51f>] cpu_idle+0xaf/0x120 Jul 29 18:30:22 laptop kernel: [ 304.100573] [<ffffffff815e3bab>] start_secondary+0x248/0x24a Jul 29 18:30:22 laptop kernel: [ 304.100576] ---[ end trace eea67604a4f72295 ]--- This problem with webcam continues, and it have nothing to do with monitor setup, or flash or nvidia. I really have no idea what is causing it, but I really would like to make use of my webcam with a browser... that trace has nothing in common with the one this bug is about. Sorry it took me so long to get to this, I should check my bugzilla folder more often. Obviously the warning is no good and we need to fix it, but I think it's a needless warning for our case. I'm going to try and force this to happen, but I assume that if we unlink a file, fsync it and crash then we can have a file with nlink of 0 in our log. This all works out ok because we do our orphan processing afterwards and the file will get cleaned up, it just ends up tripping up this code. I'll try and reproduce and if it is in fact whats happening I'll fix it up and send it to stable. This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 Is this still a problem with 3.9 based F19 kernels? I'm unable to test F19. Closing insufficient data, please reopen if you can reproduce on F19 |