linux-toradex.git/fs/9p, branch master Linux kernel for Apalis and Colibri modules Merge tag '9p-for-7.4-rc2' of https://github.com/martinetd/linux 2026-11-03T16:32:35+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-11-03T16:32:35+00:00 7d1471e50943196f909674d2d22eb4196c7df48e Pull late 9p updates from Dominique Martinet: "This is mostly a huge wave of LLM-driven fixes. At least the LLM fixes sort of slowed down recently? Or maybe it's just the time of the cycle and/or I got used to it, time will tell... A few exceptions: - a new vsock transport was added, since it's a variant of the existing fd/tcp transport there is little harm in taking it in - there's an incomplete fix for when file actual size doesn't match the size attribute (e.g. exports of sysfs). The fix addresses when st_size > actual size with cache=none but just about everything else is still broken (st_size=0 with actual data regardless of cache, or with data cache st_size > actual is still wrong and so are symlinks with 0 size)... Maybe at some point I'll find time to understand how netfs works and address these :| - some fixes for the usbg transport by its author, thank you!" * tag '9p-for-7.4-rc2' of https://github.com/martinetd/linux: (39 commits) 9p: optimize p9_fcall struct 9p: reject RERROR/RLERROR with zero errcode 9p: do not store the create fid on special files 9p: fall back to the normal open path for non-regular files 9p: don't decrement a server-owned zero nlink 9p: fix kernel-doc warning for enum p9_session_flags 9p: treat read return values of 0 as EOF 9p/xen: validate the response size from the backend 9p: fix typo in file header comments 9p: remove duplicated assignment in v9fs_fill_super() 9p: fix typos and wrong parameter docs in vfs_inode.c 9p: fix header guard comment in acl.h net/9p/usbg: clear stale client pointer on close net/9p/usbg: remove bogus context initialization in alloc_requests net/9p/usbg: fix out_req buffer leak in disable_usb9pfs net/9p/usbg: call disable_usb9pfs() from usb9pfs_disable() net/9p/usbg: always reset completion when disconnecting net/9p/usbg: set client to Disconnected on usb9pfs_disable net/9p/usbg: also disable endpoints on p9_usbg_close net/9p/usbg: Fix use-after-free in disable_usb9pfs() ... 
Pull late 9p updates from Dominique Martinet:
 "This is mostly a huge wave of LLM-driven fixes. At least the LLM fixes
  sort of slowed down recently? Or maybe it's just the time of the cycle
  and/or I got used to it, time will tell...

  A few exceptions:

   - a new vsock transport was added, since it's a variant of the
     existing fd/tcp transport there is little harm in taking it in

   - there's an incomplete fix for when file actual size doesn't match
     the size attribute (e.g. exports of sysfs).

     The fix addresses when st_size > actual size with cache=none but
     just about everything else is still broken (st_size=0 with actual
     data regardless of cache, or with data cache st_size > actual is
     still wrong and so are symlinks with 0 size)...

     Maybe at some point I'll find time to understand how netfs works
     and address these :|

   - some fixes for the usbg transport by its author, thank you!"

* tag '9p-for-7.4-rc2' of https://github.com/martinetd/linux: (39 commits)
  9p: optimize p9_fcall struct
  9p: reject RERROR/RLERROR with zero errcode
  9p: do not store the create fid on special files
  9p: fall back to the normal open path for non-regular files
  9p: don't decrement a server-owned zero nlink
  9p: fix kernel-doc warning for enum p9_session_flags
  9p: treat read return values of 0 as EOF
  9p/xen: validate the response size from the backend
  9p: fix typo in file header comments
  9p: remove duplicated assignment in v9fs_fill_super()
  9p: fix typos and wrong parameter docs in vfs_inode.c
  9p: fix header guard comment in acl.h
  net/9p/usbg: clear stale client pointer on close
  net/9p/usbg: remove bogus context initialization in alloc_requests
  net/9p/usbg: fix out_req buffer leak in disable_usb9pfs
  net/9p/usbg: call disable_usb9pfs() from usb9pfs_disable()
  net/9p/usbg: always reset completion when disconnecting
  net/9p/usbg: set client to Disconnected on usb9pfs_disable
  net/9p/usbg: also disable endpoints on p9_usbg_close
  net/9p/usbg: Fix use-after-free in disable_usb9pfs()
  ...
