linux-ext4 - Re: Journaled quota

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 28 Aug 2018 10:27:50 +0200
From:   Jan Kara <jack@...e.cz>
To:     Liu Bo <obuil.liubo@...il.com>
Cc:     linux-ext4@...r.kernel.org, Jan Kara <jack@...e.cz>
Subject: Re: Journaled quota

Hi!

On Mon 27-08-18 12:01:10, Liu Bo wrote:
> I've run into a problem that "repquota" doesn't always show the latest
> quota stats when using journaled quota of v2, "aquota.group".
> 
> Here's the steps:
> 1. quotacheck -cug /mnt
> 2. quotaon -g /mnt
> 3. setquota -g 0 0 2G 0 0 /mnt
> 4. repquota -g /mnt
> 
> # in step 4, it didn't always show 2G as the hardlimit
> 
> I straced repquota and had realized that it does call both ->sync_fs()
> and sync_blockdev() and then truncates quota file's page cache to
> avoid userspace programs reading stale quota stats.  However, the
> changes that "setquota" writes to quota files are stored as metadata
> in ext4 and the "bh" is then marked as "jbddirty".  At the ->sync_fs()
> time, if the bh is modified by a later transaction while committing
> ext4's journal, the journal bh "jh" makes it to disk while the "bh" is
> not, and the "bh" is again queued in BJ_Metadata list and marked
> "jbddirty", the point is "bh" is not marked as dirty so that
> sync_blockdev() is not able to flush it to disk, then the end result
> is that quota file "aquota.group" still has stale data which
> "repquota" is reading and showing.
> 
> I found the above in an old 3.x kernel, but I've checked that the
> logic also applied to 4.18.
> 
> I was wondering if it was a known problem or am I missing anything?

I was not aware of this problem but you are right that if the buffer with
latest quota data gets modified after repquota(8) calls ->sync_fs() and
before it calls sync_blockdev(), then sync_blockdev() won't checkpoint the
data (write them to final location on disk) and thus repquota(8) won't see
them when reading quota information. This is inherent to how JBD2
journalling works and is difficult to avoid (the only way I currently see
is to freeze the journal which also forces checkpointing of all the
transactions but that is much more heavyweight operation).

The problem with data visibility in aquota.* files also exists in 4.18
kernel, however newer kernels (and quota tools) have different way of
reporting quotas - they have Q_GETNEXTQUOTA quotactl which repquota(8) will
use if available and that fixes this problem as repquota(8) no longer needs
to read quota files directly.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR