[DeathCamel58]

Problem

OpenIPC's /init keeps settings in rootfs_data through an overlay over the squashfs root. It skips the overlay when /proc/filesystems has none. This 3.10 kernel predates mainline overlayfs and has no other, so a flashed S3L image boots with a read-only root:

• nothing persists;
• /etc/fw_env.config can't be written, so fw_printenv/fw_setenv fail ("environment not initialized");
• the first-boot setup can't save the root password, so the console never gets past it.

Change

Miklos Szeredi's out-of-tree overlayfs v18 (fs/overlayfs plus its VFS hooks in namei.c, namespace.c, open.c, splice.c, fs.h, mount.h). It's the same patch this repo carries on the 3.10.14 ingenic-t31 kernel (0001-overlayfs.v18.patch, e7666aa), and it applies here with line offsets only. It registers overlayfs, which /init mounts with lowerdir=/,upperdir=/overlay. Boards turn it on with CONFIG_OVERLAYFS_FS=y; it's off by default.

The prebuilt S3L modules (iav.ko & co.) are unaffected: struct inode and struct file keep their layout (inode.i_cdev 0x110, file.private_data 0x70, as iav.ko expects). super_block and inode_operations only grow at their ends.

Testing

On an Amcrest IP4M-1026E (S3L, OV4689), flashed and booted from SPI-NOR with CONFIG_OVERLAYFS_FS=y:

• rootfs_data mounts as jffs2, with overlayfs over /;
• fw_printenv works, and the root password and a test file in /etc survive reboots;
• the prebuilt IAV stack loads and streams.

This was repeated across two stock ↔ OpenIPC flash round trips. On this branch alone, the kernel also builds with s3l.generic.config plus CONFIG_OVERLAYFS_FS=y, using the S3L hard-float toolchain. The inode/file offsets above were measured on that build with a throwaway module.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

ambarella: s3l: backport overlayfs v18 for persistent root settings

🐞 Bug fix ✨ Enhancement 🕐 40+ Minutes

AI Description

• Backport overlayfs v18 so S3L can persist settings over its read-only squashfs root.
• Add the VFS hooks and stacking limits needed by the backport.
• Make overlayfs optional through CONFIG_OVERLAYFS_FS and document its behavior.

Diagram

graph TD
  Init["Boot init"] --> Mount["Overlayfs mount"] --> Root["Merged root"] --> VFS["VFS operations"] --> Copy["Copy up"] --> Upper[("JFFS2 upper")]
  Lower[("SquashFS lower")] --> Root
  Upper --> Root

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Backport a newer mainline overlayfs

• ➕ Starts from a newer upstream implementation.
• ➖ Requires a substantially larger adaptation to the 3.10 VFS.
• ➖ Increases compatibility risk for the prebuilt S3L modules.

2. Implement persistence in userspace

• ➕ Avoids adding kernel filesystem and VFS code.
• ➖ Does not readily provide transparent copy-on-write behavior for the whole root.
• ➖ Would require broader boot and application changes.

Recommendation: Reuse the existing v18 backport: it already targets a 3.10 kernel in this repository and supplies the transparent root overlay expected by init. The newer-kernel and userspace alternatives have substantially greater integration costs for this device.

Files changed (22) +3002 / -16

Enhancement (13) +2768 / -5

main.cLimit eCryptfs stacking depth +7/-0

Limit eCryptfs stacking depth

• Tracks eCryptfs depth relative to its lower filesystem and rejects mounts that exceed the shared stacking limit.

fs/ecryptfs/main.c

namei.cRoute pathname opens through vfs_open +7/-3

Route pathname opens through vfs_open

• Exports __inode_permission for stacking filesystems and changes the non-atomic open path to invoke vfs_open, allowing an inode to redirect opening to an underlying file.

fs/namei.c

namespace.cProvide private mount cloning +27/-0

Provide private mount cloning

• Adds an exported helper that clones a path's mount without attaching it to the namespace or propagating mount changes.

fs/namespace.c

open.cIntroduce the redirectable VFS open path +21/-2

Introduce the redirectable VFS open path

• Adds vfs_open to dispatch to an inode's dentry_open hook when present, otherwise retaining the ordinary open path. dentry_open now uses that dispatch as well.

fs/open.c

copy_up.cCopy lower-layer objects into the upper layer +387/-0

Copy lower-layer objects into the upper layer