9p: do not store the create fid on special files 2026-10-29T06:01:11+00:00 Yuanfu Xie yuanfuxie@stu.pku.edu.cn 2026-09-22T13:16:22+00:00 56894cadf21c34abbba7f74b8f5d78dabf69dd39 v9fs_vfs_atomic_open_dotl() always stores the create fid in file->private_data after finish_open(). FIFO and device inodes already have type-specific file_operations that own that field. Overwriting it with the fid makes later read/write/close treat the p9_fid as a pipe_inode_info, which corrupts the fid and can use it after it has been clunked. The non-dotl atomic_open path does not assign the fid this way. Only attach the fid for regular files and directories. Special files do not need the create fid; leave it for the existing p9_fid_put() on the out path so it is clunked before return. KASAN report, linux-stable 4982d3552a3b: BUG: KASAN: slab-use-after-free in anon_pipe_prefill_and_lock+0x376/0x3f0 Read of size 4 at addr ffff88800ab30538 by task repro/1 Call Trace: <TASK> anon_pipe_prefill_and_lock+0x376/0x3f0 anon_pipe_write+0x127/0x1600 fifo_pipe_write+0x24/0x300 vfs_write+0x659/0xd00 ksys_write+0x10f/0x200 do_syscall_64+0xdd/0x4a0 </TASK> Fixes: 30d904947459 ("kill struct opendata") Signed-off-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn> Message-ID: <92377346-29E9-46D3-96F5-AABA8A64CD57@stu.pku.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
v9fs_vfs_atomic_open_dotl() always stores the create fid in
file->private_data after finish_open().  FIFO and device inodes
already have type-specific file_operations that own that field.
Overwriting it with the fid makes later read/write/close treat the
p9_fid as a pipe_inode_info, which corrupts the fid and can use it
after it has been clunked.  The non-dotl atomic_open path does not
assign the fid this way.

Only attach the fid for regular files and directories.  Special
files do not need the create fid; leave it for the existing
p9_fid_put() on the out path so it is clunked before return.

KASAN report, linux-stable 4982d3552a3b:

BUG: KASAN: slab-use-after-free in anon_pipe_prefill_and_lock+0x376/0x3f0
Read of size 4 at addr ffff88800ab30538 by task repro/1

Call Trace:
 <TASK>
 anon_pipe_prefill_and_lock+0x376/0x3f0
 anon_pipe_write+0x127/0x1600
 fifo_pipe_write+0x24/0x300
 vfs_write+0x659/0xd00
 ksys_write+0x10f/0x200
 do_syscall_64+0xdd/0x4a0
 </TASK>

