* apt taints kernel - btrfs destroys inode
@ 2016-05-01 13:38 Jakob Schürz
2016-05-02 0:38 ` Duncan
0 siblings, 1 reply; 4+ messages in thread
From: Jakob Schürz @ 2016-05-01 13:38 UTC (permalink / raw)
To: linux-btrfs
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: 0000000000000286 00000000bf954d90
ffffffff81310e95 0000000000000000
Mai 01 15:36:42 aldebaran kernel: 0000000000000000 ffffffff8107a4ee
ffff88004dd46180 ffff88010c9f7dc8
Mai 01 15:36:42 aldebaran kernel: ffff8800a09eb800 ffff88010c9f7dc8
ffff880008b87058 ffff88010c9f7dc8
Mai 01 15:36:42 aldebaran kernel: Call Trace:
Mai 01 15:36:42 aldebaran kernel: [<ffffffff81310e95>] ?
dump_stack+0x5c/0x77
Mai 01 15:36:42 aldebaran kernel: [<ffffffff8107a4ee>] ? __warn+0xbe/0xe0
Mai 01 15:36:42 aldebaran kernel: [<ffffffffc04fed34>] ?
btrfs_destroy_inode+0x234/0x2a0 [btrfs]
Mai 01 15:36:42 aldebaran kernel: [<ffffffff81207b98>] ?
__dentry_kill+0x178/0x1d0
Mai 01 15:36:42 aldebaran kernel: [<ffffffff81207d0b>] ? dput+0x11b/0x210
Mai 01 15:36:42 aldebaran kernel: [<ffffffff811f2dd4>] ? __fput+0x164/0x1e0
Mai 01 15:36:42 aldebaran kernel: [<ffffffff81097431>] ?
task_work_run+0x71/0x90
Mai 01 15:36:42 aldebaran kernel: [<ffffffff8100333a>] ?
exit_to_usermode_loop+0xba/0xc0
Mai 01 15:36:42 aldebaran kernel: [<ffffffff81003c05>] ?
syscall_return_slowpath+0x45/0x50
Mai 01 15:36:42 aldebaran kernel: [<ffffffff815c44fe>] ?
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/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: apt taints kernel - btrfs destroys inode
2016-05-01 13:38 apt taints kernel - btrfs destroys inode Jakob Schürz
@ 2016-05-02 0:38 ` Duncan
2016-05-07 23:11 ` Adam Borowski
0 siblings, 1 reply; 4+ messages in thread
From: Duncan @ 2016-05-02 0:38 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: apt taints kernel - btrfs destroys inode
2016-05-02 0:38 ` Duncan
@ 2016-05-07 23:11 ` Adam Borowski
2016-05-08 6:31 ` Duncan
0 siblings, 1 reply; 4+ messages in thread
From: Adam Borowski @ 2016-05-07 23:11 UTC (permalink / raw)
To: linux-btrfs, Duncan
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: apt taints kernel - btrfs destroys inode
2016-05-07 23:11 ` Adam Borowski
@ 2016-05-08 6:31 ` Duncan
0 siblings, 0 replies; 4+ messages in thread
From: Duncan @ 2016-05-08 6:31 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-05-08 6:31 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-01 13:38 apt taints kernel - btrfs destroys inode Jakob Schürz
2016-05-02 0:38 ` Duncan
2016-05-07 23:11 ` Adam Borowski
2016-05-08 6:31 ` Duncan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.