We hit an issue when upgrading Go compiler from 1.13 to 1.15 [1], as we use Go's `io.Copy` to copy the content of `/sys/kernel/debug/tracing/trace` to a temporary file. Under the hood, Go 1.15 uses `copy_file_range` syscall to optimize the copy operation. However, that fails to copy any content when the input file is from tracefs, with an apparent size of 0 (but there is still content when you `cat` it, of course). >From discussions in [2][3], it is clear that copy_file_range cannot be properly implemented on filesystems where the content is generated at runtime: the file size is incorrect (because it is unknown before the content is generated), and seeking in such files (as required by partial writes) is unlikely to work correctly. With this patch, Go's `io.Copy` gracefully falls back to a normal read/write file copy. I'm not 100% sure which stable tree this should go in, I'd say at least >=5.3 since this is what introduced support for cross-filesystem copy_file_range (and where most users are somewhat likely to hit this issue). But let's discuss the patch series first. [1] http://issuetracker.google.com/issues/178332739 [2] https://lkml.org/lkml/2021/1/25/64 [3] https://lkml.org/lkml/2021/1/26/1736 Nicolas Boichat (6): fs: Add flag to file_system_type to indicate content is generated proc: Add FS_GENERATED_CONTENT to filesystem flags sysfs: Add FS_GENERATED_CONTENT to filesystem flags debugfs: Add FS_GENERATED_CONTENT to filesystem flags tracefs: Add FS_GENERATED_CONTENT to filesystem flags vfs: Disallow copy_file_range on generated file systems fs/debugfs/inode.c | 1 + fs/proc/root.c | 2 +- fs/read_write.c | 3 +++ fs/sysfs/mount.c | 2 +- fs/tracefs/inode.c | 1 + include/linux/fs.h | 1 + 6 files changed, 8 insertions(+), 2 deletions(-) -- 2.30.0.478.g8a0d178c01-goog
