<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/git/stable/linux-stable.git/fs/ext4/ialloc.c, branch linux-4.19.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<id>https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-4.19.y</id>
<link rel='self' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/atom?h=linux-4.19.y'/>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/'/>
<updated>2024-11-08T15:19:06+00:00</updated>
<entry>
<title>ext4: avoid negative min_clusters in find_group_orlov()</title>
<updated>2024-11-08T15:19:06+00:00</updated>
<author>
<name>Kemeng Shi</name>
<email>shikemeng@huaweicloud.com</email>
</author>
<published>2024-08-20T13:22:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=7b98a77cdad322fa3c7babf15c37659a94aa3593'/>
<id>urn:sha1:7b98a77cdad322fa3c7babf15c37659a94aa3593</id>
<content type='text'>
[ Upstream commit bb0a12c3439b10d88412fd3102df5b9a6e3cd6dc ]

min_clusters is signed integer and will be converted to unsigned
integer when compared with unsigned number stats.free_clusters.
If min_clusters is negative, it will be converted to a huge unsigned
value in which case all groups may not meet the actual desired free
clusters.
Set negative min_clusters to 0 to avoid unexpected behavior.

Fixes: ac27a0ec112a ("[PATCH] ext4: initial copy of files from ext3")
Signed-off-by: Kemeng Shi &lt;shikemeng@huaweicloud.com&gt;
Link: https://patch.msgid.link/20240820132234.2759926-4-shikemeng@huaweicloud.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ext4: make directory inode spreading reflect flexbg size</title>
<updated>2022-09-28T09:02:58+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2022-09-08T09:21:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=66b955d30f8cf4949a590bf6ce7b264b5ab64dea'/>
<id>urn:sha1:66b955d30f8cf4949a590bf6ce7b264b5ab64dea</id>
<content type='text'>
commit 613c5a85898d1cd44e68f28d65eccf64a8ace9cf upstream.

Currently the Orlov inode allocator searches for free inodes for a
directory only in flex block groups with at most inodes_per_group/16
more directory inodes than average per flex block group. However with
growing size of flex block group this becomes unnecessarily strict.
Scale allowed difference from average directory count per flex block
group with flex block group size as we do with other metrics.

Tested-by: Stefan Wahren &lt;stefan.wahren@i2se.com&gt;
Tested-by: Ojaswin Mujoo &lt;ojaswin@linux.ibm.com&gt;
Cc: stable@kernel.org
Link: https://lore.kernel.org/all/0d81a7c2-46b7-6010-62a4-3e6cfc1628d6@i2se.com/
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Link: https://lore.kernel.org/r/20220908092136.11770-3-jack@suse.cz
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: fix avefreec in find_group_orlov</title>
<updated>2021-07-20T14:15:40+00:00</updated>
<author>
<name>Pan Dong</name>
<email>pandong.peter@bytedance.com</email>
</author>
<published>2021-05-25T07:36:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=fdb1e064f2cc38f99e4ccf6890f03b1ae3c52729'/>
<id>urn:sha1:fdb1e064f2cc38f99e4ccf6890f03b1ae3c52729</id>
<content type='text'>
commit c89849cc0259f3d33624cc3bd127685c3c0fa25d upstream.

The avefreec should be average free clusters instead
of average free blocks, otherwize Orlov's allocator
will not work properly when bigalloc enabled.

Cc: stable@kernel.org
Signed-off-by: Pan Dong &lt;pandong.peter@bytedance.com&gt;
Link: https://lore.kernel.org/r/20210525073656.31594-1-pandong.peter@bytedance.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: fix check to prevent false positive report of incorrect used inodes</title>
<updated>2021-05-22T08:59:21+00:00</updated>
<author>
<name>Zhang Yi</name>
<email>yi.zhang@huawei.com</email>
</author>
<published>2021-03-31T12:15:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=7687f5aba0f50c7ff8040e506bae184e59c8e7b8'/>
<id>urn:sha1:7687f5aba0f50c7ff8040e506bae184e59c8e7b8</id>
<content type='text'>
commit a149d2a5cabbf6507a7832a1c4fd2593c55fd450 upstream.

