Warning quota dquot_claim_space

[sl45sms]

Binary package hint: quota

Linux ubuntu 2.6.31-14-server #48-Ubuntu SMP Fri Oct 16 15:07:34 UTC 2009 x86_64 GNU/Linux
Ubuntu 2.6.31-14.48-server

I get the following repeated on syslog:

Nov 10 12:26:59 ubuntu kernel: [ 425.010627] ------------[ cut here ]------------
Nov 10 12:26:59 ubuntu kernel: [ 425.010630] WARNING: at /build/buildd/linux-2.6.31/fs/quota/dquot.c:964 dquot_claim_space+0x15d/0x170()
Nov 10 12:26:59 ubuntu kernel: [ 425.010632] Hardware name:
Nov 10 12:26:59 ubuntu kernel: [ 425.010634] Modules linked in: xt_multiport quota_v2 quota_tree iptable_filter ip_tables x_tables psmouse i2c_piix4 serio_raw virtio_balloon lp parport virtio_blk floppy 8139too 8139cp mii virtio_pci virtio_ring virtio
Nov 10 12:26:59 ubuntu kernel: [ 425.010648] Pid: 25, comm: pdflush Tainted: G W 2.6.31-14-server #48-Ubuntu
Nov 10 12:26:59 ubuntu kernel: [ 425.010650] Call Trace:
Nov 10 12:26:59 ubuntu kernel: [ 425.010654] [<ffffffff8105e618>] warn_slowpath_common+0x78/0xb0
Nov 10 12:26:59 ubuntu kernel: [ 425.010658] [<ffffffff8105e65f>] warn_slowpath_null+0xf/0x20
Nov 10 12:26:59 ubuntu kernel: [ 425.010661] [<ffffffff8116e5cd>] dquot_claim_space+0x15d/0x170
Nov 10 12:26:59 ubuntu kernel: [ 425.010665] [<ffffffff811da786>] ext4_mb_mark_diskspace_used+0x356/0x3a0
Nov 10 12:26:59 ubuntu kernel: [ 425.010668] [<ffffffff811daa79>] ext4_mb_new_blocks+0x2a9/0x540
Nov 10 12:26:59 ubuntu kernel: [ 425.010672] [<ffffffff811d02a0>] ? ext4_ext_find_extent+0x130/0x2f0
Nov 10 12:26:59 ubuntu kernel: [ 425.010676] [<ffffffff811d2124>] ext4_ext_get_blocks+0x4a4/0x5b0
Nov 10 12:26:59 ubuntu kernel: [ 425.010680] [<ffffffff811b2f79>] ext4_get_blocks+0x1d9/0x210
Nov 10 12:26:59 ubuntu kernel: [ 425.010683] [<ffffffff811b3957>] mpage_da_map_blocks+0xa7/0x370
Nov 10 12:26:59 ubuntu kernel: [ 425.010688] [<ffffffff811e949e>] ? jbd2_journal_start+0xae/0x100
Nov 10 12:26:59 ubuntu kernel: [ 425.010691] [<ffffffff811b3ec3>] ext4_da_writepages+0x2a3/0x500
Nov 10 12:26:59 ubuntu kernel: [ 425.010696] [<ffffffff810e30f8>] do_writepages+0x28/0x50
Nov 10 12:26:59 ubuntu kernel: [ 425.010699] [<ffffffff8113e2cc>] writeback_single_inode+0x1bc/0x450
Nov 10 12:26:59 ubuntu kernel: [ 425.010703] [<ffffffff8113ebe8>] generic_sync_sb_inodes+0x418/0x530
Nov 10 12:26:59 ubuntu kernel: [ 425.010713] [<ffffffff8113ee0b>] writeback_inodes+0x5b/0x100
Nov 10 12:26:59 ubuntu kernel: [ 425.010716] [<ffffffff810e1e8c>] wb_kupdate+0xbc/0x140
Nov 10 12:26:59 ubuntu kernel: [ 425.010720] [<ffffffff810e38fe>] __pdflush+0x13e/0x260
Nov 10 12:26:59 ubuntu kernel: [ 425.010724] [<ffffffff810e3a20>] ? pdflush+0x0/0x50
Nov 10 12:26:59 ubuntu kernel: [ 425.010727] [<ffffffff810e3a68>] pdflush+0x48/0x50
Nov 10 12:26:59 ubuntu kernel: [ 425.010731] [<ffffffff810e1dd0>] ? wb_kupdate+0x0/0x140
Nov 10 12:26:59 ubuntu kernel: [ 425.010735] [<ffffffff810e3a20>] ? pdflush+0x0/0x50
Nov 10 12:26:59 ubuntu kernel: [ 425.010738] [<ffffffff81078236>] kthread+0xa6/0xb0
Nov 10 12:26:59 ubuntu kernel: [ 425.010741] [<ffffffff810130aa>] child_rip+0xa/0x20
Nov 10 12:26:59 ubuntu kernel: [ 425.010745] [<ffffffff81078190>] ? kthread+0x0/0xb0
Nov 10 12:26:59 ubuntu kernel: [ 425.010748] [<ffffffff810130a0>] ? child_rip+0x0/0x20
Nov 10 12:26:59 ubuntu kernel: [ 425.010750] ---[ end trace e1e81976cdd3ab12 ]---

