On 4/30/25 07:28, Mike Marshall wrote:
> I ran through xfstests at 6.14-rc7, and then not again until 6.15-rc4.
>
> Starting with 6.14 xfstests generic/010 hits "WARN_ON(wr->pos >= len);" in
> orangefs_writepage_locked. I bisected:
Any chance you could share the entire warning splat?
I suspect what's happening here is that the orangefs code had an
existing bug when it faults during a write and the write partially
completes. My _guess_ is that the code effectively incremented wr->pos
too far which took it past i_size.
Before my patch, the writes fully complete. After my patch, the writes
partially complete.
Ext4 had a similar bug that caused this to get reverted the first time:
> 00a3d660cbac ("Revert "fs: do not prefault sys_write() user buffer pages"")
I would have felt pretty bad adding a hack to ext4 to work around this
bug. I don't feel as bad doing it to orangefs. Does that make me a
horrible person? :)
Anyway, does the (entirely untested) attached patch hack around the
issue for you? It just adds the old prefault behavior back to orangefs.
BTW, I suspect you could reproduce this splat _without_ 665575cf by
finding a way to undo the iov_iter_fault_in_readable() before
iov_iter_copy_from_user_atomic(). Maybe by having another thread sit
there and pound on the source memory buffer with MADV_DONTNEED or something.
BTW, the orangefs Documentation/ is looking a little crusty. Both of
these 404 on me:
https://lists.orangefs.org/pipermail/devel_lists.orangefs.org/
https://docs.orangefs.com/home/index.htm
---
b/fs/orangefs/file.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff -puN fs/orangefs/file.c~orangefs-hack fs/orangefs/file.c
--- a/fs/orangefs/file.c~orangefs-hack 2025-04-30 08:30:36.992142576 -0700
+++ b/fs/orangefs/file.c 2025-04-30 08:34:43.002231158 -0700
@@ -360,6 +360,7 @@ out:
static ssize_t orangefs_file_write_iter(struct kiocb *iocb,
struct iov_iter *iter)
{
+ size_t bytes;
int ret;
orangefs_stats.writes++;
@@ -369,6 +370,17 @@ static ssize_t orangefs_file_write_iter(
return ret;
}
+ /*
+ * This is a hack. There's (probably) an orangefs bug out
+ * there that does not properly handle faults that happen in
+ * the middle of a write. Avoid the bug by prefaulting. It
+ * is possible but unlikely that this fault will be undone
+ * by reclaim by the time the buggy code is run.
+ */
+ bytes = iov_iter_count(iter);
+ if (fault_in_iov_iter_readable(iter, bytes) == bytes)
+ return -EFAULT;
+
ret = generic_file_write_iter(iocb, iter);
return ret;
}
_
