linux-ext4 - Re: [PATCH RFC 0/3] Block reservation for ext3

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] [day] [month] [year] [list]

Message-ID: <20101013001739.GA4833@thunk.org>
Date:	Tue, 12 Oct 2010 20:17:39 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Jan Kara <jack@...e.cz>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-ext4@...r.kernel.org
Subject: Re: [PATCH RFC 0/3] Block reservation for ext3

On Wed, Oct 13, 2010 at 01:14:08AM +0200, Jan Kara wrote:
> c) When we decide some reservation scheme is unavoidable, there is question
>    how to estimate amount of indirect blocks. My scheme is one possibility,
>    but there is a wider variety of tradeoffs between complexity and
>    accuracy. A special low effort, low impact possibility here might be to
>    just ignore the ENOSPC problem as we did so far, reserve only quota for
>    data block on page fault, and rely on the fact that there isn't going to
>    be that much metadata so user cannot exceed his quota limit by too
>    much... But when we already have the interface change, it seems a bit
>    stupid not to fix it properly and also handle ENOSPC with it.

We ultimately decided to do two different things for ENOSPC versus
EDQUOTA in ext4.  For quota overflow we just assume that the number of
metadata blocks won't be that many, and just allow them to go over
quota.  For ENOSPC, we would force writeback to see if it would free
space, and ultimately we would drop out of delayed allocation mode
when we were close to running out of space (and for non-root users we
would depend on the 5% blocks reserved for root). 

Yeah, that means if root application mmap's a huge 100GB sparse
region, and we only have 2GB free in the file system, and then the
application proceeds to write to all 100GB of mmap'ed region, there's
a chance data might get silently lost when we drop out of delalloc
mode and we then really do completely run out of memory.  But really,
what we are we supposed do?  Unless you have the kernel break out in
hysterical laughter and reject the mmap at allocation time, I suppose
the only other thing we could do, if silently dropping data is
unacceptable, is we can send the SEGV early even though we might have
a few blocks left.  That way the data loss isn't silent (the
application will probably drop core and die instead), so it's no
longer our problem.  :-)

						- Ted
--
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