3.7.8: PAX: refcount overflow detected in: mount:1174

[Carlos Carvalho]

I've found this in the kernel log since booting the machine with 3.7.8:

Feb 17 16:47:45 cyre kernel: PAX: refcount overflow detected in: mount:1174, uid/euid: 0/0
Feb 17 16:47:45 cyre kernel: CPU 8
Feb 17 16:47:45 cyre kernel: Pid: 1174, comm: mount Not tainted 3.7.8 #2 Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+
Feb 17 16:47:45 cyre kernel: RIP: 0010:[<ffffffff810f3ec3>] [<ffffffff810f3ec3>] ext4_fill_super+0x1183/0x24c5
Feb 17 16:47:45 cyre kernel: RSP: 0018:ffff882036915c28 EFLAGS: 00000a06
Feb 17 16:47:45 cyre kernel: RAX: 0000000000008000 RBX: ffff882037942800 RCX: ffff882037942000
Feb 17 16:47:45 cyre kernel: RDX: ffff8820378c3990 RSI: ffff88203f451920 RDI: ffff882037942800
Feb 17 16:47:45 cyre kernel: RBP: ffff882037942000 R08: 0000000000015d49 R09: 00000000000002ba
Feb 17 16:47:45 cyre kernel: R10: 8000000000000000 R11: 00000000000002ba R12: ffff88207f78a400
Feb 17 16:47:45 cyre kernel: R13: 0000000000015d49 R14: 0000000000000000 R15: ffff882037942000
Feb 17 16:47:45 cyre kernel: FS: 0000038bed0967e0(0000) GS:ffff88207fc00000(0000) knlGS:0000000000000000
Feb 17 16:47:45 cyre kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Feb 17 16:47:45 cyre kernel: CR2: 000003b22a263f38 CR3: 000000000133a000 CR4: 00000000000407f0
Feb 17 16:47:45 cyre kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Feb 17 16:47:45 cyre kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Feb 17 16:47:45 cyre kernel: Process mount (pid: 1174, threadinfo ffff882037b04ed8, task ffff882037b04b00)
Feb 17 16:47:45 cyre kernel: Stack:
Feb 17 16:47:45 cyre kernel: 0000000000000000 ffff882036915cd0 ffff8820378c3990 ffff88203f451920
Feb 17 16:47:45 cyre kernel: 0000000000000000 ffff882038c57bc8 0000000000000001 0000000400015d4b
Feb 17 16:47:45 cyre kernel: 00000000000002bb ffff882037942ae0 ffff88203792c5c0 ffffffff000002bb
Feb 17 16:47:45 cyre kernel: Call Trace:
Feb 17 16:47:45 cyre kernel: [<ffffffff810f2d40>] ? ext4_calculate_overhead+0x288/0x288
Feb 17 16:47:45 cyre kernel: [<ffffffff8115edbd>] ? snprintf+0x39/0x42
Feb 17 16:47:45 cyre kernel: [<ffffffff810f2d40>] ? ext4_calculate_overhead+0x288/0x288
Feb 17 16:47:45 cyre kernel: [<ffffffff8109063c>] ? mount_bdev+0x143/0x1b7
Feb 17 16:47:45 cyre kernel: [<ffffffff8115903c>] ? idr_pre_get+0x51/0x6c
Feb 17 16:47:45 cyre kernel: [<ffffffff8109084a>] ? mount_fs+0x10/0xa8
Feb 17 16:47:45 cyre kernel: [<ffffffff810a783c>] ? vfs_kern_mount+0x62/0xe7
Feb 17 16:47:45 cyre kernel: [<ffffffff810a7933>] ? do_kern_mount+0x49/0xe1
Feb 17 16:47:45 cyre kernel: [<ffffffff810a8e91>] ? do_mount+0x6c8/0x75a
Feb 17 16:47:45 cyre kernel: [<ffffffff81073168>] ? memdup_user+0x11b/0x177
Feb 17 16:47:45 cyre kernel: [<ffffffff81327d96>] ? int_with_check+0x1f/0x25
Feb 17 16:47:45 cyre kernel: [<ffffffff810a8fa8>] ? sys_mount+0x85/0xc3
Feb 17 16:47:45 cyre kernel: [<ffffffff81327bd8>] ? system_call_fastpath+0x18/0x1d
Feb 17 16:47:45 cyre kernel: Code: 97 f0 02 00 00 48 89 df 48 8b 74 24 18 4c 01 f2 48 89 54 24 10 e8 a5 c0 ff ff 48 8b 54 24 10 f0 01 42 04 71 06 f0 29 42 04 cd 04 <48> 8b 74 24 18 48 89 df 4d 03 b7 f0 02 00 00 e8 c2 c0 ff ff f0
Feb 17 16:47:45 cyre kernel: EXT4-fs (md3): mounted filesystem with ordered data mode. Opts: commit=30,inode_readahead_blks=64,usrquota,grpquota

Is this a problem with pax or ext4? Nothe that the moutn succeeds anyway.

[PaX Team]

it's probably a refcount false positive (i.e., an atomic variable not used as a refcount), but i'd need your corresponding vmlinux to be able to tell for sure (and then fix it).

[PaX Team]

so it turns out that this may not be a false positive after all, for a change . what the signed overflow triggered on was a struct flex_groups member (free_clusters in particular) in ext4_fill_flex_info. it seems that the fields of this structure were changed by commit 9f24e4208f7ee2748f157368b63287dc903fcf60 from __u32 to atomic_t (the latter has a signed int underneath, so that's an immediate halving of the useful range i guess). it also seems to me that these fields are actual counters of something (they get incremented/decremented on inode allocation activity), and therefore are probably not meant to overflow, so i think this is a real bug in ext4. now i could work it around in PaX to the extent that the overflows won't be reported, but the actual solution falls on the ext4 devs' shoulder. would you care to report this to them please?

[tytso]

Yes, this looks like an ext4 bug. I believe it only shows up if you are using a file system size larger than 8TB and with a non-standard flex_bg size (65536, where the default is 16), which is why we've never noticed this up until now.

Thanks for reporting it. I'll look into a fix, which will probably be replacing the use of atomic_t with atomic64_t.

Regards,

-- Ted

[PaX Team]

thanks Ted! Carlos, can you tell us a bit about your filesystem you tried to mount here? perhaps some size related fields from a dumpe2fs output?

[tytso]

Proposed fix here:

*EDIT*: Let's use this URL instead, which allows people to see any follow on comments to the patch:

http://thread.gmane.org/gmane.comp.file ... ext4/37530

[PaX Team]

just for future reference, this has been fixed in http://git.kernel.org/cgit/linux/kernel ... a9d1d46cd2 and backported to 3.8.5 at least already.