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]
Message-ID: <20150626150041.GI6271@quack.suse.cz>
Date:	Fri, 26 Jun 2015 17:00:41 +0200
From:	Jan Kara <jack@...e.cz>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Jan Kara <jack@...e.cz>
Subject: Re: [PATCH] ext4: prevent ext4_quota_write() from failing due to
 ENOSPC

On Tue 23-06-15 18:29:17, Jan Kara wrote:
> On Tue 23-06-15 10:25:45, Ted Tso wrote:
> > 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.
> 
> So quota record is actually first written from dquot_acquire() function
> which gets called (through ->acquire_dquot() callback) when we get the
> first reference to a quota structure in dqget() (called from
> dquot_initialize() / dquot_transfer()). So the problem really is in the
> lack of error propagation from dqget() up through dquot_initialize() /
> dquot_transfer() to the filesystem.
> 
> Doing the propagation for dquot_transfer() should be pretty easy since that
> already reports other errors. With dquot_initialize() it is more difficult
> since that doesn't return any errors currently so we have to add error
> handling into filesystems to the inode creation path.
> 
> I'll look into this.

The attached patch propagates errors from quota creation up into the caller
so now chown will return ENOSPC... The patch seems to work for me. Can you
check whether it fixes the failures you are seeing? If yes, I'll merge the
patch through my tree.

Missing is still handling of errors from dquot_initialize() in filesystems.
I'll add that on top if this patch works for you.

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

View attachment "0001-quota-Propagate-error-from-acquire_dquot.patch" of type "text/x-patch" (8458 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