I guess it's just another instance of
http://kerneloops.org/searchweek.php?search=dquot_claim_space

There are instances of this bug Redhat, Novell, Ubuntu and I suppose other bugzillas. Mingming who wrote the code doesn't seem to have time to fix it
so I guess I'll have to dive into the deep dark corners of ext4 mballoc allocator. I've already tried but always gave it up after half an hour with disgust ;)

OK, ok, I'm finishing with ranting and going to do some work...

This bug exists also in mainline kernel. I suppose is not necessary to fill another bug report.

No. BTW: Do you have any recipe how to trigger the warning?

Nope it appears suddenly.
The message repeats quite often but quota works as I can see...

lease tell me if there's anything I can help I can provide shell access to this machine is nit a production environment yet.

Dmitry Monakhov has just fixed several bugs in ext4 quota reservation which should hopefully also fix your problem. I'll attach here a combo patch with all the fixes.

Created attachment 24208 [details]
Patch with various ext4 quota fixes

This patch is on top of current Linus's tree. You can for example take 2.6.32-git12 (http://www.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.32-git12.bz2) as a base for my patch.

Could you please try running with the above fix and see whether your issue gets fixed? Thanks.

ok I just upgraded to 2.6.32.2, I will post here if anything else accurs.

------------[ cut here ]------------
WARNING: at fs/quota/dquot.c:964 ()
Hardware name:
Pid: 1755, comm: flush-254:0 Not tainted 2.6.32-xpr-cp #1
Call Trace:
 [<ffffffff81368b82>] ?
 [<ffffffff810ed0ba>] ?
 [<ffffffff81033630>] ?
 [<ffffffff810ed0ba>] ?
 [<ffffffff811473dd>] ?
 [<ffffffff81147650>] ?
 [<ffffffff8113e0a1>] ?
 [<ffffffff8104aa40>] ?
 [<ffffffff81192b72>] ?
 [<ffffffff81190411>] ?
 [<ffffffff8119313d>] ?
 [<ffffffff81128e4e>] ?
 [<ffffffff811291c7>] ?
 [<ffffffff8106f03a>] ?
 [<ffffffff8106d3a4>] ?
 [<ffffffff8112b580>] ?
 [<ffffffff8112c588>] ?
 [<ffffffff810c4e60>] ?
 [<ffffffff810c5f40>] ?
 [<ffffffff811aba53>] ?
 [<ffffffff810bcfd2>] ?
 [<ffffffff810bd85e>] ?
 [<ffffffff810bdac8>] ?
 [<ffffffff810bddae>] ?
 [<ffffffff810bde28>] ?
 [<ffffffff81079440>] ?
 [<ffffffff810794a3>] ?
 [<ffffffff8104aa06>] ?
 [<ffffffff810034ca>] ?
 [<ffffffff8104a970>] ?
 [<ffffffff810034c0>] ?
---[ end trace a92b953f5f42206a ]---


that would be 2.6.32.2, seems like the problem persists.

I also need to mention that all this is inside a KVM virtual machine. Virtio block

2.6.32.2 does not have the fixes - Greg has included the fixes into his stable tree queue just yesterday. So either you have to wait for the next -stable release or try the patch above...

patch seems to work, when will it be included in stable?

Thanks for testing the patch! There appeared some problems with the fix so it was not included in the latest -stable release. Hopefully I can get it into the next one.

ok, I am back
now the codes are mouch more often, and it's 2.6.32.8

------------[ cut here ]------------
WARNING: at fs/quota/dquot.c:964 ()
Hardware name: VMware Virtual Platform
Modules linked in:
Pid: 979, comm: syslogd Tainted: G        W  2.6.32.8 #1
Call Trace:
 [<ffffffff810e8a4a>] ?
 [<ffffffff810e8a4a>] ?
 [<ffffffff81030635>] ?
 [<ffffffff810e8a4a>] ?
 [<ffffffff8113a4ed>] ?
 [<ffffffff81135453>] ?
 [<ffffffff8113a760>] ?
 [<ffffffff811311a0>] ?
 [<ffffffff810bedbd>] ?
 [<ffffffff8139a940>] ?
 [<ffffffff81132c63>] ?
 [<ffffffff81119d35>] ?
 [<ffffffff81146ff6>] ?
 [<ffffffff8111bf5e>] ?
 [<ffffffff811ade23>] ?
 [<ffffffff8111c2d7>] ?
 [<ffffffff810706ca>] ?
 [<ffffffff8106eb24>] ?
 [<ffffffff8111e630>] ?
 [<ffffffff8106945d>] ?
 [<ffffffff8111f632>] ?
 [<ffffffff81097a3b>] ?
 [<ffffffff810482d0>] ?
 [<ffffffff81068d3b>] ?
 [<ffffffff81068db1>] ?
 [<ffffffff8139a660>] ?
 [<ffffffff810bcf6a>] ?
 [<ffffffff810bd056>] ?
 [<ffffffff810bd0ab>] ?
 [<ffffffff810023eb>] ?
