linux-ext4 - [Bug 219306] ext4_truncate() is being called endlessly, all the time

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <bug-219306-13602-AiaOgRBBQP@https.bugzilla.kernel.org/>
Date: Wed, 25 Sep 2024 00:10:27 +0000
From: bugzilla-daemon@...nel.org
To: linux-ext4@...r.kernel.org
Subject: [Bug 219306] ext4_truncate() is being called endlessly, all the time

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

Theodore Tso (tytso@....edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@....edu

--- Comment #2 from Theodore Tso (tytso@....edu) ---
It/s not true that "nothing is triggering it".   What is triggering it
systemd-journald, which is apparently calling ftruncate(2) on its log file
every single time that writes to the binary log file.  I'm not sure why
journald is calling ftruncate(2) to the size of the file, but this is causing a
call to ext4_setattr(), which is what is calling ext4_truncate.

So when you added the printk in the codepath of ext4_truncate(), this causes a
kernel log to be emitted, which triggered journald, which then would write into
the circular log file /var/log/journal/XXXXXXXXX/system.journal.    Why it is
repeatedly calling ftruncate(2) in what is apparently a no-op, is unclear to
me, but this triggeres another kernel log, which triggers a journald, in an
repeated loop.

So it is was the very act of adding the printk which caused it to be printed
"all the time".    Under normal circumstances, this shouldn't be that much of
an issue.

Now, it is true that we could optimize ftruncate(2) for workloads that are
calling truncate very often.   Calling ext4_truncate() does involve starting a
journal handle, and adding and removing the inode from the orphan list.   We
just didn't think that there would be programs calling ftruncate(2) in a tight
loop with arguments that made it effectively a no-op.    It would be possible
to add a flag to the in-memory inode if it has been truncated, so that we would
know that in the case where the ftruncate(2) is a no-op, we can skip calling
ext4_truncate.  If fallocate is called on the inode with the
FALLOC_FL_KEEP_SIZE, we would clear that in-memroy flag. 

Other ways of address this, if you really want to track how often ext4_truncate
gets called without triggering the journald doom loop would be to use ftrace
and/or tracepoints instead of using printk.    This is much more efficient,
since the log is written into an in-kernel circular buffer, and is then
expanded from binary form into human-readable task without having to invoke
systemd's journald.   

And finally, someone could reach out to the systemd developers and ask why they
are calling ftruncate(2) in many cases where it appears to be completely
unnecessary.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.