[Derek (derek-redhat-bugs)]

Created attachment 360109
Error Message

Description of problem:

After the most recent update to the new Kernel (2.6.30.5-43.fc11.ppc.smp) After the first reboot, I got a strange red line and did not move. I rebooted the machine again and it came alive. Now I get "Message from syslogd@hotmallo at Sep 8 10:01:35 ...
 kernel:------------[ cut here ]------------"

on SSH and on the screen of the Machine it self.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.
2.
3.

Actual results:

Expected results:

Additional info:
Sep 6 21:53:17 kernel: ------------[ cut here ]------------
Sep 6 21:53:17 kernel: Badness at fs/quota/dquot.c:964
Sep 6 21:53:17 kernel: NIP: c018a754 LR: c018a724 CTR: c018a698
Sep 6 21:53:17 kernel: REGS: efb0da00 TRAP: 0700 Not tainted (2.6.30.5-43.fc11.ppc.smp)
Sep 6 21:53:17 kernel: MSR: 00029032 <EE,ME,CE,IR,DR> CR: 28008028 XER: 00000000
Sep 6 21:53:17 kernel: TASK = ef92ae80[27] 'pdflush' THREAD: efb0c000 CPU: 0
Sep 6 21:53:17 kernel: GPR00: 00000001 efb0dab0 ef92ae80 c078ea60 00000015 00000015 00002000 00000000
Sep 6 21:53:17 kernel: GPR08: 00000000 ef4510a0 00000000 00001000 22008042 00000000 c057b42c 00000001
Sep 6 21:53:17 kernel: GPR16: ef5880f0 00000000 00000001 00000000 00000000 000095f9 00000000 000095f8
Sep 6 21:53:17 kernel: GPR24: c0790000 ee673350 ef5880f0 ef5ad1b0 00000000 00002000 ee673350 efb0dab0
Sep 6 21:53:17 kernel: NIP [c018a754] dquot_claim_space+0xbc/0x1ec
Sep 6 21:53:17 kernel: LR [c018a724] dquot_claim_space+0x8c/0x1ec
Sep 6 21:53:17 kernel: Call Trace:
Sep 6 21:53:17 kernel: [efb0dab0] [c018a724] dquot_claim_space+0x8c/0x1ec (unreliable)
Sep 6 21:53:17 kernel: [efb0dad0] [c01ecbd0] ext4_mb_mark_diskspace_used+0x4a0/0x5ac
Sep 6 21:53:17 kernel: [efb0db20] [c01f17ac] ext4_mb_new_blocks+0x308/0x64c
Sep 6 21:53:17 kernel: [efb0db90] [c01e749c] ext4_ext_get_blocks+0xd0c/0xfc8
Sep 6 21:53:17 kernel: [efb0dc70] [c01cf918] ext4_get_blocks_wrap+0x174/0x358
Sep 6 21:53:17 kernel: [efb0dcb0] [c01d18b0] mpage_da_map_blocks+0xe8/0x77c
Sep 6 21:53:17 kernel: [efb0dd90] [c01d2294] ext4_da_writepages+0x350/0x570
Sep 6 21:53:17 kernel: [efb0de40] [c00f9fe4] do_writepages+0x60/0x9c
Sep 6 21:53:17 kernel: [efb0de50] [c015d3ec] __writeback_single_inode+0x184/0x324
Sep 6 21:53:17 kernel: [efb0dea0] [c015db48] generic_sync_sb_inodes+0x2b4/0x46c
Sep 6 21:53:17 kernel: [efb0def0] [c015e058] writeback_inodes+0xec/0x178
Sep 6 21:53:17 kernel: [efb0df20] [c00fa2a8] wb_kupdate+0x104/0x1ac
Sep 6 21:53:17 kernel: [efb0df80] [c00fb7e4] pdflush+0x180/0x284
Sep 6 21:53:17 kernel: [efb0dfd0] [c00856d8] kthread+0x68/0xb0
Sep 6 21:53:17 kernel: [efb0dff0] [c0019ef0] kernel_thread+0x4c/0x68
Sep 6 21:53:17 kernel: Instruction dump:
Sep 6 21:53:17 kernel: 813e0104 2f890000 419e005c 81690078 38000000 7f8be000 419c0014 40be0014
Sep 6 21:53:17 kernel: 8169007c 7f8be840 409c0008 38000001 <0f000000> 81690070 81890074 80e90078