• Implements copy-up of parent directories, file data, symlinks, metadata, and extended attributes. Includes a truncated-copy path for size changes.

fs/overlayfs/copy_up.c

dir.cImplement overlay directory mutations +605/-0

Implement overlay directory mutations

• Handles creation, removal, linking, and renaming against the upper layer. Uses whiteouts and opaque-directory attributes to hide lower-layer entries.

fs/overlayfs/dir.c

inode.cImplement overlay inode operations +372/-0

Implement overlay inode operations

• Provides permission, attribute, extended-attribute, and symlink handling. Its dentry-open hook copies up files when needed and opens the selected underlying file.

fs/overlayfs/inode.c

overlayfs.hDefine shared overlayfs interfaces +70/-0

Define shared overlayfs interfaces

• Declares layer types and the helpers shared by overlay lookup, inode operations, directory handling, and copy-up.

fs/overlayfs/overlayfs.h

readdir.cMerge upper and lower directory listings +566/-0

Merge upper and lower directory listings

• Implements per-open directory caching, upper/lower entry merging, and whiteout filtering. Also checks directory emptiness before removal.

fs/overlayfs/readdir.c

super.cMount and register overlayfs +685/-0

Mount and register overlayfs

• Parses layer paths, validates stacking depth, clones private mounts, and constructs the merged root. Provides lookup, mount lifecycle, filesystem statistics, and overlayfs registration.

fs/overlayfs/super.c

splice.cExport direct splice for copy-up +1/-0

Export direct splice for copy-up

• Exports do_splice_direct so overlayfs can copy regular-file data between layers.

fs/splice.c

fs.hDeclare VFS stacking interfaces +17/-0

Declare VFS stacking interfaces

• Adds the maximum stacking depth, a superblock depth field, and the inode dentry-open hook. Declares the open, permission, and splice helpers used by overlayfs.

include/linux/fs.h

mount.hDeclare private mount cloning +3/-0

Declare private mount cloning

• Exposes clone_private_mount for stacking filesystems that need isolated references to their underlying paths.

include/linux/mount.h

Refactor (1) +0 / -11

internal.hRemove private declarations for exported VFS helpers +0/-11

Remove private declarations for exported VFS helpers

• Removes local declarations of __inode_permission and do_splice_direct; their declarations now reside in the public filesystem header.

fs/internal.h

Documentation (4) +215 / -0

LockingRecord locking rules for the dentry-open hook +2/-0

Record locking rules for the dentry-open hook

• Adds the new inode operation to the filesystem locking reference and records that it is called without the listed lock.

Documentation/filesystems/Locking

overlayfs.txtDocument overlayfs v18 semantics +199/-0

Document overlayfs v18 semantics

• Describes mounting, upper and lower layers, copy-up, merged directories, whiteouts, and known non-standard behavior.

Documentation/filesystems/overlayfs.txt

vfs.txtDocument the stacking filesystem open hook +7/-0

Document the stacking filesystem open hook

• Adds dentry_open to the inode-operations reference and explains how it opens an underlying file for native I/O.

Documentation/filesystems/vfs.txt

MAINTAINERSAdd overlayfs maintainer entry +7/-0

Add overlayfs maintainer entry

• Lists the overlayfs maintainer, mailing list, source files, and documentation.

MAINTAINERS

Other (4) +19 / -0

KconfigInclude overlayfs configuration +1/-0

Include overlayfs configuration

• Sources the new overlayfs Kconfig entry so kernel builds can select it.

fs/Kconfig

MakefileBuild overlayfs when selected +1/-0

Build overlayfs when selected

• Adds the overlayfs directory to the filesystem build conditional on CONFIG_OVERLAYFS_FS.

fs/Makefile

KconfigDefine optional overlayfs support +10/-0

Define optional overlayfs support

• Introduces the tristate CONFIG_OVERLAYFS_FS option and summarizes upper/lower layer behavior.

fs/overlayfs/Kconfig

MakefileAssemble the overlayfs filesystem +7/-0

Assemble the overlayfs filesystem

• Builds the overlayfs object from its superblock, inode, directory, readdir, and copy-up components.

fs/overlayfs/Makefile

[DeathCamel58]

Goes with OpenIPC/firmware#2781, which sets CONFIG_OVERLAYFS_FS=y in s3l.generic.config so S3L images use this.

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (9) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Directory reads can omit files silently 🐞 Bug ≡ Correctness

Description

