Bug 53591

ACtually quotas just don't seem to update at all unless you do quotacheck.

Here's the end of an strace:
lseek(3, 31550464, SEEK_SET)            = 31550464
read(3, "", 1024)                       = 0
lseek(3, 31562752, SEEK_SET)            = 31562752
read(3, "", 1024)                       = 0
lseek(3, 31575040, SEEK_SET)            = 31575040
read(3, "", 1024)                       = 0
lseek(3, 31538176, SEEK_SET)            = 31538176
read(3, "", 1024)                       = 0
lseek(3, 31522816, SEEK_SET)            = 31522816
read(3, "", 1024)                       = 0
lseek(3, 31559680, SEEK_SET)            = 31559680
read(3, "", 1024)                       = 0
lseek(3, 1567744, SEEK_SET)             = 1567744
read(3, "\0\0\0\0\0\0\0\0\25\0\0\0\0\0\0\0=y\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
lseek(3, 31781888, SEEK_SET)            = 31781888
read(3, "", 1024)                       = 0
lseek(3, 31818752, SEEK_SET)            = 31818752
read(3, "", 1024)                       = 0
lseek(3, 31815680, SEEK_SET)            = 31815680
read(3, "", 1024)                       = 0
lseek(3, 31823872, SEEK_SET)            = 31823872
read(3, "", 1024)                       = 0
lseek(3, 31820800, SEEK_SET)            = 31820800
read(3, "", 1024)                       = 0
lseek(3, 31828992, SEEK_SET)            = 31828992
read(3, "", 1024)                       = 0
lseek(3, 31819776, SEEK_SET)            = 31819776
read(3, "", 1024)                       = 0
lseek(3, 31826944, SEEK_SET)            = 31826944
read(3, "", 1024)                       = 0
lseek(3, 31827968, SEEK_SET)            = 31827968
read(3, "", 1024)                       = 0
lseek(3, 31817728, SEEK_SET)            = 31817728
read(3, "", 1024)                       = 0
lseek(3, 31814656, SEEK_SET)            = 31814656
read(3, "", 1024)                       = 0
lseek(3, 31822848, SEEK_SET)            = 31822848
read(3, "", 1024)                       = 0
lseek(3, 31825920, SEEK_SET)            = 31825920
read(3, "", 1024)                       = 0
lseek(3, 31821824, SEEK_SET)            = 31821824
read(3, "", 1024)                       = 0
lseek(3, 31824896, SEEK_SET)            = 31824896
read(3, "", 1024)                       = 0
lseek(3, 31816704, SEEK_SET)            = 31816704
read(3, "", 1024)                       = 0
lseek(3, 31835136, SEEK_SET)            = 31835136
read(3, "", 1024)                       = 0
lseek(3, 31838208, SEEK_SET)            = 31838208
read(3, "", 1024)                       = 0
lseek(3, 31831040, SEEK_SET)            = 31831040
read(3, "", 1024)                       = 0
lseek(3, 9216, SEEK_SET)                = 9216
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1024) = 1024
socket(PF_UNIX, SOCK_STREAM, 0)         = 4
connect(4, {sin_family=AF_UNIX, path="                                                                                       /var/run/.nscd_socket"}, 110) = 0
write(4, "\2\0\0\0\1\0\0\0\2\0\0\0", 12) = 12
write(4, "8\0", 2)     = 2
read(4, "\350\22\30@\1\0\0\0\5\0\0\0\2\0\0\0\10\0\0\0\f\0\0\0\5"..., 36) = 36
read(4, "mail\0x\0mail\0/var/spool/mail\0\0", 29) = 29
close(4)                                = 0
time([1025026691])                      = 1025026691
time([1025026691])                      = 1025026691
--- SIGSEGV (Segmentation fault) ---

I wonder why there are so many seeks past the end-of-file?

Here's a backtrace from an unstripped repquota:
(gdb) bt
#0  0x0804dd5c in report_tree (dquot=0x8054c38, blk=1531, depth=3, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:696
#1  0x0804dda6 in report_tree (dquot=0x8054c38, blk=3, depth=2, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:703
#2  0x0804dda6 in report_tree (dquot=0x8054c38, blk=2, depth=1, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:703
#3  0x0804dda6 in report_tree (dquot=0x8054c38, blk=1, depth=0, 
    bitmap=0x8054c90 "`\a 
P{\177_{\177Gw\237o}]w\177}ow?{o\177~wm\177{o?v{o{/\217}w{{w?_{o\177o}\177w__}\177o}?w
}\003Aj", '' <repeats 15 times>, "s{~_soo75~}~~~{w\177w~w\203", process_dquot=0x80496b0 <print>) at 
quotaio_v2.c:703
#4  0x0804deb9 in v2_scan_dquots (h=0x8056088, process_dquot=0x80496b0 <print>)
    at quotaio_v2.c:733
#5  0x08049960 in report_it (h=0x8056088, type=0) at repquota.c:151
#6  0x08049a15 in report (type=0) at repquota.c:170
---Type <return> to continue, or q <return> to quit---
#7  0x08049a7d in main (argc=2, argv=0xbffff914) at repquota.c:183
#8  0x4003d647 in __libc_start_main (main=0x8049a30 <main>, argc=2, 
    ubp_av=0xbffff914, init=0x8048ef4 <_init>, fini=0x8050460 <_fini>, 
    rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xbffff90c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) print i
$15 = 226
(gdb) print blk
$16 = 193368

Apparently blk is too large for the bitmap (which maxes out at 17264 bytes).  Is info->dqi_blocks the highest used pointer block or is it a count of the 
number of pointer blocks?  Is the tree allowed to be fragmented?

Fixed with quota 0.3-8
(created a 64Mb file in test's home dir then deleted it) to get a before and
after snapshot)


[root@dhcp59-202 root]# repquota -ua > l

[root@dhcp59-202]$ su - test
[test@dhcp59-202]$ rm test

[root@dhcp59-202 root]# repquota -ua > ll

[root@dhcp59-202 root]# diff l ll 
38c38
< test      --   65668 5242880 5242880             17     0     0       
---
> test      --      64 5242880 5242880             16     0     0       


Please try ftp://ftp.redhat.com/pub/redhat/linux/rawhide/SRPMS/SRPMS
quota-3.06-4.src.rpm

Phil
=--=

ack with quota 3.06-4 I meant to say, not 0.3-8..
appologies

Phil
=--=

This doesn't work for me.  Granted my quota files have some corruption, but
couldn't repquota handle this more gracefully?

Created attachment 75924 [details]
Patch to skip invalid block pointers

I've attached a patch that fixes the segfaults on my machine.  It silently
ignores block pointers that are too large.  You might want to change this to
print a warning instead.  Also, does the info->dqi_blocks limit apply to tree
nodes as well?  If so, it may be more efficient to check those pointers also.

Is my patch incorporated into quotacheck as well?  It segfaulted on me this morning.

Similar problems in #91022. See also releated quota bug #90939.

Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.

Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.