linux.git/fs/orangefs, branch v7.2-rc2

orangefs: keep the readdir entry size 64-bit in fill_from_part()

2026-07-01T13:26:27+00:00

fill_from_part() computes the size of a directory entry in size_t but
stores it in a __u32. An entry length near U32_MAX wraps it to a small
value, bypasses the bounds check, and is then used to index the entry,
reading far past the directory part -- an out-of-bounds read that oopses
the kernel.

Compute the size as a u64 so it cannot truncate; the bounds check then
rejects the entry. The trailer is supplied by the userspace client.

Fixes: 480e3e532e31 ("orangefs: support very large directories")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas 
Link: https://patch.msgid.link/20260619-b4-disp-50d2bd59-v1-1-ce332969b4a2@proton.me
Signed-off-by: Christian Brauner (Amutable)

fs: Fix return in jfs_mkdir and orangefs_mkdir

2026-05-11T12:19:01+00:00

Return NULL instead of passing to ERR_PTR while err is zero
Fixes these smatch warnings:
  - fs/jfs/namei.c:311 jfs_mkdir() warn: passing zero to 'ERR_PTR'
  - fs/orangefs/namei.c:369 orangefs_mkdir() warn: passing zero
    to 'ERR_PTR'

Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *")
Signed-off-by: Hongling Zeng 
Link: https://patch.msgid.link/20260501071058.1243245-1-zenghongling@kylinos.cn
Reviewed-by: Jori Koolstra 
Signed-off-by: Christian Brauner

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