linux-ext4 - Re: [PATCH] ext4: prevent ext4_quota_write() from failing due to ENOSPC

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, 23 Jun 2015 10:25:45 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Cc:	Jan Kara <jack@...e.cz>
Subject: Re: [PATCH] ext4: prevent ext4_quota_write() from failing due to
 ENOSPC

On Sun, Jun 21, 2015 at 01:27:42AM -0400, Theodore Ts'o wrote:
> In order to prevent quota block tracking to be inaccurate when
> ext4_quota_write() fails with ENOSPC, we make two changes.  The quota
> file can now use the reserved block (since the quota file is arguably
> file system metadata), and ext4_quota_write() now uses
> ext4_should_retry_alloc() to retry the block allocation after a commit
> has completed and released some blocks for allocation.
> 
> This fixes failures of xfstests generic/270:
> 
> Quota error (device vdc): write_blk: dquota write failed
> Quota error (device vdc): qtree_write_dquot: Error -28 occurred while creating quota
> 
> Signed-off-by: Theodore Ts'o <tytso@....edu>

This patch significantly reduces the incidence of generic/270 failing,
but it doesn't completely eliminate them, especially when using a 1k
block size.  This makes sense, because what this generic/270 does is
to chown files to random uid's using an ENOSPC hitter as an
antagonist.  This means the quota system needs to allocate a huge
number of blocks, and with a 1k block, it's doing 4x the number
allocations.

Something we could do that would help this situation is if there was
an interface in the quota system that initialized the quota records
for a particular uid or gid, which we could call from ext4_setattr()
or ext4_open() *before* we actually need to allocate a block quota
record for the file.

(We do check the error return from dquot_transfer() and abort if it
fails, but either the allocation qtree_write_dquot() isn't getting
perculated all the way up to dquot_transfer(), or the quota mismatch
is taking place because we're doing the chown on an empty file, and
then when we subsequently write to the file, that's when the quota
record is created and by the time we try to resolve the quota file
update, it's too late to back out the delayed allocation write.)

Jan, does that make sense to you as a way to solve this issue?

     	       	    	     	 - Ted

P.S.  BTW, have you had a chance to take a look at the various
competing project quota patches and do you have an opinion about their
disposition?  Project quota hasn't been high priority for me, to be
honest, but there are people who seem to care about it, and I've been
waiting to see what you think about the patchsets from Li Xi and
Konstantin Khlebnikov.  Thanks!!

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html