[Bug] - devtmpfs /dev size=4m ignored since kernel 6.15; /dev sized at ~50% of RAM

[praveenworkid]

Describe the bug

On the AL2023 kernel-6.18 line, /dev (devtmpfs) is no longer capped at the fixed 4 MB it used to be on the kernel-6.12 line — it now defaults to ~50% of instance RAM, so it scales with instance size.

systemd requests /dev be mounted with size=4m on both kernels. On kernel <= 6.12 devtmpfs reapplied that option on each mount (via reconfigure_single()), so /dev was capped at 4 MB. Since kernel 6.15 it no longer reapplies mount options — /dev just reuses the kernel's original early mount, which has no size limit, so it defaults to ~50% of RAM and systemd's size=4m is silently ignored.

This is upstream commit cb0e0a8bf4e1 ("devtmpfs: replace ->mount with ->get_tree in public instance"), merged in Linux 6.15. It converted /dev to the new mount API and dropped the option-reapplication logic, effectively re-breaking the 2022 fix a6097180d884 ("devtmpfs regression fix: reconfigure on each mount"). The commit message says the new ->get_tree "simply takes an extra reference on the existing internal mount as before", so the change of behavior appears unintended.

To Reproduce

1. Launch an instance from an AL2023 AMI on the kernel-6.12 line and run findmnt /dev.
2. Launch an instance of the same size from an AL2023 AMI on the kernel-6.18 line and run findmnt /dev.
3. Compare the size= value.

Observed (two instances, same size, ~3830 MiB RAM, same systemd 252.23):

# kernel 6.12.83-113.160.amzn2023.aarch64
/dev devtmpfs devtmpfs rw,nosuid,seclabel,size=4096k,nr_inodes=479804,mode=755

# kernel 6.18.39-79.141.amzn2023.aarch64
/dev devtmpfs devtmpfs rw,nosuid,seclabel,size=1917144k,nr_inodes=479286,mode=755

On 6.18 the size is exactly the tmpfs "half of RAM" default (nr_blocks == nr_inodes == ~RAM/2 pages), confirming size=4m had no effect.

Expected behavior

Mounting /dev with size=4m should cap /dev at 4 MB, as it did on kernel 6.12 and earlier.

Environment

• OS: Amazon Linux 2023 (aarch64)
• Bad: kernel 6.18.39-79.141.amzn2023.aarch64, systemd 252.23-12.amzn2023
• Good: kernel 6.12.83-113.160.amzn2023.aarch64, systemd 252.23-11.amzn2023

Additional context

• Regressing commit (Linux 6.15): torvalds/linux@cb0e0a8bf4e1
• 2022 fix it re-broke: torvalds/linux@a6097180d884

Questions:

1. Is this a known/intended change in the AL2023 6.18 kernel?
2. Any plan to carry a fix (restore option reapplication on the public /dev mount)?

Note: size= on devtmpfs is a cap, not a memory reservation, so the larger value does not itself consume extra memory — but it is a user-visible behavior change and defeats the size/nr_inodes limits set on /dev.