Fixes: 30d904947459 ("kill struct opendata")
Signed-off-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn>
Message-ID: <92377346-29E9-46D3-96F5-AABA8A64CD57@stu.pku.edu.cn>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: fall back to the normal open path for non-regular files 2026-10-29T06:01:11+00:00 Yuanfu Xie yuanfuxie@stu.pku.edu.cn 2026-09-22T13:15:36+00:00 ff1baa01a6e1f24741f7428119e6f3a61b995604 v9fs_vfs_atomic_open() and v9fs_vfs_atomic_open_dotl() call finish_open(file, dentry, generic_file_open) regardless of the file type the server reported for the created dentry. The supplied callback replaces f_op->open in do_dentry_open(), so blkdev_open() never runs for a server-reported device node: an open() with O_CREAT succeeds with f_op = def_blk_fops while f_mapping still points at the 9p inode, because the bdev mapping swap only happens inside blkdev_open(). The block file methods then derive their block_device from that inode with I_BDEV(); the loads land at the tail of a 656-byte v9fs_inode_cache object (offsets +624 and +632), which KASAN reports as slab-out-of-bounds, and the garbage they read is then dereferenced, so the first read(), write(), ioctl() or close() ends in a NULL pointer write and a panic. In the ioctl(BLKGETSIZE64) variant the value read this way is returned to userspace. The server controls the file type reported for the create, so a malicious server can crash the client this way. KASAN report of the read() variant, on a build of linux-stable 2709dd5ae32f: BUG: KASAN: slab-out-of-bounds in blkdev_read_iter+0x3cd/0x440 Read of size 8 at addr ffff88800828ceb0 by task repro/1 Call Trace: <TASK> dump_stack_lvl+0x7b/0xa0 print_report+0xd0/0x630 kasan_report+0xe5/0x120 blkdev_read_iter+0x3cd/0x440 vfs_read+0x718/0xa50 ksys_read+0x10f/0x200 do_syscall_64+0xdd/0x4a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> The buggy address belongs to the object at ffff88800828cc40 which belongs to the cache v9fs_inode_cache of size 656 The buggy address is located 624 bytes inside of allocated 656-byte region [ffff88800828cc40, ffff88800828ced0) A plain open() without O_CREAT is not affected: it runs blkdev_open() and either maps the device correctly or fails with -ENXIO for an rdev with no registered device. When the created inode is not a regular file, clunk the fid the create opened. The unopened fid is already on the dentry. Set FMODE_CREATED and return finish_no_open(file, NULL) so the VFS keeps its dentry reference and calls the inode's ->open. Regular files still use finish_open() with generic_file_open. Fixes: be12af3ef5e6 ("getting rid of 'opened' argument of ->atomic_open() - part 1") Signed-off-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn> Message-ID: <908FC420-EC1F-46FC-8526-698F646961A8@stu.pku.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
v9fs_vfs_atomic_open() and v9fs_vfs_atomic_open_dotl() call
finish_open(file, dentry, generic_file_open) regardless of the file
type the server reported for the created dentry.  The supplied
callback replaces f_op->open in do_dentry_open(), so blkdev_open()
never runs for a server-reported device node: an open() with O_CREAT
succeeds with f_op = def_blk_fops while f_mapping still points at the
9p inode, because the bdev mapping swap only happens inside
blkdev_open().  The block file methods then derive their block_device
from that inode with I_BDEV(); the loads land at the tail of a
656-byte v9fs_inode_cache object (offsets +624 and +632), which KASAN
reports as slab-out-of-bounds, and the garbage they read is then
dereferenced, so the first read(), write(), ioctl() or close() ends
in a NULL pointer write and a panic.  In the ioctl(BLKGETSIZE64)
variant the value read this way is returned to userspace.

The server controls the file type reported for the create, so a
malicious server can crash the client this way.  KASAN report of the
read() variant, on a build of linux-stable 2709dd5ae32f:

BUG: KASAN: slab-out-of-bounds in blkdev_read_iter+0x3cd/0x440
Read of size 8 at addr ffff88800828ceb0 by task repro/1

Call Trace:
 <TASK>
 dump_stack_lvl+0x7b/0xa0
 print_report+0xd0/0x630
 kasan_report+0xe5/0x120
 blkdev_read_iter+0x3cd/0x440
 vfs_read+0x718/0xa50
 ksys_read+0x10f/0x200
 do_syscall_64+0xdd/0x4a0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 </TASK>

The buggy address belongs to the object at ffff88800828cc40
 which belongs to the cache v9fs_inode_cache of size 656
The buggy address is located 624 bytes inside of
 allocated 656-byte region [ffff88800828cc40, ffff88800828ced0)

A plain open() without O_CREAT is not affected: it runs blkdev_open()
and either maps the device correctly or fails with -ENXIO for an rdev
with no registered device.  When the created inode is not a regular
file, clunk the fid the create opened.  The unopened fid is already
on the dentry.  Set FMODE_CREATED and return finish_no_open(file, NULL)
so the VFS keeps its dentry reference and calls the inode's ->open.
Regular files still use finish_open() with generic_file_open.

