Bug 660717 - gfs2 FIEMAP oops
Summary: gfs2 FIEMAP oops
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 14
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Josef Bacik
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: 663041 663042
TreeView+ depends on / blocked
Reported: 2010-12-07 16:48 UTC by Petr Pisar
Modified: 2011-02-08 12:15 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 663041 663042 (view as bug list)
Last Closed: 2011-02-08 12:15:46 UTC
Type: ---

Attachments (Terms of Use)

Description Petr Pisar 2010-12-07 16:48:13 UTC

I created 200 MB big gfs2 file system without locking (lock_nolock) and 1 journal. I raised quota limit for root user to 2 MB, created 1 MB file and found quotas were not enabled during mount (gfs2_quota check reported mismatches).

I removed the file, umounted the file system and mounted with `quota' option, recreated the 1 MB file, synced quotas successfully, repquota (from `quota' package) reported correct values, however gfs2_quota segfaulted.

Then I enlarged the file to 3 MB and kernel did allow it. (I expected the write(2) failed.) I run gfs2_quota sync, however it never returned from syscall. I got following oops in kernel log:

[28299.494077] ------------[ cut here ]------------
[28299.494081] kernel BUG at fs/gfs2/bmap.c:587!
[28299.494083] invalid opcode: 0000 [#1] SMP 
[28299.494087] last sysfs file: /sys/devices/system/cpu/cpu3/cache/index2/shared_cpu_map
[28299.494089] CPU 3 
[28299.494091] Modules linked in: gfs2 dlm configfs sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf tun bridge stp llc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 xt_physdev nf_conntrack_sip kvm_intel kvm snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer hp_wmi rfkill snd ppdev soundcore snd_page_alloc parport_pc parport serio_raw tg3 x38_edac iTCO_wdt wmi edac_core iTCO_vendor_support microcode cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt usb_storage nouveau ttm drm_kms_helper drm i2c_algo_bit video output i2c_core [last unloaded: scsi_wait_scan]
[28299.494144] Pid: 10210, comm: gfs2_quota Tainted: G          I #1 0AA0h/HP xw4600 Workstation
[28299.494147] RIP: 0010:[<ffffffffa03c45b8>]  [<ffffffffa03c45b8>] gfs2_block_map+0x52/0x7fc [gfs2]
[28299.494162] RSP: 0018:ffff8800b8c77bc8  EFLAGS: 00010246
[28299.494165] RAX: 0000000000000000 RBX: ffff880100358d60 RCX: 000000000000000c
[28299.494167] RDX: ffff8800b8c77d68 RSI: 0000000000000000 RDI: ffff880100358d60
[28299.494170] RBP: ffff8800b8c77cf8 R08: ffffffffa03c4566 R09: 0000000000000000
[28299.494172] R10: 00000000000006b4 R11: 0000000000000006 R12: ffff8800b8c77d68
[28299.494175] R13: ffff8800b8c4d000 R14: 0000000000001000 R15: 0000000000001000
[28299.494178] FS:  00007ff4429c2720(0000) GS:ffff880002180000(0000) knlGS:0000000000000000
[28299.494181] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[28299.494184] CR2: 000000365fee51a0 CR3: 0000000085811000 CR4: 00000000000406e0
[28299.494186] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[28299.494189] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[28299.494192] Process gfs2_quota (pid: 10210, threadinfo ffff8800b8c76000, task ffff8800b8bbc5c0)
[28299.494195] Stack:
[28299.494196]  ffff8800b8c77bd8 ffffffff814698de ffff8800b8c77bf8 ffffffffa03cc940
[28299.494200] <0> ffff880105a548c0 ffff8800b8c77c68 ffff8800b8c77c18 ffffffffa03cdd1e
[28299.494205] <0> 0000000000000000 ffff8800b8c77c68 ffff880000000000 ffffffffa03cdd89
[28299.494210] Call Trace:
[28299.494216]  [<ffffffff814698de>] ? _raw_spin_lock+0xe/0x10
[28299.494226]  [<ffffffffa03cc940>] ? gfs2_glock_schedule_for_reclaim+0x47/0x8a [gfs2]
[28299.494237]  [<ffffffffa03cdd1e>] ? gfs2_glock_put+0x10b/0x111 [gfs2]
[28299.494248]  [<ffffffffa03cdd89>] ? gfs2_holder_uninit+0x23/0x38 [gfs2]
[28299.494259]  [<ffffffffa03ced3b>] ? gfs2_glock_dq_uninit+0x1e/0x23 [gfs2]
[28299.494273]  [<ffffffffa03d78eb>] ? gfs2_open+0x0/0x168 [gfs2]
[28299.494286]  [<ffffffffa03d7a1e>] ? gfs2_open+0x133/0x168 [gfs2]
[28299.494291]  [<ffffffff81066380>] ? bit_waitqueue+0x17/0xa9
[28299.494294]  [<ffffffff81066380>] ? bit_waitqueue+0x17/0xa9
[28299.494298]  [<ffffffff811241c2>] __generic_block_fiemap+0x10e/0x2be
[28299.494307]  [<ffffffffa03c4566>] ? gfs2_block_map+0x0/0x7fc [gfs2]
[28299.494321]  [<ffffffffa03da62c>] gfs2_fiemap+0xde/0x103 [gfs2]
[28299.494335]  [<ffffffffa03da24f>] ? gfs2_glock_nq_init+0x16/0x37 [gfs2]
[28299.494338]  [<ffffffff81124778>] do_vfs_ioctl+0x324/0x49b
[28299.494342]  [<ffffffff81124945>] sys_ioctl+0x56/0x79
[28299.494346]  [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b
[28299.494349] Code: 4f 5c 48 89 fb 48 89 b5 10 ff ff ff 49 89 d4 4c 8b a8 80 02 00 00 48 8b 42 20 48 d3 e8 45 8b 75 64 85 c0 89 85 40 ff ff ff 75 02 <0f> 0b 31 c0 83 bd 20 ff ff ff 00 48 8d 95 50 ff ff ff b9 14 00 
[28299.494378] RIP  [<ffffffffa03c45b8>] gfs2_block_map+0x52/0x7fc [gfs2]
[28299.494378]  RSP <ffff8800b8c77bc8>
[28299.494410] ---[ end trace a7919e7f17c0a727 ]---

I have no experience with GFS2, so I did maybe something wrong. I will try to reproduce the bug after reboot.

Comment 1 Steve Whitehouse 2010-12-08 10:08:14 UTC
The system call in which the oops has triggered is the FIEMAP ioctl and not the quota sync syscall.

It appears to have triggered this check:

int gfs2_block_map(struct inode *inode, sector_t lblock,
                   struct buffer_head *bh_map, int create)
        const unsigned int maxlen = bh_map->b_size >> inode->i_blkbits;
        BUG_ON(maxlen == 0);

so it looks like somehow a request has been passed to GFS2 asking to map an extent which is 0 blocks in length. That sounds like something which the generic part of FIEMAP should really be checking for.

It doesn't appear that this has any direct relationship with quota, anyway. We'll try and fix this up as soon as we can.

Comment 2 Steve Whitehouse 2010-12-08 10:14:14 UTC
Petr, also I should explain that the quota limits in GFS2 are not always exact. There is a lot of overhead in making the limits exact, so that running with defaults, it is sometimes possible to exceed the limits. We have mount command line options which bound the quota accuracy in time and space and these can be changed to give exact results if required.

Also note that root doesn't have quota limits enforced normally. You'll need to try your test with non-root users I suspect.

Comment 4 Steve Whitehouse 2011-02-08 12:15:46 UTC
Now fixed in the upstream kernel. Josef, are you intending to send it to -stable as well? It probably should be copied there.

Note You need to log in before you can comment on or make changes to this bug.