ovl_dir_read() discards err and returns zero after an underlying readdir or cache-allocation
failure. Merged readdir can then cache a partial listing, and an empty-directory check can treat
that incomplete listing as complete.

Code

fs/overlayfs/readdir.c[188]

+	return 0;

Evidence

The function records both VFS and filler errors but returns success; its callers rely on a nonzero
result to reject incomplete listings.

fs/overlayfs/readdir.c[179-189]
fs/overlayfs/readdir.c[312-327]
fs/overlayfs/readdir.c[459-490]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ovl_dir_read()` discards errors from the underlying readdir operation and its filler, allowing incomplete directory scans to appear successful.
## Fix Focus Areas
- fs/overlayfs/readdir.c[179-189]
## Recommended Fix
Return the accumulated `err` after closing `realfile`, and retain the callers' existing cleanup on nonzero returns.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. A failed directory sync can crash the kernel 🐞 Bug ☼ Reliability

Description

ovl_dir_fsync() stores a failed ovl_path_open() result in od->realfile without clearing the
error pointer. If a lower-only directory becomes merged while its descriptor is open, a directory
reset can leave this field null; a subsequent upper-open failure leaves the error pointer for the
next sync or release to use as a file.

Code

fs/overlayfs/readdir.c[R402-404]

+		od->realfile = ovl_path_open(&upperpath, O_RDONLY);
+		if (IS_ERR(od->realfile))
+			return PTR_ERR(od->realfile);

Evidence

Reset explicitly clears the saved file during a lower-to-merged transition, while the sync failure
path retains an error pointer that release passes to fput().

fs/overlayfs/readdir.c[191-207]
fs/overlayfs/readdir.c[392-418]
fs/overlayfs/readdir.c[423-447]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A failed upper-directory open remains in `od->realfile` as an error pointer, which later file operations dereference or release.
## Fix Focus Areas
- fs/overlayfs/readdir.c[392-418]
## Recommended Fix
Open into a temporary `struct file *`; assign it to `od->realfile` only on success, leaving that field NULL on failure.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Directory sync can miss upper-layer changes 🐞 Bug ≡ Correctness

Description

ovl_dir_fsync() reopens the upper directory only when od->realfile is null, although that field
can still refer to the lower directory opened by ovl_dir_open(). If a lower-only directory is
copied up after the descriptor is opened, fsync on that descriptor syncs the old lower directory
rather than the upper directory receiving changes.

Code

fs/overlayfs/readdir.c[R398-402]

+	if (!od->realfile) {
+		struct path upperpath;
+
+		ovl_path_upper(file->f_path.dentry, &upperpath);
+		od->realfile = ovl_path_open(&upperpath, O_RDONLY);

Evidence

Open retains the initially selected real path; copy-up changes the directory's backing path, but
fsync tests only whether a saved file exists.

fs/overlayfs/readdir.c[392-407]
fs/overlayfs/readdir.c[423-447]
fs/overlayfs/dir.c[346-359]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
An open lower-directory file can remain in `od->realfile` after copy-up, causing fsync to target the wrong filesystem.
## Fix Focus Areas
- fs/overlayfs/readdir.c[392-407]
- fs/overlayfs/readdir.c[423-447]
## Recommended Fix
Detect when the saved file refers to the lower directory and acquire an upper-directory file for fsync, without changing the descriptor's iteration state. Handle an upper-open failure without storing an error pointer.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View action required (1)

4. A failed rename can leave both names visible 🐞 Bug ≡ Correctness

Description

ovl_rename() creates the old-name whiteout after a successful vfs_rename() and returns the
whiteout error without reversing the rename. When whiteout creation fails for a source represented
in the lower layer, the destination exists while the lower old name becomes visible again.

Code

fs/overlayfs/dir.c[R570-571]

+	if (old_type != OVL_PATH_UPPER || old_opaque)
+		err = ovl_whiteout(old_upperdir, old);

Evidence

The code performs the upper rename first, then stores a separately fallible whiteout result in the
syscall error without rollback.

fs/overlayfs/dir.c[559-585]
fs/overlayfs/dir.c[19-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A whiteout failure occurs after the upper rename has committed, so the returned error does not reflect the resulting namespace.
## Fix Focus Areas
- fs/overlayfs/dir.c[550-585]
## Recommended Fix
Arrange the required old-name whiteout atomically with the rename where possible, or add a recovery path that restores a consistent namespace and returns a result matching the committed operation.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. File owners can lose control of new links 🐞 Bug ≡ Correctness

Description

ovl_link() initializes the new overlay inode's UID and GID from the destination directory instead
of the linked file. When those owners differ, ownership checks against the overlay inode can reject
the file owner's metadata operations through the new link.

Code

fs/overlayfs/dir.c[452]

+		ovl_copyattr(upperdir->d_inode, newinode);

Evidence

ovl_copyattr() copies UID and GID; the inode used for the new link receives them from its parent,
while generic attribute checks consult the target inode's ownership.

fs/overlayfs/dir.c[438-457]
fs/overlayfs/overlayfs.h[59-64]
fs/attr.c[44-81]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A new hard-link alias receives its parent directory's ownership in its overlay inode rather than the underlying linked file's ownership.
## Fix Focus Areas
- fs/overlayfs/dir.c[438-457]
## Recommended Fix
Initialize the new overlay inode's attributes from `newdentry->d_inode` or `olddentry->d_inode`, not `upperdir->d_inode`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. A failed hard link can still create a file 🐞 Bug ≡ Correctness

Description

ovl_link() allocates its overlay inode after vfs_link() has successfully created the upper hard
link, but its allocation-failure path does not undo that link. Under memory pressure, link(2)
returns ENOMEM while the destination name remains in the upper layer.

Code

fs/overlayfs/dir.c[R448-450]

+		if (!newinode) {
+			err = -ENOMEM;
+			goto link_fail;

Evidence

The underlying link is made before ovl_new_inode(); the link_fail label only handles a possible
whiteout and drops a dentry.

fs/overlayfs/dir.c[438-463]
fs/namei.c[3629-3634]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Overlay inode allocation can fail after the underlying hard link has already been created, leaving a destination behind despite a failed syscall.
## Fix Focus Areas
- fs/overlayfs/dir.c[423-463]
## Recommended Fix
Allocate the overlay inode before calling `vfs_link()`, and release it if the underlying link fails. Ensure any remaining post-link failure path rolls back the upper link.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. Copy-up silently drops file attributes 🐞 Bug ≡ Correctness

Description

ovl_copy_up_xattr() treats a zero-length vfs_getxattr() result as a reason to exit its attribute
loop, while returning zero as success. Copying a file with an empty-valued xattr therefore omits
that attribute and every attribute listed after it.

Code

fs/overlayfs/copy_up.c[R55-59]

+		size = vfs_getxattr(old, name, value, XATTR_SIZE_MAX);
+		if (size <= 0) {
+			error = size;
+			goto out_free_value;
+		}

Evidence

The getter's length may validly be zero, and the setter supports zero-length values, but this loop
exits before setting one.

fs/overlayfs/copy_up.c[48-63]
fs/xattr.c[122-143]
fs/xattr.c[231-264]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A valid zero-length xattr ends copy-up's attribute loop without an error, silently omitting metadata.
## Fix Focus Areas
- fs/overlayfs/copy_up.c[48-63]
## Recommended Fix
Treat only negative `vfs_getxattr()` returns as errors. Pass a zero length to `vfs_setxattr()` and continue iterating.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View review recommended (2)

8. Copy-up can hide lower-layer files 🐞 Bug ≡ Correctness

Description

ovl_copy_up_xattr() copies reserved trusted.overlay.* attributes from a lower object into its
new upper object without filtering them. If an imported lower directory carries
trusted.overlay.opaque=y, copying it up promotes that attribute into overlay control metadata, so
subsequent lookup hides its lower children.

Code

fs/overlayfs/copy_up.c[60]

+		error = vfs_setxattr(new, name, value, size, 0);

Evidence

Copy-up writes every enumerated xattr, and later lookup interprets the reserved names on upper
objects as instructions to suppress lower entries.

fs/overlayfs/copy_up.c[48-63]
fs/overlayfs/copy_up.c[190-215]
fs/overlayfs/super.c[215-228]
fs/overlayfs/super.c[300-326]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Copy-up promotes reserved attributes from lower content into upper-layer overlay control metadata, changing which lower files are visible.
## Fix Focus Areas
- fs/overlayfs/copy_up.c[48-63]
- fs/overlayfs/super.c[315-326]
## Recommended Fix
Skip `trusted.overlay.*` when copying lower xattrs. Preserve overlay-generated opaque and whiteout state through the existing explicit overlay operations instead.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

9. Invalid mount options leak kernel memory 🐞 Bug ☼ Reliability

Description

ovl_fill_super() jumps directly to out_free_ufs when ovl_parse_opt() fails, bypassing the
cleanup for option strings already allocated by the parser. Repeated mount attempts with a valid
directory option followed by an invalid option retain those allocations after each rejected mount.

Code

fs/overlayfs/super.c[R539-541]

+	err = ovl_parse_opt((char *) data, &ufs->config);
+	if (err)
+		goto out_free_ufs;

Evidence

The parser can allocate one string before rejecting a later token; the selected failure label skips
the frees for both strings.

fs/overlayfs/super.c[486-521]
fs/overlayfs/super.c[534-547]
fs/overlayfs/super.c[649-655]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Partially parsed mount options are leaked when option parsing returns an error.
## Fix Focus Areas
- fs/overlayfs/super.c[486-521]
- fs/overlayfs/super.c[534-555]
- fs/overlayfs/super.c[649-655]
## Recommended Fix
Route parser failures through `out_free_config`, whose initialized option pointers can be freed safely, rather than jumping straight to `out_free_ufs`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can hide the parts of a finding you never read, like the evidence or the agent prompt

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[DeathCamel58]

These are all in the overlayfs v18 code itself (fs/overlayfs/*), which this PR imports unchanged from the ingenic-t31 kernel's 0001-overlayfs.v18.patch, so the T31 copy has them too. I'd rather keep the two identical than fork the S3L copy here. If any of them matter in practice, backporting the mainline fixes to both kernels would be a separate change.

[openipc-ai]

No objection to the approach, and nothing here should need a respin. fs/overlayfs/ is byte-identical to ingenic-t31, and the file list and line counts match T31's e7666aa11e, so what follows is existing v18 behaviour rather than anything this port introduced. The option is off by default, so this changes nothing on a camera until OpenIPC/firmware#2781 turns it on. This comes from reading the code at ae44f23d; nothing was built or run on a camera.

One test to ask for: firstboot and sysupgrade -n on the IP4M-1026E. The testing described covers stock ↔ OpenIPC flashing, which doesn't reach this path. Overlayfs holds mnt_want_write on its upper mount for as long as it is mounted rw (super.c:608), so mount -o remount,ro /overlay should return EBUSY. quiesce_overlay in firmware's sysupgrade relies on that remount to stop the jffs2 GC thread before erasing rootfs_data. When it's refused, it warns and erases live. Please paste the output of a run, including whether Could not remount ... erasing it live appears and whether the settings are really gone after the reboot. The same output on OpenIPC/firmware#2781 is fine, since it's waiting on this PR.

Small bugs for a follow-up, on both ambarella-s3l and ingenic-t31, not for this PR. Keeping this PR identical to T31 is worth more than fixing them here.

• readdir.c:188: ovl_dir_read() always returns 0, so errors collected in err are lost. A partial listing could let ovl_check_empty_dir pass, and rmdir would then write a whiteout over a non-empty lower directory.
• readdir.c:402: ovl_dir_fsync() leaves an ERR_PTR in od->realfile when the open fails, and ovl_dir_release() then calls fput() on it.
• readdir.c:166: ovl_fill_upper() returns -ENOMEM without setting rdd->err, so ovl_dir_read() may retry at the same position for as long as the allocation fails. I didn't trace this one through vfs_readdir.

Known limits of v18, for the record. Copy-up creates the file under its final name and fills it in place (copy_up.c:192), and removal unlinks the upper file before writing the whiteout (dir.c:378). A power cut in either window can leave a partial file hiding the good one, or bring a deleted file back, until the overlay is wiped. T31 has the same exposure, and I'm not asking for a change here.

[DeathCamel58]

Thanks for merging. I ran the firstboot / sysupgrade -n test on the IP4M-1026E. The full output is on OpenIPC/firmware#2781, as you suggested. In short:

• remount,ro is refused, as predicted: mount -o remount,ro /overlay gives Resource busy.
• firstboot erases live: it prints Could not remount /mnt/overlay read-only; erasing it live. After the reboot the settings are really gone: a marker file in /etc is missing, and root's password is back to unset.
• sysupgrade -n with a new rootfs hands PID 1 over to a RAM root before flashing, which releases the overlay, so there's no live erase on that path.

Noted on the three readdir.c bugs and the v18 limits, which are shared with ingenic-t31.