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  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:	Wed, 26 Jun 2013 10:54:17 -0400
From:	Theodore Ts'o <>
To:	Nagachandra P <>
Cc:	Vikram MP <>,
Subject: Re: Memory allocation can cause ext4 filesystem to be remounted r/o

On Wed, Jun 26, 2013 at 10:02:05AM -0400, Theodore Ts'o wrote:
> In this particular case, we could reflect the error all the way up to
> the ftruncate(2) system call.  Fixing this is going to be a bit
> involved, unfortunately; we'll need to update a fairly large number of
> function signatures, including ext4_truncate(), ext4_ext_truncate(),
> ext4_free_blocks(), and a number of others.

One thing that comes to mind.  If we change things so that ftruncate
reflects an ENOMEM error all the way up to userspace, one side effect
of this is that the file may be partially truncated when ENOMEM is
returned.  Applications may not be prepared for this.

There would be a similar issue if we do the truncate in the unlink
call and return ENOMEM in case of a failure, the file might not be
unlinked, and in fact we might have a partially truncated file in the
directory, which would probably cause all sorts of confusion.  So
we're probably better off, putting the inode on a list of inodes in
memory, and on the orphan list on disk, and then retry the truncation
when memory is available.  Messy, but that probably gives the best
result for applications living constantly in high memory pressure

							- Ted
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists