According to the man page, truncate should fail and return ETXTBUSY if "The file is a pure procedure (shared text) file that is being executed.". Indeed it does on 13.0-RELEASE, 13.1-RC5, 13.1-STABLE (as of 29-Apr), and 12.3-STABLE (as of 17-Jan). But on 14.0-CURRENT (tested at 90161e72eec and b9e5884ef78) it succeeds. Tested on ZFS, UFS, and fusefs. Steps to reproduce: * sudo pkg install perl5 * git clone https://github.com/pjd/pjdfstest.git * cd /tmp * sudo prove -rv /path/to/pjdfstest/tests/truncate/11.t
I determined that the bug was introduced by revision e511bd1406fa35301e770aad05d1bfdc345c8639, review D33128 . Mateusz, could you please take it from here? Improved steps to reproduce: * sudo pkg install -y autoconf automake perl5 git * git clone https://github.com/pjd/pjdfstest * cd pjdfstest * autoreconf -ifs && ./configure && make * cd .. * prove -rv pjdfstest/tests/truncate/11.t
I'll look into it Monday or Tuesday.
There are 2 unrelated bugs here. 1. #define atomic_load_int(p) (*(volatile u_int *)(p)) as vop_stdis_text now employs it, the negative test always fails. 2. the code doing truncate fails to temporarily bump write count anyway Fixing the latter is sufficient to make the bug go away (and it eliminates the call to vop_stdis_text), the former will require more poking around as fixing the macros may result in significant fallout.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=ec3c225711ae7d5b8e71ed036aada09ef91149ec commit ec3c225711ae7d5b8e71ed036aada09ef91149ec Author: Mateusz Guzik <mjg@FreeBSD.org> AuthorDate: 2022-05-16 01:28:22 +0000 Commit: Mateusz Guzik <mjg@FreeBSD.org> CommitDate: 2022-05-20 17:25:51 +0000 vfs: call vn_truncate_locked from kern_truncate This fixes a bug where the syscall would not bump writecount. PR: 263999 sys/kern/vfs_syscalls.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-)
The bug is still present as of the latest 14.0. Only now instead of succeeding it returns EACCES. It ought to return ETXTBSY.
I'll look into it this week.
I get ETXTBUSY both from open() and truncate() calls, tested ufs and tmpfs.
So do I, now that I try it. So there must be two bugs. You fixed the one that caused truncate to succeed. But there's another bug in ZFS that causes it to return the wrong error code. I still get EACCES for ZFS with today's main build (rfa3eb3c9700).
I see what it is and it is not zfs-specific. If the user does not have write perms to the file the ETXTBUSY check is not even performed. Linux returns ETXTBUSY in this case instead. I'll see about it.
(In reply to Mateusz Guzik from comment #9) > If the user does not have write perms to the file the ETXTBUSY check is not even performed. This seems like the preferable ordering to me, is there a reason the Linux behaviour is desirable?
I don't think the behavior is inherently better, but between being compatible with Linux or not, I think it is better to be.
I think we can close this. The real bug is fixed, and I don't think we need to quibble about whether to return EACCES or ETXTBUSY when both errors apply.