Installed Packages:

basesystem-10.0-2.noarch
chkconfig-1.3.42-1.ppc
readline-5.2-14.fc11.ppc
libattr-2.4.43-3.fc11.ppc
libacl-2.2.47-4.fc11.ppc
file-libs-5.03-2.fc11.ppc
libidn-1.9-4.ppc
libnl-1.1-6.fc11.ppc
finduti...

[Chuck (chuck-redhat-bugs)]

static void dquot_claim_reserved_space(struct dquot *dquot,
                                                qsize_t number)
{
        WARN_ON(dquot->dq_dqb.dqb_rsvspace < number);
        dquot->dq_dqb.dqb_curspace += number;
        dquot->dq_dqb.dqb_rsvspace -= number;
}

The quota code hasn't changed, so I'd suspect and ext4 bug.

[Eric (eric-redhat-bugs)]

This is a new function made just for ext4:

740d9dcd (Mingming Cao 2009-01-13 16:43:14 +0100 961)static void dquot_claim_reserved_space(struct dquot *dquot,

commit 740d9dcd949a986c88886a591054a0cdb89ef669
Author: Mingming Cao <email address hidden>
Date: Tue Jan 13 16:43:14 2009 +0100

    quota: Add quota reservation claim and released operations

AFAIK ext4 quota wasn't really working at all prior to .30 so it's not really a regression, though it does look like a bug. Guessing a locking problem around some bucket of usage information in quota and/or ext4.

-Eric

[Derek (derek-redhat-bugs)]

Thank you for your help so far.

However, the strange part is that I do not have any quota limits for any of my users at this time.

Please let me know if you need any more information.

[Eric (eric-redhat-bugs)]

Oh, well that is most unfortunate, if you didn't even have quota set. :)

Do you have any quota on at all? (maybe quotas enabled but no limits set?)

I'll see what's going on, thanks.

-Eric

[Derek (derek-redhat-bugs)]

Correct, the quota is enabled with "Unlimited". At this time I don't have any users that I am worried about taking up to much space.

Maybe I will create a user.. with a quota limit and see what happens?

Thanks,
Derek

[Eric (eric-redhat-bugs)]

If you feel like testing, sure ;)

-Eric

[Derek (derek-redhat-bugs)]

Okay, I will do some testing on my side... I only knew how to adjust quota's via Webmin :( .....

Normally when I would go to "Quota" usages, it would give me a long list of everyone on my system and how much space they are using. That does not happen anymore. If I select my username, it does not let me edit it anymore. I would think that is a Webmin issue, but I dont know.

At this time I disabled the quota, I am going to see if I keep getting those error messages...

Thanks,

[Chuck (chuck-redhat-bugs)]

Upstream discussion:
http://marc.info/?t=125238694400002&r=1&w=2

[Derek (derek-redhat-bugs)]

(In reply to comment #7)
> Okay, I will do some testing on my side... I only knew how to adjust quota's
> via Webmin :( .....
>
> Normally when I would go to "Quota" usages, it would give me a long list of
> everyone on my system and how much space they are using. That does not happen
> anymore. If I select my username, it does not let me edit it anymore. I would
> think that is a Webmin issue, but I dont know.
>
> At this time I disabled the quota, I am going to see if I keep getting those
> error messages...
>
> Thanks,

The Error Message have stopped.. with Quota Disabled.

[Rolf (rolf-redhat-bugs)]

Same here for x86_64:

2009-09-10T14:20:01.928275+02:00 home07 kernel: ------------[ cut here ]------------
2009-09-10T14:20:01.928285+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xd9/0x14e() (Tainted: P W )
2009-09-10T14:20:01.928292+02:00 home07 kernel: Hardware name: System Product Name
2009-09-10T14:20:01.928324+02:00 home07 kernel: Modules linked in: fuse bridge stp llc bnep sco l2cap bluetooth it87 hwmon_vid nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath raid1 kvm_amd kvm uinput snd_hda_codec_analog snd_hda_intel ppdev snd_hda_codec snd_hwdep nvidia(P) snd_pcm snd_timer snd k8temp serio_raw pcspkr soundcore 8139too i2c_nforce2 snd_page_alloc parport_pc 8139cp hfcpci asus_atk0110 mISDN_core forcedeth mii parport hwmon i2c_core joydev pata_amd ata_generic pata_acpi sata_nv raid456 raid6_pq async_xor async_memcpy async_tx xor [last unloaded: scsi_wait_scan]
2009-09-10T14:20:01.928337+02:00 home07 kernel: Pid: 29, comm: pdflush Tainted: P W 2.6.30.5-43.fc11.x86_64 #1
2009-09-10T14:20:01.928343+02:00 home07 kernel: Call Trace:
2009-09-10T14:20:01.928351+02:00 home07 kernel: [<ffffffff81057104>] warn_slowpath_common+0x95/0xc3
2009-09-10T14:20:01.928359+02:00 home07 kernel: [<ffffffff81057159>] warn_slowpath_null+0x27/0x3d
2009-09-10T14:20:01.928368+02:00 home07 kernel: [<ffffffff81160b7f>] dquot_claim_space+0xd9/0x14e
2009-09-10T14:20:01.928376+02:00 home07 kernel: [<ffffffff811af275>] ext4_mb_mark_diskspace_used+0x332/0x3f0
2009-09-10T14:20:01.928385+02:00 home07 kernel: [<ffffffff811b2beb>] ext4_mb_new_blocks+0x243/0x4bc
2009-09-10T14:20:01.928394+02:00 home07 kernel: [<ffffffff811a87bf>] ? ext4_ext_find_extent+0x62/0x29c
2009-09-10T14:20:01.928402+02:00 home07 kernel: [<ffffffff811aa5ae>] ext4_ext_get_blocks+0xb69/0xd3b
2009-09-10T14:20:01.928410+02:00 home07 kernel: [<ffffffff812104d8>] ? generic_make_request+0x254/0x2b2
2009-09-10T14:20:01.928418+02:00 home07 kernel: [<ffffffff81197ca4>] ext4_get_blocks_wrap+0x117/0x271
2009-09-10T14:20:01.928427+02:00 home07 kernel: [<ffffffff81199326>] mpage_da_map_blocks+0xc0/0x5fa
2009-09-10T14:20:01.928434+02:00 home07 kernel: [<ffffffff810dd200>] ? pagevec_lookup_tag+0x34/0x54
2009-09-10T14:20:01.928442+02:00 home07 kernel: [<ffffffff810db207>] ? write_cache_pages+0x195/0x40c
2009-09-10T14:20:01.928450+02:00 home07 kernel: [<ffffffff811bfce9>] ? jbd2_journal_start+0xb7/0x106
2009-09-10T14:20:01.928459+02:00 home07 kernel: [<ffffffff81199b9d>] ext4_da_writepages+0x33d/0x53a
2009-09-10T14:20:01.928467+02:00 home07 kernel: [<ffffffff810db503>] do_writepages+0x3a/0x60
2009-09-10T14:20:01.928476+02:00 home07 kernel: [<ffffffff811345b4>] __writeback_single_inode+0x168/0x2a8
2009-09-10T14:20:01.928542+02:00 home07 kernel: [<ffffffff81134b26>] generic_sync_sb_inodes+0x21a/0x361
2009-09-10T14:20:01.928550+02:00 home07 kernel: [<ffffffff81134ee3>] writeback_inodes+0xb0/0x119
2009-09-10T14:20:01.928558+02:00 home07 kernel: [<ffffffff810db73c>] wb_kupdate+0xc0/0x14a
2009-09-10T14:20:01.928566+02:00 home07 kernel: [<ffffffff810dc802>] pdflush+0x16d/0x272
2009-09-10T14:20:01.928574+02:00 home07 kernel: [<ffffffff81...

[Theodore (theodore-redhat-bugs)]

Note: This has hit the top-ten list on kerneloops.org:

http://www.kerneloops.org/searchweek.php?search=dquot_claim_space

[Rolf (rolf-redhat-bugs)]

x86_64 again (2.6.30.9-90.fc11.x86_64)

WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xd9/0x14e() (Tainted: P W )
Hardware name: System Product Name
Modules linked in: fuse bridge stp llc bnep sco l2cap bluetooth it87 hwmon_vid nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath raid1 kvm_amd kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep ppdev snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm nvidia(P) snd_timer snd 8139too 8139cp hfcpci soundcore serio_raw i2c_nforce2 k8temp mISDN_core pata_amd parport_pc forcedeth parport asus_atk0110 mii pcspkr i2c_core joydev hwmon snd_page_alloc ata_generic pata_acpi sata_nv raid456 raid6_pq async_xor async_memcpy async_tx xor [last unloaded: scsi_wait_scan]
Pid: 29, comm: pdflush Tainted: P W 2.6.30.9-90.fc11.x86_64 #1
Call Trace:
 [<ffffffff81057098>] warn_slowpath_common+0x95/0xc3
 [<ffffffff810570ed>] warn_slowpath_null+0x27/0x3d
 [<ffffffff8115ed03>] dquot_claim_space+0xd9/0x14e
 [<ffffffff811ad445>] ext4_mb_mark_diskspace_used+0x332/0x3f0
 [<ffffffff811b0dbd>] ext4_mb_new_blocks+0x243/0x4be
 [<ffffffff811a698f>] ? ext4_ext_find_extent+0x62/0x29c
 [<ffffffff811a877e>] ext4_ext_get_blocks+0xb69/0xd3b
 [<ffffffff8120e670>] ? generic_make_request+0x254/0x2b2
 [<ffffffff81195e74>] ext4_get_blocks_wrap+0x117/0x271
 [<ffffffff811974f6>] mpage_da_map_blocks+0xc0/0x5fa
 [<ffffffff810db94c>] ? pagevec_lookup_tag+0x34/0x54
 [<ffffffff810d99bb>] ? write_cache_pages+0x195/0x40c
 [<ffffffff811bde7a>] ? jbd2_journal_start+0x74/0x106
 [<ffffffff811bdebd>] ? jbd2_journal_start+0xb7/0x106
 [<ffffffff81197d6d>] ext4_da_writepages+0x33d/0x53a
 [<ffffffff810d9cb7>] do_writepages+0x3a/0x60
 [<ffffffff8113289c>] __writeback_single_inode+0x168/0x2a8
 [<ffffffff81132e0e>] generic_sync_sb_inodes+0x21a/0x361
 [<ffffffff811331cb>] writeback_inodes+0xb0/0x119
 [<ffffffff810d9ef0>] wb_kupdate+0xc0/0x14a
 [<ffffffff810daf57>] pdflush+0x163/0x25e
 [<ffffffff810d9e30>] ? wb_kupdate+0x0/0x14a
 [<ffffffff810dadf4>] ? pdflush+0x0/0x25e
 [<ffffffff81070171>] kthread+0x6d/0xae
 [<ffffffff810528e7>] ? schedule_tail+0x38/0xa3
 [<ffffffff8101310a>] child_rip+0xa/0x20
 [<ffffffff81070104>] ? kthread+0x0/0xae
 [<ffffffff81013100>] ? child_rip+0x0/0x20

Popularity on kerneloops is rising!

[Thierry Carrez (ttx)]

Also discussed at http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-09/msg08248.html

[Rolf (rolf-redhat-bugs)]

Just an update: I updated to Fedora 12 and the problem is still there. That's no news I guess, because the kerneloops is still very "popular".

Well, anyway: kernel-2.6.31.6-145.fc12.x86_68

------------[ cut here ]------------
WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a() (Tainted: P W )
Hardware name: System Product Name
Modules linked in: fuse hwmon_vid nfs lockd fscache nfs_acl auth_rpcgss sunrpc ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath kvm_amd kvm uinput snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_hwdep nvidia(P) snd_seq snd_seq_device snd_pcm snd_timer snd soundcore amd64_edac_mod snd_page_alloc i2c_nforce2 hfcpci edac_core mISDN_core i2c_core serio_raw joydev k8temp ppdev parport_pc asus_atk0110 parport raid1 raid456 raid6_pq async_xor async_memcpy async_tx xor 8139cp pata_acpi 8139too ata_generic usb_storage mii forcedeth pata_amd sata_nv [last unloaded: scsi_wait_scan]
Pid: 1495, comm: updatedb Tainted: P W 2.6.31.6-145.fc12.x86_64 #1
Call Trace:
 [<ffffffff810516f4>] warn_slowpath_common+0x84/0x9c
 [<ffffffff81051720>] warn_slowpath_null+0x14/0x16
 [<ffffffff8113e4c4>] dquot_claim_space+0xca/0x12a
 [<ffffffff8118d852>] ext4_mb_mark_diskspace_used+0x272/0x31a
 [<ffffffff81190522>] ext4_mb_new_blocks+0x1e4/0x3fe
 [<ffffffff8118710a>] ? ext4_ext_find_extent+0x53/0x279
 [<ffffffff81188dcb>] ext4_ext_get_blocks+0xb5c/0xcea
 [<ffffffff811e72df>] ? generic_make_request+0x24e/0x2ac
 [<ffffffff8101286e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff8141a8e0>] ? __down_write_nested+0x17/0xab
 [<ffffffff8141a998>] ? __down_read+0x17/0xaa
 [<ffffffff8116dc1e>] ext4_get_blocks+0x119/0x27b
 [<ffffffff8116de34>] mpage_da_map_blocks+0xb4/0x5da
 [<ffffffff810c9879>] ? pagevec_lookup_tag+0x25/0x2e
 [<ffffffff8116e86c>] ? __mpage_da_writepage+0x0/0x153
 [<ffffffff8116e619>] ext4_da_writepages+0x2bf/0x468
 [<ffffffff810c817c>] do_writepages+0x2d/0x3c
 [<ffffffff810c1ff8>] __filemap_fdatawrite_range+0x50/0x52
 [<ffffffff810c27b9>] filemap_flush+0x1c/0x1e
 [<ffffffff8116d19a>] ext4_alloc_da_blocks+0x30/0x32
 [<ffffffff811748db>] ext4_rename+0x608/0x624
 [<ffffffff8110617b>] vfs_rename+0x225/0x3c0
 [<ffffffff811bb417>] ? security_inode_permission+0x21/0x23
 [<ffffffff811075da>] sys_renameat+0x193/0x20c
 [<ffffffff81111a09>] ? mntput_no_expire+0x29/0xec
 [<ffffffff810fb331>] ? sys_fchmodat+0xb2/0xc5
 [<ffffffff811042e1>] ? path_put+0x22/0x27
 [<ffffffff81095e6c>] ? audit_syscall_entry+0x11e/0x14a
 [<ffffffff8110766e>] sys_rename+0x1b/0x1d
 [<ffffffff81011cf2>] system_call_fastpath+0x16/0x1b
---[ end trace c9d7015b9c68d760 ]---

I'm also intrigued by the fact that this bug lives for so long. Perhaps it's no bug but a feature?

[Theodore (theodore-redhat-bugs)]

It's primarily a matter of time available from the ext4 development
community, plus the fact that very few of them run with quotas and/or
SELinux.

The warning message is mostly harmless, but it's definitely a bug that we should fix.

Would you mind answering a few questions about your system configuration?

1) Can you reproduce it easily? If so, what is the best reproduction
case?

2) Do you have both user and group quotas enabled, or just user quotas?

3) Do you have SELinux enabled?

