kernel/linux.git/fs/orangefs, branch master

Merge tag 'for-linus-7.1-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux

2026-04-18T00:03:43+00:00

Pull orangefs updates from Mike Marshall: "Fixes: - validate getxattr response length - don't overflow the bufmap slot on readahead - fix parsing problem with kernel debug keywords Cleanup: - take better advantage of strscpy New: - manage bufmap as folios - add usercopy whitelist to orangefs_op_cache" * tag 'for-linus-7.1-ofs1' of git://git.kernel.org/pub/scm/linux/kernel/git/hubcap/linux: bufmap: manage as folios, V2. orangefs: validate getxattr response length orangefs_readahead: don't overflow the bufmap slot. debugfs: take better advantage of strscpy. orangefs: add usercopy whitelist to orangefs_op_cache orangefs-debugfs.c: fix parsing problem with kernel debug keywords.

bufmap: manage as folios, V2.

2026-04-13T16:14:17+00:00

Thanks for the feedback from Dan Carpenter and Arnd Bergmann. Dan suggested to make the rollback loop in orangefs_bufmap_map more robust. Arnd caught a %ld format for a size_t in orangefs_bufmap_copy_to_iovec. He suggested %zd, I used %zu which I think is OK too. Orangefs userspace allocates 40 megabytes on an address that's page aligned. With this folio modification the allocation is aligned on a multiple of 2 megabytes: posix_memalign(&ptr, 2097152, 41943040); Then userspace tries to enable Huge Pages for the range: madvise(ptr, 41943040, MADV_HUGEPAGE); Userspace provides the address of the 40 megabyte allocation to the Orangefs kernel module with an ioctl. The kernel module initializes the memory as a "bufmap" with ten 4 megabyte "slots". Traditionally, the slots are manipulated a page at a time. This folio/bufmap modification manages the slots as folios, with two 2 megabyte folios per slot and data can be read into and out of each slot a folio at a time. This modification works fine with orangefs userspace lacking the THP focused posix_memalign and madvise settings listed above, each slot can end up being made of page sized folios. It also works if there are some, but less than 20, hugepages available. A message is printed in the kernel ring buffer (dmesg) at userspace start time that describes the folio/page ratio. As an example, I started orangefs and saw "Grouped 2575 folios from 10240 pages" in the ring buffer. To get the optimum ratio, 20/10240, I use these settings before I start the orangefs userspace: echo always > /sys/kernel/mm/transparent_hugepage/enabled echo always > /sys/kernel/mm/transparent_hugepage/defrag echo 30 > /proc/sys/vm/nr_hugepages https://docs.kernel.org/admin-guide/mm/hugetlbpage.html discusses hugepages and manipulating the /proc/sys/vm settings. Comparing the performance between the page/bufmap and the folio/bufmap is a mixed bag. - The folio/bufmap version is about 8% faster at running through the xfstest suite on my VMs. - It is easy to construct an fio test that brings the page/bufmap version to its knees on my dinky VM test system, with all bufmap slots used and I/O timeouts cascading. - Some smaller tests I did with fio that didn't overwhelm the page/bufmap version showed no performance gain with the folio/bufmap version on my VM. I suspect this change will improve performance only in some use-cases. I think it will be a gain when there are many concurrent IOs that mostly fill the bufmap. I'm working up a gcloud test for that. Reported-by: Dan Carpenter Reported-by: Arnd Bergmann Signed-off-by: Mike Marshall

orangefs: validate getxattr response length

2026-04-07T15:28:19+00:00

orangefs_inode_getxattr() trusts the userspace-client-controlled downcall.resp.getxattr.val_sz and uses it as a memcpy() length both for the temporary user buffer and the cached xattr buffer. Reject malformed negative or oversized lengths before copying response bytes. Reported-by: Hyungjung Joo Signed-off-by: HyungJung Joo Signed-off-by: Mike Marshall

orangefs_readahead: don't overflow the bufmap slot.

2026-04-07T15:26:48+00:00

generic/340 showed that this caller of wait_for_direct_io was sometimes asking for more than a bufmap slot could hold. This splits the calls up if needed. Signed-off-by: Mike Marshall

debugfs: take better advantage of strscpy.

2026-04-07T15:25:54+00:00

Signed-off-by: Mike Marshall

orangefs: add usercopy whitelist to orangefs_op_cache

2026-04-07T15:22:18+00:00

orangefs_op_cache is created with kmem_cache_create(), which provides no usercopy whitelist. orangefs_devreq_read() copies the tag and upcall fields directly from slab objects to userspace via copy_to_user(). With CONFIG_HARDENED_USERCOPY enabled, this triggers usercopy_abort(). Switch to kmem_cache_create_usercopy() with a whitelist covering the tag and upcall fields, matching the pattern already used by orangefs_inode_cache in super.c. Signed-off-by: Ziyi Guo Signed-off-by: Mike Marshall

orangefs-debugfs.c: fix parsing problem with kernel debug keywords.

2026-04-07T15:21:32+00:00

When /sys/kernel/debug/orangefs/kernel-debug was set to a single keyword, the keyword was ignored. Now single and multiple keyword settings produce the expected debug output to the ring buffer. Signed-off-by: Mike Marshall

treewide: change inode->i_ino from unsigned long to u64

2026-03-06T13:31:28+00:00

On 32-bit architectures, unsigned long is only 32 bits wide, which causes 64-bit inode numbers to be silently truncated. Several filesystems (NFS, XFS, BTRFS, etc.) can generate inode numbers that exceed 32 bits, and this truncation can lead to inode number collisions and other subtle bugs on 32-bit systems. Change the type of inode->i_ino from unsigned long to u64 to ensure that inode numbers are always represented as 64-bit values regardless of architecture. Update all format specifiers treewide from %lu/%lx to %llu/%llx to match the new type, along with corresponding local variable types. This is the bulk treewide conversion. Earlier patches in this series handled trace events separately to allow trace field reordering for better struct packing on 32-bit. Signed-off-by: Jeff Layton Link: https://patch.msgid.link/20260304-iino-u64-v3-12-2257ad83d372@kernel.org Acked-by: Damien Le Moal Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Chuck Lever Signed-off-by: Christian Brauner

Convert more 'alloc_obj' cases to default GFP_KERNEL arguments

2026-02-22T04:03:00+00:00

This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\