The ext2_off_t and ext2_off64_t types are used by ext2_file_lseek()
and ext2_file_llseek(), and they need to be signed so that it can be a
negative offset from the end of the file when EXT2_SEEK_END is used.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The type ext2_off64_t should only be used in the context of the ext2fs
library's llseek() and ftruncate() analogs, ext2_file_llseek() and
ext2_inode_set_size(). That's because like the POSIX.1's off_t, it
needs to be a signed integer value so that SEEK_END will work
correctly.
qcow.c's use of ext2_off64_t is only internal, and not in any exposed
interfaces, so changes nothing; it just prepares us to be able to
change the type of ext2_off64_t.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
We mark the bad blocks as used on fs->block_map before allocating
group tables. Don't translate the block number to cluster number when
doing this, the fs->block_map is still a block-granularity allocation
map, it will be coverted later by ext2fs_convert_subcluster_bitmap().
Signed-off-by: Li Dongyang <dongyangli@ddn.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Also, add a missing dash and two missing brackets and two missing
spaces, and remove three excess spaces.
Signed-off-by: Benno Schulenberg <bensberg@telfort.nl>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Don't reserve blocks in the base map if the file does not exist in the
target image. This can happen if a file is removed or renamed in between
two builds. If the removed file is quite large, skipping it is important
since otherwise it will prevent blocks from being allocated for new files.
Bug: 145316683
Test: e2fsdroid with dynamic partitions
Change-Id: I63a9372c58adeaae3e1235fd92fed78a284ed391
From AOSP commit: 2b6646a3d2a7dd9972275cb829239ae033762da5
When using a Base FS map, track deduplicated blocks in a separate
bitmap. The first inode to request a block from this set will succeed
in getting the block. Blocks in the dedup set are not available for
libext2fs to allocate; this ensures that previously deduplicated blocks
are re-used for their original purpose.
Note that deduplication takes priority over block allocation, so that
once a block is removed from the dedup set, that does not actually
prevent it from being re-used. Similarly, a file that was not previously
sharing a block may have its blocks shared in the new image.
Bug: 145316683
Test: e2fsdroid with dynamic partitions
Change-Id: I73856faa5d294a7b5fb985ccd1a6974a989481ea
From AOSP commit: 4e55425ff5d7d7cea27dcf79125766762e2b3529
If certain metadata properties change in between builds, such as the
inode table size, then block mappings may not be valid from one build to
the next. For example, build A could allocate block N for a file. If
build B has a larger inode table, block N may no longer be a data block.
In this case, we need to remove the block from the BaseFS range list so
we do not give it back to libext2fs for writing data. We do this with a
new "owned_block_map" bitmap. If a block from the base FS is not in use
by the initial image, and is not used by any other file, it is
considered owned, and can be claimed by that file.
Note that while this produces correct images, it also prevents
deduplicated blocks from being re-used. This will be addressed in a
follow-up patch.
Bug: 145316683
Test: e2fsdroid block mapping with dynamic partitions
Change-Id: I3145e45156f7879bdf956384723fab4bd69acb93
Signed-off-by: David Anderson <dvander@google.com>
From AOSP commit: b3d1ccdb673772588b7bb14c4581980ef549a0b8
This refactors base_fs_alloc_load() to address two issues. First, the
failure cases have been made simpler by factoring out a common helper
for freeing a base_fs_allocator. Second, we no longer return
EXIT_FAILURE, since this is not an errcode_t.
Bug: 145316683
Change-Id: I8b28c684ecf3423b605b550177d7ead4eb2821a4
From AOSP commit: b461ade872a809ab913d7506e9b8ed597d57dc87
block_range is a singly-linked list, but the head/tail links are
manually managed all over. Instead, introduce a block_range_list
structure and refactor list helpers to operate on this instead. This
ensures head/tail are maintained properly (in some cases, like
delete_block_range, they were not).
Bug: 145316683
Test: manual test
Change-Id: Ieec6324549e2c3a71129871f703f4f0a37aeb1fa
From AOSP commit: 4220594792297619d2e70a29476667d1698dbd63
Make libext2-headers and libext2_uuid available to vendor and
product. They are required by f2fs-tools which are installed in
product partition.
Bug: 120954888
Bug: 145580164
Test: set PRODUCT_PRODUCT_VNDK_VERSION := current and build
Change-Id: Ibf5678448f9efbcb72c0544a3a50280fbfee2f38
From AOSP commit: 2c79a5f79197c090fc9c9534546f4ab4f7690809
The problem is alloc_blocks() will call get_next_block() which might
reallocate outdir->buf, and memory address could be changed after
this. To fix this, pointers that point into outdir->buf, such as
int_limit and root need to be recaulated based on the new starting
address of outdir->buf.
[ Changed to correctly recalculate int_limit, and to optimize how we
reallocate outdir->buf. -TYT ]
Signed-off-by: Wang Shilong <wshilong@ddn.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The function ext2fs_inode_i_blocks() is a bit confusing whether it is
returning the inode's i_blocks value, or whether it is returning the
value ala the stat(2) system call, which returns i_blocks in units of
512 byte sectors. This caused ext2fs_inode_i_blocks() to be
incorrectly used in fuse2fs and the function quota_compute_usage().
To address this, we add a new function, ext2fs_get_stat_i_blocks()
which is clearly labelled what it is returning, and use it in fuse2fs
and quota_compute_usage(). It's also a bit more convenient to use it
in e2fsck, so use it there too.
Reported-by: Wang Shilong <wangshilong1991@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Previously, uids were truncated at 16 bits because we weren't properly
handling i_uid_high and i_gid_high.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If directory has been deleted in pass1[bcd] processing, then we
shouldn't try to rehash the directory in pass 3a when we try to
rehash/reoptimize directories.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In e2fsck pass 3a, when we are rehashing directories, at least in
theory, all of the directories should have had corruptions with
respect to directory entry structure fixed. However, it's possible
(for example, if the user declined a fix) that we can reach this stage
of processing with a corrupted directory entries.
So check for that case and don't try to process a corrupted directory
block so we don't run into trouble in mutate_name() if there is a
zero-length file name.
Addresses: TALOS-2019-0973
Addresses: CVE-2019-5188
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Optimize _("getting next inode from scan") so it is not called for
each initialized inode in the file system, and make a similar
optimization in pass 2 for each directory block.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This program calls a few ext2fs library functions used by the current
generation of libext2fs fuzzers, and is helpful in reproducing UBSAN
failures reported externally.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
An internal customer followed an erroneous AskUbuntu article[1] to try to
change the UUID of a live ext4 filesystem. The article claims that you
can work around tune2fs' "cannot change UUID on live fs" error by
disabling uninit_bg, changing the UUID, and re-enabling the feature.
This led to metadata corruption because tune2fs' journal descriptor
rewrite races with regular filesystem writes. Therefore, prevent
administrators from turning on or off uninit_bg on a mounted fs.
[1] https://askubuntu.com/questions/132079/how-do-i-change-uuid-of-a-disk-to-whatever-i-want/195839#459097
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Setting a bit to 0 is normally called "clearing", not "resetting"; and
chattr.1 already says "clear" in some places. Use "clear" consistently.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This old text was never updated to mention ext4 in addition to ext2 and
ext3. Do so now. Also don't bother to mention old unmerged patches.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
- "can only be open" => "can only be opened"
- "is not candidate" => "is not a candidate"
- "written ... on the disk" => "written ... to the disk"
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When the casefold attribute ('F') was added to the chattr man page, it
was forgotten to add it to the mode string. Add it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Adjust the documentation for the encryption attribute ('E') to clarify
that encryption isn't experimental anymore and isn't restricted to
regular files, and that the encryption is done by the filesystem.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The AX_CHECK_MOUNT_OPT macro fails if /usr/include/sys/mount.h.
Unfortunately, the GNU HURD doesn't have this header file. Drop the
requirement, since if it doesn't exist, the macro will assume that
given mount options don't exist, which for e2fsprogs is used to test
to for the existence of the mount options nosuid and nodev. This is
only used for fuse2fs, and HURD doesn't support fuse2fs anyway.
Addresses-Debian-Bug: #944649
Reported-by: Svante Signell <svante.signell@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If there is a trickster which tries to use device names as the mount
device for pseudo-file systems, the resulting /proc/mounts can confuse
ext2fs_check_mount_point(). (So far as I can tell, there's no good
reason to do this, but sysadmins do the darnest things.)
An example of this might be the following /proc/mounts excerpt:
/dev/sdb /mnt2 tmpfs rw,relatime 0 0
/dev/sdb /mnt ext4 rw,relatime 0 0
This is created via "mount -t tmpfs /dev/sdb /mnt2" followed via
"mount -t ext4 /dev/sdb /mnt". (Normally, a sane mount of tmpfs would
use something like "mount -t tmpfs tmpfs /mnt2".)
Fix this by double checking the st_rdev of the claimed mountpoint and
match it with the dev_t of the device. (Note that the GNU HURD
doesn't support st_rdev, so we can't solve this problem for the HURD.)
Reported-by: GuiYao <guiyao@huawei.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently, the estimate of minimum filesystem size is using free blocks
counter in the superblock. The counter generally doesn't get updated
while the filesystem is mounted and thus the estimate is very unreliable
for a mounted filesystem. For some usecases such as automated
partitioning proposal to the user it is desirable that the estimate of
minimum filesystem size is reasonably accurate even for a mounted
filesystem. So use group descriptor counters of free blocks for the
estimate of minimum filesystem size. These get updated together with
block being allocated and so the resulting estimate is more accurate.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
gregor herrmann reports that the weekly e2scrub cronjob emits these
errors:
/sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or directory
The root cause of this is that the ls_targets stdout is piped to stdin
to the entire ls_targets loop body to prevent the loop body from reading
the loop iteration items. Remove all the broken hackery by reading the
target list into a bash array and iterating the bash array.
Addresses-Debian-Bug: #944033
Reported-by: gregor herrmann <gregoa@debian.org>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Dave Chinner complains that the automated on-boot e2scrub reaping takes
a long time (because the lvs command can take a while to run) even
though the automated e2scrub is disabled via e2scrub.conf on his
systems.
We still need the reaping service to kill off stale e2scrub snapshots
after a crash, but it's unnecessary to annoy everyone with slow bootup.
Because we can look for the e2scrub snapshots in /dev/mapper, let's
skip reaping if periodic e2scrub is disabled unless we find evidence of
e2scrub snapshots in /dev.
Reported-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This avoids a potential UBsan failure when we multiply an insanely
high block number with the block size and we get a multiplication
overflow.
Google-Bug-Id: 128130353
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Use ext2fs_free_{block,inode}_bitmaps() instead of ext2fs_free_mem()
to avoid some memory leaks if there is an error while calling
read_bitmaps().
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If count * block_size exceeds 2GB, we will overflow a 32-bit signed
integer value. This shouldn't happen in practice except for
fuzz-corrupted file systems, but let's fix the code so it's correct.
Bug: https://github.com/tytso/e2fsprogs/issues/24
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The testing links are not stable and are not guaranteed to exist.
Test: After re-generating the generated files, the link works now.
Change-Id: I36e73ef74571b3246f470280a75ae1098245eff5
From AOSP commit: 5971f6a5113b12b33d9454229bf27621853e1da7
Test: see I3781b6d1e55923e9410644e8a7ba834b4d13b733
Change-Id: Ie071b30937dcf73f34df5dc3aa08d23ae30d9c63
From AOSP commit: d2a16e1616b807a6143b9c6232a1c54f90dc06f6
Try to make it clearer that enabling 'encrypt' just enables *support*
for encryption; it doesn't actually encrypt anything by itself.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Try to make it clearer that enabling 'encrypt' just enables *support*
for encryption; it doesn't actually encrypt anything by itself.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The features are listed in alphabetic order, so put the casefold feature
in the right place.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Some versions of cron leave fd 3 open for some unknown reason. So
when e2scrub_all is run by cron (on non-systemd systems) this results
in an annoying message from the Cron Daemon because lvm will print
warning messages about "leaked file descriptors. So force close fd 3
at the beginning of e2scrub and e2scrub_all.
Addresses-Debian-Bug: #940240
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