Thanks!!

[Rolf (rolf-redhat-bugs)]

1) I initially had the problem on a Fedora 10->11 upgraded x86-64 system after converting ext3 to ext4 and enabling quota. Upgrading tot Fedora 12 did not solve the problem. Enabling or disabling SElinux has no effect, currently SElinux is permissive.
I then installed a fresh Fedora 12 KVM system, again x86_64. I created a custom file layout (/boot is ext3, / is ext4, apart from swap no other filesystems), but otherwise it's standard. SELinux is active (enforcing). After enabling quotas the reported problems showed up again.

2) Both user and group quotas are enabled

3) Yes and no. Two systems, enforcing or permissive makes no difference.

[Rolf (rolf-redhat-bugs)]

The warning message may be harmless, but it suggests there's at least something not working fine. To be more precise: are quota broken with ext4 or aren't they?

If quota are broken, people should stop using them on ext4, and they should be told.

If quota are OK, and ext4 is as well... then the message is harmless indeed, and should disappear. abrt is driving me (and itself) nuts with the huge amount of (harmless) messages that are processed.

[Eric (eric-redhat-bugs)]

Rolt, are you still encountering this problem with the 2.6.32 kernel on F12?

Thanks,
-Eric

[Eric (eric-redhat-bugs)]

Hm based on kerneloops.org, I suppose so.