---[ end trace bb0af93142efddf7 ]---

this error now comes almoust every minute....

That's nasty. We didn't get all the fixes to stable because they were just too big :(. Could you try running with 2.6.33-rc8 kernel? That should solve your problems...

the 2.6.33-rc8 version acts like this:

------------[ cut here ]------------
WARNING: at fs/quota/dquot.c:984 dquot_claim_space+0x12a/0x130()
Hardware name: VMware Virtual Platform
Modules linked in:
Pid: 791, comm: flush-8:0 Not tainted 2.6.32-xpr #1
Call Trace:
 [<ffffffff810e719a>] ? dquot_claim_space+0x12a/0x130
 [<ffffffff810e719a>] ? dquot_claim_space+0x12a/0x130
 [<ffffffff81033ae5>] ? warn_slowpath_common+0x85/0xb0
 [<ffffffff810e719a>] ? dquot_claim_space+0x12a/0x130
 [<ffffffff8111a943>] ? ext4_da_update_reserve_space+0x233/0x360
 [<ffffffff81130951>] ? ext4_ext_get_blocks+0x1561/0x16a0
 [<ffffffff81049000>] ? bit_waitqueue+0x10/0xb0
 [<ffffffff8118d622>] ? get_request+0x2f2/0x380
 [<ffffffff8118aee1>] ? elv_rb_add+0x61/0x70
 [<ffffffff81342415>] ? __down_write_nested+0x15/0xd0
 [<ffffffff8111ab72>] ? ext4_get_blocks+0x102/0x230
 [<ffffffff8111adb0>] ? mpage_da_map_blocks+0xb0/0x6a0
 [<ffffffff8107716a>] ? pagevec_lookup_tag+0x1a/0x30
 [<ffffffff810755c5>] ? write_cache_pages+0xe5/0x330
 [<ffffffff8111d040>] ? __mpage_da_writepage+0x0/0x170
 [<ffffffff8111e039>] ? ext4_da_writepages+0x329/0x6d0
 [<ffffffff81198b03>] ? cpumask_next_and+0x23/0x40
 [<ffffffff810bc2f2>] ? writeback_single_inode+0x92/0x280
 [<ffffffff810bcbb0>] ? writeback_inodes_wb+0x270/0x390
 [<ffffffff810bce06>] ? wb_writeback+0x136/0x1f0
 [<ffffffff810bd104>] ? wb_do_writeback+0x174/0x190
 [<ffffffff810bd15b>] ? bdi_writeback_task+0x3b/0xc0
 [<ffffffff81080b90>] ? bdi_start_fn+0x0/0xd0
 [<ffffffff81080bf3>] ? bdi_start_fn+0x63/0xd0
 [<ffffffff81048d86>] ? kthread+0x96/0xa0
 [<ffffffff81002f54>] ? kernel_thread_helper+0x4/0x10
 [<ffffffff81048cf0>] ? kthread+0x0/0xa0
 [<ffffffff81002f50>] ? kernel_thread_helper+0x0/0x10
---[ end trace 9af19d2cc5731f69 ]---

at least seems to be more specific:)

Hmm, the version 2.6.32-xpr looks strange. Are you sure it's 2.6.33-rc8? And by any chance: Don't you write to the filesystem before turning quotas on? If yes, you might want to try 2.6.33-rc8 with the two patches I'll attach here applied.

Created attachment 25192 [details]
Patches fixing WARN_ON when filesystem is written before quota is turned on

the problem is that I am kind of stuck with the 2.6.32 branch because of the grsecurity patch which is crucial for tpe and some security stuff implemented in it, it's a shell access machine and it was already targeted twice.

I am recompiling the kernel with those patches now. thank you

ok, with this patches and correct kernel version I have enabled journaled quota.
The error dissapeared but I have grsec features missing now, is there any plan to include this on the main kernel? 2.6.32 ? thank you

Ah, finally. Thanks for testing. Since Linus has just released 2.6.33 they won't make it there but I'll push these two patches to 2.6.33-stable. For 2.6.32 - quite a bit had to be done in 2.6.33 to fix all the breakage so pushing all the stuff to 2.6.32-stable isn't likely...

BTW: When these patches fix problems for you, it means that you write to the filesystem before running quotaon and thus your quota accounting is going to be
imprecise. It's good to turn on quotas from init scripts so that such things
cannot happen...

yes, im already reveiving errors regardign that I will check out init scripts.
also im using rhel 5 and rhel's quota does not support ext4 so is quite a diff.

so when 2.6.33 will be out I suppose this patches will be included ?

The problem is 2.6.33 *is* already out :) So the above two patches will be only in the first stable release...

then I guess 2.6.33.1 is what im waiting for.