apt taints kernel - btrfs destroys inode

apt taints kernel - btrfs destroys inode

[Jakob Schürz]

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/

Re: apt taints kernel - btrfs destroys inode

[Duncan]

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

Re: apt taints kernel - btrfs destroys inode

[Adam Borowski]

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.

Re: apt taints kernel - btrfs destroys inode

[Duncan]

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