Re: apt taints kernel - btrfs destroys inode
Adam Borowski posted on Sun, 08 May 2016 01:11:18 +0200 as excerpted: > Duncan wrote: >> > btrfs_destroy_inode > >> That's a known apparent false-positive warning on current 4.6-rc kernel >> btrfs. The destroy-inode bit is related to a file deletion happening >> in the normal order of things, where this warning code is run, and >> apparently triggers even under normal operations. > > Are you guys reasonably certain it's false-positive? I don't personally know. I'm just a btrfs user and list regular myself, not a dev, and I personally haven't seen this bug, but then my use-case doesn't require either snapshots or quotas, so I don't use either, and wouldn't be _expected_ to see this bug. But all reported evidence suggests that it's a false-positive, as even the people hitting it extremely frequently haven't seen any real problems from it. > If so, you _really_ > want to disable the warning for 4.6, less than a week from now. Any > reasonable user of a stable kernel who notices such a warning and stack > dumps will assume something is broken, rightfully panic and consider the > filesystem unsound. I can't disagree. But I'm a user, not a dev... However, based on my own tracking of pre-release kernels, reverts or (temporarily?) silenced warnings for exactly this sort of appeared-over- the-release-cycle issue that they had hoped to actually track down and fix during the cycle, but simply didn't get there in time, do tend to come in at about this time, as it becomes apparent the trace-down, fix, and full testing, simply can't be completed in the cycle in which the problem was introduced or at least exposed, so the wise action is to simply revert or paper over for at least the one release, with the appropriate fix very likely to then hit the next kernel, either the initial commit window, or in any case before rc3 or so when people like me often start testing. What worries me is that I've seen no on-list indication that this particular bug has been traced even to a point that a specific revert can be done, or alternatively, that there's enough code-level confidence that it's a false-positive to silence the warning. However, it should be noted that particularly if it's a simple revert, there may in fact be no such on-list discussion as there's not necessarily anything to discuss, only a final decision by the project lead (or occasionally Linus himself) to revert or simply let it ride. >> It's related to some btrfs feature (I think either snapshotting or >> quotas, but don't recall which) I don't use here so I don't seem the >> warnings, but there's several threads where people have reported the >> warnings, so it's apparently quite commonly triggered, but nobody has >> reported any further problems even where the warnings are coming in the >> hundreds due to their use-case, so as I said, apparently a >> false-positive induced by normal operations. > > A data point: I've been running for a week with this WARN_ON replaced by > a printk: > > --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9258,7 +9258,8 @@ void > btrfs_destroy_inode(struct inode *inode) > WARN_ON(BTRFS_I(inode)->outstanding_extents); > WARN_ON(BTRFS_I(inode)->reserved_extents); > WARN_ON(BTRFS_I(inode)->delalloc_bytes); > - WARN_ON(BTRFS_I(inode)->csum_bytes); > + if (BTRFS_I(inode)->csum_bytes) > + printk("btrfs: btrfs_destroy_inode: WARN csum_bytes\n"); > WARN_ON(BTRFS_I(inode)->defrag_bytes); > > /* > > and no data loss or anything suspicious so far. This box has a SSD > (moderate use) and HDD (light use), no RAID, no quotas, compress=lzo, > many subvolumes, 20ish snapshots daily (mostly sbuild for Debian > packages). That's nearly identical to what others have noted, as well, thus my describing it as an apparent false-positive, because despite many triggered warnings among the several reporters, no tragedy has seemed to strike as a result. > [~]$ dmesg|grep btrfs_destroy_inode|wc -l > 50 > [~]$ uptime > 00:17:47 up 1 day, 18:44, 19 users, load average: 0.23, 0.35, 0.61 > [~]$ cat /proc/version > Linux version 4.6.0-rc6-debug+ (kilobyte@umbar) > (gcc version 6.1.1 20160430 (Debian 6.1.1-1) ) > #1 SMP Fri May 6 00:33:44 CEST 2016 > >> I'd expect the warning to be either fixed to only warn when there's an >> actual issue, or be silenced, by 4.6 release. > > In order to get to 4.6 such a commit would need to hit Linus about right > now... Agreed. (Matter of fact, I'm about to git pull and git log check what's new over the last couple days, as I write this, before I continue checking the new messages here. As you say, it's gotta be real soon now if it's going to happen. Maybe it's either in-kernel or at least in a list-announced pull ready for Linus as I write...) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: apt taints kernel - btrfs destroys inode
Duncan wrote: > > btrfs_destroy_inode > That's a known apparent false-positive warning on current 4.6-rc kernel > btrfs. The destroy-inode bit is related to a file deletion happening in > the normal order of things, where this warning code is run, and > apparently triggers even under normal operations. Are you guys reasonably certain it's false-positive? If so, you _really_ want to disable the warning for 4.6, less than a week from now. Any reasonable user of a stable kernel who notices such a warning and stack dumps will assume something is broken, rightfully panic and consider the filesystem unsound. > It's related to some btrfs feature (I think either snapshotting or > quotas, but don't recall which) I don't use here so I don't seem the > warnings, but there's several threads where people have reported the > warnings, so it's apparently quite commonly triggered, but nobody has > reported any further problems even where the warnings are coming in the > hundreds due to their use-case, so as I said, apparently a false-positive > induced by normal operations. A data point: I've been running for a week with this WARN_ON replaced by a printk: --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9258,7 +9258,8 @@ void btrfs_destroy_inode(struct inode *inode) WARN_ON(BTRFS_I(inode)->outstanding_extents); WARN_ON(BTRFS_I(inode)->reserved_extents); WARN_ON(BTRFS_I(inode)->delalloc_bytes); - WARN_ON(BTRFS_I(inode)->csum_bytes); + if (BTRFS_I(inode)->csum_bytes) + printk("btrfs: btrfs_destroy_inode: WARN csum_bytes\n"); WARN_ON(BTRFS_I(inode)->defrag_bytes); /* and no data loss or anything suspicious so far. This box has a SSD (moderate use) and HDD (light use), no RAID, no quotas, compress=lzo, many subvolumes, 20ish snapshots daily (mostly sbuild for Debian packages). [~]$ dmesg|grep btrfs_destroy_inode|wc -l 50 [~]$ uptime 00:17:47 up 1 day, 18:44, 19 users, load average: 0.23, 0.35, 0.61 [~]$ cat /proc/version Linux version 4.6.0-rc6-debug+ (kilobyte@umbar) (gcc version 6.1.1 20160430 (Debian 6.1.1-1) ) #1 SMP Fri May 6 00:33:44 CEST 2016 > I'd expect the warning to be either fixed to only warn when there's an > actual issue, or be silenced, by 4.6 release. In order to get to 4.6 such a commit would need to hit Linus about right now... Meow! -- How to exploit the Bible for weight loss: Pr28:25: he that putteth his trust in the ʟᴏʀᴅ shall be made fat. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: apt taints kernel - btrfs destroys inode
Jakob Schürz posted on Sun, 01 May 2016 15:38:22 +0200 as excerpted: > What does this mean??? > > Mai 01 15:36:42 aldebaran kernel: [ cut here ] > Mai 01 15:36:42 aldebaran kernel: WARNING: CPU: 3 PID: 8937 at > /build/linux-aGlcVo/linux-4.6~rc3/fs/btrfs/inode.c:9261 > btrfs_destroy_inode+0x234/0x2a0 [btrfs] That's a known apparent false-positive warning on current 4.6-rc kernel btrfs. The destroy-inode bit is related to a file deletion happening in the normal order of things, where this warning code is run, and apparently triggers even under normal operations. It's related to some btrfs feature (I think either snapshotting or quotas, but don't recall which) I don't use here so I don't seem the warnings, but there's several threads where people have reported the warnings, so it's apparently quite commonly triggered, but nobody has reported any further problems even where the warnings are coming in the hundreds due to their use-case, so as I said, apparently a false-positive induced by normal operations. I'd expect the warning to be either fixed to only warn when there's an actual issue, or be silenced, by 4.6 release. If you want further details, as I said, there's at least two other threads with people reporting and discussing it, so read the last week or two of the list archive (or even just the non-patch original thread starter posts) and you'll find them. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
apt taints kernel - btrfs destroys inode
What does this mean??? Mai 01 15:36:42 aldebaran kernel: [ cut here ] Mai 01 15:36:42 aldebaran kernel: WARNING: CPU: 3 PID: 8937 at /build/linux-aGlcVo/linux-4.6~rc3/fs/btrfs/inode.c:9261 btrfs_destroy_inode+0x234/0x2a0 [btrfs] Mai 01 15:36:42 aldebaran kernel: Modules linked in: cpuid(E) udp_diag(E) tcp_diag(E) inet_diag(E) ip_set_hash_net(E) ip_set(E) nfnetlink(E) uas(E) usb_storage(E) rfcomm(E) xt_multiport(E) ctr(E) ccm(E) bnep(E) Mai 01 15:36:42 aldebaran kernel: videobuf2_v4l2(E) rtlwifi(E) joydev(E) videobuf2_core(E) mac80211(E) videodev(E) media(E) cfg80211(E) rtsx_pci_ms(E) memstick(E) battery(E) parport_pc(E) 8250_fintek(E) snd_hda Mai 01 15:36:42 aldebaran kernel: ppdev(E) lp(E) parport(E) efivarfs(E) autofs4(E) btrfs(E) crc32c_generic(E) xor(E) raid6_pq(E) sr_mod(E) cdrom(E) sd_mod(E) hid_generic(E) usbhid(E) hid(E) rtsx_pci_sdmmc(E) mm Mai 01 15:36:42 aldebaran kernel: CPU: 3 PID: 8937 Comm: apt-get Tainted: G U W E 4.6.0-rc3-amd64 #1 Debian 4.6~rc3-1~exp1 Mai 01 15:36:42 aldebaran kernel: Hardware name: Hewlett-Packard /2248, BIOS M74 Ver. 01.08 12/12/2014 Mai 01 15:36:42 aldebaran kernel: 0286 bf954d90 81310e95 Mai 01 15:36:42 aldebaran kernel: 8107a4ee 88004dd46180 88010c9f7dc8 Mai 01 15:36:42 aldebaran kernel: 8800a09eb800 88010c9f7dc8 880008b87058 88010c9f7dc8 Mai 01 15:36:42 aldebaran kernel: Call Trace: Mai 01 15:36:42 aldebaran kernel: [] ? dump_stack+0x5c/0x77 Mai 01 15:36:42 aldebaran kernel: [] ? __warn+0xbe/0xe0 Mai 01 15:36:42 aldebaran kernel: [] ? btrfs_destroy_inode+0x234/0x2a0 [btrfs] Mai 01 15:36:42 aldebaran kernel: [] ? __dentry_kill+0x178/0x1d0 Mai 01 15:36:42 aldebaran kernel: [] ? dput+0x11b/0x210 Mai 01 15:36:42 aldebaran kernel: [] ? __fput+0x164/0x1e0 Mai 01 15:36:42 aldebaran kernel: [] ? task_work_run+0x71/0x90 Mai 01 15:36:42 aldebaran kernel: [] ? exit_to_usermode_loop+0xba/0xc0 Mai 01 15:36:42 aldebaran kernel: [] ? syscall_return_slowpath+0x45/0x50 Mai 01 15:36:42 aldebaran kernel: [] ? system_call_fast_compare_end+0x94/0x96 Mai 01 15:36:42 aldebaran kernel: ---[ end trace 6c4d524799d6f2a2 ]--- -- http://xundeenergie.at http://verkehrsloesungen.wordpress.com/ http://cogitationum.wordpress.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html