Fixes: be12af3ef5e6 ("getting rid of 'opened' argument of ->atomic_open() - part 1")
Signed-off-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn>
Message-ID: <908FC420-EC1F-46FC-8526-698F646961A8@stu.pku.edu.cn>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: don't decrement a server-owned zero nlink 2026-10-29T06:01:11+00:00 Yuanfu Xie yuanfuxie@stu.pku.edu.cn 2026-09-28T07:25:48+00:00 4e915aa8566173b44146bc46177c85afbe6bdf96 A 9P2000.L server can report nlink=0 for a regular file that still exists. On a cache=loose or cache=fscache mount, lookup stores that value with set_nlink(). A later successful unlink calls v9fs_dec_count(), which still calls drop_nlink() for a non-directory. drop_nlink() warns, and the unsigned link count wraps to 4294967295. fstat() on a descriptor opened before the unlink shows 0 before and 4294967295 after. The warning on the unpatched kernel, trimmed: WARNING: fs/inode.c:408 at drop_nlink+0xac/0xd0, CPU#1: trigger/188 CPU: 1 UID: 0 PID: 188 Comm: trigger Tainted: G N 7.3.0-rc4-00537-ga3ff15db6820 #1 PREEMPT(lazy) RIP: 0010:drop_nlink+0xac/0xd0 Call Trace: <TASK> v9fs_remove+0x529/0x750 vfs_unlink+0x2f0/0xbd0 filename_unlinkat+0x340/0x6c0 __x64_sys_unlink+0x46/0x70 do_syscall_64+0xe8/0x4f0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]--- Directories whose cached nlink is at most 2 already skip this decrement, because the exported filesystem may not maintain nlink (commit ac89b2ef9b559). cache=none skips it as well (commit 574aa0b479947). cache=mmap does not take this path: it sets neither CACHE_META nor CACHE_LOOSE. A regular file on cache=loose or cache=fscache still does. Its count came from GETATTR and may already be zero, so skip the decrement when i_nlink is already 0. Verified on 7.3-rc4-00537-ga3ff15db6820 with only this change. A server that advertises nlink=0 and accepts the unlink no longer warns, and the open descriptor stays at nlink 0. An honest server on the same mount still goes from 1 to 0. A rejected unlink leaves the count unchanged. cache=none is unchanged. With panic_on_warn the unpatched kernel panics on the warning; the patched kernel does not. Fixes: ac89b2ef9b559 ("9p: don't maintain dir i_nlink if the exported fs doesn't either") Cc: stable@vger.kernel.org Signed-off-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn> Message-ID: <8B490036-EBB0-4A36-AE39-F294F7C79649@stu.pku.edu.cn> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
A 9P2000.L server can report nlink=0 for a regular file that still
exists.  On a cache=loose or cache=fscache mount, lookup stores that
value with set_nlink().  A later successful unlink calls
v9fs_dec_count(), which still calls drop_nlink() for a non-directory.
drop_nlink() warns, and the unsigned link count wraps to 4294967295.
fstat() on a descriptor opened before the unlink shows 0 before and
4294967295 after.

The warning on the unpatched kernel, trimmed:

WARNING: fs/inode.c:408 at drop_nlink+0xac/0xd0, CPU#1: trigger/188
CPU: 1 UID: 0 PID: 188 Comm: trigger Tainted: G                 N  7.3.0-rc4-00537-ga3ff15db6820 #1 PREEMPT(lazy)
RIP: 0010:drop_nlink+0xac/0xd0
Call Trace:
 <TASK>
 v9fs_remove+0x529/0x750
 vfs_unlink+0x2f0/0xbd0
 filename_unlinkat+0x340/0x6c0
 __x64_sys_unlink+0x46/0x70
 do_syscall_64+0xe8/0x4f0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
 </TASK>
---[ end trace 0000000000000000 ]---

