When meta_bg feature is enabled, the total number of group descriptors
is not really limiting the filesystem size. So there's no reason to
check it in that case. This allows resize2fs to resize filesystems past
256TB boundary similarly as the kernel can do it.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Link: https://lore.kernel.org/r/20240925171926.11354-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This test verifies that e2fsck clears the orphan file if it is present.
The filesystem was created by simply creating a bunch of empty files and,
while those files were open by an application, delete some of them in
order to add them to the orphan file. After this, the filesystem is
simply powered off. An e2fsck will need to clear the orphaned inodes but
also to clean the orphan file.
Signed-off-by: Luis Henriques (SUSE) <luis.henriques@linux.dev>
Link: https://lore.kernel.org/r/20240611142704.14307-3-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If the filesystem supports the orphan file feature and that file is present
then don't skip the filesystem checks as that file may need to be cleaned
up.
Signed-off-by: Luis Henriques (SUSE) <luis.henriques@linux.dev>
Link: https://lore.kernel.org/r/20240611142704.14307-2-luis.henriques@linux.dev
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Write the mke2fs and debugfs output from f_badjour_encrypted/script
into a log file instead of stdout/stderr, so that it doesn't mess
up the "make check" output, and is available if this test ever fails.
[ Fixed missing definition of $LOG -- TYT ]
Fixes: b0cd09e5 ("e2fsck: don't allow journal to have encrypt flag")
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Link: https://lore.kernel.org/r/20240605200408.55221-1-adilger@dilger.ca
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
In commit 3ab99d9b60, the build system was changed not to set
_FILE_OFFSET_BITS explicitly due to some weird error on mips64el.
Unfortunately, this breaks the aarch64 Debian build because libfuse
2.9.9 requires this value to be set explicitly. Restore this dumb
preprocessor symbol dependency with even more hackery as documented in
the commit.
Fixes: 3ab99d9b60 ("Remove explicit #define of _FILE_OFFSET_BITS")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Link: https://lore.kernel.org/r/20240529181214.GA52969@frogsfrogsfrogs
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This has recently started being used by ext2fs.h. Other users of the
ext2fs.h header would always get the 32-bit versions of the
__encode_extra_time, __decode_extra_sec, and __sb_set_tstamp; and the
64-bit version of __sb_get_tstamp, due to the SIZEOF_TIME_T macro
being undefined and treated as zero.
Fixes: 5b599a32 ("Fix 32-bit build and test failures")
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Link: https://lore.kernel.org/r/20240527074121.2767083-1-hi@alyssa.is
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This fixes a Lintian warning which is triggered by an arbtrary
MANROFFSEQ='' environment variable:
an.tmac:<standard input>:376: warning: tbl preprocessor failed, or it or soelim was not run; table(s) likely not rendered (TE macro called with TW register undefined)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
So far, we have used `instalable: false` to avoid collision with the
other modules that are installed to the same path. A typical example was
<foo> and <foo>.microdroid. The latter is a modified version of the
former for the inclusion of the microdroid image. They however both have
the same instalation path (ex: system/bin) and stem (ex: foo) so that we
can reference them using the same path regardless of whether we are in
Android or microdroid.
However, the use of `installable: false` for the purpose is actually
incorrect, because `installable: false` also means, obviously, "this
module shouldn't be installed". The only reason this incorrect way has
worked is simply because packaging modules (ex: android_filesystem)
didn't respect the property when gathering the modules.
As packaging modules are now fixed to respect `installable: false`, we
need a correct way of avoiding the collision. `no_full_install: true` is
it.
If a module has this property set to true, it is never installed to the
full instal path like out/target/product/<partition>/... It can be
installed only via packaging modules.
Bug: 338160898
Test: m
Change-Id: Idb173a7e3528c96b23f857bb3bdf5f37e698c445
From AOSP commit: 21a895548df7de83ce1e2e146e1718e5f723af7f
borked and breaks asan build
Bugs: me
Test: build with SANITIZE_HOST=address
Change-Id: I9ae15ba328081c38e31c61834e80ce10765f9e30
From AOSP commit: eff2c071b546c3d2d3ea5eb89328babcc48e4bc2
vendor_init needs to execute these binaries when converting partitions
to EXT4.
Test: th
Bug: 293313353
Change-Id: I1fa49c1a0f802b3c36e96112ef262bae4d5d394a
From AOSP commit: 0b54b8227815d447b52de76bb419735b21608941
It was being installed on some products when it shouldn't be.
Bug: 205632228
Test: m installclean && m with aosp/2773149
Change-Id: I7f4642ba6fa8d97f7711b6df57c4e3fd781b40fd
From AOSP commit: ecb8d2faa7411d9de228a3bd8b883ed2d5220188
Fix same_file() to use stat() instead of lstat() when checking the
paths, so that symlinks are dereferenced. This is needed to be
consistent with how the paths are actually accessed later. Otherwise,
not all cases where the input and output file are the same are detected.
Also just use the stat() result to check whether the output file exists,
instead of using a separate call to access().
Fixes: db6f320912 ("AOSP: android: add the ext2simg tool")
Change-Id: Ie36981f9dbc19494732f518488a75fb92c0f0343
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: 08c122f12fc231029a74c24b969e337203c7b6e2
Check the return value of io_channel_read_blk64() correctly, considering
that it returns an errcode_t, which can be positive.
Fixes: db6f320912 ("AOSP: android: add the ext2simg tool")
Change-Id: Iafc6c0169bc8ac79198f285da0246ff3b841ded8
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: 60634ff32a0d8c0d7942c6e522a74a5051d4b6e9
libsparse assumes 32-bit block numbers. Also, ext2simg might read
nearly the entire filesystem into memory.
Therefore, make ext2simg use appropriate integer types, and explicitly
check for when the filesystem is too large or allocating memory failed.
Change-Id: Ic415d0e974dce2b4ff6e7fa9265f6e86d371a274
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: 8fff11068c100be627745967992fb88759dea9c1
Remove a level of indentation, check a bool in the normal way, and
simplify the linked list handling. No change in behavior.
Change-Id: I12589a254f155b1c40418458a666b87c7ef5c1cf
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: 7d0f5c1aca332da22e4878f5825e0ffb5122f96b
Use a standard flexible array instead of a nonstandard zero-length
array. No change in behavior.
Change-Id: Ifdce24f5d6e2471634bb785527def3fe8fefc202
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: c88ea796fbf7f4c79155196ec483681b3733bbff
For the values that get used as the 'bool' parameters of
sparse_file_write(), use 'bool' in ext2simg too. No change in behavior.
Change-Id: I05f7d6fd3027eb10231c035f9fdc8e946e2c4c90
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: 2728c6e766976acbf442d3721f2d93960e13682e
File identity is determined by the combination of st_dev and st_ino, not
by st_ino alone.
This fixes a bug where ext2simg would needlessly make a copy of all the
data when the input and output files happened to have the same st_ino.
Fixes: db6f320912 ("AOSP: android: add the ext2simg tool")
Change-Id: I94e4bf57d9f91b31e5438768805e9f10bec3411d
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: 0749f83a2cf4c134a2403701ab78388500e53f76
The chunk_end parameter to add_chunk() is exclusive, but two callers
incorrectly treat it as inclusive: when the maximum chunk length of
'INT32_MAX - 12' bytes is reached, and when a chunk extends to the very
end of the filesystem. The result is that the output simg file contains
zeroes for the last block of these chunks instead of the correct data.
A related bug is that the expanded size of the simg file is set to the
filesystem size (in blocks) minus s_first_data_block. On filesystems
where s_first_data_block != 0, i.e. 1K blocksize filesystems without
bigalloc enabled, this truncates the last block of the filesystem.
Fix these bugs by (a) making add_chunk() take the chunk length and
passing the correct values, and (b) using the filesystem size properly.
Here is a reproducer that shows the last block of the filesystem being
truncated (bsize=1024) and being corrupted with zeroes (bsize=4096):
for bsize in 1024 4096; do
rm -f ext4.img
mkfs.ext4 -b $bsize ext4.img 10000
mkdir -p mnt
sudo mount -t ext4 -o loop ext4.img mnt
sudo cp /dev/urandom mnt/fill
sudo umount mnt
ext2simg ext4.img ext4.simg
simg2img ext4.simg ext4.img.restored
cmp ext4.img ext4.img.restored
done
Fixes: db6f320912 ("AOSP: android: add the ext2simg tool")
Reported-by: Clemens Lang <clemens.lang@bmw.de>
Change-Id: I3b64c4fbffa5821b431f29e99b36168617da7563
Signed-off-by: Eric Biggers <ebiggers@google.com>
From AOSP commit: 1e498908c6ac13b4d5ec0117f4ddcd577aac607e
It turns out the "Can't use getmntent or getmntinfo" warning was the
only warning remaining in the macOS build via the Android build system.
So now that it's fixed, -Wno-error can be removed.
That being said, the upstream CI (GitHub Actions) currently uses
-Wno-error=deprecated-declarations for the macOS build, since it's still
needed for some files (which aren't built by the Android build system).
For now, let's just replace -Wno-error with
-Wno-error=deprecated-declarations to match what the upstream CI uses.
Change-Id: I77f6649b99432ef1d73a0c7e30bbb150c3111b27
From AOSP commit: 6ea38ded59fe970704612a31a3aea4ccaf923d6a
macOS supports getmntinfo(), but not getmntent(). To match what the
'configure' script detects, define HAVE_GETMNTINFO to 1.
This prevents the following warning:
#warning "Can't use getmntent or getmntinfo to check for mounted filesystems!"
Bug: 267448785
Change-Id: I3131563fc317fa9fef7745937ec2c4b09a1d29b0
From AOSP commit: bb6d46cc9770f4f15a5e52122a16f762c1bb567a
Unfortunately, the macOS build is not tested either by presubmit or by
local builds. A macOS build *is* being tested in the upstream GitHub
Actions workflow now; however, that uses the autotools-based build
system, and there can be issues specific to the Android build system.
As a result, removing -Wno-error was not safe yet, and the macOS build
is currently broken in postsubmit. As there could be multiple issues,
let's restore -Wno-error until I've had a chance to fix the warnings.
Bug: 267448785
Change-Id: I305f73d1f8637477da3d57b6c93037a6e3d9e829
From AOSP commit: 0ed82a3f0a393605b56672704379f4fc1e53d281
The qcow2.h header file uses types such __u32 which are defined in
ext2_types.h. So include it directly to avoid relying on users of the
qcow2.h header file to include right dependencies.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Some old tests of EA inodes were not in fact completely fixing the
filesystem (like they were leaving directories with EA_INODE_FL set or
EA inodes referenced from directory hierarchy). New e2fsck checks fix
these so golden output changes. Update it.
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240506174132.12883-3-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Currently checking of EA inodes was rather weak. Add several more
consistency checks.
1) Check that EA inode is a regular file.
2) Check that EA_INODE feature is set if the filesystem has EA inodes.
3) Make sure that no EA inode is referenced from directory hierarchy.
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240506174132.12883-1-jack@suse.cz
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
There's a issue:
[]$~/e2fsprogs/e2fsck/e2fsck -f scsi-disk2.img
e2fsck 1.47.0 (5-Feb-2023)
scsi-disk2.img: recovering journal
Clearing orphaned inode 12 (uid=0, gid=0, mode=0140777, size=0)
Pass 1: Checking inodes, blocks, and sizes
Extended attribute block 4247 has reference count 3, should be 2. Fix<y>? no
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (249189, counted=249188).
Fix<y>? no
Free inodes count wrong (65526, counted=65523).
Fix<y>? no
scsi-disk2.img: ***** FILE SYSTEM WAS MODIFIED *****
scsi-disk2.img: ********** WARNING: Filesystem still has errors **********
scsi-disk2.img: 10/65536 files (0.0% non-contiguous), 12955/262144 blocks
Above issue can reproduce as follows:
step1: socat UNIX-LISTEN:/home/test/mysocket.sock,mode=777,reuseaddr,fork EXEC:/home/test &
step2: setfacl some xattr for mysocket.sock
step3: cp -a /home/test/mysocket.sock /home/test/sock1
cp -a /home/test/mysocket.sock /home/test/sock2
step4: sync
step5: Power-off
step6: run e2fsck
As after commit 42475e281d add ext2fs_inode_has_valid_blocks() judgement in
release_inode_blocks() which means socket type file skip realse block include
ACL block. The kernel does not restrict the setting of extended attributes for
socket files. So this will lead to ACL block leak.
To solve above issue there's need to release ACL block for other kind of
special file.
Fixes: 42475e281d ("super.c (release_inode_blocks): Don't try to release the blocks if the orphaned inode is a device file, symlink, or some other kind of special file that doesn't have a block list.")
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240418063946.2802835-1-yebin10@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
If sysconf(_SC_NPROCESSORS_CONF) returns zero, this can cause a divide
by zero. Make ext2fs_rw_bitmaps() more robust defaulting to 4 threads
if _SC_NPROCESSORS_CONF returns an invalid value.
https://github.com/tytso/e2fsprogs/issues/114
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The size of msg_buffer is carefully calculated so it can never
overflow, but it triggers a Coverity warning. Use snprintf instead of
sprintf to silence the Coverity warning.
Addresses-Coverty-Bug: 1520603
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The in-memory data structures used time_t for the grace period (which
is a delta timestamp denominated in seconds), as well as the soft
limit expiration time (which is an actual time_t). Use an explicit
__u32 for the former, and the __u64 for the latter.
This silences a Coverity warning, but more importantly, using an
explicit __u64 for the expiration time means that running e2fsck on a
platform with a 32-bit time_t, and it needs to read and then modify a
quota structure, we won't lose the high 32-bits of the quota
expiration time.
Addresses-Coverity-Bug: 1531824
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