Commit &lt;50122847007&gt; ("ext4: fix check to prevent initializing reserved
inodes") check the block group zero and prevent initializing reserved
inodes. But in some special cases, the reserved inode may not all belong
to the group zero, it may exist into the second group if we format
filesystem below.

  mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda

So, it will end up triggering a false positive report of a corrupted
file system. This patch fix it by avoid check reserved inodes if no free
inode blocks will be zeroed.

Cc: stable@kernel.org
Fixes: 50122847007 ("ext4: fix check to prevent initializing reserved inodes")
Signed-off-by: Zhang Yi &lt;yi.zhang@huawei.com&gt;
Suggested-by: Jan Kara &lt;jack@suse.cz&gt;
Link: https://lore.kernel.org/r/20210331121516.2243099-1-yi.zhang@huawei.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>ext4: increase wait time needed before reuse of deleted inode numbers</title>
<updated>2020-05-02T15:25:59+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2020-04-14T02:30:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=fffce4a4c4befb2a53fe9bbd5da9addd1efe41a8'/>
<id>urn:sha1:fffce4a4c4befb2a53fe9bbd5da9addd1efe41a8</id>
<content type='text'>
[ Upstream commit a17a9d935dc4a50acefaf319d58030f1da7f115a ]

Current wait times have proven to be too short to protect against inode
reuses that lead to metadata inconsistencies.

Now that we will retry the inode allocation if we can't find any
recently deleted inodes, it's a lot safer to increase the recently
deleted time from 5 seconds to a minute.

Link: https://lore.kernel.org/r/20200414023925.273867-1-tytso@mit.edu
Google-Bug-Id: 36602237
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ext4: fix potential race between s_flex_groups online resizing and access</title>
<updated>2020-02-28T15:38:57+00:00</updated>
<author>
<name>Suraj Jitindar Singh</name>
<email>surajjs@amazon.com</email>
</author>
<published>2020-02-19T03:08:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=50017cec3dbbdfe85bb7bd5a2e3dbcdbc49e6e1a'/>
<id>urn:sha1:50017cec3dbbdfe85bb7bd5a2e3dbcdbc49e6e1a</id>
<content type='text'>
commit 7c990728b99ed6fbe9c75fc202fce1172d9916da upstream.

During an online resize an array of s_flex_groups structures gets replaced
so it can get enlarged. If there is a concurrent access to the array and
this memory has been reused then this can lead to an invalid memory access.

The s_flex_group array has been converted into an array of pointers rather
than an array of structures. This is to ensure that the information
contained in the structures cannot get out of sync during a resize due to
an accessor updating the value in the old structure after it has been
copied but before the array pointer is updated. Since the structures them-
selves are no longer copied but only the pointers to them this case is
mitigated.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=206443
Link: https://lore.kernel.org/r/20200221053458.730016-4-tytso@mit.edu
Signed-off-by: Suraj Jitindar Singh &lt;surajjs@amazon.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: avoid declaring fs inconsistent due to invalid file handles</title>
<updated>2019-01-09T16:38:43+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2018-12-19T17:29:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=263663888d2f00421887e251d93ebc52650a37ab'/>
<id>urn:sha1:263663888d2f00421887e251d93ebc52650a37ab</id>
<content type='text'>
commit 8a363970d1dc38c4ec4ad575c862f776f468d057 upstream.

If we receive a file handle, either from NFS or open_by_handle_at(2),
and it points at an inode which has not been initialized, and the file
system has metadata checksums enabled, we shouldn't try to get the
inode, discover the checksum is invalid, and then declare the file
system as being inconsistent.

This can be reproduced by creating a test file system via "mke2fs -t
ext4 -O metadata_csum /tmp/foo.img 8M", mounting it, cd'ing into that
directory, and then running the following program.

#define _GNU_SOURCE
#include &lt;fcntl.h&gt;

struct handle {
	struct file_handle fh;
	unsigned char fid[MAX_HANDLE_SZ];
};

int main(int argc, char **argv)
{
	struct handle h = {{8, 1 }, { 12, }};

	open_by_handle_at(AT_FDCWD, &amp;h.fh, O_RDONLY);
	return 0;
}

Google-Bug-Id: 120690101
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ext4: use ext4_warning() for sb_getblk failure</title>
<updated>2018-08-01T16:02:31+00:00</updated>
<author>
<name>Wang Shilong</name>
<email>wshilong@ddn.com</email>
</author>
<published>2018-08-01T16:02:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5ef2a69993676a0dfd49bf60ae1323eb8a288366'/>
<id>urn:sha1:5ef2a69993676a0dfd49bf60ae1323eb8a288366</id>
<content type='text'>
Out of memory should not be considered as critical errors; so replace
ext4_error() with ext4_warnig().

Signed-off-by: Wang Shilong &lt;wshilong@ddn.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>ext4: use timespec64 for all inode times</title>
<updated>2018-07-29T19:51:00+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2018-07-29T19:51:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=7b62b293200ffaba5b281668ba7102cb4209774f'/>
<id>urn:sha1:7b62b293200ffaba5b281668ba7102cb4209774f</id>
<content type='text'>
This is the last missing piece for the inode times on 32-bit systems:
now that VFS interfaces use timespec64, we just need to stop truncating
the tv_sec values for y2038 compatibililty.

Reviewed-by: Andreas Dilger &lt;adilger@dilger.ca&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: fix check to prevent initializing reserved inodes</title>
<updated>2018-07-29T19:34:00+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2018-07-28T12:12:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.rulkc.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/?id=5012284700775a4e6e3fbe7eac4c543c4874b559'/>
<id>urn:sha1:5012284700775a4e6e3fbe7eac4c543c4874b559</id>
<content type='text'>
Commit 8844618d8aa7: "ext4: only look at the bg_flags field if it is
valid" will complain if block group zero does not have the
EXT4_BG_INODE_ZEROED flag set.  Unfortunately, this is not correct,
since a freshly created file system has this flag cleared.  It gets
almost immediately after the file system is mounted read-write --- but
the following somewhat unlikely sequence will end up triggering a
false positive report of a corrupted file system:

   mkfs.ext4 /dev/vdc
   mount -o ro /dev/vdc /vdc
   mount -o remount,rw /dev/vdc

Instead, when initializing the inode table for block group zero, test
to make sure that itable_unused count is not too large, since that is
the case that will result in some or all of the reserved inodes
getting cleared.

This fixes the failures reported by Eric Whiteney when running
generic/230 and generic/231 in the the nojournal test case.

Fixes: 8844618d8aa7 ("ext4: only look at the bg_flags field if it is valid")
Reported-by: Eric Whitney &lt;enwlinux@gmail.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
</feed>