Directories whose cached nlink is at most 2 already skip this
decrement, because the exported filesystem may not maintain nlink
(commit ac89b2ef9b559).  cache=none skips it as well (commit
574aa0b479947).  cache=mmap does not take this path: it sets neither
CACHE_META nor CACHE_LOOSE.  A regular file on cache=loose or
cache=fscache still does.  Its count came from GETATTR and may
already be zero, so skip the decrement when i_nlink is already 0.

Verified on 7.3-rc4-00537-ga3ff15db6820 with only this change.  A
server that advertises nlink=0 and accepts the unlink no longer
warns, and the open descriptor stays at nlink 0.  An honest server
on the same mount still goes from 1 to 0.  A rejected unlink leaves
the count unchanged.  cache=none is unchanged.  With panic_on_warn
the unpatched kernel panics on the warning; the patched kernel does
not.

Fixes: ac89b2ef9b559 ("9p: don't maintain dir i_nlink if the exported fs doesn't either")
Cc: stable@vger.kernel.org
Signed-off-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn>
Message-ID: <8B490036-EBB0-4A36-AE39-F294F7C79649@stu.pku.edu.cn>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: fix kernel-doc warning for enum p9_session_flags 2026-10-29T06:01:10+00:00 Omokefe Emmanuel Onanaroghene emmaonana18@gmail.com 2026-10-02T03:58:37+00:00 d037e9c1b40c28eb57ea10947141cad3781b91a7 kernel-doc cannot parse enum p9_session_flags, since its documentation comment is followed by #define lines instead of the enum declaration: fs/9p/v9fs.h:31 : error: Cannot parse enum! Move the three #define lines below the enum whose values they are derived from, and give V9FS_ACCESS_ANY and V9FS_ACCESS_MASK their own kernel-doc comments with the descriptions they had in the enum comment. Also document the four enum members that had no description, using the corresponding mount option wording from Documentation/filesystems/9p.rst. Fixes: 76381a42e4a5 ("fs/9p: Add access = client option to opt in acl evaluation.") Assisted-by: LLM Signed-off-by: Omokefe Emmanuel Onanaroghene <emmaonana18@gmail.com> Message-ID: <20261002035837.39703-1-emmaonana18@gmail.com> [Dominique: slight reword, also fixed typo in Doc/ for access=client] Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
kernel-doc cannot parse enum p9_session_flags, since its documentation
comment is followed by #define lines instead of the enum declaration:

  fs/9p/v9fs.h:31 : error: Cannot parse enum!

Move the three #define lines below the enum whose values they are
derived from, and give V9FS_ACCESS_ANY and V9FS_ACCESS_MASK their own
kernel-doc comments with the descriptions they had in the enum comment.

Also document the four enum members that had no description, using the
corresponding mount option wording from
Documentation/filesystems/9p.rst.

Fixes: 76381a42e4a5 ("fs/9p: Add access = client option to opt in acl evaluation.")
Assisted-by: LLM
Signed-off-by: Omokefe Emmanuel Onanaroghene <emmaonana18@gmail.com>
Message-ID: <20261002035837.39703-1-emmaonana18@gmail.com>
[Dominique: slight reword, also fixed typo in Doc/ for access=client]
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: treat read return values of 0 as EOF 2026-10-29T06:01:10+00:00 Barret Rhoden brho@google.com 2026-07-02T09:09:32+00:00 a3a6212c7d67baebebd0e4c2cf2ae1b75eb9231e If your 9p server shares a synthetic file system such as sysfs, the file size from stat often disagrees with the actual file size. Treat non-error reads of 0 as EOF, except in the case where the request was for 0 bytes. Tested: git@github.com:hugelgupf/p9.git, served "/" on 10.0.2.2 bash-5.3# mount -t 9p -o trans=tcp,port=12345,cache=none 10.0.2.2 /tmp/foo bash-5.3# cat /tmp/foo/sys/devices/system/cpu/online 0-47 Fixes: eb497943fa21 ("9p: Convert to using the netfs helper lib to do reads and caching") Signed-off-by: Barret Rhoden <brho@google.com> Message-ID: <20260702090941.1298188-1-brho@google.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
If your 9p server shares a synthetic file system such as sysfs, the file
size from stat often disagrees with the actual file size.