[Rolf (rolf-redhat-bugs)]

Absolutely, this useless assertion still floods my syslog.

[Eric (eric-redhat-bugs)]

For what it's worth 2.6.34-rc1 has the following change:

commit 0a5a9c725512461d19397490f3adf29931dca1f2
Author: Jan Kara <email address hidden>
Date: Tue Feb 9 18:20:39 2010 +0100

    quota: Fix warning when a delayed write happens before quota is enabled

    If a delayed-allocation write happens before quota is enabled, the
    kernel spits out a warning:
    WARNING: at fs/quota/dquot.c:988 dquot_claim_space+0x77/0x112()

    because the fact that user has some delayed allocation is not recorded
    in quota structure.

    Make dquot_initialize() update amount of reserved space for user if it sees
    inode has some space reserved. Also make sure that reserved quota space does
    not go negative and we warn about the filesystem bug just once.

    Signed-off-by: Jan Kara <email address hidden>

so for one, we only get one warning now ...

However, I wonder if there's a chance that fedora bootup is doing something to cause writes prior to quota enablement... or if we are getting out of sync in another way.

[Eric (eric-redhat-bugs)]

Actually this is the other piece needed, which handles writes prior to quotaon.

From: Dmitry Monakhov <email address hidden>
Date: Tue, 9 Feb 2010 16:53:36 +0000 (+0100)
Subject: quota: manage reserved space when quota is not active [v2]
X-Git-Tag: v2.6.34-rc1~192^2~27

