Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
When quotacheck attempts to update a gfs2 quota (that falls within block 0 of the quota file), a NULL-pointer dereference panic is triggered.

This is due to the fact that the gfs2 quota file is forcefully unstuffed in gfs2_adjust_quota(). But when quotacheck attempts the update, gfs2 concludes that no additional blocks need to be allocated as this is all in the first block of the file that's already allocated. However, the forceful unstuffing does need one block to be allocated and it panics because that block has not been allocated.

Also, there's another special case that needs handling. Some quotas lie on block boundaries and need to update two blocks instead of one. For such quotas, the block reservation for the transaction falls short of what is needed and an assert is tripped.

This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux maintenance release. Product Management has 
requested further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed 
products. This request is not yet committed for inclusion in an Update release.

Created attachment 477440 [details]
small program to update quota using quotactl

Created attachment 477441 [details]
another program to mimic operation of quotacheck utility

Created attachment 477444 [details]
patch to fix the problem

Created attachment 477451 [details]
Upstream version of the patch

Posted patch in comment #5 for inclusion upstream
Posted patch in comment #4 to rhkernel-list for inclusion in RHEL6.1

Patch(es) available on kernel-2.6.32-117.el6

Verified with attached test programs against 2.6.32-131.0.10.el6.x86_64

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0542.html