Treat non-error reads of 0 as EOF, except in the case where the request
was for 0 bytes.

Tested:
	git@github.com:hugelgupf/p9.git, served "/" on 10.0.2.2

	bash-5.3# mount -t 9p -o trans=tcp,port=12345,cache=none 10.0.2.2 /tmp/foo
	bash-5.3# cat /tmp/foo/sys/devices/system/cpu/online
	0-47

Fixes: eb497943fa21 ("9p: Convert to using the netfs helper lib to do reads and caching")
Signed-off-by: Barret Rhoden <brho@google.com>
Message-ID: <20260702090941.1298188-1-brho@google.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: fix typo in file header comments 2026-10-29T06:01:09+00:00 Ankit Thakur codeankit.thakur@gmail.com 2026-10-24T09:21:54+00:00 8a152d6a389a8375e272e4eb0f3447dce742bc20 Fix the spelling mistake contians -> contains in the header comments of vfs_addr.c, vfs_dentry.c and vfs_file.c. Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com> Message-ID: <20261024092154.1844-4-codeankit.thakur@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Fix the spelling mistake contians -> contains in the header comments
of vfs_addr.c, vfs_dentry.c and vfs_file.c.

Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com>
Message-ID: <20261024092154.1844-4-codeankit.thakur@gmail.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: remove duplicated assignment in v9fs_fill_super() 2026-10-29T06:01:09+00:00 Ankit Thakur codeankit.thakur@gmail.com 2026-10-24T09:21:53+00:00 9eb9b583ea3513473c7a366dc1f17075069bb41f The declaration of v9ses assigns it twice (v9ses = v9ses = sb->s_fs_info). Drop the redundant assignment. No functional change. Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com> Message-ID: <20261024092154.1844-3-codeankit.thakur@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
The declaration of v9ses assigns it twice (v9ses = v9ses =
sb->s_fs_info). Drop the redundant assignment. No functional change.

Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com>
Message-ID: <20261024092154.1844-3-codeankit.thakur@gmail.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: fix typos and wrong parameter docs in vfs_inode.c 2026-10-29T06:01:09+00:00 Ankit Thakur codeankit.thakur@gmail.com 2026-10-24T09:21:52+00:00 6b18056882abf93ae3a78f67901695998efd8cee Fix spelling mistakes in comments (functon -> function, Hadlink -> Hardlink). Also fix the kernel-doc of v9fs_vfs_mkdir(), which described @dir and @dentry as being unlinked instead of being the parent directory and the directory being created. Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com> Message-ID: <20261024092154.1844-2-codeankit.thakur@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
Fix spelling mistakes in comments (functon -> function, Hadlink ->
Hardlink).

Also fix the kernel-doc of v9fs_vfs_mkdir(), which described @dir and
@dentry as being unlinked instead of being the parent directory and the
directory being created.

Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com>
Message-ID: <20261024092154.1844-2-codeankit.thakur@gmail.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
9p: fix header guard comment in acl.h 2026-10-29T06:01:08+00:00 Ankit Thakur codeankit.thakur@gmail.com 2026-10-24T09:21:51+00:00 ec8cd74fcf73329ffe3b40e7a3c1afd50e6dc930 The closing comment of the include guard says FS_9P_XATTR_H, but the guard macro is FS_9P_ACL_H. Fix the comment to match. Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com> Message-ID: <20261024092154.1844-1-codeankit.thakur@gmail.com> Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> 
The closing comment of the include guard says FS_9P_XATTR_H, but the
guard macro is FS_9P_ACL_H. Fix the comment to match.

Signed-off-by: Ankit Thakur <codeankit.thakur@gmail.com>
Message-ID: <20261024092154.1844-1-codeankit.thakur@gmail.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>