quota: manage reserved space when quota is not active [v2]

Since we implemented generic reserved space management interface,
then it is possible to account reserved space even when quota
is not active (similar to i_blocks/i_bytes).

Without this patch following testcase result in massive comlain from
WARN_ON in dquot_claim_space()

...

I'll do a little testing of this in the F12 kernel; it will be good to know if we actually are doing writes prior to quotaon or if there is some other accounting problem.

[Rolf (rolf-redhat-bugs)]

This may be informational, as it demonstrates the time the system is booted en the sh*tload of quota messages long after it's booted:

[root@home07 ~]# last | head
rolf pts/1 :0.0 Tue Mar 30 23:32 still logged in
rolf pts/0 :0.0 Tue Mar 30 19:11 still logged in
rolf tty1 :0 Tue Mar 30 19:06 still logged in
reboot system boot 2.6.32.9-70.fc12 Tue Mar 30 19:04 - 23:35 (04:31)
rolf pts/1 :0.0 Tue Mar 30 08:22 - 08:22 (00:00)

[root@home07 ~]# grep dquot_claim_space /var/log/messages | tail -n 50
2010-03-30T23:31:49.372978+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:49.373078+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:31:49.384245+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:31:49.384597+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:31:49.384943+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:49.385052+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:31:54.384332+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:31:54.384454+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:31:54.384729+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:54.384829+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:31:59.394486+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:31:59.394614+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:31:59.394910+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:31:59.395012+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:32:29.428766+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:32:29.429044+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:32:29.429740+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:32:29.429863+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:32:59.429518+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:32:59.429636+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:32:59.429928+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xca/0x12a()
2010-03-30T23:32:59.430029+02:00 home07 kernel: [<ffffffff811646ec>] dquot_claim_space+0xca/0x12a
2010-03-30T23:33:29.485002+02:00 home07 kernel: WARNING: at fs/quota/dquot.c:964 dquot_claim_space+0xa2/0x12a()
2010-03-30T23:33:29.485515+02:00 home07 kernel: [<ffffffff811646c4>] dquot_claim_space+0xa2/0x12a
2010-03-30T23:33:29.487117+02:00 home07 kernel: WARNING: at ...

