Claude review: libfs: set SB_I_NOEXEC and SB_I_NODEV by default in init_pseudo()

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

**Status: Looks good.**

The change is a single line addition in `fs/libfs.c:739`:

```c
fc->s_iflags |= SB_I_NOEXEC | SB_I_NODEV;
```

placed right after the existing `fc->sb_flags |= SB_NOUSER;`. This is the natural location — these flags are logically coupled with `SB_NOUSER` since pseudo-filesystems are never path-reachable.

**Correctness analysis:**

- **`SB_I_NODEV`** is inert on `SB_NOUSER` mounts since device nodes on unreachable mounts can never be opened via path. Adding it to callers that lacked it (aio, dma-buf, socket, pipe, resource, erofs, btrfs-tests, vfio, drm, dax, bdev) is harmless.

- **`SB_I_NOEXEC`** has one observable effect: `mmap()` with `PROT_EXEC` on a pseudo-fs fd will now return `-EPERM` for callers that didn't previously set this flag. The commit message correctly states no in-tree caller maps these fds executable, which is reasonable — there's no use case for executable mappings of sockets, pipes, dma-bufs, DRM fds, etc.

- The `|=` operator preserves any flags already set by callers before `init_pseudo()`, and callers that set the same flags after `init_pseudo()` are simply redundant (cleaned up in patch 2).

- The `Fixes:` tag, `Cc: stable`, and reproducer instructions are all appropriate.

**One minor note:** The commit message says "No in-tree caller maps these executable." A stronger statement might reference that `PROT_EXEC` on a dma-buf would be nonsensical since the backing pages are GPU memory / DMA coherent allocations. But this is a commit message style preference, not a correctness issue.

---
Generated by Claude Code Patch Reviewer