<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/fs/ext4/super.c, branch linux-6.15.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.15.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2025-04-05T08:30:12Z</updated>
<entry>
<title>treewide: Switch/rename to timer_delete[_sync]()</title>
<updated>2025-04-05T08:30:12Z</updated>
<author>
<name>Thomas Gleixner</name>
</author>
<published>2025-04-05T08:17:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8fa7292fee5c5240402371ea89ab285ec856c916'/>
<id>urn:sha1:8fa7292fee5c5240402371ea89ab285ec856c916</id>
<content type='text'>
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.

Conversion was done with coccinelle plus manual fixups where necessary.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
</entry>
<entry>
<title>ext4: on a remount, only log the ro or r/w state when it has changed</title>
<updated>2025-03-21T05:33:11Z</updated>
<author>
<name>Nicolas Bretz</name>
</author>
<published>2025-03-19T17:10:11Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d7b0befd09320e3356a75cb96541c030515e7f5f'/>
<id>urn:sha1:d7b0befd09320e3356a75cb96541c030515e7f5f</id>
<content type='text'>
A user complained that a message such as:

EXT4-fs (nvme0n1p3): re-mounted UUID ro. Quota mode: none.

implied that the file system was previously mounted read/write and was
now remounted read-only, when it could have been some other mount
state that had changed by the "mount -o remount" operation.  Fix this
by only logging "ro"or "r/w" when it has changed.

https://bugzilla.kernel.org/show_bug.cgi?id=219132

Signed-off-by: Nicolas Bretz &lt;bretznic@gmail.com&gt;
Link: https://patch.msgid.link/20250319171011.8372-1-bretznic@gmail.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: Make sb update interval tunable</title>
<updated>2025-03-21T05:12:33Z</updated>
<author>
<name>Ojaswin Mujoo</name>
</author>
<published>2025-03-18T07:52:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=896b02d0b9e7deb4a4eb365e13dd912b49916519'/>
<id>urn:sha1:896b02d0b9e7deb4a4eb365e13dd912b49916519</id>
<content type='text'>
Currently, outside error paths, we auto commit the super block after 1
hour has passed and 16MB worth of updates have been written since last
commit. This is a policy decision so make this tunable while keeping the
defaults same. This is useful if user wants to tweak the superblock
behavior or for debugging the codepath by allowing to trigger it more
frequently.

We can now tweak the super block update using sb_update_sec and
sb_update_kb files in /sys/fs/ext4/&lt;dev&gt;/

Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Ritesh Harjani (IBM) &lt;ritesh.list@gmail.com&gt;
Reviewed-by: Baokun Li &lt;libaokun1@huawei.com&gt;
Signed-off-by: Ojaswin Mujoo &lt;ojaswin@linux.ibm.com&gt;
Link: https://patch.msgid.link/950fb8c9b2905620e16f02a3b9eeea5a5b6cb87e.1742279837.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: avoid journaling sb update on error if journal is destroying</title>
<updated>2025-03-21T05:12:33Z</updated>
<author>
<name>Ojaswin Mujoo</name>
</author>
<published>2025-03-18T07:52:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ce2f26e73783b4a7c46a86e3af5b5c8de0971790'/>
<id>urn:sha1:ce2f26e73783b4a7c46a86e3af5b5c8de0971790</id>
<content type='text'>
Presently we always BUG_ON if trying to start a transaction on a journal marked
with JBD2_UNMOUNT, since this should never happen. However, while ltp running
stress tests, it was observed that in case of some error handling paths, it is
possible for update_super_work to start a transaction after the journal is
destroyed eg:

(umount)
ext4_kill_sb
  kill_block_super
    generic_shutdown_super
      sync_filesystem /* commits all txns */
      evict_inodes
        /* might start a new txn */
      ext4_put_super
	flush_work(&amp;sbi-&gt;s_sb_upd_work) /* flush the workqueue */
        jbd2_journal_destroy
          journal_kill_thread
            journal-&gt;j_flags |= JBD2_UNMOUNT;
          jbd2_journal_commit_transaction
            jbd2_journal_get_descriptor_buffer
              jbd2_journal_bmap
                ext4_journal_bmap
                  ext4_map_blocks
                    ...
                    ext4_inode_error
                      ext4_handle_error
                        schedule_work(&amp;sbi-&gt;s_sb_upd_work)

                                               /* work queue kicks in */
                                               update_super_work
                                                 jbd2_journal_start
                                                   start_this_handle
                                                     BUG_ON(journal-&gt;j_flags &amp;
                                                            JBD2_UNMOUNT)

Hence, introduce a new mount flag to indicate journal is destroying and only do
a journaled (and deferred) update of sb if this flag is not set. Otherwise, just
fallback to an un-journaled commit.

Further, in the journal destroy path, we have the following sequence:

  1. Set mount flag indicating journal is destroying
  2. force a commit and wait for it
  3. flush pending sb updates

This sequence is important as it ensures that, after this point, there is no sb
update that might be journaled so it is safe to update the sb outside the
journal. (To avoid race discussed in 2d01ddc86606)

Also, we don't need a similar check in ext4_grp_locked_error since it is only
called from mballoc and AFAICT it would be always valid to schedule work here.

Fixes: 2d01ddc86606 ("ext4: save error info to sb through journal if available")
Reported-by: Mahesh Kumar &lt;maheshkumar657g@gmail.com&gt;
Signed-off-by: Ojaswin Mujoo &lt;ojaswin@linux.ibm.com&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Link: https://patch.msgid.link/9613c465d6ff00cd315602f99283d5f24018c3f7.1742279837.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: define ext4_journal_destroy wrapper</title>
<updated>2025-03-21T05:12:33Z</updated>
<author>
<name>Ojaswin Mujoo</name>
</author>
<published>2025-03-18T07:52:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5a02a6204ca37e7c22fbb55a789c503f05e8e89a'/>
<id>urn:sha1:5a02a6204ca37e7c22fbb55a789c503f05e8e89a</id>
<content type='text'>
Define an ext4 wrapper over jbd2_journal_destroy to make sure we
have consistent behavior during journal destruction. This will also
come useful in the next patch where we add some ext4 specific logic
in the destroy path.

Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Baokun Li &lt;libaokun1@huawei.com&gt;
Signed-off-by: Ojaswin Mujoo &lt;ojaswin@linux.ibm.com&gt;
Link: https://patch.msgid.link/c3ba78c5c419757e6d5f2d8ebb4a8ce9d21da86a.1742279837.git.ojaswin@linux.ibm.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: don't over-report free space or inodes in statvfs</title>
<updated>2025-03-20T19:31:19Z</updated>
<author>
<name>Theodore Ts'o</name>
</author>
<published>2025-03-14T04:38:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f87d3af7419307ae26e705a2b2db36140db367a2'/>
<id>urn:sha1:f87d3af7419307ae26e705a2b2db36140db367a2</id>
<content type='text'>
This fixes an analogus bug that was fixed in xfs in commit
4b8d867ca6e2 ("xfs: don't over-report free space or inodes in
statvfs") where statfs can report misleading / incorrect information
where project quota is enabled, and the free space is less than the
remaining quota.

This commit will resolve a test failure in generic/762 which tests for
this bug.

Cc: stable@kernel.org
Fixes: 689c958cbe6b ("ext4: add project quota support")
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: "Darrick J. Wong" &lt;djwong@kernel.org&gt;
</content>
</entry>
<entry>
<title>ext4: clear DISCARD flag if device does not support discard</title>
<updated>2025-03-18T04:15:25Z</updated>
<author>
<name>Diangang Li</name>
</author>
<published>2025-03-11T02:13:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5f1cf94d80208f5baa203f10fa762d3f0b567ad8'/>
<id>urn:sha1:5f1cf94d80208f5baa203f10fa762d3f0b567ad8</id>
<content type='text'>
commit 79add3a3f795e ("ext4: notify when discard is not supported")
noted that keeping the DISCARD flag is for possibility that the underlying
device might change in future even without file system remount. However,
this scenario has rarely occurred in practice on the device side. Even if
it does occur, it can be resolved with remount. Clearing the DISCARD flag
not only prevents confusion caused by mount options but also avoids
sending unnecessary discard commands.

Signed-off-by: Diangang Li &lt;lidiangang@bytedance.com&gt;
Link: https://patch.msgid.link/20250311021310.669524-1-lidiangang@bytedance.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: remove references to bh-&gt;b_page</title>
<updated>2025-03-18T04:15:25Z</updated>
<author>
<name>Matthew Wilcox (Oracle)</name>
</author>
<published>2025-02-13T18:23:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=08be56fec0588972f6fd4a3ce4ced3265de43dd8'/>
<id>urn:sha1:08be56fec0588972f6fd4a3ce4ced3265de43dd8</id>
<content type='text'>
Buffer heads are attached to folios, not to pages.  Also
flush_dcache_page() is now deprecated in favour of flush_dcache_folio().

Signed-off-by: Matthew Wilcox (Oracle) &lt;willy@infradead.org&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Link: https://patch.msgid.link/20250213182303.2133205-1-willy@infradead.org
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: remove redundant function ext4_has_metadata_csum</title>
<updated>2025-03-17T15:19:41Z</updated>
<author>
<name>Eric Biggers</name>
</author>
<published>2025-02-07T03:13:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e224fa3b8a0351834fe310ccac61a5aab941ee22'/>
<id>urn:sha1:e224fa3b8a0351834fe310ccac61a5aab941ee22</id>
<content type='text'>
Since commit f2b4fa19647e ("ext4: switch to using the crc32c library"),
ext4_has_metadata_csum() is just an alias for
ext4_has_feature_metadata_csum().  ext4_has_feature_metadata_csum() is
generated by EXT4_FEATURE_RO_COMPAT_FUNCS and uses the regular naming
convention for checking a single ext4 feature.  Therefore, remove
ext4_has_metadata_csum() and update all its callers to use
ext4_has_feature_metadata_csum() directly.

Signed-off-by: Eric Biggers &lt;ebiggers@google.com&gt;
Reviewed-by: Darrick J. Wong &lt;djwong@kernel.org&gt;
Link: https://patch.msgid.link/20250207031335.42637-1-ebiggers@kernel.org
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
<entry>
<title>ext4: show 'shutdown' hint when ext4 is forced to shutdown</title>
<updated>2025-03-13T14:16:35Z</updated>
<author>
<name>Baokun Li</name>
</author>
<published>2025-01-22T11:41:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5855c3519463e9ac4d10424bb49953047a04c602'/>
<id>urn:sha1:5855c3519463e9ac4d10424bb49953047a04c602</id>
<content type='text'>
Now, if dmesg is cleared, we have no way of knowing if the file system has
been shutdown. Moreover, ext4 allows directory reads even after the file
system has been shutdown, so when reading a file returns -EIO, we cannot
determine whether this is a hardware issue or if the file system has been
shutdown.

Therefore, when ext4 file system is shutdown, we're adding a 'shutdown'
hint to commands like mount so users can easily check the file system's
status.

Signed-off-by: Baokun Li &lt;libaokun1@huawei.com&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Zhang Yi &lt;yi.zhang@huawei.com&gt;
Link: https://patch.msgid.link/20250122114130.229709-8-libaokun@huaweicloud.com
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
</entry>
</feed>