[Rolf (rolf-redhat-bugs)]

So, if there's a testable kernel, I think it's good if I give it a try.

[Eric (eric-redhat-bugs)]

I've got this reproducing just fine here, finally, so I'll poke at it a bit myself. I'll let you know when there's something for you to test, ok?

Right now I have it on the stock f12 kernel; I first want to instrument it to see what the bad values are in this condition, then I'll likely test upstream to see if it's any different.

But what I'm seeing rules out "writes before quota was turned on" - this is clearly happening runtime, I think.

Thanks,
-Eric

[Eric (eric-redhat-bugs)]

Just for posterity, we're off by about this much:

inode 13866 reserved 0, claiming 4096
inode 13866 reserved 0, claiming 4096
inode 256521 reserved 0, claiming 4096
inode 256521 reserved 0, claiming 4096
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 306162 reserved 0, claiming 4096
inode 306162 reserved 0, claiming 4096
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 44925 reserved 0, claiming 4096
inode 330300 reserved 0, claiming 4096
inode 330300 reserved 0, claiming 4096
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 101443 reserved 8192, claiming 12288
inode 101443 reserved 8192, claiming 12288
inode 44925 reserved 4096, claiming 8192
inode 44925 reserved 0, claiming 4096
inode 121139 reserved 8192, claiming 12288
inode 121139 reserved 8192, claiming 12288

So claiming one more block than reserved, and in some cases having reserved none.

I thought it could possibly be the selinux xattr block, but seems not - persists to some degree at least even w/o selinux enabled.

-Eric

[Norman (norman-redhat-bugs)]

I occasionally the warning messages mentioned in this bugzilla.

I don't know if it's related, but often when I call setquota(8) I also get these messages in syslog:

Mar 31 10:16:59 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 102818). There's a risk of filesystem corruption in case of system crash.
Mar 31 10:16:59 turing kernel: JBD: Spotted dirty metadata buffer (dev = dm-1, blocknr = 102818). There's a risk of filesystem corruption in case of system crash.

Perhaps this is related? I get these messages much more often than the other warnings here.

[Eric (eric-redhat-bugs)]

Norman, the spotted dirty metadata business probably needs to be its own bug ...

as far as the quota issue,

http://marc.info/?l=linux-ext4&m=127004978200365&w=2

I proposed pushing

0a5a9c725512461d19397490f3adf29931dca1f2 quota: Fix warning when a delayed write happens before quota is enabled

and

c469070aea5a0ada45a836937c776fd3083dae2b quota: manage reserved space when quota is not active [v2]

to -stable, they seem to fix things up on my box just fine.

Rolf, if you're able to compile your own kernels and want to test, go for it ...

One interesting tidbit is that quota complains that /etc/mtab was written before quota was turned on; I don't think there's any way around this! :)

-Eric

[Norman (norman-redhat-bugs)]

> Norman, the spotted dirty metadata business probably needs to be its own bug

OK, I've made bug 578674

[Rolf (rolf-redhat-bugs)]

I included the patches in 2.6.32.10-90.fc12.src.rpm and did a rebuilt. After installing the resulting kernel 2.6.32.10-90.fc12.x86_64 I did a reboot, and so far (5 minutes) no more disturbing messages. I'll check later again te see if all is still quiet.

[Rolf (rolf-redhat-bugs)]

Created attachment 403897
The spec for my modified 2.6.32.10-90.fc12.x86_64 kernel

This spec file includes the patches that may solve the dquot_claim_space messages, the patches in the spec are Patch20001 and Patch20002

[Rolf (rolf-redhat-bugs)]

Several hours later syslog is still quiet. And quota seem to work reliably.

So it looks like a fix!

[Eric (eric-redhat-bugs)]

Good deal, thanks.

After I pinged Jan, found out he'd already submitted the patches for -stable (just yesterday) :)

F12 just went to 32.11 so .12 might be a ways out; I'm putting the patches in cvs today.

Thanks,
-Eric

[Eric (eric-redhat-bugs)]

Committed to F12 CVS.

Sorry this one took so long. :)

[Jeremy Foshee (jeremyfoshee)]

Hi sl45sms,

This bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux 479916

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.